[🤖] J’ai testé le Graph Engineering avec Codex

✨ Résumé de GPT-5.6 Sol

Après l’échec chaotique d’une tâche Codex de 16 heures, j’ai remis en question le Graph Engineering, l’ai réduit à un Gate Skill minimal et l’ai testé sur un véritable contrat d’autorisation.

Hier, après une longue discussion, j’ai achevé des spécifications page par page pour une refonte complète de l’UI/UX, puis créé un Goal Codex chargé de les implémenter. Ce Goal a tourné pendant 16 heures.

Aujourd’hui, j’ai ouvert l’écran plein d’espoir. Le résultat était tout simplement catastrophique.

Deux jours plus tôt, j’avais déjà écrit qu’il fallait sortir du fantasme de la magie de l’IA en une seule tentative. Cette fois, je ne m’étais pas contenté d’une instruction d’une ligne. J’avais défini les tâches par rôle et les spécifications de chaque page, avec le calendrier, la vue en tableau, la recherche, les filtres et la récupération après erreur. Après plusieurs prototypes ratés, j’avais même créé des critères d’audit UI spécifiques.

Pourtant, après une nuit durant laquelle plusieurs workers avaient écrit du code et annoncé que tests et audits étaient passés, j’ai découvert un vieil écran d’administration dont je comprenais à peine le sens. Où étaient passés le calendrier et la vue en tableau dont j’avais tant parlé ?

Une quantité énorme de tokens avait été consommée, une quantité énorme de code modifiée et une quantité énorme de rapports PASS accumulée. Mais le résultat que je voulais réellement n’existait pas.

Je suis redevenu humble. Encore une fois.

J’ai donc décidé de tester le Graph Engineering avec Codex. Je ne voulais pas simplement apprendre le dernier terme à la mode ni commencer par installer un framework gigantesque. Je voulais le réduire à la forme la plus petite capable d’éviter l’échec que je venais de vivre.

J’avais désormais une raison de tester le Graph Engineering

J’ai demandé à l’IA d’analyser ce qui s’était passé. Les règles communes faisaient partie du problème, et l’audit UI s’était trop concentré sur des éléments faciles à mesurer, comme la taille du texte ou la hauteur des boutons. Mais le problème principal se trouvait ailleurs.

Je n’avais pas contrôlé chaque résultat intermédiaire de Codex. La session d’implémentation déclarait elle-même son travail terminé, puis d’autres sessions héritaient de ce résultat et continuaient à construire des pages et du backend. La mauvaise architecture de l’information choisie au départ s’était propagée à plusieurs écrans avant toute véritable vérification. Lorsque j’ai ouvert le produit, 16 heures de travail reposaient déjà sur cette mauvaise direction.

Je n’avais donc pas besoin d’une manière de faire travailler l’IA plus longtemps.

J’avais besoin d’une structure qui interdise de passer au travail suivant lorsqu’un résultat intermédiaire est incorrect.

En poursuivant cette discussion avec l’IA, j’ai découvert l’expression Graph Engineering. Cette approche ne confie pas tout à la longue boucle d’un seul Agent : elle relie plusieurs Agents, vérificateurs et décisions humaines sous forme de nodes et d’edges, puis définit explicitement quel résultat autorise le passage à l’étape suivante. Il s’agit moins d’une technologie entièrement nouvelle que d’un nom récent donné à des idées connues de workflow et de state machine.¹

L’important n’était pas de mémoriser un nouveau buzzword. Une session Codex peut désormais prendre en charge un travail assez conséquent ; son résultat peut donc devenir un node, avec des conditions explicites pour passer à la session suivante.

Dans mon expérience, j’ai traduit le Graph Engineering ainsi :

• node : un résultat intermédiaire que l’utilisateur peut examiner indépendamment
• edge : la condition qui renvoie vers une correction ou ouvre le travail suivant selon le verdict
• state : la trace du résultat audité, des critères utilisés et de l’action actuellement autorisée
• cycle : la boucle qui corrige uniquement le même résultat puis le vérifie à nouveau lorsqu’un défaut est trouvé

Appeler plusieurs Agents ne suffit donc pas à faire du Graph Engineering. Le cœur de mon test consistait à concevoir la topologie et les transitions d’état afin qu’un node non vérifié ne puisse pas ouvrir ses edges suivants.

Mon premier graph ne comportait qu’une session de travail et une session d’audit

Quand j’ai proposé d’appliquer le Graph Engineering à ce problème, l’IA a immédiatement commencé à agrandir la structure. Elle a séparé Coordinator, Worker et Auditor, puis ajouté la validation humaine de la direction, les versions du contrat, un durable ledger et un audit final à froid.

Pris séparément, rien de tout cela n’était faux. Mais cela m’inquiétait.

« Est-ce qu’on ne complique pas inutilement les choses ? »

Pour empêcher une tâche de 16 heures de consommer tous les tokens sans résultat, allions-nous cette fois lancer plusieurs Agents et accumuler états et rapports ? Quelle différence réelle ? Si l’application du Graph Engineering devenait elle-même un grand projet, elle risquait encore d’absorber les tokens sans produire de valeur.

