Ce qui sépare un prototype Make d'un système en production
Le scénario marche. Monté en une après-midi, testé sur cinq enregistrements, les cinq sont passés. On a l'impression d'avoir fini, et c'est précisément là que le problème commence : un prototype prouve que le processus est possible ; un système en production prouve qu'il l'est encore le mardi à trois heures du matin, avec une donnée bizarre et l'API d'en face à terre. Entre les deux il y a du travail, et ce n'est pas du glisser-déposer de modules.
Quand une automatisation Make ne passe pas à l'échelle, ce n'est presque jamais la logique métier qui lâche. Ce sont quatre choses que le prototype n'avait pas parce qu'il n'en avait pas besoin : un plafond d'exécution qui n'apparaît qu'avec le volume, un comportement en cas d'erreur qu'il faut décider à la main, l'absence totale de versioning, et une facture qui grossit justement quand tu fais les choses bien.
| Dimension | Prototype qui marche | Système en production |
|---|---|---|
| Volume | Cinq enregistrements de test | Le pic de fin de mois, sans prévenir |
| Erreurs | Il n'y en a pas eu | On part du principe qu'il y en aura et on décide du sort de la donnée |
| Propriétaire | Celui qui l'a monté, s'il s'en souvient | Quelqu'un d'astreinte, avec alerte et procédure |
| Modifications | On édite à chaud | On versionne, on teste à part, on promeut |
| Coût | Largement dans le forfait | Projeté à douze mois avec les étapes durcies |
Aucune de ces cinq lignes n'est un défaut de Make. Make est un excellent outil pour découvrir si un processus est automatisable, et cette phase compte. L'erreur n'est pas de commencer là : c'est d'y rester et d'appeler ça de la production.
Le plafond de temps : 40 minutes et ce qui arrive quand tu le touches
Make coupe toute exécution qui dépasse son temps maximum. Sur les forfaits payants ce plafond est de 40 minutes ; sur le gratuit, 10. Quand tu le touches, pas d'avertissement poli : la corrida s'arrête sur une erreur du genre «MAXIMUM EXECUTION TIMEOUT [40 minutes] had elapsed», et ce qui était à moitié fait reste à moitié fait.
Un prototype n'y touche jamais. Il traite cinq lignes et finit en douze secondes. Le schéma qui fait tout sauter est toujours le même et toujours par surprise : un itérateur sur une liste qui grossit. Tu synchronises 200 commandes et tout va bien ; six mois plus tard elles sont 4 000 et le scénario meurt à mi-parcours, après avoir brûlé les opérations des 2 700 premières. Le processus n'a pas changé. C'est l'activité qui a changé, ce qui était l'objectif.
La bonne sortie n'est presque jamais un forfait supérieur, parce que le plafond de temps ne s'achète pas : il se contourne par la conception. Le schéma qui marche, c'est découper le travail en deux scénarios — un qui collecte et met en file, un qui vide la file par petits lots avec sa propre planification — pour qu'aucune exécution ne s'approche de la limite. C'est plus de travail que d'ajouter un module, et c'est la différence entre un flux qui encaisse la croissance et un flux qui casse pile quand les affaires marchent.
Ce que fait Make quand ça casse (et ce qu'il ne fait pas à ta place)
Make embarque un filet de sécurité que beaucoup n'activent même pas : les exécutions incomplètes. Quand un scénario explose en cours de route, au lieu de perdre la donnée la plateforme stocke la corrida inachevée pour que tu puisses la reprendre ou la réparer. Bon filet, à utiliser. Il a aussi des bords, et ces bords sont la petite ligne qui décide si ton système perd de l'information.
Ce stock n'est pas infini : il y a une limite par scénario non résolu — de l'ordre de 10 Mo — et un plafond global par équipe — de l'ordre de 500 Mo — et celles que tu résous sont supprimées automatiquement au bout de 30 jours. La partie gênante arrive quand le stock se remplit, car le comportement dépend alors d'une case cochée il y a des mois sans y réfléchir : si la perte de données est désactivée, Make désactive le scénario ; si elle est activée, Make continue de lancer les corridas et jette l'exécution incomplète qui ne rentre pas. Aucune des deux options n'est bonne. L'une arrête ton activité, l'autre la vide en silence.
| Ce qui casse | Ce que Make fait par défaut | Ce que tu dois décider |
|---|---|---|
| 429 de l'API cible (rate limit) | L'exécution meurt ; si les incomplètes sont actives, la donnée atterrit là | Combien de relances, avec quelle attente, et que faire quand elles sont épuisées |
| 503 transitoire d'en face | Pareil : ça s'arrête où c'en était | Relancer, ou envoyer l'enregistrement dans une file de revue humaine |
| Donnée inattendue (champ vide, format bizarre) | Rien de spécial : le module qui la touche casse | Valider en entrée et router le cas bizarre vers une personne |
| Stock d'incomplètes plein | Désactive le scénario, ou jette l'exécution, selon une case | Lequel des deux maux tu préfères — et comment tu l'apprends |
Il y a une seconde erreur classique, et elle est auto-infligée : la relance sans plafond. Un gestionnaire d'erreurs qui relance indéfiniment contre une API qui renvoie des 429 ne répare rien ; il brûle des opérations à vitesse d'incendie et bloque le scénario. Toute relance a besoin de trois choses — un nombre maximum, une attente croissante entre les tentatives, et une destination finale pour l'enregistrement une fois épuisées — et cette destination finale, c'est en général une personne. Concevoir cette sortie sans en faire un goulot d'étranglement, c'est exactement le problème de l'humain dans la boucle.
Versioning : le scénario que personne ne sait qui a touché
Make n'embarque pas de contrôle de version à la manière d'un dépôt de code. La pratique répandue, et celle que presque tout le monde recommande, c'est de cloner le scénario avant d'y toucher et de tester sur des données de dev. Ça marche tant que tu es seul. Dès que vous êtes trois, le dossier se remplit de copies nommées «Commandes v2 FINAL (la bonne)» et personne ne sait laquelle tourne.
Le vrai coût du non-versioning, ce n'est pas le désordre, c'est que tu perds la capacité de répondre à trois questions le jour où ça casse : qu'est-ce qui a changé, qui l'a changé, et comment on revient en arrière. Sans ces trois réponses, chaque incident devient de l'archéologie. Et l'archéologie, en production, se paie en heures de gens chers pendant que le processus est à l'arrêt.
- Un blueprint exporté à chaque changement. Make permet d'exporter le scénario en JSON : mets-le dans le dépôt de l'entreprise. Voilà le diff que la plateforme ne te donne pas.
- Une nomenclature ennuyeuse et stricte. Un nom par scénario, un suffixe pour la copie de travail, zéro adjectif. «FINAL» n'est pas un état.
- Un vrai environnement de test, avec ses propres identifiants et des données bidon. Tester en production sur un enregistrement réel, c'est exactement ce que ça a l'air d'être.
- Une personne qui promeut. N'importe qui propose un changement ; une seule le passe en production. Ce n'est pas de la bureaucratie, c'est savoir qui appeler à trois heures du matin.
- Un journal de deux lignes. Date, ce qui a été touché, pourquoi. Personne ne le lit jusqu'au jour où on en a besoin, et ce jour-là il paie tous les autres.
Ce n'est pas une lubie d'ingénieur : c'est la part minimale de gouvernance et de contrôle de l'automatisation sans laquelle on ne peut pas dire qu'un processus est en production. Un flux qui déplace de l'argent ou des données clients et que n'importe qui peut éditer à chaud sans laisser de trace n'est pas un système : c'est un risque avec une jolie interface.
La facture monte pile quand tu fais bien
Voilà le piège qui pousse discrètement beaucoup de gens à laisser le scénario fragile exprès. Make facture à l'opération : chaque module qui traite de la donnée passe en caisse. Et tout ce qu'on vient de décrire — valider l'entrée, gérer les erreurs, relancer avec attente, journaliser, alerter un humain quand le cas est ambigu — ce sont des modules. Durcir le flux multiplie la consommation du même processus sans automatiser un seul cas nouveau.
Résultat : une incitation perverse parfaitement mesurable, la plateforme te facture plus parce que tu as rendu le système plus solide. Ce n'est pas de la méchanceté de Make, c'est la conséquence arithmétique de facturer au pas, et ça arrive à tout outil sur ce modèle. La comparaison complète des trois unités de facturation — pas, opération et exécution — est dans le prix des outils d'automatisation, et c'est la lecture qui transforme ce guide en décision chiffrée.
Conséquence pratique : quand tu projettes le coût du passage en production, ne projette pas le scénario d'aujourd'hui. Projette le scénario durci, qui aura trois fois plus de modules, au volume attendu dans douze mois. Si le calcul est mauvais, le problème n'est plus de configuration ; il est d'outil, et c'est la conversation Make face à n8n.
Trois sorties : durcir, découper ou déplacer le moteur
Tous les scénarios coincés n'ont pas besoin de la même chose, et se tromper de diagnostic coûte cher dans les deux sens : migrer par goût coûte des semaines, rester par inertie coûte des pannes. Voici les trois sorties réelles et le signal qui les distingue.
| Ta situation | Quoi faire | Signe que c'est ton cas |
|---|---|---|
| Le scénario est correct mais fragile | Le durcir sur place : validation, gestion d'erreurs, alertes, logs | Il casse rarement, mais quand il casse personne ne le sait avant qu'un client demande |
| Le scénario étouffe sous la taille | Le découper : un qui met en file, un qui vide par lots | Tu touches le plafond de temps, ou l'itérateur grossit chaque mois |
| Le modèle de prix te punit | Déplacer le moteur vers un outil qui facture à l'exécution | La facture monte et tu n'as ajouté aucun processus |
Les trois exigent la même décision préalable, et elle est organisationnelle, pas technique : quelqu'un doit être propriétaire du flux. Un processus automatisé sans propriétaire se dégrade tout seul, parce que les API changent, les formats bougent et les cas bizarres augmentent avec le volume. Cette discipline — qui regarde quoi, à quelle fréquence, avec quelles alertes — c'est ce que décrit la maintenance des automatisations, et c'est la différence entre un système qui vieillit bien et un système qui a simplement cessé de tourner un jour sans que personne ne le remarque.