La méthode
Rien n’est acquis
tant qu’une mesure ne l’a pas dit.
Nous travaillons avec des agents IA. Ils écrivent vite ; la méthode décide de ce qu’ils écrivent, et la mesure dit si c’est vrai. Voici les méthodes que nous avons construites, ce qu’elles ont produit sur nos chantiers, et la règle qui les relie.
La règle
Tout ce que nous produisons doit être prouvé par quelque chose d’extérieur à lui. Une exigence, par son test. Une règle métier, par un contre-exemple. Une phase, par une démo qui marche vraiment. Une sauvegarde, par sa restauration. Une spécification, par un relecteur qui ne l’a pas écrite. Et la méthode elle-même, par ses chantiers réels. Ce qui n’a pas de preuve extérieure reste une opinion bien présentée.
Cette règle vient d’erreurs concrètes, payées une fois : un score DNS à 100/100 pendant que le courrier partait signé au nom d’un autre domaine ; un contrôle de santé vert sur une route qui ne répondait plus ; un échantillon de douze thèmes qui annonçait un défaut là où il y en avait cinquante et un.
On mesure au lieu d’affirmer
« C’est complet » ne suffit pas : on le montre. Chaque chiffre de ce site vient d’une mesure, et quand la mesure manque, nous le disons.
Un état honnête, jamais un faux vert
Quand une dépendance manque, l’application affiche un état d’attente, jamais un résultat inventé. Pas de simulation, pas de données factices dans le code livré.
On ne recode pas ce que la plateforme rend
Avant d’écrire, on vérifie dans l’ordre : le Hub le rend-il déjà ? Un pack le rend-il dans l’application ? Par quel mécanisme du socle écrire le reste ? Ce qu’aucun ne couvre est déclaré avant d’être codé.
Le papier suit le terrain
Quand le réel contredit la spécification, la spécification se met à jour, datée, sans effacer ce qui avait été décidé. Et quand une méthode ne sert à rien, on ne la déroule pas.
Nos méthodes, d’un coup d’œil
Besoin→Plan
De la vision au plan technique en huit maillons, avec six arrêts où le commanditaire tranche. Aucune ligne de code avant le go. La méthode en détail →
WhoAmI
La mémoire de chaque projet, écrite pour qu’un agent IA qui a tout oublié reprenne le travail en quelques minutes. La méthode en détail →
La rétrodocumentation
Reconstruire la documentation d’une application qui existe, depuis son code, en séparant ce qui est constaté de ce qui est voulu.
La méthode des sites
Un site décrit en un fichier, des outils qui posent, et un script qui constate ce qui tient. La méthode en détail →
RealMock
Le double statique d’une application sur des données inventées, avec une aide sur chaque élément et des parcours rejoués. La méthode et la démonstration →
Les skills
Nos procédures, écrites pour qu’un agent IA les charge et les suive, avec leurs arrêts et leurs garde-fous.
Besoin→Plan : de la vision au plan, sans code avant le go
La méthode qui cadre une application. Elle range tout sur trois axes qui ne se mélangent jamais : le métier (ce qu’on promet), la technique (avec quoi on le fait) et la livraison (quand et comment on le démontre). Le seul endroit où ils se croisent est une matrice de couverture : chaque promesse y est tracée jusqu’à sa brique, son test et sa démo.
M0 — Besoin et vision
Ce qu’on veut faire, pour qui, avec qui, et jusqu’où, en trois à cinq lignes. On passe quand le commanditaire dit : « oui, c’est ça ».
M1 — Spécification
Le quoi, jamais le comment : concepts, données, règles de gestion, droits, exigences non fonctionnelles. Un tiers doit comprendre le domaine sans connaître le code.
M2 — User stories
Les besoins réécrits en petites histoires, chacune démontrable par un test d’acceptation.
M3 — Features et épics
Chaque histoire a une seule capacité propriétaire, et aucune capacité n’est vide.
M4 — Arbitrages
Les doutes, rendus visibles pendant l’écriture, sont tranchés un par un avec leur pourquoi. Tant qu’une décision bloquante est ouverte, on n’avance pas.
M5 — Phasage
Des phases livrables une à une. Chacune se ferme par une démo, vue par le rôle concerné, jamais par une liste cochée.
M6 — Plan technique
Ce que la plateforme rend déjà, les briques à utiliser, et la matrice de couverture : rien d’oublié, rien de codé en trop.
M7 — Exécution
On sait où va le code, avec quels outils, sur quelle cible. Puis on code, phase après phase, et chaque phase revérifie les précédentes.
La méthode est conduite par un agent IA, qui s’arrête six fois pour une décision du commanditaire : la vision, la spécification signée, les arbitrages, le phasage, le plan, et enfin le go du code. Le dernier arrêt ne se présente jamais nu : un contrôle avant go vérifie que tout est tracé, et tout écart non levé bloque le code. Les livrables M1, M4 et M6 sont relus par un relecteur différent en nature de celui qui les a écrits : un humain du métier, ou un autre modèle d’IA.
Tout le détail de Besoin→Plan →
Ce que la méthode a produit sur nos chantiers
Chaque application importante commence par un chantier de cadrage. Une vingtaine sont tenus dans nos dépôts, chacun avec son journal de pilotage. Quelques exemples, tels qu’ils y sont consignés.
Une boîte à idées en trente minutes
Une démonstration pour une équipe de managers : développer et déployer une application devant la salle, en trente minutes, minutées. Le cadrage, mené en profil court, a tranché quatorze arbitrages, dont deux contre la recommandation de l’agent.
Le geste naturel l’emporte
Dans ce même cadrage, une idée reste modifiable en renvoyant un courriel du même objet. L’agent recommandait l’inverse ; le commanditaire a tranché : « c’est le geste naturel d’un utilisateur de messagerie ». Six règles de bord en sont nées.
Un chantier qui change de profil
Pour la fiche société partagée, un arbitrage apparu en cours de route a activé la conformité et l’exploitation : le chantier est passé du profil « solo » au profil « client ». Huit phases, quarante-deux tests verts.
Sept décisions contre l’agent
Pour la cité des agents IA, un cahier des charges de 1 794 lignes a donné trente-huit règles, toutes avec contre-exemple, et vingt-six arbitrages : dix-neuf conformes à la recommandation, sept contre. La relecture du plan a apporté onze corrections, dont trois graves.
Et une honnêteté qui se lit dans les journaux : sur la fiche société, le contrôle avant go a rendu « go sous réserve », parce qu’une dépendance côté plateforme n’était pas livrée. Aucune démo de phase n’a été déclarée franchie : rien n’est simulé.
WhoAmI : la mémoire de chaque projet
Un agent IA oublie tout d’une session à l’autre. Chaque dépôt porte donc son référentiel WhoAmI : identité de l’agent, architecture, journal, état du code, conventions, feuille de route. Il est mis à jour après chaque travail significatif, et des instantanés datés, jamais modifiés, gardent l’historique. Le référentiel est versé dans NotionSocle, où chaque fichier modifié devient une version interrogeable. Plus de quatre-vingts dossiers de nos dépôts en ont un.
La rétrodocumentation E0→E9
Pour une application qui existe déjà, nous reconstruisons la documentation depuis le code, en dix étapes : un point de départ figé, onze registres produits par script, le tri entre cœur, support et périphérie, puis personas, épics, features, user stories et règles de gestion, en séparant toujours le constaté du voulu. L’application est ensuite observée en marche, la documentation publiée, et le corpus obtenu nourrit un assistant, évalué sur un banc de questions tenu à l’écart du rédacteur.
Aucun chiffre écrit à la main
Chaque nombre du livrable est régénérable par une commande. Tant qu’il ne l’est pas, le chantier n’est pas fini.
Ce qui passe par un modèle se mesure en taux
Une réponse d’IA n’est pas « juste » : elle l’est dans une proportion, mesurée sur au moins trois passages, avec sa stabilité publiée à côté.
Une absence se prouve contre un registre
« Cela n’existe pas » ne se conclut jamais d’une simple recherche dans le code, mais d’un registre complet des éléments.
Une conséquence se lit dans les usages
Ce qu’un élément change s’établit en lisant qui s’en sert, pas en le supposant.
La publication passe trois contrôles : aucune affirmation sans source, aucun lien cassé, et une seconde régénération qui ne change rien. Sur l’une de nos applications, la reconstruction a relevé 833 éléments au registre, et en a tiré quatre personas, douze épics, quarante-deux features, quarante-six user stories et trente-cinq règles de gestion.
La méthode des sites
Un site décrit en un fichier, des outils qui posent, et un script de validation qui constate. Le script ne répare rien : il nomme, et il sort en erreur s’il reste un échec. Le premier site a passé ses trente-quatre vérifications sans échec ; trois sites suivants ont été posés en une après-midi depuis des descriptions engendrées par un programme.
La méthode des sites en détail → · Les sites qu’elle a produits →
RealMock : montrer une application sans rien exposer
Un RealMock est le double statique des écrans d’une application, sur les données d’une société inventée. Chaque élément porte une aide à trois niveaux, des parcours guidés se rejouent dans les écrans, et un contrôle bloque la publication à la moindre donnée réelle. Le premier, celui du Hub, est en ligne.
- 120+
écrans reproduits - 9
parcours rejoués pas à pas - 61
étapes racontées - 8 785
éléments expliqués
Comprendre RealMock et entrer dans la démonstration →
Les skills : la méthode, outillée
Une skill est une procédure écrite qu’un agent IA charge et suit, avec ses arrêts et ses garde-fous. Neuf sont publiées dans notre catalogue ; cinq autres, qui touchent à l’exploitation de la flotte, restent internes.
besoin2plan
Déroule Besoin→Plan sur un répertoire, reprend un chantier depuis son journal de pilotage, et s’arrête aux décisions du commanditaire.
realmock
Fabrique le RealMock d’une application, lot après lot, et s’arrête à ses trois validations.
majContexte
Tient à jour le référentiel WhoAmI d’un dépôt et le verse dans NotionSocle.
majDocRag
Écrit la documentation qu’on indexe pour un assistant, au lieu d’indexer le code brut, qui ne donnait que onze réponses justes sur vingt.
echeance
Confie une échéance de supervision à Alfred, le majordome du Hub, qui l’inscrit et l’annonce au carnet de bord.
things
Dépose, coche et relit des tâches dans Things, notre boîte de tâches pilotable par un humain ou par un agent.
majTodo
Dépose le reste-à-faire d’un chantier dans Things, rangé par dépôt.
majEnCours
Ajoute une ligne en tête du journal commun des sessions : la plus récente est toujours la première lue.
publierPage
Publie une page web autonome et rend un lien à partager.
Questions fréquentes
Faut-il toujours dérouler toute la méthode ?
Non. Si l’intention tient dans un message et se prouve par un test, on fait, on prouve, et on n’instrumente pas. La méthode sert quand il y a des décisions à prendre.
Que devient un cahier des charges existant ?
Il devient l’entrée de la méthode. La vision et la spécification en sont extraites, chaque histoire renvoie à son paragraphe, et les zones floues deviennent des arbitrages. Rien n’est inventé pour combler les trous.
Et pour un très gros sujet ?
Nous avions une méthode dédiée aux systèmes majeurs, FromSpec2Plan, éprouvée sur notre pack IA. Elle est aujourd’hui entièrement couverte par Besoin→Plan, en mode « cahier des charges fourni ».
Combien de fois le commanditaire intervient-il ?
Six fois entre le besoin et la première ligne de code, trois en profil court. Le reste du temps, l’agent avance seul et tient son journal.
Un projet à cadrer ?
Nous commençons par la vision et les arbitrages. Le code vient après le go.