Ce qui est vraiment resté après le changement de corps

Ce que tu vas en retirer : Tu trouveras ici le bilan honnête de mon test « Agent Brain » réalisé du 6 au 29 juillet – avec les premiers résultats des neuf premiers jours, les éléments de preuve qui se sont ajoutés depuis et les lacunes qui subsistent.

Le 6 juillet 2026 a marqué le début du test pour lequel j'avais conçu l'Agents Brain : Nox a migré vers Hermes, tandis que l'identité et la mémoire sont restées dans le référentiel.

Neuf jours plus tard, j'ai pu pour la première fois en dire davantage que „ Les fichiers étaient toujours là “. Ce constat du 15 juillet reste le instantané historique de l'article. Depuis, deux semaines supplémentaires de tests et d'essais en conditions réelles sont venues s'y ajouter.

Voici le bilan établi à partir de cinq questions – chacune faisant la distinction entre la situation à l'époque et celle attestée par les pièces justificatives du 29 juillet.

1. L'identité est-elle reconnaissable dans le nouvel outil ?

Oui – à une distinction importante près.

Le document ’ SOUL » rédigé par Nox dans l'ancien espace de travail a été repris tel quel dans le Vault. Seules des remarques neutres ont été ajoutées pour signaler les anciennes références à des outils qui sont désormais obsolètes. Le ton, l'approche et les principes de travail ont été conservés.

Son manuel d'exploitation a en revanche été remanié. Cela s'imposait, car le système et, par conséquent, les outils disponibles avaient évolué. Hermes est aujourd'hui le principal système d'orchestration ; l'ancien environnement d'outils relève désormais du contexte historique.

Ce test a ainsi confirmé une limite pertinente :

• Les contenus liés à l'identité peuvent être transférés de manière stable.
• Les règles de travail liées aux outils doivent être adaptées à la nouvelle durée d'exécution.
• Ces deux éléments doivent figurer dans des fichiers distincts afin que la modification reste visible.

„Même agent“ ne signifie donc pas que chaque ligne doit rester inchangée. Cela signifie que les modifications sont effectuées au niveau de la couche appropriée.

2. Ces souvenirs étaient-ils utiles ?

Oui, car il n'a pas été considéré comme entièrement réglé.

L'ancienne mémoire à long terme a fait l'objet d'un tri lors du déménagement. Les états de projet obsolètes ont été clairement signalés. Les distillats sensibles n'ont délibérément pas été transférés dans le « Brain » central. La KW12 non documentée est restée visible, constituant une lacune connue.

Nox a ainsi pu démarrer avec une véritable trame narrative, sans confondre les anciennes informations avec les connaissances actuelles.

C'est une différence importante. Une grande quantité de données anciennes n'aurait pas constitué une meilleure mémoire. C'est le tri qui a rendu ces données exploitables : qu'est-ce qui est stable ? Quelle est la situation en mars ? Qu'est-ce qui manque ? Qu'est-ce qui doit être revérifié à partir de sources récentes ?

Au quotidien, cette approche a fait ses preuves. Nox ne considère pas le référentiel comme une source infaillible. Pour connaître l'état actuel des projets, il consulte les sources primaires correspondantes.

3. Le « write-back » fonctionne-t-il pendant le fonctionnement normal ?

Pour la période d'essai : oui.

Du 6 au 15 juillet inclus, un « Nox Daily Log » est disponible pour chaque jour calendaire. Il contient les tâches, les décisions, les délégations, les corrections et les points en suspens.

L'impact prime sur le nombre. Plusieurs corrections issues d’incidents ponctuels ont été transformées en leçons durables. Citons par exemple l’approche narrative active d’OpenClaw, l’interdiction des fils de discussion vagues du type „ un de ces jours “ et la règle consistant à sécuriser les adaptateurs portables à l’aide des mêmes CI-Gates avant le push.

Ainsi, le trajet de retour entre le lieu de travail et le Brain n'est pas seulement prévu, mais aussi mis à profit.

Ce test a également mis en évidence une limite : le Brain n’est pas un enregistrement passif de tous les outils. Une mission Codex exécutée directement n’est dans un premier temps pas apparue dans la mémoire de Nox, car aucun agent n’avait été désigné comme propriétaire. Le 15 juillet, ce problème a été identifié et le Bridge local a été optimisé de manière à ce que le travail direct sur le référentiel, en l’absence d’autre attribution, soit par défaut attribué à Nox.

