Automatisation de flux par l'IA : concevez la chaîne par sa manière de casser

L'automatisation classique possède une propriété que l'on apprécie rarement avant de l'avoir perdue : elle s'arrête quand elle ne comprend plus. Un analyseur devant un format imprévu lève une exception. Une étape qui ne trouve pas un champ interrompt l'exécution. Quelqu'un reçoit une alerte, le traitement reste en échec, et les dégâts sont bornés par le fait que rien n'a continué.

Placez un modèle de langue au milieu de cette chaîne et vous perdez entièrement cette propriété. Devant une entrée qu'il ne sait pas traiter, le modèle ne s'arrête pas. Il produit quelque chose de convenable à partir de ce qu'il en tire, et le passe à l'étape suivante. Celle-ci l'accepte, puisque la forme est celle attendue. Rien, nulle part, ne signale un problème.

Quand quelqu'un s'en aperçoit, le mauvais résultat a déjà été classe, envoyé ou appliqué, et il reste tout un historique à reprendre.

Cette différence constitue tout le problème de conception. Construire une chaîne qui marche quand tout est bien forme est simple. Construire une chaîne dont les pannes se voient, c'est le vrai travail d'ingénierie.

Règle un : contraindre la forme de sortie, puis la valider

Exigez une structure fixe, et vérifiez cette structure avant que l'étape suivante ne s'exécute.

Cela ressemble à une question de mise en forme, ce n'en est pas une. Une étape qui émet de la prose libre dans un champ qu'une autre lit comme une valeur finira par émettre une prose non voulue, et l'étape réceptrice en fera quelque chose. Un contrôle de schéma à la frontière transforme cette corruption silencieuse en panne explicite, au moment où elle se produit.

Validez le type, la présence des champs obligatoires, et quand c'est possible la vraisemblance des valeurs. Une date très lointaine, un montant du mauvais ordre de grandeur, une chaîne vide là où un nom était requis : ces contrôles coûtent peu et attrapent une part surprenante des vrais problèmes.

Règle deux : autoriser chaque étape à refuser

Une étape obligée de toujours produire une réponse en produira toujours une, y compris quand elle n'a rien.

Aménagez donc une sortie explicite. Permettez à une étape de renvoyer une valeur signifiant je ne sais pas traiter celui-ci, et dirigez ces cas vers une file humaine. C'est le changement au meilleur rapport valeur sur effort dans la plupart des chaînes, car il transforme une catégorie d'erreurs invisibles en une petite liste visible que quelqu'un traite.

Concrètement, cela suppose que le prompt autorise le refus, que le schéma prévoie un emplacement pour lui, et que la logique en aval le traite comme un résultat normal et non comme une exception. S'il manque l'un des trois, le chemin de refus n'existe pas et l'étape inventera.

Règle trois : journaliser l'entrée à côté de la sortie

Quand un mauvais résultat remonte des semaines plus tard, le seul moyen de comprendre est de voir ce qui est entre.

Ne conserver que les sorties rend les pannes inexplicables, et une panne inexplicable se répète, faute de pouvoir identifier la classe d'entrées qui l'a causée. Conservez les deux, assez longtemps pour que cela serve, et rendez-les cherchables par l'identifiant qu'un humain aura réellement sous la main quand la réclamation arrivera.

C'est aussi ainsi que l'on découvre si sa chaîne se trompe discrètement depuis un moment, question à laquelle il vaut mieux pouvoir répondre.

Ou placer l'humain

Le bon placement n'est pas une validation générale en fin de chaîne, qui devient un tampon automatique en deux semaines. Personne ne tient son attention sur un flux d'éléments presque toujours corrects.

Les bons placements sont étroits. Sur la file de refus, où la personne ne voit que les cas signalés par la chaîne. Au point où la sortie devient irréversible pour la première fois, avant un envoi externe ou une écriture dans un système de référence. Et sur une relecture par échantillon, ou une petite part tirée au hasard des exécutions réussies est examinée sérieusement, précisément parce que rien d'autre ne les contrôle.

La question à trancher avant de construire

Décidez de ce qui se passe si la chaîne se trompe et que personne ne le remarque pendant une semaine.

Si la réponse est que quelques brouillons seront à refaire, construisez-la. Si la réponse implique de l'argent déplacé, un client à qui l'on a dit quelque chose de faux, ou un enregistrement dont d'autres travaux dépendent désormais, alors il faut une personne dans la chaîne, pas un meilleur prompt. Aucune ingénierie de prompt ne transforme une panne non bornée en panne bornée, et traiter le sujet comme un problème de formulation est précisément la façon dont les pannes bornées cessent de l'être.

Les chaînes qui survivent au contact des entrées réelles sont celles conçues par quelqu'un qui a supposé, dès le départ, qu'une étape se tromperait en silence. Cette supposition est juste, et construire dessus coûte bien moins cher que de le découvrir ensuite.