MakeDébutant

5 automatisations à mettre en place quand on est freelance

Cinq automatisations Make complètes pour freelance : relances de factures, rendez-vous qualifiés, devis signés, pré-facturation et tri des leads entrants.

Photo de Jean-Paul LOVISSOUKPO20 min de lectureMis à jour le 29 juillet 2026
Poste de travail de freelance d'où partent cinq flux d'automatisation ordonnés

Être freelance, c’est exercer deux métiers en même temps. Il y a celui pour lequel tes clients te paient, et il y a l’autre : relancer les factures, qualifier les demandes entrantes, rédiger les devis, compter les heures, trier les opportunités. Ce second métier ne rapporte rien, il grignote tes soirées, et il a une particularité intéressante : il est presque entièrement automatisable avec des outils no-code. Autant dire qu’on va lui régler son compte.

Les cinq automatisations freelance à traiter en priorité sont les relances de factures, la qualification des prospects, la génération du devis et du contrat, la préfacturation à partir des heures suivies et le tri des opportunités entrantes. Elles réduisent les oublis sur les tâches qui touchent directement au chiffre d’affaires et à la trésorerie.

Ce guide construit cinq automatisations complètes avec Make, la plateforme d’automatisation visuelle, chacune réalisable en moins d’une heure, chacune avec sa version simple pour démarrer et sa version renforcée pour tenir dans la durée. Pas de généralités : les colonnes exactes des registres, les modules dans l’ordre, les formules à recopier et le piège classique de chaque scénario.

Un mot sur les chiffres avant de commencer, parce que tu vas en croiser beaucoup. Les temps gagnés annoncés dans les articles du genre sortent souvent de nulle part. Ici, chaque estimation affiche ses hypothèses (nombre de factures, minutes par tâche manuelle) pour que tu recalcules avec tes propres volumes. Une estimation honnête et ajustable vaut mieux qu’une promesse ronde et invérifiable. Les promesses rondes, garde-les pour LinkedIn.

Ce qu’il te faut

  • un compte Make, le plan Free suffit pour démarrer
  • un compte Google (Sheets, Gmail, Drive et Docs sont utilisés partout)
  • selon les automatisations choisies : des comptes gratuits Tally, Cal.com, Toggl Track et DocuSeal (une nuance sur les webhooks Cal.com t’attend dans l’automatisation 2)
  • environ 1 heure par automatisation, test compris

Le modèle de crédits Make, et comment lire les coûts annoncés

Avant de poser le premier module, deux minutes sur ce que Make facture, parce que chaque automatisation de ce guide affichera son coût mensuel estimé. Dans Make, chaque exécution d’un module s’appelle une opération, et ces opérations consomment des crédits, l’unité décomptée de ton forfait (un module standard consomme en général 1 crédit par exécution). D’après la page tarifaire relevée en juillet 2026, le plan Free inclut 1 000 crédits par mois, et le plan Core, à 9 dollars par mois, en donne 10 000. Détail utile pour la suite : les modules de branchement If-else et Merge consomment des opérations mais aucun crédit, ce qui rend les scénarios à conditions très économes.

Le plan Free porte en revanche deux limites qui comptent plus que les crédits : 2 scénarios actifs au maximum, et 15 minutes d’intervalle minimum entre deux exécutions planifiées. Les cinq automatisations de ce guide tiennent très largement dans 1 000 crédits, mais elles représentent six scénarios (la qualification des prospects en utilise deux, un par webhook) : pour tout faire tourner en parallèle, il faudra le plan Core. La bonne stratégie de démarrage en découle : commence par la relance de factures, qui tient dans le plan Free avec un seul scénario, valide-la sur un mois, puis décide si le reste vaut 9 dollars. Vu ce que ça rend, le billet est vite rentabilisé.

Automatisation 1 : relancer les factures impayées à J+7, J+15 et J+30

La première place revient à la relance de factures, parce que c’est la seule automatisation de la liste qui récupère directement de l’argent. Une facture impayée se relance en moyenne trois fois, chaque relance manuelle demande de vérifier l’échéance, retrouver l’email, adapter le ton, et c’est précisément le genre de tâche qu’on repousse. Résultat : des paiements qui traînent des semaines de plus que nécessaire. Ton argent dort chez les autres.

