La preuve commence quand le système accepte d’avoir tort

Un angle de la branche EH pose une règle simple : la preuve plutôt que la promesse. Il est facile de l’appliquer aux autres. Il est beaucoup plus exigeant de l’appliquer à son propre portfolio. Une page publique peut accumuler des captures, des journaux, des tests et des décisions sans démontrer le résultat qu’elle affirme. La quantité de traces ne transforme pas automatiquement une affirmation en preuve. Elle permet seulement de remonter le travail, à condition que les traces répondent à la bonne question.

Pour une méthode, la question n’est pas seulement : a-t-elle été utilisée ? Il faut demander par qui, quand, sur quel objet, avec quel résultat, selon quelle mesure et où ce résultat peut être relu. Un cockpit utilisé par son auteur établit un usage. Un test exécuté établit un comportement dans un périmètre donné. Un journal public établit qu’une construction a été racontée et datée. Aucun de ces éléments, pris seul, ne démontre qu’une méthode produit un résultat observable au-delà de son propre contexte.

La distinction paraît sévère parce qu’elle retire une récompense symbolique à un travail réel. C’est précisément pour cela qu’elle est utile. Si l’état le plus élevé peut être accordé dès qu’un système fonctionne pour son auteur, il ne décrit plus la maturité de la méthode. Il décrit la satisfaction de celui qui l’a construite. La preuve commence lorsque cette satisfaction ne suffit plus.

ADAMA OS conserve donc plusieurs couches qui ne doivent pas être fusionnées. Une source permet de retrouver l’origine d’une affirmation. Une méthode explique comment cette source a été transformée. Un horodatage fixe le moment de l’observation. Une expiration indique quand il faut relire. Un revirement conserve la trace du changement. Le résultat mesurable vient ensuite. Il ne peut pas être remplacé par la propreté des couches précédentes.

Un autre angle de EH2 affirme que l’IA n’a pas le droit de décider. Dans le système, cette phrase ne signifie pas que le modèle serait inutile. Elle signifie que sa sortie ne devient pas vraie simplement parce qu’elle a été formulée avec assurance. Le modèle peut chercher, rapprocher, résumer ou proposer. La chaîne doit encore retrouver une source, vérifier la pertinence, exposer la limite et refuser lorsque le matériau ne suffit pas.

Cette frontière possède déjà des éléments mesurés. Le plancher de récupération est fixé à 0,15. La vérification publique considère l’échec sous 0,45 et la réussite à partir de 0,50. Ces nombres n’établissent pas une qualité générale de l’IA. Ils décrivent des portes précises dans une chaîne précise. Leur utilité vient de cette modestie : ils indiquent quand continuer, quand signaler une faiblesse et quand ne pas répondre.

La passe a montré qu’une règle de refus peut elle-même être surévaluée. Dire que la chaîne échoue plutôt que d’inventer décrit un comportement de conception. Pour faire passer la méthode AI Decision Boundary de TESTE à PROUVE, il faut publier une mesure du taux de refus observé. Sans cette mesure, la frontière existe dans le code et dans les tests, mais son résultat réel n’est pas encore établi.

Le même principe vaut pour l’article que vous lisez. Aucun nombre n’est ajouté pour rendre le récit plus impressionnant. Les comptes cités viennent de la passe. Lorsqu’un ordre de grandeur n’a pas été mesuré, il n’entre pas dans le texte. Une histoire moins spectaculaire mais remontable vaut davantage qu’une précision fabriquée.

Le troisième angle affirme que construire seul n’est pas construire petit. Une personne peut tenir une architecture étendue, plusieurs registres et une chaîne de publication. Mais la concentration des rôles crée un risque particulier : la même personne formule l’idée, construit le système, choisit le test, interprète le résultat et publie le verdict. Sans mécanisme de contradiction, cette continuité devient une machine à confirmer ses propres choix.

