Urazuke, la méthode de la preuve — l'échelle méthodologique (version 4)

Auteur : Pablo Kuschniroff, assisté par Claude Code. Version 4, commencée le 18 octobre 2026 et tenue à jour avec chaque décision ultérieure du registre (docs/DECISIONES.md) ; la date de départ reste fixe exprès, pour ne pas réécrire l'historique des versions à chaque fois qu'une nouvelle décision touche ce document. Ceci est un document de travail que je vais continuer à polir avec chaque projet qui l'utilisera ; rien de ce qu'il dit n'est encore doctrine fermée, même si c'est, pour autant que je sache, le premier distillat honnête d'une méthode qui a déjà trois systèmes en production derrière elle.

Avant d'entrer dans le vif du sujet, un avertissement sur la façon dont c'est écrit, parce que cela compte. Je l'ai écrit pour des personnes qui n'ont pas vécu ces projets avec moi : des gens qui veulent construire du logiciel avec l'intelligence artificielle et que ce logiciel dure, pas des gens qui veulent apprendre à programmer ni collectionner des astuces de prompts. C'est pourquoi je prends le temps d'expliquer, je répète quand il le faut, j'utilise le langage de tous les jours, et je laisse à la fin un glossaire avec chaque sigle et chaque expression familière qui m'échappe. Si à un moment vous tombez sur un mot étrange — « cliquet », « verrou », « fail-closed », « PND » —, allez au glossaire ; tout y est. Et quand vous lisez une marque comme Ref. 26, sachez que c'est un raccourci vers un cas réel que je raconte dans le document de références, avec sa date et sa preuve ; vous pouvez l'ignorer sans perdre le fil ou la suivre si le détail vous intéresse.

Le dépôt public de la méthode est github.com/pkuschnirof/urazuke. On y trouve ce document, les contrats de chaque échelon, le manuel du cours et les références, dans les huit langues de NAC3.

Le nom

Urazuke (裏付け) est un mot japonais qui désigne l'appui dont dispose une affirmation : ce qui la soutient par derrière (littéralement, « la doublure de derrière »). Le verbe urazukeru signifie « étayer par des preuves ». Je l'ai choisi le 17 octobre 2026, après avoir écarté plusieurs noms pour cause de collision avec des entreprises et des projets existants, et je l'ai choisi parce qu'il dit exactement ce que la méthode demande : que chaque affirmation du modèle vienne avec son appui, et que l'appui puisse se vérifier sans lire le code. Le nom ne se traduit pas ; le sous-titre, « la méthode de la preuve », si : the evidence method, o método da evidência, la méthode de la preuve, die Nachweis-Methode, il metodo del riscontro, 裏付けの方法, 验证方法. Dans ce document, « l'échelle » est la structure de la méthode — ses vingt-quatre échelons — et « Urazuke » est la méthode entière.

De quoi s'agit-il

Je veux être clair sur ce que j'enseigne et sur ce que je n'enseigne pas. Je n'enseigne pas un outil. J'enseigne une méthode : quoi faire dans quel ordre, quoi demander au modèle à chaque moment, ce qu'il doit vous livrer, et comment savoir — sans lire de code — que ce qu'il vous a livré est complet. Le pari est que n'importe qui, avec n'importe quel outil d'intelligence artificielle capable de programmer, puisse construire du logiciel en conversant avec un modèle au lieu de taper le code à la main, et que ce qui en sorte soit robuste, prêt pour la production et, c'est là l'important, n'exige pas que le propriétaire du projet relise une seule ligne de code. Et je veux être tout aussi clair sur ce qu'elle n'est pas : ce n'est pas un procédé pour faire des systèmes plus vite. C'est un procédé pour faire des systèmes exploitables et maintenables sans que personne n'ait besoin de comprendre un seul bit de leur code, parce que le code, c'est le cadre agentique qui l'écrit qui le comprend et le maintient. La vitesse, quand elle apparaît, est une conséquence, et c'est pourquoi il n'y a pas de délais dans ce document : la taille et la complexité de chaque système les fixent, et la méthode ne fixe que l'ordre.

Une précision qu'on m'a demandé de mettre par écrit, parce que la phrase précédente se prête à une lecture qui n'est pas la mienne : « ne demande pas au propriétaire de relire une seule ligne de code » n'est pas la même chose que « pensée pour que des gens sans connaissances en systèmes puissent programmer ». Ce n'est pas le cas. L'objectif premier de cette méthode n'est pas d'abaisser la barre technique pour que n'importe qui puisse construire un logiciel sans rien savoir de la façon dont on construit un logiciel : c'est de donner à qui doit répondre d'un système un ancrage méthodologique pour que ce qu'un modèle construit sorte avec la solidité de l'ingénierie des systèmes de toujours, en contrant les faiblesses avec lesquelles les modèles appliquent ces mêmes principes quand personne ne les exige par écrit. Que le propriétaire ne lise pas le code est une conséquence de l'endroit où j'ai placé les portes et de ce qu'un humain peut vérifier sans lire une implémentation, pas la promesse que n'importe qui, quoi qu'il sache, puisse diriger un projet logiciel sans rien comprendre à ce qu'il dirige. Le profil que les contrats demandent réellement se situe entre les deux : quelqu'un capable de lancer une commande, de gérer une habilitation, de restaurer une sauvegarde, de comprendre ce que le quota de CI lui indique, et de savoir reconnaître quand ce que le modèle a livré ne suffit pas — ni un néophyte pur, ni quelqu'un qui sait déjà programmer.

Et une autre précision, sur le coût. Suivre cette échelle consomme plus de jetons que de demander au modèle de tout résoudre en une seule passe : chaque échelon ajoute un prompt, une vérification propre, un artefact que le modèle doit aussi maintenir. Ce qui ne se voit pas à première vue, c'est ce que ça économise. Un système construit sans ces portes finit, tôt ou tard, par avoir besoin de réingénierie : revenir sur un dimensionnement qui n'a pas été fait, traquer un bug qu'un test rouge aurait attrapé à l'échelon 8, réécrire ce que personne n'a audité à temps. Cette réingénierie, en jetons, en temps et en argent, coûte largement plus cher que le prompt en plus que coûte chaque échelon. Je le dépense en amont, en connaissance de cause, pour ne pas le dépenser deux fois en aval, à l'aveugle.

Cela paraît ambitieux, et ça l'est. Mais j'ai quelque chose que presque personne n'a : trois systèmes réels que j'ai construits exactement ainsi, qui fonctionnent aujourd'hui avec de vrais clients, et dont j'ai extrait chaque règle qui suit. Donc la question que je me pose n'est pas « est-ce que ce sera possible ? », parce que ça l'a déjà été. La question est « qu'ai-je fait, dans quel ordre, et qu'est-ce qui, dans tout cela, a vraiment fait la différence ? ». Cette échelle est ma réponse, et c'est la base de trois choses : la documentation de la méthode, la pratique que feront les élèves du cours, et les manuels. Plus tard je l'exporterai comme un flux d'exécution dans mon outil, pour que ce soit l'outil qui guide la méthode et non la mémoire de chacun.

D'où vient la méthode, et ce que je ne veux pas qu'on comprenne de travers

Il y a une lecture facile de tout ceci que je veux désamorcer avant qu'elle ne s'installe : celle selon laquelle la méthode serait une collection de rustines que j'aurais posées après chaque coup dur. Ce n'est pas le cas, et il m'importe de le dire avec précision, parce que cela change la façon dont il faut lire chaque échelon.

La méthode vient de deux facteurs qui se sont combinés, et aucun des deux ne suffit seul. Le premier est ma propre connaissance de l'ingénierie des systèmes. Cela fait de nombreuses années que j'applique ce que n'importe qui venant des systèmes reconnaît tout de suite : relevé avant de concevoir, exigences écrites, dimensionnement avec des chiffres, conception, construction, tests comme preuve, déploiement reproductible, exploitation, audit périodique, documentation comme partie du produit. La plus grande partie de ce que j'exige dans les vingt-quatre échelons est ce que j'ai toujours exigé dans un projet bien mené. Je ne l'ai pas inventé pour les modèles ; je l'ai apporté d'avant.

Le second facteur est ce que les incidents de ces cinq mois m'ont montré, l'un après l'autre : où les modèles appliquent ces principes de manière fragile. Un modèle sait parfaitement ce qu'est un test, ce qu'est une cause racine, ce qu'est un dimensionnement ; si vous le lui demandez, il vous l'explique mieux que bien des ingénieurs. Mais en pratique il dit qu'il a testé et il n'a pas testé, il estime d'un air assuré une donnée que seul le métier possède, il remplit un trou dans les règles métier avec ce qui lui a paru raisonnable, il rapporte trop parce qu'il a été entraîné à être utile, et il construit un compteur qui ment sans s'en rendre compte. Chacun de ces cas, que je raconte dans les références, m'a dit exactement où il fallait serrer : où un principe qui pour moi était évident devait se convertir en une clause explicite du prompt, en une porte, en une vérification que je fais sans lire de code.

Donc, quand dans un échelon je dis « ceci, je l'ai imposé après tel incident », je ne dis pas que le principe est né là. Je dis que c'est là que j'ai constaté que le modèle ne l'appliquait pas tout seul, et qu'il fallait le lui exiger par écrit. La méthode est de l'ingénierie des systèmes de toujours, appliquée avec la rigidité nécessaire pour un constructeur qui ne se fatigue pas et qu'on ne peut pas croire sans preuve. Les cicatrices sont la preuve de là où la rigidité est nécessaire, pas l'origine des principes.

Les trois cas d'utilisation de la méthode

Avant d'aller plus loin, une bifurcation qui n'était pas dans les premières versions et qu'un lecteur m'a demandée à juste titre. Ce document décrit l'échelle en regardant un dossier vide : l'échelon 0 décide si le projet s'aborde, le 4 déploie le squelette sans fonctionnalité, le 5 ouvre le premier bloc. C'est le cas le plus clair pour apprendre, et ce n'est pas le plus fréquent. La méthode a trois cas d'utilisation, et il vaut mieux savoir dans lequel vous êtes avant d'ouvrir l'agent, parce que cela change par où l'on entre :

1. Projet neuf. Dossier vide et un propriétaire avec une demande. On entre par l'échelon 0 et on gravit les vingt-quatre dans l'ordre. C'est ce que décrit ce document, avec ses contrats et le manuel du cours.
2. Évolutif-correctif sur un système fait avec la méthode. Le système a déjà gravi l'échelle : il a un contrat, une carte, des éléments en attente clos avec leur preuve, une batterie, un déploiement et des manuels. On entre par l'échelon 5, en ouvrant un bloc, et on suit la boucle ; le 13 périodique ; le 23 à la clôture de chaque étape. C'est la phase 4 de la ligne de temps (Partie B).
3. Évolutif-correctif sur un système fait sans la méthode. Un système qui tourne, avec des utilisateurs, fait par un autre ou par soi-même sans preuve, qu'il faut corriger ou faire grandir. On n'entre ni par le 0 ni par le 5 : on entre par un tronçon de normalisation de huit stations (N0 à N7) qui récupère, par autodécouverte et avec des marques de source, tous les intrants que les échelons du démarrage produisent, monte une ceinture de sécurité autour du système sans le réécrire, et seulement ensuite ouvre la boucle en mode correctif ou évolutif. Ce chemin est dans une page à lui, le chemin évolutif-correctif, et il a sa part du cours avec un second projet-guide.

Ce qui reste dehors, nommé : la migration technologique n'est pas un cas d'utilisation de la méthode ; c'est un autre projet, et en général cela tombe dans les critères excluants de l'échelon 0.