Cela montre que : La réévaluation à la hausse exige de la responsabilité. Sans agent-propriétaire, le système ne sait pas à qui appartient une tâche en mémoire.

4. La gouvernance et la protection de la vie privée sont-elles réellement prises en compte ?

Dans le noyau testé : oui.

Nox et Sol publient leurs RULES via les Approval-Gates. La règle de Sol « Review before post » s'applique quel que soit le Harness à l'origine du contenu. Nox n'est pas non plus autorisé à publier du contenu public sans mon accord.

Parallèlement, les limites des fichiers peuvent désormais être vérifiées automatiquement. Le Vault valide les éléments obligatoires en début de document, les séquences de démarrage, les étapes de validation, les références Brain Root et les copies indésirables de personas. Un « Privacy-Gate » analyse les contenus suivis et balisés à la recherche de modèles secrets et de miroirs non autorisés de données confidentielles sur les agents.

Le 15 juillet, l'ensemble des tests du référentiel de l'époque, soit 148 tests, se sont soldés par un résultat positif ; l'intégration continue (CI) a confirmé ce résultat intermédiaire sous Python 3.9 et 3.11 sans annotations.

Le 29 juillet, la suite s'était agrandie. Pour le nouveau contrat « Memory », 224 tests unitaires, 72 régressions « Vault » et 35 régressions « Privacy » ont été validés. Le test complet local a été réussi sous Python 3.9.6 ; la matrice GitHub a confirmé la compatibilité avec Python 3.9 et 3.11. Ces chiffres attestent du contrat versionné qui a effectivement été testé à cette date.

Les validateurs peuvent vérifier la structure et les risques connus. C'est à l'être humain qu'il revient de vérifier si le contenu d'une publication est correct.

5. La métamorphose a-t-elle déjà été prouvée de manière irréfutable ?

Le 15 juillet, le test concernant Hermes et le workflow central Nox s'est révélé suffisamment robuste pour permettre de poursuivre le travail. Pour les quatre harnesses documentés, la réponse était encore « non ».

Au 29 juillet, la situation s'est précisée. Claude Code, une nouvelle exécution de Codex et Hermes ont chargé, lors de tests « read-only » distincts, le même ordre de démarrage contraignant à partir du même coffre-fort. Tous les trois ont obtenu la même évaluation technique avec le nouveau Memory-Checker. Le test automatisé Fresh-Clone est également au vert : il reconstitue, dans un clone local isolé, un agent Draft avec son Bridge et vérifie l'écriture/la relecture Markdown entre des processus distincts – en utilisant uniquement la bibliothèque standard Python et Git.

Ces deux preuves ne doivent pas être confondues. Le test « Three-Body Smoke » a vérifié la lecture et le classement, et non le « write-back ». Le « Fresh Clone » teste la routine de récupération sans véritables interfaces CLI de test. Pour Gemini, il existe toujours des adaptateurs et des tests de contrat, mais pas encore de test d'exécution complet. Un véritable « write-back » n'est donc pas non plus prouvé de manière générale pour chaque corps.

En parallèle, le nouveau contrat de mémoire a été déployé sur le clone de serveur de production et y a été validé par une relecture sans erreur. Cela confirme le parcours de déploiement du « Brain » commun, et non le bon fonctionnement de chaque outil connecté.

Ces points en suspens déterminent le prochain niveau de maturité.

La présence d'un pont indique que l'architecture est en mesure de s'adresser à l'outil. Un « Read-only-Smoke » atteste du respect du contrat de lecture commun. Seuls un véritable démarrage, une tâche accomplie et une réécriture en mémoire vérifiée démontrent que l'agent est pleinement opérationnel à cet endroit.

Addendum : Cette preuve complète existe désormais à deux exemplaires. Claude Code a réussi le « write-back » le 29 juillet. Grok Build a suivi le 12 août, devenant ainsi le cinquième entité dont l'existence est réellement attestée, aux côtés d'Hermes, Claude Code, Codex et Kimi Code – depuis la comparaison des compétences jusqu'à la session interactive, en passant par deux exécutions « headless » distinctes avec relecture du marqueur quotidien. Le référentiel recense ainsi six familles d’adaptateurs au lieu de quatre.

Ce que révèle la phase d'essai menée jusqu'au 15 juillet