Les registres, les invariants, les listes de contrôle et l’inventaire machine ne servent donc pas à donner une apparence industrielle au travail. Ils séparent des moments qui seraient autrement confondus. Une décision est écrite avec sa raison et sa condition de caducité. Un invariant peut faire tomber une décision plus récente. Un test peut retirer un état déjà affiché. Une limite fermée reste visible avec la preuve de sa fermeture. Le système gagne en surface parce qu’il doit compenser l’absence d’une équipe qui contredirait naturellement son auteur.

La passe de vérification a joué ce rôle de contradiction. Elle n’a pas demandé si le programme était ambitieux ou cohérent dans son intention. Elle a recompilé les comptes, suivi les dépendances, comparé les textes en vigueur, vérifié les liens et opposé chaque état à son critère. Plusieurs éléments ont tenu. D’autres ont cassé. La valeur de la passe vient de l’absence de traitement préférentiel entre les deux catégories.

Construire seul exige enfin de rendre la correction moins coûteuse que le déni. Un état doit pouvoir descendre sans effacer le travail déjà accompli. Une décision doit pouvoir être remplacée sans faire disparaître son ancienne raison. Une page publique doit pouvoir reconnaître une erreur sans devenir inutilisable. Cette réversibilité n’affaiblit pas le système. Elle évite qu’il défende une affirmation uniquement parce qu’elle est déjà visible.

Le programme utilise trois états principaux pour les méthodes : RECHERCHE, TESTE et PROUVE. RECHERCHE signifie que la question, l’hypothèse ou la structure existe, mais qu’un essai daté manque encore. TESTE signifie qu’un usage ou un essai a eu lieu et qu’il peut être remonté. PROUVE exige davantage : un résultat mesurable publié, rattaché à un usage réel et daté.

Une autre échelle existait dans le laboratoire. La passe a fixé la correspondance : OBSERVÉ rejoint RECHERCHE, EXPÉRIMENTÉ rejoint TESTE et PROUVE reste PROUVE. CONCEPT et ARCHIVE n’ont pas d’équivalent dans le laboratoire. Cette correspondance empêche deux vocabulaires voisins de produire des maturités différentes pour le même objet.

La correction de quatre méthodes ne doit pas être lue comme leur retour à zéro. TESTE reconnaît du travail réel. Il dit seulement ce que ce travail permet d’affirmer aujourd’hui. M-003 reste TESTE dans l’attente d’un second corpus extérieur. M-005 reste TESTE dans l’attente d’un second produit. M-007 reste RECHERCHE dans l’attente d’un essai daté. Chaque état contient ainsi sa prochaine condition sans annoncer le moment où elle sera remplie.

La passe a trouvé neuf décisions citées mais jamais écrites. XDEC-09 à XDEC-17 apparaissaient comme une plage résumée, sans énoncé, sans raison et sans condition de caducité. Dans le même temps, une page annonçait que ces décisions restaient à rendre tandis que le registre disait que toutes les décisions étaient datées. Les deux affirmations ne pouvaient pas rester vraies. Les neuf décisions ont été écrites en entier.

Quatre contradictions internes opposaient aussi des textes en vigueur. L’affiliation sortante et l’affiliation entrante étaient confondues. Le maintien du public entrait en conflit avec la possibilité de retirer une entrée fausse. Une sortie logicielle de méthode semblait autoriser ce que XINV-01 interdit à la branche. Chaque collision a reçu une règle de priorité et une lecture bornée.

Le registre XDEC, cité par trois procédures, n’était atteignable depuis aucune page du programme. Il existait, mais le lecteur ne pouvait pas y arriver. Cette panne rappelle qu’une preuve inaccessible ne joue pas son rôle. Un identifiant ou un nom de registre ne remplace pas un chemin utilisable.

Enfin, cinq chantiers, EH7 à EH11, restaient hors de toutes les vagues alors qu’ils portaient des idées identifiées. Le tableau distribuait 127 chantiers sur 132 et paraissait complet à la lecture. Le recompte a fait apparaître le trou. Les cinq chantiers ont rejoint la vague X3.

