La couche manquante : structurer les agents IA pour les hiérarchies organisationnelles

Un modèle de référence pour la façon dont les organisations structurent leur travail avec l'IA

Jose Martinez · 1 octobre 2026 · v1.8.1 (mesuré dans Claude Code ; revérifié par rapport à la documentation d'Anthropic le 1 octobre 2026)

En cinq lignes.

1. Les organisations sont des arbres : entreprise, ligne métier, projet, tâche. Les projets de Claude sont plats : le chat dispose d'un seul bloc organisationnel de 3 000 caractères, les projets dans le chat et Cowork ne s'imbrquent pas et n'héritent pas les uns des autres, et au sein d'un projet, un compte de connecteur appartient à une personne ou à toute l'organisation, jamais à une branche.

1. Résultat : chaque projet reçoit une copie artisanale des règles de sa ligne métier, ces copies divergent avec le temps, et personne ne peut voir quelle règle a produit une réponse.

1. Anthropic a déjà construit cet arbre à deux reprises. Claude Code imbrique les instructions par dossier et, depuis le 1 octobre 2026, il exécute les mods de l'organisation avant ceux de l'utilisateur. Claude Tag, dans Slack, hérite des instructions et des identifiants de l'organisation vers l'espace de travail, puis vers le canal. Aucun des deux n'atteint le niveau du projet. Le même modèle pourrait y parvenir : une couche « ligne métier », des projets générés depuis leurs dossiers, des tâches typées, un compilateur qui rejette les conflits avant que le modèle ne les voie, et des autorisations par nœud fonctionnant sur Team.

1. Je l'ai mesuré dans Claude Code, à deux reprises. Une règle d'organisation et une règle de projet contradictoires, placées à des niveaux CLAUDE.md distincts et aucune marquée comme contraignante : la règle du projet l'a emporté 20 fois sur 20. La même règle d'organisation marquée comme appliquée, mais uniquement par des mots : elle l'a emporté 20 fois sur 20. La priorité était dictée par une formulation que n'importe qui modifiant n'importe quelle couche peut changer, et non par la structure.

1. Cela fonctionne aujourd'hui. Une application de bureau que j'ai développée exécute Claude Code à l'intérieur de l'arbre. Elle monte chaque couche sous forme de fichier CLAUDE.md, limite Claude à ce que la personne est autorisée à faire sur ce nœud, rejette le conflit dès son écriture et journalise chaque réponse avec ses règles, ses tokens et son relecteur. Lors des mesures, l'arbre a chargé 20 à 34 % de tokens d'instruction en moins que les copies plates.

Les organisations sont des arbres. L'entreprise définit la politique générale, la ligne métier fixe ses standards, un projet les applique à une mission précise, et une tâche livre un résultat concret. Tous les systèmes qualité dans lesquels j'ai travaillé sont construits ainsi, tout comme l'arborescence de presque tous les serveurs de fichiers d'entreprise : entreprise, ligne métier, année, puis un dossier par mission, nommé avec un numéro de projet qui encode toutes ces informations.

Les projets d'IA sont plats. Je prends Claude comme exemple car c'est le produit que j'utilise au quotidien, et parce qu'il intègre déjà la réponse dans deux de ses propres interfaces. Dans le chat de Claude, les projets ne peuvent pas être imbriqués, et les instructions de l'organisation forment un bloc unique de 3 000 caractères maximum qui s'applique à tout le monde. Sur Enterprise, les administrateurs peuvent restreindre les autorisations par groupe. Sur Team, les rôles s'appliquent à toute l'organisation. Rien de ce qui est documenté dans le chat ou Cowork ne fait descendre les instructions jusqu'à un département ou une ligne métier, puis jusqu'à ses projets. Sur Enterprise, les compétences et les projets peuvent être partagés avec un groupe, mais il s'agit de distribution, pas d'héritage.

C'est la couche manquante : celle située entre l'organisation et le projet. Cet article détaille ce qui manque, pourquoi c'est important, ce que cela coûte réellement, et propose un modèle de référence que n'importe quelle plateforme pourrait implémenter, y compris ses autorisations et sa structure de données.

1. Ce qui existe aujourd'hui

Vérifié par rapport à la documentation d'Anthropic du 29 septembre au 1 octobre 2026. Claude dispose de quatre interfaces où le travail d'une équipe s'exécute, et chacune possède son propre modèle d'instructions :

Les autorisations dépendent de l'offre :

Anthropic a construit la moitié de l'arbre pour les autorisations. Sur Enterprise, des rôles personnalisés sont attribués aux groupes ; « les rôles personnalisés contrôlent également quels connecteurs, et quels outils sur ces connecteurs, un rôle peut utiliser » ; sur l'ensemble de la plateforme, entre les niveaux organisation, rôle et utilisateur, « le niveau le plus restrictif l'emporte », tandis que les différents rôles d'un membre se cumulent ; les administrateurs peuvent « Afficher le rôle effectif », avec une mention « Accordé par » ; et les groupes peuvent avoir leurs propres limites de dépenses. Mais ce sont des groupes plats, pas un arbre, et rien de tout cela n'atteint les instructions. Ce qui s'en rapproche le plus, ce sont les plugins : sur Enterprise, un propriétaire peut rendre un plugin et ses compétences obligatoires ou installés par défaut pour un groupe, selon un ordre défini (« paramètre du groupe, puis paramètre de l'organisation, puis valeur par défaut de la marketplace »). Cela cible un groupe de personnes, pas un projet, rien ne s'hérite entre les projets, et une compétence ne se charge toujours que lorsque Claude la juge pertinente. Team propose des rôles pour toute l'organisation et un partage individu par individu ; ses paramètres de plugin n'ont, selon les termes de la documentation, « aucun paramètre de groupe ». Et Team est justement l'offre conçue pour les petites et moyennes entreprises.

Anthropic a construit l'arbre entier à deux reprises, en dehors des projets.

Dans Claude Code, par dossier. Claude Code charge les fichiers CLAUDE.md depuis quatre niveaux ; « tous les fichiers découverts sont concaténés dans le contexte plutôt que de s'écraser mutuellement », ordonnés « de la racine du système de fichiers jusqu'à votre répertoire de travail », et les fichiers des sous-répertoires « se chargent à la demande ». Le bloc d'une organisation peut arriver sous forme de fichier géré sur chaque machine ou de texte provenant de la console d'administration (la clé claudeMd). La documentation est franche quant à cette limite : Claude traite ces fichiers « comme du contexte, et non comme une configuration imposée », et « si deux instructions se contredisent, Claude peut en choisir une arbitrairement. »

Dans Claude Tag, par canal Slack. Claude Tag, c'est Claude intégré au Slack d'une équipe, en bêta publique sur Team et Enterprise. Ses paramètres sont rattachés à une portée, et « une portée est l'endroit où un bundle s'applique : accès Slack par défaut (la racine à l'échelle de l'organisation), un espace de travail ou un canal unique. » Trois éléments réclamés dans le reste de cet article sont déjà présents :

• Les instructions s'héritent. « Les instructions personnalisées par portée sont concaténées : d'abord l'accès Slack par défaut, puis l'espace de travail, enfin le canal. Les instructions d'un canal s'ajoutent à celles définies au-dessus, au lieu de les remplacer. »

• Les identifiants appartiennent à la branche. Dans les canaux, Claude agit via des comptes de service qu'un administrateur attache à une portée, et « l'identifiant de la portée la plus restreinte est utilisé : le canal l'emporte sur l'espace de travail, qui l'emporte sur l'accès Slack par défaut. »

• Vous pouvez voir d'où provient l'accès. Chaque ligne de connecteur, de dépôt et de plugin indique « Hérité de » une portée plus large ou « Attaché depuis » un bundle. Les dépenses sont plafonnées pour l'organisation et par canal, et rapportées par canal.

Les limites sont elles aussi documentées. L'arbre épouse la forme de Slack : trois niveaux fixes, et les canaux Slack ne s'imbrquent pas. Les instructions constituent « un guide, et non un garde-fou imposé », et la documentation ne décrit aucune vérification des conflits entre les portées. Il n'y a « aucun journal par action de chaque tâche et de son demandeur ». Et cela s'arrête aux portes d'un projet : « Les projets dans claude.ai ne s'appliquent pas ici ; Claude ne lit pas les instructions ni les connaissances d'un projet dans Slack, et un canal ne peut pas être pointé vers un projet. »

Ce qui a changé le 1 octobre 2026. Claude Code 2.1.287 a activé les mods, auparavant en accès anticipé : des fonctions au sein d'un plugin qui s'exécutent dans Claude Code et peuvent réécrire un prompt ou une section du prompt système, bloquer ou modifier un appel d'outil, approuver ou refuser une demande d'autorisation, et afficher des panneaux dans l'interface. Trois aspects nous intéressent ici :

• Ils suivent un ordre déclaré. Un garde-fou intégré et les mods propres à l'organisation s'exécutent en premier, puis viennent les mods installés par l'utilisateur. « Le premier mod est le plus externe : il voit l'événement avant les autres et le résultat après eux, et décide si les autres s'exécutent ou non. » Là où le garde-fou est chargé (une machine avec des paramètres gérés, ou une connexion Team ou Enterprise), le mod d'un utilisateur ne peut pas modifier « le prompt système, votre CLAUDE.md géré et les autres instructions gérées », et il ne peut pas approuver un appel d'outil qu'une règle de refus bloque. C'est une priorité définie par la structure, exactement ce que réclame cet article. Il s'agit d'un comportement par défaut, pas d'un verrou : une personne qui lance Claude Code avec --safe-mode s'exécute sans les mods installés, y compris ceux de l'organisation, tandis que les hooks gérés et les règles de refus continuent de s'appliquer.

• L'ordre a deux propriétaires. Les mods de l'organisation s'exécutent avant ceux de l'utilisateur, ou après si l'organisation le décide. Il n'y a pas de niveau pour une ligne métier. Les paramètres diffusés depuis la console d'administration « s'appliquent uniformément à tous les utilisateurs de l'organisation. Les configurations par groupe ne sont pas encore prises en charge. » Une organisation souhaitant une politique différente par groupe dispose de deux options, toutes deux via le service informatique : déployer un fichier de paramètres différent sur les machines de chaque groupe, ou exécuter une passerelle auto-hébergée qui « diffuse des paramètres gérés par groupe IdP ».

• Ils n'atteignent pas le chat, et Cowork de manière inégale. « Les mods fonctionnent dans l'interface CLI de Claude Code et dans l'onglet Code de l'application de bureau Claude. » Un mod est livré dans le fichier hooks/hooks.json d'un plugin, et le tableau de compatibilité des plugins d'Anthropic indique que ce fichier est « Ignoré » dans le chat. Le même tableau indique qu'il « Se charge » dans Cowork, car « Cowork dans l'application de bureau Claude exécute ses sessions sur Claude Code » ; les pages de documentation des mods ne mentionnent pas Cowork, et je ne l'ai pas testé. Le contrôle de l'organisation y est plus limité : dans une session Cowork, Claude Code « ne récupère jamais les paramètres gérés par le serveur depuis la console d'administration claude.ai, même lorsque l'utilisateur se connecte avec un compte Team ou Enterprise », et les sessions Cowork distantes n'ont aucune stratégie d'appareil à lire.

Ce qui est en cours de déploiement. Cowork fusionne avec Claude : le centre d'aide indique désormais que « Claude Cowork est maintenant simplement Claude », d'abord sur Pro et Max, tandis que Team et Enterprise « conservent le chat et Claude Cowork tels qu'ils sont aujourd'hui ». Le 6 octobre 2026, les nouvelles tâches Cowork sur Pro et Max passeront dans le cloud. Et une nouvelle version des projets est en bêta publique sur Pro et Max, en commençant par Claude Code, le chat, Cowork, Team et Enterprise suivront ; dans cette version, « un projet est une conversation » que Claude divise en fils parallèles. Cela reste un niveau unique : « Un projet appartient à un utilisateur », et « il n'y a pas de contrôles au niveau de l'organisation pour les projets pendant la bêta. »

L'arbre n'est donc pas une idée nouvelle pour Anthropic. Il existe par dossier pour le code et par canal pour Slack, et dans les deux cas, l'organisation passe en premier. L'endroit où une entreprise classe son travail, le projet, n'a ni parent ni hiérarchie supérieure. Deux autres offres d'Anthropic vont dans le même sens et sortent du cadre de cet article : Claude for Government résout les paramètres via une chaîne locataire, groupe et organisation, et Claude Desktop chez des fournisseurs tiers propose des politiques par groupe en bêta.

2. Pourquoi c'est important

Les projets ne sont pas des conteneurs. Une véritable mission est un conteneur. Elle possède une clé (le numéro de projet), un parent (sa ligne métier), un cycle de vie (ouverte, clôturée, archivée par année), un dossier, un client, des collaborateurs, des règles et des livrables. Un projet Claude a un nom en texte libre, aucune clé, aucun parent ni enfant, et son cycle de vie documenté se limite à l'archivage et à la suppression. Cowork peut lier un projet à un dossier local, mais uniquement à la main, un projet à la fois, sans modèle de clé ni parent. Une ligne métier peut ouvrir des centaines de missions par an. Il ne reste alors que deux mauvaises options : un projet Claude créé à la main par mission, chacun avec sa propre copie des règles, ou un projet par ligne métier, où les contextes de différents clients cohabitent.

Le chemin de charge est rompu. En ingénierie structurelle, chaque charge nécessite un chemin continu jusqu'aux fondations. Retirez un élément et rien de ce qui se trouve au-dessus ne se transmet vers le bas. Les règles fonctionnent de la même manière. Lorsqu'il n'y a pas de couche entre l'organisation et le projet, les standards, modèles et règles de validation d'une ligne métier n'ont nulle part où vivre. Chaque projet reçoit donc une copie artisanale.

Les copies divergent. Corrigez une règle dans un projet, et les autres conservent l'ancienne version. Chaque projet continue de passer son propre contrôle local. Le décalage n'apparaît que lorsque quelqu'un compare les projets côte à côte, et dans les secteurs réglementés, c'est généralement un auditeur. Les équipes d'infrastructure connaissent bien cette défaillance. Dans l'étude 2026 de Firefly, environ un tiers des répondants ont lié la dérive de configuration à des incidents de production coûteux, et près d'un sur cinq n'avait aucun processus pour la détecter ou la corriger.

L'identité est plate, elle aussi. De nombreuses personnes travaillent pour plusieurs organisations, et chacune a besoin de son propre contexte étanche. À l'intérieur de n'importe laquelle d'entre elles, dans le chat et Cowork, un compte de connecteur appartient à une personne, pas à une branche. Les rôles Enterprise peuvent décider quels connecteurs un groupe est autorisé à utiliser, et un administrateur peut autoriser un connecteur une seule fois pour toute l'organisation ; un connecteur personnalisé peut même porter un identifiant partagé pour tout le monde (en bêta). Dans tous les cas, le compte est celui de la personne ou de l'organisation, jamais celui d'une branche : un consultant servant deux clients ne peut pas lier le Drive de chaque client aux projets de ce client. Les projets partagés accentuent le problème : « Les connecteurs ne sont disponibles que dans les projets privés. » Claude Tag prouve qu'une autre conception est possible, avec un compte de service attaché à un canal Slack, et montre aussi où elle s'arrête : au projet. La page du connecteur Google d'Anthropic décrit un seul compte Google connecté, et la méthode documentée pour en changer consiste à se déconnecter puis se reconnecter ; trois tickets ouverts (ci-dessous) réclament la prise en charge de plusieurs comptes. La frontière vit dans la tête de l'utilisateur, ce qui est précisément le genre de limite manuelle qui échoue silencieusement.

Personne ne peut voir quelle règle s'est appliquée. Claude Enterprise montre aux administrateurs une option « Afficher le rôle effectif » pour les autorisations, et la commande /context de Claude Code liste les fichiers mémoire chargés. Un mod Claude Code peut désormais afficher son propre panneau, une vue des instructions effectives est donc réalisable par n'importe qui. Claude Tag étiquette chaque connecteur et dépôt avec la portée dont il a hérité, mais pour les instructions, sa documentation suggère de « demander à Claude de répéter ses instructions d'administration ». Aucune interface ne montre, pour une réponse donnée, quelle instruction provient de quelle couche. Sans provenance, il n'y a pas de piste d'audit, et sans piste d'audit, il n'y a pas de système qualité.

Les utilisateurs réclament des morceaux de tout cela. Tickets ouverts dans le tracker public d'Anthropic (github.com/anthropics/claude-code), vérifiés le 2026-10-01 :

Un septième, #47741, demandait un fichier CLAUDE.md géré par l'organisation et a été fermé car Claude Code en possède déjà un. C'est tout l'enjeu : les couches existent dans Code et dans Slack, et les tickets les réclament là où se trouvent les projets.

3. Ce que cela coûte, et ce que le token masque

3.1 Les tokens ne sont pas l'obstacle

Plus de couches pourraient signifier plus de contexte à chaque message, et l'IA est facturée au token. Cette explication n'est que partiellement exacte. Sur les offres Enterprise facturées à l'usage, la consommation est facturée aux tarifs de l'API, donc plus de contexte signifie plus de revenus, et non moins. Sur Team, les licences sont forfaitaires sauf si l'utilisation supplémentaire est activée, et les tokens supplémentaires se traduisent par des membres atteignant plus vite leur limite hebdomadaire. Et Claude Code, facturé avec ces mêmes tokens, propose déjà une cascade à quatre niveaux. Si les tokens étaient l'obstacle, cela n'existerait pas. Mesuré dans la section 3.2, le prompt système et les outils propres à Claude Code représentaient environ 30 200 tokens avant même nos instructions ; les instructions complètes d'un projet y ajoutaient 3,5 à 5,2 %.

3.2 Un exemple chiffré

Légendes sur chaque image : RÉEL = mesuré, ou vérifié par rapport à la documentation d'Anthropic, entre le 29 septembre et le 1 octobre 2026 ; EST = simulé ; IND = illustratif.

D'abord les mesures. J'ai posé la même question dans Claude Code (claude -p, Claude Sonnet 5.5) sur un projet de démonstration, cinq fois par condition, et j'ai relevé les tokens d'entrée rapportés par Claude Code lui-même. J'ai effectué le test sur Claude Code 2.1.286 le 30 septembre, puis de nouveau sur la version 2.1.287 le 1 octobre ; les décomptes d'instructions étaient identiques. En soustrayant une exécution sans aucune instruction de projet, on obtient le coût de chaque architecture :

Deux éléments que la simulation ci-dessous ne pouvait pas montrer. La cascade coûte 224 tokens de plus que le fichier compilé pour les mêmes règles : chaque fichier supplémentaire entraîne une surcharge, ici le marqueur et l'en-tête propres à l'application sur le fichier de chaque niveau, plus l'encadrement ajouté par Claude Code autour de chaque fichier chargé. Plus il y a de niveaux, plus la surcharge augmente. Et Claude Code a en réalité chargé 21 à 26 % de plus que ce qu'estimait le tokenizer public, même multiplié par 1,30 ; une partie de cet écart vient de cette même surcharge par fichier. Les ratios y résistent, pas les montants absolus en dollars : considérez donc les chiffres de la simulation comme des minimums.

Puis une simulation à l'échelle d'un cabinet. J'ai simulé un mois de tokens d'instruction pour un cabinet fictif : 40 personnes réparties sur trois lignes métier, 250 projets actifs, six types de rapports par ligne, 35 messages par personne et par jour ouvré lors de sessions de cinq, soit 29 400 messages au total. Les tailles en tokens ont été comptées sur des textes d'instruction échantillons avec le tokenizer public historique d'Anthropic (qu'Anthropic qualifie lui-même d'« approximation très grossière » pour Claude 3 et versions ultérieures) et multipliées par 1,30 pour le tokenizer de Claude 4.7+. Le bloc organisation est extrapolé d'un échantillon de 597 caractères jusqu'au plafond de 3 000 caractères, et le manuel de ligne métier correspond au triple d'un échantillon de 953 caractères. Les prix sont ceux de la grille tarifaire de Claude Sonnet 5.5 (entrée à 2 $, écriture dans le cache de 5 minutes à 2,50 $, lecture du cache à 0,20 $ par million de tokens). Le cache de prompt dure cinq minutes et est rafraîchi à chaque accès.

• Plat (la solution de contournement actuelle) : le bloc organisation, puis la copie propre à chaque projet du manuel de ligne métier, les six modèles de rapports et les spécificités du projet.

• Arbre : organisation, ligne métier, uniquement le modèle de rapport utilisé, puis les spécificités du projet, compilés en plaçant d'abord les éléments les plus partagés.

Tailles derrière le tableau : bloc organisation 830 tokens (3 000 caractères), manuel de ligne métier 729, un modèle de rapport 147, spécificités du projet 98 (valeurs arrondies ; les totaux ont été calculés avant arrondi). La simulation ignore le prompt système propre à Claude, qui précède le bloc organisation.

Deux mises en garde honnêtes. Premièrement, l'arbre ne permet pas d'économiser des tokens à lui seul. Les −29 % proviennent des tâches typées : seul le modèle du rapport en cours de rédaction est chargé, et non les six. Les −62 % viennent principalement de la compilation des couches les plus partagées en premier, de sorte que des centaines de projets partagent un préfixe identique à l'octet près : le simple tri, avec les six modèles toujours chargés, fait passer le coût du cache partagé de 36 $ à 18 $ (−51 %), et les tâches typées fournissent le reste. Cette seconde économie n'existe que si le cache est partagé entre les utilisateurs. Sur l'API Claude, les caches sont isolés entre les organisations et, au sein d'une même organisation, par espace de travail ; les préfixes identiques sont donc réutilisés entre les requêtes d'un même espace de travail. Pour claude.ai, ce n'est pas documenté. Cela ne se produit pas dans la version actuelle de Claude Code : là, « le cache est effectivement limité à une machine et un répertoire », donc deux personnes dans deux dossiers de projets distincts ne profitent pas du cache de l'autre. Lisez la dernière colonne comme ce qu'une couche native dans le chat pourrait apporter, et non comme quelque chose de disponible aujourd'hui. Une objection légitime : les Skills se chargent déjà à la demande, donc un espace de travail plat qui déplace ses modèles vers les Skills obtient dès aujourd'hui une partie des −29 %. Ce qui manque aux Skills dans le chat et Cowork, c'est la portée et l'héritage : une compétence ne peut pas appartenir à une ligne métier et descendre vers les projets de cette ligne. (Dans Claude Code, une compétence située dans un sous-dossier se charge bien pour les sessions démarrées dans ce dossier ou en dessous.) Deuxièmement, il ne s'agit que des tokens d'instruction, et à cette échelle, ils représentent de 14 $ à 149 $ par mois selon la mise en cache. L'historique des conversations et les sorties dominent les factures réelles. L'argument fort en faveur de l'arbre est l'exactitude et, sur Team, la capacité. Ce n'est pas la facture.

La mesure ci-dessus reproduit l'effet des tâches typées sur un véritable arbre, dans Claude Code, au lieu de tailles supposées : −20 % en cascade et −34 % compilé, contre les −29 % de la simulation. Une ligne métier avec un seul type de tâche n'économiserait rien grâce aux tâches typées.

3.3 La même réponse, avec le vrai Claude

J'ai posé la même question quarante fois à Claude Code : dix réponses indépendantes sous chacune des quatre conditions, en deux séries de cinq espacées d'une journée. La question portait sur la réussite d'un essai de densité in situ sur une couche de forme, à 112,3 pcf pour une densité sèche maximale de 115,8 pcf avec 98 % requis. Les instructions étaient soit les six règles du cabinet, soit un prompt d'une ligne de type « assistant utile », et la langue était l'anglais ou l'espagnol. Les quarante réponses ont abouti à la même conclusion : 97,0 %, échec.

Claude Code rapporte deux valeurs en sortie : les tokens facturés, et la part correspondant à la réflexion que le lecteur ne voit jamais.

Quatre constats :

• Les règles du cabinet ont rendu les réponses 1,4 fois plus longues à l'écran, et 1,8 à 1,9 fois plus longues sur la facture. L'excédent visible correspondait aux sections de signalements, normes et limitations exigées par les règles. Dans un système qualité, c'est la partie qui a de la valeur.

• Avec les règles du cabinet, plus d'un tiers de la sortie facturée était invisible. 37 % des tokens de sortie facturés correspondaient à la réflexion, contre 16 % avec le prompt simple. En anglais, le lecteur voit 447 tokens et en paie 711.

• L'espagnol a coûté 1,2 fois plus de tokens visibles que l'anglais pour des réponses dont la longueur en mots variait de moins de 4 %. Mesurées de la même façon, les règles du cabinet ont consommé 1,53 fois plus de tokens d'entrée lorsqu'elles étaient rédigées en espagnol.

• La même conclusion a été facturée de 317 à 953 tokens, soit trois fois plus pour la réponse la plus longue que pour la plus courte. Une facturation au token ne permet pas de distinguer la rigueur du remplissage. Des critères d'acceptation, si.

Ces ratios varient entre les séries de cinq. Le ratio à l'écran pour les règles du cabinet était de 1,43 à 1,52 dans la première série et de 1,27 à 1,31 dans la seconde ; le ratio facturé était de 1,78 à 1,82 puis de 1,70 à 2,05 ; le ratio de l'espagnol était de 1,29 à 1,38 puis de 1,14 à 1,18. La tendance n'a jamais changé. L'ordre de grandeur est fiable à un chiffre significatif près.

Méthode : Claude Code 2.1.286 le 2026-09-30 et 2.1.287 le 2026-10-01, claude -p --output-format json, Claude Sonnet 5.5. Tous les outils ont été désactivés et les fichiers personnels ~/.claude exclus, de sorte que seules les instructions déclarées différaient entre les conditions. Les décomptes de tokens proviennent du rapport d'utilisation propre à Claude Code, y compris thinking_tokens ; le coût mensuel applique le tarif de 10 $ par million de tokens de sortie de Sonnet 5.5 à la moyenne facturée. Le script de mesure, les deux séries, les chiffres consolidés et chaque réponse sont conservés par l'auteur et disponibles sur demande. La première version de cet article estimait ces chiffres avec des sous-agents et le tokenizer public ; ces estimations sont désormais obsolètes.

3.4 Quand les règles entrent en conflit, c'est la formulation qui décide

La documentation d'Anthropic admet que des instructions contradictoires peuvent être résolues « arbitrairement ». J'ai testé un conflit typique de ceux qu'engendre l'absence de couche « ligne métier ». La règle de l'organisation imposait les unités impériales américaines ; une règle de projet exigeait de rapporter les densités en unités SI. Je les ai placées comme le ferait un arbre : la règle de l'organisation dans un CLAUDE.md à la racine du stockage, la règle du projet dans un CLAUDE.md du dossier du projet, toutes deux chargées par la cascade native de Claude Code. Puis j'ai relancé le même dispositif avec la règle de l'organisation marquée comme contraignante, uniquement par des mots : la balise ENFORCED dans son libellé et une phrase ajoutée, « Cette règle est imposée : aucune règle de ligne métier ou de projet ne peut la remplacer. » Chaque configuration a été exécutée dix fois le 30 septembre et dix autres fois le 1 octobre.

Ce n'était pas arbitraire. Sans contrainte déclarée, Claude a choisi à chaque fois la règle la plus proche et la plus spécifique. Quatorze des vingt réponses expliquaient pourquoi (« cette règle est plus spécifique que la règle impériale applicable à tout le cabinet », ou qu'elle écrase la règle du cabinet) ; cinq citaient uniquement la règle du projet sans jamais mentionner le désaccord avec celle du cabinet. Avec la contrainte formulée en toutes lettres, la règle de l'organisation l'a emporté à chaque fois, et chaque réponse précisait que la règle contraignante du cabinet avait priorité. La deuxième série a reproduit les unités choisies, 10 fois sur 10 à chaque fois, et l'écart entre les deux lignes est bien trop grand pour relever du hasard (test exact de Fisher, p < 0,0001). Les explications se sont montrées moins constantes : neuf réponses sur dix justifiaient la victoire de la règle du projet dans la première série, contre cinq sur dix dans la seconde.

C’est une bonne nouvelle pour le modèle, mais une mauvaise pour l’espace de travail. La priorité existe bel et bien, mais elle réside dans la formulation des règles, que toute personne modifiant n’importe quelle couche peut changer, et que personne ne passe en revue comme une décision de priorité. Et lorsque la règle inférieure l’a emporté, un quart des réponses n’ont pas indiqué au lecteur qu’une règle supérieure avait été écartée. Un test pilote mené pour la première version de cet article, avec les deux règles réunies dans une seule invite au lieu d’une cascade, a également vu ses résultats varier selon leur simple ordre (règle organisationnelle en premier : SI 5 sur 5 ; règle organisationnelle en dernier : SI 2 sur 5, et 3 sur 5 ont fourni les deux unités ou demandé laquelle appliquer).

Aucun modèle ne devrait être chargé de trancher un conflit que l’organisation aurait pu détecter dès la rédaction de la règle. Claude Code apporte deux réponses partielles. /doctor prompt-audit demande à Claude de repérer les fichiers d’instructions qui se contredisent, lorsqu’un utilisateur lance la commande. Et depuis le 1er octobre, un mod peut imposer un ordre dans le code : les mods de l’organisation s’exécutent avant ceux de l’utilisateur et, là où la garde intégrée se charge, les règles de refus (deny) priment sur le mod d’un utilisateur. Aucun des deux ne couvre le texte des instructions. Les fichiers d’instructions sont toujours concaténés, et la documentation décrit le résultat de trois manières : Claude « peut en choisir un arbitrairement » ; lorsqu’une règle utilisateur et une règle de projet entrent en conflit, « Claude peut suivre l’une ou l’autre » ; et « lorsque les instructions sont contradictoires, Claude fait appel à son jugement pour les concilier ». Le résultat de vingt sur vingt illustre précisément ce jugement. Claude Tag déclare un ordre pour ses trois portées et qualifie le résultat d’« orientation, et non de garde-fou appliqué ». Le contrôle de l’implémentation de référence rejette exactement cette modification, « R-22 définit units.density=SI ; R-01 (org:firm) impose US », avant même que quoi que ce soit n’atteigne Claude, et enforced est un champ de la règle, pas une phrase qu’elle contient.

La densité des instructions aggrave la situation. Dans le benchmark IFScale (2025), la précision de Claude Sonnet 4 est passée de 100 % avec 10 instructions simultanées à 42,9 % avec 500.

3.5 Le calcul ou l’énergie seraient-ils des unités plus justes ?

Le token est un indicateur raisonnable du calcul au sein d’un même modèle : plus de tokens signifient réellement plus de travail pour le matériel. C’est aussi pourquoi une tarification basée sur le calcul ou l’énergie ne corrigerait pas la pénalité linguistique. L’espagnol coûte plus cher parce que le tokenizer le compresse moins, et ces tokens supplémentaires représentent un véritable coût de calcul. La solution passe par un meilleur tokenizer ou par une facturation normalisée selon le contenu.

Une unité de calcul normalisée aiderait tout de même sur trois points. Elle rendrait comparables les différents modèles et fournisseurs. Elle serait physique et déclarable, par exemple pour les rapports de durabilité. Et si le coefficient est fixé par rapport à un matériel de référence, le fournisseur conserve ses propres gains d’efficacité, ce qui constitue la bonne incitation. Il existe des précédents : les fournisseurs cloud vendaient autrefois des unités normalisées comme l’EC2 Compute Unit.

Mais cela pose de vrais problèmes. Le client ne peut pas le vérifier sans norme ni auditeur. L’énergie réelle dépend du matériel, de l’efficacité du data center, du traitement par lots et du réseau électrique. De plus, Anthropic ne publie pas la consommation énergétique par requête ; je n’ai trouvé que des estimations tierces. Surtout, le calcul reste une donnée d’entrée. Il ne dit pas si la réponse était correcte.

Ma conclusion tient en trois couches distinctes :

1. Facturer en tokens ou dans une unité de calcul normalisée.

1. Déclarer l’énergie consommée par tâche et par nœud.

1. Piloter selon le coût par résultat vérifié.

Pour Team, l’étape minimale consiste à publier la limite hebdomadaire dans une unité définie. Le quota par session est présenté comme « 1,25 fois le quota d’utilisation par session du plan Pro » ; la limite hebdomadaire, elle, n’a aucun chiffre publié. Impossible de budgétiser l’un ou l’autre.

Comme le résume la FinOps Foundation, « le token est l’unité de facturation, pas l’unité de valeur ». C’est la hiérarchie qui permet de définir la valeur, car c’est là que peuvent résider les critères d’acceptation.

3.6 Les raisons les plus probables pour lesquelles cela n’a pas été construit

1. Priorité implicite. La propre documentation d’Anthropic reconnaît que des instructions directement contradictoires peuvent produire des comportements variables, et la section 3.4 montre que la priorité suit simplement la formulation des règles. Empiler les couches multiplie les conflits, et le respect des instructions se dégrade avec la densité : dans le benchmark IFScale (2025), même les meilleurs modèles testés n’ont atteint que 68 % de précision avec 500 instructions par mots-clés simultanées (le benchmark cité en section 3.4).

1. Héritage des permissions. Si les connaissances descendent dans une arborescence, les accès doivent faire de même. Cela implique de reconstruire le modèle de permissions sous chaque couche.

1. Une préférence pour la mémoire et la récupération plutôt que pour des couches statiques.

1. La simplicité avant tout pour le grand public. Les outils de code héritent gratuitement d’une arborescence via le système de fichiers. Les produits de chat, eux, doivent en inventer une.

Anthropic n’a pas expliqué publiquement pourquoi le chat Claude et Cowork n’ont pas de hiérarchie. Tout ce qui figure dans cette section est déduit de ce qui a été livré.

4. Le modèle de référence

Cette conception s’inspire de systèmes ayant déjà résolu ce problème : les hiérarchies de ressources cloud (AWS Organizations, Google Cloud Org Policy, groupes d’administration Azure), les stratégies d’annuaire (Stratégie de groupe Active Directory) et la propre cascade CLAUDE.md de Claude Code. Les relations entre les nœuds reposent sur cinq termes : contient, hérite, utilise, scellé et partagé.

4.1 Monter l’arborescence que l’organisation possède déjà

Il ne faut pas obliger les utilisateurs à recréer leur organisation au sein de l’espace de travail IA. Le serveur de fichiers ou le système documentaire est déjà la source de vérité. Prenons un chemin :

Le numéro de dossier 26GT301 encode déjà l’arborescence : année, ligne de métier, séquence. L’espace de travail doit monter cette structure, et non la copier.

4.2 Nœuds porteurs de règles, nœuds de regroupement, projets et tâches

• Nœuds porteurs de règles : organisation, ligne de métier, projet, tâche. Chacun porte les mêmes trois éléments : le contexte (instructions et connaissances), la politique (quels outils, données et connecteurs sont autorisés) et les identités (les comptes de connecteur qui y sont liés).

• Nœuds de regroupement : série, année, région. Ils ne portent aucune règle. Ils servent à la navigation, à la rétention et au cycle de vie. Les séparer permet de garder l’arbre des règles peu profond, soit trois à quatre niveaux, comme le recommandent les propres directives de Microsoft pour les groupes d’administration (« pas plus de trois à quatre niveaux »).

• Le projet est un conteneur clé. Il est créé automatiquement : lorsqu’un dossier correspondant au motif de clé de la ligne apparaît (par exemple {YY}GT{NNN}_{Nom} sous la racine de la ligne), un nœud de projet est créé, hérite de sa ligne et obtient un accès connecteur limité à ce seul dossier. Il ne contient que ce qui diffère de sa ligne : membres, client, spécifications. Il passe du statut ouvert à fermé, puis archivé (diagramme 2).

• La tâche est typée. Son type provient du catalogue de la ligne (un rapport de densité, un log de forage). Ce type inclut un modèle et des critères d’acceptation. Le livrable est classé dans le dossier du projet selon la convention de nommage du cabinet, puis un relecteur l’accepte. Les compétences (Skills) sont ce qui se rapproche le plus des types de tâches chez Claude aujourd’hui. Sur Enterprise, elles peuvent être partagées avec un groupe, mais il s’agit de distribution, pas d’héritage : rien ne descend le long d’une branche.

La récursivité est intentionnelle. Le modèle de système viable de Stafford Beer l’énonce clairement : « Dans une structure organisationnelle récursive, tout système viable contient, et est contenu dans, un système viable. »

4.3 Un parent principal, plus des superpositions

Christopher Alexander affirmait en 1965 qu’« une ville n’est pas un arbre ». Les structures réelles se chevauchent. Un client, le cahier des charges d’une agence ou un type de tâche peut couvrir plusieurs lignes de métier. Ainsi, chaque nœud possède un parent principal, et les jeux de règles transversaux s’attachent sous forme de superpositions (utilise). Les conflits se résolvent toujours de la même manière : le refus l’emporte, sinon c’est le nœud le plus proche qui gagne.

4.4 Deux canaux, deux sémantiques

C’est le cœur de la conception, et c’est là que la plupart des hiérarchies échouent.

• Le contexte se concatène. Les instructions et les connaissances fusionnent de la racine vers les feuilles, comme le fait CLAUDE.md.

• La politique fonctionne par refus par défaut. Un outil ou un connecteur n’est autorisé que si une autorisation existe sur tout le chemin depuis la racine, et un refus explicite situé n’importe où au-dessus l’emporte, à l’image des Service Control Policies d’AWS. Un parent peut marquer une règle comme appliquée (enforced), et aucun enfant ne peut la bloquer, comme dans la Stratégie de groupe.

Mélanger les deux est l’erreur classique. Le contexte consultatif doit se fondre. L’application stricte, non.

4.5 Compiler avant que le modèle ne lise

Aujourd’hui, les instructions contradictoires sont arbitrées par le modèle au moment de générer la réponse. La solution est un compilateur d’instructions effectives qui s’exécute avant que le modèle ne voie quoi que ce soit :

1. Fusionner le contexte de la racine jusqu’à la feuille.

1. Appliquer la politique : le refus l’emporte, et une autorisation doit être valable sur tout le chemin.

1. Respecter les règles appliquées (enforced) des parents.

1. Estampiller chaque règle avec un identifiant et sa couche.

1. Ordonner le bloc selon le degré de partage de chaque partie, et appliquer un budget de tokens par couche.

Les conflits n’atteignent jamais cette étape : ils sont rejetés en amont, lors de la rédaction d’une règle, et l’approbation vient d’une personne autre que l’auteur (diagramme 3, voie inférieure).

Puisque les conflits sont résolus à la compilation, le résultat peut être ordonné selon le degré de partage de chaque partie, et non strictement par profondeur : organisation, ligne, modèle de type de tâche, puis spécificités du projet. Cet ordre maximise les succès de cache (section 3.2). Il correspond aux quatre points de rupture de cache d’Anthropic, avec un budget de tokens par couche, même si, en pratique, un point de rupture peut être nécessaire pour la conversation elle-même.

4.6 Des identités liées aux branches, pas aux personnes

L’identité d’un connecteur (compte, locataire, portée) s’attache à un nœud, et non à une personne. Claude Tag fonctionne déjà ainsi pour les canaux Slack : un administrateur lie un compte de service à une portée, et l’identifiant de la portée la plus restreinte l’emporte. Le modèle présenté ici exige la même chose un niveau en dessous, sur une ligne de métier et ses projets. Une personne travaillant dans deux organisations dispose de deux arbres scellés ; elle change d’arbre, pas de compte. Rien ne circule entre eux sauf si les propriétaires des deux le partagent explicitement. La primitive technique existe déjà : la spécification d’autorisation MCP utilise des jetons OAuth liés à une audience (indicateurs de ressource RFC 8707, métadonnées de ressource protégée RFC 9728) et exige que les serveurs « NE DOIVENT PAS accepter ou transmettre d’autres jetons » (version de la spécification du 28/07/2026).

4.7 Les permissions suivent l’arborescence

Principaux : personnes, groupes, comptes de service, invités externes (un client, par exemple) et l’agent lui-même.

L’agent ne dépasse jamais la personne ni le nœud. Claude agit avec les permissions de l’utilisateur qui l’invoque, croisées avec la politique du nœud. Il ne peut pas modifier les règles ou les permissions ; il peut seulement proposer des changements. (Aujourd’hui, Claude peut mettre à jour seul les instructions d’un dossier Cowork. Dans ce modèle, cela devient une proposition qu’une personne doit approuver.)

Évaluation. Les attributions descendent uniquement, jamais vers le haut ou latéralement. La permission effective à un nœud correspond à ce que les rôles de son chemin accordent, dans les limites de ce que la politique autorise sur l’ensemble du chemin, moins tout refus situé au-dessus. Une superposition n’accorde l’accès qu’à son propre contenu : lire une spécification n’ouvre pas les projets qui l’utilisent.

Cycle de vie.

• Ouvert : les rôles s’appliquent tels qu’attribués.

• Fermé : aucune nouvelle tâche, mais les validations en attente peuvent aboutir.

• Archivé : lecture seule pour tous ; seul le propriétaire peut restaurer, et la restauration est journalisée.

• Arbre scellé : rien ne traverse sans partage explicite.

Exceptions et délégation. Les exceptions sont limitées dans le temps, justifiées, et approuvées par quelqu’un d’autre que le demandeur. Elles expirent d’elles-mêmes et sont comptabilisées, car chaque dérogation crée un îlot de maintenance permanent ; les limites d’héritage rompu de SharePoint servent d’avertissement. Une délégation ne peut jamais accorder plus que ce que le délégant possède. L’accès d’urgence (break-glass) du propriétaire existe, est toujours journalisé et fait l’objet d’une révision a posteriori.

Sur Team, cela fonctionne sans groupes : l’attribution réside sur le nœud, de sorte qu’une organisation à quatre rôles obtient tout de même des permissions par branche.

4.8 Comment les couches interagissent

Construire un arbre n’a d’intérêt que si les modifications y circulent. Trois interactions assurent l’essentiel du travail (diagramme 5) :

• Pousser vers le bas. Un responsable de ligne publie une nouvelle version d’une règle. Chaque projet de la ligne la lit lors de sa prochaine compilation. Une exception approuvée conserve l’ancienne version jusqu’à son expiration, et les livrables déjà classés gardent la version avec laquelle ils ont été créés.

• Tirer vers le haut. Un membre améliore un modèle au sein d’un projet et le propose. C’est le responsable de ligne, et non l’auteur de la proposition, qui l’approuve, et les projets frères en héritent. Aujourd’hui, cette amélioration reste cantonnée au projet où elle est née.

• Transversalement. Le cahier des charges d’une agence change une seule fois. Les projets de trois lignes recompilent avec cette modification, sans que les lignes elles-mêmes ne changent. Un conflit avec une règle de ligne est rejeté dès la saisie de la mise à jour.

Une seule requête mobilise toutes les couches à la fois (diagramme 6) : l’arbre vérifie l’attribution du membre et l’état du projet, le compilateur construit le bloc, Claude lit les données terrain via une identité limitée au dossier de ce projet, classe un livrable typé dans le dossier, et un relecteur qui n’en est pas l’auteur l’accepte. Chaque étape atterrit dans le journal, et le coût est imputé à la clé du projet.

4.9 La structure de données

Le provisionnement est piloté par les événements : un nouveau dossier correspondant à key_pattern sous le storage_root d’une ligne crée le nœud de projet. L’answer_log fournit la traçabilité de chaque réponse et le coût par nœud.

4.10 Mesurer les résultats, pas les tokens

Chaque type de tâche comporte des critères d’acceptation : la définition du travail terminé. Avec eux en place, une meilleure unité de mesure du travail de l’IA devient quantifiable :

coût par résultat vérifié = (coût en tokens + temps de relecture) ÷ livrables acceptés

Puisque chaque réponse est journalisée sur un nœud, le coût de l’IA peut être imputé à une clé de projet de la même manière que la main-d’œuvre et les matériaux. Certains éléments existent déjà : Claude Tag signale et plafonne les dépenses par canal, et la télémétrie de Claude Code peut être étiquetée manuellement par département, centre de coûts ou dépôt. Mais rien n’est rattaché à une clé de projet, et rien n’est divisé par les livrables acceptés. Pour un cabinet qui facture au numéro de dossier, l’IA devient un coût direct de mission plutôt qu’une charge générale. En ingénierie, on paie pour le livrable vérifié et scellé, pas pour la mine du crayon. Le travail de l’IA devrait être mesuré de la même façon.

4.11 Objections et réponses

« Les compétences et les plugins font déjà cela. » Une compétence se charge lorsque Claude la juge pertinente, ce qui relève de la pertinence, et non d’une garantie. Le provisionnement attribue une compétence à tout le monde ; sur Enterprise, un plugin qui la porte peut être rendu obligatoire pour un groupe. C’est ce qui se rapproche le plus d’une ligne de métier dans le chat et Cowork aujourd’hui, mais cela pèche sur trois points : c’est réservé à Enterprise, cela cible des personnes et non des projets, et rien ne descend d’une ligne vers ses projets. Une règle qui doit toujours s’appliquer dans une ligne ne peut pas dépendre de la détection de pertinence.

« Les mods font déjà cela. » Dans Claude Code, en partie, depuis le 1er octobre 2026. Un mod peut réécrire l’invite système, refuser un appel d’outil et afficher un panneau, et les mods d’une organisation s’exécutent avant ceux d’un utilisateur. Ainsi, le compilateur, le contrôle à l’écriture et la vue des instructions effectives décrits dans cet article pourraient être construits sous forme de mod dès aujourd’hui, comme l’indique la section 6. Trois limites subsistent. Les mods ne s’exécutent pas dans le chat Claude, et dans Cowork, les paramètres de la console de l’organisation ne s’appliquent pas. Leur ordre a deux propriétaires, l’organisation et la personne, sans ligne de métier entre eux ; sur Enterprise, un plugin obligatoire pour un groupe peut y injecter un mod, mais celui-ci s’exécute comme l’un des mods personnels de l’utilisateur, sans priorité. Enfin, un mod est du code non isolé (unsandboxed) : pour s’exécuter avant les mods personnels, le mod d’une organisation doit résider dans un répertoire sur chaque machine, or les paramètres diffusés depuis la console d’administration « ne peuvent pas placer le répertoire sur une machine ». Un cabinet sans gestion de parc peut déployer un mod pour tous, mais il s’exécutera parmi les mods personnels, et non avant eux. Une entreprise ne devrait pas avoir à écrire du TypeScript pour indiquer qu’un département utilise des unités différentes.

« La mémoire apprendra les règles. » La mémoire est principalement rédigée par Claude, pour une personne ou un projet donné, et un propriétaire ne peut ni lire ni modifier les souvenirs d’un membre. Un auditeur a besoin de règles rédigées par un humain, versionnées, approuvées et traçables jusqu’à chaque réponse. Anthropic l’a déjà construit trois fois : pour les permissions, avec « Afficher le rôle effectif » et son libellé « Accordé par » ; pour les compétences et les plugins, avec l’historique des versions et une étape de validation où « vous ne pouvez pas approuver votre propre travail » ; et pour les accès de Claude Tag, avec ses libellés « Hérité de ». Les instructions d’un projet ne bénéficient d’aucun de ces trois mécanismes.

« Claude Tag fait déjà cela. » Pour les canaux Slack, en grande partie oui, comme le mentionne la section 1. Mais il manque encore trois choses. Un canal n’est pas un projet : il n’a ni dossier, ni clé, ni cycle de vie, et « un canal ne peut pas pointer vers un projet ». L’arbre comporte trois niveaux fixes, si bien qu’un cabinet organisé en lignes de métier avec des centaines de dossiers doit aplatir deux de ses niveaux dans les noms de canaux. Par ailleurs, la documentation ne décrit aucun contrôle de conflit lors de la rédaction d’une instruction ; les portées sont concaténées et le modèle doit les concilier lui-même. Au contraire, Claude Tag constitue la preuve la plus solide en faveur de la conception de cet article : la même entreprise a choisi l’héritage, les identifiants liés à une portée et un libellé d’origine lorsqu’elle a conçu un outil pour les équipes.

« Les hiérarchies ajoutent de la complexité. » Seulement si leur profondeur est illimitée. Les propres directives de Microsoft pour les groupes d’administration préconisent « pas plus de trois à quatre niveaux ». Ce modèle fixe quatre niveaux porteurs de règles, et les dossiers de regroupement comme les séries ou les années n’en portent aucune.

« L’héritage est un risque de sécurité. » Il l’est si les accès sont hérités à la légère. La réponse du cloud s’applique ici : une autorisation doit exister à chaque niveau, un refus l’emporte partout, Claude agit en tant qu’utilisateur croisé avec le nœud, et les propres modifications de règles de Claude deviennent des propositions.

« Plus de couches coûtent plus de tokens. » La section 3.2 a mesuré l’inverse dans Claude Code : 20 % de tokens d’instructions en moins sous forme de cascade, 34 % en moins une fois compilés, par rapport à des copies à plat. Chaque fichier supplémentaire ajoute un peu de surcharge, d’où la supériorité de la compilation sur la cascade. Les tâches typées éliminent les modèles inutilisés, et les préfixes compilés sont identiques à l’octet près entre les projets, ce qui permet à la mise en cache des invites de les réutiliser. Sur l’API Claude, les caches sont isolés par espace de travail ; un espace de travail par organisation correspond donc à la racine de l’arbre. Claude Code n’en bénéficie pas aujourd’hui : son cache est limité à une machine et à un répertoire.

« Les équipes peuvent simplement gérer leurs propres projets. » C’est la solution de contournement actuelle, et le prototype de la section 5 a mesuré ce qu’elle produit : deux copies collées sur six étaient obsolètes lors d’une petite démonstration.

5. Ça tourne aujourd’hui : une implémentation de référence

Pour prouver que ce modèle est réalisable, et pas seulement défendable sur le papier, j’ai créé Worktree, une petite application de bureau (Node et Electron, 24 tests réussis sous Windows et Linux) dont l’interface rappelle celle de Claude Desktop. La vidéo ci-dessus montre une véritable exécution, raccourcie uniquement pendant les phases de travail de Claude. Il s’agit d’une application distincte qui pilote Claude Code de l’extérieur, et non d’un mod. Elle n’appelle aucun modèle par elle-même. Chaque discussion exécute le Claude Code déjà installé sur l’ordinateur (claude -p), avec l’authentification configurée dans Claude Code : un abonnement Claude ou une clé API. Je l’ai testée sur un cabinet fictif comptant trois lignes de métier et six projets. Lorsqu’une personne envoie un message :

• Autoriser. L’utilisateur agissant doit disposer d’une attribution sur le projet ou à un niveau supérieur, et le projet doit être ouvert. Un administrateur sans attribution sur la ligne a été bloqué avant même le démarrage de Claude.

• Vérifier. Le contrôle à l’écriture s’exécute en premier. La règle SI de la section 3.4 est rejetée car en conflit avec une règle du cabinet appliquée (enforced), elle n’atteint donc jamais un fichier CLAUDE.md.

• Monter. L’arborescence est écrite dans les véritables dossiers de projet sous la forme d’un fichier CLAUDE.md par niveau (l’organisation à la racine de stockage, puis la ligne, puis le projet), et la cascade native de Claude Code les charge. Un mode compilé écrit plutôt un seul fichier par projet. Les fichiers dépourvus du marqueur de l’application ne sont jamais écrasés.

• Exécuter. Le modèle de tâche passe par --append-system-prompt-file. Ce que Claude peut faire est imposé par Claude Code, et non par CLAUDE.md : --allowedTools correspond au rôle de la personne croisé avec la politique de chaque niveau, les écritures sont limitées au dossier du projet, et --permission-mode dontAsk refuse tout le reste. Lors de tests réels, une recherche web a été refusée car la politique de la ligne n’autorise pas le web, et une écriture hors du dossier du projet a été bloquée et journalisée.

• Journaliser et valider. Chaque réponse est consignée avec la personne, le nœud, chaque balise de règle, les règles citées par Claude, ainsi que les tokens d’entrée, de cache et de sortie signalés par Claude Code. Un relecteur qui n’a pas rédigé la réponse l’accepte ou la renvoie. Une véritable exécution de rapport de densité sur la démo a pris environ 30 secondes ; sur trois essais, Claude Code a annoncé un coût de 0,08 à 0,22 $ par réponse aux tarifs publics. Claude a cité les règles appliquées, signalé les résultats proches de la limite d’acceptation et laissé vides les champs réservés à l’ingénieur.

• Dérive. Chaque fichier CLAUDE.md monté est comparé à l’arborescence, et les modifications manuelles sont signalées. Un précédent prototype en ligne de commande a effectué la même comparaison sur des copies collées dans des projets à plat et a trouvé deux fichiers obsolètes sur six : l’un encore sur R-07 v3, l’autre dont une règle avait été supprimée manuellement.

Trois enseignements tirés de ce développement, utiles à quiconque superpose des instructions sur Claude Code :

1. Vos instructions personnelles s’infiltrent dans les exécutions de l’organisation. Par défaut, chaque exécution chargeait également mon fichier personnel ~/.claude/CLAUDE.md, mes règles, agents et serveurs MCP. L’application les exclut désormais via le paramètre claudeMdExcludes, combiné à --strict-mcp-config. Sur ma machine, cela a fait passer le contexte d’une exécution de 29,6 k à 21,4 k tokens. L’alternative évidente, --setting-sources project,local, a produit l’effet inverse de celui recherché dans Claude Code 2.1.284 sous Windows : elle a conservé le fichier personnel et supprimé les fichiers CLAUDE.md des dossiers parents qui portent l’organisation et la ligne.

1. Les mods personnels s’infiltrent aussi. Les mods sont arrivés le lendemain de la création de l’application, je les ai donc testés. J’ai installé un mod à un seul hook dans ma propre portée utilisateur, qui ajoute une ligne à chaque invite. Il a atteint les exécutions de l’application : les trois règles de l’organisation ont été chargées, tout comme ma ligne personnelle, et la réponse s’y est conformée. L’ajout de disableAllHooks aux paramètres de l’exécution l’a tenu à l’écart tout en préservant les trois niveaux de CLAUDE.md ; l’application le fait désormais. --safe-mode n’est pas une solution de remplacement : il a supprimé le mod, mais aussi toute la cascade CLAUDE.md. Selon la documentation, disableAllHooks placé dans les paramètres personnels laisse fonctionner ce que l’organisation gère.

1. CLAUDE.md est du contexte, l’application stricte est de la configuration. La documentation d’Anthropic le précise : « Les règles de paramètres sont appliquées par le client indépendamment de ce que Claude décide de faire. Les instructions de CLAUDE.md orientent le comportement de Claude mais ne constituent pas une couche d’application stricte. » L’application repose sur ce principe. Tout ce qu’une règle doit garantir est mappé sur des permissions d’outils ; tout ce qui figure dans CLAUDE.md relève de l’orientation, accompagnée d’une balise.

Cela fonctionne avec le Claude Code actuel, et le texte compilé peut être collé dans un chat ou dans les instructions d’un projet Cowork, quel que soit le plan. Une dépendance est toutefois datée : l’application repose sur le chargement des fichiers CLAUDE.md par claude -p, or la documentation d’Anthropic indique que --bare, qui les ignore, « deviendra le comportement par défaut de -p dans une future version ». Lorsque cela arrivera, l’application devra transmettre l’arborescence autrement ; le mode compilé et --append-system-prompt-file le permettent déjà. Il s’agit d’une spécification fonctionnelle pour la version native, et non d’une frontière de sécurité : le mode « agir en tant que » est un bouton de démonstration, pas une authentification.

6. Une voie à partir de ce qui est déjà disponible

Dans Claude Code, dès maintenant. Depuis le 1er octobre, l'arborescence peut être déployée sous forme de mod : compiler les règles du nœud dans une section du prompt système, bloquer les appels d'outils interdits par la politique du nœud et afficher les instructions effectives dans un panneau. Une organisation peut exécuter ce mod avant tout ce qu'un utilisateur installe. Je ne l'ai pas développé ; c'est le premier point de la feuille de route de l'implémentation de référence. Cela couvrirait Claude Code, et potentiellement les sessions Cowork sur la machine de l'utilisateur, qui reposent sur le même moteur. Le chat, en revanche, ne serait pas concerné.

La version à 30 jours, pour le chat et Cowork. Anthropic dispose déjà des briques nécessaires. Permettre à un projet de désigner un projet parent dont il hérite les instructions, comme un canal Slack hérite de son espace de travail dans Claude Tag. Compiler les deux dans l'ordre, avec un tag sur chaque règle, et ajouter un panneau « Voir les instructions effectives » à côté du panneau existant « Voir le rôle effectif ». À lui seul, cela offre à chaque métier un endroit unique où centraliser ses règles.

Ensuite, chaque étape est utile en soi, à commencer par ce qui profite aux forfaits Team :

1. Les nœuds par métier et le provisionnement de motifs clés, en réutilisant la sémantique de CLAUDE.md qui fonctionne déjà dans le code. Dans Claude Code lui-même, l'étape de correspondance constitue un niveau intermédiaire pour un groupe, entre les mods de l'organisation et ceux de l'utilisateur, ainsi que des paramètres gérés par groupe.

1. Les types de tâches en tant que compétences limitées à un métier, assorties de critères d'acceptation.

1. Une vérification des conflits lors de l'écriture, afin que les contradictions soient rejetées par l'arborescence plutôt qu'arbitrées par le modèle.

1. Les autorisations sur les nœuds, qui fonctionnent sur Team sans groupes et étendent les rôles personnalisés d'Enterprise.

1. Les identités de connecteurs liées aux branches pour les projets, à l'image de Claude Tag qui associe déjà un compte de service à un canal Slack.

1. Une comptabilité par nœud rattachée au projet, comme Claude Tag génère déjà des rapports par canal ; une limite hebdomadaire publiée dans une unité définie ; et une déclaration de consommation énergétique par tâche.

7. Limites

• Couverture. Le 1er octobre 2026, l'intégralité des index de code.claude.com/docs et claude.com/docs a été triée par titre (466 pages) et environ 150 pages ont été lues, en plus des articles du centre d'aide cités ici. Les versions précédentes de cet article omettaient totalement Claude Tag ; celle-ci passe peut-être à côté d'autre chose. Claude for Government et Claude Desktop chez des fournisseurs tiers sont mentionnés, mais non analysés.

• Les fonctionnalités de la plateforme évoluent chaque mois, et l'une d'elles a changé pendant la rédaction de cet article. Chaque affirmation produit est datée du 29 septembre au 1er octobre 2026 et doit être revérifiée avant d'être prise pour acquise. Les mods existent depuis un jour à peine ; j'ai lu leur documentation et testé un cas, sans les avoir utilisés en production.

• Les chiffres mesurés des sections 3.1 à 3.4 proviennent des propres rapports d'utilisation de Claude Code, en deux lots : Claude Code 2.1.286 le 30/09/2026 et 2.1.287 le 01/10/2026, tous deux sur Claude Sonnet 5.5. Le script, les deux lots et chaque réponse sont conservés par l'auteur et disponibles sur demande. Ils incluent le propre prompt de Claude Code (environ 30 200 tokens), que claude.ai et Cowork ne partagent pas, et portent sur un seul modèle, un seul projet de démonstration et une seule question. Les échantillons sont restreints : dix réponses par condition pour la longueur des réponses, vingt par condition pour le test de conflit. Les ratios de longueur de réponse ont varié entre les deux lots (section 3.3) ; deux lots espacés d'une journée diffèrent aussi par la version de Claude Code, et je ne peux pas isoler cet effet du hasard.

• Le temps d'exécution, le coût et la taille du contexte de la section 5 proviennent du journal de réponses de l'application pour trois exécutions de démonstration et un test d'isolation manuel, qui constituent les propres relevés de l'auteur.

• Les réponses au test de conflit ont été codées par l'auteur, en ouvert, en lisant chaque réponse (unités signalées ; indication ou non de la règle gagnante et de sa justification ; présence ou non d'une question). Les quarante réponses sont disponibles sur demande pour un nouveau codage. Le test utilisait une formulation précise de « appliqué » ; d'autres formulations, modèles et paires de règles pourraient se comporter différemment.