La construction commence par le registre. Crée un Google Sheet nommé « Factures » avec une ligne par facture et ces colonnes, dont l’orthographe exacte compte puisque les modules Make s’y référeront.

Colonne Contenu Exemple
numero numéro de la facture F-2026-041
client nom du client Studio Kpade
email adresse de facturation compta@studiokpade.com
montant montant TTC en chiffres 1200
echeance date d’échéance au format AAAA-MM-JJ 2026-07-15
statut envoyee ou payee envoyee
palier_relance 0, 1, 2 ou 3, géré par le scénario 0

Ce registre alimente un scénario planifié chaque matin à 8 h. Premier module : Google Sheets, Search Rows, avec deux filtres combinés, statut égal à envoyee et echeance antérieure à {{formatDate(now; "YYYY-MM-DD")}}. Chaque ligne trouvée devient un bundle qui traverse la suite du scénario. Deuxième étage : un module If-else à trois conditions ordonnées du retard le plus grand au plus petit, parce que seule la première condition vraie s’exécute et qu’une facture à J+35 doit tomber dans la branche J+30, jamais dans la J+7. La première condition s’écrit littéralement echeance antérieure ou égale à {{formatDate(addDays(now; -30); "YYYY-MM-DD")}} et palier_relance inférieur à 3, et les deux suivantes reprennent le même motif avec leurs valeurs :

  • retard de 30 jours ou plus et palier_relance inférieur à 3 : dernier rappel
  • retard de 15 jours ou plus et palier_relance inférieur à 2 : relance ferme
  • retard de 7 jours ou plus et palier_relance inférieur à 1 : relance courtoise

Chaque branche contient deux modules : Gmail, Send an Email avec le texte du palier, puis Google Sheets, Update a Row qui écrit le palier de la branche dans palier_relance : 3 pour le dernier rappel, 2 pour la relance ferme, 1 pour la courtoise. Écrire la valeur, et surtout ne pas l’incrémenter : une facture à J+40 encore à 0 partirait sinon de 0 vers 1 après son dernier rappel, la condition « palier inférieur à 3 » resterait vraie, et le même email repartirait chaque matin. Un module Merge referme les branches. La double condition de chaque palier fait tout le travail d’idempotence : une facture déjà relancée au palier 2 ne recevra jamais deux fois l’email du palier 2, même si le scénario rejoue après une erreur, puisque la colonne palier_relance garde la trace de ce qui est parti. Le fonctionnement complet se lit d’un coup d’œil sur le cycle quotidien.

Diagramme du processus : Chaque matin : lecture du registre, Facture en retard et non payée ?, Rien à envoyer aujourd'hui, Palier atteint : J+7, J+15 ou J+30 ?, Email courtois, Email ferme, Dernier rappel, Palier noté dans le registre.

Le schéma montre aussi où vit ton seul geste manuel : à l’encaissement, tu passes statut à payee, et la facture sort définitivement du cycle dès le lendemain matin. Ce geste unique cache le piège classique de l’automatisation : relancer un client qui a payé la veille. Il se produit quand l’envoi se décide sur des données périmées, une liste de retardataires préparée la veille, ou un registre que tu ne mets à jour qu’en lot le vendredi. La parade est double : dans le scénario, la sélection et l’envoi vivent dans la même exécution matinale, à quelques secondes d’écart ; et de ton côté, le registre se met à jour dès l’encaissement, jamais en fin de semaine. La version renforcée ajoute un palier de ton par email : courtois à J+7 (une facture oubliée arrive aux meilleurs, tout le monde n’a pas la discipline d’un Lannister, la famille de Game of Thrones qui paie toujours ses dettes), factuel à J+15 avec le rappel du numéro et du montant, et à J+30 l’annonce claire de la suite (suspension des travaux en cours, indemnité forfaitaire de recouvrement).

