Make et Hostinger pour solopreneur : quoi automatiser, quoi héberger, et dans quel ordre

Quand on lance une activité seul, le problème n’est pas le manque d’outils. C’est l’inverse. Chaque vidéo propose une nouvelle plateforme, chaque essai ajoute un abonnement, et la semaine finit avec cinq tableaux de bord ouverts pour une seule demande client.

Make et Hostinger peuvent former une base utile, à condition de ne pas leur demander la même chose. Make déplace et transforme des informations entre vos applications. Hostinger gère un domaine, des emails ou un hébergement selon la formule choisie. L’un orchestre un flux. L’autre fournit une partie de l’infrastructure visible par vos prospects.

Ce guide ne promet donc pas un business automatique. Il montre un ordre de marche sobre : publier un point d’entrée crédible, capter une demande, puis automatiser une seule tâche répétitive sans perdre le contrôle.

Make et Hostinger : deux rôles à ne pas confondre

Un hébergeur ne suit pas vos prospects. Un outil d’automatisation ne remplace pas un site clair. La distinction paraît évidente, mais beaucoup de stacks de solopreneurs deviennent fragiles parce qu’elles commencent par les connexions techniques avant de définir le parcours client.

Le dernier point compte davantage que les trois autres. Si personne ne sait quoi faire d’une demande, Make accélérera seulement le désordre. Commencez par écrire le flux en français courant : « quand une personne remplit le formulaire, je reçois ses coordonnées, je confirme la réception, puis je la rappelle sous le délai annoncé ».

Ce que Make peut réellement automatiser au démarrage

Dans Make, un workflow s’appelle un scénario. Il est composé de modules qui surveillent, transforment ou envoient des données. La documentation officielle propose par exemple de surveiller de nouvelles lignes dans un tableur puis d’envoyer une notification à l’équipe commerciale. Pour un indépendant, le même principe peut rester beaucoup plus simple.

Voici un premier scénario raisonnable :

1. un formulaire reçoit une demande ;
2. Make ajoute la demande dans un tableur ou un CRM léger ;
3. Make vous envoie une notification avec le nom, le téléphone et le besoin ;
4. le prospect reçoit un accusé de réception factuel ;
5. vous décidez personnellement de la réponse et de la prochaine action.

Ce flux évite la copie manuelle et réduit le risque d’oubli. Il ne confie ni le devis, ni la promesse commerciale, ni l’envoi d’une réponse complexe à une machine. Cette limite est saine tant que votre offre et vos cas particuliers évoluent encore.

Webhook ou vérification planifiée ?

Un webhook déclenche généralement le scénario dès qu’une application transmet une nouvelle donnée. Une vérification planifiée demande périodiquement à une application si quelque chose a changé. Le webhook est utile pour une demande entrante qui doit être traitée vite. La vérification planifiée convient à un relevé moins urgent, comme la préparation d’un récapitulatif quotidien.

Ne choisissez pas selon ce qui paraît le plus technique. Choisissez selon le délai métier. Une demande de rappel exige une alerte rapide ; un tableau de bord hebdomadaire peut attendre.

Le coût de Make se mesure en exécutions, pas seulement en scénarios

Make utilise désormais des crédits comme unité de consommation. Pour la plupart des applications non liées à l’IA, une opération correspond à un crédit. Un module peut toutefois s’exécuter plusieurs fois lorsqu’il traite plusieurs éléments. Un scénario court lancé sur chaque événement peut donc consommer moins qu’un scénario qui interroge inutilement plusieurs services toutes les quelques minutes.

Avant d’activer une automatisation, estimez :

• combien de fois le déclencheur s’exécute ;
• combien d’éléments il récupère à chaque passage ;
• combien de modules traitent chaque élément ;
• si une fonction d’IA ajoute une consommation variable ;
• si le flux peut être regroupé sans dégrader le délai de réponse.

Le plan gratuit peut servir à prototyper un premier scénario, mais ses limites et son intervalle minimal d’exécution doivent être vérifiés sur la page tarifaire au moment de choisir. Les offres évoluent. Construisez d’abord le scénario sur quelques cas de test, observez sa consommation réelle, puis décidez si un abonnement est justifié.

Ce que Hostinger peut gérer — et ce qu’il ne faut pas lui attribuer par réflexe

Hostinger peut cumuler plusieurs rôles : registrar du domaine, gestionnaire DNS, fournisseur d’emails et hébergeur web. Vous n’êtes pas obligé d’utiliser tous ces rôles ensemble. Un domaine acheté ou géré chez Hostinger peut, par exemple, pointer vers un site déployé sur Vercel. Dans ce cas, le site n’est pas hébergé chez Hostinger : seuls le domaine et éventuellement le DNS y restent gérés.

Cette nuance évite une erreur fréquente : modifier les serveurs de noms ou supprimer des enregistrements DNS sans vérifier les emails existants. Avant tout changement, exportez ou notez les enregistrements utiles, notamment MX, TXT, SPF, DKIM et DMARC. Une mauvaise modification peut rendre le site ou la messagerie indisponible.

Pour un site hébergé chez Hostinger