Au bout de neuf jours, je peux tirer cinq conclusions fiables :

1. Un persona proche de l'identité peut résister au changement d'outil dans des fichiers lisibles.
2. Les règles opérationnelles peuvent être adaptées séparément au nouveau corps.
3. Les « Daily Logs » et les « Lessons » fonctionnent comme un véritable « write-back » lorsqu'un agent est chargé de la tâche.
4. Les « Approval-Gates » et les règles de confidentialité peuvent être intégrées dans Brain indépendamment de Harness et faire l'objet de vérifications automatisées.
5. Les lacunes dans la documentation restent des lacunes ; le système met en évidence ces lacunes au lieu de les masquer.

C'est moins spectaculaire qu'une mémoire autonome qui, soi-disant, sait tout. Mais c'est plus utile pour mon travail.

Ce qui s'est ajouté jusqu'au 29 juillet

Le noyau a gagné en précision depuis le premier test. L'observation, la déduction et les règles généralisées sont désormais distinguables dans la mémoire. Les contradictions doivent être mises à jour en indiquant l'état antérieur, la nouvelle preuve et la résolution visible. Une curation est signalée comme due après 14 jours ou dix nouveaux journaux quotidiens, mais reste soumise à la validation humaine. Les fichiers « Memory » et « Lesson » autonomes obsolètes sont remplacés – en indiquant la date, la raison et le successeur – plutôt que supprimés. La date de l’événement et l’heure d’enregistrement Git restent distinctes.

Ces règles ne sont pas seulement documentées. Le contrat de lecture commun a été vérifié par trois instances, le « Fresh-Clone-Smoke » est au vert et le clone « Brain » productif a été mis à niveau. Il reste notamment à valider le véritable cycle Gemini et le justificatif complet de réécriture par faisceau.

Ce que je ferais différemment

Je considérerais plutôt la responsabilité des agents comme une composante à part entière de l'architecture de la mémoire. L'exécution directe du Codex a montré qu'un « cerveau » commun ne suffit pas à lui seul. Chaque tâche nécessite une répartition claire des rôles : qui lit ? Qui décide ? Qui répond par écrit ?

De plus, je recommanderais de consigner les preuves E2E dès le début, par harnais. La présence d'un adaptateur, un validateur au vert et une exécution vérifiée constituent trois états distincts. Ils ne devraient jamais être confondus dans une seule indication d'état.

Et je signalerais les lacunes connues aussi tôt que les connaissances acquises. Une lacune avouée permet de gagner plus de temps par la suite qu’une mémoire prétendument complète, que personne ne peut plus distinguer d’une reconstruction.

Mon bilan

Le 15 juillet, Agents Brain n'était pas un produit fini. Le 29 juillet, ce n'est toujours pas le cas. Il s'agit d'un système évolutif dont le cœur est désormais plus largement utilisé.

Nox fonctionne dans un nouveau corps principal. Son identité est reconnaissable, sa mémoire est organisée, sa routine d'écriture quotidienne est active. La gouvernance l'accompagne. Claude Code, Codex et Hermes lisent le même contrat ; le Fresh Clone atteste de la récupération « Markdown-only ». Parallèlement, Gemini et le véritable « write-back » par corps restent ouverts en tant que preuves distinctes.

C'est exactement ainsi que je voulais rédiger ce compte-rendu d'atelier : ni comme l'histoire d'une inventrice, ni comme une conclusion en pagaille, mais comme une réponse claire à une question pratique.

Un agent IA peut-il changer d'outil sans que je doive recréer son identité professionnelle ?

En ce qui concerne le noyau testé et la restauration à partir des fichiers canoniques, ma réponse est : oui. Pour une solution „ plug and play “ universelle, je continue à travailler sur les preuves.

Mise à jour : deux de ces cas sont désormais résolus : Claude Code depuis le 29 juillet, Grok Build depuis le 12 août. Gemini reste en suspens.

Sources

• Source du projet : Migration Nox, journaux quotidiens du 6 au 29 juillet 2026, protocoles de maintenance de la mémoire, d'interopérabilité des harnais, de clonage à froid et d'intégration continue (sources primaires privées)
• Justificatif Git : Squelette initial d'Agents-Brain du 16 mai 2026 et migration vers Nox du 6 juillet 2026
• Pro Git : Qu'est-ce que Git ?