Agents · Mémoire
Le Doyen
Une équipe d'assistants IA où chacun sait ce qu'il a le droit de faire, et surtout ce qu'il n'a pas le droit de faire.
En résumé
- Problème
- Un assistant unique à qui l'on parle de tout devient vite ingérable : les sujets se mélangent, les informations privées débordent, et on ne sait plus qui a décidé quoi.
- Solution
- Plutôt qu'un seul assistant, une petite organisation : six rôles, chacun avec son périmètre, ses responsabilités et la liste de ce qu'il ne peut pas faire.
- Ce que ça apporte
- Chaque sujet reste à sa place, on sait qui a fait quoi, et aucun assistant ne peut décider seul de ce qui devient officiel.
- Où il en est
- Fonctionne et me sert tous les jours. L'interface de supervision existe à l'état de prototype.
- Mon rôle
- J'ai conçu l'organisation, écrit les règles et le périmètre de chaque rôle, et défini les scénarios à tester. Le code a été écrit avec des assistants, sous ma direction.
Pourquoi ce projet
Comme beaucoup de gens qui utilisent l'IA au quotidien, j'ai fini par accumuler des échanges, des décisions, des projets et des notes éparpillés entre un éditeur de notes, des dépôts de code, des conversations et des documents.
J'ai commencé comme tout le monde, avec un seul assistant à qui je parlais de tout. Ça a marché quelques semaines.
Ce qui a coincé
Un assistant qui touche à tout n'a aucune raison de refuser quoi que ce soit. Trois problèmes sont vite apparus.
Les sujets se mélangeaient. Une question sur un projet pro ramenait un détail personnel dans la réponse. Pas grave quand on est seul, beaucoup plus gênant dès qu'il faut partager quelque chose.
Je ne savais plus qui avait décidé quoi. Quand une information arrivait dans mes notes, impossible de savoir si elle venait d'une décision que j'avais prise ou d'une déduction de l'assistant.
La mémoire se remplissait de suppositions. Un assistant qui choisit lui-même ce qu'il retient finit par prendre ses hypothèses pour des faits.
Ce que j'ai mis en place
Plutôt qu'un assistant, une petite organisation : six rôles, chacun avec son périmètre, ses responsabilités et la liste de ce qu'il ne peut pas faire.
- Un chef d'orchestre reçoit la demande, ne garde que le contexte utile et l'envoie au bon rôle. Il ne traite rien lui-même.
- Deux responsables de domaine, l'un pour le privé, l'autre pour les projets. Ils n'ont aucun accès l'un à l'autre.
- Trois experts interviennent sans diriger personne : un contrôleur qui vérifie la qualité et la sécurité, un rôle qui transforme une demande floue en consigne claire, et un responsable des outils qui regarde ce qui existe déjà avant d'ajouter quoi que ce soit.
Ce qui rend le système fiable
Ce n'est pas le nombre d'assistants, c'est ce qui est écrit pour chacun sur ce qu'il n'a pas le droit de faire.
Le responsable du privé ne voit pas les projets, et inversement. Le contrôleur n'a aucun accès permanent : il reçoit un accès limité, le temps d'un contrôle. Et une règle vaut pour tous : aucun assistant ne peut décider seul qu'une information devient officielle. Il propose, je valide.
C'est le même principe que les droits d'accès dans une entreprise, appliqué à des assistants. Et pour qui veut déployer l'IA dans plusieurs services, c'est la vraie question : est-ce que le système peut déraper ?
Voir les détails techniques
Le registre
L'organisation est décrite dans un registre versionné qui fait foi. Pour chaque rôle : un identifiant, son domaine, ce qu'il peut consulter, qui il peut appeler, qui peut l'appeler, ses responsabilités et ses interdictions. Les quinze sous-agents dépendent chacun d'un seul rôle et ne peuvent pas être appelés depuis un autre domaine.
L'aiguillage
Le chef d'orchestre ne traite pas les demandes, il les transmet avec le contexte strictement nécessaire. Une demande ambiguë est renvoyée pour être précisée, plutôt que traitée à peu près par le rôle le plus proche.
Les tests
Ils vérifient que chaque demande part au bon endroit, et surtout qu'une demande hors périmètre est refusée. Vérifier qu'un responsable ne peut pas lire l'espace de l'autre compte plus que vérifier qu'il lit bien le sien.
Chiffres
6
rôles
un chef d'orchestre, deux responsables de domaine et trois experts transversaux
Source · registre d'architecture le-doyen-v1
15
sous-agents
cinq pour le domaine privé, dix pour les projets
Source · registre d'architecture le-doyen-v1
11
règles communes
valables pour tous les rôles, quel que soit leur domaine
Source · registre d'architecture le-doyen-v1
19
outils recensés
inventoriés et réutilisés avant d'en ajouter un nouveau
Source · registre des capacités
Ce que j'ai fait
Architecture
J'ai découpé le système en un chef d'orchestre, deux responsables de domaine et trois experts transversaux.
Conception des agents
J'ai défini pour chacun des six rôles et des quinze sous-agents ce qu'il peut faire, qui il peut appeler et ce qui lui est interdit.
Création des règles
J'ai écrit les onze règles communes, dont l'interdiction pour tout assistant de valider seul une information.
Développement assisté
Le serveur et l'aiguillage des demandes ont été écrits en TypeScript avec Claude Code et Codex, sous ma supervision.
Tests
J'ai défini les scénarios à tester, en particulier ceux où une demande doit être refusée.
Documentation
J'ai tenu un registre qui fait foi sur les rôles et les règles.
Preuves
Un registre qui fait foi
vérifiéUn seul fichier décrit les rôles, ce que chacun peut consulter, qui il peut appeler et ce qui lui est interdit. Aucun assistant ne peut s'inventer un périmètre.
- Source
- agent-registry.json, schéma versionné
- Vérifiable par
- Lecture du registre et comparaison avec le comportement réel du système.
Des interdictions écrites pour chaque rôle
vérifiéLe responsable du domaine privé n'a aucun accès aux projets, et inversement. Le contrôleur n'a aucun accès permanent.
- Source
- champ restrictions du registre d'architecture
- Vérifiable par
- Lecture du registre, puis vérification que les tests refusent bien les accès croisés.
Des scénarios testés
vérifiéDes tests vérifient qu'une demande part vers le bon rôle, et qu'une demande hors périmètre est refusée plutôt que traitée à peu près.
- Source
- suite de tests du système, fichiers de scénarios Doyen et Lucius
- Vérifiable par
- Exécution de la suite le 30 septembre 2026 : 24 scénarios de routage et 12 scénarios de capacités, tous passants.
Limites
- L'interface de supervision n'est encore qu'un prototype. Aujourd'hui, le système se pilote surtout en ligne de commande et depuis l'éditeur.
- Certaines intégrations ne sont pas terminées.
- Le système dépend d'outils externes : si un fournisseur de modèles change ses interfaces, une partie est à reprendre.
- Il est prévu pour beaucoup plus d'informations qu'il n'en contient aujourd'hui. Il prend de la valeur avec l'usage.
- C'est un système personnel, il n'a pas été testé avec plusieurs utilisateurs.
Ce que j'en retiens
- La bonne question n'est pas « que peut faire cet assistant ? » mais « qu'est-ce qui doit lui être impossible ? ». Écrire les interdictions avant les capacités change toute la conception.
- Un chef d'orchestre qui aiguille sans tout mélanger vaut mieux qu'un assistant qui sait tout. On perd un peu de confort, on évite beaucoup d'erreurs.
- Retirer à tous les assistants le droit de valider une information, c'est ce qui rend le système fiable dans la durée.
Ce que ça peut apporter à une entreprise
- Une équipe commerciale peut séparer de la même façon les comptes clients, les décisions internes et les contrats, avec des droits différents pour chacun.
- Une entreprise qui déploie des assistants IA dans plusieurs services peut écrire les interdictions de chacun, pour qu'aucun ne déborde sur le périmètre d'un autre.
- Toute organisation qui doit garder une trace de ses décisions peut imposer une validation humaine avant qu'une information devienne officielle.
Technologies
- TypeScript
- Node.js
- Model Context Protocol
- Zod
- Vitest
- Obsidian