Le Jardin Secret du Développeur : Comment l'Ontologie Spatiale Aligne les LLMs Sans Prompt Engineering

Publié le 03 May 2026

temps de lecture : 20 minutes

Le prompt engineering, c’est fragile. À 80 000 tokens, vos règles d’alignement sont noyées dans le bruit, et le LLM oublie ce que vous lui avez demandé en début de conversation. Ma solution ? Ne pas aligner par le texte, mais par l'espace. J’ai structuré mon workspace de développement en quatre cercles de confiance concentriques — du jardin secret intime jusqu’aux forges publiques — et chaque cercle est une zone physique du système de fichiers. Le LLM n’a pas besoin qu’on lui rappelle les règles : le chemin du fichier les contient. Voici comment ça fonctionne, et pourquoi cette architecture d’alignement par l’espace est plus résiliente qu’un system prompt de 500 lignes.

C’est un article long.
Installez-vous confortablement.

1. Le Constat : le Prompt Engineering est un Château de Sable

Pendant trois semaines, j’ai développé des plugins Gradle avec Opencode, en utilisant trois LLMs différents — Kimi K2.6, GLM-5.1, et DeepSeek-V4-Pro (le seul survivant, mais c’est une autre histoireDéjà couverte ici.). Ma méthode de gouvernance agentJe l’ai documentée en détail dans un précédent article. repose sur des fichiers AsciiDoc — AGENT.adoc, INDEX.adoc, PROMPT_REPRISE.adoc — qui chargent ~30 000 tokens de règles, de backlog et d’historique à chaque début de session.

Et malgré cette infrastructure documentaire, deux choses m’ont frappé :

  1. Le LLM oublie. Même avec les règles absolues en tête de chaque fichier EAGER, au-delà de 60 000 tokens cumulés (contexte initial + conversation), Kimi K2.6 a commencé à proposer des Write écrasants sur des fichiers de configuration. GLM-5.1 a confondu un token Firebase avec un placeholder à remplacer. Les règles étaient écrites — le LLM ne les voyait plus.

  2. La gouvernance elle-même devient un problème. Après avoir implémenté le mécanisme Hot/Warm/ColdArticle sur la rotation de backup. pour éviter l’explosion du contexte, mes fichiers EAGER pesaient encore 1414 lignesJ’ai documenté cet audit ici.. La gouvernance — conçue pour protéger le LLM de la saturation — saturait le LLM.

J’avais besoin d’un mécanisme d’alignement qui ne dépende pas du nombre de tokens dans le prompt.

La réponse : arrêter d’aligner par le texte, et commencer à aligner par l'espace.

2. Les Quatre Cercles de Confiance : une Ontologie Spatiale

Mon dossier workspace/ (dans ~/workspace/) n’est pas un dépôt Git. C’est la racine de tout mon travail — code, documentation, formation, infrastructure. Et il est structuré en quatre zones qui ne sont pas des conventions de rangement, mais des cercles de confiance concentriques :

Niveau

Label

Zone physique

CVS

Visibilité

0

Jardin secret

workspace/ racine

Aucun

Intime — pensée libre, pas de commit, pas de publication

1

Coffre-fort

configuration/

Git privé (solo)

Secrets, tokens, archive de vision. Une seule personne.

2

Bibliothèque

office/

Git privé (élargi)

Data pédagogique, SPG/SPD, schémas JSON. Cercle de confiance identifié.

4

Forges (publiques)

repositories/

Git public (Apache 2.0)

Code source, plugins, tests, documentation technique.
Il n’y a pas de niveau 3 dans le tableau. Le niveau 3 est un niveau transitoire : c’est du contenu de office/ qui a été anonymisé et est prêt à être publié en open data. Il n’a pas de zone physique propre — c’est un état de la donnée, pas un emplacement.

