Bonnes pratiques : la discipline des agents fiables
Les outils et la configuration vous mènent loin ; la discipline vous mène au bout du chemin. Ces pratiques viennent de mois d'exploitation d'agents en production chez eaQbe : chacune existe parce que son absence nous a un jour coûté quelque chose. Elles sont simples à énoncer, et toutes peuvent être imposées par la configuration plutôt que laissées aux bonnes intentions.
Prémortem : contrôler avant de proposer
Un « prémortem », c'est l'habitude de vérifier avant d'affirmer. Avant que l'agent ne propose un changement ou n'énonce un fait, il doit répondre : qu'ai-je réellement lu ou mesuré qui étaye cela ? Pas de source, pas d'affirmation.
Pourquoi cela compte : les modèles de langage sont éloquents, et l'éloquence fait sonner vrai des affirmations non vérifiées. La règle du prémortem convertit « ça a l'air juste » en « je l'ai vérifié ». Dans notre configuration, c'est un hook : quand une requête touche un sujet sensible, un rappel automatique se déclenche : cite ce que tu as lu, re-mesure chaque chiffre, ne propose pas de solution avant d'avoir diagnostiqué.
Un effet concret : à la question « qu'est-ce qui ne va pas avec X ? », un agent discipliné au prémortem répond « laisse-moi d'abord lire X » : puis il le lit : au lieu de produire une supposition qui sonne plausible.
Vérifier avant « terminé »
La règle en miroir, appliquée après le travail : ne jamais revendiquer un résultat sans preuve. Le test qui est passé, la page qui répond, le chiffre qui correspond à la base de données : la preuve d'abord, l'affirmation ensuite.
Cela paraît évident et c'est constamment violé : par les humains comme par l'IA. L'astuce pratique consiste à intégrer la vérification dans la définition même de la tâche : le travail n'est pas « mettre à jour la page » mais « mettre à jour la page et me montrer qu'elle répond correctement ». Les agents suivent la définition de la tâche : alors mettez-y la vérification.
La boucle des leçons : chaque erreur n'arrive qu'une fois
Quand quelque chose tourne mal, le fichier de leçons reçoit une nouvelle entrée : ce qui s'est passé, pourquoi, et la règle qui l'empêche. Le fichier est relu à chaque session. Au fil des mois, cela se cumule en quelque chose de remarquable : un système dont le taux d'erreur diminue avec l'usage, parce que son histoire est institutionnelle, pas anecdotique.
L'habitude à construire : clore chaque incident, si petit soit-il, par la question « quelle règle l'aurait évité ? » : et l'écrire. Trente secondes d'écriture vous achètent l'immunité contre toute une catégorie d'erreurs récurrentes.
Sessions structurées : démarrer informé, finir consigné
Deux extrémités rendent fiables les collaborations au long cours :
- Démarrage de session : l'agent charge son contexte avant de travailler : règles du projet, mémoire, leçons, état courant des systèmes dont il dépend. Comme la checklist d'avant-vol d'un pilote : ennuyeuse, mécanique, et la raison pour laquelle rien n'est oublié. ( La nôtre est automatisée : une commande, et l'agent annonce « contexte chargé : N règles, M souvenirs, systèmes au vert » avant de toucher à quoi que ce soit. )
- Fin de session : les décisions et résultats importants sont sauvegardés dans la mémoire persistante, pour que la session suivante : demain ou dans trois mois : reparte de la trace écrite.
Un changement à la fois
Quand vous améliorez un système avec un agent, changez une seule chose, mesurez, puis changez la suivante. Plusieurs changements simultanés rendent les résultats impossibles à attribuer : vous n'apprenez rien, même quand les choses s'améliorent. Cette règle a des siècles dans la science expérimentale ; les agents la rendent simplement facile à enfreindre, parce que les changements sont devenus très peu coûteux à produire.
Questions fréquentes
Qu'est-ce qu'un prémortem dans le travail avec l'IA ?
La discipline de vérifier avant d'affirmer : lire le fichier réel, mesurer le chiffre réel : avant de proposer quoi que ce soit. C'est l'antidote aux sorties qui sonnent plausibles mais sont fausses.
Comment empêcher un agent IA de revendiquer un travail terminé alors qu'il ne l'est pas ?
Mettez la vérification dans la tâche : « fais X et montre la preuve que ça a marché ». Imposez-la avec des hooks quand c'est possible. La preuve avant l'affirmation, mécaniquement.
Ces pratiques exigent-elles des compétences techniques ?
Non : ce sont des habitudes de travail, écrites en langage clair dans les fichiers d'instructions de l'agent. Ce qui demande un peu de mise en place, c'est leur automatisation ( les hooks ), ce que nous couvrons en partie en formation.
Pour aller plus loin
- Dernière page : le standard eaQbe-ISO : tout ce guide, assemblé en une configuration prête à copier.