La mémoire situative

PARTIE I — INTRODUCTION

La vraie question n'est pas de savoir comment l'IA se souvient — mais à qui appartient ce dont elle se souvient.

La vraie question : qui possède votre mémoire ?

L'intelligence artificielle de 2026 évolue vite. Les grands éditeurs (Anthropic, OpenAI, Google) intègrent désormais des systèmes de mémoire persistante : conversations, projets et préférences sont conservés au fil des sessions.

Ce progrès technique règle une partie du problème. Mais il en ouvre un autre, plus discret et plus lourd : si la mémoire de votre organisation vit chez l'éditeur, elle lui appartient.

Tout ce que vous lui apportez au fil des mois — conventions, décisions, culture interne, cartographie clients et projets — devient progressivement un actif stratégique du fournisseur. Un actif que vous ne possédez pas, que vous ne pouvez pas exporter intégralement, et qui devient captif au moment où vous voudriez changer de prestataire.

C'est le mécanisme classique du verrouillage par la donnée : plus vous nourrissez, plus vous dépendez.

Pour une petite entreprise — où la mémoire institutionnelle vaut souvent davantage que le parc de logiciels — ce compromis n'est pas trivial. Il mérite d'être pensé avant d'arriver.

L'état de l'art

Deux familles d'approches coexistent aujourd'hui pour donner une mémoire à l'IA — chacune avec sa logique et ses limites.

Les systèmes de mémoire intégrés aux éditeurs

ChatGPT mémorise ce que vous lui racontez ; Claude propose des projets qui conservent documents et instructions ; Gemini étend son contexte ; d'autres suivent. Ces solutions sont techniquement efficaces et immédiatement accessibles — aucune installation, aucune compétence technique requise.

Leur limite n'est pas technique. Elle est contractuelle et stratégique : la mémoire vit sur l'infrastructure du fournisseur, sous ses conditions d'utilisation, sujette à ses évolutions commerciales. Ce qui est pratique pour un usage individuel peut devenir fragile pour une organisation : changer de modèle, de fournisseur, ou faire travailler plusieurs IA en parallèle sur les mêmes contextes — tout cela devient coûteux, parfois impossible.

Cette limite n'est pas théorique. Le Tribunal fédéral — la plus haute juridiction suisse — fait tourner son informatique sur du logiciel libre depuis plus de vingt ans, à l'écart des géants américains, par souci d'indépendance et de protection des données⁹ ; pendant que l'administration fédérale équipait 54 000 postes de Microsoft 365, la Cour suprême, mouton noir du paysage fédéral, avait manifestement réfléchi au pourquoi — et vu juste. Et pour cause : la confiance se mesure aux actes, pas aux promesses. En 2023, le régulateur fédéral américain a sanctionné Microsoft pour avoir illégalement collecté les données personnelles d'enfants — décision entrée en force, amende payée, sans reconnaissance de faute¹⁰. Le montant importe peu : ce n'est pas le nombre des fautes qui disqualifie, c'est la faute elle-même.

Que l'on ne s'y méprenne pas : les deux voies fonctionnent. L'administration fédérale opère sur Microsoft, le Tribunal fédéral sur logiciel libre — chacun remplit sa mission. Toute entreprise suisse dispose de la même liberté : accepter une dépendance en connaissance de cause, ou s'en affranchir. Ce texte ne dicte pas le choix ; il demande seulement qu'il soit fait les yeux ouverts.

Les systèmes souverains techniques — RAG et bases vectorielles

L'autre voie repose sur des architectures plus structurées : bases de données vectorielles, pipelines RAG (Retrieval-Augmented Generation), frameworks d'agents mémoriels. Techniquement puissantes, souveraines — mais historiquement construites pour les grandes organisations, et lourdes à tenir : moteur d'embedding, stockage vectoriel, pipeline d'indexation. À l'échelle d'une PME, cette machinerie est souvent un surcoût — d'autant que les IA agentiques d'aujourd'hui lisent un système de fichiers directement, sans qu'on ait à en vectoriser le contenu au préalable.

Markdown structuré et cloud souverain — deux briques complémentaires

Une troisième voie s'est consolidée depuis 2025. Andrej Karpathy a publié en avril 2026 LLM Wiki¹ : une base de connaissances en Markdown structuré, construite et maintenue par un LLM qui la consulte au moment des requêtes. Le framework DSPy² (Stanford) pousse dans la même direction côté académique. Du texte bien structuré, dans un dépôt Git, suffit pour porter la mémoire active d'une organisation.

Pour les volumes denses qui débordent cette mémoire active — archives, correspondances, contrats étalés sur plusieurs années — un cloud d'entreprise souverain prend le relais : un serveur de fichiers, synchronisé sur le poste par un client desktop, où l'IA lit à la demande les dossiers utiles. Pas de base vectorielle, pas d'indexation préalable : l'organisation par dossiers est le mécanisme d'accès. Les deux briques ne se concurrencent pas — elles couvrent deux échelles distinctes de la mémoire.

Ces approches sont puissantes, encore peu incarnées dans un usage d'entreprise. Il manque une proposition concrète, accessible à une PME, qui garde la simplicité du Markdown et y ajoute la discipline d'une organisation : structure par couches, règles permanentes, gouvernance explicite, souveraineté d'hébergement.

Mémoire et conduite — les deux moitiés

Détenir sa mémoire ne suffit pas. Une organisation réellement augmentée par l'IA repose sur deux piliers : une mémoire qu'elle possède, et une manière de conduire l'intelligence qui s'en sert. La première sans la seconde donne une IA bien renseignée mais mal employée — un exécutant d'instructions là où l'on pouvait disposer d'un explorateur de solutions.

Ce texte traite les deux. La mémoire et son architecture occupent la partie II ; la conduite — comment piloter l'IA pour en tirer la puissance réelle — la partie III ; leur incarnation concrète, éprouvée chez APCOM Solutions SA, la partie IV.

PARTIE II — LE SYSTÈME DE MÉMOIRE

Une mémoire qu'on ne possède pas est une mémoire qu'on loue — et tout locataire dépend du bailleur.

Une architecture pratique

L'approche retenue repose sur un principe simple : la mémoire contextuelle d'une organisation doit être un actif qu'elle détient, pas un service auquel elle souscrit. Trois bénéfices pratiques en découlent :

• Souveraineté — les données, les décisions, les conventions sont hébergées sur une infrastructure sous mon contrôle (dépôts Git privés, VPS souverain suisse). Rien ne dépend des conditions d'utilisation d'un éditeur d'IA.
• Mobilité — le jour où je veux changer de modèle ou de fournisseur d'IA, ma mémoire reste intacte. Aucun coût de bascule. Aucune perte de contexte accumulé.
• Multi-acteurs — plusieurs IA peuvent travailler sur le même contexte sans se marcher dessus. Claude ce matin, un autre modèle cet après-midi, un modèle spécialisé pour une tâche précise : tous lisent la même mémoire, tous respectent le même cadre. Mieux : je peux composer une équipe d'IA de plusieurs éditeurs selon les forces de chacun, au lieu d'être enfermé dans la suite d'agents d'un fournisseur unique. La souveraineté rend l'organisation plus libre, pas moins intégrée.

Ces trois bénéfices n'en font qu'un : une liberté opérationnelle. Elle a pourtant une frontière qu'il faut nommer sans détour — les IA les plus productives restent aujourd'hui commerciales ; l'open source auto-hébergeable, agents comme modèles, n'égale pas encore leur rendement. On reste donc dépendant d'un outil qu'on ne détient pas. La souveraineté cesse alors de se résumer à où vivent les données : elle devient aussi la décision de ce qu'une IA commerciale a le droit de voir — l'objet de l'atelier de fichiers (le CORPUS, plus bas) et de la barrière atelier/vitrine (Partie IV).

L'implémentation tient sur des briques universelles et open source : Git et Markdown pour la mémoire active de l'organisation (le KERNEL), et — pour les volumes denses qui débordent cette mémoire active — un cloud d'entreprise souverain doté d'un client desktop (chez APCOM, Nextcloud auto-hébergé). Aucune dépendance propriétaire à un éditeur d'IA, aucune base vectorielle à maintenir. Git et Markdown existeront encore dans vingt ans ; le cloud n'est qu'un serveur de fichiers, remplaçable — les contenus restent des fichiers ouverts, lus à la demande.