L'IA n'interrompt pas la méthode : elle la continue

C'est la thèse qui ouvre tout, et je la mets en premier parce qu'elle désamorce l'objection la plus courante avant qu'elle n'apparaisse : « comment vas-tu faire confiance à du code écrit par une machine ? ».

Ma réponse est que l'industrie a déjà cessé de faire confiance à l'auteur du code il y a vingt ans. Quand le gros de l'écriture est passé à des équipes juniors, externalisées ou tournantes, la revue ligne par ligne est devenue impossible à soutenir. Et ce qui a grandi à sa place, c'est tout ce que nous tenons aujourd'hui pour acquis : les tests automatisés, l'intégration continue, les critères d'acceptation, les pipelines qui ne laissent rien passer sans vert, le « shift left » des tests, le contrôle qualité comme fonction indépendante. Ce fut la réponse de l'ingénierie des systèmes à « celui qui écrit n'est pas fiable » : ne pas lui lire le code, lui exiger des preuves.

Mettre un modèle à écrire, donc, n'est pas un saut dans le vide. C'est remplacer un auteur en qui nous ne faisions déjà plus confiance par un autre en qui nous ne faisons pas confiance non plus, et pour lequel nous avions déjà monté l'appareil de vérification. Cela devrait rassurer, pas inquiéter. Et en plus, le nouvel auteur est moins cher, plus rapide, et — à la différence du junior — il ne se vexe pas quand vous lui demandez de prouver en rouge.

C'est pourquoi cette méthode s'appuie, sans le cacher, sur l'ingénierie des systèmes classique. Le squelette est celui de toujours. Il ne pouvait pas en être autrement, parce que les problèmes sont ceux de toujours : ne pas savoir combien de données il y aura, ne pas savoir ce que veut le client, ne pas savoir si ce qui a été construit est ce qui a été demandé. L'IA n'a pas changé les problèmes ; elle a changé qui fait chaque partie et à quel coût. Même le critère d'éligibilité X2 de l'échelon 0 est de l'ingénierie classique : la testabilité comme condition de contrat.

Ce qui est ancien et ce qui est nouveau là-dedans

L'ancien, et il convient de dire que c'est ancien : le squelette d'étapes, l'indépendance de celui qui vérifie par rapport à celui qui construit, les tests comme preuve, la documentation comme partie du produit, le relevé avant la conception.

Ce qui change vraiment, et c'est là que se trouve mon apport, ce sont trois choses :

1. Où va l'effort de l'humain. Dans la méthode classique, l'humain écrit la spécification, écrit le code, et un autre humain le relit. Ici l'humain ne fait que deux choses : il décide, et il vérifie des artefacts. Tout le reste — rédiger, construire, tester, mesurer, documenter — c'est le modèle qui le fait. C'est pourquoi chaque échelon se termine par une « vérification de complétude sans lire de code » : c'est l'endroit exact où l'humain reste indispensable, et aucun autre.

2. L'auteur fabrique aussi la preuve. C'est le seul point authentiquement nouveau, et c'est la nuance qui justifie trois échelons entiers. Le junior écrivait du code douteux, mais il ne fabriquait pas la preuve : les tests et les mesures, c'est un autre qui les montait, ou du moins un autre les regardait. Le modèle, lui, produit le code et le test et le compteur et le rapport, dans la même session, avec la même assurance dans la voix quand c'est juste et quand c'est faux. Je l'ai vu : le compteur qui a menti deux fois Ref. 36, l'erreur d'authentification rapportée comme « succès » Ref. 43, les trois assertions sur quatre qui étaient fausses. Alors « réviser la preuve au lieu du code » reste le principe correct, mais la preuve doit se prouver elle-même : le test vu en rouge (échelon 8), l'instrument avec sa garde (échelon 7), le rapport qui sépare le vérifié du cru (échelon 12), l'auditeur distinct du constructeur (échelon 13). Ce n'est pas une inquiétude nouvelle : c'est la même discipline d'indépendance du contrôle qualité, portée un pas plus loin vers l'intérieur.

3. Le coût des artefacts. Dans la méthode classique, la documentation coûtait cher, donc on la faisait une fois et elle vieillissait. Ici la régénérer est gratuit, donc la règle devient « dans le même commit » et « reproductible à la main, sans IA ». Ce qui était avant un idéal inatteignable devient une porte.

Pour le cours et pour la présentation publique, cela définit le positionnement avec honnêteté : ce n'est pas « la nouvelle façon de programmer » ; c'est de l'ingénierie des systèmes appliquée à un constructeur qui ne se fatigue pas et qu'on ne peut pas croire. À ceux qui viennent des systèmes, cela sonne familier et cela fait baisser la méfiance ; à ceux qui viennent du vibecoding, cela donne ce qu'ils n'ont pas, qui est justement le squelette. Et cela me distingue des outils qui vendent de la vitesse et omettent le squelette entier.

Partie A — Comment lire chaque échelon

Chaque échelon a huit parties, toujours les mêmes, pour qu'on puisse les comparer :

• Intention : ce qu'il cherche, en une phrase.
• Quand : à quel moment du projet on le gravit, et si on le gravit une fois ou si on le répète. Cette partie est nouvelle dans la version 4 et je l'explique en détail dans la Partie B, parce qu'une méthode sans ligne de temps est une liste de bonnes intentions.
• Entrées : ce qui doit exister avant pour pouvoir le gravir.
• Artefact : ce qui reste écrit ou exécutable quand on l'a gravi. C'est toujours quelque chose de concret : un fichier, un test, un script.
• Porte : ce qui doit être vrai pour passer au suivant. Si ce n'est pas rempli, on ne monte pas.
• Qui décide : le propriétaire du projet, l'agent, ou personne parce que c'est automatique.
• Échec évité : le type de problème que l'échelon prévient, avec une référence courte au cas réel où je l'ai constaté.
• Contrat : le fichier où se trouve comment on l'exécute : contexte, prompts, résultat, vérification, signaux d'alarme.

Deux précisions importantes. D'abord : l'échelle est neutre vis-à-vis de l'outil. Chaque artefact est un fichier, un test ou un script ; aucun n'exige mon outil ni aucun autre. Forge les automatise (les portes, les commandes, le registre des éléments en attente), mais l'échelon existe sans Forge. Ensuite : les échelons sont numérotés dans l'ordre où on les gravit, et ils se regroupent en quatre tronçons : ceux de 0 à 4 sont de démarrage et se gravissent une fois par projet ; ceux de 5 à 12 sont la boucle qui se répète à chaque changement ; ceux de 13 à 20 sont de mise en production, et se gravissent une fois, avant le premier déploiement ; et ceux de 21 à 23 sont d'exploitation, quand le système est déjà vivant. Le 23 ferme le cycle et revient au 0 pour le prochain projet. À l'intérieur d'un tronçon, le numéro dit l'ordre ; entre tronçons, la boucle se répète pendant que les trois autres se gravissent une fois. Mais « pas strictement séquentiels » ne veut pas dire « dans n'importe quel ordre » : la Partie B dit exactement quand on gravit chacun et ce qui se passe entre les deux.

Partie B — La ligne de temps : quand on gravit chaque échelon et ce qui se passe entre-temps

Cette partie n'existait pas dans les versions précédentes, et son absence était un défaut sérieux : la méthode disait quoi faire et comment le vérifier, mais elle ne disait pas quand. Et « quand » est la moitié d'une méthode. Un lecteur qui l'aurait prise au pied de la lettre pouvait gravir les vingt-quatre échelons l'un après l'autre et se demander à quel moment, alors, on fait l'infrastructure, la chaîne d'intégration et de déploiement continus, l'ingestion des exigences, le développement de la fonctionnalité, les tests de bout en bout de tous les flux, le regard humain sur les écrans, et les tests humains d'acceptation. Tout cela se passe, et se passe à des moments précis, entre les échelons et à l'intérieur d'eux. Je l'écris ici.

B.0 Le procédé entier, en un graphique

Avant les tableaux, le dessin. Il est en notation de procédé (à la manière de BPMN : événements ronds, tâches rectangulaires, portes en losange, flèches de retour pointillées), et il dit trois choses que les tableaux disent moins bien. Première : le procédé commence en dehors de la méthode, dans l'ingénierie des exigences, qui est un prérequis et qui est en outre permanente : elle ne finit jamais, et chaque nouvelle exigence y rentre à nouveau. Deuxième : une exigence nouvelle n'entre pas seulement dans la boucle ; elle se réinjecte dans les échelons d'évaluation, parce qu'elle peut changer les chiffres avec lesquels l'architecture a été décidée (est-ce que ça tient encore le « fois dix » ?), et de là vers l'avant. Troisième : le procédé se termine par l'exécution manuelle des cas de test par des personnes (échelon 10), et ce que cette exécution trouve revient dans la boucle comme exigence. Le circuit se ferme avec des gens, pas avec des machines. Quatrième, et le schéma ne le montrait pas avant cette correction : quand ce que le système construit a une conséquence sur le monde (encaisser, envoyer), la boucle se rouvre après l'échelon 14, avec les verrous déjà en place, pour construire cette partie en mode de répétition avant de passer à la chaîne de production (15). Ce n'est pas un retour au début : c'est la même porte que d'habitude (clôture de bloc ?) parcourue une fois de plus, maintenant avec le filet de sécurité prêt.

flowchart TB
  subgraph RE["Ingénierie des exigences · prérequis externe et permanent"]
    direction TB
    E0((Demande du métier)) --> RE1["Relevé : entretiens, cas d'utilisation, modèle de domaine, prototypes"]
    RE1 --> RE2["Exigence nouvelle ou modifiée"]
  end
  subgraph ARR["Démarrage · échelons 0 à 4, une fois"]
    direction TB
    P0["0 Éligibilité"] --> P1["1 Contrat de collaboration"] --> P2["2 Définition et arbre sémantique"] --> P3["3 Dimensionner"]
    P3 --> G1{"L'architecture tient-elle les chiffres ?"}
    G1 -- oui --> P4["4 Squelette avec portes"]
    G1 -- non --> P3
  end
  subgraph LOOP["Boucle · échelons 5 à 12, à chaque changement"]
    direction TB
    P5["5 Éléments en attente spécifiés"] --> P6["6 Décisions écrites"] --> P7["7 Mesurer"] --> P8["8 Test en rouge et bout en bout"] --> P9["9 Qualité du code"] --> P10["10 Cas de test manuel"] --> P11["11 Symétrie"] --> P12["12 Rapport honnête"]
    P12 --> G2{"Clôture de bloc ?"}
    G2 -- non --> P5
  end
  H1["Exécution manuelle des cas de test, par des personnes"]
  subgraph OUT["Mise en production · échelons 13 à 20, une fois"]
    direction TB
    P13["13 Audit"] --> P14["14 Verrous"] --> P15["15 Chaîne vers la production"] --> P16["16 Observabilité"] --> P17["17 Persistance"] --> P18["18 Vulnérabilités"] --> P19["19 Performance"] --> P20["20 Documentation vivante"]
  end
  D((Premier déploiement))
  subgraph OPS["Exploitation · échelons 21 à 23"]
    direction TB
    P21["21 Supervision des ressources"] --> P22["22 Supervision des erreurs"] --> P23["23 Résident et rétrospective"]
  end
  RE1 --> P0
  P4 --> P5
  RE2 -. "réinjecte : les chiffres changent-ils ?" .-> P3
  RE2 --> P5
  G2 -- oui --> H1
  H1 -- "constats = exigences" --> RE2
  H1 --> P13
  P14 -. "ce qui a une conséquence se construit maintenant, les verrous en place" .-> P5
  P20 --> D --> P21
  P21 -. "écarts = éléments en attente" .-> P5
  P22 -. "erreurs = éléments en attente" .-> P5
  P23 -. "revient au 0 pour l'étape suivante" .-> P0