Ce que j’imaginais était beaucoup plus simple.

La session de travail termine un résultat vérifiable.
→ Elle le transmet à la session d’audit et attend.
→ La session d’audit renvoie PASS ou des corrections.
→ Ce n’est qu’alors que la session de travail reprend.

J’ai demandé si ce flux pouvait devenir un Skill réutilisable. Mais l’IA continuait à parler de la structure des sessions et des limites d’une contrainte mécanique, en compliquant le sujet. J’ai même apporté la réponse d’une autre session pour reposer la question.

« En faire un Skill est vraiment inefficace ? Sérieusement ? Tu ne racontes pas simplement ce qui t’arrange ? »

J’ai aussi exigé qu’elle critique mon idée au lieu de l’approuver automatiquement. Je ne cherchais pas à entendre que j’avais raison, mais à savoir si cette méthode empêcherait réellement un nouvel échec de 16 heures ou si je fabriquais seulement un nouveau jouet séduisant.

J’ai réduit la portée de l’expérience en multipliant les objections

Après plusieurs examens critiques, j’ai admis que ma proposition simple comportait elle aussi des failles.

Si la session de travail définit également les critères d’audit, elle peut choisir des critères favorables à son propre résultat. Si la session d’audit reçoit tout le reasoning et toute l’autoévaluation du worker, elle risque de relire ses explications au lieu d’examiner indépendamment le résultat. Si le travail suivant commence pendant l’audit, le PASS gate devient inutile. Il était aussi possible de valider un ancien écran après un changement du Runtime, ou de mal se souvenir d’un PASS après une compaction de la conversation.

Inversement, je n’avais pas à accepter toutes les propositions de l’IA. J’ai abandonné l’idée de trois sessions permanentes, d’un graph runtime séparé, d’une base de données, d’un dashboard, d’un audit de chaque page et d’un nouvel audit complet à chaque changement de contrat. Avec tout cela, le système de gestion aurait dépassé le produit.

Je n’ai conservé que ces principes :

• La session principale coordonne et travaille à la fois.
• Une session d’audit séparée n’est ouverte que pour un résultat qui a réellement besoin d’un Gate.
• L’auditeur ne reçoit pas toute la conversation précédente.
• Le résultat audité est gelé et ni lui ni son travail directement suivant ne changent avant la fin de l’audit.
• Une implémentation incorrecte est distinguée d’une direction de travail incorrecte.
• Si un problème important subsiste après une correction et un nouvel audit, on arrête les patches et on rouvre le plan.
• Si le contrat change, seuls les travaux affectés sont réexaminés.
• Un PASS d’audit ne remplace ni mon approbation de la direction du produit ni l’autorisation de déployer.

Surtout, j’ai décidé de ne pas appliquer cette structure à toutes les tâches. Une faute de frappe, un bug réglé par un test décisif ou une exploration libre sans voie connue ne justifient pas une nouvelle session d’audit. Le Gate ne doit apparaître qu’à un endroit où un mauvais résultat pourrait contaminer plusieurs travaux suivants.

Je n’ai pas non plus transformé automatiquement chaque page en unité de travail. Si le véritable parcours consiste à chercher dans une liste, ouvrir un détail, agir puis revenir au même filtre, ce journey entier doit former l’unité vérifiable. À l’inverse, il n’est pas utile d’auditer séparément chaque écran qui répète simplement le même pattern.

En réduisant ainsi la structure, j’ai préservé le graph simple que je voulais tout en précisant pourquoi il fallait s’arrêter et quoi vérifier.

J’ai transformé le graph minimal en Codex Skill

J’ai finalement demandé à Codex de créer un Skill commun nommé custom-graph-engineering-gate. OpenAI fournit déjà un moyen d’enregistrer des workflows récurrents sous forme de Skills, puis de faire appeler par l’Agent principal un subagent séparé dont il récupère le résultat.²³ Aucun service supplémentaire n’était nécessaire pour organiser les échanges entre la session de travail et celle d’audit.

J’ai aussi demandé de ne pas agrandir l’implémentation. Aucun script d’exécution, aucune base de données distincte et aucun graph dashboard. Seulement le contenu du Skill et le minimum de metadata nécessaire à son affichage dans Codex.

Le Skill fait principalement trois choses.

Premièrement, il détermine si le travail est assez important pour nécessiter un Gate. Il ne s’applique que lorsqu’un résultat intermédiaire erroné pourrait endommager plusieurs résultats ultérieurs.

Deuxièmement, il fige en une phrase le résultat à auditer. Il enregistre le résultat attendu par l’utilisateur, le critère qui distingue réussite et échec, le candidate exact, le chemin normal de vérification et le travail directement ouvert par un PASS. Le nombre de fichiers modifiés ou de tests exécutés ne remplace jamais ce résultat.

Troisièmement, il limite les transitions entre travail et audit.