La valeur n'est pas dans la technologie — elle est gratuite et interchangeable. Elle est dans la discipline de structuration : comment l'information est organisée, comment elle circule, comment elle est protégée, comment elle est projetée vers les bonnes personnes.

Le modèle KERNEL-CORPUS-SPOKE

Pour qu'une mémoire soit à la fois permanente, scalable et projetable vers d'autres, elle doit être structurée en couches distinctes avec des rôles clairs et une gouvernance explicite. L'architecture retenue repose sur quatre composantes articulées autour d'une gouvernance unique.

Principe général

Quatre disciplines inspirées du pattern hub-and-spoke

Le pattern hub-and-spoke³ est un modèle architectural établi depuis les années 1970 (logistique, réseaux, modélisation de données, et récemment architectures multi-agents LLM). L'apport ici n'est pas le pattern — il est reconnu et documenté. Il est dans les quatre disciplines propres qui transforment un pattern technique en architecture d'intelligence organisationnelle :

• Asymétrie d'écriture — le KERNEL a un propriétaire unique. Les SPOKES peuvent être écrits par plusieurs acteurs ; mais seul le propriétaire du KERNEL décide ce qui y entre.
• Impermanence des SPOKES par design — un SPOKE n'est pas un nœud périphérique permanent. Il est créé pour une mission, vit le temps de cette mission, puis est consolidé et fermé.
• Consolidation filtrée — le KERNEL ne se met pas à jour automatiquement depuis les SPOKES. La remontée est un acte humain de sélection, pas un flux automatique. Cette friction volontaire protège la cohérence.
• Séparation index / contenu — le KERNEL reste léger (index, cartes, règles). Les contenus denses vivent dans le CORPUS, consulté à la demande. L'organisation peut grandir sans alourdir la mémoire active.

Structures internes

┌──────────────── KERNEL (index permanent, léger) ───────────────────┐
│ GLOBAL/          — constitution, règles, conduite, rituels, cartes │
│ SERVEURS/        — accès hébergeurs, architecture serveur          │
│ STACK_TECHNIQUE/ — stack des logiciels, routines de développement  │
│ EQUIPE/          — organisation par flux, profils des membres      │
│ CLIENTS/         — index clientèle (fiche par client)              │
│ PROJETS/         — conduite de projet (API et méthodes)            │
│ MANIFESTE/       — corpus éditorial                                │
└────────────────────────────────────────────────────────────────────┘
                    ↕  archive ↔ extraction
┌──────────── CORPUS (cloud souverain, lu à la demande) ─────────────┐
│ Client desktop (Nextcloud / kDrive) → l'explorateur du poste       │
│                                                                    │
│   CLIENTS/    fiches, échanges, vision stratégique                 │
│   PROJETS/    cahiers des charges, contrats, chantiers             │
│   PV/         procès-verbaux, transcriptions, notes                │
│   ÉCHANGES/   résumés de sessions IA (.md), correspondance         │
│   DOC · FINANCE · MAIL · …                                         │
│                                                                    │
│ Pas de base vectorielle ni d'API — l'IA ouvre le dossier utile     │
└────────────────────────────────────────────────────────────────────┘
                    ↕  projection ↔ consolidation
┌──────────────── SPOKE (projection mission, éphémère) ──────────────┐
│ EQUIPE/             contenu complet                                │
│ GLOBAL/             CORE.md · CREDENTIALS.md · CONDUITE/ · STRUCTURE/│
│ MANIFESTE/          MEMOIRE_SITUATIVE.md uniquement                │
│ PROJETS/            contenu complet                                │
│ SERVEURS/           contenu complet                                │
│ STACK_TECHNIQUE/    STACK.md + ROUTINES/ + dossier logiciel ciblé  │
└────────────────────────────────────────────────────────────────────┘

┌──────────────── BACKUPS NEXTCLOUD (sauvegarde additionnelle) ──────┐
│ KERNEL/          clone Git miroir (sync par git pull)              │
│ CORPUS/          clone de l'arborescence (sync périodique)         │
│ CLAUDE-MEMORY/   copie additive de la mémoire locale IA            │
└────────────────────────────────────────────────────────────────────┘

Les quatre composantes

Le KERNEL — index permanent, léger. Dépôt Git privé qui accumule l'intelligence de chaque session : identité, équipe, clients, projets, conventions, règles. Il ne se ferme jamais. Il est léger par nature : aucun contenu dense. Les fiches clients et projets sont des index — des cartes qui décrivent, résument, pointent. Personne n'écrit directement dans la version consolidée du KERNEL — pas même le propriétaire. Chaque contribution transite par une branche de travail dédiée avant d'être intégrée, ce qui rend chaque évolution explicite et réversible.

Le CORPUS — réservoir souverain. Un cloud d'entreprise souverain doté d'un client desktop, où vivent les contenus denses : contrats, cahiers des charges, procès-verbaux, correspondance, comptabilité — et les résumés produits par l'IA elle-même (synthèses d'échanges, notes distillées), déposés en fichiers Markdown dans le bon dossier. L'organisation est par dossiers, pas par index. Le CORPUS est consulté à la demande : le client desktop synchronisant l'arborescence dans l'explorateur du poste, l'IA ouvre directement le dossier pertinent et lit les pièces utiles — jamais le tout en bloc, sans base vectorielle. Une discipline archive → extraction gouverne le CORPUS : tout document déposé produit au moins une extraction vivante dans le KERNEL — fiche légère qui pointe vers la source dense.

Les SPOKES — projections ciblées, éphémères. Quand un membre de l'équipe ou un partenaire a besoin de contexte pour une mission, un SPOKE est créé — un dépôt séparé hébergé sur l'instance Git souveraine de l'organisation, qui contient uniquement ce que la gouvernance a décidé de projeter depuis le KERNEL (et, si pertinent, des extraits ciblés du CORPUS). Cycle de vie explicite : création → mission → consolidation vers KERNEL / CORPUS → fermeture. Les destinataires travaillent avec leur propre IA, contextualisée par l'intelligence projetée.

Les Backups Nextcloud — sauvegarde additionnelle. Trois sauvegardes sur un stockage cloud souverain distinct : un clone Git miroir du KERNEL, un clone de l'arborescence de fichiers du CORPUS, et une copie additive de la mémoire locale IA. Redondance souveraine — chaque sauvegarde reste réutilisable indépendamment, sans système propriétaire.

Le CORPUS en clair — souverain, sans index

Le CORPUS n'est pas une base de données : c'est un cloud de fichiers d'entreprise sur infrastructure souveraine, avec un client desktop. La bascule est là : le client synchronise l'arborescence dans l'explorateur de fichiers du poste, si bien que l'IA agentique y accède comme à n'importe quel dossier local — elle ouvre le dossier utile et lit les pièces à la demande. Aucun moteur d'embedding, aucun index vectoriel à maintenir : à l'échelle d'une PME, l'organisation par dossiers suffit. On y dépose aussi les résumés d'échanges produits par l'IA, en Markdown, pour qu'une session future les relise.

Le CORPUS est un atelier de fichiers, pas un coffre universel. Comme l'atelier de code ne contient jamais de données de production, l'atelier de fichiers ne reçoit que des contenus dont le traitement par une IA commerciale est légalement admissible — au regard du droit suisse de la protection des données — et éthiquement toléré par l'organisation. Ce qu'on choisit de ne pas y exposer ne disparaît pas : il vit dans un cloud d'entreprise traditionnel, séparé, auquel aucune IA du marché n'a accès — chez APCOM, un second serveur Nextcloud auto-hébergé ; chacun tranche selon sa ligne. La frontière n'est pas technique, elle est décidée : quoi confier à l'IA, où, pourquoi, avec quel outil.

Deux voies souveraines, selon le curseur autonomie / facilité — et une famille écartée par principe :

Le client desktop n'est pas le différenciateur — OneDrive l'offre aussi. Ce qui départage, c'est la souveraineté : Nextcloud et kDrive donnent la même commodité sans capturer la donnée. On ne choisit donc pas entre confort et souveraineté ; on refuse seulement les solutions captives.

Le flux d'intelligence

L'intelligence ne stagne pas dans les couches — elle circule selon quatre flux clairs.

Les quatre flux