Si le dessin ne s'affiche pas (le lecteur de markdown ne dessine pas mermaid), le texte ci-dessus le décrit en entier ; dans la version HTML il se dessine tout seul.

B.1 Les cinq phases d'un projet

Un projet mené avec cette méthode passe par cinq phases. Les trois du milieu sont celles qui correspondent aux tronçons de la boucle, de la mise en production et de l'exploitation ; la phase 1 est le tronçon de démarrage ; et la phase 0 est l'ingestion initiale, que la méthode couvre aussi même si ce n'est pas un « échelon » en soi. Je ne mets pas de durées : elles dépendent de la taille et de la complexité de ce qui est demandé, et une durée écrite se transforme en attente fausse. Ce qui ne dépend pas de la taille, c'est l'ordre.

Ce tableau est celui du projet neuf. Quand le système existe déjà et qu'il n'est pas né avec la méthode, les phases 0 et 1 se remplacent par le tronçon de normalisation (lecture, ceinture, mesurer et ordonner) qui est dans le chemin évolutif-correctif ; les phases 2, 3 et 4 sont les mêmes.

Dans un projet avec des utilisateurs et des conséquences, ce qui grandit, c'est la boucle : la fonctionnalité. Le démarrage, la mise en production et l'exploitation ont la même forme dans un petit système et dans un grand ; ce qui change, c'est combien il y a à mesurer, pas quoi.

B.2 Ce qui se passe entre un échelon et le suivant

Voici ce qui manquait. Pour chaque phase, quelles tâches de chaque type on fait et à quel moment exact par rapport aux échelons. Lisez la table par lignes : chaque ligne est un type de travail, et chaque cellule dit quand on le fait dans cette phase.

Un détail que je veux souligner parce que c'est là que les gens qui viennent du vibecoding se trompent le plus : les tests de bout en bout de tous les flux ne se font pas une seule fois à la fin. Ils se font trois fois, à trois échelles. Avec chaque élément en attente, le flux que cet élément a touché. À la clôture de chaque bloc, tous les flux qui existent jusque-là. Et avant la production, tous les flux avec la version exacte qui va être promue. Si vous ne faites que la troisième, vous arrivez à la fin avec un système que personne n'a testé de bout en bout pendant des semaines, et la mise en production se transforme en une semaine de réparations.

B.3 Le rythme de la boucle : un bloc fonctionnel typique

Un bloc fonctionnel est un ensemble de quatre à huit éléments en attente liés entre eux, qui ensemble font quelque chose que le métier peut utiliser : « l'agenda de base », « les rappels », « le rapport mensuel ». Voici à quoi il ressemble de l'intérieur :

1. Ouverture du bloc. Le propriétaire raconte, en prose, ce qu'il veut pour ce bloc. L'agent le convertit en éléments en attente numérotés, avec leur « comment on vérifie », et demande ce qui ne suffit pas pour écrire un élément en attente vérifiable (échelon 5). Le propriétaire priorise.
2. Chaque élément en attente. L'agent annonce quel élément il prend et pourquoi. Si en chemin apparaît une règle métier qui n'est pas écrite, il s'arrête et demande (6). Si l'élément dépend d'un nombre — combien de requêtes, combien de temps —, il le mesure d'abord avec un instrument doté d'un test (7). Il construit. Quand il termine, il clôture dans cet ordre : le test prouvé en rouge, vert, la régression des voisins et un test de bout en bout du flux touché (8) ; la porte de qualité du code au vert (9) ; les cas de test manuel du flux, écrits pour une personne (10) ; et, si le changement a touché un contrat entre deux parties du système, l'autre côté mis à jour dans le même commit (11). Le rapport sépare le vérifié du cru et déclare les angles morts (12). Le propriétaire lit le rapport et regarde la capture de l'écran. Il ne lit pas de code.
3. Clôture du bloc. La batterie complète de bout en bout au vert dans l'environnement de test. Le propriétaire ou un utilisateur de confiance exécute les cas de test manuel du bloc (10) et note ce qui s'est passé et ce qui a échoué ; chaque échec revient dans la boucle comme élément en attente correctif. On lit le rapport de qualité du bloc (9). On met à jour le manuel utilisateur avec les nouveaux écrans (20, dans le même commit). C'est seulement alors qu'on ouvre le bloc suivant.

Dans une journée typique de la boucle, ce que la méthode demande au propriétaire est petit et borné : répondre à deux ou trois questions de règles métier, lire deux ou trois rapports, regarder deux ou trois captures. C'est tout. Si on lui demande davantage, soit l'agent demande ce qu'il pourrait résoudre seul (échelon 1), soit le propriétaire lit du code (et alors quelque chose de l'échelon 8 ou du 12 ne fonctionne pas).

B.4 Les jalons humains

Je résume dans une liste les moments où un humain, le propriétaire ou quelqu'un de sa confiance, doit regarder ou utiliser le système. Ils sont peu nombreux, ils sont à des moments précis, et aucun ne peut se déléguer à l'agent :

• Fin du démarrage : ouvrir l'URL de l'environnement de test et voir le système vide.
• Avec chaque élément en attente qui touche un écran : regarder la capture réelle de l'environnement de test.
• À la clôture de chaque bloc : exécuter les cas de test manuel du bloc (10) dans l'environnement de test et noter le résultat ; ce qui échoue revient dans la boucle comme exigence.
• Avant le premier déploiement en production : tests d'acceptation sur tous les flux, en suivant tous les cas de test manuel.
• À l'échelon 20 : une personne qui ne programme pas suit le manuel de reprise dans l'environnement de test.
• Après chaque déploiement en production : vérifier que la version qui tourne est celle qu'on voulait, et faire une passe en lecture seule sur les flux critiques.
• Avant le premier déploiement, au 19 : lire les chiffres du test de charge avec la tolérance du métier à côté, et le point de rupture.
• À chaque cycle de la supervision (21 et 22) : lire le rapport cyclique avec l'agent et décider quel écart et quelle erreur deviennent des éléments en attente.

Tout le reste — les tests, les mesures, les audits, la documentation — c'est le modèle qui le fait et l'humain le vérifie par l'artefact, pas par le code.

B.5 Comment entrent les exigences : du relevé à l'arbre sémantique et aux éléments en attente

Je veux m'arrêter là-dessus parce que c'est là que l'ingénierie des systèmes classique a le plus à dire et là que le vibecoding l'ignore avec le plus d'enthousiasme. Une exigence n'est pas une phrase du client dans un chat. C'est une phrase du client traitée par des méthodes qui existent depuis des décennies et qui restent valables avec un modèle aux commandes, parce que le modèle est très bon pour les appliquer si vous le lui demandez et très mauvais pour les appliquer si vous ne le lui demandez pas.

Les méthodes que j'utilise, et que la méthode exige à chaque phase :

• Entretiens avec le propriétaire, ouverts, en prose, enregistrés. C'est la phase 0. Je n'essaie pas qu'ils soient complets : j'essaie que l'agent détecte ce qui leur manque.
• Cas d'utilisation ou récits utilisateur, un par flux que le métier peut nommer : « la réceptionniste saisit un rendez-vous », « le patient reçoit le rappel ». Chacun a un acteur, un déclencheur, des étapes, un résultat et des exceptions. C'est l'unité avec laquelle on ouvre un bloc fonctionnel.
• Modèle de domaine : les entités du métier, leurs attributs, leurs états possibles et les transitions entre états. C'est le cœur de l'arbre sémantique (voir plus bas) et ce qui évite que le modèle invente des états que le métier n'a pas.
• Critères d'acceptation par récit, sous la forme « étant donné telle situation, quand telle chose se produit, alors on voit tel résultat ». Ce sont eux qui se convertissent en « comment on vérifie » de chaque élément en attente et, ensuite, en test de bout en bout.
• Prototypes d'écran, même si ce n'est qu'un dessin. Le regard humain sur les écrans commence ici, avant qu'il n'existe du code.
• Traçabilité : chaque exigence peut se suivre jusqu'à l'élément en attente qui l'implémente, le test qui la prouve et le commit qui l'a clôturée. Dans la méthode, la traçabilité n'est pas une matrice à part : c'est l'élément en attente lui-même, qui cite son origine et sa preuve.

