Les agents IA persistants en pratique : coûts, dérive mémoire et le problème des 80 %.

Pendant environ deux ans, la manière standard d’utiliser un modèle était de mener une conversation. On tape un message, on lit la réponse, puis on l’utilise ou on la remet en question. On est dans un cycle continu et on vérifie chaque sortie avant qu’elle ne soit utilisée. Puis les recommandations ont changé : il fallait cesser de taper des instructions, et plutôt utiliser des agents capables de travailler seuls, dotés de mémoire, d’outils et autorisés à terminer des tâches sans être surveillés à chaque étape. Essayez cela pendant une semaine, avec des agents qui lisent du code, exécutent des commandes et ouvrent des demandes de fusion, et cette approche fonctionne parfois. Mais elle ne fonctionne pas toujours. Les échecs apparaissent dans un ordre assez prévisible.

Pourquoi les gens ont abandonné les instructions

Le passage à une approche sans prompts reflète une véritable limite. Un prompt correspond à une question et à une réponse, ce qui convient bien pour des recherches. Il est peu adapté aux tâches où le modèle doit collecter des informations en plusieurs endroits, raisonner sur ce qu’il sait, utiliser un outil et réviser ses actions en fonction des résultats obtenus. Demander tout cela d’un seul coup n’est pas la manière dont se déroulent les vraies tâches professionnelles.

Ce qui est nécessaire, c’est un cycle : réfléchir, agir, observer le résultat, réfléchir à nouveau. En ajoutant une mémoire qui persiste entre les sessions, on obtient ce que l’on appelle un agent persistant. Une distinction importante mérite d’être clarifiée dès le début : une transcription de conversation n’est pas la mémoire de l’agent. La mémoire ressemble plutôt à un fichier que l’agent peut lire et écrire pour mémoriser des informations. Cette différence sera abordée plus loin.

Ainsi, cette décision est logique, et personne ne devrait prétendre le contraire. Ce qui compte, c’est ce qui se passe une fois que vous l’avez mise en œuvre, en commençant par le coût et en terminant par la personne encore responsable du résultat.

La facture

La première chose que personne ne mentionne : chaque appel API commence à zéro. Le fournisseur ne conserve aucune mémoire des appels précédents, ce qui oblige le programme à réenvoyer toute la conversation chaque fois qu’il demande quelque chose. La première étape est peu coûteuse. Mais à la vingtième étape, avec les résultats des outils et tous les détails supplémentaires, chaque appel peut contenir des milliers de mots, et vous devez payer pour tous ces éléments à chaque appel.

Les calculs deviennent préoccupants. Une étude menée sur trente équipes d’ingénierie a révélé qu’un retard dans une étape de tâche coûtait environ quinze cents. Cela semble anodin tant que l’on ne le multiplie pas par cinquante étapes par tâche, des dizaines de tâches par développeur par jour et toute une équipe. Le résultat s’élève à six chiffres par mois, et les agents consomment bien plus de tokens qu’un simple chat pour accomplir la même tâche.

Le coût incontrôlable représente un autre risque. Une boucle qui continue de réessayer quelque chose qui ne peut pas fonctionner entraîne des facturations continues. Il circule une histoire au sujet d’une entreprise qui a reçu une facture de cinquante millions de dollars à cause précisément de ce phénomène. Que ce montant soit exact ou non, il est tout à fait plausible qu’un agent mal configuré consomme l’intégralité de son budget journalier pour une tâche manuelle d’une durée de dix minutes. Ce qui est inquiétant, c’est que tout semble normal pendant que cela se produit : l’agent travaille, mais il tourne en rond sans avancer.

La solution qui s’est avérée efficace en pratique se compose de trois éléments :

• Un budget quotidien strict pour chaque agent, appliqué en dehors même de l’agent lui-même
• Une fenêtre de contexte dynamique, afin que les étapes antérieures disparaissent et ne s’accumulent pas
• L’envoi des tâches routinières à un modèle peu coûteux, et le transfert uniquement des cas difficiles vers un modèle plus puissant

Les équipes ayant mis en place ce type d’outils simples ont constaté que les coûts liés aux agents avaient chuté de plus de 50 % en l’espace d’un mois. Un modèle plus performant n’a jamais été la solution ; c’est plutôt une contrainte stricte qui a joué ce rôle, et il est utile d’être franc à ce sujet, car la première réaction face à une facture élevée est de chercher un meilleur modèle.

La première demande de fusion est une ruse

La première demande de fusion d’un agent peut sembler impressionnante : une fonctionnalité complète apparaît en quelques minutes et tous les tests réussissent, ce qui provoque naturellement un sentiment de soulagement. Puis vient le soupçon que le vrai travail n’a pas encore été accompli, et ce soupçon est généralement justifié.