Vérifiez le périmètre exact de l’offre : technologie supportée, fréquence des sauvegardes, restauration, environnement de test, ressources, renouvellement et conditions de migration. Hostinger indique fournir une protection par sauvegardes selon ses plans et installer automatiquement un certificat SSL pour les domaines ajoutés à un hébergement web ou cloud compatible. Contrôlez néanmoins l’état HTTPS après la mise en ligne.

Pour un site déployé ailleurs

Ajoutez d’abord le domaine dans le projet de destination. La plateforme vous indiquera ensuite les enregistrements A ou CNAME attendus. Vercel recommande d’inspecter la configuration propre au projet plutôt que de copier aveuglément une valeur trouvée dans un tutoriel. Ajoutez les enregistrements chez le fournisseur qui gère réellement votre DNS, puis vérifiez le domaine et le certificat.

Ne changez jamais le DNS pendant une période commerciale sensible sans avoir noté l’état initial et préparé un retour arrière.

Le bon ordre pour un solopreneur

Étape 1 — Stabiliser l’offre et le point d’entrée

Écrivez en une phrase qui vous aidez, quel problème vous résolvez et quelle est la prochaine étape. Publiez une page qui contient cette promesse, une preuve, un moyen de contact et le délai de réponse. Un site de cinq pages confuses n’est pas supérieur à une page claire.

Étape 2 — Choisir une seule source de vérité

Décidez où vivent les demandes : tableur, CRM ou base légère. La messagerie ne doit pas être l’unique mémoire commerciale. Chaque demande doit posséder au minimum une date, une source, un statut et une prochaine action.

Étape 3 — Traiter dix demandes manuellement

Cette phase révèle les variantes réelles : coordonnées incomplètes, doublons, demandes hors cible, absence de réponse, urgence ou besoin de pièce jointe. Sans ces exemples, vous automatisez un parcours imaginaire.

Étape 4 — Automatiser le transfert le plus répétitif

Commencez par déplacer les données du formulaire vers votre source de vérité et créer une notification. Gardez la réponse commerciale sous validation humaine. Testez avec de fausses données, dont un champ vide, un numéro mal formaté et une soumission en double.

Étape 5 — Ajouter la gestion des erreurs

Un scénario fiable doit prévoir ce qui se passe lorsqu’un service ne répond plus ou qu’une donnée ne respecte pas le format attendu. Make propose des gestionnaires d’erreurs et le stockage des exécutions incomplètes. Au minimum, conservez une alerte lisible et une file à reprendre manuellement. Une automatisation silencieuse qui perd une demande est plus dangereuse qu’une saisie manuelle.

Trois automatisations adaptées à une petite activité

Demande entrante vers suivi commercial

Le formulaire alimente un tableau de suivi, crée une alerte et confirme la réception. C’est le meilleur premier scénario, car son résultat est visible et mesurable : aucune demande ne doit rester sans statut.

Rappel interne après un devis

Lorsqu’un devis est envoyé, une date de relance est calculée. Le jour venu, Make crée une tâche interne. Le message final reste préparé ou validé par vous. Vous automatisez la mémoire, pas la relation.

Récapitulatif hebdomadaire

Une fois par semaine, le scénario compte les nouvelles demandes, celles en attente et les prochaines actions dépassées. Ce récapitulatif suffit souvent à repérer les fuites sans construire un tableau de bord complexe.

Les erreurs qui coûtent plus cher que l’abonnement

• Automatiser une décision floue : si vous ne savez pas quelle réponse est correcte, le scénario ne le saura pas davantage.
• Enregistrer des données personnelles partout : limitez les champs, les copies et les accès à ce qui sert réellement le traitement.
• Ignorer les doublons : prévoyez une clé ou une vérification avant de créer un nouveau contact.
• Supprimer les alertes : un échec doit laisser une trace exploitable.
• Dépendre d’un seul compte personnel : documentez les connexions, les propriétaires et la procédure de reprise.
• Changer le DNS sans inventaire : le site peut fonctionner tandis que la messagerie cesse de recevoir, ou l’inverse.

La checklist avant de passer en production

1. Le formulaire affiche une confirmation vraie, seulement après enregistrement ou envoi réussi.
2. La demande apparaît dans une source de vérité unique.
3. Une personne identifiée reçoit l’alerte.
4. Les erreurs déclenchent une notification et restent récupérables.
5. Les accès utilisent des comptes maîtrisés et une authentification renforcée.
6. Le domaine principal, sa variante www et le HTTPS conduisent vers une seule version canonique.
7. Les enregistrements email ont été vérifiés après toute modification DNS.
8. Le scénario a été testé avec des données normales, incomplètes et dupliquées.
9. Une procédure manuelle existe si Make ou l’hébergement devient indisponible.

Commencer petit, mais construire quelque chose de récupérable

Make et Hostinger peuvent être de bons outils de départ parce qu’ils réduisent une partie de la barrière technique. Ils ne remplacent toutefois ni une offre claire, ni une base de suivi, ni une procédure de secours. Le système le plus utile n’est pas celui qui possède le plus de connexions. C’est celui que vous comprenez, que vous pouvez contrôler et que vous savez reprendre à la main.

Pour cette semaine, fixez un objectif sobre : une page qui explique votre offre, un formulaire testé, une liste unique des demandes et un scénario qui vous alerte sans décider à votre place. Lorsque ce flux tient sur dix cas réels, vous pourrez automatiser la prochaine friction avec beaucoup moins de risque.