Côté coûts, le calcul est transparent : 31 exécutions par mois consomment 31 crédits de recherche, plus 2 crédits par relance effectivement envoyée (email + mise à jour), les If-else et Merge étant gratuits en crédits. Avec l’hypothèse de 10 factures par mois dont 4 en retard relancées 2 fois en moyenne, cela donne environ 47 crédits par mois. Côté temps, avec ces mêmes hypothèses et 10 minutes par relance manuelle (retrouver la facture, rédiger, envoyer, noter), l’automatisation absorbe environ 1 h 20 par mois, et surtout elle relance à J+7 pile, ce que la version manuelle ne fait jamais. Relancer sans gêne, c’est son métier.

Automatisation 2 : qualifier les prospects avant le rendez-vous

L’argent des factures sécurisé, le poste de dépense de temps suivant se trouve en amont : les rendez-vous de découverte avec des prospects qui n’auraient jamais dû en obtenir un. Trente minutes d’appel pour découvrir un budget dix fois sous ton tarif, c’est une heure perdue en comptant la préparation, et ça se filtre très bien avant le calendrier. Filtre à l’entrée, tranquille au calendrier.

Le principe : personne n’obtient ton lien de réservation sans passer par un court formulaire de qualification. Crée un formulaire Tally (les webhooks et l’intégration Make sont inclus dans son plan gratuit) avec trois questions fermées : le type de besoin (choix parmi tes prestations), le budget (tranches, dont une tranche plancher sous ton tarif minimum), le délai souhaité. Les réponses fermées sont la clé : la qualification devient une simple comparaison de valeurs, sans interprétation.

Le scénario Make démarre sur le webhook Tally (module Tally, Watch New Responses), enchaîne sur un If-else qui teste tes critères, par exemple budget au-dessus de la tranche plancher et délai supérieur à deux semaines. Branche qualifiée : Gmail, Send an Email avec ton lien Cal.com et un mot personnalisé reprenant le besoin exprimé. Branche non qualifiée : un email tout aussi soigné, sans lien de réservation, qui remercie, donne ta fourchette tarifaire et laisse une porte ouverte. Un refus courtois et immédiat sert mieux ta réputation qu’un rendez-vous subi.

La seconde moitié du dispositif s’active quand le prospect qualifié réserve. Dans Cal.com, un webhook se configure dans les réglages développeur sur l’événement de réservation créée, mais d’après la grille tarifaire relevée en juillet 2026, les webhooks sont réservés aux plans payants. Deux options, donc. Avec un plan payant, le webhook déclenche le second scénario Make en temps réel. En restant sur le plan gratuit, la parade passe par le calendrier : chaque réservation Cal.com atterrit dans ton Google Calendar connecté, et un module Google Calendar, Watch Events planifié la détecte à l’exécution suivante, quelques minutes de latence pour zéro euro. Dans les deux cas, la suite est identique : création du dossier Google Drive nommé 2026-07 - Studio Kpade (module Create a Folder), puis ajout d’une ligne dans ton Sheet « Prospects » avec le besoin, le budget déclaré et la date du rendez-vous. Le jour où tu veux un vrai CRM à la place du Sheet, la logique reste identique, y compris pour un CRM sans intégration native branché par son API. L’enchaînement complet, du formulaire au dossier prêt, ressemble à ceci.

Diagramme du processus : Formulaire Tally soumis, Critères de qualification remplis ?, Email avec lien Cal.com, Email courtois sans lien, Réservation détectée : webhook ou calendrier, Dossier Drive créé + ligne registre, "Formulaire Tally soumis", "Email avec lien Cal.com".

Ce schéma révèle le piège de l’automatisation : deux événements indépendants, la soumission du formulaire et la réservation, qui concernent la même personne mais arrivent par deux webhooks séparés, parfois à des jours d’intervalle. La réconciliation se fait par l’email : le second scénario commence par un Search Rows sur le Sheet « Prospects » avec l’email de la réservation, complète la ligne existante s’il la trouve, et sinon crée une ligne marquée sans_formulaire. Cette ligne orpheline est précieuse : elle signale quelqu’un qui a obtenu ton lien Cal.com sans passer par la qualification (transfert entre collègues, vieux lien), exactement le trou dans le filet que tu veux voir.