PASS              → n’ouvrir que le travail directement suivant
CHANGES_REQUESTED → corriger une fois le même résultat et le réauditer
REPLAN_REQUIRED   → revoir le contrat ou le découpage, pas poursuivre l’implémentation
NOT_VERIFIABLE    → ne pas valider sans preuve

La session d’audit n’hérite pas de la conversation précédente. Ma colère, les efforts de la session de travail et les parties jugées bonnes par l’implémentateur ne constituent pas des preuves. Le reviewer examine directement la demande originale et le résultat actuel.

Si le source ou le Runtime change pendant l’audit, l’ancien verdict est annulé. Si une interruption ou une compaction empêche de reconstruire quel candidate a reçu quel verdict, le Skill ne suppose pas qu’il a été accepté.

Cette structure reste très proche de mon idée initiale. Le Skill ne fait que préserver les conditions de transition faciles à oublier, pour que le principe d’« une session d’audit maintenue » puisse être rejoué avec la même topologie lors de la session suivante.

J’ai testé le graph sur un véritable contrat

Faire confiance au Skill simplement parce qu’il avait été créé aurait reproduit la même erreur. J’ai donc confié le nouveau Skill lui-même à un reviewer distinct qui n’avait pas hérité de la conversation précédente.

J’ai d’abord vérifié qu’il ne devait pas être utilisé pour une simple modification de texte. Ne pas l’utiliser quand il est inutile constituait le premier test contre le gaspillage de tokens.

J’ai ensuite choisi comme premier node réel un contrat de transition d’autorisation dont dépendraient plusieurs fonctionnalités. J’ai gelé le candidate et l’ai transmis à l’audit. Le premier verdict n’a pas été PASS, mais CHANGES_REQUESTED. Il ne définissait pas assez clairement le moment auquel l’autorisation devait être évaluée, l’origine d’une autorité déléguée et la propagation de sa révocation, ni le lien réel entre l’utilisateur, le droit et l’entreprise cible dans un même scope.

Si ce contrat avait été étendu à plusieurs fonctionnalités, il aurait fallu reconstruire plus tard toute la frontière d’autorisation. La session de travail n’a corrigé que ce périmètre, puis la même session d’audit l’a vérifié une seconde fois avant de rendre PASS. Pendant tout ce temps, l’implémentation suivante et le déploiement sont restés fermés.

Le test était modeste, mais il a produit l’effet de Graph Engineering que je recherchais. L’edge suivant est resté fermé sur un node que le worker jugeait « suffisant », et le problème a été corrigé avant de se propager. Ce n’est qu’après l’examen du candidate corrigé par le même auditeur et son verdict PASS que l’étape suivante a pu s’ouvrir.

La première expérience a réussi, mais elle n’a pas encore résolu l’échec de l’UI

Le graph a fonctionné comme prévu lors du premier test. Je ne peux pourtant pas affirmer que ce Skill aurait empêché l’échec UI de 16 heures. Auditer un contrat d’autorisation au source relativement explicite n’est pas la même chose qu’interrompre à temps une mauvaise direction visuelle. Je n’ai pas encore vérifié qu’il réduisait le temps total et les tokens lors d’un véritable grand chantier UI. La session d’audit utilise le même modèle et voit le même Working Tree, elle peut donc partager les fausses hypothèses de la session de travail. Un Skill est une instruction, pas un moteur d’enforcement.

Le prochain travail long ne devra donc pas être évalué au nombre de PASS.

• La première mauvaise direction a-t-elle été détectée avant son extension ?
• Le coût de la reprise évitée a-t-il dépassé les tokens dépensés pour l’audit ?
• Le moment où j’ai vu le premier résultat provisoire a-t-il été retardé ?
• Les sessions de travail et d’audit ont-elles partagé le même contrat erroné ?

Si l’expérience n’est pas rentable, je devrai utiliser moins de Gates, pas ajouter des règles. Si le même échec se répète, je devrai d’abord revoir ce que j’ai regroupé comme un résultat et les preuves données au reviewer, plutôt que d’ajouter une étape d’audit.

Connaître le terme Graph Engineering ne m’a pas soudainement appris à bien utiliser l’IA. Mais cette fois, je n’ai pas installé un framework géant dès que j’ai entendu un mot à la mode. Je n’ai gardé que le graph nécessaire à l’échec vécu, j’ai continué à contester les propositions excessives de l’IA et je l’ai transformé en un petit Skill que je pourrai tester lors de prochaines sessions.

Pour ne plus découvrir, seulement 16 heures plus tard, que toute la direction était fausse.

Références

1. LangChain, « 3 Years of Graph Engineering with LangGraph ». Présente le terme récent Graph Engineering et l’idée de concevoir les workflows d’Agents sous forme de graphs explicites. ↩

2. OpenAI, « Build skills ». La méthode officielle pour enregistrer des workflows réutilisables sous forme de Codex Skills. ↩

3. OpenAI, « Subagents ». Explique comment un Agent principal peut créer des subagents séparés et récupérer leurs résultats. ↩