• Sortant — la gouvernance projette le contexte du KERNEL (et des extraits ciblés du CORPUS) vers un SPOKE. Le destinataire travaille avec une IA augmentée par la vision, les conventions et les décisions de l'organisation — pas avec une IA générique.
• Entrant — ceux qui ont le droit d'écrire enrichissent le SPOKE pendant la mission. Leur travail, leurs observations, leurs décisions alimentent un flux de retour.
• Consolidation — seule la gouvernance décide ce qui entre dans le KERNEL ou dans le CORPUS. Chaque remontée fait l'objet d'une fusion Git explicite (merge --no-ff), déclenchée sur validation et traçable dans l'historique. Le merge n'est pas un écrasement silencieux : c'est un acte de gouvernance. Les SPOKES nourrissent, ne polluent pas.
• Archive ↔ extraction — flux interne KERNEL ↔ CORPUS. Quand un document est déposé dans le CORPUS (dans son dossier thématique), une extraction vivante est produite dans le KERNEL. L'extraction est lisible et concise — fiche, résumé, pointeur ; le CORPUS est la source dense, relue à la demande, dossier par dossier. Quand une information du KERNEL devient trop volumineuse, elle migre vers le CORPUS et laisse dans le KERNEL une fiche d'index.

Ce modèle résout simultanément plusieurs tensions :

• Sécurité — chaque destinataire voit uniquement ce qu'il doit voir. Et aucun secret ne vit dans la mémoire : ni dans le KERNEL, ni dans le CORPUS, ni dans un SPOKE. Les credentials sont conservés dans un coffre dédié et souverain ; la mémoire n'en porte qu'une cartographie — quel accès existe, où le trouver, jamais sa valeur.
• Effet multiplicateur — chaque membre et chaque partenaire devient une source d'intelligence augmentée. Ils ne consomment pas seulement le contexte ; ils le nourrissent.
• Scalabilité sans perte de contrôle — on peut créer 3 ou 30 SPOKES sans complexifier le système central. Si un accès doit être coupé, on ferme le SPOKE — le KERNEL n'est pas impacté.
• Scalabilité du contenu — l'organisation peut accumuler des années de documents denses sans jamais saturer la mémoire active de l'IA.

Une session de travail

Toute session obéit à la même discipline : elle n'écrit jamais directement sur la branche principale d'un dépôt. À son ouverture, elle crée sa branche de travail dédiée ; à sa clôture, cette branche est poussée ou consolidée. Cette pratique systématique prévient par construction les collisions entre sessions parallèles et rend chaque contribution traçable.

La consolidation vers la branche principale n'est jamais automatique : elle est ordonnée explicitement par la gouvernance (pour le KERNEL) ou par le propriétaire du SPOKE. Elle prend la forme d'une fusion Git (merge --no-ff) qui laisse dans l'historique une trace visible de qui a consolidé quoi, quand — pas d'écrasement silencieux, pas de réécriture. Dans le cas SPOKE → KERNEL, la gouvernance lit le SPOKE enrichi, propose les mises à jour fichier par fichier, valide l'intégration, puis archive ou ferme le SPOKE.

Typologie des sessions, cycle ouverture · cœur · clôture · consolidation et commandes exactes : dans la référence de développement.

Les principes fondamentaux

Six principes gouvernent cette architecture. Ils relèvent de la discipline d'organisation, pas de l'outil technique.

Souveraineté

La souveraineté n'est pas une option technique : c'est une règle structurelle. Tout ce qui constitue la mémoire — données, conventions, décisions — vit sur une infrastructure que l'organisation contrôle. Aucune dérogation ne tient dans la durée.

Versionnement

Chaque modification est tracée, datée, réversible. Si une erreur est introduite dans le contexte, on peut revenir en arrière. Si on veut comprendre l'évolution d'une décision, l'historique est là. Ce n'est pas un fichier texte qu'on écrase — c'est un système vivant avec une mémoire de sa propre évolution.

Structure plutôt que volume

La mémoire situative n'est pas un lac de données — c'est une architecture. Chaque information a sa place. Chaque fichier a un rôle. La structure elle-même est documentée et maintenue à jour. L'IA sait non seulement quoi lire, mais où chercher et pourquoi. Quand un fichier devient trop volumineux, un mécanisme d'archivage le segmente par période.

Cohérence outillée

Git n'est pas ici un simple support de versionnement. Il est l'outil par lequel la cohérence d'ensemble est maintenue quand plusieurs intelligences contribuent. Chaque contribution transite par une branche. Chaque remontée passe par une revue. Chaque intégration laisse trace. La friction est volontaire — elle rend visible ce qui, dans les systèmes classiques, se perd dans la boîte mail ou l'écrasement silencieux.

La gouvernance étend cette mécanique au code de production : une branche de chantier par sujet, une intégration sur un tronc commun, une livraison qui pose un jalon de version — branche, revue, trace, comme pour le KERNEL. Le modèle d'ensemble est détaillé en Partie IV (La boucle de développement).

Responsabilité inversée

Dans le modèle classique, c'est l'humain qui doit rappeler le contexte à l'IA. Ici, c'est l'IA qui a la responsabilité de maintenir, enrichir et protéger la mémoire. Si l'humain doit rappeler quelque chose qui est déjà documenté, l'IA a failli. Ce renversement de charge rend le système véritablement augmenté plutôt que simplement assisté.

Simplicité radicale

Deux technologies universelles : Git pour le versionnement, Markdown pour le contenu. N'importe qui peut écrire du Markdown ; n'importe quelle IA sait le lire ; n'importe quelle organisation peut utiliser Git. Cette simplicité rend le système accessible à quiconque et indépendant de tout fournisseur.

Si vous ne deviez retenir qu'une chose de cette partie — la mémoire d'une organisation doit être un actif qu'elle détient : structurée en couches (KERNEL léger, CORPUS dense, SPOKES éphémères), versionnée par Git. La technologie est gratuite ; c'est la discipline de structuration qui fait la valeur.

PARTIE III — LA CONDUITE

On ne dicte pas son chemin à ce qui sait explorer.

L'architecture des deux parties précédentes règle la question de la mémoire. Reste la seconde moitié, tout aussi décisive : la conduite. Une IA bien renseignée n'est pas encore une IA bien employée. La mémoire détermine ce que l'intelligence sait ; la conduite décide ce qu'on en obtient — un exécutant qui applique, ou un explorateur qui propose.

Cette doctrine a connu sa propre montée en puissance. D'un savoir-faire intuitif, elle est devenue une convention explicite et opposable, articulée autour d'un instrument central : la Donnée d'Ordres.

Le texte comme source exécutable

La mémoire situative n'est pas seulement une mémoire. C'est un script de paramétrage : un fichier de configuration déclaratif qui définit, en langage naturel, comment une intelligence artificielle doit se comporter, ce qu'elle doit protéger, ce qu'elle doit savoir. Avec les LLM, le langage naturel devient enfin source exécutable.

Pendant quatre-vingts ans, l'informatique a marché dans une seule direction — faire monter la machine vers le langage humain. Grace Hopper théorise le compilateur dès 1952⁶. FORTRAN (1957), COBOL (1959), puis C, Python, Ruby — chaque génération de langage rapproche la syntaxe formelle du parler naturel. Mais aucune n'atteint le but. Toutes exigent une grammaire figée, une rigueur syntaxique, un apprentissage.

Les LLM franchissent la dernière marche. Ce que l'on écrit en français structuré peut désormais orienter un comportement computationnel réel — sans compilation classique, sans langage intermédiaire, sans syntaxe imposée. Andrej Karpathy a popularisé cette bascule sous le nom de « Software 3.0 »⁴ : au code humain (Software 1.0) et aux modèles entraînés (2.0) s'ajoute une troisième couche — les programmes en langage naturel.

Cela change la nature de ce qui se construit. Le KERNEL n'est pas une documentation : c'est un code source comportemental. Les fichiers Markdown sont des déclarations de comportement ; la fiche identitaire d'un membre paramètre la manière dont l'IA interprète ses intentions.

Un LLM seul lit et génère. Un agent IA lit, agit et écrit — il peut cloner un dépôt, lire des fichiers, exécuter des commandes, pousser des modifications. Le modèle KERNEL-CORPUS-SPOKE est conçu pour cet usage : il ne documente pas l'organisation pour qu'un modèle la mémorise passivement — il lui donne un terrain d'action structuré et souverain. Quand plusieurs agents travaillent en parallèle sur le même contexte, la mémoire partagée et versionnée devient le seul garant de leur cohérence.

Ce paradigme a ses limites — il serait malhonnête de ne pas les nommer. Le langage naturel est ambigu par construction, ce que les langages formels ne sont pas. L'exécution est probabiliste : un même texte peut produire deux résultats différents. Et le résultat dépend du modèle qui l'interprète — pas de portabilité stricte entre fournisseurs.

