Anthropic décrit un cycle de développement entièrement réorganisé autour d’agents IA. Memex en applique déjà une bonne partie — et en refuse délibérément une autre. Voici les deux, côte à côte.
Écrire du code n’est plus ce qui ralentit une équipe. Un agent IA produit en quelques heures ce qui demandait des semaines. Ce sont donc les étapes autour du code — recueil du besoin, validation, revue, mise en production — qui deviennent le goulot d’étranglement, parce qu’elles ont été taillées pour une vitesse humaine.
L’article propose de refondre le cycle entier autour de ce constat, en gardant l’humain à chaque point où il faut trancher.
« Code is no longer the bottleneck »
« Humans remain accountable for every decision that requires judgment. »
Les deux phrases qui portent tout l’article
Le fichier n’est pas un détail de mise en œuvre : c’est le mécanisme. Chaque étape dépose dans le dépôt un document relisible, comparable d’une version à l’autre, et opposable. Les meetings deviennent des fichiers.
Celui qui a l’idée en discute avec l’IA et en sort un document d’intention structuré, au lieu d’attendre un comité. Le responsable produit valide avant qu’on aille plus loin. Des semaines d’ateliers de recueil deviennent une session de quelques heures.
Besoin et conception fusionnent en une seule session. L’IA travaille sous contrainte de règles maison fournies à l’avance — charte graphique, sécurité, conformité, expérience utilisateur — donc les objections remontent avant que l’ingénieur ne voie le document.
L’IA propose d’abord une stratégie d’implémentation, qu’un humain approuve ; le plan approuvé devient à son tour un fichier versionné. Trois leviers : un fichier de contexte à la racine du dépôt (commandes, conventions, architecture), des règles réutilisables d’une session à l’autre, et des scripts automatiques qui bloquent les actions interdites. Un ingénieur pilote plusieurs chantiers en parallèle.
L’agent vérifie son propre travail avant de solliciter un humain : tests au vert, build qui passe, comparaison visuelle. Et surtout — c’est l’idée la plus originale de l’article — on teste la configuration de l’agent elle-même. Dès qu’on modifie ses instructions ou son contexte, une batterie de cas de référence rejoue pour vérifier qu’il ne s’est pas mis à mal se comporter. Chaque incident de production vient enrichir cette batterie, définitivement.
L’IA relit la demande de fusion contre les règles maison ; l’humain se concentre sur l’intention et le risque, et répond en interpellant l’IA, qui pousse elle-même les corrections. La mise en production reste bloquée tant qu’une personne nommément désignée n’a pas autorisé. Le retour arrière est répété avant d’en avoir besoin.
Une surveillance classique — des seuils, des scripts, pas d’IA — détecte la sortie de la bande normale. C’est seulement là que l’IA est réveillée, sans interface, pour diagnostiquer et rédiger… un document d’intention.
Memex part exactement de la même phrase — le code n’est plus le goulot — et refuse ensuite la solution proposée. Sa critique tient en une ligne : un document, même bien structuré, même versionné, est une photographie. Il est juste le jour où on l’écrit, faux une semaine plus tard, et rien ne signale quelle partie a dérivé.
Un historique de décisions qui n’est relié à rien de mesurable reste de la prose. Il pourrit comme un paragraphe ; simplement, de façon plus lisible. Or les trois artefacts centraux de l’article — intent.md, spec.md, plan.md — sont trois fichiers de prose.
Le remède de Memex : au lieu d’écrire un document, il enregistre deux types d’objets.
Conséquence : le dossier ne peut pas mentir en silence. Il sait, en permanence, si le code déployé fait encore ce qui avait été décidé. Vérifier devient une requête, pas une impression.
| Dans l’article | Dans Memex | Ce qui change |
|---|---|---|
| Cadrer | Cadrer | Memex ne se contente pas d’un texte de cadrage. Il exige une liste d’engagements séparés, formulés en langage courant, un par ligne : chacun décrit un résultat auquel on s’engage, et chacun sera confronté à la réalité individuellement. Un paragraphe, on ne peut pas le cocher ; trois engagements distincts, si. |
| Concevoir | Arbitrer | Tant que les questions ouvertes ne sont pas tranchées, il est interdit de créer des tâches. Une tâche écrite avant l’arbitrage est une supposition déguisée en engagement. |
| Construire | Construire | Pratiquement identique, y compris les sessions parallèles et le contexte versionné dans le dépôt. |
| Tester | aucune | Pas d’étape équivalente, parce que tester n’est pas une phase. Les critères sont branchés sur les tests dès qu’ils existent et rapportent en continu, du premier jour jusqu’après la mise en production. |
| Déployer | Vérifier | Les suites de tests doivent être au vert avant l’ouverture de la demande de fusion, pas après. Les contrôles automatiques sont le filet, pas l’endroit où l’on découvre que c’est rouge. |
| Exploiter | Signaler | Memex sait enregistrer un problème remonté et le transformer en travail. La boucle automatique qui referme le cycle, non — voir plus bas. |
| aucune | Clôturer | La dernière étape de Memex n’est pas un déploiement mais une signature humaine. Un agent ne peut jamais clore un chantier lui-même, quelle que soit la couleur des tests. |
L’article place les blocages dans des scripts qui tournent sur le poste du développeur. Un script local se contourne, se désactive, ou ne s’installe jamais : c’est un conseil, pas une barrière. Dans Memex, les contrôles qui comptent vivent côté serveur et côté dépôt central — un contrôle obligatoire avant fusion, lui, ne se contourne pas. Les scripts locaux restent autorisés, mais jamais pour quelque chose dont la justesse dépend.
L’article s’appuie sur l’historique du dépôt. Memex enregistre pour chaque écriture : quand, qui, et par quel canal — donc s’il s’agit d’une personne ou d’un agent, et via quelle interface. Un historique de dépôt ne fait pas cette distinction, et c’est exactement celle qu’un auditeur demandera.
Selon l’endroit où en est le chantier, l’outil fournit le texte exact d’instructions à donner à l’agent. L’article laisse ce passage informel, à la charge de chacun — donc différent d’une personne à l’autre.
Memex vérifie que les fichiers de règles existent et restent cohérents entre eux — c’est structurel. Il ne vérifie pas que l’agent se comporte toujours correctement après une modification de ses instructions. La preuve que c’est un manque et non un oubli : la question est posée noir sur blanc dans un chantier en cours, et elle est toujours ouverte. La méthode actuelle, ce sont des essais à blanc faits à la main. La proposition de l’article — une batterie de cas rejouée automatiquement à chaque changement de configuration — est la bonne réponse.
Il n’existe dans Memex aucune détection automatique qui réveille un agent pour rédiger le point de départ du chantier suivant. Et d’après la dernière vérification en date — non refaite aujourd’hui — la brique de mesure censée alimenter cette boucle n’émet rien, ni en préproduction ni en production. Le socle n’existe pas encore.
L’article décrit comment faire tourner la chaîne vite. Memex décrit ce qui l’empêche de mentir.
Les deux manques réels sont les deux endroits où l’article est en avance sur Memex. Tout le reste relève d’un choix assumé : préférer des engagements vérifiables en continu à des documents corrects le jour où on les écrit.