Pourquoi un agent IA fiable a besoin de règles, pas seulement d'un bon prompt

Rétrospective · semaine du 31 août 2026

« Ne crée jamais deux fois le même devis. » Cette instruction paraît raisonnable dans le prompt d'un agent. Mais que se passe-t-il si le devis est créé, puis si la connexion coupe avant que l'agent reçoive la confirmation ? Au redémarrage, une consigne rédigée en français ne suffit pas à établir ce qui s'est réellement passé.

Dans son guide du 31 août 2026, n8n distingue le modèle de la logique qui organise son exécution dans la durée. Cette distinction invite à examiner les mécanismes autour de l'agent, pas seulement la qualité de ses instructions. Source : n8n, Long-running agents beyond prompt engineering.

Séparer compréhension et exécution

Un modèle peut interpréter une demande, proposer une catégorie ou préparer un texte. Le workflow doit ensuite déterminer quelles opérations sont permises, avec quelles informations et sous quelles conditions. L'intérêt de cette séparation est de rendre les décisions importantes inspectables sans devoir relire toute une conversation.

Dans un processus commercial, « préparer un devis » et « envoyer le devis » sont deux étapes différentes. Elles doivent rester distinctes même lorsque la conversation les évoque dans une seule phrase. Un statut de validation explicite donne à l'équipe un point de contrôle que le texte seul ne fournit pas.

Deux mémoires, deux fonctions

L'historique conversationnel aide à comprendre ce que le demandeur souhaite. Le registre d'opérations sert à savoir ce que le système a effectivement tenté et confirmé. Mélanger les deux revient à utiliser un compte rendu de discussion comme preuve d'exécution.

Pour chaque opération importante, prévoyez une référence de demande, une référence d'action, un état et, lorsque disponible, l'identifiant retourné par l'application cible. Distinguez « à réaliser », « confirmé » et « résultat incertain ». Ce dernier état est essentiel : une absence de confirmation n'est pas toujours la preuve d'un échec.

Exemple illustratif : une interruption après création

Imaginons un workflow de démonstration qui crée un brouillon de devis dans un outil de test. La connexion est interrompue juste après la création. À la reprise, le processus commence par vérifier si le brouillon correspondant existe, au lieu de relancer immédiatement la création.

Si l'application permet une protection contre les doublons à partir d'une référence unique, cette protection peut compléter le contrôle. Sinon, une vérification adaptée et une intervention humaine peuvent être nécessaires. Il ne faut pas promettre la même garantie pour tous les logiciels : les possibilités dépendent du système cible et du scénario de panne.

Tester la panne, pas seulement le parcours réussi

Une recette utile inclut plusieurs interruptions contrôlées : avant l'action, pendant l'attente de confirmation et après une confirmation enregistrée. Pour chaque cas, écrivez le résultat attendu. Le bon résultat peut être une reprise automatique, mais aussi un arrêt accompagné d'une alerte claire.

Vérifiez notamment qu'une relance ne produit pas un second document et qu'elle n'envoie pas de nouvelle notification si la première est déjà confirmée. Testez aussi la reprise par une autre personne : peut-elle comprendre l'état du dossier sans connaître l'historique du développement ?

Donner à l'équipe un moyen d'agir

La supervision doit montrer les demandes bloquées, les résultats incertains et la prochaine action possible. Une alerte « erreur technique » est moins utile qu'une indication précise : création non confirmée, vérifier la référence avant de relancer. Prévoyez également comment suspendre les nouvelles opérations pendant une investigation.

Le livrable à demander est un scénario de panne documenté, avec le résultat du test et ses limites. C'est une preuve de fonctionnement plus concrète qu'une démonstration sans incident. Avec l'offre automatisation de SWM, cette réflexion peut être intégrée au cadrage du workflow. Regardons comment vos workflows reprennent après une erreur, sans répéter les actions déjà réalisées.