Quatre agents en production. Voici ce qui a vraiment cassé.
Nous faisons tourner nos propres agents IA en production. Pas une démo, pas un POC qu'on rallume avant les rendez-vous : quatre agents qui travaillent tous les matins. Une veille sectorielle à 8h, une analyse marché à 9h, un radar de delivery produit à 9h30, un rappel de tâches à midi. Ils tournent sur une plateforme d'orchestration open source récente, la même catégorie d'outils qu'on installerait chez vous.
Ce document raconte ce qui a cassé cette semaine. Pas ce qui pourrait casser en théorie : ce qui a cassé chez nous, comment on l'a découvert, et ce qu'on a changé. Nous publions ça parce que personne ne le fait, or c'est dans les pannes qu'on apprend à construire des systèmes qui tiennent.
Histoire n°1 : L'agent qui n'a jamais travaillé
Notre agent de midi avait un travail simple : lire notre tableau de tâches et envoyer un rappel de ce qui attend. Statut affiché : scheduled, tous les jours, depuis des jours. Tout avait l'air normal.
Il n'avait jamais réussi une seule fois.
La consigne lui demandait d'exécuter une commande qui n'existait pas dans son environnement. Chaque midi, il essayait, échouait proprement, s'excusait poliment dans un message… et recommençait le lendemain. Aucune alerte, aucun crash, aucun voyant rouge. Un agent qui échoue poliment ressemble exactement à un agent qui travaille.
Ce qu'on en retient
Le statut d'un agent ne dit rien de son travail. La seule vérification qui compte, c'est la première exécution réelle, suivie de bout en bout : la commande lancée, la sortie obtenue, le message arrivé. Chez un client, cette vérification fait partie de la mise en service, pas des « améliorations futures ».
Histoire n°2 : Le matin où tout est arrivé deux heures trop tôt
Un matin, la veille de 8h est arrivée à 6h04. L'analyse marché de 9h, à 7h. Le radar de 9h30, à 7h30. Aucune erreur nulle part : chaque agent a fait exactement son travail, proprement, au mauvais moment.
La cause : une mise à jour silencieuse de la plateforme, déployée pendant la nuit, avait changé la façon d'interpréter les horaires. Ce qui était lu en temps universel était désormais lu en heure locale. Le contournement qu'on avait mis en place pour l'ancien comportement s'est mis à corriger un problème qui n'existait plus, dans le mauvais sens.
Ce qu'on en retient
Une plateforme d'agents se met à jour sans vous demander votre avis, et ce qui marchait hier peut dériver sans produire un seul message d'erreur. Un système d'agents en production a besoin d'un contrôle indépendant qui compare l'attendu au constaté, pas de la confiance.
Histoire n°3 : Le registre qui mentait
Une fois le décalage compris, on corrige les horaires dans l'interface. La base de données est à jour, l'écran affiche les bonnes heures, l'API confirme. Et à l'heure dite… rien.
Il a fallu creuser pour comprendre : le planificateur ne recharge sa configuration qu'au redémarrage. Toutes nos corrections existaient dans le registre, aucune n'existait dans le système vivant. Cerise : le bouton « exécuter maintenant » de l'interface armait un tir que rien, nulle part, n'exécutait jamais.
Ce qu'on en retient
C'est notre conviction centrale, et elle dépasse les agents : le registre ne dit pas la vérité du terrain. C'est vrai d'un board de tickets qui affiche « en cours » sur un travail terminé depuis quatre jours. C'est vrai d'une interface d'administration qui affiche une configuration que le système n'applique pas. La seule vérité, c'est ce qui s'est réellement exécuté, à condition de le journaliser.
Ce qu'on a changé chez nous, le jour même
Un journal de tout, en append-only. Chaque exécution écrit ce qu'elle a vérifié et ce qu'elle a signalé. Notre radar de delivery effectue 370 contrôles chaque matin : le chiffre n'est pas du marketing, c'est un comptage, vérifiable ligne à ligne dans le journal.
Une mesure d'effet, pas une auto-évaluation. Trois jours après chaque signal émis, une seule question : est-ce que quelque chose a bougé ? C'est un fait constaté dans les données, jamais l'avis du modèle sur lui-même. Les signaux qui ne produisent rien seront coupés, par les chiffres.
Une séparation stricte des rôles. Le déterminisme détecte (tout résultat est recomptable à la main), le modèle de langage rédige et propose des rapprochements à faible enjeu, l'humain décide et envoie. Nos agents ne priorisent pas, ne diagnostiquent pas, et n'écrivent jamais à un client ou à un responsable sans une main humaine : c'est contractuel, pas philosophique.
Pourquoi on vous raconte ça
Parce que c'est notre métier : monter des systèmes d'agents qui tiennent en production, et savoir exactement où ils cassent, puisqu'on répare les nôtres tous les matins.
Sur les clients qui vous ont signalé un problème cette année, combien ont su qu'il était corrigé ?
Si la réponse est « aucune idée », vos outils contiennent déjà la réponse ; personne n'a le temps de la lire. C'est exactement ce qu'on outille.
Réserver un diagnostic : 30 minutes, vos chiffres →