• Le test de mod de la section 5 porte sur un seul mod avec un seul hook, sur une machine Linux, avec Claude Haiku, connecté via un abonnement et sans paramètres gérés. Je n'ai testé ni le mod de politique d'une organisation, ni le garde-fou intégré à une connexion Team ou Enterprise, ni l'application Desktop.

• Le modèle de coût de la section 3.2 est une simulation pour une entreprise fictive, et non une facturation mesurée. Il ne couvre que les tokens d'instruction ; l'historique de conversation, la sortie et la réflexion dominent généralement les factures réelles. Ses tailles de tokens utilisent le tokenizer public historique d'Anthropic × 1,30 ; lors des mesures, Claude Code a chargé 21 à 26 % de plus que cette estimation, si bien que ses montants en dollars sont sous-évalués. Ses pourcentages sont des ratios et restent valables. Les schémas de session et le partage de cache reposent sur des hypothèses.

• La question de savoir si l'utilisation du chat sur Enterprise bénéficie de la tarification du cache API et si les caches sont partagés entre utilisateurs sur claude.ai n'est pas documentée. Cowork exécute ses sessions sur Claude Code, et les hooks de plugins s'y chargent, mais les pages des mods ne mentionnent pas Cowork et je ne l'ai pas testé ; au 1er octobre, l'application desktop intégrait encore Claude Code 2.1.286, soit une version antérieure à l'activation des mods. La politique gérée d'un appareil s'applique aux sessions Cowork sur la machine de l'utilisateur, sauf si l'organisation les exécute dans un bac à sable VM complet. Deux pages se contredisent quant à l'accès des fichiers ~/.claude personnels à Cowork ; cet article ne tranche donc pas. Je n'ai pas non plus testé si les fichiers CLAUDE.md des dossiers parents se chargent dans une session Cowork ; si c'est le cas, l'arborescence montée de l'implémentation de référence atteindrait Cowork sur la machine de l'utilisateur dès aujourd'hui. Sur Pro et Max, cette fenêtre se referme le 6 octobre 2026, lorsque les nouvelles tâches Cowork basculeront dans le cloud.