C'est précisément pour cela que la structure du KERNEL réduit l'ambiguïté en contraignant le contexte ; la discipline d'écriture rend le comportement stable ; Git tient la mémoire déterministe de ce qui est, par nature, probabiliste.

Conduire par intention, pas par tâche

Le texte exécutable règle ce que l'IA sait. La conduite règle comment on l'emploie. L'erreur la plus courante consiste à parler à l'IA comme si l'on savait déjà comment faire ce que l'on veut faire : on décrit la procédure, on dicte les étapes, l'IA exécute. Le résultat est correct — mais pauvre. On vient de réduire l'un des systèmes d'exploration les plus puissants jamais construits à un suiveur d'instructions.

La puissance de l'IA n'est pas dans l'exécution — elle est dans l'interprétation. Elle naît du mixe entre l'intention humaine et l'exploration de la machine. Quand un humain exprime où il veut arriver et pourquoi — sans dicter le chemin — l'IA propose des routes qu'il n'aurait pas tracées seul. Ce sont ces routes inattendues, validées et orientées par l'humain, qui produisent les résultats supérieurs.

Conduire, c'est donc tenir l'image précise de l'état final recherché — pas du chemin pour y parvenir. L'exprimer comme une intention. Poser les bornes — ce qui ne peut être franchi — et confier une mission. Ce principe est codifié depuis des décennies dans la doctrine militaire suisse sous l'expression conduite en confiant des missions⁷ : « Les chefs définissent les buts à atteindre. Ils laissent à leurs subordonnés la plus grande liberté possible quant aux moyens à mettre en œuvre. » Le renversement n'est pas intuitif : il demande de savoir ce que l'on veut sans savoir comment l'obtenir. C'est là qu'est la compétence du commandant — dans la clarté de la vision, pas dans la maîtrise de la technique.

La Donnée d'Ordres

Conduire par intention suppose un instrument : un format d'ordre qui transmette la direction sans dicter le chemin. Chez APCOM, cet instrument est la Donnée d'Ordres — la D.O.

Une D.O. n'est pas une liste de tâches. C'est la transmission structurée d'une intention : elle répond au quoi et au pourquoi, jamais au comment. Le gouverneur émet la D.O. — il fixe l'orientation, l'intention et la mission ; il laisse l'exécutant, humain ou IA, explorer les moyens.

La D.O. se décline en trois formats. L'émetteur choisit le plus adapté — il n'y a pas de format par défaut.

La D.O. en cinq points — pour un chantier nouveau, une mission engageante, un changement structurel :

1. Orientation — le décor posé net : ce qui se passe, ce qu'on sait, ce qu'on ignore. Inclut la mission que l'émetteur a lui-même reçue à son niveau, pour éclairer le pourquoi.
2. Intention — la direction recherchée, à grands traits. Pas le chemin.
3. Mission — l'état final attendu, par objectif et par acteur. Le quoi, pas le comment.
4. Dispositions particulières — les contraintes non négociables : conventions, normes, sécurité, échéances critiques, dépendances.
5. Emplacements — l'organisation pratique : canaux, outils, fréquence d'audit, décideur en cas de friction.

La D.O. en trois points — pour une tâche dans le cadre courant, sans contrainte nouvelle : orientation · intention · mission, en quelques phrases. Dispositions et emplacements restent implicites — le cadre habituel. Dès qu'une contrainte nouvelle s'impose, on repasse au format long.

Le FRAGO — l'ordre fragmentaire. Un ajustement émis en cours d'exécution : ce qui change, pourquoi, à partir de quand. Le FRAGO ne touche ni la mission ni l'intention — seulement l'exécution. Il corrige sans tout réémettre.

Quittancer, puis converger

Une D.O. émise n'est pas une D.O. comprise. Avant toute exécution sur une tâche non triviale, l'exécutant quittance : il reformule l'orientation, l'intention et la mission telles qu'il les a saisies ; il pose ses questions ; il expose le ou les chemins qu'il compte prendre. Le gouverneur valide, ou corrige. L'exécution ne commence qu'une fois l'idée de manœuvre alignée.

Ce quittancement n'est pas une formalité — c'est le premier delta : la vérification que l'image de l'état final est partagée avant que le travail commence. Un malentendu détecté là coûte une phrase ; détecté en fin d'exécution, il coûte le travail entier.

La mission lancée, la conduite s'exerce en boucle continue — le delta management : comparer en permanence l'état en cours à l'état final visé, mesurer l'écart résiduel, corriger la trajectoire, répéter jusqu'à convergence. Après chaque livraison partielle : comparer, recadrer. Si l'exécution doit dévier sans que la mission change, un FRAGO suffit.

 ①  DONNÉE D'ORDRES
     le gouverneur fixe l'orientation, l'intention, la mission
        │
        ▼
 ②  QUITTANCEMENT
     l'exécutant reformule, questionne, expose son plan
     → le gouverneur aligne l'idée de manœuvre
        │
        ▼
 ┌─► ③  EXÉCUTION
 │       l'exécutant explore les moyens, livre par bonds
 │        │
 │        ▼
 │   ④  BOUCLE DELTA — état en cours comparé à l'état final
 │        │
 └────────┤   écart résiduel → recadrage · FRAGO
          │
          ▼
       CONVERGENCE — état final atteint

La notion de delta management m'a été transmise par le Brigadier Maurizio Dattrino⁸ alors que j'étais capitaine, commandant une compagnie d'infanterie sous ses ordres. Ce que j'ai reçu comme un art du commandement entre hommes s'est révélé universel : ce qui décuple le potentiel d'un subordonné humain décuple à l'identique le potentiel d'une IA sous conduite. L'art transcende l'interlocuteur.

Ce que cela change pour une équipe

Pour une équipe augmentée par l'IA, cette doctrine implique un déplacement de compétence : moins de savoir-faire procédural, plus de clarté sur les intentions. Savoir dire où l'on veut aller et pourquoi devient plus précieux que savoir dire comment y aller.

Ce n'est pas une délégation aveugle. Le gouverneur garde le contrôle de l'état final : il valide les chemins proposés, corrige les dérives. Mais il n'est plus enfermé dans la technique — il est libéré pour tenir la vision.

Et la doctrine vaut dans les deux sens. Une IA conduite par D.O. reconnaît le format reçu, quittance dans la même grille, propose ses chemins sans attendre qu'on les dicte, et signale d'elle-même tout écart entre l'état en cours et l'état final. La conduite cesse d'être l'effort de l'humain seul — elle devient une convention partagée.

La doctrine de conduite opérationnelle — principe, schéma de la Donnée d'Ordres, quittancement, boucle delta — est documentée dans GLOBAL/CONDUITE/ du KERNEL.

Si vous ne deviez retenir qu'une chose de cette partie — conduire une IA, c'est transmettre l'état final recherché et les bornes, jamais le chemin. La Donnée d'Ordres porte l'intention ; le quittancement aligne ; la boucle delta fait converger.

PARTIE IV — MISE EN ŒUVRE : APCOM SOLUTIONS SA

Un modèle vaut ce que vaut son incarnation — voici la nôtre, en production.

Le modèle théorique vaut ce que vaut son incarnation concrète. Voici ce que l'expérience APCOM — un système en production — a enseigné sur la manière de tenir un KERNEL vivant, sans qu'il dérive ni se fige — et sur la manière de conduire, sur le même socle Git, le développement logiciel de production (La boucle de développement).

Une structure par fonction, pas par projet

Le piège serait d'organiser le KERNEL par projets en cours — chaque projet aurait son dossier, avec tout ce qui le concerne rassemblé. Mauvaise idée : les projets vont et viennent, mais les fonctions (équipe, clients, infrastructure, stratégie) persistent. Le KERNEL APCOM est organisé par fonction :

KERNEL/
├── GLOBAL/                # constitution, règles, conduite, rituels, cartes
│   ├── CORE.md            # constitution — valeurs, gouvernance, règles permanentes
│   ├── MEMOIRE_VIVE.md    # état inter-sessions — écrasé à chaque clôture
│   ├── CREDENTIALS.md     # cartographie des accès — aucun secret en clair
│   ├── ROADMAP.md         # registre des évolutions (EVO-NNN)
│   ├── CONDUITE/          # doctrine de conduite — principe, Donnée d'Ordres
│   ├── SESSION/           # rituels de session — OUVERTURE.md, CLOTURE.md
│   └── STRUCTURE/         # cartes vivantes — KERNEL, CORPUS, SPOKES, GIT, Backups
├── EQUIPE/                # organisation par flux, profils des membres
├── CLIENTS/               # index clientèle — pas de contenu dense
├── PROJETS/               # conduite de projet — API et méthodes des outils
├── SERVEURS/              # accès hébergeurs, architecture serveur
├── STACK_TECHNIQUE/       # stack des logiciels + routines de développement
└── MANIFESTE/             # corpus éditorial

