La mémoire situative

PARTIE I — INTRODUCTION

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.

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 — historiquement construites pour les grandes organisations. La maturité d'un écosystème open source les rend désormais accessibles à une équipe réduite et à un VPS modeste, à condition de rester sobre sur l'architecture d'ensemble.

Markdown structuré et RAG 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 RAG souverain prend le relais : moteur d'embedding local, stockage vectoriel, accès par API. 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 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. La souveraineté rend l'organisation plus libre, pas moins intégrée.

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 VPS souverain modeste en Suisse hébergeant un RAG ouvert (AnythingLLM, Ollama, LanceDB) interrogé via API. Aucune dépendance propriétaire à un éditeur d'IA. Git et Markdown existeront encore dans vingt ans ; les briques RAG sont remplaçables — les sources restent en Markdown structuré, le moteur d'inférence et de recherche peut évoluer.

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 (RAG souverain, interrogé via API) ─────────────┐
│ Workspaces (unité d'organisation) :                                │
│   CONTEXTE_APCOM   organisation, règles, équipe (KERNEL ingéré)    │
│   CLIENT           fiches, échanges, vision stratégique            │
│   PROJETS          cahiers des charges, contrats, suivi chantier   │
│   PV               procès-verbaux, audio, vidéo                    │
│   TODO  ·  TIME  ·  DOC  ·  GIT  ·  MAIL  ·  FINANCE               │
│                                                                    │
│ Embedding : Ollama (nomic-embed-text / mxbai-embed-large)          │
│ Vectorstore : LanceDB     Moteur : AnythingLLM                     │
└────────────────────────────────────────────────────────────────────┘
                    ↕  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/          snapshot du volume vectoriel (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. Base documentaire vectorisée hébergée sur un VPS souverain suisse, organisée en workspaces thématiques (clients, projets, procès-verbaux, correspondance, documents, comptabilité…). Les sources sont en Markdown structuré ; elles sont ingérées dans le moteur RAG (AnythingLLM + Ollama + LanceDB), interrogeable en langage naturel par API. Le CORPUS est consulté à la demande : l'IA identifie les workspaces et passages pertinents, récupère les chunks utiles — jamais le tout en bloc. Une discipline archive → extraction gouverne le CORPUS : tout document ingéré 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 snapshot du volume vectoriel 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 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 ingéré dans le CORPUS (workspace thématique du RAG), une extraction vivante est produite dans le KERNEL. L'extraction est lisible et concise — fiche, résumé, pointeur ; le CORPUS est la source dense, interrogeable en langage naturel à la demande. 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 de travail obéit à la même discipline : elle n'écrit jamais directement sur la branche principale d'un dépôt. À son ouverture, la session crée sa branche de travail dédiée. À sa clôture, la 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.

Typologie des sessions

Cycle d'une session

La consolidation — acte de gouvernance

La consolidation d'une branche vers la branche principale d'un dépôt n'est jamais automatique. Elle est ordonnée explicitement par la gouvernance (pour le KERNEL) ou par le propriétaire du SPOKE (pour un SPOKE). Elle prend la forme d'une fusion Git (merge --no-ff) qui crée un commit de fusion dans l'historique — une trace visible de qui a consolidé quoi, quand. Pas d'écrasement silencieux, pas de réécriture d'historique : chaque évolution de la branche principale est un acte délibéré.

Dans le cas particulier SPOKE → KERNEL, la gouvernance lit le SPOKE enrichi, propose les mises à jour fichier par fichier dans le KERNEL, valide l'intégration, puis archive ou ferme le SPOKE selon la nature de la mission.

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.

PARTIE III — LA CONDUITE

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.

PARTIE IV — MISE EN ŒUVRE : APCOM SOLUTIONS SA

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 RAG

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 :

• Chaque carte Deck représente une demande contractuelle (un ticket).
• Chaque commit Git porte la (les) référence(s) Deck dans son message — préfixe [DECK-{id}]. Un commit peut référencer plusieurs cartes si un changement transverse résout plusieurs tickets.
• Chaque saisie timesheet mentionne le hash complet du commit auquel elle correspond.

Le commit est ainsi le pivot qui relie l'effort enregistré (timesheet) à la demande contractuelle (carte Deck). Le journal de projet vivant est la simple consolidation de ces trois sources — Deck, commits, timesheet — sans rédaction supplémentaire.

Le rôle du CORPUS RAG 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 RAG souverain — archivage long terme dans le workspace 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 interrogeable pour toujours.

Trois bénéfices opérationnels justifient l'archivage RAG systématique des cahiers de besoin :

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, l'équipe peut interroger le RAG en langage naturel : « a-t-on déjà traité une demande similaire ? », « quel chiffrage avons-nous fait pour une fonction de ce type ? ». L'IA retourne les passages pertinents de tous les cahiers archivés. 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 RAG 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 à l'archivage est marginal — un push de fichier .md. 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 conduite du développement a désormais une ligne unique de référence, fixée par la gouvernance : ce que les règles permanentes font pour l'écriture des dépôts, ce chapitre le fait pour le flux Git. Jusqu'ici, chaque équipier conduisait son dépôt au mieux dans le cadre général ; les pratiques ont divergé d'un logiciel à l'autre. La gouvernance arrête ici le modèle cible : l'opposabilité vaut dès maintenant, la résorption des écarts se fait projet par projet, lors d'un audit dédié.

Le socle est posé en doctrine ; sa généralisation est en cours. La séparation entre dépôt souverain et dépôt public est une règle ancienne — la Règle 24 interdit à l'IA tout accès en écriture aux dépôts de production hors infrastructure souveraine — et le travail en branche systématique, décrit plus bas, gouverne déjà toute écriture. Ce chapitre ne réinvente pas ce socle : il l'étend au code de production et en fixe le flux d'ensemble.

Les deux faces du code. Le dépôt de développement souverain — chez APCOM, Forgejo auto-hébergé — a vocation à être l'atelier : dans le modèle cible, il détient toute la vérité, branches de travail, commits intermédiaires, allers-retours, historique granulaire, développement et production. Le dépôt public — GitHub — est la vitrine : il 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 branches de chantier. Les deux historiques divergent volontairement. La vitrine n'a qu'une utilité externe — offrir un historique de release lisible et rejoindre les habitudes des clients et partenaires, qui consultent GitHub ; l'historique de développement complet, lui, ne quitte pas l'atelier.

Le modèle, en une ligne. commit → feature → develop → main + tag : grain, chantier, intégration, livraison, jalon figé. Quatre lignes de travail coexistent dans l'atelier :

• la branche de chantier (feat/<sujet>) — un sujet, une branche, ouverte depuis le tronc d'intégration ; supprimée après intégration, ses commits restant acquis ;
• le tronc d'intégration (develop) — où converge le travail de toutes les branches de chantier : l'état consolidé, mais pas encore livré. C'est une branche d'intégration, à ne pas confondre avec un simple environnement de démonstration ;
• la branche de production (main) — n'avance que par livraison (intégration du tronc) ou par correctif, et porte à chaque arrivée un jalon de version (tag SemVer) immuable ;
• la branche de correctif urgent (hotfix) — ouverte depuis le jalon de prod concerné, jamais depuis le tronc d'intégration, pour ne corriger que ce qui est réellement livré ; le correctif est ensuite propagé, obligatoirement, dans le tronc d'intégration (anti-régression).

Les neuf bascules numérotées sur le schéma — la légende, par cas.

Features et versions

Hotfix

Rollback (théorique)

Deux règles d'or prolongent directement les disciplines déjà posées pour la mémoire — la consolidation comme acte de gouvernance, et la consolidation en lot (local d'abord, distant ensuite, sur décision explicite) :

• 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 de version poussé est immuable, comme un historique partagé ne se réécrit pas ; une version mauvaise appelle un correctif incrémenté, pas une réécriture.

Le garde-fou qualité — le test live. Dans le modèle cible, chaque branche poussée est déployée sur un environnement de test dédié (test live), pour qu'une fonction soit vue fonctionner avant d'être intégrée ; aujourd'hui ce test se fait par environnement (démo, test) attaché à une branche, le déploiement par branche de chantier restant à généraliser. Le verrou cible — non encore acquis — lie ce test à la protection des branches : tant que le test est au rouge, l'intégration vers le tronc ou la production reste impossible.

Le travail en branche systématique décrit plus bas vaut tel quel pour le code : deux sessions parallèles tiennent chacune leur branche de chantier et convergent vers le tronc d'intégration.

Cette ligne fixe le modèle, pas l'état de chaque projet : le tronc d'intégration, les jalons de version, le correctif depuis le tag, la propagation et le retour arrière sont la part prescriptive, en cours de généralisation — comme l'est le rattachement effectif de chaque logiciel à l'atelier souverain, certains lisant encore un miroir du dépôt public. Les commandes Git exactes de chaque bascule et l'état réel par logiciel sont tenus dans GLOBAL/STRUCTURE/GIT.md du KERNEL, qui renvoie lui-même aux DEV_WORKFLOW.md de chaque logiciel.

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 : aucune vérification a priori ne garantit 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, indépendamment du nombre de sessions actives.

Quand plusieurs sessions travaillent réellement en même temps — plusieurs agents IA conduits en parallèle — chacune opère dans un worktree Git distinct : un répertoire de travail séparé, rattaché au même dépôt, sur sa propre branche. La branche par session isole les écritures ; le worktree isole les espaces de travail. Ensemble, ils rendent le travail parallèle sûr par construction.

Cette discipline a aussi un effet secondaire bénéfique : chaque bloc de travail devient un jalon isolé et révocable, chaque évolution de la branche principale un acte de gouvernance explicite tracé dans l'historique Git.

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 ; archivez les contenus denses dans un RAG souverain hébergé sur un VPS. Plusieurs stacks open source le permettent aujourd'hui (AnythingLLM, Ollama, LanceDB ou équivalents) — sources en Markdown structuré, ingestion par workspace thématique, interrogation par API. L'IA consulte ce CORPUS à la demande, par recherche sémantique ciblée — jamais en bloc.

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 et perspectives

Par honnêteté envers le lecteur, il faut nommer ce que ce système ne résout pas — et ce qui reste à améliorer.

La mémoire probabiliste du modèle

Même avec un KERNEL structuré, l'IA peut oublier des fondamentaux en cours de session. Ce phénomène est documenté : 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 effective exploitable est sensiblement inférieure à la longueur théorique.

Cette limite n'est pas spécifique à un modèle : elle touche Claude comme GPT comme Gemini. Elle est structurelle au paradigme LLM actuel. Le KERNEL ne la fait pas disparaître — il la compense par la discipline de structure et par la relecture ciblée en début de session. C'est précisément 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 à partir d'une mémoire dégradée.

La charge des routines

Les routines d'ouverture et de clôture prennent du temps — quelques minutes à l'ouverture, un peu plus à la clôture. Sur une journée de plusieurs sessions courtes, le cumul peut peser. Ce coût est le prix de la continuité, mais il mérite d'être optimisé : automatisation partielle, génération automatique de certaines cartes, rappels proactifs par l'IA quand un rituel est oublié.

L'épuration continue

Un KERNEL vivant accumule les règles, les entrées, les notes. Sans épuration régulière, il devient dense, répétitif, moins lisible — exactement l'inverse de ce qui fait sa valeur. La discipline retenue est l'audit périodique : relire l'ensemble du KERNEL, identifier les redondances, condenser les règles, déplacer les fichiers trop volumineux vers le CORPUS. L'opération est exigeante mais elle paie sur la durée — un KERNEL propre est un KERNEL utile.

Les limites intrinsèques du Markdown

Le Markdown n'a ni schéma, ni validation, ni exécution native. Un fichier mal structuré ne sera pas détecté automatiquement. C'est le prix de la simplicité radicale : tout lecteur humain ou IA peut ouvrir n'importe quel fichier, mais rien ne garantit qu'il soit conforme à la convention interne. Le garde-fou est humain — la discipline d'écriture — outillé par la structure documentée (règles permanentes, carte vivante, routines).

Le registre des évolutions

Un système en production identifie en permanence ce qui pourrait être amélioré — une fonction manquante d'une API, une automatisation à mettre en place, une convention à durcir. Pour qu'aucune de ces idées ne se perde ni n'encombre, elles sont consignées dans un registre des évolutions : chaque évolution reçoit un identifiant stable (EVO-NNN) ; le registre en tient l'index ; la fiche détaillée vit dans le fichier qui porte naturellement l'évolution.

Parmi les chantiers ainsi suivis, un se détache : l'inférence souveraine. Aujourd'hui, le RAG du CORPUS est interrogé via un LLM commercial. La mémoire — données et contextes — est déjà sous contrôle ; il restera à passer le moteur d'inférence sous la même règle, avec un modèle open source auto-hébergé. La trajectoire est tracée ; elle n'est pas bloquante. Aucune de ces évolutions ne l'est : le système fonctionne tel quel — elles relèvent du perfectionnement, pas de la correction.

Avant de vous lancer

Ce texte décrit un système qui fonctionne. Il ne décrit pas un système sans tensions. Les nommer honnêtement est plus utile que de les taire.

La responsabilité inversée reste à construire. Ce principe — l'IA maintient la mémoire, l'humain valide — est posé comme fondamental. En pratique, il suppose une gouvernance capable de savoir ce qu'elle valide et pourquoi. Un KERNEL mal gouverné ne se maintient pas seul.

La souveraineté est réelle sur les données. Elle est partielle sur le comportement. La constitution du KERNEL est optimisée pour le modèle avec lequel elle a été construite. Changer de fournisseur d'IA ne sera pas indolore — certaines conventions devront être réécrites. Ce n'est pas un verrouillage propriétaire, mais c'est un coût de migration réel que ce texte ne doit pas minimiser. Tester la portabilité sur deux modèles différents avant de vous engager est une précaution raisonnable.

Le coût d'entrée est réel. Écrire une constitution exige de savoir qui vous êtes et quelles règles vous voulez opposables. Intégrer les routines demande une discipline que la plupart des organisations n'ont pas encore installée. Le système suppose une équipe à l'aise avec Git et la documentation structurée. Évaluez honnêtement, avant de commencer, si vous avez les personnes capables de porter cette discipline dans la durée.

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. Ce sont deux choses distinctes — et la confusion entre les deux est la première cause d'échec. Une mémoire organisationnelle qui n'appartient pas à ceux qui la vivent ne tient pas dans la durée : elle se vide de sa substance, ou reste figée faute de gouverneur qui comprend ce qu'il gère.

Le différentiel de souveraineté peut s'éroder. Cet essai repose sur un constat : les éditeurs d'IA ne donnent pas de vraie souveraineté sur votre mémoire. Ce constat est juste aujourd'hui. Il pourrait changer si les grands éditeurs offraient de vraies garanties contractuelles — export intégral, non-entraînement garanti, portabilité réelle. Avant de bâtir une stratégie sur ce différentiel, tranchez une question préalable : la souveraineté des données est-elle un critère stratégique non négociable pour votre organisation ? Si oui, ce système a une valeur indépendante de l'évolution du marché.

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 qui le rend possible n'est pas la technologie — elle est gratuite et interchangeable. C'est la rigueur de structuration et la discipline d'écriture qui font la différence. Et c'est la conduite qui en tire la puissance : 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 décrites ici 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 commence 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.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 ajoute un RAG souverain.

² 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.

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. Avancer imparfaitement, corriger en continu, vaut toujours mieux qu'attendre une certitude qui n'arrivera pas.

Grégory Liand