Google répartit la préparation des spécifications par IA entre deux rôles dans le plugin EGM

Vous passez une demi-heure à discuter d’une nouvelle fonctionnalité avec une IA. Elle pose des questions, acquiesce aux décisions et rédige une spécification détaillée. Vous lui demandez de la vérifier : tout semble convaincant. Puis, après le lancement, vous découvrez qu’un événement envoyé deux fois par le service de paiement prolonge deux fois l’abonnement. Dans la conversation, tout le monde tenait la protection contre les doublons pour acquise. Elle n’a pas été consignée dans le document.

Elephant-Goldfish Model, ou EGM, vise précisément ce problème. Ce plugin open source permet de préparer et de vérifier des documents techniques avec l’aide de l’IA. Un agent rassemble les décisions ; d’autres examinent le résultat sans disposer de l’historique des échanges. L’objectif concret est de repérer les non-dits avant la mise en œuvre, tant qu’il suffit encore de quelques lignes dans la spécification pour les corriger.

Pourquoi le relecteur doit oublier la conversation

EGM distingue deux rôles. L’« éléphant » conserve le contexte du projet et prépare le document. Les « poissons rouges » reçoivent le document et le code source associé, mais pas la conversation qui les a précédés. Le développeur choisit les remarques à retenir, résout les contradictions et valide la conception avant l’écriture du code. C’est ainsi que le processus est décrit dans le dépôt de Google.

L’absence d’historique constitue ici une condition de la revue. Si une décision n’est compréhensible que pour les participants à une longue conversation, la personne chargée de sa mise en œuvre risque de manquer d’informations. Un relecteur qui découvre le sujet doit évaluer ce qui est réellement écrit, sans pouvoir compléter mentalement le document avec les accords passés.

L’expression « contexte nul » peut toutefois être prise trop au pied de la lettre. Le relecteur reçoit bien des éléments de travail. C’est l’historique de la discussion qui est tenu à l’écart, pas l’ensemble des informations sur le système. La qualité de la spécification et le choix du code source fourni restent donc déterminants.

Un exemple avec les paiements

Imaginons qu’une équipe ajoute le traitement des notifications de paiement. La première version du document indique : recevoir l’événement, retrouver l’utilisateur, prolonger l’abonnement. Cela suffit pour une démonstration de la fonctionnalité. Pour un service en production, des questions restent ouvertes.

Que faire si le même événement arrive deux fois ? Si la base de données a enregistré la prolongation, mais que le serveur n’a pas eu le temps d’accuser réception ? Si la notification d’annulation du paiement arrive avant celle qui annonce sa réussite ? Ce sont des exemples de questions possibles lors d’une revue, et non un compte rendu des résultats d’EGM.

L’auteur du document a pu discuter des doublons dans la conversation et considérer le sujet comme réglé. Le relecteur privé de cet historique voit une lacune : la spécification ne définit aucune règle de traitement des événements répétés. L’ingénieur devra déterminer comment reconnaître les doublons, où conserver le résultat du traitement et quel comportement attendre après une panne.

Le responsable produit a lui aussi un rôle à jouer. Les remboursements, les résiliations d’abonnement et la livraison répétée d’une notification touchent aux engagements pris envers l’utilisateur. Ces décisions ne peuvent pas être entièrement laissées à l’appréciation de l’agent qui écrit le code. L’équipe doit d’abord s’accorder sur le comportement du produit, puis le documenter de façon à ce qu’une autre personne ou un autre agent puisse le vérifier.

Que tester, et avec quelles limites

Le site d’EGM décrit les étapes de discussion de l’idée, de préparation du document et de revue. Il présente également des outils pour documenter un projet existant et rechercher les écarts entre la spécification et le code. Il est raisonnable de commencer par une seule fonctionnalité comportant des décisions à débattre : paiements, droits d’accès ou tâches en arrière-plan.

Avant la revue, il est utile de consigner les contraintes et les critères d’acceptation. Ensuite, il faut examiner les remarques, corriger le document, puis seulement passer à la mise en œuvre. Pour évaluer l’intérêt de la démarche, on peut compter les lacunes confirmées qui ont été détectées avant l’écriture du code et mesurer le temps consacré à la revue. Il s’agit d’une méthode d’évaluation proposée, pas d’indicateurs publiés sur l’efficacité du plugin.

EGM ne permet pas de promettre l’élimination des erreurs d’architecture. Des agents distincts peuvent reproduire les mêmes idées fausses, et une remarque convaincante peut se révéler erronée. Les cycles supplémentaires prennent aussi du temps et consomment des tokens. Le coût de la revue doit être proportionné à celui d’une erreur éventuelle.

Le projet est distribué sous licence Apache 2.0 ; ses auteurs précisent qu’il ne s’agit pas d’un produit officiellement pris en charge par Google. La revue nécessite des contextes de sous-agents vierges, et le processus ne remplace ni les tests ni le jugement de l’ingénieur. Ces limites sont explicitement énumérées dans le README.

EGM propose une habitude utile : avant la mise en œuvre, confier la spécification à quelqu’un qui n’a pas participé à son élaboration. Si elle ne peut pas être exécutée sans explications orales, le document doit encore être retravaillé.