Carte complète et tenue à jour de l'arborescence : GLOBAL/STRUCTURE/KERNEL.md.

Cette structure permet à l'IA de naviguer par type de question — « que sais-je de ce client ? », « quelles sont les règles de production ? », « qui dans l'équipe travaille sur quelle stack ? » — plutôt que par arborescence de projets. Une décision de projet met à jour plusieurs dossiers simultanément : le suivi du projet dans le CORPUS, l'annuaire du client, parfois le profil d'un membre. Cette dispersion est voulue : elle fait que chaque couche reste navigable seule.

L'équipe organisée par flux

Une organisation traditionnelle est structurée par hiérarchie : direction, cadres intermédiaires, équipes opérationnelles. Cette structure pré-IA tenait sa cohérence de la chaîne de commandement — chaque échelon traduisait, filtrait, orientait l'information vers l'échelon suivant. Mais quand l'IA absorbe le travail d'exécution et de coordination, la chaîne hiérarchique perd une partie de sa raison d'être : elle introduit des délais et des pertes d'information dans un système qui en demande de moins en moins.

L'organisation APCOM s'est construite sur un autre principe : non hiérarchique, par flux distincts, avec une gouvernance transverse.

Schéma d'ensemble

Le principe — gouvernance transverse, deux flux

La gouvernance n'est pas un sommet de pyramide. Elle encercle l'ensemble des processus. Elle décide la procédure, la composition de l'équipe, l'architecture serveur et logicielle. Elle ne s'insère pas dans les flux : elle les définit, les arbitre et les fait évoluer.

Deux flux orthogonaux se rencontrent à un pivot opérationnel :

• Le flux externe est l'interface entre l'organisation et le marché : conduite de projets côté client, devis, facturation, formation, livraison. Il porte la responsabilité contractuelle.
• Le flux interne structure et cadence le travail de production : structuration des tâches, planification, suivi, test, validation. Il porte la responsabilité technique.

Le pivot flux externe ↔ flux interne est le point critique de la chaîne. C'est là que le besoin formalisé bascule du marché vers la production, et que le travail validé remonte de la production vers le marché. Ce pivot garantit qu'aucun travail ne sort vers le client sans validation interne, et qu'aucune livraison ne s'effectue sans contrôle contractuel.

L'équipe technique exécute le travail de développement sous le cadrage du flux interne. Aucun développeur ne reçoit directement une demande client — tout passe par la chaîne flux externe → flux interne → équipe technique.

Pourquoi cette organisation sert la mémoire situative

Cette structure n'est pas qu'une organisation du travail. Elle a deux conséquences directes sur la manière dont l'IA peut augmenter l'organisation :

1. Chaque flux est augmentable indépendamment. Une chaîne hiérarchique propage les décisions de proche en proche — chaque échelon doit traduire pour le suivant. Une organisation par flux donne à chaque acteur la responsabilité complète de son segment de chaîne. L'IA peut alors augmenter chaque flux à hauteur de sa fonction : le flux externe avec un contexte client persistant et une génération automatisée de PV, le flux interne avec un audit qualité automatisé et la formulation de directives techniques précises, l'équipe technique avec un cadrage explicite sur chaque ticket. Les profils individuels (EQUIPE/<MEMBRE>/PROFIL.md) permettent à l'IA d'ajuster son comportement à chaque acteur — ses forces, ses points de vigilance, ses directives spécifiques.

2. Chaque flux peut recevoir son SPOKE. Quand un flux a besoin de contexte pour une mission, la gouvernance projette un SPOKE qui contient exactement ce qu'il faut — pas plus. Un SPOKE pour l'équipe technique sur un projet précis ne contient pas la cartographie commerciale ; un SPOKE pour le flux externe sur un nouveau prospect ne contient pas le code source. La séparation des flux rend les projections SPOKE naturelles et étanches.

Cas particulier — l'intégration tiers

Quand un projet implique l'intégration avec un système externe (API d'un prestataire, partenaire technique), la livraison ne peut pas être portée seule par le flux externe — elle nécessite une compréhension technique du protocole. Dans ce cas, le flux interne participe à la livraison aux côtés du flux externe. Le flux externe garde la responsabilité contractuelle ; le flux interne porte la dimension technique de l'interface.

Source unique de vérité de l'organisation APCOM : EQUIPE/ORGANISATION.md du KERNEL.

La routine projet et le rôle du CORPUS

Une organisation par flux (section précédente) précise qui fait quoi. Une routine projet précise comment : la séquence d'étapes par laquelle un besoin client devient un livrable validé, avec une traçabilité explicite à chaque étape. La routine devient elle-même mémoire d'organisation.

La chaîne de bout en bout

Chaque étape précise qui agit, quel outil, quel livrable, quelle traçabilité. La séquence est rigide ; ce qui circule à l'intérieur (le contenu de chaque étape) est variable selon le projet.

Le commit comme pivot de traçabilité

Le point névralgique de la routine est la convention deck-commit-timesheet : la carte Deck porte la demande contractuelle, le commit référence la carte, la saisie timesheet référence le commit. Le commit devient ainsi le pivot qui relie l'effort enregistré à la demande contractuelle ; le journal de projet vivant n'est que la consolidation de ces trois sources, sans rédaction supplémentaire. Le format exact des références — préfixe de carte, hash de commit — est tenu dans la référence de développement.

Le rôle du CORPUS dans la routine

La rédaction formelle du besoin (étape 2) produit un document — généralement un cahier de besoin structuré en Markdown. Ce document a trois lieux de stockage :

1. Nextcloud personnel du producteur — espace de travail individuel pendant la rédaction
2. Partage interne — pour relecture et appui par l'équipe
3. CORPUS souverain — dépôt long terme dans le dossier projet ou client concerné

Les deux premiers lieux sont des supports de production immédiate. Le troisième est ce qui transforme un document écrit une fois en mémoire relisible pour toujours.

Trois bénéfices opérationnels justifient le dépôt systématique des cahiers de besoin dans le CORPUS :

1. Mémoire transverse au-delà des personnes. Le Nextcloud d'un collaborateur peut être réorganisé, purgé, ou ne plus être accessible si la personne quitte la société. Le CORPUS, lui, est un actif d'entreprise. Un cahier de besoin archivé en 2024 reste interrogeable en 2030, indépendamment du parcours du collaborateur qui l'a rédigé.

2. Recherche contextuelle inter-projets. Quand un nouveau besoin arrive, on demande à l'IA d'ouvrir le CORPUS et de parcourir les cahiers du dossier concerné : « a-t-on déjà traité une demande similaire ? », « quel chiffrage avons-nous fait pour une fonction de ce type ? ». Elle lit les cahiers pertinents et en tire la réponse. On ne repart jamais de zéro.

3. Contextualisation IA pour la production. Quand un développeur attaque un nouveau ticket, l'IA peut nourrir son contexte avec les éléments du cahier de besoin original — sans qu'il ait à le lire en entier. Le CORPUS sert d'intermédiaire entre la documentation de besoin (dense, longue) et l'exécution technique (qui n'a besoin que de l'essentiel à chaque moment).

L'investissement au dépôt est marginal — un fichier .md classé dans le bon dossier. Le retour s'apprécie dans la durée : chaque nouveau projet devient plus rapide et plus juste grâce à l'accumulation. C'est le principe d'intérêts composés appliqué à la mémoire d'organisation — la valeur ne s'additionne pas, elle se multiplie.

Routine opérationnelle complète et conventions techniques détaillées : STACK_TECHNIQUE/ROUTINES/PROJET.md du KERNEL.

La boucle de développement — atelier souverain et vitrine publique

La routine projet dit quoi tracer et s'arrête au commit. Reste à dire par où ce commit passe avant d'atteindre la production. La gouvernance fixe désormais une ligne unique pour le développement : un même cadre Git pour tous les dépôts, là où les pratiques divergeaient d'un logiciel à l'autre. L'opposabilité vaut dès maintenant ; la résorption des écarts se fait projet par projet.

