Référence de développement

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.

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.

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

Atelier & vitrine

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.

Cette barrière n'est pas qu'une commodité : elle est fondée par la Règle 24 du KERNEL — séparation entre l'IA et les dépôts de production hors infrastructure souveraine. Seul l'humain pousse vers le dépôt public, et il nomme toujours ce qu'il livre.

La même logique gouverne la donnée, pas seulement le code. Le CORPUS est l'atelier de fichiers : l'IA commerciale n'y lit que des contenus dont le traitement lui est légalement (droit suisse) et éthiquement admissible. Les données de production et le cloud d'entreprise traditionnel — chez APCOM, un second Nextcloud auto-hébergé — lui restent fermés. Atelier de code, atelier de fichiers : l'IA n'opère que dans les ateliers souverains ; la production et la vitrine publique ne sont jamais son terrain.

Les neuf bascules

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

Features et versions

Hotfix

Rollback (théorique)

Garde-fous

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.

Deux règles d'or prolongent directement les disciplines 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.

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.

Traçabilité — deck · commit · timesheet

Chaque commit s'inscrit dans la routine projet (du besoin client au livrable validé), dont le point névralgique 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.

Routine projet complète et conventions : STACK_TECHNIQUE/ROUTINES/PROJET.md du KERNEL.

Discipline de branche & session

Toute session n'écrit jamais directement sur la branche principale : à l'ouverture elle crée sa branche de travail, à la clôture elle la pousse ou la consolide.

Typologie des sessions

Cycle d'une session

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. La consolidation vers la branche principale n'est jamais automatique : elle prend la forme d'une fusion Git (merge --no-ff) — commit de fusion, trace explicite, pas d'écrasement silencieux.

Routines de session dev

Distinctes des rituels de session KERNEL, les routines de développement — ouverture, permanence, clôture, cycle de vie projet — encadrent le travail des équipiers sur les logiciels, dans les SPOKES. Elles reposent sur la ligne Git unique décrite ci-dessus, de la branche de chantier au jalon de production.

Checklists exactes : STACK_TECHNIQUE/ROUTINES/ du KERNEL (ouverture, permanence, clôture) et les DEV_WORKFLOW.md par logiciel.

Renvois

• Manifeste — la thèse, le modèle, la doctrine de conduite : La mémoire situative.
• KERNEL (privé) — commandes Git exactes de chaque bascule et état réel par logiciel : GLOBAL/STRUCTURE/GIT.md, qui renvoie aux DEV_WORKFLOW.md.
• Règles permanentes citées : Règle 13 (commits par bloc logique), Règle 14 (trois ordres : écrire / commiter / pousser), Règle 24 (séparation IA / dépôts de production).

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.