Une vérification qui ne publie que les erreurs produit une autre déformation. Plusieurs structures ont résisté au recompte. Les additions de jours des branches du ratissage sont exactes. Les comptes de chantiers bouclent sur 208. Aucun code de chantier n’a de trou ni de doublon sur les dix-huit branches. Aucune dépendance ne pointe vers un chantier inexistant.

Le registre XINV va de 01 à 60 sans rupture ni répétition. Les huit familles ajoutées couvrent AXP-223 à AXP-300 sans trou ni chevauchement. Les sept routes de l’interface sont bien sept et restent toutes en lecture. Le récapitulatif du registre XDEC couvre sa plage complète.

Ces résultats comptent parce qu’ils donnent une forme au désaccord. La correction des méthodes ne signifie pas que tout le système est faux. Elle signifie que certains éléments ont passé leurs tests et que d’autres ont échoué. La méthode doit savoir publier les deux sans transformer les succès en immunité ni les échecs en condamnation générale.

Le coût réel de la méthode n’est pas un prix de logiciel. Il apparaît dans les renoncements qu’elle impose. Il faut abandonner un état valorisant, reprendre un texte déjà publié, conserver une erreur dans l’historique, réparer un lien peu visible et retarder une affirmation que l’on voudrait utiliser immédiatement.

Il apparaît aussi dans l’entretien. Une source peut changer, un chiffre peut diverger, un lien peut mourir et une règle peut être révisée. La preuve n’est donc pas un paquet constitué une fois pour toutes. C’est une relation maintenue entre une affirmation et les éléments qui permettent encore de la soutenir. La date et l’expiration ne sont pas des métadonnées décoratives. Elles empêchent une observation ancienne de continuer à parler au présent.

La passe a montré un autre coût : résumer un invariant de mémoire est plus rapide que le copier, mais cette économie déforme la règle. Sept des dix-sept défauts observés sur les pages de branche venaient d’invariants raccourcis. Dans un cas, la version tronquée était devenue le critère de contrôle d’une interface. La règle corrigée est directe : un invariant se cite dans sa forme entière ou par un lien qui permet de le relire.

Enfin, une preuve publique oblige à accepter une asymétrie. Le travail nécessaire pour retirer un mot peut être important, alors que la correction visible tient parfois en une ligne. Cette disproportion est normale. La fonction de la ligne n’est pas de montrer l’effort fourni. Elle est de dire exactement ce que les éléments permettent encore d’affirmer.

Première règle : un état se gagne, il ne se décerne pas. La fiche doit porter la condition observable qui ouvre l’état suivant. Tant que cette condition manque, le travail reste nommé à son niveau actuel.

Deuxième règle : une citation d’invariant se copie ou se relie. Elle ne se recompose pas de mémoire. Le sens d’une règle tient souvent dans sa réserve, sa date ou son exception, exactement les morceaux qu’un résumé retire en premier.

Troisième règle : un chiffre possède un relevé. S’il n’existe ni comptage, ni source, ni méthode de calcul, il reste un jugement et doit être écrit comme tel. La précision visuelle d’un nombre ne remplace pas son origine.

Quatrième règle : un renvoi doit être parcourable. Un registre nommé mais inaccessible, une preuve sans URL stable ou une décision sans chemin depuis le texte qui la cite sont des objets incomplets.

Cinquième règle : la correction reste visible. Une entrée fausse peut être retirée, mais une notice datée doit dire ce qui existait et pourquoi cela a changé. Le revirement devient alors une partie de la preuve, pas un défaut à cacher.

Après la passe, aucune des sept méthodes n’est à l’état PROUVE. Cette phrase n’annule ni le code ni les usages déjà observés. Elle remet chaque élément à sa place et rend les prochaines conditions vérifiables.

La preuve commence ici : non pas lorsque le système accumule assez de traces pour paraître solide, mais lorsqu’il accepte qu’une règle puisse lui retirer une affirmation à laquelle son auteur tient. Un portfolio qui publie ce retrait ne devient pas infaillible. Il devient lisible, contestable et révisable. Cette base permet de continuer à construire sans masquer ce qui reste ouvert.