Ce cadre n'invente rien — il étend au code de production une discipline déjà posée pour la mémoire : le travail en branche systématique, et la Règle 24, qui interdit à l'IA tout accès en écriture aux dépôts hors infrastructure souveraine. De cette règle naît l'image qui gouverne tout le flux — l'atelier et la vitrine.

Le dépôt souverain — chez APCOM, Forgejo auto-hébergé — est l'atelier : il détient toute la vérité, branches de chantier, commits intermédiaires, historique granulaire, développement et production. Le dépôt public — GitHub — est la vitrine : elle ne reçoit que la production livrée, la branche de production et ses jalons de version, jamais le tronc d'intégration ni les chantiers. Les deux historiques divergent volontairement : la vitrine offre un historique de release lisible à ceux qui consultent GitHub ; l'atelier garde tout le reste.

Le modèle tient en une ligne — commit → feature → develop → main + tag : grain, chantier, intégration, livraison, jalon figé. Deux règles d'or le gardent, prolongement direct des disciplines de la mémoire :

• ne jamais pousser large vers la vitrine — on nomme toujours ce qu'on publie, la branche de production et le jalon livré, jamais une poussée globale ;
• ne jamais réécrire un jalon publié — un tag poussé est immuable ; une version défaillante appelle un correctif incrémenté, pas une réécriture.

Le manifeste affirme le cap ; la manœuvre vit dans l'atelier. Les neuf bascules du flux — de l'ouverture d'un chantier au retour arrière —, leurs déclencheurs, leurs commandes exactes et l'état réel de chaque logiciel sont tenus dans la référence de développement, pour ceux qui construisent — adossée elle-même, pour la vérité vivante par logiciel, aux fichiers du KERNEL.

Des règles permanentes, pas des bonnes intentions

Le CORE du KERNEL contient un ensemble de règles permanentes numérotées — vingt-cinq à ce jour, regroupées en six familles : comportement avec l'utilisateur, responsabilités et charge, production, Git et commits, structure et archivage, architecture mémoire. Chacune tient en une à trois lignes, avec un impératif clair. La numérotation est stable : les autres fichiers du KERNEL référencent une règle par son numéro sans la réexpliquer. Quelques exemples tirés du vécu :

• Règle 12 — L'humain qui opère est seul auteur de tous les commits. Jamais de mention de l'IA dans les métadonnées Git. L'IA est un outil, pas un contributeur.
• Règle 13 — Commits par bloc logique, pas par micro-étape. On accumule, on valide, on commit un bloc cohérent. L'historique reste lisible.
• Règle 14 — Trois ordres distincts : écrire, commiter, pousser. L'IA accumule en mémoire de session ; sur ordre explicite, elle écrit ; sur un ordre séparé, elle commite ; sur un troisième, elle pousse. Trois portes, trois ordres.
• Règle 15 — Chaque ajout, renommage ou suppression de fichier → mise à jour de la carte vivante GLOBAL/STRUCTURE/KERNEL.md. Pas de structure à deux vitesses où la réalité diverge de la documentation.

Ces règles ne sont pas des vœux : elles sont opposables. Si l'IA s'en écarte, l'utilisateur le signale. Si l'IA les rappelle l'une après l'autre sans friction, le système fonctionne.

Elles encadrent aussi le code de production. La Règle 24 — séparation entre l'IA et les dépôts de production hors infrastructure souveraine — fonde la barrière entre l'atelier et la vitrine : seul l'humain pousse vers le dépôt public, et il nomme toujours ce qu'il livre.

L'ouverture et la clôture de session

Chaque session de travail sur le KERNEL suit deux rituels inscrits noir sur blanc — l'ouverture et la clôture. L'ouverture : synchroniser le clone, lire la constitution, lire l'état de la dernière session, lire le profil de l'utilisateur, ouvrir la branche de travail. La clôture : proposer les mises à jour, commiter par bloc logique, pousser sur ordre, mettre à jour la mémoire inter-sessions, synchroniser les Backups. Ces rituels ont un coût — quelques minutes de part et d'autre. C'est le prix de la continuité.

Ces rituels de session se distinguent des routines de développement — ouverture, permanence, clôture, cycle de vie projet — qui encadrent le travail des équipiers sur les logiciels, dans les SPOKES. Les premiers gouvernent les sessions sur le KERNEL ; les secondes, le travail de production. Deux familles, deux jeux de fichiers distincts — pour qu'aucune ne soit prise pour l'autre. Ces routines de développement ont vocation à reposer sur la ligne Git unique fixée plus haut (La boucle de développement) — c'est elle qui en règle le flux, de la branche de chantier au jalon de production.

Le travail en branche systématique

Au départ, l'architecture autorisait le travail direct sur la branche principale quand une seule session était active. Une collision entre deux sessions ouvertes simultanément a révélé la faille : rien ne garantit a priori qu'une autre session ne surgira pas. La règle a été durcie — toute session crée sa branche de travail avant toute écriture, sans exception. Cette discipline a un effet secondaire précieux : chaque bloc de travail devient un jalon isolé et révocable, chaque évolution de la branche principale un acte de gouvernance tracé. Le travail réellement parallèle — plusieurs agents en même temps — s'isole en worktrees Git distincts ; la mécanique exacte est tenue dans la référence de développement.

La vigilance de cohérence

L'IA aime travailler — et c'est précisément le risque. Laissée sans cadre strict, elle tend à remplir l'espace : expliquer une procédure dans un fichier de directive, puis la répéter dans un fichier de structure. Chaque fichier semble complet en lui-même ; l'ensemble devient redondant, gonflé, moins lisible.

Cette vigilance appartient au gouverneur. À chaque consolidation du KERNEL ou du CORE, il vérifie que l'information nouvellement ajoutée ne duplique pas ce qui existe déjà. La règle est simple : une information a une place — les autres fichiers y pointent, ils ne la répètent pas.

La bonne nouvelle : l'IA se remet en cohérence rapidement, dès que le besoin est clairement formulé. Un audit de cohérence précis produit des corrections fiables. La précision et la discipline restent côté humain — le travail de remise en ordre, lui, peut être délégué.

Piloter par objectif, pas par tâche

L'agent IA n'est pas fait pour les petites choses. Il est fait pour les grandes. Deux cents micro-tâches dispersées ne valent pas une session conduite sur un objectif structurant clair.

La discipline qui s'impose : formuler l'objectif, conduire l'agent à hauteur — architecture, cohérence, structure — puis à chaque itération auditer, optimiser et nettoyer l'ensemble plutôt que des points isolés. Un regard global sur ce qui a été produit, une décision sur ce qui tient et ce qui non.

C'est la logique du delta management appliquée à l'agent : la puissance n'est pas dans la vitesse — elle est dans le niveau auquel il travaille quand on lui confie une direction, pas une liste.

La consolidation en lot

Les agents IA ont un réflexe naturel : consolider immédiatement vers le dépôt distant. Ce comportement multiplie les allers-retours réseau et fragmente le travail sans valeur ajoutée.

La discipline retenue est inverse : maximiser le travail en session avant toute consolidation distante. Accumuler les modifications validées pendant que le contexte est chaud. Quand un lot cohérent est prêt, structurer la consolidation explicitement — local d'abord (commits, merge sur main), distant ensuite (push). L'ordre de pousser reste une décision explicite de la gouvernance, jamais un automatisme.

Guide d'implémentation

Pour reproduire cette approche, voici les étapes essentielles.

Une précision préalable : ce guide décrit une implémentation — celle d'APCOM Solutions SA. Le cadre est transposable ; ce qu'on y met ne l'est pas tel quel. KERNEL-CORPUS-SPOKE-Backups est l'architecture de base — elle tient pour toute organisation. Ce qui variera, c'est son contenu : les fonctions à documenter, les règles à rendre opposables, les conventions à établir. Une fiduciaire, un cabinet d'architectes ou un prestataire de santé construiront un KERNEL qui reflète leur métier, leur équipe, leur culture. La logique est partagée. L'incarnation sera la leur.

1. Créer un dépôt Git privé (le KERNEL)

N'importe quel fournisseur convient : Forgejo auto-hébergé, GitLab, Gitea. L'essentiel est que le dépôt soit privé et que vous en contrôliez l'accès. C'est votre KERNEL — la mémoire permanente de l'organisation. Il ne se ferme jamais.

2. Structurer par fonction, pas par projet

