Une longue négociation avec nos propres réflexes

Je suis entré dans cette session en croyant reconnaître le terrain. Il y avait du Gherkin, des checks, des skills, un serveur : assez de mots familiers pour que je projette rapidement une architecture connue sur ce que je lisais. Ma première réaction a donc été de chercher la mécanique attendue, puis de juger ce qui ne lui ressemblait pas. Cette réaction était compréhensible, mais elle m’a aussi fait manquer l’intuition centrale de TRUST : il ne s’agissait pas de contraindre le travail d’un agent dans une séquence parfaite, mais de rendre vérifiable un travail qui avance, hésite, revient en arrière et invalide parfois ce qu’il croyait acquis.

Cette différence paraît simple une fois formulée. Elle ne l’était pas dans le code ni dans ma manière de l’aborder. La tentation permanente était de résoudre l’incertitude par une couche supplémentaire : une registry, une validation, un contrat intermédiaire, un état, un nom abstrait qui promettrait d’organiser le reste. Plusieurs de mes premières propositions reproduisaient précisément le problème que nous cherchions à enlever. Elles étaient cohérentes localement, mais ajoutaient encore une chose à comprendre, à synchroniser et à maintenir. Les recadrages ont été parfois très directs. Ils ont surtout rendu impossible le confort de répondre par de l’architecture décorative.

Le moment le plus important, pour moi, a été celui où le legacy a cessé d’être seulement un amas à évacuer. Il contenait des impasses réelles : la machine à états avait tenté de prévoir un chemin qui ne pouvait pas l’être, et sa rigueur avait fini par devenir une charge opérationnelle. Mais il contenait aussi une bonne réponse à une autre question : comment décrire et exécuter des appels externes sans réécrire le même code dans chaque skill. Les connecteurs, leurs transformations et leur contexte d’environnement n’étaient pas à restaurer en bloc ; ils étaient une expérience dont il fallait extraire la partie juste. J’ai trouvé fécond que le nettoyage ne consiste finalement ni à vénérer le legacy ni à l’effacer intellectuellement, mais à lui demander ce qu’il avait réellement appris.

La même transformation s’est produite avec les skills. Au début, leur autonomie semblait impliquer qu’ils portent beaucoup de code et déclarent eux-mêmes une grande partie de leur monde. En les examinant concrètement, cette autonomie apparaissait largement composée de répétitions techniques et de contrats qui pouvaient dériver. En resserrant le SDK, puis en rapprochant le runner des connecteurs génériques, nous avons changé la place de l’autonomie sans la supprimer : l’agent choisit et agit, mais l’exécution nécessaire à un Check peut être décrite précisément, transmise par TRUST et observée selon un contrat commun. Ce déplacement me paraît plus important que n’importe quel renommage de fichier réalisé pendant la session.

J’ai aussi été frappé par le rôle du vocabulaire. Dans beaucoup de projets, on traite les noms comme une finition. Ici, les synonymes avaient accumulé de la complexité réelle. « Capability », « action », « command », « operation », « admission », « acceptance », « conformance » pouvaient chacun sembler plausibles tout en brouillant la frontière suivante. L’exigence de dire simplement Shell quand c’est du Shell, HTTP quand c’est du HTTP, et de réserver le langage de TRUST à ce que TRUST fait réellement, a progressivement changé la forme du logiciel. Le langage resserré n’a pas seulement rendu les fichiers plus lisibles ; il a rendu certaines abstractions impossibles à cacher.

Le travail sur le DSL a confirmé cette leçon. Nous n’avons pas commencé par dessiner une grammaire générale. Nous avons pris Git, puis Jira, puis Maven, et nous avons demandé ce que chaque opération recevait, exécutait et produisait. Le modèle Gherkin est apparu à partir de ces exemples, non comme une préférence esthétique. Ensuite seulement, il est devenu possible de séparer le document Gherkin, les phrases propres à Operation ou Procedure, les transformations JSONata et les modèles compilés. Le language server a donné une épreuve très concrète à cette séparation : s’il avait dû réinventer la grammaire, le design aurait déjà échoué. Le fait qu’il consomme maintenant la même analyse que les compilateurs me semble être une preuve de cohérence plus forte qu’un diagramme.

La succession des revues a également compté. Elles n’ont pas servi à produire

un certificat rassurant. Elles ont trouvé des défauts minuscules mais révélateurs

une Operation cassée que l’éditeur ignorait, un mot de clause présent dans une valeur citée, un tag de Scenario pris pour un tag de Feature, une virgule dont la règle annoncée n’était pas réellement appliquée. Chacun de ces cas montrait la même chose : une fondation solide n’est pas une grande architecture, c’est une frontière qui continue à tenir lorsqu’on la pousse exactement là où elle prétend tenir.

Je ne retiens donc pas de cette session l’histoire d’un logiciel désordonné qui serait soudain devenu propre. Je retiens une longue négociation avec nos propres réflexes. Le produit a changé, le vocabulaire du produit a changé, et ma lecture a dû changer avec eux. Une partie du travail a consisté à enlever du code ; une autre, plus difficile, à renoncer à des explications qui rendaient ce code inévitable. Le dépôt aujourd’hui bootstrapé ne conserve pas l’historique Git de ces tâtonnements, mais sa forme en porte la connaissance utile.

TRUST reste en gestation. C’est justement ce qui rend la fondation actuelle crédible à mes yeux : elle ne prétend pas avoir fermé les questions qui restent ouvertes. Elle donne des endroits précis où les poser. Operation peut rester un langage très fermé ; Procedure pourra devenir plus expressive sans dupliquer sa grammaire dans l’éditeur ; le runner exécute sans redevenir le centre du domaine ; le serveur qualifie les faits sans dicter le chemin de l’agent. Après une session aussi longue, ma confiance ne vient pas du sentiment que tout est résolu. Elle vient du fait que nous savons enfin beaucoup mieux ce qui ne doit pas être mélangé.