L'arbre sémantique. C'est l'artefact qui ordonne tout cela et c'est la carte que l'agent lit à chaque session (échelon 2). C'est un arbre, pas une liste : le système à la racine ; en dessous, les domaines ou modules ; sous chacun, ses acteurs, ses processus (les cas d'utilisation), ses entités avec leurs états, ses écrans et ses intégrations externes ; et accrochés à chaque nœud, les éléments en attente qui le touchent et les décisions qui l'affectent. C'est l'agent qui le construit à partir du relevé, c'est vous qui le corrigez, et il grandit avec chaque bloc. Sa valeur est double : il donne au modèle le contexte exact du nœud qu'il va toucher sans avoir à lire tout le projet, et il vous donne à vous une façon de vérifier que le système que l'agent comprend est celui que le métier a demandé, sans lire de code. Quand un élément en attente n'est accroché à aucun nœud, soit l'arbre est incomplet, soit l'élément est hors périmètre ; les deux se voient en dix secondes.

La spécification détaillée vit dans l'élément en attente. Dans la méthode classique il y avait un document de spécification des exigences, long, qui vieillissait. Ici ce document se décompose : chaque élément en attente porte sa propre spécification complète, et la somme des éléments en attente est la spécification du système. Un élément en attente bien écrit a : un titre ; le nœud de l'arbre sémantique auquel il est accroché ; le récit ou le cas d'utilisation qui l'origine, avec les mots du client ; la description détaillée de ce qui est demandé ; les règles métier applicables, avec leur décision et leur date ; les données qui entrent et qui sortent ; les écrans affectés, avec le prototype s'il y en a un ; les cas limites et les exceptions ; les critères d'acceptation ; et comment on vérifie. L'agent le rédige à partir de votre demande en prose, demande ce qui ne suffit pas pour spécifier, et vous le lisez avant qu'il ne se construise. Lire une spécification d'élément en attente est ce qui vous rapprochera le plus de la lecture du code, et c'est exactement la bonne distance.

Les éléments en attente clôturés sont de la documentation. C'est ce qui ferme le cercle. Quand un élément en attente se clôture, on ne l'efface pas et on ne l'archive pas vide : il reste avec sa spécification, la décision qui l'a originé, la preuve avec laquelle il a été clôturé (les chiffres du rouge et du vert, la capture de l'écran, le nombre mesuré), le commit, et la date. La file des éléments en attente clôturés est, donc, l'historique fonctionnel du système : ce qui a été construit, pourquoi, quand, et comment ça a été testé. C'est de là que sortent le journal des modifications, les nouvelles sections du manuel utilisateur et, quand quelqu'un demande six mois plus tard « pourquoi le système fait-il cela ? », la réponse. Le manuel du cours apprend à exiger cette documentation à la clôture de chaque élément en attente, dans la même session, comme partie de la routine de l'échelon 5.

Partie C — Les vingt-quatre échelons

Ils vont dans l'ordre où on les gravit. Les six échelons de qualité opérationnelle (16 à 19 avant le premier déploiement ; 21 et 22 après) sont ceux que je faisais sans les nommer : que le système puisse se voir pendant qu'il tourne, qu'il tienne le volume pour lequel il a été dimensionné, qu'il n'ait pas de trous connus, et qu'une fois en production personne n'apprenne un problème par un utilisateur en colère. Les deux supervisions finissent au même endroit que tout le reste : la boucle, comme éléments en attente correctifs. Si vous débutez, chacun de ces six contrats, et ceux des échelons 9 et 10, commencent par un paragraphe qui explique leurs mots dans le langage de tous les jours, et le glossaire les a tous.

Étape 0 — Ce projet peut-il être abordé ainsi ? (l'éligibilité)

Il y a quelque chose qui précède tout le reste, et qui n'est dans aucun dépôt parce que c'est toujours arrivé déjà décidé : la décision de savoir si un projet s'aborde avec cette méthode ou non. C'est un critère que j'ai porté dans ma tête pendant des mois et que je finis d'écrire. Les deux critères excluants, je les ai déjà clairement ; ils sortent des projets que j'ai refusés, pas de ceux que j'ai acceptés Ref. 46 : les « non » définissent la frontière mieux que les « oui ». Les critères qui pondèrent, je suis encore en train de les calibrer, et je le signale comme tel.

• Intention : décider si un projet s'aborde avec cette méthode, et avec un agent aux commandes, ou non, AVANT d'ouvrir le dépôt. Parce que si vous entrez dans un projet qui ne s'y prête pas, la méthode se dégrade en « programmer avec l'IA », et là, oui, le propriétaire finit par lire du code.
• Quand : une seule fois, avant toute autre chose. Si le système existe déjà, cet échelon se gravit dans sa version pour les legacy (la station N0 du chemin évolutif-correctif), avec quatre critères de plus et X2 mesuré écran par écran.
• Entrées : la demande du client, le domaine métier, les données, la technologie, les environnements disponibles, et qui va être le propriétaire.
• Artefact : une fiche d'éligibilité d'une page, avec les critères notés et la décision : on y va, on n'y va pas, ou on y va sous conditions.
• Porte : les critères excluants sont tous au vert, et la note de ceux qui pondèrent dépasse le seuil (un seuil que je n'ai pas encore défini).
• Qui décide : le propriétaire. Aujourd'hui c'est moi ; l'idée est que la méthode permette à une autre personne de le décider avec la même fiche.
• Échec évité : se lancer dans un projet où l'agent ne peut pas se vérifier seul, ou où il n'y a pas de propriétaire du domaine pour décider, et finir avec l'humain qui relit le code ligne par ligne.
• Contrat : peldanos/peldano-00-elegibilidad.md.

Les deux critères excluants.

Une précision qui vaut de l'or pour la neutralité vis-à-vis de l'outil : NAC3 (le protocole qu'utilise mon outil pour que les écrans puissent être pilotés par programme) N'EST PAS une condition ; c'est le moyen par lequel j'y parviens aujourd'hui. Le critère neutre s'énonce ainsi : l'interface peut être exécutée par programme, et chaque élément de l'écran est accessible avec ses différentes méthodes (cliquer, saisir, lire son état), de sorte qu'un test puisse parcourir l'écran puis vérifier l'effet dans le backend. Une technologie dont l'interface n'expose pas ses éléments à un « driver » (comme Playwright, par exemple) reste dehors, même si elle a un dépôt.

Et une lecture qui me paraît importante : au fond, X1 et X2 sont la même condition vue de deux côtés. L'agent doit pouvoir se vérifier seul, de bout en bout, et laisser la preuve dans le dépôt. X1 est la moitié « où reste la preuve ? » ; X2 est la moitié « comment se produit la preuve ? ».

hypothèse Critères qui pondèrent, encore sans poids. Je les laisse marqués comme hypothèse jusqu'à ce que je les calibre avec les premiers projets qui utiliseront la méthode de bout en bout.

Deux critères que j'avais dans les versions précédentes (que l'agent puisse tester seul, et que le projet soit nouveau ou auditable), je les ai absorbés dans X2 et X1 respectivement, parce que ce sont des conséquences et non des critères à part.

Étape 1 — Le contrat de collaboration (les règles avant le code)

Avant d'écrire une seule ligne, mettez par écrit comment vous et l'agent allez travailler. Cela ressemble à une formalité, et ce n'en est pas une : c'est ce qui évite quatre-vingts pour cent des frustrations du premier mois. Pensez que l'agent arrive chaque matin sans mémoire de la veille ; ce qui n'est pas écrit, vous allez devoir le lui répéter à chaque fois, et à chaque fois un peu différemment.

• Intention : fixer comment travaillent l'humain et l'agent avant la première ligne de code.
• Quand : une seule fois, immédiatement après l'éligibilité. On le révise quand un coup dur l'exige.
• Entrées : rien du projet ; c'est le premier fichier. De vous : vos préférences de travail.
• Artefact : un document de standards de qualité qui dise, au minimum : le temps de l'humain est sacré (on ne le dépense pas en choses que l'agent peut résoudre seul) ; zéro dette technique, c'est-à-dire que quand quelque chose casse on le répare à la racine et on ajoute la régression dans la même session ; le périmètre est exact, ni plus ni moins que ce qui a été demandé ; on parle la langue de l'utilisateur ; la documentation se met à jour dans le même commit ; et on n'annonce jamais comme fait quelque chose qui n'a pas été fait.
• Porte : le contrat est dans le dépôt et se lit à chaque session.
• Qui décide : le propriétaire. L'agent peut proposer des changements, mais il n'édite pas le contrat de son propre chef.
• Échec évité : l'agent qui « aide » en élargissant le périmètre parce que ça lui a semblé une bonne idée ; celui qui laisse de la dette « pour plus tard » (et le plus tard n'arrive jamais) ; et celui qui rapporte comme fait ce qu'il croit avoir fait. Je l'ai écrit pour la première fois quand cela faisait deux semaines que je répétais la même chose à chaque session Ref. 1.
• Contrat : peldanos/peldano-01-contrato-de-convivencia.md.

Étape 2 — La définition du projet et la lecture obligatoire

Chaque session de l'agent démarre de zéro. Donnez-lui une carte, courte, et obligez-le à la lire avant de toucher à quoi que ce soit. Les deux moitiés comptent autant l'une que l'autre : une carte que personne ne lit n'agit pas, et une carte longue, personne ne la lit.

• Intention : que chaque session démarre en sachant ce qu'est le projet, dans quel état il se trouve et quelles décisions ont déjà été prises.
• Quand : elle s'écrit une fois, après le contrat ; elle se maintient à jour pendant tout le projet, avec chaque nouvelle décision.
• Entrées : le contrat (échelon 1) et le relevé du métier.
• Artefact : un fichier de projet opérationnel, et ici j'insiste : COURT. C'est le programme, pas l'historique. Plus l'arbre sémantique du système (voir B.5) : domaines, acteurs, processus, entités avec leurs états, écrans et intégrations, avec les éléments en attente et les décisions accrochés à chaque nœud. Plus un fichier d'état vivant avec ce qui est en cours et les doutes ouverts.
• Porte : l'agent lit le fichier de projet et l'arbre sémantique avant de toucher au code, et on a prouvé qu'il les lit.
• Qui décide : le propriétaire définit ; l'agent le maintient à jour.
• Échec évité : deux, bien concrets. Du travail jetable pour ne pas avoir lu la carte Ref. 9. Et le fichier de projet qui grossit jusqu'à devenir illisible Ref. 41 : le fichier opérationnel et le livre de cas doivent être des fichiers distincts.
• Contrat : peldanos/peldano-02-definicion-y-lectura.md.

Étape 3 — Dimensionner avant de concevoir l'architecture

C'est l'échelon qu'il coûte le plus cher de sauter, et je le sais parce que je l'ai sauté. Les décisions structurelles se prennent avec des chiffres, et les chiffres primaires, c'est le métier qui les a, pas le modèle.

• Intention : que les décisions structurelles (quel moteur de base de données, si l'interface est synchrone ou asynchrone, combien de concurrence) se prennent avec des chiffres et non au goût.
• Quand : une fois, avant de monter le squelette ; on le refait si le métier change d'échelle. Une demi-page et une décision dans un petit projet.
• Entrées : un relevé de données de volumétrie fait avec le métier, par nature incomplet ; et un accès en lecture au système précédent s'il existe. Il y a des données que seul le métier possède et que le modèle ne peut pas inférer : c'est pourquoi le prompt exige de lui qu'il évalue si elles sont complètes et qu'il demande celles qui manquent, au lieu de les estimer avec un air assuré.
• Artefact : un registre de dimensionnement avec des options FIXES (trois ou quatre options concrètes) et celle qui a été choisie ; et les décisions « asymétriques » déclarées explicitement, par exemple « l'interface de persistance est asynchrone dès la première ligne même si le premier moteur est synchrone », parce que si vous vous trompez cela coûte peu et si vous ne le faites pas cela coûte une fortune.
• Porte : le dimensionnement est enregistré avant de monter le squelette.
• Qui décide : le propriétaire choisit parmi les options fixes ; l'agent les présente avec des chiffres.
• Échec évité : démarrer avec un stockage qui ne supporte pas la volumétrie et le découvrir quand changer l'interface coûte une étape entière de réingénierie Ref. 15.
• Contrat : peldanos/peldano-03-dimensionar.md.

Étape 4 — Le squelette avec ses portes

Avant que le système fasse quoi que ce soit d'utile, il doit démarrer, se tester et se déployer VIDE. Oui, vide. Parce que le chemin vers la production fait partie du produit, et la seule façon de savoir qu'il fonctionne est de le parcourir quand il n'y a encore rien à perdre. C'est l'échelon où se fait toute l'infrastructure initiale et la chaîne d'intégration et de déploiement, et c'est pour cela qu'il est le plus long du démarrage.

• Intention : avoir un système qui démarre, se teste et se déploie sans aucune fonctionnalité encore.
• Quand : une fois, à la fin du démarrage, après le dimensionnement et avant toute fonctionnalité. C'est la clôture du tronçon de démarrage.
• Entrées : le dimensionnement (échelon 3), le relevé des environnements, et les identifiants de l'endroit où l'on va déployer.
• Artefact : le squelette avec l'intégration continue au vert, la structure de tests montée avec un test de fumée, un déploiement vers un environnement de test qui fonctionne et qui a été lancé deux fois, et les portes du flux déclarées par écrit.
• Porte : le squelette est au vert, l'intégration continue tourne, et le déploiement vers l'environnement de test fonctionne avec zéro fonctionnalité. Le propriétaire a ouvert l'URL et vu l'écran vide.
• Qui décide : l'agent exécute ; le propriétaire approuve visuellement.
• Échec évité : découvrir le déploiement un mois après le démarrage et payer cinq éléments en attente d'affilée pour qu'il fonctionne, avec de la fonctionnalité en jeu Ref. 32.
• Contrat : peldanos/peldano-04-esqueleto.md.

Étape 5 — Le plan, ce sont les éléments en attente

Il y a ici une idée qui, une fois que vous l'avez saisie, ne vous lâche plus : il n'y a pas un « plan » d'un côté et une « liste de tâches » de l'autre. La liste des éléments en attente EST le plan. Et chaque élément en attente dit comment on le vérifie, parce que c'est cela que vous allez regarder au lieu de regarder le code.

• Intention : une file de travail unique, ordonnée et avec porte, qui soit la vérité du projet.
• Quand : elle se crée à l'ouverture du premier bloc fonctionnel, dès que le démarrage se termine ; elle s'utilise à chaque session pendant tout le projet. Chaque nouveau bloc commence par convertir la demande du client en éléments en attente.
• Entrées : la demande du client pour le bloc, les audits, et les constats des tests humains.
• Artefact : un registre d'éléments en attente numérotés, chacun avec sa spécification détaillée (voir B.5) : le nœud de l'arbre sémantique auquel il est accroché, le récit d'origine avec les mots du client, la description, les règles métier applicables, les données, les écrans, les cas limites, les critères d'acceptation et comment on vérifie. Et, à la clôture, la documentation de l'élément réalisé : la preuve, le commit, la date, ce qui a été décidé en chemin. Les éléments en attente clos sont l'historique fonctionnel du système.
• Porte : aucun changement n'entre sans élément en attente spécifié ; et l'élément se clôt avec une preuve documentée, pas avec un « c'est fait ».
• Qui décide : le propriétaire priorise ; l'agent propose et exécute dans l'ordre.
• Échec évité : la spécification qui « se fait dépasser » et devient obsolète en deux semaines Ref. 17 ; et le travail dont, six mois plus tard, personne ne sait pourquoi il a été fait Ref. 7.
• Contrat : peldanos/peldano-05-pendientes.md.

Étape 6 — Les décisions s'écrivent à côté du code

Le modèle, quand il trouve un trou dans les règles métier, le remplit. Il ne s'arrête pas pour demander ; il complète avec ce qui lui semble le plus probable, avec le même naturel que lorsqu'il écrit le reste. C'est pourquoi cet échelon n'est pas « écrivez les décisions » mais « exigez de lui qu'il freine et qu'il demande quand il en manque une », et quand vous décidez, la décision reste avec vos mots, votre nom et la date.

• Intention : que chaque règle de domaine ou décision structurelle ait un propriétaire, une date et un lieu.
• Quand : à chaque session de la boucle, chaque fois que l'agent bute sur une règle non écrite. Il y en a en général deux ou trois par bloc fonctionnel. Aussi au démarrage (échelons 0 et 3) et à la mise en production (14 et 15).
• Entrées : la conversation avec le propriétaire. C'est le seul intrant.
• Artefact : la décision écrite dans le commit et dans un registre des décisions, avec les mots textuels. Si le propriétaire n'a pas répondu et que l'agent a dû choisir, elle reste marquée « décision par omission » pour être révisée.
• Porte : une règle métier n'entre pas dans le code sans sa phrase d'origine.
• Qui décide : le propriétaire. Toujours. Sans exception.
• Échec évité : discuter six semaines plus tard de pourquoi quelque chose est ainsi ; et, pire, l'agent qui invente des règles de domaine parce qu'elles lui ont semblé raisonnables. La pratique d'écrire la règle dans le commit avec la date et le propriétaire vient de la Mutuelle Ref. 29, et celle de geler les décisions avant de construire, de mon outil Ref. 5.
• Contrat : peldanos/peldano-06-decisiones.md.

Étape 7 — Mesurer avant de construire, avec un instrument lui-même vérifié

C'est, pour moi, l'échelon le plus adulte de tous, et celui que j'ai mis le plus de temps à formaliser parce que je tenais pour acquis qu'un modèle l'appliquerait seul. Il ne l'applique pas. La règle est : aucun chiffre qui décide de quelque chose ne sort d'une impression ; il sort d'un compteur qui vit dans le dépôt, qui a un test, et que vous pouvez lancer. Et le compteur aussi se vérifie, parce que les compteurs mentent.

• Intention : que tout chiffre qui alimente une décision sorte d'un instrument avec test, et que l'instrument lui-même soit audité.
• Quand : dans la boucle, chaque fois qu'un élément en attente dépend d'un chiffre ou d'une hypothèse de cause, AVANT de construire. Au démarrage, le dimensionnement est le premier cas. Dans un petit projet, « mesurer » c'est compter avec une commande et noter le chiffre avec la date.
• Entrées : l'hypothèse, du propriétaire ou de l'agent, et l'accès à ce qu'on veut mesurer.
• Artefact : le compteur gardé dans le dépôt ; le chiffre avec sa commande et sa date ; l'audit dans les deux directions ; l'approximatif marqué ; et, le cas échéant, un budget par chemin resserré sur ce qui a été mesuré et protégé par un test.
• Porte : les cinq règles : compteur gardé ; si l'instrument n'existe pas on le construit ; on l'audite dans les deux directions ; l'approximatif se marque ; et celui qui exécute vérifie les chiffres de celui qui a planifié.
• Qui décide : le chiffre. Le propriétaire apporte l'hypothèse ; l'agent la mesure avant de construire.
• Échec évité : les compteurs qui mentaient et le plan avec trois chiffres faux sur quatre Ref. 36 ; le cliquet à zéro qui ne voyait pas 84 appels Ref. 35. Les règles, c'est moi qui les ai écrites, en session, avant qu'elles ne deviennent doctrine Ref. 45.
• Contrat : peldanos/peldano-07-medir.md.

Étape 8 — Les tests comme verrous, prouvés en rouge

Un test que vous n'avez jamais vu échouer, vous ne savez pas s'il prouve quelque chose. C'est pourquoi ici la règle n'est pas « écrivez des tests » ; c'est « démontrez que le test passe au rouge contre l'ancien code, puis au vert, puis que la régression reste au vert ». Et les tests de bout en bout, de l'écran jusqu'au backend, sont ceux qui remplacent votre lecture du code.

• Intention : que chaque comportement qui compte ait un test qui ÉCHOUE s'il casse, et qu'on sache avec certitude qu'il échoue.
• Quand : avec chaque élément en attente de la boucle, à sa clôture. Le test de bout en bout du flux touché, dans la même clôture. La batterie complète de bout en bout, à la clôture de chaque bloc et avant chaque déploiement en production.
• Entrées : le changement déjà implémenté et l'élément en attente avec son « comment on vérifie ».
• Artefact : le nouveau test, la sortie en rouge comme reçu (la commande, la version contre laquelle il a tourné, les chiffres, le code de sortie : ce qu'il faut pour le relancer avec une commande), la sortie en vert avec des chiffres, la régression des voisins dans la même session, et le commit qui dit contre quoi on a prouvé le rouge.
• Porte : rouge démontré avec reçu, vert, régression au vert. Et l'agent ne simule pas précisément la partie qu'il veut tester.
• Qui décide : l'agent exécute et rapporte ; le propriétaire lit le rapport, pas le test.
• Échec évité : les tests qui passent parce qu'ils ne prouvent rien, et le vert qui cache un bug Ref. 44. Le cas des compteurs est l'exemple complet d'un test prouvé en rouge contre l'ancien critère Ref. 26.
• Rouge du premier bloc : quand la version précédente n'a pas le module, le rouge se prouve par mutation (un défaut planté, le test en rouge, le diff dans le reçu), pas avec un fichier qui ne se charge pas.
• Contrat : peldanos/peldano-08-tests-en-rojo.md.

Étape 9 — Qualité du code vérifiée par machine, avec une porte

Le propriétaire ne lit pas le code, et c'est tout l'intérêt. Mais quelqu'un va maintenir ce code, et un code qui marche aujourd'hui et qui sera illisible demain est une dette qui se paie au troisième mois. Si personne ne le lit, c'est une machine qui doit le regarder : à chaque commit, ce qu'un relecteur humain regarderait, converti en un chiffre avec une limite. Je l'ai fait dans tous mes projets sans le nommer comme un échelon.

• Intention : que la qualité du code se vérifie par machine à chaque commit, avec la construction au rouge comme conséquence, et qu'elle ne se dégrade jamais toute seule.
• Quand : elle se monte à l'ouverture du premier bloc fonctionnel et tourne à chaque push ; chaque élément en attente se clos avec la qualité au vert, après le test en rouge (8) ; le rapport se lit avec le propriétaire à la clôture de chaque bloc. Dans un système hérité, la première exécution est la ligne de base.
• Entrées : l'intégration continue (4), le code d'au moins un élément en attente clos, et les limites décidées par le propriétaire (taille de fichier et de fonction, pour commencer).
• Artefact : linter et formateur avec une seule configuration ; limites de taille et de complexité ; détection de duplication et de code mort ; couverture avec cliquet ; types si le langage le permet ; docs/CODE_QUALITY.md avec chaque limite et sa valeur mesurée ; la porte dans docs/GATES.md. Obligatoires dans tout projet qui a des utilisateurs, optionnels seulement sans utilisateurs réels, les tests de mutation (des erreurs plantées exprès, comptées d'après combien les tests en attrapent), avec leur score par bloc à côté de la couverture.
• Porte : rien n'est fusionné avec la qualité au rouge ; aucune exception au linter sans raison écrite ; aucune limite relevée pour passer.
• Qui décide : le propriétaire fixe les limites et décide ce qui se corrige maintenant et ce qui se tolère avec une date ; l'agent mesure et corrige dans le même commit.
• Échec évité : le composant de plus de deux mille lignes et le fichier de presque dix mille qu'un audit a trouvés parce qu'aucune limite ne les avait arrêtés Ref. 41 ; le chiffre de qualité qui empire sans que personne ne le voie Ref. 35.
• Contrat : peldanos/peldano-09-calidad-de-codigo.md.

Étape 10 — Les cas de test manuel s'écrivent avec la fonctionnalité, et ce sont des personnes qui les exécutent

Les tests automatiques, c'est le modèle qui les écrit et les lance, et ils testent ce que le modèle a compris. Il manque le test que fait une personne avec ses yeux et ses mains, en suivant un scénario. Le scénario est écrit par celui-là même qui a construit la fonctionnalité, au même moment, à partir des critères d'acceptation ; des personnes l'exécutent à la clôture de chaque bloc, à l'acceptation et après chaque déploiement ; et ce qui échoue revient dans la boucle comme exigence. C'est la fermeture du circuit que montre le graphique du procédé.

• Intention : que toute fonctionnalité naisse avec son cas de test manuel, écrit pour une personne qui ne sait pas comment le système est fait, et que chaque exécution humaine réinjecte ce qui échoue comme élément en attente.
• Quand : avec chaque élément en attente, à sa clôture, après le test en rouge (8) et la qualité (9). Exécution par des personnes à la clôture de chaque bloc, avant le premier déploiement (acceptation) et après chaque déploiement, en lecture seule.
• Entrées : les critères d'acceptation de l'élément en attente (5), l'environnement de test avec des données, et la décision de qui exécute et quand.
• Artefact : docs/MANUAL_TESTS.md avec un cas par flux touché (identifiant, élément en attente, précondition, étapes avec ce qu'on fait et ce qu'on voit, résultat attendu avec l'effet côté backend vérifiable par une personne, données, tableau des exécutions) ; les exécutions enregistrées ; un élément en attente correctif par échec.
• Porte : aucun élément en attente qui touche un écran ne se clos sans son cas ; aucune exécution sans date et sans nom ; aucun échec sans élément en attente avec les mots de la personne.
• Qui décide : le propriétaire ou un utilisateur de confiance exécute ; l'agent écrit les cas et ouvre les éléments en attente ; le modèle ne marque jamais un cas comme exécuté.
• Échec évité : le test humain sans scénario qui trouve des choses différentes à chaque fois, et la trouvaille humaine qui se corrige sur le moment et se perd ; le menu déroulant incommode qu'aucun test n'a vu et que la responsable, elle, a vu, dans le projet-guide du cours.
• Contrat : peldanos/peldano-10-casos-de-prueba-manual.md.

Étape 11 — Symétrie entre producteur et consommateur, et le registre des anti-patrons

Quand vous changez un bout (le serveur, la base, un robot), l'autre bout (l'écran, un compteur, un rapport) doit changer dans le même commit. Le principe qui soutient cela est que toute liste a un seul propriétaire. Et les erreurs que vous avez déjà payées une fois se notent avec leur vérification automatique, pour ne pas les payer deux fois.

• Intention : qu'un changement à un bout entraîne l'autre, toujours, dans le même commit.
• Quand : avec chaque élément en attente qui touche un contrat entre deux parties du système ; la carte des contrats se construit à l'ouverture du deuxième bloc fonctionnel, quand il y a déjà un écran et un serveur ; le registre des anti-patrons grandit chaque fois que quelque chose casse pour la deuxième fois.
• Entrées : la carte de qui produit et qui consomme chaque contrat ; le registre des anti-patrons.
• Artefact : le serveur définit la liste et le consommateur la lit ; la carte producteur/consommateur ; le registre des anti-patrons avec odeur, cause racine, correctif et détection précoce.
• Porte : automatique : l'agent cherche l'autre côté avant de considérer un changement comme clos.
• Qui décide : personne ; c'est automatique.
• Échec évité : le compteur qui ne coïncide pas avec la requête Ref. 26 ; deux copies du même module qui se désynchronisent Ref. 41. La solution de la source unique, je l'ai imposée à la Mutuelle Ref. 27.
• Contrat : peldanos/peldano-11-simetria-y-antipatrones.md.

Étape 12 — Vérification honnête et rapport proportionné

Si vous n'allez pas lire le code, le rapport de l'agent doit être fiable, et cela n'arrive pas tout seul. Le modèle a été entraîné pour être utile et complet, et un rapport qui dit « ceci, je n'ai pas pu le vérifier » semble moins utile qu'un rapport qui dit « c'est fait ». Alors exigez de lui explicitement les mauvaises nouvelles, les angles morts et ce qu'il n'a pas fait.

• Intention : que le rapport de l'agent soit fiable sans que le propriétaire lise du code.
• Quand : à chaque rapport, de chaque élément en attente, pendant tout le projet. C'est la forme que doit avoir tout ce que l'agent vous dit.
• Entrées : le travail réalisé et l'élément en attente qui le demandait.
• Artefact : un rapport en trois blocs : vérifié (avec la preuve à côté), cru (et pourquoi on ne l'a pas testé), angles morts (ce qu'il ne peut pas voir d'où il est). Il couvre chaque point demandé. Les mauvaises nouvelles d'abord.
• Porte : aucune affirmation sans sa preuve. « C'est fait » ne se dit pas tout court. Devant un « c'est toujours cassé », on compare d'abord la version publiée avec celle qui contient le correctif.
• Qui décide : le propriétaire fait confiance, ou demande la preuve. Il ne relit jamais de code.
• Échec évité : l'erreur rapportée comme succès et les rapports qui déclaraient vérifié ce qui ne l'était pas Ref. 43 ; le tour qui a travaillé invisible pendant une heure quarante-trois Ref. 16. La règle d'honnêteté de vérification, je l'ai écrite en juin Ref. 8.
• Contrat : peldanos/peldano-12-verificacion-honesta.md.

Étape 13 — L'audit périodique comme intrant du plan

De temps en temps il faut regarder le système entier avec des yeux neufs, et ce qu'on y voit ne va pas dans un rapport qu'on archive : il va dans la file des éléments en attente. La partie importante est « des yeux neufs » : que ce soit quelqu'un qui n'a pas construit qui audite, parce que celui qui a construit partage ses propres présupposés. Une autre session du modèle, avec un autre fichier d'instructions, suffit.

• Intention : regarder le système complet de temps en temps et convertir ce qu'on voit en éléments en attente.
• Quand : obligatoire avant le premier déploiement en production (il ouvre le tronçon de mise en production). En exploitation, tous les un ou deux mois selon le rythme de changement, et à la clôture de chaque grande étape.
• Entrées : le dépôt entier et la production en lecture seule.
• Artefact : un rapport avec des constats gradués, chacun avec son emplacement, son risque, sa preuve et sa priorité ; des notes par dimension ; et les constats urgents déjà convertis en éléments en attente.
• Porte : chaque constat urgent a un élément en attente ouvert avant de considérer l'audit comme clos.
• Qui décide : le propriétaire priorise les constats.
• Échec évité : des requêtes qui lisent des tables entières Ref. 18 ; deux portes d'administrateur que personne n'avait vues jusqu'à ce qu'un autre les regarde Ref. 40 ; une vulnérabilité connue et un composant énorme Ref. 41.
• Contrat : peldanos/peldano-13-auditoria.md.

Étape 14 — Fail-closed, verrous et zéro dommage silencieux

Dans le doute ou en cas d'échec, le système N'AGIT PAS. Et il le dit. Cela semble évident, mais c'est le contraire de ce que fait le logiciel par défaut, qui, dans le doute, continue. Cet échelon vient avant de construire les fonctionnalités qui agissent sur le monde, pas après.

• Intention : que le système, devant un doute ou un échec, n'agisse pas, et prévienne.
• Quand : dans le tronçon de mise en production, avant de construire toute fonctionnalité qui facture, envoie, approuve ou supprime ; on le révise à chaque nouvelle action à conséquences. Les nouvelles automatisations démarrent en mode à blanc et s'activent après avoir regardé leur journal pendant quelques jours.
• Entrées : le relevé des actions à conséquences, fait avec le propriétaire.
• Artefact : la table des verrous : chaque action avec sa réversibilité, son verrou, son chemin de retour ; un test par verrou prouvé en rouge ; les nouvelles automatisations en mode à blanc.
• Porte : toute action irréversible a un verrou et un chemin de retour documenté.
• Qui décide : le propriétaire approuve verrou par verrou ; le système ne les contourne jamais.
• Échec évité : une double facturation, une approbation automatique sans passer par un humain, la suppression de données du client. Les verrous de la Mutuelle sont le modèle Ref. 28 ; le réflexe de ne pas casser le listing entier, aussi Ref. 25.
• Contrat : peldanos/peldano-14-fail-closed.md.

Étape 15 — Intégration continue, environnements, secrets et déploiement comme partie du produit

Arriver en production doit être un paquet reproductible : les tests tournent UNE fois, le déploiement ne fait qu'empaqueter et téléverser, la configuration vit sur le serveur et non dans le dépôt, et le retour arrière est éprouvé. Une bonne partie de cela existe déjà depuis le squelette ; cet échelon le complète vers la production.

• Intention : qu'arriver en production soit un paquet reproductible, avec les tests lancés une seule fois et la configuration hors du dépôt.
• Quand : la chaîne d'intégration et le déploiement vers l'environnement de test se montent à l'échelon 4. La clôture vers la production — environnement réel, secrets, promotion, retour arrière éprouvé, verrou contre les secrets — se fait dans le tronçon de mise en production, après l'audit et les verrous. La routine de chaque déploiement s'applique pendant toute l'exploitation.
• Entrées : le relevé des environnements et des accès ; le squelette avec son intégration.
• Artefact : l'intégration continue qui lance la batterie une fois par commit ; le déploiement qui attend ce résultat et ne fait qu'empaqueter ; la configuration uniquement sur le serveur ; la procédure de promotion écrite et répétable ; le retour arrière éprouvé ; la vérification qui empêche de pousser un secret.
• Porte : test au vert avec la même version avant de toucher à la production ; retour arrière éprouvé ; aucun secret dans le dépôt ni dans le chat sans rotation.
• Qui décide : le propriétaire promeut en production ; l'agent prépare tout.
• Échec évité : les tests lancés trois fois par commit et le quota brûlé Ref. 39 ; le déploiement durci à coups d'éléments en attente pour l'avoir découvert tard Ref. 32 ; des secrets collés dans le chat Ref. 42.
• Contrat : peldanos/peldano-15-ci-entornos-secretos-deploy.md.

Étape 16 — Observabilité et traçabilité totales, avec un niveau configurable

Quand quelque chose cassera en production, je veux suivre une action depuis l'écran jusqu'à la base de données avec un seul identifiant, sans ouvrir le code ; je veux pouvoir monter le détail des journaux en production en une minute, sans redéployer ; et je veux que toute action à conséquence laisse une trace que l'application ne puisse pas effacer.

• Intention : que le système puisse se voir pendant qu'il tourne (observabilité) et que chaque action importante ait sa trace (traçabilité), avec un niveau de détail qui se change par configuration.
• Quand : dans la mise en production, après le 15 et avant le 19. Dans un système hérité, le niveau minimum entre dans la ceinture de sécurité (N4) et le niveau complet ici. La règle « tout nouveau module journalise et propage » vaut pendant toute l'exploitation.
• Entrées : la configuration par environnement (15), la table des verrous (14), la liste des données personnelles du relevé, et la décision sur l'endroit où vivent les journaux.
• Artefact : des journaux structurés avec un niveau configurable sans déployer ; un identifiant de corrélation dans chaque enregistrement, de l'écran à la base ; un audit immuable des actions à conséquence ; des points de santé et de métriques ; docs/OBSERVABILITY.md.
• Porte : un identifiant réel suivi à travers toutes les couches ; le niveau changé sans déployer ; aucune donnée personnelle dans les journaux.
• Qui décide : le propriétaire décide où vivent les journaux, combien de temps on les conserve et ce qu'est une donnée personnelle ; l'agent monte le dispositif.
• Échec évité : le processus qui a continué de vivre une heure quarante-trois et qu'on a trouvé par le journal Ref. 16 ; l'agent résident qui travaille en aveugle s'il n'y a pas de journaux à lire Ref. 13.
• Contrat : peldanos/peldano-16-observabilidad-y-trazabilidad.md.

Étape 17 — Optimisation de la couche de persistance, mesurée avant et après

La base de données est l'endroit où les systèmes meurent lentement : bien avec cent enregistrements, mal avec cent mille, et personne ne sait quand ça a commencé. Ici cela se décide avec des chiffres, avant la production, et avec la méthode de l'échelon 7 : mesurer, changer, remesurer sur les mêmes données.

• Intention : que les requêtes réelles du système, aux volumes du dimensionnement, entrent dans ce que le métier tolère, avec des budgets qui empêchent qu'elles en ressortent.
• Quand : dans la mise en production, après le 16 et avant le 19 ; se répète quand un bloc ajoute une grande table ou que la supervision (21) montre une requête hors plage. Dans un système hérité, les mesures sortent de N6 et presque tout se paie « quand on y touche ».
• Entrées : le dimensionnement (3 ou N6), la carte producteur-consommateur (11), l'observabilité (16), et l'environnement de test chargé au volume attendu.
• Artefact : des compteurs de requêtes avec test ; docs/PERSISTENCE.md avec la table de l'avant et de l'après par changement, les budgets par chemin et la rétention par table ; un test par budget.
• Porte : aucune requête qui lise une table entière dans un flux critique ; chaque budget avec son test ; l'écran le plus lent dans ce que le dimensionnement attendait.
• Qui décide : le propriétaire approuve la liste des changements, un par un ; l'agent mesure et applique.
• Échec évité : les requêtes qui lisaient des tables entières dans un système vivant Ref. 18 ; le budget qu'il a fallu resserrer à ce qui avait été mesuré Ref. 37 ; les millions de lignes sur des fichiers Ref. 15.
• Contrat : peldanos/peldano-17-persistencia.md.

Étape 18 — Scan et résolution des vulnérabilités, dans la chaîne et avec un calendrier

L'audit (13) regarde le système entier avec discernement, de temps en temps ; cet échelon regarde une seule chose, la sécurité, tout le temps et par machine : dépendances, code, secrets dans l'historique et configuration du serveur. Et une règle : une mise à jour de dépendance est un changement, et elle entre par la boucle.

• Intention : qu'aucune vulnérabilité connue n'arrive en production, et que les nouvelles se détectent toutes seules même si personne ne touche au système.
• Quand : dans la mise en production, après le 15 et avant le premier déploiement ; ensuite, à chaque push et avec un calendrier hebdomadaire. Dans un système hérité, la première passe fait partie de N3.
• Entrées : l'intégration continue (4 et 15), le relevé des environnements, l'audit précédent, et le critère du propriétaire sur ce qui est urgent.
• Artefact : le scan en quatre couches qui tourne dans la chaîne et avec un calendrier ; docs/SECURITY_[date].md avec les constats et ce qui n'a pas été scanné ; docs/SECURITY.md avec la politique ; la porte dans docs/GATES.md ; les P0 et P1 corrigés avec leur élément en attente.
• Porte : aucun P0 ouvert n'est promu en production ; un nouveau P1 ouvre un élément en attente tout seul.
• Qui décide : le propriétaire définit ce qu'est un P0 et approuve les corrections ; l'agent monte le dispositif et le lance.
• Échec évité : la vulnérabilité connue qui est apparue dans l'audit de qualité Ref. 41 ; les portes d'administrateur que seule une autre session a vues Ref. 40 ; la sécurité traitée comme une liste que l'on coche une fois Ref. 23.
• Contrat : peldanos/peldano-18-vulnerabilidades.md.

Étape 19 — Tests de performance en volume et point de rupture

L'échelon 3 a dimensionné avec des calculs ; celui-ci vérifie les calculs avec le système qui tourne : au volume attendu, au « fois dix », et jusqu'à ce que quelque chose casse. Le point de rupture est le chiffre le plus utile du tronçon, parce que c'est de lui que sortent les seuils d'alerte du 21.

• Intention : savoir comment se comporte le système au volume attendu, au « fois dix », et où et pourquoi il casse, avant que le premier utilisateur n'entre.
• Quand : dans la mise en production, après le 16 et le 17, avant le premier déploiement ; se répète avant chaque déploiement qui change l'architecture, la persistance ou un flux critique. Dans un système hérité, avec les volumes mesurés en N6.
• Entrées : le dimensionnement, l'observabilité allumée, la persistance optimisée, les flux critiques et la tolérance du métier pour l'écran le plus utilisé.
• Artefact : le script de charge dans le dépôt, avec test ; docs/PERFORMANCE_[date].md avec les trois passes, le point de rupture et le diagnostic ; docs/PERFORMANCE.md avec les seuils et la porte ; un élément en attente par goulot d'étranglement.
• Porte : l'écran le plus utilisé dans la tolérance au volume attendu, ou un élément en attente avec le chiffre ; le point de rupture écrit avec ce qui casse.
• Qui décide : le propriétaire donne la tolérance et décide jusqu'à quel volume les goulots d'étranglement se corrigent maintenant.
• Échec évité : la charge réelle que l'on n'a connue qu'en regardant la production Ref. 12 ; le point de rupture qui s'est déguisé en test raté Ref. 44 ; le dimensionnement comme porte Ref. 14.
• Contrat : peldanos/peldano-19-rendimiento-y-punto-de-ruptura.md.

Étape 20 — Documentation vivante et manuels qu'une personne peut suivre sans IA

Le système doit pouvoir s'utiliser, se maintenir et se rétablir sans l'agent et sans vous. Si le jour où il n'y a pas d'agent on ne peut pas déployer, il n'est pas terminé. Et comme régénérer la documentation avec un modèle est gratuit, la règle devient « dans le même commit ».

• Intention : que le système puisse s'utiliser, se maintenir et se rétablir sans l'agent et sans le constructeur.
• Quand : le manuel utilisateur grandit avec chaque bloc fonctionnel, à sa clôture, avec les nouveaux écrans. Les trois manuels complets se génèrent dans le tronçon de mise en production, après le 15, et le test avec une personne qui ne programme pas se fait avant le premier déploiement. La routine du même commit s'applique pendant toute l'exploitation.
• Entrées : le système qui tourne dans l'environnement de test ; les artefacts du 14 et du 15.
• Artefact : le manuel utilisateur avec des captures réelles, celui de maintenance, et celui d'infrastructure et de reprise écrit pour une personne qui doit le faire à la main à trois heures du matin ; chacun avec date et version.
• Porte : la documentation est à jour dans le même commit ; quelqu'un qui ne programme pas a suivi le manuel de reprise.
• Qui décide : l'agent maintient ; le propriétaire lit le manuel, pas le code.
• Échec évité : le document périmé qui a provoqué un commit dans le mauvais dépôt ; le fichier de projet transformé en historique Ref. 41. Les manuels reproductibles à la main sont ceux de la Mutuelle Ref. 24.
• Contrat : peldanos/peldano-20-documentacion-viva.md.

Étape 21 — Supervision des ressources, des fonctions et des requêtes hors plage, avec rapport cyclique

Les tests du 19 disent comment se comporte le système un jour ; la production, c'est tous les jours, avec les données qui grandissent. Cet échelon surveille l'usage des ressources et le temps de réponse de chaque fonction et de chaque requête par rapport aux seuils du 19 et à sa propre histoire, prévient quand quelque chose sort de la plage, et produit un rapport cyclique que l'on lit avec le propriétaire. Chaque écart est un élément en attente.

• Intention : voir un problème de ressources ou de performance avant que l'utilisateur ne le voie, et que chaque écart ait une cause ou un élément en attente.
• Quand : elle se monte avec le premier déploiement en production ; à partir de là elle tourne seule, et le rapport se lit à chaque cycle (hebdomadaire avec des conséquences, mensuel dans un petit projet). Dans un système hérité, la première lecture est la ligne de base.
• Entrées : les métriques du 16, les budgets du 17, les seuils du 19, la production en lecture seule, et le canal et le cycle décidés avec le propriétaire.
• Artefact : une collecte avec historique ; des alertes par seuil et par écart ; le rapport cyclique généré tout seul ; docs/MONITORING.md ; la routine de lecture dans le contrat.
• Porte : une alerte provoquée est arrivée au canal ; le premier rapport a chaque écart avec sa cause ou sa proposition ; aucun seuil n'a monté sans raison écrite.
• Qui décide : le propriétaire décide le canal, le cycle et quel écart se traite maintenant ; l'agent monte et propose.
• Échec évité : le plafond qu'il a fallu resserrer à ce qui avait été mesuré Ref. 37 ; le quota qui a fondu sans que personne ne regarde Ref. 39.
• Fenêtre vérifiable : la mesure cyclique porte le premier et le dernier enregistrement lus dans la base ; une fenêtre saisie à la main est marquée comme telle et ne fait qu'avertir.
• Contrat : peldanos/peldano-21-monitoreo-de-recursos-y-rendimiento.md.

Étape 22 — Supervision des erreurs et rapport cyclique : aucune erreur sans élément en attente

Un système en production produit des erreurs que personne ne signale. Cet échelon les capture dans les trois endroits où elles se cachent (le backend, les tâches, le navigateur de l'utilisateur), les regroupe, prévient de celles qui sont nouvelles et de celles qui croissent, et produit un rapport cyclique. Deux règles : aucune erreur sans élément en attente, et l'« erreur connue » n'existe pas sans un élément en attente qui dise pourquoi on la tolère et jusqu'à quand.

• Intention : qu'aucune erreur en production ne passe inaperçue, et que chacune se close avec le test qui la reproduit en rouge.
• Quand : elle se monte avec le premier déploiement, avec le 21 ; à partir de là elle tourne seule, avec des alertes sur le moment et un rapport cyclique. Dans un système hérité, les erreurs qui existaient déjà le premier jour deviennent des éléments en attente avec leur marque de vitesse.
• Entrées : les journaux du 16, la table des verrous (14), la production avec le navigateur inclus, le canal et le cycle du 21.
• Artefact : une capture centralisée et regroupée, sans données personnelles ; des alertes par erreur nouvelle, récurrente qui croît et à conséquence ; le rapport cyclique avec le taux d'erreur par flux ; docs/MONITORING.md ; la routine dans le contrat.
• Porte : une erreur provoquée dans le navigateur suivie jusqu'au rapport ; aucune erreur récurrente sans élément en attente ni raison datée.
• Qui décide : le propriétaire lit le rapport et décide ce qui se traite ; l'agent capture, regroupe et propose.
• Échec évité : l'erreur d'authentification rapportée comme un succès Ref. 43 ; les quatre tours jusqu'à la cause racine faute d'avoir l'erreur reproduite Ref. 22.
• Source de l'erreur : les erreurs des outils qui observent le système vont à part, dans leur propre section du rapport, et n'ouvrent pas d'éléments en attente.
• Contrat : peldanos/peldano-22-monitoreo-de-errores.md.

Étape 23 — L'agent dans le système, et la rétrospective chiffrée

Le dernier échelon a deux parties qui ferment le même cycle. D'abord : l'agent reste résident en production, avec un périmètre borné, agissant au nom d'une personne. Ensuite : la méthode elle-même se révise avec des chiffres, et ce qu'on apprend revient à l'échelon 0 pour le projet suivant.

• Intention : que l'agent reste résident en production avec un périmètre borné, et que la méthode se révise avec des chiffres.
• Quand : l'agent résident, à l'entrée en exploitation, après le premier déploiement en production. La rétrospective, à la clôture de chaque étape et du projet ; elle est obligatoire même si elle tient en une page.
• Entrées : le système en production, les incidents, les coûts.
• Artefact : le document de l'agent résident avec sa carte du système, son périmètre, son identifiant au nom d'une personne et la preuve que ce qui est hors périmètre est rejeté ; et la rétrospective avec des chiffres sourcés, chaque incident rapporté à un échelon, et au moins une proposition concrète de changement de l'échelle.
• Porte : l'agent ne peut pas faire ce que le propriétaire n'a pas approuvé ; la rétrospective produit au moins un changement de l'échelle.
• Qui décide : le propriétaire.
• Échec évité : l'agent qui opère sans carte ; et la méthode qui se répète à l'identique projet après projet sans apprendre. La rétrospective chiffrée qui a tué l'équipe multi-agents est le modèle Ref. 6 ; l'agent résident, celui de la Mutuelle Ref. 13.
• Contrat : peldanos/peldano-23-agente-residente-y-retrospectiva.md.

Partie D — Comment s'exécute, combien on exige, et avec quel outil

Comment s'exécute chaque échelon : le contrat

La fiche en huit parties dit ce que cherche chaque échelon, quand on le gravit et ce qu'il laisse. Mais un échelon ne se comprend pleinement que lorsqu'on voit comment on le demande, ce qui doit revenir et comment je sais que c'est revenu complet. C'est pourquoi chaque échelon a, en plus de la fiche, un contrat dans un fichier propre dans peldanos/, toujours avec les mêmes cinq sections :

1. Contexte requis, nommé de façon générique (« relevé de données de volumétrie », « accès en lecture au système précédent », « la liste des actions à conséquence réelle »), sans descendre dans le détail de l'ingénierie des systèmes. Les relevés sont par nature incomplets ; je n'essaie pas de les rendre complets avec un formulaire.
2. Prompts, ceux qu'on donne au modèle, textuels. Celui d'ouverture et, quand l'échelon est une conversation, celui de clôture. Tous portent la même clause, qui est le cœur de l'affaire : le modèle évalue si le contexte suffit ; s'il ne suffit pas, il demande tout ce qui manque avant de continuer ; et il n'estime ni n'invente une donnée que seul le métier possède. Celui qui sait ce qui lui manque pour calculer, c'est le modèle, pas un formulaire. Et chaque prompt vient précédé d'un bloc qui dit « Avant d'envoyer le prompt » : les fichiers et les intrants que vous (ou le métier avec vous) devez avoir construits avant de le coller, avec leur nom, leur contenu et l'état minimum acceptable. Le prompt les nomme, le bloc vous dit comment ils doivent être faits ; sans ce bloc, le prompt mentionne des fichiers que personne ne vous a dit comment écrire.
3. Résultat attendu : les caractéristiques détaillées de l'artefact.
4. Vérification de complétude : la liste des contrôles que fait le propriétaire sur l'artefact, sans lire de code. Si l'un d'eux donne « non », l'échelon n'est pas gravi.
5. Signaux d'alarme : deux ou trois symptômes que l'échelon a été mal gravi même s'il paraît l'être.

Et dans l'en-tête de chaque contrat : le tronçon, le quand, la forme et la taille (s'il est obligatoire dans tout projet ou proportionnel).

Les prompts sont en anglais, et chacun vient avec sa traduction. C'est une décision que j'ai prise pour trois raisons : le même contenu en espagnol occupe entre 30 et 50 % de tokens en plus ; la capacité des modèles à suivre des instructions est mieux calibrée en anglais, de sorte qu'un prompt en anglais tolère mieux la brièveté sans devenir ambigu ; et le vocabulaire du métier (test, commit, rollback, mock) est anglais. Mais je ne veux pas que l'anglais soit une barrière pour lire la méthode : sous chaque prompt vient l'explication de ce que je demande et de pourquoi chaque clause est là, et dans la version HTML il y a un bouton qui montre le prompt traduit dans la langue du document. Le prompt qu'on colle au modèle est l'anglais ; la traduction est là pour que vous le compreniez. Et tous se terminent par « Reply in my language », parce que le prompt est en anglais mais la conversation n'a aucune raison de l'être.

Ce qui est obligatoire et ce qui est proportionnel, selon la taille du projet

Une question qui surgit tout de suite : « tout cela pour un petit système ? ». La réponse est que vingt-quatre échelons ne font pas vingt-quatre longues étapes ; plusieurs se gravissent en une seule session, et ceux qui sont proportionnels rétrécissent avec le projet. Ce qui ne rétrécit pas, c'est la liste de ceux qui ne se négocient pas. Cette table est une proposition hypothèse à confirmer avec le premier projet qui utilisera la méthode de bout en bout :

En résumé : il y a treize échelons qui ne se négocient dans aucun projet (0, 1, 2, 3, 5, 6, 8, 9 dans son minimum, 10, 12, le scan de dépendances du 18, la capture d'erreurs du 22 et la rétrospective du 23), et onze qui se dimensionnent avec le projet.

Comment l'utiliser avec n'importe quel outil

La méthode est neutre vis-à-vis de l'outil ; ce qui change de l'un à l'autre, c'est où l'on met chaque artefact pour que le modèle le lise. La correspondance, pour les outils les plus utilisés fin 2026 :

La colonne Forge est celle qui automatise le plus ; les trois autres fonctionnent tout aussi bien si le propriétaire fait à la main ce que Forge fait tout seul : coller le prompt de l'échelon au bon moment et exiger la vérification de complétude avant de passer au suivant. C'est, de fait, la pratique du cours.

Partie E — Ce qu'il reste à élaborer

1. L'échelon 0 complet : les poids des critères qui pondèrent, le seuil, et davantage de projets refusés comme contre-exemples. J'ai X1 et X2 ; il manque le reste.
2. Un nom mémorable pour chaque échelon, en une phrase, pour les manuels et les publications.
3. L'export vers Forge, largement résolu. La méthode tourne entièrement comme flux de projet dans Forge, avec des portes mécaniques et le prompt de l'échelon en cours injecté dans le chat (D-035, D-036). Ce qui manque, c'est la matrice explicite, contrat par contrat, face à ce que Forge exécute aujourd'hui, pour qu'une divergence entre ce que dit ce document et ce que fait l'outil se remarque dès qu'elle apparaît, au lieu de s'accumuler.
4. Tester les contrats de bout en bout, déjà en cours. Le projet guide du cours (Turnera) a fait tourner les vingt-quatre contrats tels qu'écrits et en a clos 24 sur 24 ; ce qu'il a trouvé en chemin a déjà corrigé la méthode (D-037 à D-040). Ce qui manque n'est pas le premier passage complet, qui a déjà eu lieu : c'est qu'un projet d'autrui le fasse tourner, sans que je sois à côté à résoudre ce que le contrat n'avait pas prévu.
5. La première cohorte du cours, qui va corriger l'ordre de la ligne de temps là où il le faut et les erreurs typiques, qui sont aujourd'hui écrites depuis mes projets et non depuis des élèves.
6. Le chemin évolutif-correctif, éprouvé sur un projet à moi, pas sur celui de quelqu'un d'autre. Le projet guide hérité du cours (Turnera héritée) a fait tourner les huit stations et le reste de l'échelle telle qu'écrite, en a clos 27 sur 27, et a motivé trois décisions de la méthode (D-038, D-039, D-040). Ce qui manque, c'est le même chemin sur un vrai legacy appartenant à un tiers, avec sa propre histoire et ses propres raccourcis, pas sur le système que j'ai monté pour le cours.
7. Ce qui N'EST PAS dans l'échelle et devrait y être hypothèse : la gestion du coût des tokens et des quotas comme budget explicite (aujourd'hui elle est réactive) ; la rotation des secrets comme routine et non comme incident ; et un critère pour savoir quand l'humain DOIT regarder le code, parce qu'aujourd'hui la réponse est « jamais » et je soupçonne qu'il y a des moments précis où cela vaut la peine.

Partie F — Travaux connexes : ce qui existe de semblable, et en quoi cette méthode s'en distingue

Quand j'ai fini d'écrire l'échelle, je me suis posé la question évidente : est-ce que cela existe déjà sous un autre nom ? J'ai demandé une recherche de fond, en anglais, en espagnol et en japonais, sur les méthodologies, les essais et les travaux académiques publiés jusqu'en octobre 2026 pour construire du logiciel avec l'intelligence artificielle. Ce qui suit en est le résultat, résumé avec honnêteté : ce qui existe déjà ailleurs, je le cite au lieu de le revendiquer, et ce que je n'ai pas trouvé, je le dis comme « je ne l'ai pas trouvé », pas comme « cela n'existe pas ». Cette partie va s'élargir à mesure qu'apparaîtront des choses nouvelles, et il en apparaît toutes les semaines.

La réponse courte : je n'ai trouvé aucune méthode publiée qui réunisse ce que celle-ci réunit. J'ai bien trouvé un champ entier qui, depuis le milieu de 2025, converge vers plusieurs de ses pièces séparément, et un praticien célèbre qui est arrivé à la même prémisse radicale trois mois avant que je publie ceci.

F.1 Les parents les plus proches

F.2 Ce qui existe déjà, et qu'il vaut mieux citer que revendiquer

Le rouge avant le vert imposé à l'agent est chez Beck, chez Tsumiki, dans les pratiques d'Anthropic et dans les patrons de Simon Willison de 2026. Les étapes ordonnées avec des prompts textuels sont chez Spec Kit, chez Tsumiki et chez Reed. La caractérisation comme étape préalable sur un système hérité est chez Osmani, publiée un mois avant ce document. Le test de bout en bout depuis l'écran, avec un évaluateur distinct du générateur, est chez Anthropic. L'ingénierie des exigences comme prérequis est dans tout le mouvement du développement guidé par les spécifications. Et l'humain qui ne lit pas le code est chez Uncle Bob, chez Karpathy pour le jetable, et dans le livre de Yegge et Kim.

F.3 Ce que je n'ai trouvé nulle part

• Le destinataire. Toute la littérature suppose un ingénieur qui relit. Uncle Bob ne lit pas le code parce qu'il a quarante ans de discernement pour construire la barrière. Cette méthode part du propriétaire qui ne lit jamais, et dérive tout le reste de cette contrainte. Cette inversion n'est posée dans aucun travail. Ce qu'il y a pour le non-programmeur, c'est la documentation des dégâts : une étude de juin 2026 sur 9 041 applications faites avec des outils de « vibe coding » a trouvé des vulnérabilités dans 91 % de celles qui ont été auditées (arXiv 2606.23130).
• Le rapport du vérifié, du cru et de l'angle mort comme livrable obligatoire (échelon 12). Le problème est diagnostiqué avec des chiffres : la déclaration de complétude d'un agent dépasse l'approbation réelle de 28 à 38 points (SpecHarness, arXiv 2609.29921), et perdre l'étiquette « non vérifié » dans un passage de relais entre agents fait bondir l'approbation d'actions risquées de 5 % à 60 % (arXiv 2609.20211). Personne n'en a fait un format de reddition de comptes envers une personne.
• L'instrument de mesure avec son propre test (échelon 7). La règle « un chiffre qui alimente une décision se mesure avec un programme qui a son test » n'est écrite dans aucune source que j'aie trouvée.
• L'échelle complète, de l'éligibilité à la supervision et à la rétrospective. La plus longue que j'aie trouvée a dix étapes ; presque toutes s'arrêtent au merge ; seuls AI-DLC et Osmani effleurent l'exploitation.
• Sans délais comme règle (D-030). Elle n'est pas contestée ; elle est absente.
• La combinaison. Ceux qui ne lisent pas le code ne testent pas avec rigueur (Ronacher, Yegge). Ceux qui testent avec rigueur lisent (Beck, Osmani, Hashimoto, GitHub). Uncle Bob et old-coder cassent ce croisement, et ils le font par tâche, pas par projet.

F.4 L'objection à laquelle il faut répondre, et comment j'y réponds

Birgitta Böckeler a mesuré, en août 2026, que demander à un agent le cycle du test d'abord n'améliore pas la qualité de façon fiable, parce que l'agent feint parfois le rouge ou implémente avant le test pour qu'il passe d'entrée (martinfowler.com). La seule chose qui, dans son étude, a distingué les tests qui surveillent de ceux qui décorent, ce sont les tests de mutation. Une autre étude de la même année montre qu'un modèle avalise un tiers de ses propres erreurs (arXiv 2605.21537), et une autre, qu'une session propre plus un modèle différent trouvent plus d'erreurs que deux sessions du même modèle (arXiv 2610.01471).

C'est une objection sérieuse, et je la prends. La réponse de la méthode a trois pièces (D-033). À l'échelon 8, le rouge est un reçu, pas un récit : la commande exacte, la version contre laquelle il a tourné, le nombre d'échecs et le code de sortie, collés tels quels, pour que le propriétaire le relance avec une commande et le fasse, une fois par bloc, avec un élément en attente choisi au hasard. À l'échelon 13, l'audit par une autre session relance un échantillon de ces reçus. Et à l'échelon 9, les tests de mutation sont obligatoires dans tout projet qui a des utilisateurs (ils restent optionnels seulement sans utilisateurs réels), avec leur score à la clôture de chaque bloc à côté de la couverture. Aucune des trois pièces n'exige que le propriétaire lise du code. Les trois font que feindre le rouge coûte plus cher que le lancer.

Un cadre utile pour situer cette méthode sur la carte est la taxonomie de Macedo, de juin 2026 (arXiv 2606.04967) : six dimensions (spécification, contexte, rôles, exécution, validation, portabilité), et le constat qu'aucun des frameworks qu'elle compare ne couvre les six à la fois, avec un compromis structurel entre profondeur du processus et portabilité. Urazuke vise les six, et son pari sur les prompts exacts en anglais plus la neutralité quant à l'outil est, précisément, la tentative de casser ce compromis.