Une chaîne ne vaut que par son maillon le moins honnête
L'automatisation classique casse bruyamment. Un script qui ne sait pas lire un fichier lève une erreur et s'arrête. Vous le savez tout de suite.
Une chaîne contenant un modèle de langue casse poliment. Devant une entrée mal formée, elle ne s'arrête pas : elle produit quelque chose de plausible et le transmet. L'étape suivante l'accepte, puisque cela ressemble à ce qu'elle attendait. Quand quelqu'un s'en aperçoit, le mauvais résultat a déjà été classe, envoyé ou appliqué.
Toute la difficulté de conception tient à cette différence. Vous ne construisez pas une chaîne qui marche, c'est facile. Vous construisez une chaîne dont les pannes se voient.
Trois règles qui tiennent
Contraignez la forme de sortie, puis validez-la. Exigez une structure fixe et vérifiez-la avant l'étape suivante. Une étape qui renvoie de la prose libre dans un champ lu par une machine finira par renvoyer une prose non voulue.
Donnez à chaque étape le droit de refuser. Une étape obligée de toujours répondre inventera une réponse. Une étape autorisée à ne rien renvoyer, et à passer la main à un humain, fait la différence entre trois exceptions en attente et un mois de corruption silencieuse.
Journalisez 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 garder que la sortie rend la panne inexplicable, donc répétable.
Ce que l'on saute toujours
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 gênante, il faut un humain dans la chaîne, pas un meilleur prompt.