Les équipes continuent de signaler le même schéma : la première proposition de modification est impressionnante, mais à la cinquième, quelque chose se dérègle en production sans que aucun test ne l’ait détecté. Une tentative de correction a manqué. Un cas où la valeur est nulle n’a pas été géré. Une vérification d’authentification couvrait trois points d’accès tout en ignorant le quatrième. Le code fonctionnait, mais il ne résistait pas au contact avec la réalité.

C’est ce qu’on appelle souvent le problème des 80 %. L’outil fournit les 80 % évidents, mais manque systématiquement des 20 % correspondant aux exigences non fonctionnelles, aux modes de défaillance et à la cohérence architecturale, car ces 20 % nécessitent un contexte que l’outil ne possède pas. Il génère du code qui s’exécute, mais pas du code qui dure.

Voici une version en une ligne de ce piège : le code se compile, passe les vérifications de syntaxe, mais fait quand même la mauvaise chose, car l’attention portée à son fonctionnement a diminué. Le résultat semble complet, donc on le parcourt rapidement, comme on jette un coup d’œil au travail terminé par un junior.

Réparer cela plus tard coûte plus cher que de le faire correctement dès le début. Ces problèmes se répètent dans l’ensemble du code, il n’y a donc pas d’endroit unique pour les corriger.

La mémoire existe en deux formes

Le plus grand problème était la mémoire, sous deux formes qui n’étaient pas évidentes au début.

La première consiste à oublier au cours d’une tâche. Lorsqu’une opération prend beaucoup de temps, l’agent oublie les décisions qu’il a prises au début. La solution habituelle dans ce domaine est de lui fournir plus de contexte, un million ou deux millions de tokens, en pensant que voir tout cela mène à de bonnes décisions. Cela ne fonctionne pas. Un agent confronté à une grande quantité de code complexe se retrouve perdu. Il peut résoudre un problème mais en créer un plus grave, car il voit de nombreuses petites parties sans comprendre le tout.

La deuxième forme est plus insidieuse, et c’est elle qui cause des dommages réels : le décalage contextuel. L’agent suit les fichiers de configuration et de spécifications. La base de code évolue tandis que ces fichiers restent figés. Bientôt, un travailleur en permanence écrit du code selon des normes obsolètes depuis des mois, sans que rien ne paraisse anormal, car il obéit fidèlement à des instructions issues d’une copie périmée de la vérité. Si l’on multiplie ce phénomène par plusieurs agents et répertoires, l’écart s’agrandit chaque jour sans un bruit.

C’est là que la responsabilité se déplace du modèle. Ce n’était pas le modèle qui était défectueux, mais plutôt la mémoire du projet, cette partie stockée sur disque et qui survit à toute session, qui n’avait pas été mise en place.

Le rôle du développeur a changé

Le développeur n’a pas diminué en nombre. Son rôle s’est simplement déplacé, et les conséquences ne sont pas aussi dramatiques que ce à quoi on pouvait s’attendre, ni que les excès d’enthousiasme ni les réactions négatives.

La création de prompts devient beaucoup moins importante une fois qu’un agent fonctionne pendant une longue période. Ce qui compte, c’est le contexte : ce que l’agent peut voir, ce qu’il peut se rappeler, ce qu’il est autorisé à faire, ainsi que la manière de savoir ce qu’il a fait. Les équipes qui ont obtenu des résultats n’avaient pas de prompts ingénieux. Elles ont rédigé des spécifications, les ont mises à jour, les ont fournies à l’agent en tant que mémoire, et ont elles-mêmes examiné l’architecture.

Un travail basé sur des spécifications rend le développeur plus important et déplace l’effort vers la définition de ce que l’agent doit faire, l’approbation des limites de son action et l’examen de l’architecture qu’il propose. Lorsque les exigences changent, ce sont les spécifications qui changent, pas les prompts. L’agent rédige, met en œuvre et teste en fonction de ces spécifications, sans avoir de contrôle sur la direction. Ce partage des responsabilités était le seul moyen d’éviter que les choses ne tombent en panne.

Derrière tout cela se cache une pointe de critique mesurée. Une étude a chronométré des développeurs travaillant sur des bases de code réelles et a constaté qu’ils étaient environ 19 % plus lents, bien qu’ils se sentent à peu près 20 % plus rapides. Se sentir rapide et être réellement rapide étaient deux choses distinctes. Les agents persistants élargissent cet écart lorsqu’ils en ont l’occasion, car ils excellent à créer l’illusion de vitesse. Ce qui le réduit est ennuyeux mais nécessaire : une gouvernance stricte, des revues, des spécifications correspondant à la réalité et une limite aux dépenses.

Revenir à des instructions simples n’est pas la solution, car le cycle est plus puissant. Mais l’agent n’est pas un collègue. C’est un prestataire rapide et confiant qui n’a jamais admis être incertain. On garde un tel prestataire parce qu’il est utile, et on lit tout ce qu’il nous remet, à chaque fois.