Créez les couches par fonction : GLOBAL (constitution, règles, conduite, routines), EQUIPE, CLIENTS, PROJETS, SERVEURS, STACK_TECHNIQUE, MANIFESTE. Chaque fichier a un rôle précis. Un fichier sacré (la constitution) qui ne change presque jamais. Des fichiers vivants (journaux, états de projet) qui évoluent à chaque session.

3. Écrire la constitution en premier

C'est le plus important et le plus difficile. Qui êtes-vous. Comment vous travaillez. Quelles sont vos faiblesses connues. Quelles valeurs sont non négociables. Quelles règles l'IA doit suivre, et comment vous la conduisez. Ce fichier est votre contrat avec la machine — il définit la relation et le cadre.

4. Donner l'accès à l'IA dès l'ouverture de session

Un clone Git local, lu par l'IA en début de session. Elle lit d'abord la constitution, puis l'état de la dernière session (mémoire inter-sessions), puis le profil de l'utilisateur qu'elle va assister. Elle est opérationnelle en quelques secondes, sans qu'on ait à ré-expliquer.

5. Travailler systématiquement en branche

Aucune session n'écrit directement sur la branche principale du KERNEL. Avant toute modification, la session ouvre sa branche (git checkout -b work/<sujet>). Elle commite par bloc logique — pas de micro-commits. En fin de session, la branche est poussée. La consolidation vers la branche principale est un acte délibéré, ordonné explicitement.

6. Confier la maintenance à l'IA

Ne mettez pas à jour les fichiers vous-même. Demandez à l'IA de proposer les mises à jour, de fournir les fichiers complets, de maintenir la carte de structure à jour. Vous validez. Elle exécute. Si vous devez lui rappeler de le faire, affinez les règles de la constitution.

7. Ajouter un CORPUS quand le volume le justifie

Tant que le KERNEL reste lisible rapidement, il se suffit. Quand les documents s'accumulent, séparez : gardez dans le KERNEL les index et les extractions stratégiques ; déposez les contenus denses dans un cloud d'entreprise souverain doté d'un client desktop — Nextcloud auto-hébergé si vous voulez l'autonomie complète, kDrive Infomaniak si vous préférez un service géré souverain. L'arborescence se synchronise dans l'explorateur du poste ; l'IA y ouvre à la demande le dossier utile et lit les pièces — sans base vectorielle, sans indexation. Fuyez les clouds propriétaires captifs (OneDrive et consorts) : mêmes fonctions, mais données sous droit étranger.

8. Projeter vers les autres via les SPOKES

Quand un collaborateur interne, un client ou un partenaire externe a besoin de contexte pour une mission, créez un dépôt éphémère séparé (SPOKE) dans votre organisation Git, avec les droits ajustés. Il contient ce qu'il doit voir, rien de plus. Celui qui l'utilise y travaille, y écrit éventuellement. La consolidation vers le KERNEL passe par une revue explicite — vous intégrez ce qui mérite d'entrer, vous archivez ce qui est dense dans le CORPUS, vous fermez le SPOKE quand la mission s'achève.

CLÔTURE TRANSVERSALE

Limites — ce que ce système ne résout pas

Par honnêteté envers le lecteur, il faut nommer ce que ce système ne résout pas. Les limites se rangent en deux familles : celles du support technique, celles de la maturité de l'organisation qui l'adopte.

Limites techniques.

La mémoire probabiliste du modèle. Même avec un KERNEL structuré, l'IA peut oublier des fondamentaux en cours de session : tous les LLM actuels exhibent un memory drift et un contextual forgetting bien avant la limite annoncée de leur fenêtre de contexte⁵. La longueur réellement exploitable est inférieure à la longueur théorique. La limite touche Claude comme GPT comme Gemini — elle est structurelle au paradigme. Le KERNEL ne la fait pas disparaître ; il la compense par la discipline de structure et la relecture ciblée. C'est pourquoi la responsabilité inversée compte : l'IA doit signaler ses propres oublis et proposer de revenir lire un fichier précis plutôt que de produire depuis une mémoire dégradée.

Le support Markdown, et sa charge d'entretien. Le Markdown n'a ni schéma, ni validation, ni exécution native : un fichier mal structuré n'est pas détecté automatiquement. C'est le prix de la simplicité radicale — le garde-fou est humain, la discipline d'écriture, outillée par la structure documentée. S'y ajoute un entretien réel : un KERNEL vivant accumule règles et notes, et sans épuration périodique il devient dense et redondant — exactement l'inverse de ce qui fait sa valeur. La discipline retenue est l'audit périodique.

Limites de maturité organisationnelle.

Le coût d'entrée est réel. Écrire une constitution exige de savoir qui l'on est et quelles règles on veut rendre opposables. Intégrer les routines — ouverture, clôture, quelques minutes de part et d'autre — demande une discipline que la plupart des organisations n'ont pas encore installée, et une équipe à l'aise avec Git et la documentation structurée. À évaluer honnêtement avant de commencer.

La souveraineté est réelle sur les données, partielle sur le comportement. La constitution est optimisée pour le modèle avec lequel elle a été construite. Changer de fournisseur ne sera pas indolore — certaines conventions devront être réécrites. Ce n'est pas un verrouillage propriétaire, mais un coût de migration réel ; tester la portabilité sur deux modèles avant de s'engager est une précaution raisonnable.

La gouvernance de mémoire est une compétence, pas une installation. Un accompagnement externe peut construire la structure et donner l'autonomie technique ; il ne donne pas l'autonomie de gestion. Confondre les deux est la première cause d'échec : une mémoire qui n'appartient pas à ceux qui la vivent se vide de sa substance, ou se fige faute de gouverneur qui comprend ce qu'il gère. C'est là que la responsabilité inversée — l'IA maintient, l'humain valide — reste à construire dans la durée.

Le différentiel de souveraineté peut s'éroder. Cet essai repose sur un constat : les éditeurs d'IA n'offrent pas de vraie souveraineté sur votre mémoire. Il est juste aujourd'hui ; il pourrait changer s'ils garantissaient contractuellement export intégral, non-entraînement et portabilité réelle. Avant de bâtir une stratégie sur ce différentiel, tranchez la question préalable : la souveraineté des données est-elle, pour vous, un critère non négociable ? Si oui, ce système a une valeur indépendante de l'évolution du marché.

Une trajectoire, enfin, reste ouverte et assumée : les modèles qui interprètent le KERNEL et lisent le CORPUS sont aujourd'hui commerciaux. La mémoire — données et contextes — est déjà sous contrôle souverain ; il restera, quand la qualité open source le permettra, à passer le moteur d'inférence lui-même sous la même règle. Comme les évolutions consignées au registre (EVO-NNN, indexé dans GLOBAL/ROADMAP.md), elle n'est pas bloquante : le système fonctionne tel quel — ces chantiers relèvent du perfectionnement, pas de la correction.

Clôture

Ce texte décrit un système opérationnel — pas un concept théorique. Il fonctionne aujourd'hui, dans une petite entreprise suisse, avec une équipe réduite. Il n'a demandé ni investissement lourd, ni compétence technique exceptionnelle : des outils universels (Git, Markdown), une infrastructure souveraine modeste (un VPS), et une discipline de structuration qui se construit avec le temps.

Ce qu'on ne peut ni acheter ni copier, c'est cette discipline — et c'est elle, pas l'outil, qui se capitalise. La technologie est gratuite et interchangeable ; la conduite, elle, fait la différence : une mémoire détenue, conduite par intention, vaut infiniment plus qu'une mémoire louée, pilotée à la tâche.

Ce texte est daté — et le dire est une honnêteté nécessaire. Le domaine évolue : certaines pratiques seront adaptées, d'autres abandonnées, quelques-unes remplacées par des approches qu'on ne voit pas encore. C'est précisément pour cela qu'il faut commencer maintenant : celui qui s'y met aujourd'hui, même imparfaitement, sera dans un an infiniment mieux placé que celui qui attend une certitude qui n'arrivera jamais tout à fait.

La question qui reste est moins technique que stratégique : quelle organisation acceptera longtemps de laisser sa mémoire contextuelle vivre chez un fournisseur dont elle ne détient pas les clés ?

Historique de version

