ICM Architect

Que fait ICM Architect ?

Construisez des espaces de travail où la structure des dossiers fait l’orchestration. Un agent, lisant les bons fichiers au bon moment, remplace une architecture multi-agents : les dossiers numérotés portent l’ordre, la hiérarchie porte le cadrage du contexte, les fichiers Markdown simples portent l’état. Un humain peut ouvrir n’importe quel dossier et voir exactement où en est le système, car l’état n’est que des fichiers.

Considérez l’espace de travail comme une bibliothèque. Les fichiers de routage sont le catalogue : petits, stables, ils pointent vers tout et ne stockent presque rien. Le contenu vit sur les étagères (dossiers d’étape, fichiers nœuds, documents de référence). Un seul bibliothécaire — un seul modèle — parcourt le bâtiment, et la question décide quelle étagère est consultée. Personne ne photocopie la bibliothèque dans un sac à dos ; c’est ce qu’est le bourrage de contexte. Le catalogue est intentionnellement petit.

Méthode : Interpretable Context Methodology (Van Clief & McDermott, arXiv:2603.16021, sous licence MIT).

Les invariants

Tout ICM, quelle que soit sa forme, obéit à ces règles. Lors de la construction ou de la restructuration, appliquez les dix :

1. Un dossier, un travail. Chaque dossier effectue une seule étape ou contient un seul type de chose, et déclare son propre but dans un fichier à l’intérieur. La structure est la documentation.
2. Un fichier d’entrée petit et stable. CLAUDE.md (ou AGENTS.md) à la racine répond à « où suis-je, où tout se trouve, où aller pour la tâche X » — et rien d’autre. Visez environ 60 lignes. Il route ; il ne contient jamais de contenu.
3. La numérotation code l’ordre. 01_, 02_, … là où l’ordre importe. Renommer les dossiers réordonne le pipeline — c’est le but.
4. Chaque contrat au niveau dossier est explicite. Un CONTEXT.md par dossier de travail : ce qu’il lit (entrées), ce qu’il fait (processus), ce qu’il écrit (sorties), ce qu’un humain vérifie. Voir assets/templates/stage-CONTEXT.md.
5. Usine vs. produit. Les documents de référence (règles, ton, schémas, modèles — stables d’une exécution à l’autre) vivent structurellement à part des artefacts de travail (sorties, brouillons — nouveaux à chaque exécution). Configurez l’usine une fois ; le produit est ce que chaque exécution émet.
6. Chaque sortie est une surface d’édition. Les sorties intermédiaires sont des fichiers simples qu’un humain peut ouvrir, éditer et enregistrer avant que l’étape suivante ne les lise. Rien n’avance tant qu’une personne n’a pas lu la dernière sortie.
7. Ne chargez que ce dont l’étape a besoin. Un agent qui exécute une étape lit son contrat, ses références et ses entrées — pas tout l’espace de travail. 2 000 à 8 000 tokens par étape est la plage saine.
8. Texte brut, lié, interrogeable. Markdown + YAML frontmatter. Les liens ([[wikilinks]] ou chemins relatifs) en font un graphe ; les étiquettes frontmatter le rendent interrogeable. Un fait par emplacement — un lien vaut mieux qu’une copie.
9. Le système de fichiers est la machine d’état. L’« état » se déduit en scannant ce qui existe dans les dossiers de sortie. Les index générés (plans de fichiers, journaux) sont reconstruits par script, jamais édités à la main.
10. Instancier par copie. Nouvelle unité de travail = copier un dossier modèle, pas une page vierge. Gardez les modèles dans un dossier _templates/ ou _system/.

Choisir un mode

• Construction à partir d’un processus, d’une idée ou d’un problème décrit → Mode Construction.
• Un dossier, dépôt ou coffre existant qui a besoin d’une structure ICM → Mode Restructuration.

Mode Construction

1. Extraire la structure du dialogue. La structure est déjà dans la façon dont la personne décrit le travail — n’imposez pas de forme, révélez la leur. Posez (quelques-unes à la fois, pas toutes en même temps) :

• Quelle est l’unité de travail répétitive ? (un épisode, un client, un rapport, une personne, une équipe ?)
• Parcourez-moi une exécution, du début à la fin. Où vous arrêtez-vous pour vérifier quelque chose avant de continuer ?
• Qu’est-ce qui reste identique à chaque exécution (ton, règles, marque, schéma) par rapport à ce qui est nouveau à chaque exécution ?
• À quoi ressemble « terminé » — quel artefact quitte l’espace de travail ?
• Qui d’autre touche à cela, et de quoi ont-ils besoin pour trouver sans vous demander ?

Leurs pauses deviennent des limites d’étape. Leurs « je vérifie toujours X avant Y » deviennent des portes humaines. Leurs « ça doit toujours ressembler à / suivre Z » devient du matériel de référence d’usine.

2. Choisir la forme. Lisez references/forms.md et choisissez :

Forme	À utiliser quand
Pipeline	La même séquence s’exécute de manière répétée, produisant un livrable à chaque exécution
Parapluie	Plusieurs pipelines distincts partagent une même couche de marque/ton/référence
Bibliothèque d’enregistrements	L’unité est un enregistrement (personne, client, session) qui s’accumule, pas une exécution
Lot de connaissances	Le produit est la connaissance elle-même navigable (un cerveau, un wiki, un modèle de quelque chose)
Carte de contexte	Le sujet est une organisation — équipes, processus, données et les liens entre eux

Les espaces de travail réels mélangent les formes (une bibliothèque d’enregistrements dont les enregistrements sont des mini lots de connaissances ; un pipeline qui émet dans une bibliothèque d’enregistrements). Composez librement — les invariants s’appliquent à tous les niveaux, récursivement.

