Ce que j'ai appris en faisant tourner un système d'agents en production
J'ai 62 ans et j'écris du code depuis suffisamment longtemps pour avoir vu passer plusieurs vagues de promesses. Celle-ci est différente, mais pas pour les raisons qu'on lit partout. Je le sais parce que je ne regarde pas des démonstrations : je fais tourner un système d'agents tous les jours, sur mes propres dossiers réels — comptabilité, fiscalité, litiges, courriers, banque, sept entités. Quand il se trompe, ce n'est pas un ticket : c'est un courrier parti chez un notaire avec une date fausse.
Voici ce que ça m'a appris. Les ratés compris — surtout les ratés.
1. Le problème n'est pas l'intelligence, c'est la mémoire
Un modèle de langage répond bien à une question posée. Il ne sait rien de ce qui s'est passé la semaine dernière, ni de ce qu'il a lui-même fait il y a deux heures. Tant qu'on reste dans la conversation jetable, ça ne se voit pas. Dès qu'on lui confie un dossier qui vit sur six mois, c'est le mur.
Tout ce que j'ai construit de sérieux depuis un an tourne autour de ça : une base qui persiste, des faits sourcés, un journal machine des actions réellement exécutées. Pas « le modèle se souvient » — le modèle ne se souvient de rien. Une base se souvient, et le modèle la relit.
2. Un système qui agit doit pouvoir relire ce qu'il a fait
L'erreur la plus grave que j'ai rencontrée n'est pas une hallucination sur un chiffre. C'est un agent qui a exécuté une action, puis a affirmé ne pas l'avoir faite. En toute bonne foi : il reconstruisait son passé par déduction, au lieu de le lire.
Le correctif n'est pas dans le modèle, il est dans l'architecture : un journal des appels réellement émis, qui fait autorité sur le récit. La règle qui en découle tient en une phrase — ce que tu as fait se relit, il ne se devine pas. C'est la même discipline que les logs en production. Rien de neuf. Simplement, on l'avait oubliée en route parce que ça parlait bien.
3. Plausible n'est pas vrai, et c'est le vrai danger
Une erreur visible se corrige. Ce qui coûte cher, c'est l'explication plausible : un agent qui, face à un échec qu'il ne comprend pas, invente une cause vraisemblable — « permissions insuffisantes », « session non interactive » — au lieu de rendre le message d'erreur brut.
C'est exactement ce qu'un humain compétent fait de pire sous pression. Le correctif est le même que pour un humain : interdiction d'expliquer ce qu'on ne sait pas, obligation de rendre le brut. « Je ne sais pas pourquoi, voici l'erreur » est une réponse professionnelle. Une cause inventée n'en est pas une.
4. Le contrôleur compte plus que le producteur
La brique qui a le plus amélioré la qualité chez moi n'est pas un meilleur modèle. C'est un second agent dont le seul travail est de vérifier le premier : les citations sont-elles réelles, les dates tiennent-elles debout, l'argument survit-il à une réponse adverse triviale.
Un exemple qui m'a servi de leçon : un raisonnement juridique impeccable qui se concluait par « appelez le cabinet » — un samedi à 19 heures. Techniquement juste, concrètement absurde. La vérification factuelle ne suffit pas ; il faut aussi vérifier la plausibilité dans le monde réel. C'est un contrôle que personne ne pense à écrire avant de s'être pris la faute.
5. La verbosité est un défaut, pas une précaution
Un agent qui raconte son raisonnement, ses itérations, ses outils appelés, donne l'illusion de la transparence. En pratique il vole le temps de celui qui lit. Ce qu'on veut, c'est le résultat et ce qu'il reste à faire. Le reste sur demande.
Ce que j'en retiens
La partie « intelligence » est largement résolue et elle progresse toute seule. La partie difficile — celle où il reste tout à faire — c'est la mémoire, la traçabilité, la vérification, et l'humilité programmée. Autrement dit : du génie logiciel classique, appliqué à un composant qui ment avec aplomb quand on ne l'encadre pas.
C'est beaucoup moins spectaculaire que ce qu'on vend. C'est aussi la seule raison pour laquelle mon système sert à quelque chose.