• v1.9 (2026-07-02) — Deux apports conceptuels. (1) La liberté opérationnelle et sa frontière : détenir sa mémoire permet de changer de modèle et de composer une équipe d'IA de plusieurs éditeurs, hors de la suite d'agents d'un fournisseur unique — liberté toutefois bornée, les IA les plus productives restant commerciales, d'où la décision explicite de ce qu'une IA commerciale a le droit de voir. (2) Le CORPUS requalifié en atelier de fichiers : comme l'atelier de code exclut les données de production, l'atelier de fichiers n'accueille que des contenus dont le traitement par une IA commerciale est légalement (droit suisse) et éthiquement admissible ; le reste vit dans un cloud d'entreprise traditionnel fermé à l'IA. La barrière atelier/vitrine passe ainsi du code à la donnée (manifeste et référence de développement). Illustration concrète ajoutée en Partie I : le Tribunal fédéral suisse, sur logiciel libre depuis plus de vingt ans, à l'écart des géants américains. Glossaire et sources complétés.
• v1.8 (2026-07-01) — Allègement éditorial et application de la doctrine atelier/vitrine au texte lui-même : l'outillage opérationnel — neuf bascules du flux Git, tableaux, mécanique de branche et de session, convention deck-commit-timesheet — migre vers une page publique compagnon, la référence de développement (manifeste.apcom.app/dev) ; le manifeste conserve la thèse, le modèle en une ligne et les deux règles d'or. « La boucle de développement » compressée (~26 %) ; ré-enseignement de la discipline de branche supprimé (Parties II et IV) ; deux sections de limites fusionnées en deux familles (technique / maturité organisationnelle) ; passe « une idée par phrase », exergues et encarts « à retenir » ajoutés ; glossaire scindé (termes du flux — feat, hotfix, rollback — déplacés vers la référence de développement). Refonte du CORPUS : le RAG vectoriel (AnythingLLM / Ollama / LanceDB) est abandonné au profit d'un cloud de fichiers d'entreprise souverain à client desktop — Nextcloud auto-hébergé chez APCOM, kDrive Infomaniak en variante déléguée — où l'IA agentique se contextualise à la demande dans les dossiers via l'explorateur du poste, sans index ni API ; les solutions propriétaires captives (OneDrive, etc.) sont écartées, le RAG relégué à l'état de l'art. Diagrammes « Structures internes », glossaire, routine projet et clôture réalignés.
• v1.7 (2026-06-08) — Ajout en Partie IV du chapitre La boucle de développement — atelier souverain et vitrine publique, gravé en doctrine cible (standard fixé par la gouvernance, hétérogénéité antérieure en cours de résorption) : atelier Forgejo (toute la vérité) ↔ vitrine GitHub (branche de production + tags uniquement) ; modèle commit → feature → develop → main + tag ; correctif urgent depuis le tag de prod, propagation anti-régression, retour arrière par redéploiement de tag ; garde-fou test live + protection de branche (à verrouiller). Les neuf bascules sont reprises sous le schéma en trois tableaux de légende (features, hotfix, rollback) ; les commandes Git exactes et l'état réel par logiciel restent dans GLOBAL/STRUCTURE/GIT.md (Règle 10). Glossaire complété (atelier/vitrine, develop, feat, tag de version, hotfix, rollback). Correction factuelle : règles permanentes du CORE portées à vingt-cinq.
• v1.6 (2026-05-22) — Réalignement intégral sur le KERNEL courant. Montée en puissance de la conduite : la Donnée d'Ordres (5 points / 3 points / FRAGO), le quittancement et la boucle delta formalisés en Partie III. Introduction des deux piliers — mémoire et conduite. Correction : les credentials vivent dans un coffre dédié, jamais dans la mémoire. Mise à jour de l'arborescence, des rituels de session (ouverture / clôture), du travail parallèle par worktrees, et du registre des évolutions.
• v1.5 (2026-04-27) — Chapitrage en cinq parties. Partie IV enrichie (équipe par flux, routine projet, rôle du CORPUS RAG). Alignement sur le CORPUS RAG souverain.

Glossaire

Sources

¹ Karpathy, A. — LLM Wiki (GitHub Gist, 4 avril 2026). Concept présenté comme alternative aux systèmes RAG : une base de connaissances en Markdown structuré, construite et maintenue par un LLM, qu'il consulte au moment des requêtes. Convergence notable avec la couche KERNEL du modèle décrit ici — pour les contenus denses, l'architecture APCOM y adjoint un cloud de fichiers souverain, lu à la demande.

² DSPy — Framework de programmation en langage naturel (Stanford NLP, Omar Khattab et al.). Traite les prompts comme du code : modules composables, optimisation automatique, séparation explicite entre les instructions et les modèles qui les exécutent.

³ Pattern hub-and-spoke — modèle architectural central-et-satellites. Apparu en logistique dans les années 1970, étendu aux réseaux informatiques, puis récemment aux architectures multi-agents LLM. Le modèle KERNEL-CORPUS-SPOKE en est une extension, enrichie d'une gouvernance asymétrique, d'une impermanence des satellites, et d'une consolidation filtrée.

⁴ Karpathy, A. — « Software 3.0 » (juin 2025). Cadre conceptuel étendant les paradigmes Software 1.0 (code humain) et Software 2.0 (modèles entraînés) d'une troisième couche : les LLM comme systèmes programmables interprétant du langage naturel.

⁵ Limites de la mémoire contextuelle des LLM — sources scientifiques. Les LLM exhibent un memory drift et un contextual forgetting bien avant la limite annoncée de leur fenêtre de contexte effective ; ils n'ont pas de mémoire au sens traditionnel et relisent tout le contexte à chaque tour. Contraintes techniques : croissance quadratique du mécanisme d'attention, coûts mémoire GPU.

⁶ Chronologie des langages — Grace Hopper et les premiers compilateurs. Grace Hopper théorise le compilateur et développe le premier (A-0) en 1952. FORTRAN (1957) marque le premier pas significatif ; COBOL (1959), conçu pour être lisible par un manager, vise explicitement à rapprocher la syntaxe du langage humain. Jalons de la trajectoire « faire monter la machine vers le langage humain » que les LLM ont achevée en 2022-2023.

⁷ Règlement de service de l'armée (RSA) — Conduite en confiant des missions (RS 51.002). Articles clés : les chefs définissent les buts et laissent la liberté sur les moyens (Art. 10) ; les subordonnés doivent connaître l'intention de leur supérieur (Art. 14). Département fédéral de la Défense, de la Protection de la Population et des Sports.

⁸ Dattrino, M. — Divisionnaire Maurizio Dattrino. A servi comme Brigadier lors de la transmission orale de la notion de delta management à l'auteur, alors capitaine commandant une compagnie d'infanterie.

⁹ Tribunal fédéral suisse — une informatique libre, à l'écart des géants américains. La plus haute juridiction du pays fait fonctionner son informatique sur Linux et logiciels libres (dont LibreOffice) depuis plus de vingt ans, par souci d'indépendance, de pérennité de l'information et de protection des données — quand l'administration fédérale a, elle, déployé Microsoft 365 sur quelque 54 000 postes. Source : Le Temps, « Au Tribunal fédéral, l'informatique se passe des géants américains ».

¹⁰ Federal Trade Commission — sanction de Microsoft (Xbox), 2023. Le régulateur fédéral américain a sanctionné Microsoft (ordonnance entrée en force, amende de 20 millions de dollars) pour avoir illégalement collecté et conservé les données personnelles d'enfants sur le service Xbox, sans consentement parental préalable, en violation de la loi COPPA.

Note d'auteur

Ce texte décrit un modèle dans lequel l'humain est architecte et décideur. Il définit la direction, pose les questions, tranche les tensions, valide chaque étape. Les outils exécutent ce qu'il décide.

J'ai construit ce document selon ce principe. L'architecture KERNEL-CORPUS-SPOKE décrite dans ces pages n'est pas un concept exposé depuis l'extérieur : c'est le système dans lequel ce texte a été produit, session après session, avec les routines d'ouverture et de clôture décrites plus haut. Les choix conceptuels, les arbitrages, les angles retenus et ceux écartés sont les miens.

L'outil de production et de révision qui a travaillé à mes côtés est une intelligence artificielle. Je le dis parce que le taire serait en contradiction avec ce que cet essai défend. Le style est imposé par l'auteur ; les révisions ont été nombreuses, exigeantes, toujours supervisées — une collaboration sous contrainte humaine, pas une délégation.

Ce texte est vivant — et il doit le rester. Le domaine évolue vite : les pratiques décrites ici seront affinées, certaines remplacées, d'autres confirmées par l'expérience.

Grégory Liand