• Les intentions sont déduites. Anthropic n'a pas expliqué publiquement pourquoi le chat Claude et Cowork sont plats.

• Le code et les données brutes ne sont pas publiés avec cet article. Un lecteur ne peut pas reproduire les mesures à partir du seul article ; la vidéo montre l'application en fonctionnement, pas sa conception.

• L'implémentation de référence repose sur une entreprise fictive. Elle n'est pas intégrée à claude.ai ni à Cowork, et le mode « agir en tant que » est un simple bouton de démonstration, pas une authentification. Les permissions sont appliquées par les listes d'outils de Claude Code, et non par l'application. L'isolation désactive les hooks et mods personnels de l'utilisateur pour l'exécution ; les mods intégrés à Claude Code continuent de tourner, et les noms des agents personnels peuvent toujours apparaître dans le contexte. L'application dépend du chargement de CLAUDE.md par claude -p, ce qui, selon Anthropic, cessera d'être le comportement par défaut. La fuite de fichier personnel et le résultat de --setting-sources ont été testés sur Windows ; les mesures et le test de mod ont été réalisés sur Linux.

Sources

• Anthropic, Définir les instructions de l'organisation

• Anthropic, Rôles et autorisations

• Anthropic, Qu'est-ce que le forfait Team ? · Forfaits et tarifs