Chaque niveau répond à une question précise :

  • Où déposer une idée qui n’est pas encore prête à être partagée, même avec un cercle restreint ? → Le jardin secret. Pas de Git. Pas de pression.

  • Où stocker un token API sans qu’il fuie ? → Le coffre-fort (configuration/). Physiquement isolé. Aucun autre dépôt ne peut le référencer par erreur.

  • Où co-construire un catalogue de formation avec un OF pilote ? → La bibliothèque (office/). Versionné, collaboratif, mais privé.

  • Où industrialiser un plugin Gradle open source ? → Les forges (repositories/). Public, forkable, testé en CI.

Cette ontologie est consommable par un LLM. Quand il lit un fichier dans repositories/plantuml-gradle/src/, il sait implicitement : "je suis dans le cercle 4 — code public, tests obligatoires, pas de secrets, pas de données pédagogiques". Il n’a pas besoin d’un prompt qui le lui rappelle.

2.1. Le Jardin Secret : l’Espace Hors-CVS

C’est le concept le plus important — et le plus contre-intuitif.

La racine workspace/ n’a pas de .git/. Les documents qui y vivent (WORKSPACE_VISION.adoc, WORKSPACE_AS_PRODUCT.adoc, WORKSPACE_ORGANIZATION.adoc — et celui que vous lisez en ce moment, qui en est issu) ne sont pas destinés à être versionnés, partagés, ou même relus par quelqu’un d’autre que moi. Ce sont des pensées en germination.

Le jardin secret est out-of-CVS par nature. L’absence de versionnage est la condition de la liberté de penser. On n’y écrit pas pour être lu — on y écrit pour clarifier sa propre vision.

Mais cette liberté a un coût : un rm accidentel, et c’est des mois de réflexion stratégique qui disparaissent. La solution n’est pas de versionner le jardin (ce serait le détruire) — c’est de le mirrorer dans le cercle le plus restreint.

J’ai créé configuration/vision-archive/ : des snapshots datés de tous les .adoc de la racine, commités dans le dépôt privé configuration/. Chaque session de brainstorming produit un snapshot :

