Planifier avec des agents : en finir avec le mur de Markdown

Deux façons de naviguer, deux façons de planifier

Appleton ouvre avec l'anthropologue Thomas Gladwin, qui a vécu parmi les Chuukese de Micronésie entre les années 1940 et 1960. Le navigateur européen trace une route à partir de cartes et de principes abstraits, puis compare chaque manœuvre au plan établi. Le navigateur chuukese, lui, part avec un objectif — atteindre une île — et improvise en lisant le vent, les vagues, les courants, le soleil et les oiseaux.

Lucy Suchman reprend cette anecdote dans son livre de 1987 sur la planification et la communication avec les machines. L'enjeu n'est pas de savoir quelle méthode est supérieure : c'est de constater qu'un plan établi en amont devient vite hors-sujet dès qu'on agit en situation réelle.

D'où la formule qu'Appleton met en avant : les plans sont au mieux « une ressource faible pour l'activité ad hoc ». Tout le monde agit comme les Chuukese, même ceux qui parlent comme des Européens. Ou, version Mike Tyson : tout le monde a un plan jusqu'à ce qu'il reçoive un coup de poing dans la figure — et en ingénierie, le coup vient de la complexité.

Ce qui cloche vraiment dans le mode « plan »

Le rituel actuel est décrit sans complaisance : seul dans son CLI ou son app desktop, on active un mode plan ou une skill de type /grill-me, puis on répond à une quarantaine de questions à choix multiples. Vers la huitième, la fatigue s'installe et l'on coche systématiquement l'option A, celle recommandée.

Suit un mur de Markdown, puis une question binaire : approuver ce plan, oui ou non ? Dans un CLI, impossible d'éditer directement le plan, impossible de répondre proprement aux questions ouvertes qu'il contient encore, impossible de dire « creusons ce point » ou « prototype-moi ça ». Aucune gestion du rythme. Et tout ce qu'on décide est ensuite traité par l'agent comme gravé dans le marbre.

Deuxième défaut : le processus est étrangement privé. Chacun planifie de son côté, sans voir le travail des autres, sans pouvoir commenter ni débattre. Alors que la planification est, par nature, une activité collective.

Le problème structurel reste le décalage de débit. L'humain skimme, se fatigue, rate des détails importants, et doit prendre des décisions difficiles à longueur de journée dans un médium inadapté au travail profond.

Le trou de serrure : deux mondes partiellement lisibles

Appleton revient sur l'étude devenue classique de Suchman : deux chercheurs en doctorat filmés devant un photocopieur Xerox PARC équipé d'un « système expert d'aide intelligent ». Ils échouent à faire leurs copies. Ce n'est pas seulement une histoire de mauvais design d'interface, mais d'asymétrie d'information.

La machine ne voyait que les appuis sur les boutons et l'ouverture du bac papier — ni les hésitations, ni les débats, ni les gestes, ni les attentes verbalisées. Les humains ne voyaient que des messages à l'écran, sans accès à l'état interne du programme. Chacun observait l'autre par un trou de serrure.

Le parallèle avec les agents est direct. Les humains vivent dans un monde d'incarnation, d'espace physique, de couleur, de geste, d'émotion et de culture ; les agents dans un monde de vecteurs, de poids, de récompenses et de descente de gradient. Les deux mondes sont riches, aucun n'est pleinement lisible pour l'autre — l'interprétabilité n'est pas un problème résolu.

Appleton imagine alors l'idéal : un tableau blanc, des collègues, des gestes, des silences, des prototypes qui tournent sur plusieurs laptops. Un agent ne comprendrait presque rien de cette scène. La réponse ubicomp — caméras, capteurs, micros, suivi du regard — resterait un cauchemar de volume de données et de contexte social. Sa conclusion : ce n'est peut-être pas nécessaire.

Boundary objects et interfaces épaisses

Plutôt que de fusionner les deux mondes, Appleton mobilise la notion de boundary object, illustrée par la fondation d'un muséum d'histoire naturelle : biologistes, trappeurs, financeurs et administrateurs universitaires ont collaboré via des spécimens, des étiquettes, des notes de terrain, des dessins et des cartes. Chaque objet signifiait autre chose pour chaque groupe, tout en créant une réalité partagée.

Nos boundary objects actuels avec les agents — plans, prompts, skills, fichiers AGENT.md — fonctionnent à peu près, mais sont taillés pour la manière de voir de l'agent. On sert le même Markdown aux deux parties : l'agent avale sans broncher les walls of text, les piles de tool calls et les logs de debug ; l'humain, lui, paie cher en temps et en énergie.

D'où l'idée d'interfaces « plus épaisses » : utiliser le travail quasi gratuit et illimité des agents pour construire des couches de traduction au service de l'humain. La formule clé : l'humain est la partie prioritaire, l'agent devrait fournir bien plus de labeur à son bénéfice.

Concrètement, ces objets doivent exploiter le visuel, le spatial, l'interactif et le social : graphiques pour comparer, cartes pour le mouvement, timelines pour la séquence, state machines et diagrammes d'architecture — des conventions que le software engineering connaît déjà, comme le montre un outil tel que Mindwalk qui trace les fichiers touchés par un run d'agent.

Trois démos et un prototype nommé Chopin

Premier exemple : un agent propose trois ombres pour un design system — crisp, soft ou pronounced. Décision impossible en texte, faute de voir l'état actuel du système. La bonne interface serait branchée sur l'app en direct, avec manipulation des couleurs et de l'intensité, aperçu immédiat et sauvegarde de la décision dans le plan — avec un nombre d'options bien supérieur à trois.

Deuxième exemple, plus abstrait : un bug entre un lecteur vidéo et un reducer. Là encore, le CLI est le mauvais médium ; une state machine générée à la volée permettrait d'explorer les états, de tester les transitions et de comprendre la boucle de buffering.

Troisième exemple : choisir entre options object, wrapper function ou client policy pour une logique de retry. Appleton fait construire les trois par des sous-agents sur des branches séparées, puis générer un rapport interactif. Résultat lisible : l'option A couvre les 60 call sites avec huit points nécessitant un jugement humain ; l'option B en couvre 60 mais en modifie silencieusement 16 ; l'option C ne demande que 14 changements mécaniques mais laisse 46 call sites non supportés. Verdict évident : A.

Les limites sont assumées : les agents sont encore mauvais pour produire ces explications visuelles sans un design humain en amont, et il faudrait les faire travailler en parallèle, cinq coups d'avance, pour éviter l'attente. C'est ce que teste Chopin, prototype multijoueur temps réel bâti sur un éditeur Markdown enrichi en MDX, où collègues et agents écrivent le plan ensemble et où chaque décision est horodatée.