3. Échafauder la plus petite structure qui porte le travail. Copiez les starters depuis assets/templates/ et remplissez-les. Ne créez pas de dossiers pour des étapes qui n’existent pas encore, de dossiers « divers » vides ou de profondeur spéculative. Trois étapes réelles valent mieux que sept imaginées. Si tout le travail tient dans une invite sauvegardée, dites-le et ne construisez pas d’espace de travail du tout.

4. Rédiger les contrats. CLAUDE.md racine (identité + table de routage), CONTEXT.md racine (définition du pipeline ou du schéma), un CONTEXT.md par dossier d’étape/de hub, setup/questionnaire.md si l’usine doit être configurée par utilisateur. Écrivez les entrées comme des chemins de fichiers explicites, en séparant le travail (cette exécution) et la référence (chaque exécution).

5. Valider avec le test de marche (ci-dessous).

Mode Restructuration

1. Inventorier avant de toucher. Listez l’arborescence. Pour chaque zone, notez : ce que c’est, quand a été la dernière modification, ce qui y fait référence. Ne supprimez ni ne déplacez rien lors de cette passe.

2. Trouver la forme cachée. Demandez au propriétaire (ou déduisez et confirmez) : quelle est l’unité répétitive ici ? Où le travail entre et sort ? Le fouillis contient généralement un véritable pipeline, bibliothèque ou carte qui a grandi sans squelette — extrayez-le, ne le remplacez pas. Interviewez le dossier comme vous interviewez la personne.

3. Classer chaque fichier dans l’un des cinq rôles :

• Catalogue — identité/routage (devient ou alimente CLAUDE.md / fichiers d’index)
• Contrat — décrit le fonctionnement d’une étape (devient un CONTEXT.md)
• Usine — référence stable (→ _shared/, _system/ ou references/)
• Produit — artefacts spécifiques à l’exécution (→ dossiers output/ d’étape ou dossiers d’enregistrement)
• Mort — obsolète, dupliqué ou remplacé (→ proposer _archive/, ne jamais supprimer silencieusement)

4. Proposer avant de déplacer. Présentez l’arborescence cible et une carte de migration (ancien chemin → nouveau chemin → rôle). Obtenez l’approbation. C’est une porte humaine dans une méthode bâtie sur des portes humaines — respectez-la.

5. Migrer. Déplacez les fichiers, écrivez le fichier d’entrée et les contrats, dé-dupliquez vers un fait par emplacement (laissez un lien là où la copie se trouvait si quelque chose pourrait y faire référence). Séparez méthode et instance : si la structure est réutilisée ailleurs, le modèle vide vit séparément de ce déploiement rempli.

6. Valider avec le test de marche.

Le test de marche

Validez tout ICM — nouveau ou restructuré — en le parcourant à froid, en tant qu’agent sans mémoire :

• Ouvrez la racine. Pouvez-vous répondre à où suis-je et où vais-je pour la tâche actuelle avec le fichier d’entrée plus au plus deux autres lectures ?
• Choisissez une étape/nœud. Son contrat nomme-t-il des chemins d’entrée exacts, le travail, la sortie et la vérification humaine ?
• Pouvez-vous déterminer l’état du pipeline simplement en scannant ce qui existe dans les dossiers output/ (ou le frontmatter des nœuds) ?
• Un fichier de routage porte-t-il une charge utile de contenu ? Déplacez la charge utile sur une étagère ; laissez un pointeur.
• Un fait est-il stocké à deux endroits ? Choisissez un emplacement ; liez depuis l’autre.
• Vérification des tokens : fichier d’entrée + un contrat + ses entrées devraient se situer entre environ 2k et 8k tokens.

Si une étape échoue, corrigez la structure — pas en expliquant plus, mais en déplaçant ou fractionnant les fichiers jusqu’à ce que la marche fonctionne.

Garde-fous

• Ne pas sur-structurer. L’échelle va : conversation → invite/skill sauvegardé → dossiers + un agent. Ne montez que lorsque l’échelon inférieur est véritablement automatisé et répétitif. Un espace de travail pour une chose faite deux fois est un échafaudage, pas une architecture.
• Savoir où ICM perd. La collaboration multi-agents en temps réel, le service multi-utilisateurs à haute concurrence et le branchement automatisé en milieu de pipeline nécessitent vraiment du code framework. ICM est destiné au travail séquentiel, révisé par un humain et répétitif — ce qui représente la plupart du travail de connaissance, mais pas tout.
• Anti-patrons observés sur le terrain : fichiers d’entrée dupliqués qui dérivent (générez-en un à partir de l’autre, ou faites-en un pointeur) ; documents de schéma qui imposent des noms que les fichiers réels ont cessé d’utiliser (mettez à jour le schéma ou les fichiers — choisissez un) ; modifications manuelles d’index générés ; sessions d’atelier qui produisent des diapositives au lieu de données structurées (chaque session de travail doit se terminer par un artefact que la structure peut contenir) ; motifs déclarés de haut en bas (une équipe qui se plaint est une doléance — la même forme apparaissant trois fois indépendamment est une structure).

Références

• references/core.md — les cinq principes de conception, la hiérarchie de contexte à cinq couches, les conventions de nommage, la discipline des tokens. À lire lors de la rédaction des contrats ou lorsqu’une décision structurelle est contestée.
• references/forms.md — les cinq formes en profondeur : arbres squelettiques, actions définissantes, modes de défaillance. À lire à l’étape 2 du mode Construction ou à l’étape 2 du mode Restructuration.
• assets/templates/ — starters copiables : CLAUDE.md, CONTEXT.md d’espace de travail, stage-CONTEXT.md, node.md, schema.md, questionnaire.md.