DATE=$(date +%Y-%m-%d)
mkdir -p configuration/vision-archive/$DATE
cp workspace/*.adoc configuration/vision-archive/$DATE/
cd configuration && git add vision-archive/ && \
  git commit -m "vision-archive: snapshot $DATE"

L’historique Git de configuration/ devient la biographie de ma pensée stratégique. Je peux faire un git log — vision-archive/ et voir l’évolution de ma vision, session par session, date par date.

Et pour le LLM, c’est un oracle de cohérence : quand il observe une contradiction entre l’implémentation actuelle et la vision archivée à une date antérieure, il peut la signaler.

2.2. Le Coffre-Fort : configuration/ comme Spring Cloud Config

configuration/ ne contient pas que l’archive de la vision. Sa fonction première — et future — est d’être un serveur Spring Cloud Config. Tous les secrets, tokens, credentials, et descripteurs d’infrastructure vivent ici, dans un dépôt Git privé accessible au seul propriétaire.

Pourquoi un dépôt séparé plutôt qu’un fichier .env dans chaque projet ?

  • Push accidentel d’un secret : impossible. Les secrets sont dans un dépôt privé que les projets publics ne peuvent pas référencer par erreur.

  • Audit : l’historique Git donne la piste de chaque modification de configuration. Qui a changé quoi, quand, avec quel hash SHA.

  • Rollback : git revert sur une configuration cassée. Instantané, sans backup manuel.

2.3. La Bibliothèque : office/ comme Data Consommable

office/ est le pendant documentaire du travail de développement. Il contient les articles de blog, les spécifications techniques, les supports de formation (38 répertoires de cours FPA, SPG/SPD, schémas JSON, taxonomies Bloom/Harrow/Krathwohl) — tout ce qui constitue le matériau pédagogique.

Mais office/ n’est pas qu’un tiroir à docs. C’est une source de données structurée que les plugins Gradle de repositories/ consomment. Un article de blog dans office/ est une entrée qu’un plugin transformera en HTML. Un SPG AsciiDoc dans office/metiers/FPA/ est un artefact qu’un orchestrateur parsera pour générer des slides, des quiz, et des capsules vidéo.

Et le build.gradle.kts à la racine de office/ n’est pas du code métier — c’est un script de consommation de l’écosystème de plugins. Il dit : "voici les plugins Gradle que j’utilise, voici le contexte de mon workspace".

2.4. Les Forges : repositories/ comme Implémentation

repositories/ contient le code industrialisé. 54 dépôts Git, dont 7 actuellement gouvernés par des .agents/. C’est ici que la vision devient exécutable — plugins Gradle, CI/CD, tests JUnit5 + Cucumber.

La relation avec office/ est bidirectionnelle :

  • office/ → repositories/ : les données pédagogiques sont la matière première que les plugins consomment.

  • repositories/ → office/ : les plugins produisent de la data qui enrichit office/ — le graph.json de graphify-gradle, les decks slider compilés, les rapports de build.

3. Pro/Contra : Alignement Spatial vs Alignement par Prompt

Comparons les deux approches.

3.1. Approche Classique : Alignement par Pré-Prompt

✅ Pro

❌ Contra

Simple à mettre en œuvre. Un bloc de texte dans le system prompt.

Fragile au contexte long : la règle est noyée après 80K tokens.

Fonctionne pour des règles générales (ton, format).

Non vérifiable : rien n’empêche le LLM de violer la règle.

Pas besoin de repenser l’architecture du projet.

Non transférable : chaque repo redéclare les règles.

Purement déclaratif : le LLM sait qu’il devrait, mais rien ne l’empêche.

3.2. Cette Approche : Alignement par Ontologie Spatiale

✅ Pro

❌ Contra

Résilient au contexte long : la règle est dans le chemin du fichier, pas dans un prompt lointain.

Coût d’infrastructure initial : structurer le workspace en cercles prend du temps.

Vérifiable mécaniquement : un secret dans repositories/ est détectable par git check-ignore.

Nécessite discipline : un nouveau contributeur doit comprendre les cercles.

Transférable : un AGENT.adoc standard expose les cercles à tout nouveau projet.

Ne couvre que les contraintes spatiales — le code style reste dans le prompt.

Sécurité par conception : un git push depuis repositories/ ne peut pas exposer configuration/.

Consommable par des agents non-LLM : un orchestrateur Gradle peut router selon le cercle.

Le gain principal n’est pas défensif (sécurité, visibilité) — il est créatif. Quand le LLM travaille dans un espace structuré par une ontologie, il peut faire ce qu’aucun prompt ne lui permet : observer le delta.

4. L’Algèbre Relationnelle du Workspace et le Delta Observable

Quand le LLM parcourt repositories/, il dispose d’un treillis de données structurées : nœuds (plugins, fichiers, tests, dépendances), arêtes typées (import, depends_on, generates, tests), relations de composition et d’ordre (training-gradle extrait le référentiel → slider-gradle génère les slides → capsule-gradle monte la vidéo).

Cette algèbre n’est écrite nulle part en clair — mais elle est observable. Chaque build.gradle.kts expose des dépendances. Chaque INDEX.adoc expose des références croisées.

Le LLM observe cette algèbre et détecte le delta : l’écart entre ce que le système sait déjà produire et ce que la vision décrit.

À partir de ce delta, il peut définir des cartographies d’experts métiers — CDA (Concepteur Développeur d’Applications, Kotlin/Gradle/JHipster) et FPA (Formateur Professionnel d’Adultes, Pédagogie/Qualiopi/Bloom) — et identifier ce qui manque pour chaque expert.

Expert CDA (Kotlin/Gradle/JHipster)
  ├── Plugins : jhipster-gradle-plugins, plantuml-gradle,
  │   codebase-gradle
  ├── Delta : pas encore de SPG CDA formalisé,
  │   pas de fine-tuning expert CDA

Expert FPA (Pédagogie/Qualiopi/Bloom)
  ├── Plugins : training-gradle, slider-gradle,
  │   school-backoffice/forms, capsule-gradle
  ├── Matériel : 38 modules cours, SPG/SPD, taxonomies
  └── Delta : parser AsciiDoc→JSON à créer,
      orchestrateur à coder

Le LLM n’a pas besoin qu’on lui dise quoi faire. Le delta émerge de la structure.

5. Le Vecteur Composite de Contexte : RAG + pgvector + Graphify

L’algèbre relationnelle n’est pas une construction théorique. Elle est matérialisée par trois composantes qui forment un vecteur composite de contexte pour le LLM.

5.1. Composante 1 — RAG LangChain4j + PostgreSQL pgvector

J’ai déjà LangChain4j en production dans deux plugins : slider-gradle (4 providers LLM) et plantuml-gradle (7 providers). Les embeddings ONNX (AllMiniLmL6V2) indexent les données de office/ et le code source de repositories/ dans PostgreSQL + pgvector.

Ce RAG opère sur deux dimensions : * Dimension data : les documents office/ (SPG, articles, formations, schémas JSON) * Dimension code : les codebases repositories/ (sources Kotlin, tests Cucumber, AGENT.adoc)

L’intersection couvre à la fois le quoi (le domaine métier) et le comment (l’implémentation).

5.2. Composante 2 — Knowledge Graph Graphify

Graphify est intégré dans plantuml-gradle (109 tests, 380/380 PASS) et produit un graph.json — un knowledge graph structuré avec nœuds, arêtes, et communautés détectées automatiquement.

Contrairement au RAG qui opère par similarité vectorielle (flou), le knowledge graph opère par relations exactes (déterministe) : graphify query pour les interrogations sémantiques (~50 tokens), graphify path pour naviguer, graphify explain pour expliquer.

5.3. Composante 3 — Graphify Incrémental : Épars, Agrégeable, Consommable

C’est la décision architecturale clé.

Graphify ne doit pas vivre dans un dépôt unique. Il doit vivre de manière éparse dans chaque plugin :

  1. Chaque plugin embarque une tâche Gradle updateKnowledgeGraph qui appelle Graphify sur son propre scope et produit un graph.json local.

  2. Le build script de office/ consomme graphify-gradle avec rootDir = /home/cheroliv/workspace et produit un graph.json global qui agrège les graphes locaux.

  3. Le RAG de chaque plugin injecte le graph.json global comme filtre de contexte pour les requêtes LLM.

TÂCHE GRADLE (dans chaque plugin)
    ↓
graphify → graph.json (scope local)
    ↓
office/build.gradle.kts → graph.json (scope global)
    ↓
RAG pgvector (dans slider, plantuml, codebase...)
    ↓  ← injection du graph.json comme filtre
LLM (deepseek-v4-pro)
    ↓  ← observation algèbre relationnelle
    ↓  ← détection delta vs cartographies experts
PRIORISATION → prochaine tâche

Résultat : le LLM ne cherche pas dans le vide — il navigue dans un espace structuré par le knowledge graph. Une requête sur "génère un diagramme" sait atteindre les nœuds pertinents du graphe.

6. Classification RGPD Automatique : le LLM comme Routeur

L’ontologie spatiale ne se contente pas d’aligner le LLM — elle lui donne une grille de classification RGPD pour router chaque donnée vers sa zone légitime.

Critère

Détection LLM

Action

Niveau max

Donnée personnelle (nom, email, IP)

Pattern @, IP, noms propres

Anonymiser → [OF_PILOTE] ou router niveau 2

2

Token / Secret / Credential

Pattern sk-…​, ghp_…​, ya29…​

Router → configuration/. Référencer par ${VAR} dans le code.

1

URL interne

Contient localhost, IP privée

Anonymiser → ${API_URL}

2

Donnée pédagogique (SPG, cours)

Structure Bloom/Qualiopi

Router → office/ (niveau 2). Double version si export.

3

Code source / test

Extension .kt, .kts dans repositories/

Router → repositories/. Vérifier absence de secrets.

4

En fin de session, le LLM exécute une tâche globale :

  1. Inventaire de tous les fichiers modifiés (tous cercles confondus)

  2. Classification automatique de chaque fichier

  3. Routage : snapshot jardin secret → configuration/vision-archive/, données office/ → commit privé, code repositories/ → ./gradlew check, configuration → commit

  4. Rapport structuré avec alertes RGPD

Le LLM n’est plus un simple générateur de texte. Il est le gestionnaire d’information de l’écosystème — producteur, classifieur, routeur.

7. Roadmap : de l’AsciiDoc à LangGraph4j

Aujourd’hui, cette gouvernance est déterministe : le LLM applique une procédure décrite dans des fichiers AsciiDoc. C’est la phase 1 — le prompt engineering avec mémoire LLM.

La phase 2 extraira chaque étape de la procédure dans une tâche Gradle typée :

./gradlew endSessionWorkspace    → snapshot vision-archive
./gradlew endSessionProject      → archive .agents/
./gradlew endSessionReport       → rapport multi-zones

La phase 3 modélisera le processus de fin de session comme un graphe d’état avec LangGraph4j :

[Start] → [Inventaire fichiers modifiés]
       → [Classification RGPD] (nœud ONNX)
       → [Branchement par cercle]
            ├→ cercle 0 → snapshot → commit
            ├→ cercle 2 → anonymisation → commit
            ├→ cercle 4 → archive → commit
            └→ cercle 1 → commit configuration/
       → [Rapport] → [End]

Ce graphe sera versionné dans la CI/CD, exécuté par Gradle, configuré via les GitHub Secrets des plugins. Le LLM n’aura plus à décider du routage — le graphe le fera.

8. Ce que Cette Architecture Résout (et ce qu’elle ne Résout pas)

L’ontologie spatiale ne couvre pas tout. Les conventions de code style, le nommage, les choix de design architectural — tout ça reste dans le prompt. Ce que l’ontologie spatiale résout, c’est la couche de sécurité et de visibilité : où chaque octet doit vivre, et qui peut le voir.

Voici ce qu’elle apporte concrètement :

  1. Pas de git push accidentel d’un secret : les secrets sont dans configuration/ (cercle 1). Les projets publics sont dans repositories/ (cercle 4). Aucun chemin ne traverse les deux.

  2. Pas de code métier dans la data : office/ contient des .adoc, des YAML, des JSON Schemas — mais pas de .kt. Le build.gradle.kts qui y vit est un script de consommation, pas du code métier.

  3. Pas de pensée stratégique exposée : les documents de vision vivent dans le jardin secret (racine hors-CVS). Les snapshots sont dans configuration/ (coffre-fort privé). Personne, même en cercle de confiance élargi, ne lit la genèse de la stratégie.

  4. Auto-priorisation : le LLM observe le delta entre l’algèbre relationnelle (ce qui existe) et les cartographies d’experts (ce qui est nécessaire). La prochaine tâche de développement émerge de ce delta.

9. Conclusion : l’Architecture comme Discours

Je ne mets pas de manifeste politique dans le footer de mon site. Je ne mets pas de règles éthiques dans mes prompts. L’alignement n’est pas dans le texte — il est dans le système de fichiers.

Quand un LLM travaille dans cet espace, il ne peut pas fuiter un secret (le chemin l’en empêche). Il ne peut pas confondre une donnée pédagogique avec du code source (la zone physique est différente). Il ne peut pas oublier une règle de sécurité à 80 000 tokens — parce que la règle n’est pas dans le prompt, elle est dans le workspace/ → configuration/ → office/ → repositories/ que chaque lecture de fichier réactive.

C’est le principe de la secure by design appliqué à l’alignement agent : ne pas demander au LLM de se souvenir des règles. Faire en sorte que l’architecture rende l’erreur structurellement impossible.

Et au passage, ça donne au LLM ce qu’aucun prompt ne peut lui donner : la capacité de percevoir où il est, ce qui existe, ce qui manque — et d’en déduire ce qu’il doit faire.

10. Références