Arrêtez de construire la plomberie de vos workflows

La plupart des équipes qui construisent une automatisation opérationnelle consacrent l’essentiel de leur effort d’ingénierie à des choses qui ne relèvent pas de leur logique métier : relancer les étapes échouées, planifier le moment où le travail s’exécute, suivre l’état d’un processus de longue durée, s’assurer qu’une action ne se déclenche pas deux fois, et se rétablir proprement lorsque quelque chose plante en cours de route. Rien de tout cela n’est la règle qui décide quoi faire. C’est la plomberie qui fait exécuter cette règle de façon fiable, et la construire à la main est l’une des façons les plus courantes de faire exploser le budget d’un projet d’automatisation.

La taxe de la plomberie

Imaginez une équipe qui automatise une règle opérationnelle simple : quand la commande d’un client reste non expédiée pendant plus de 48 heures, envoyer une alerte et ouvrir un ticket de support. La règle elle-même tient en une phrase. La construire de façon fiable nécessite un planificateur qui vérifie la condition périodiquement, un moyen de suivre quelles commandes ont déjà déclenché une alerte pour que la même commande ne se déclenche pas deux fois, un chemin de nouvelle tentative pour quand l’API de ticketing est brièvement indisponible, un mécanisme pour reprendre la vérification en cours si le processus redémarre en plein milieu, et une journalisation assez bonne pour répondre à « est-ce que cela s’est réellement déclenché pour la commande 4471 ». Cela fait cinq problèmes d’ingénierie distincts pour soutenir une phrase de logique métier, et chacun d’eux est un endroit où un bug peut se cacher.

La plupart des équipes sous-estiment cela parce que la plomberie n’apparaît pas comme une ligne budgétaire tant qu’elle ne casse pas. Elle casse silencieusement, et elle casse de trois façons précises et coûteuses.

Les trois modes d’échec qui rendent cela coûteux

L’échec partiel silencieux. Un workflow exécute l’étape un et deux, puis l’étape trois déclenche une erreur qui est journalisée mais jamais remontée là où un humain la verra. Le système croit désormais que la tâche est terminée, ou il ne revérifie jamais. Personne ne s’en aperçoit jusqu’à ce qu’un client se plaigne de quelque chose qui aurait dû être automatique des semaines plus tôt.

Les effets secondaires en double. Une nouvelle tentative se déclenche parce qu’une réponse était lente, pas parce que la première tentative a réellement échoué, et voilà que le paiement, l’email ou le ticket est créé deux fois. L’idempotence, le fait de s’assurer qu’une opération produit le même effet qu’elle s’exécute une fois ou cinq fois, ressemble à un détail mineur jusqu’à ce qu’un paiement ou une notification client se déclenche deux fois et que quelqu’un doive expliquer pourquoi.

L’état perdu au redémarrage. Un processus de longue durée est interrompu par un déploiement, un plantage ou un événement de scaling, et l’enregistrement en mémoire de l’endroit où il en était dans une séquence à plusieurs étapes disparaît. Le workflow repart soit de zéro, refaisant le travail et risquant des effets secondaires en double, soit s’arrête silencieusement, et personne ne s’en aperçoit jusqu’à ce qu’un rapport en aval semble faux.

Chacun de ces problèmes est résoluble. Aucun n’est trivial, et tous les trois reviennent dans chaque workflow qu’une équipe construit, ce qui signifie que le coût de les avoir mal résolus une fois est payé de nouveau à chaque nouvelle automatisation.

Confiez la plomberie à l’infrastructure

L’argument ici n’est pas « ne jamais écrire de code d’orchestration ». C’est que les nouvelles tentatives, la planification, le suivi d’état et l’idempotence sont des problèmes résolus, avec une infrastructure mature derrière eux, et les résoudre à nouveau par projet est un mauvais usage du temps d’ingénierie, qui devrait plutôt aller vers les règles métier réelles : ce qui compte comme une commande bloquée, quel est le bon seuil d’escalade, ce que signifie « résolu » pour cette entreprise en particulier. C’est la logique que seule votre équipe comprend, et c’est celle qui mérite qu’on protège le temps d’ingénierie pour elle.

Une équipe qui limite son code sur mesure à « ce qui doit se passer » et qui s’appuie sur l’infrastructure pour « s’assurer que cela se passe de façon fiable » livre plus vite et débogue moins, parce que les modes d’échec généraux et difficiles évoqués plus haut sont pris en charge par quelque chose d’éprouvé plutôt que par quelque chose construit une fois sous la pression d’un délai et jamais revu depuis.

Quand la construire soi-même

Ce n’est pas un argument général contre l’orchestration sur mesure. Si votre processus n’a réellement pas besoin de nouvelles tentatives, parce que chaque étape est instantanée et idempotente par nature, la plomberie n’est pas un vrai coût et la construire vous-même est parfaitement acceptable. Si vos exigences de fiabilité sont particulièrement spécifiques, comme des garanties d’ordonnancement strict entre étapes qu’un outil généraliste ne modélise pas bien, une solution construite sur mesure pour cette exigence précise peut surpasser un outil générique. Et un petit script à usage unique qui tourne une fois par jour avec un humain qui vérifie le résultat n’a pas besoin de la même rigueur qu’un processus non surveillé et exposé aux clients ; ajouter de l’infrastructure à cet endroit relève de la suringénierie, pas de la diligence.

Le jugement à porter concerne le volume et la conséquence : plus un workflow s’exécute souvent sans surveillance et plus il touche à des choses que les clients ou l’argent peuvent voir, plus la taxe de la plomberie compte, et plus l’argument pour la confier à quelque chose conçu pour gérer l’échec, plutôt qu’assemblé pour faire fonctionner une démonstration, est solide.

La logique métier est la seule partie d’un projet d’automatisation qu’un concurrent ne peut pas facilement copier. Tout le reste mérite d’être traité comme une commodité, parce que c’en est déjà une.