Le coût en crédits reste minime, autour de 4 crédits par prospect traité sur les deux scénarios, soit une trentaine de crédits pour les 8 demandes mensuelles de notre hypothèse. L’estimation de temps se calcule sur tes volumes : avec l’hypothèse de 8 demandes par mois dont 3 non qualifiées, tu récupères 3 créneaux de 45 minutes (appel + préparation), environ 2 h 15 par mois, et les prospects sérieux réservent sans échange d’emails préalable.

Automatisation 3 : générer devis et contrat, puis les envoyer en signature

Le rendez-vous de découverte qualifié débouche, quand tout se passe bien, sur un accord de principe, et c’est le maillon suivant de la chaîne : transformer « c’est d’accord » en documents signés sans y passer la soirée. La méthode repose sur des modèles Google Docs à variables et sur DocuSeal pour la signature électronique.

Prépare d’abord deux modèles dans Google Docs, un devis et un contrat, en écrivant chaque champ variable entre doubles accolades : {{client}}, {{mission}}, {{montant}}, {{delai}}, {{date}}. Le déclencheur le plus simple est un petit formulaire Tally interne, que tu remplis toi-même en deux minutes à la fin de l’appel : nom du client, email, mission en une phrase, montant, délai. Un formulaire plutôt qu’une ligne de Sheet, parce qu’il se remplit depuis le téléphone dans la foulée du rendez-vous, quand les informations sont fraîches.

Le scénario s’assemble en cinq modules : Tally, Watch New Responses, puis deux fois Google Docs, Create a Document from a Template (le devis, le contrat) qui remplacent chaque {{variable}} par la valeur du formulaire, puis DocuSeal, Create a Submission qui envoie les deux PDF au client pour signature, et enfin Gmail pour te notifier que tout est parti. La partie signature mérite son propre approfondissement, suivi des relances de signature et archivage compris : c’est exactement le sujet de l’automatisation de la signature électronique avec DocuSeal, qui prend le relais de ce paragraphe pour la version complète.

