Le problème : un handover, c'est un document mort
Depuis le printemps, je travaille avec une flotte d'agents : Kimi Code, les agents Hermes, Claude, Codex, des modèles locaux. Aucun d'eux n'a de mémoire propre d'une session à l'autre : ce qu'un agent sait de la veille, c'est ce qu'on lui remet à l'ouverture. Chaque session se terminait donc par un handover : un fichier Markdown qui résume où on en est, injecté au démarrage de la session suivante, souvent un autre modèle, pour reprendre le fil. J'avais standardisé le format, écrit un template, branché un hook. Ça marchait. Et pourtant, chaque matin, la même friction.
- Il est écrit au pire moment. En fin de session, quand l'attention de l'agent est au plus bas et ma patience aussi.
- Il est statique. Cinq minutes après sa rédaction, il est déjà en retard sur le dépôt.
- Il doit choisir entre tout dire et ne rien dire. Tout dire, c'est brûler des tokens à chaque lecture et coller dans un fichier des choses qui n'ont rien à y faire : adresses réseau, identifiants de bases, chemins de credentials. Ne rien dire, c'est un résumé inutile.
- Moi, je ne l'ouvre pas. Un Markdown dans un terminal n'est pas un endroit où l'on va vérifier quelque chose en vitesse. Ma vraie liste de choses à faire était dans ma tête. Et ce qui est dans ma tête, je l'oublie.
Le handover documentait le passé pour la machine. Personne ne pilotait le présent.
Le déclic : « pas un document statique, mais vivant »
Le 9 septembre au soir, je pilotais les agents Hermes depuis WSL pour un nouveau projet : un agent webmaster autonome pour le site cborweb.com. L'agent me proposait, comme d'habitude, un document de design en Markdown. J'ai demandé autre chose.
Je verrais bien un fichier HTML. Tu pourrais faire des liens hypertexte vers les endroits où il y a des sources, des répertoires, des bases de données. Laisse ton imagination créer un HTML, pas un document statique mais vivant. J'aimerais réinventer une autre manière d'utiliser un document de travail.
Ce que j'ai demandé à l'agent, le 9 septembre 2026
La première version est revenue sous la forme d'une « maison » à onglets : contexte, sources liées, chantiers. Bien. Mais il manquait la chose que je cherchais sans savoir la nommer. J'ai relancé : et si c'était aussi une liste à cocher, étape par étape, qui devienne un bloc-notes permanent du travail, pour ne plus rien oublier, un pense-bête accessible en quelques millisecondes ? Deuxième version : l'onglet pense-bête, avec persistance.
À ce moment-là, j'ai su que ce n'était pas un gadget. J'ai demandé de graver ce format dans le harness, dans le marbre, immuablement : plus aucun autre document que celui-là, la bible de chaque projet, et que le template de handover disparaisse au profit d'un fichier HTML interactif. La même nuit, l'agent a produit le template officiel, un générateur, la règle dans AGENTS.md, et a archivé l'ancien template Markdown. Les deux premiers commits du cockpit dans le dépôt du projet en sont l'acte de naissance.
Anatomie d'un cockpit
🏠 Le Chantier — Agent-webmaster cborweb.com
Document de travail vivant — la bible du projet (eddie-cockpit-v1)git log --oneline · Prochaine étape : découpage du chantier 1 en tâches kanban.Maquette statique du header et du bloc final d'un cockpit. Les chiffres reproduisent l'état du premier cockpit, celui du projet agent-webmaster.
Un cockpit, c'est un seul fichier, docs/cockpit.html, à la racine de chaque projet. Zéro dépendance externe, zéro build : il s'ouvre depuis un raccourci sur le bureau, dans un onglet épinglé, et il est là en quelques millisecondes. Le header vit : une horloge, une jauge de phase, un compte à rebours vers la prochaine échéance, la progression des chantiers. Dessous, cinq onglets.
- Pense-bête. Des étapes à cocher, classées en zone verte, orange ou rouge. On en ajoute une en tapant Entrée. Un bloc-notes libre se sauvegarde tout seul. Tout se souvient d'une ouverture à l'autre.
- Contexte. L'objectif, les décisions validées, l'architecture. Le seul onglet qui contient de la prose.
- Sources. Chaque source a une icône, un nom, un chemin exact avec un bouton « copier », et un lien « ouvrir » quand un navigateur peut l'ouvrir.
- Chantiers. Chacun porte un critère vérifiable et des commandes de preuve copiables. Cocher un chantier, ça se souvient aussi.
- Règles. Les non négociables du projet. Par exemple : « Preuve brute obligatoire : “ça devrait marcher” est interdit. » Ou : « Zone rouge (credentials, DNS, suppression, comptes) : jamais seul. »
Et tout en bas, le bloc que je lis en premier : les quatre lignes magiques. Statut réel. Portée réelle. Preuve. Prochaine étape. Quatre lignes, pas une de plus, qui interdisent à un agent de me raconter une histoire.
Les cinq principes derrière le format
1. Pointer, ne pas copier
C'est l'idée qui a tout déclenché. Un fichier Markdown est tenté de tout contenir. Un fichier HTML peut se contenter de savoir où c'est. Le cockpit dit : « les bases de données sont décrites là », avec un lien vers une annexe. L'inférence lit le cockpit, n'a pas toutes les informations sous les yeux, mais sait où cliquer si elle en a besoin. Trois conséquences immédiates :
- Des tokens. L'agent ne charge que ce dont il a besoin, quand il en a besoin.
- Des secrets qui restent à leur place. Le document de travail ne contient jamais un mot de passe ni une adresse interne. Il pointe vers l'annexe qui les tient, sous ses propres règles d'accès.
- De la fraîcheur. La vérité reste à la source. Le cockpit ne peut pas être en retard sur une information qu'il ne duplique pas.
Le premier document lié du système a été l'annexe des bases de données d'ExploDev. Depuis, les annexes s'enchaînent : un cockpit est la racine d'un petit graphe de documents, pas un monolithe.
2. Un pense-bête à quelques millisecondes
Ma mémoire de travail est la ressource la plus rare du système, plus rare que les tokens. Quand je jongle entre trois projets et cinq agents, le coût d'une étape oubliée se compte en jours. Le pense-bête est fait pour ça : il est toujours ouvert, il se souvient de ce que j'ai coché, et y ajouter une ligne coûte une touche. Il ne remplace pas le kanban des agents. C'est ma liste, celle que je regarde avant de leur donner un ordre.
3. La preuve, pas la promesse
Chaque chantier porte son critère de réussite et la commande qui le prouve. Pas « le déploiement est en place » : la commande curl qui renvoie les en-têtes, prête à coller. Les quatre lignes du bas appliquent la même discipline à l'ensemble du projet. Voici, mot pour mot, celles du premier cockpit à sa naissance :
Statut réel : concept validé (design v2 commité). Portée réelle : ce cockpit + le spec ; aucun ouvrier installé sur serveur-dev à ce jour. Preuve :
Bloc final du cockpit agent-webmaster, 10 septembre 2026git log --oneline. Prochaine étape : découpage du chantier 1 en tâches kanban Hermes.
« Aucun ouvrier installé à ce jour » : c'est exactement la phrase qu'un résumé enthousiaste aurait omise. Le format la rend obligatoire.
4. Un seul document, deux lecteurs
Un HTML est fait pour un humain. Comment un agent le lit-il sans avaler des kilo-octets de CSS ? Par une base documentaire dédiée aux fichiers HTML : un script d'ingestion convertit chaque page en CBOR et l'indexe, en détectant les changements par empreinte SHA-256 pour ne réingérer que ce qui a bougé. Un lecteur côté agent décode le CBOR en « texte signal », sans balisage, et compte les tokens de ce qu'il rend. Sur le premier document ingéré, ce lecteur a coûté 83 % de tokens en moins que le HTML brut.
Le point important n'est pas le chiffre. C'est qu'il n'existe plus deux documents, « celui pour moi » et « celui pour la machine », qui dérivent l'un de l'autre. Il y en a un, et chacun le lit avec ses yeux.
5. Le moteur ne se touche pas
Un cockpit est constitué de deux parties. En tête du script, un bloc de données : contexte, sources, chantiers, règles, échéance. Tout le reste est le moteur : onglets, persistance, boutons « copier », horloge. Les agents modifient le bloc de données ; ils n'ont pas à toucher au moteur. Un générateur crée le cockpit d'un nouveau projet à partir du template officiel, et refuse d'écraser un cockpit existant sans qu'on le lui demande explicitement. Le format porte un nom versionné, eddie-cockpit-v1, précisément pour pouvoir évoluer sans casser les cockpits en service.
/* ═══ DONNEES — personnaliser ici (le reste du moteur ne se touche pas) ═══ */
const COCKPIT = {
cle: 'cockpit-mon-projet', // clé de persistance locale
contexte: "Objectif, décisions validées, architecture.",
echeanceJours: 7, echeanceHeure: 9, // compte à rebours du header
sources: [
{ ic: '🗄️', nom: 'Bases de données', chemin: '~/projets/mon-projet/docs/annexe-bdd.html',
url: 'file:///home/eddie/projets/mon-projet/docs/annexe-bdd.html' },
],
chantiers: [
{ n: 'Chantier 1 — Fondations', c: 'les en-têtes de sécurité répondent en prod',
cmds: ['curl -sI https://exemple.fr | grep -i strict-transport'] },
],
regles: [
'Preuve brute obligatoire : « ça devrait marcher » est interdit.',
'Zone rouge (credentials, DNS, suppression, comptes) : jamais seul.',
],
};Ce que ça change, concrètement
Dans mon harness, la commande :handover ne produit plus un fichier. Elle met à jour le cockpit du projet : pense-bête, chantiers, quatre lignes, et un bloc de métriques de session collé en fin de course. Deux projets tournent déjà dessus : l'agent webmaster de cborweb.com, qui l'a vu naître, et un système de trading quantitatif sur le marché chinois, créé avec le générateur le lendemain.
| Handover Markdown | Cockpit vivant | |
|---|---|---|
| Quand on l'ouvre | rarement, dans un terminal | en permanence, onglet épinglé |
| Ce qu'il contient | tout, ou rien d'utile | des pointeurs et l'état courant |
| Mémoire des étapes | aucune, on relit | coches et notes persistantes |
| Preuve | des phrases | des commandes copiables |
| Secrets | tentation de coller | jamais, un lien vers l'annexe |
| Lecture par l'agent | le fichier entier | texte signal via la base CBOR |
| Évolution | réécrit à chaque session | données mises à jour, moteur intact |
Essayez : un pense-bête qui se souvient
Le principe tient en trente lignes. Cochez, rechargez la page : les coches restent. C'est tout le contrat du pense-bête, et il ne demande aucun serveur.
Persistance locale à votre navigateur (localStorage). Rien n'est envoyé nulle part.
Pour reproduire chez vous
Vous n'avez pas besoin de mon template. Vous avez besoin de cinq décisions :
- Un fichier par projet, en HTML, sans dépendance, ouvrable en double-cliquant. S'il faut un build pour le lire, il ne sera pas lu.
- Un bloc de données séparé du moteur. C'est le seul endroit que vos agents ont le droit d'éditer.
- Des liens, pas des copies. Chemins copiables, liens ouvrables, annexes pour tout ce qui est sensible ou volumineux.
- Une commande de preuve par chantier, et quatre lignes de statut honnête en bas de page.
- La persistance dans le navigateur pour les coches et les notes. C'est gratuit, immédiat, et suffisant pour une v1.
Les limites, honnêtement
C'est une version 1, et le format s'appelle ainsi pour une raison.
- Les coches vivent dans un seul navigateur. Elles ne se synchronisent pas entre deux machines, et l'agent qui lit le fichier ne les voit pas. La vérité partagée, c'est le bloc de données et les quatre lignes ; le pense-bête, c'est le mien. Une v2 devra faire remonter cet état quelque part.
- Éditer du HTML est plus risqué qu'éditer du Markdown. Une apostrophe mal placée dans le bloc de données et la page ne s'affiche plus. La séparation données / moteur et le générateur, qui se vérifie lui-même en mode test, limitent le risque ; ils ne l'annulent pas.
- C'est ma convention, pas un standard. Elle est calibrée pour ma façon de travailler : un humain, une flotte d'agents, des projets qui durent des semaines. Elle ne prétend à rien de plus.
Où je veux aller
Je crois que le document de travail est le maillon oublié du travail avec les agents. On a beaucoup investi dans les prompts, les outils, les modèles. Très peu dans l'objet que l'humain et la machine regardent ensemble. Ma vision tient en quelques lignes.
- Chaque projet a un cockpit, et le cockpit est la seule source de vérité sur l'état du projet. Pas le dernier message d'un agent, pas ma mémoire.
- Les agents le mettent à jour eux-mêmes en fin de session, avec des preuves, et un gardien refuse la mise à jour qui n'en apporte pas.
- L'état coché ne reste pas prisonnier d'un navigateur : il devient une donnée que les agents lisent, et qui pèse dans leur choix de la prochaine tâche.
- Au-dessus des cockpits, une tour de contrôle : une page qui liste tous mes projets avec leur phase, leur échéance et leur prochaine étape. Le cockpit des cockpits.
- Et, plus largement, l'idée que pour un document de travail, le HTML vivant peut devenir la norme là où le Markdown statique était le réflexe. Pas pour la documentation. Pour le travail.
En une phrase
Un document de travail doit être un tableau de bord qu'on ouvre, pas un rapport qu'on classe.
Article publié le 10 septembre 2026. Le format eddie-cockpit-v1 est en service depuis le 10 septembre 2026 sur deux projets.
Pour aller plus loin : un document unique qui pilote le projet n'a d'intérêt que si l'IA travaille vraiment avec vous. Le cours Cowork montre comment organiser cette collaboration, niveau par niveau.