J'ai mis fin à OpenClaw. Ce qu'il restait de mon équipe d'IA.

Ce que tu vas en retirer : Tu comprends pourquoi l'abandon délibéré d'un outil entraîne malgré tout une perte de contexte – et comment cela a donné naissance à mon « Agents Brain », basé sur des fichiers.

Le 10 février 2026, j'ai mis en place Nox : mon orchestrateur IA destiné à une équipe composée de quinze agents spécialisés. Fin mars, j'ai supprimé l'outil dans lequel cette équipe était organisée.

Ce n'était pas une panne imprévue. OpenClaw m'avait déjà causé des soucis à plusieurs reprises lors des mises à jour. Celles-ci s'exécutaient souvent aux petites heures du matin. Certains jours, il me fallait ensuite une demi-journée de travail pour remettre OpenClaw et mon installation en état de marche. À un moment donné, le constat était clair : je passais trop de temps à réparer l’infrastructure et pas assez à faire ce pour quoi elle était là. J’ai donc pris la décision de m’en passer.

Cette décision était la bonne. Ses conséquences n'en ont pas moins été révélatrices.

Je pensais que je ne faisais que remplacer un outil

En février et mars, l'équipe avait déjà mis en place une répartition claire des tâches. Un agent effectuait des recherches, un autre rédigeait, un troisième vérifiait. Nox, en tant que coordinateur, assurait la cohésion entre les tâches, leur ordre d'exécution et les passations de relais. Cette organisation n'était pas purement théorique : elle avait fait ses preuves pendant six semaines.

Avec la fin de cet outil, cette collaboration n'était pas facilement exportable. L'orchestration en cours, les canaux et les automatisations faisaient partie de l'état du système à l'époque. Ils ne pouvaient pas être transférés vers l'outil suivant en tant qu'entité fonctionnelle.

Une autre partie a toutefois survécu : les fichiers Markdown.

Les personas, les connaissances à long terme et les journaux quotidiens étaient lisibles, même si l'outil d'origine n'était plus utilisé. Pour ces fichiers, je n'avais besoin ni d'une exportation ni d'une interface spécifique. Un éditeur de texte suffisait.

La limite décisive était ainsi visible : J'ai dû recréer ce qui n'existait que sous forme d'outil. J'ai pu réutiliser ce qui était disponible sous forme de fichier.

Le modèle est rarement le problème. C'est presque toujours le contexte.

La phase de conception s'est déroulée de fin mars à mi-mai

Après la suppression, je ne me suis pas contenté d'installer le framework d'agents suivant. D'avril à mi-mai, j'ai travaillé sur trois questions.

Comment rendre (mon) équipe d'IA véritablement portable ?

Un dossier rempli de fichiers ne constitue pas encore un système. Je voulais une structure à partir de laquelle je puisse charger de manière fiable un agent dans un nouvel outil : avec le même rôle, les mêmes limites et les mêmes connaissances pertinentes.

Pour cela, il fallait déterminer clairement quelles informations relevaient de l'identité d'un agent – et lesquelles n'étaient que des caractéristiques de l'outil utilisé.

Comment changer d'Orchestrator ?

En tant que chef d'équipe, Nox était étroitement lié à son environnement de travail de l'époque. Je voulais rompre ce lien. L'Orchestrator devait pouvoir s'adapter à un autre environnement technique sans que j'aie à réinventer son identité, ses méthodes de travail et ses règles de validation.

Cela signifiait que l'identité ne devait plus être liée à l'invite système d'un outil particulier. L'outil ne devait plus que charger ce qui était déjà défini dans un emplacement indépendant.

Comment les sessions se transforment-elles en mémoire durable ?

Les historiques de session sont pratiques, mais ne constituent pas un moyen de stockage fiable à long terme. Ils sont tronqués, disparaissent du contexte visible ou ne sont utilisables qu'au sein d'un produit donné (par exemple Claude Code, ChatGPT Codex, OpenClaw, etc.).

J'avais donc besoin d'une routine d'écriture : des journaux quotidiens pour consigner mes expériences, des connaissances à long terme triées sur le volet pour l'essentiel, et des leçons tirées des erreurs à ne pas répéter.

Ces trois questions – la portabilité, le changement de corps et la mémoire – sont devenues le cœur de mon concept.

Le 16 mai, les croquis ont donné lieu à un reportage

Le 16 mai 2026, j'ai effectué le premier commit dans le nouveau dépôt. Son message était le suivant : feat : squelette cérébral initial partagé.

Ce nom était tout à fait approprié. Le système n'était qu'un squelette, pas un produit fini. Mais la décision fondamentale était prise : Markdown est la source de vérité. Git permet de retracer les modifications. Chaque agent dispose de son propre dossier. Les connaissances communes sont référencées plutôt que copiées. Les outils sont dotés de légers adaptateurs qui renvoient vers cette source.

J'appelle mon système Agents Brain. Il existe également des approches similaires basées sur des fichiers ailleurs, car, logiquement, je ne suis pas la seule à être confrontée aux “ maladies de jeunesse ” de l'IA agentielle, qui en est encore à ses débuts. Voici mon compte-rendu d’atelier : un système multi-agents vivant avec des rôles, des règles de mémoire et des portes d’approbation explicites.

Ce que les fichiers peuvent résoudre – et ce qu'ils ne peuvent pas résoudre

Les fichiers permettent de rendre le contexte lisible, de le versionner et de le transférer. Ils ne résolvent toutefois pas automatiquement le problème de la mémoire.

Dans les anciens journaux quotidiens, il manque par exemple une semaine en mars. Cette lacune est bien réelle. Elle n'est pas due au changement d'outil, mais est antérieure à celui-ci : ce que personne ne note ne peut pas être reconstitué par la suite, même par un référentiel.

C'est précisément pour cette raison que l'architecture est plus qu'un simple espace de stockage. Elle doit définir des règles précisant ce qui est lu au début d'une session et ce qui est écrit à la fin. Elle doit fixer une limite pour les contenus sensibles. Et elle doit faire preuve de la discipline nécessaire pour sélectionner les connaissances à long terme, plutôt que de conserver indéfiniment chaque historique.

Le fait d'avoir délibérément abandonné OpenClaw ne m'a donc pas démontré qu'un outil en particulier était mauvais. Cela m'a montré que mon identité d'agent ne doit pas être la propriété d'un outil.

La décision à l'origine du système

Mon objectif principal en matière de design peut être formulé sans grand pathos :

Si un outil venait à disparaître demain, les fichiers Markdown resteraient lisibles et l'agent pourrait être reconstitué à partir de ceux-ci. Les moteurs et les interfaces sont des compléments, pas des conditions préalables.

J'ai continué à peaufiner le système de mai à juin. Le 6 juillet, la phase de test pratique a débuté : Nox a migré vers Hermes, tandis que son « Brain » est resté dans le référentiel.

Un plan d'architecture ne permet pas de déterminer si cette séparation tient la route au quotidien. Elle doit faire ses preuves dans la pratique. C'est précisément ce que je vérifie depuis lors.

Dans la partie suivante, je vais vous présenter les sept « règles d'or » issues de cette phase de conception – et vous expliquer pourquoi mon « Agents Brain » est délibérément un dépôt Git et non une nouvelle base de données.

Sources

• Historique du projet : Spécification d'agents-brain et historique Git, au 15 juillet 2026 (sources primaires privées)
• Pro Git : À propos du contrôle de version
• Aide Obsidian : Comment Obsidian stocke les données