Le piège de cette automatisation est le plus embarrassant de la liste : le document parti chez le client avec un {{montant}} non remplacé au milieu du contrat, parce qu’un nom de variable du modèle ne correspondait plus à celui du formulaire. La parade tient en un module : entre la génération et l’envoi, un If-else teste si le texte du document contient encore la chaîne {{ (le module Google Docs qui récupère le contenu du document généré, puis la fonction contains() de Make). Si oui, la branche d’envoi ne s’exécute pas et tu reçois une alerte à la place ; le client, lui, ne voit jamais le brouillon. Ce contrôle de résidu coûte 2 crédits et t’épargne le pire email de rattrapage de ta semaine. Deux crédits pour éviter la honte, le meilleur ratio du guide.

Les coûts restent anecdotiques, environ 7 crédits par devis envoyé, une trentaine par mois pour 4 propositions. L’estimation de temps par proposition, avec l’hypothèse de 30 minutes de mise en forme manuelle (copier le vieux devis, tout modifier, exporter, renvoyer), tombe à 2 minutes de formulaire : environ 1 h 50 récupérées par mois pour 4 propositions, et des documents qui partent le soir même du rendez-vous, quand ta proposition est encore chaude dans la tête du client.

Automatisation 4 : consolider les heures et pré-facturer chaque 1er du mois

Une fois le contrat signé, la mission tourne, et le temps passé devient la matière première de ta facturation. Le suivi du temps a pourtant un défaut structurel chez les freelances : la saisie se fait au fil de l’eau dans un outil, mais la consolidation de fin de mois (additionner, ventiler par client, préparer les factures) se fait à la main, en général le soir du 31, avec des oublis.

L’outil de saisie reste Toggl Track, dont le plan gratuit couvre largement un usage solo, et dont l’application Make (vérifiée, elle expose les entrées de temps, projets et clients) permet toute la consolidation. La règle d’or en amont : chaque entrée de temps porte un projet, et chaque projet est rattaché à un client dans Toggl. Toute la ventilation automatique repose sur cette discipline de saisie.

Le scénario se planifie le 1er de chaque mois à 7 h, et cette date d’exécution rend les bornes triviales : {{addMonths(now; -1)}} donne le premier jour du mois écoulé, {{addDays(now; -1)}} la veille, donc son dernier jour. Premier module : Toggl Track, liste des entrées de temps entre ces deux dates. Deuxième module : un Array Aggregator groupé par projet, qui transforme la pluie d’entrées individuelles en une ligne par projet avec le total des durées. Troisième étage : Google Sheets, Add a Row dans un onglet « Pré-facturation AAAA-MM », une ligne par projet avec son client, les heures totales, ton taux et le montant calculé ; comme chaque projet Toggl est rattaché à son client, un sous-total par client se lit directement dans le Sheet. Dernier module : un email récapitulatif qui t’attend au réveil, avec le total par client et le montant global du mois. La facturation elle-même reste ton geste : tu relis, tu ajustes, tu émets. L’automatisation prépare, elle n’envoie rien au client, parce qu’une facture fausse coûte plus cher que dix minutes de relecture.

Le piège ici est silencieux, et c’est ce qui le rend dangereux : les entrées de temps saisies sans projet. Elles existent dans Toggl, mais le regroupement par projet les ignore, et les heures disparaissent de la consolidation sans un bruit, donc de ta facturation. La parade : une route dédiée dans le scénario qui compte les entrées sans projet du mois et, s’il y en a, ajoute une ligne « NON AFFECTÉ » bien visible dans l’onglet avec le total d’heures concerné. Une perte silencieuse devient une alerte impossible à manquer, et tu réaffectes ces heures avant d’émettre les factures.

Le coût mensuel est le plus bas du guide, une dizaine de crédits par mois pour une exécution unique. Le gain dépend de ton nombre de clients actifs : avec l’hypothèse de 4 clients et 45 minutes de consolidation manuelle mensuelle (export, additions, vérifications), l’automatisation ramène l’exercice à 10 minutes de relecture, environ 35 minutes gagnées, et supprime surtout la catégorie d’erreur la plus coûteuse du métier : les heures travaillées jamais facturées. Travailler gratuitement sans le savoir, c’est le pire des deals.

Automatisation 5 : trier les opportunités entrantes avec un score IA

Les quatre premières automatisations traitent le travail existant ; la cinquième protège ta ressource la plus dispersée : l’attention que tu donnes au flux entrant. Emails de prospects, notifications de plateformes, mises en relation, le tout mélangé aux newsletters dans la même boîte. Chaque interruption pour évaluer une opportunité moyenne casse une session de travail facturable.

Le même principe de collecte, déduplication et score sert aussi à une veille automatisée avec n8n ; ici, la différence est la décision finale. Une source de veille alimente une synthèse périodique, tandis qu’une opportunité commerciale qualifiée doit interrompre ta journée assez vite pour recevoir une réponse.

Le dispositif : une adresse ou un libellé Gmail dédié aux opportunités (un filtre Gmail y range tout ce qui vient des plateformes et des formulaires de contact), un scénario Make qui se déclenche sur chaque nouveau message (Gmail, Watch Emails sur le libellé), un module Anthropic Claude (l’application est vérifiée dans Make) qui score l’opportunité, et un If-else final : au-dessus du seuil, notification immédiate Telegram ou Slack avec le résumé ; en dessous, un libellé « à revoir » et rien d’autre, tu dépouilleras le lot une fois par semaine. Un peu comme un A&R dans un label de rap, ce dénicheur qui écoute toutes les maquettes et ne fait monter en studio que celles qui le méritent.

Toute la valeur du dispositif se joue dans le prompt de scoring, et c’est le piège de l’automatisation : un prompt vague (« note cette opportunité sur 10 ») renvoie 7/10 pour tout, et le tri ne trie rien. Le prompt qui fonctionne impose des critères binaires, un barème fermé et un format de sortie strict. Voici celui à coller dans le module Claude, à adapter à ton activité dans le premier bloc.

Tu es l'assistant de tri d'un freelance en automatisation no-code.
Son profil, à utiliser comme référentiel de scoring :
- Prestations : automatisation Make/n8n, intégration d'outils, formation.
- Tarif journalier : 450 euros. Mission minimum : 2 jours.
- Clients cibles : PME et indépendants francophones.
- Refus systématiques : missions de développement pur, régie longue
  durée sur site, projets sans budget évoqué ni évocable.

Tu reçois ci-dessous un email entrant brut. Évalue-le avec ces
5 critères BINAIRES (1 si vrai, 0 si faux, jamais de demi-point) :
1. demande_identifiable : l'email contient une demande de prestation
   explicite (pas une newsletter, pas du spam, pas une pub).
2. perimetre_couvert : le besoin correspond aux prestations listées.
3. budget_compatible : un budget est mentionné OU la nature du client
   rend un budget de 900 euros minimum plausible.
4. interlocuteur_direct : l'expéditeur est le décideur ou un contact
   nommé de l'entreprise (pas une plateforme qui masque le client).
5. delai_exploitable : aucun démarrage exigé en urgence absolue
   (moins de 3 jours ouvrés).

Le score final est la SOMME des 5 critères (0 à 5).
Ne reformule pas les critères, ne pondère pas, n'arrondis pas.

Réponds UNIQUEMENT avec ce JSON, sans texte autour :
{
  "score": <0 à 5>,
  "criteres": {"demande_identifiable": 0 ou 1, "perimetre_couvert": 0 ou 1,
   "budget_compatible": 0 ou 1, "interlocuteur_direct": 0 ou 1,
   "delai_exploitable": 0 ou 1},
  "resume": "<le besoin en une phrase factuelle>",
  "signal_fort": "<l'élément le plus décisif, positif ou négatif>"
}

Email à évaluer :
{{texte_email}}

La sortie JSON se parse avec le module JSON, Parse JSON de Make, et le If-else route sur score >= 4 : ces opportunités-là méritent l’interruption, les autres attendront la revue hebdomadaire. Les critères binaires font exactement ce que le barème sur 10 ne faisait pas : deux passages du même email donnent le même score, et le champ signal_fort te dit en un coup d’œil pourquoi une notification arrive. La logique du branchement, avec la première condition vraie qui l’emporte, se règle finement dans If-else et Merge, les modules de branchement de Make.

Ce tri note un message isolé. Si tu veux suivre la relation dans la durée, réconcilier plusieurs adresses et faire perdre du poids aux vieux signaux, passe au lead scoring CRM à deux dimensions. Le score de profil y reste séparé de l’engagement récent.

Ce scénario est le seul du guide dont le coût dépasse le crédit symbolique, et la documentation de l’app Anthropic Claude publie le barème exact : avec Claude Haiku 4.5, 904 tokens d’entrée ou 181 tokens de sortie consomment 1 crédit, en plus du crédit d’opération du module. Sur l’hypothèse de 40 emails par mois, à environ 700 tokens d’entrée et 120 de sortie par scoring, le calcul donne autour de 2,5 crédits par email, soit une centaine de crédits mensuels, très loin d’entamer le plan Core. Relève quand même ton historique Make après la première semaine : tes emails réels seront plus longs ou plus courts que l’hypothèse. Le gain se compte différemment des autres : avec 40 entrants dont 6 réellement qualifiés, ce sont 34 interruptions transformées en une revue groupée hebdomadaire, et l’estimation basse (3 minutes d’attention par entrant évité, contexte de reprise compris) donne environ 1 h 40 par mois, sans compter ce que valent des sessions de travail non fragmentées.

Par où commencer : le récapitulatif et l’ordre d’attaque

Cinq automatisations, cinq scénarios, et une question de priorité, parce que tu ne construiras pas tout le même week-end. Le tableau réunit les estimations de chaque section, avec leurs hypothèses de volume rappelées en tête : une dizaine de factures et 8 demandes entrantes qualifiables par mois, 4 clients actifs, 4 propositions envoyées, 40 emails d’opportunités.

Automatisation Mise en place Temps estimé gagné / mois Crédits Make estimés / mois
1. Relance de factures 45 min 1 h 20, encaissements plus rapides en plus ~50
2. Qualification des prospects 1 h 2 h 15 ~30
3. Devis et contrats signés 1 h 1 h 50 ~30
4. Pré-facturation mensuelle 45 min 35 min, heures oubliées en moins ~10
5. Tri des opportunités 1 h 1 h 40 ~100

Lecture du tableau : entre 6 et 8 heures récupérées chaque mois avec ces volumes moyens, pour environ 4 h 30 de construction une seule fois, et un coût en crédits qui tient très à l’aise dans le plan Core à 9 dollars. La consommation des quatre premières passerait même sous les 1 000 crédits du plan Free, mais sa limite de 2 scénarios actifs ne laisse tourner en continu que la relance de factures et un déclencheur de plus : c’est le nombre de scénarios, pas les crédits, qui justifie le passage au plan payant. Recalcule chaque ligne avec tes volumes : c’est la colonne « temps gagné » qui bougera le plus, et si tu émets trente factures par mois, la première ligne change de catégorie.

L’ordre d’attaque découle du tableau. Commence par la relance de factures : le meilleur investissement du guide, puisqu’elle rapporte du temps et accélère tes encaissements. Enchaîne avec la qualification des prospects, le plus gros gain de temps brut. Les trois autres suivront au rythme où leurs volumes le justifient chez toi. Et à chaque scénario construit, tu maîtriseras un peu mieux les briques qui reviennent partout, les webhooks, les registres Sheets, les If-else, le même vocabulaire que tu retrouveras dans tous les guides Make de ce blog pour pousser chaque automatisation plus loin. Si tu veux comparer tes scénarios avec ceux d’autres freelances qui automatisent, la communauté lesnocodeurs échange là-dessus tous les jours, registres et captures à l’appui.

Questions fréquentes

Quel plan Make faut-il pour ces automatisations ?+
Le plan Free (1 000 crédits par mois) suffit pour démarrer, mais il limite à 2 scénarios actifs et à une exécution toutes les 15 minutes. Pour faire tourner les cinq automatisations en parallèle, le plan Core à 9 dollars par mois donne 10 000 crédits et lève la limite des scénarios actifs, très au-delà des besoins d’un freelance.
Comment arrêter les relances dès qu'une facture est payée ?+
La sélection des factures et l’envoi des relances se font dans la même exécution, chaque matin : le scénario ne relance que les lignes dont le statut est encore « envoyée » au moment où il tourne. Une facture passée à « payée » sort donc du cycle dès le lendemain. Ton seul geste manuel : mettre le statut à jour dès l’encaissement, jamais en lot en fin de semaine.
Peut-on construire ces automatisations sans savoir coder ?+
Oui. Tout se construit dans l’éditeur visuel de Make en assemblant des modules existants : Google Sheets, Gmail, Tally, Cal.com, Toggl Track, DocuSeal. Les seules formules utilisées sont des fonctions de date et de texte de Make, données telles quelles dans l’article, à recopier.
Combien de temps un freelance gagne-t-il vraiment avec ces automatisations ?+
Cela dépend entièrement de tes volumes, et l’article assume de ne donner que des estimations à hypothèses visibles plutôt que des promesses. Avec des volumes moyens (une dizaine de factures et de prospects par mois), l’ordre de grandeur des cinq automatisations réunies se situe entre 6 et 8 heures par mois, à recalculer avec tes propres chiffres.
Faut-il un CRM pour mettre en place ces automatisations ?+
Non. Un Google Sheet bien structuré tient le rôle de registre des factures, des prospects et des heures pour un freelance qui démarre. Le jour où le volume le justifie, chaque scénario se rebranche sur un vrai CRM en remplaçant les modules Sheets, y compris un CRM sans intégration native via son API.
Sujets :makefreelancefacturationrelancescal.comtallytoggl