• Anthropic, Gérer les rôles personnalisés sur les forfaits Enterprise

• Anthropic, Organiser vos tâches avec les projets dans Claude Cowork

• Anthropic, Utiliser les connecteurs Google Workspace

• Anthropic, Gérer les groupes et les limites de dépenses des groupes sur les forfaits Enterprise

• Anthropic, Qu'est-ce que les projets ? (nouvelle version des projets, bêta)

• Anthropic, Premiers pas avec Claude Cowork(instructions globales et par dossier)

• Anthropic, Comment Claude mémorise votre projet (CLAUDE.md) · Tous les paramètres (claudeMdExcludes, disableAllHooks)

• Anthropic, Personnaliser Claude Code avec les mods (1er octobre 2026) · Présentation des mods · Gérer les mods pour votre organisation · Réagir aux événements avec un mod · Référence des mods

• Anthropic, Claude Tag : Qu'est-ce que Claude Tag ? · Configurer l'accès par canal · Personnaliser Claude Tag · Fonctionnement de l'identité de l'agent · Audit · Définir une limite de dépenses

• Anthropic, Projets dans Claude Code (bêta des nouveaux projets) · Projets dans Cowork · Comment Claude Code utilise la mise en cache des prompts · Exécuter Claude Code par programmation (--bare) · Étendre Claude Code · Gérer la visibilité et le partage des projets · Utiliser les connecteurs · Autoriser les connecteurs MCP pour toute votre organisation · Provisionner et gérer les compétences

