Faire travailler plusieurs agents ensemble

Un matin d’août, le mini-PC a saturé sa mémoire et il a fallu le redémarrer en catastrophe. Cinq sessions d’agent ont passé la journée à réparer les dégâts, une par projet, plus une sixième qui ne codait rien et se contentait de relire le travail des autres. Cette session de supervision s’est trompée trois fois dans la journée, et les trois fois une session de projet l’a corrigée en lui opposant de meilleures mesures.

C’est de cette journée qu’est sortie la méthode décrite ici, et son principe tient en une phrase : plusieurs agents qui se contrôlent mutuellement valent mieux qu’un agent qui distribue les ordres.

Pourquoi un second agent voit ce que le premier rate

Un agent qui vient d’écrire du code est très mal placé pour le juger. Il connaît son intention, et relit donc ce qu’il voulait faire plutôt que ce qu’il a produit. Vous avez déjà ce réflexe de défiance face à un collègue humain, et il vaut de la même façon pour une machine.

Un agent qui n’a rien produit sur un projet arrive sans cette intention en tête. Sur cette journée d’août, le relecteur a repéré trois choses que les sessions concernées regardaient sans les voir.

Un script de sauvegarde avalait les codes d’erreur de la commande qu’il lançait, si bien que l’import de la base plantait pendant que systemd annonçait un succès. Une sonde effaçait sa propre alarme toutes les heures : elle prévenait sur Slack à 6h48, puis annonçait un rétablissement à 7h07 sans avoir rien retesté. Une campagne publicitaire, enfin, avait été réparée sans que personne songe à ajouter la moindre détection. Le correctif empêchait ce bug précis de revenir, et ne disait rien du suivant.

Aucune de ces trois trouvailles n’a demandé d’être plus malin. Il fallait seulement n’avoir pas écrit le code.

Le coût se joue sur le délai de détection

Cette journée a fait remonter quatre incidents répartis sur quatre projets sans rapport entre eux, et ils se ressemblaient tous. Un import échouait en annonçant un succès pendant qu’une sonde effaçait ses propres alertes. Ailleurs, une campagne payante dormait depuis trente-trois heures sans que personne s’en aperçoive. Une passerelle, enfin, jetait une partie de sa réponse depuis des mois. Le symptôme était décrit noir sur blanc dans un commentaire, juste au-dessus de la ligne fautive.

Une fois le problème identifié, aucun de ces correctifs n’a demandé plus de quelques minutes, ce qui veut dire que le coût réel s’est intégralement joué sur le temps qu’il a fallu pour s’en apercevoir.

La règle qui fait tout tenir : le droit de refus

Le réflexe naturel consiste à faire du relecteur un chef qui distribue les ordres. C’est le schéma le plus répandu dans les frameworks multi-agents, et il aurait tout cassé dans notre cas. Une anecdote vaudra mieux qu’une démonstration.

Le relecteur mesure la lenteur d’un service et trouve une corrélation entre le temps écoulé depuis le dernier appel et la durée de réponse. Il en conclut que le cache expire trop vite, propose d’allonger sa durée de vie et d’ajouter une nouvelle tentative automatique, puis annonce tout cela avec beaucoup d’assurance.

La session propriétaire du service ne l’applique pas et préfère mesurer d’abord. La cause était ailleurs : le modèle passait ce temps à réfléchir, et la passerelle n’envoyait rien pendant sa réflexion.

Le plus intéressant, c’est que le correctif proposé aurait fonctionné si elle avait obéi. La sonde serait repassée au vert, tout le monde aurait été satisfait, et les utilisateurs auraient continué d’attendre cinq minutes devant une page blanche. Pour une raison que plus personne n’aurait cherchée.

Isoler une variable à la fois

L’erreur du relecteur mérite qu’on s’y arrête, parce qu’elle se reproduit très facilement dès qu’on travaille dans l’urgence.

Il disposait de trois mesures, et il a fait varier le temps écoulé entre chacune en laissant toutes les autres conditions se débrouiller. Il a vu une corrélation apparaître et il en a fait une cause, ce qui est le raccourci le plus tentant de la méthode expérimentale.

La session qui l’a corrigé a procédé exactement à l’envers, en faisant varier une seule chose et en tenant tout le reste immobile. Elle a mesuré l’effet de la réflexion du modèle à état de cache identique, puis l’effet du cache à réflexion identique. Ces deux expériences ont tranché là où trois observations n’avaient produit qu’une hypothèse séduisante.

Un agent excelle à fabriquer une explication plausible à partir de trois points de mesure. Demandez-lui l’expérience capable de l’invalider.

La mise en place

Ce qu’on dit concrètement au relecteur

Une session de supervision qu’on lance sans consigne se contente de commenter. Voici le brief qui a fini par marcher, à adapter à votre situation.

Tu supervises les autres sessions de la machine. Tu ne codes sur aucun de leurs projets. Ton travail : relire ce qu’elles font, vérifier la santé de la machine à intervalles réguliers, et me remonter ce que tu vois.

Avant d’affirmer une cause, montre-moi l’expérience qui l’isole. Une corrélation sur trois points reste une hypothèse, annonce-la comme telle.

Quand tu audites une autre session, lis les commandes qu’elle a exécutées et l’état réel des fichiers, jamais les libellés qu’elle a donnés à ses actions.

Si tu touches à un fichier hors de ton périmètre, préviens la session concernée avant qu’elle ne le découvre.

Si une permission t’est refusée, tu t’arrêtes et tu me le dis. Tu n’exécutes jamais à la place d’une autre session ce qui lui a été refusé.

Les deux consignes du milieu viennent d’erreurs réelles. La supervision a conclu à une expiration de cache sur trois mesures non contrôlées, puis a signalé un force push qui n’avait jamais eu lieu, parce qu’elle avait lu l’étiquette d’une commande au lieu de la commande elle-même.

Les limites, et elles sont réelles

Personne ne surveille le surveillant, et c’est le premier problème. La session de supervision meurt comme n’importe quelle autre, et sa disparition est silencieuse par définition. Faites-la tourner dans tmux, puis adjoignez-lui une sonde qui ne dépende d’aucune session, par exemple un minuteur système qui vous envoie un message. C’est ce qui a été mis en place ce jour-là, mais après coup.

Vient ensuite la question du coût. L’argument économique du schéma classique repose sur un chef coûteux qui pilote des ouvriers bon marché, alors qu’ici personne n’occupe le rôle d’ouvrier, ce qui fait grimper l’addition et interdit d’en faire un réflexe quotidien. Pour alléger la note, le comparateur de Quelle IA met prix et scores face à face ; vérifiez dans son classement Agents que le modèle choisi tient une longue tâche en autonomie.

Le relecteur, enfin, ne connaît pas le terrain. Sur les trois sujets où il s’est trompé, la session du projet connaissait son propre code bien mieux que lui, et son intérêt vient uniquement de son absence d’implication dans le travail, jamais d’une quelconque supériorité.

Reste un point qui paraît évident écrit noir sur blanc, mais qui devient tentant dans le feu de l’action : une permission refusée à une session ne s’exécute jamais depuis une autre. Quand l’une se retrouve bloquée sur un accès que sa voisine possède, l’envie de contourner arrive très vite, et elle vide de sa substance le garde-fou que vous aviez pris la peine d’installer. Mieux vaut s’arrêter et trancher vous-même.

Rien de tout cela ne fonctionne enfin sans mesures. Les trois corrections de la journée reposaient sur des chiffres. Deux agents qui débattent d’opinions produisent surtout du bruit convaincant.