Reprendre une automatisation qui casse.
Vos factures ne partent plus. Le scénario, lui, affiche toujours vert. Lilian Sevoumian reprend les automatisations Make et n8n déjà en place, y compris celles construites par quelqu'un d'autre, et remet le flux en marche.
Le symptôme arrive rarement par une alerte
Il arrive par un client qui rappelle pour une facture qu'il n'a jamais reçue. Par un chiffre d'affaires du mois qui ne tombe pas juste. Par un commercial qui redemande une information que l'outil était censé remplir tout seul. Pendant ce temps, l'automatisation tourne, et rien à l'écran ne dit qu'elle a lâché.
Chez Fraich Touch, agence de management qui représente des créateurs de contenu et des athlètes, 16 factures dormaient dans la file d'erreurs de Make, jamais envoyées aux clients. Personne ne les voyait. Un second défaut marquait des deals comme « payés » alors que seul un acompte avait été versé, à raison de 3 à 4 deals faussés par mois.
Le jour où l'équipe cesse de faire confiance au système, l'automatisation a cessé de faire son travail. Quelqu'un revérifie à la main ce que la machine était censée garantir, et vous payez les deux.
- Des factures qui ne partent plus, sans que rien ne signale l'arrêt
- Un montant encaissé qui ne correspond pas au montant facturé
- Une automatisation qui traite un email à la fois et fait attendre les suivants
- Une donnée lue de travers : une quantité prise pour un taux de TVA
- Une commande rejouée qui ressort en double
- Plus personne pour dire quelles opérations sont passées et lesquelles sont bloquées
Pourquoi une automatisation finit par casser
La panne arrive à la fin. La dérive, elle, commence le jour de la livraison. Un système automatisé vit dans un environnement qui bouge : vos process évoluent, vos outils publient de nouvelles versions, vos équipes tournent. L'automatisation, elle, reste telle qu'on l'a écrite.
Chaque écart se règle par une couche supplémentaire, et chaque couche paraît raisonnable au moment où on la pose. C'est l'accumulation qui coûte. Chez Fraich Touch, l'outil de comptabilité avait changé son API deux fois, ce qui a obligé à reconstruire le système trois fois, sans que les versions précédentes soient retirées.
Aucun de ces mécanismes ne fait de bruit. Ils se paient en heures d'équipe, en argent qui n'arrive pas, et en confiance perdue dans l'outil.
- L'empilement. On corrige en ajoutant. Le scénario d'origine reste en place, la nouvelle version se pose à côté, et personne n'ose supprimer l'ancienne.
- L'API qui bouge. Un outil change son interface, le connecteur cesse de répondre, et le flux tombe sur une erreur qu'il n'a jamais rencontrée.
- Le départ. Celui qui a construit le système s'en va, prestataire ou salarié. La logique métier vivait dans sa tête.
- L'angle mort. Les erreurs s'accumulent dans une file que personne ne regarde, parce que rien n'a été prévu pour les faire remonter.
- Le codage en dur. Une valeur écrite à la main dans chaque scénario : le jour où elle change, il faut tout rouvrir.
Chez Fraich Touch : 33 scénarios empilés et 16 factures bloquées
Fraich Touch avait déjà investi dans l'automatisation de sa facturation avec un premier prestataire. L'outil de comptabilité avait changé son API deux fois, et le système avait été reconstruit trois fois sans que les anciennes versions soient nettoyées.
L'audit du compte a couvert 33 scénarios Make, 17 connexions et 3 espaces de stockage internes. Sur ces 33 scénarios, 28 étaient des reliques inutilisées : tests, sauvegardes, versions précédentes. 16 factures attendaient dans la file d'erreurs, jamais envoyées aux clients, soit du chiffre d'affaires en suspens que personne ne voyait. Les factures elles-mêmes étaient rangées dans un espace de stockage interne accessible uniquement par API, donc invisible pour l'équipe. Et chaque pipeline annuel était codé en dur : ajouter l'année suivante obligeait à dupliquer tous les scénarios à la main.
L'audit s'est conclu par un rapport détaillé et une vidéo qui le commente. Le calcul était net : patcher l'existant serait plus long et plus coûteux que de tout reconstruire.
Le système de Fraich Touch est reparti sur 4 scénarios Make propres et documentés, qui remplacent les 33 précédents, avec le CRM comme source unique et un suivi que l'équipe consulte elle-même.
- Chez Fraich Touch, régler une erreur prend 5 min, contre 30 à 60 min avant la reprise.
- Chez Fraich Touch, ajouter un pipeline annuel prend 30 min et une ligne dans la table de configuration, contre une journée avant.
- Chez Fraich Touch, former un nouveau collaborateur prend 30 min, contre plusieurs heures avant.
- L'équipe de Fraich Touch a récupéré environ 4 h par semaine.
- Les 33 scénarios Make empilés de Fraich Touch ont été ramenés à 4, propres et documentés.
Chez Humble+ : un premier workflow trop fragile pour le volume attendu
Humble+ est une marque française de compléments alimentaires qui développe un réseau B2B auprès des pharmacies et des salles de sport. Les bons de commande arrivent en PDF côté pharmacies, en Excel côté salles de sport. Un premier workflow Make en automatisait déjà une partie. Il restait trop fragile pour absorber le volume attendu.
L'audit a porté sur le scénario Make existant, les deux formats de commande et les règles des outils de vente et de comptabilité. Les points de fragilité ont été isolés avant toute reconstruction.
Le parcours de Humble+ a ensuite été reconstruit dans n8n autour d'une règle simple : l'IA comprend le document, les règles métier garantissent le résultat. Les deux formats de bons de commande passent désormais dans un seul système, avec chacun ses règles.
Le projet de Humble+ est en phase de stabilisation. Une validation humaine dans Slack reste en place, le temps de verrouiller le comportement sur l'ensemble des formats reçus, et sera retirée progressivement.
- Le workflow ne traitait qu'un email à la fois. Il fallait attendre la fin d'une commande avant d'envoyer la suivante.
- Les deux circuits PDF et Excel partageaient la même entrée malgré des structures et des règles métier différentes.
- L'extraction confondait parfois une quantité avec un taux de TVA.
- Une commande rejouée pouvait créer un doublon si elle n'était pas détectée assez tôt.
- La création d'un nouveau client dans l'outil de vente pouvait échouer et imposer une reprise manuelle.
Comment se passe une reprise
Ça commence par un appel de 20 min. Vous décrivez le symptôme avec vos mots, tel que vous le vivez : les factures ne partent plus, les commandes s'accumulent, les chiffres ne tombent pas juste. C'est suffisant pour savoir si le sujet est de mon ressort.
Vient ensuite l'audit du compte Make ou n8n. J'ouvre ce qui existe et je cartographie ce qui tourne, ce qui dort et ce qui casse, avec les règles métier écrites noir sur blanc : TVA, frais variables, échelonnement, bons de commande. Chez Fraich Touch, cet audit a couvert 33 scénarios, 17 connexions et 3 espaces de stockage internes.
L'objectif d'une reprise est que vous puissiez vivre sans moi ensuite.
- L'audit. La liste de ce qui tourne, de ce qui ne tourne plus et de ce qui n'a jamais servi, remise sous vos yeux dans un rapport détaillé accompagné d'une vidéo explicative.
- La décision. Réparer ou reconstruire : je tranche après l'audit et je vous dis pourquoi. Chez Fraich Touch, patcher l'existant sortait plus long et plus coûteux qu'une reconstruction complète.
- La reconstruction. Moins de scénarios, une logique lisible, et une configuration lue dans une table, jamais écrite en dur dans les scénarios.
- La visibilité. Chaque erreur remonte là où votre équipe travaille déjà, avec le détail de ce qui a échoué et le lien vers la donnée concernée.
- Le transfert. Une documentation faite pour votre installation et une vidéo de formation, pour que les modifications courantes se fassent sans moi.
Ce qui empêche la dérive suivante
Une automatisation reprise puis laissée seule redérive. Ce qui tient dans le temps se pose à la reconstruction, et se résume à quelques principes simples.
Chez Fraich Touch, les identifiants de pipeline ne sont plus écrits dans les scénarios : ils sont lus dans une table de configuration Notion. Ajouter le pipeline suivant demande une ligne à remplir, sans toucher un seul scénario.
- Une alerte explicite : l'erreur remonte le jour où elle arrive, sur l'outil que votre équipe regarde déjà.
- Une configuration lue dans une table, jamais écrite en dur : ajouter une année devient une ligne à remplir.
- Un suivi que l'équipe ouvre elle-même, avec le statut de chaque opération et le détail de chaque erreur.
- Une documentation et une formation, pour que les modifications courantes se fassent sans moi.
20 min pour ouvrir le capot
Si vous lisez cette page en pensant à un système précis, c'est déjà un signe. Le premier pas prend 20 min : vous me montrez ce qui tourne, je vous dis ce que je vois, et si une reprise vaut le coup.
Vous repartez avec un avis clair, même quand la réponse est de ne rien toucher. Si je ne suis pas le bon interlocuteur, je le dis à ce moment-là.
- Vous décrivez le symptôme avec vos mots, sans préparation technique.
- Je vous dis si le sujet est de mon ressort et ce que l'audit couvrirait.
- Vous repartez avec un avis clair, même quand la réponse est de ne rien toucher.
- Réserver un diagnostic de 20 min : https://cal.com/lilian-sevoumian/20min
Ce qu’on me demande avant une reprise.
Q01 Vous reprenez une automatisation construite par quelqu'un d'autre ?
Oui. Deux des quatre cas publiés sur ce site sont des reprises. Fraich Touch avait déjà investi dans l'automatisation de sa facturation avec un premier prestataire : l'audit a porté sur 33 scénarios Make, 17 connexions et 3 espaces de stockage internes. Humble+ avait un premier workflow Make, devenu trop fragile pour absorber le volume attendu. Dans les deux cas, le travail a commencé par l'audit de ce qui existait, sans jugement sur ce qui avait été construit avant.
Q02 Vous réparez l'existant ou vous reconstruisez ?
La réponse sort de l'audit. Chez Fraich Touch, patcher les 33 scénarios en place serait devenu plus long et plus coûteux que de tout reconstruire : le système est reparti sur 4 scénarios propres et documentés. Chez Humble+, les points de fragilité ont été isolés avant toute reconstruction. Quand la base est saine, une reprise ciblée suffit, et je vous le dis avant de commencer.
Q03 La personne qui a construit notre automatisation est partie. On fait quoi ?
Ce qui part avec elle, c'est la logique métier. Je la reconstitue depuis le système lui-même et depuis vos équipes, puis je la remets à un endroit lisible : une table de configuration, une documentation, une vidéo de formation. Chez Fraich Touch, former un nouveau collaborateur prend 30 min, contre plusieurs heures avant la reprise.
Q04 Mon automatisation est sur Make. Faut-il passer sur n8n ?
L'outil se choisit après l'audit. Fraich Touch est resté sur Make, avec 4 scénarios propres et documentés à la place des 33. Humble+ est passé à n8n parce que le parcours mêlait lecture de documents par IA, contrôles déterministes et validations humaines. Le critère : ce que le flux doit faire, et qui maintiendra le système ensuite.
Q05 Comment savoir si mon automatisation est en dette ?
Trois signes suffisent. Vous découvrez les erreurs par hasard. Une modification simple se transforme en chantier. Personne ne sait dire à quoi sert la moitié des scénarios en place. Chez Fraich Touch, 28 des 33 scénarios du compte étaient des reliques inutilisées et 16 factures attendaient dans une file d'erreurs que personne ne regardait. L'appel de 20 min sert exactement à trancher.
Q06 Que se passe-t-il pendant l'appel de 20 min ?
Vous décrivez le symptôme avec vos mots : les factures ne partent plus, les commandes s'accumulent, les chiffres ne tombent pas juste. Je pose des questions sur les outils branchés, sur ce qui a été construit et sur ce que vous voyez remonter comme erreurs. À la fin, vous savez si votre sujet est de mon ressort et ce que l'audit couvrirait. Réservation sur https://cal.com/lilian-sevoumian/20min
Montrez-moi ce qui tourne encore.
Vous décrivez le symptôme avec vos mots. Je vous dis ce que je vois, et si une reprise vaut le coup.