• Anthropic, Configurer les paramètres gérés par le serveur (pas de configuration par groupe) · Gérer les plugins pour votre organisation (disponibilité des plugins par groupe sur Enterprise) · Prise en charge des fonctionnalités des plugins selon les plateformes (hooks ignorés dans le chat, chargés dans Cowork) · Déployer les paramètres gérés (Cowork exécute ses sessions sur Claude Code)

• Anthropic, Tarifs (tarifs Sonnet 5.5, note sur le tokenizer) · Mise en cache des prompts (caches isolés par organisation et par espace de travail sur l'API)

• Anthropic, @anthropic-ai/tokenizer(tokenizer public utilisé pour les comptages)

• Microsoft, Groupes d'administration · Conception des groupes d'administration de landing zone

• AWS, Évaluation des SCP · Google Cloud, Évaluation de la hiérarchie

• Microsoft, Traitement des stratégies de groupe · Autorisations granulaires SharePoint

• FinOps Foundation, Économie des tokens

• Jaroslawicz et al., Combien d'instructions les LLM peuvent-ils suivre simultanément ? (IFScale)

• Firefly, Étude 2026 sur l'état de l'IaC

• MCP, Spécification d'autorisation, version du 28/07/2026

• GitHub, tickets anthropics/claude-code #68262, #14467, #30554, #27567, #30250, #27302, #47741

• Beer, S. (1979), The Heart of Enterprise ; Alexander, C. (1965), « A City is Not a Tree », Architectural Forum ; Simon, H. (1962), « The Architecture of Complexity », Proc. Am. Phil. Soc.106(6)

• Implémentation de référence et données : l'application Worktree, ses tests, le script de mesure, les deux lots de résultats et chaque réponse sont conservés par l'auteur et disponibles sur demande.