Le risque le plus dangereux dans les workflows basés sur l’IA n’est pas un plantage direct avec une erreur.

C’est quand le modèle principal tombe en panne, et que le plan de secours ne réussit pas non plus,
mais que le système continue quand même à produire un bout de résultat qui a l’air complet, donnant l’impression que tout est terminé.
J’ai vécu ça une fois : pendant le traitement quotidien de l’information, le modèle principal a été coupé au bout de 60 secondes, le modèle de secours n’a pas non plus abouti, et pourtant j’ai finalement obtenu un extrait de texte qui ressemblait à s’y méprendre à quelque chose de correct. Le problème n’est pas « changer de voie et réessayer », mais que, une fois la voie changée, personne n’explique clairement ce qui s’est passé.
Par la suite, j’ai ajouté trois types d’accusés de réception à chaque fin, et il ne suffit pas qu’il manque un seul élément pour pouvoir le marquer comme « terminé » :
1. Le résultat effectivement utilisé : ____ (quel modèle / quel service)
2. Le résultat de chaque tentative : ____ (succès / dépassement de délai / erreur)
3. L’état actuel de la sortie : ____ (génération normale / dégradation explicite / échec)
On peut changer de voie, mais il faut l’écrire dans le résultat et pouvoir le recontrôler. Une « complétion » silencieuse est plus dangereuse qu’un rapport d’erreur.