L'explosion contextuelle

Début 2025 : Retour à l’IA

Début 2025 : génération automatique de contexte (pattern “visitor”)

En 2025, je reprends les expérimentations IA à fond. Depuis début 2025, ces sujets sont devenus le centre de gravité de mon travail d’auto‑formation et de R&D personnelle.

Mon problème central : comment faire comprendre mon projet à l’IA ? Si je lui donne tout le code d’un coup, c’est trop : elle se perd. Si je ne lui donne que des bouts, elle manque de vision d’ensemble.

Je pars donc sur une idée simple : découper le projet en morceaux organisés, comme un livre avec chapitres et sous‑chapitres. Chaque dossier aurait son résumé, et l’ensemble formerait une vue globale. L’IA pourrait naviguer du général (vue d’ensemble) au particulier (détail d’un fichier).

Mon idée : générer automatiquement des fichiers de contexte en parcourant l’arborescence du projet. Inspiré d’un cours de compilation (pattern visitor), je conçois un script qui scanne la codebase en profondeur.

Projet/
├── src/
│   ├── utils/
│   │   ├── helper.js       → scan + résumé par LLaMA
│   │   ├── config.js       → scan + résumé par LLaMA
│   │   └── .context        ← "utils/ contient des helpers et config"
│   │
│   ├── components/
│   │   ├── Button.jsx      → scan + résumé par LLaMA
│   │   ├── Form.jsx        → scan + résumé par LLaMA
│   │   └── .context        ← "components/ contient UI React"
│   │
│   └── .context            ← agrégation: utils/ + components/
│
└── .context                ← vue globale: "projet React avec utils et UI"

Flux: fichiers → LLaMA → résumés .context → agrégation bottom-up

Le principe :

• Chaque fichier est analysé par LLaMA (modèle local sur ma machine)
• Un résumé de 2-3 phrases est généré et stocké dans un fichier .context
• Les résumés remontent l’arbre : le .context d’un dossier agrège les .context de ses sous-dossiers

Sur le papier, c’est génial : on obtient une vision multi-échelle du projet (du global au détail).

En pratique, ça coince vite. Ma machine traite les fichiers séquentiellement 1 Séquentiellement : un par un, dans l’ordre. Contrairement au traitement parallèle où plusieurs fichiers seraient analysés en même temps. avec LLaMA. Petit projet : ~15 minutes. Gros projet : la complexité devient exponentielle 2 Complexité exponentielle : le temps de traitement explose de façon non-linéaire. Si 100 fichiers prennent 15 minutes, 200 fichiers ne prendront pas 30 minutes mais bien plus (genre plusieurs heures). C’est le problème classique des algorithmes en O(n²) ou pire. , donc inutilisable en conditions réelles. L’approche est intéressante, mais non scalable 3 Scalable : capable de passer à l’échelle, de gérer des volumes croissants sans s’effondrer. sur ma machine. J’ai fini par mettre ce projet en pause.

En fait, je visais plus loin. Je ne voulais pas juste un fichier de contexte brut, mais un DSL 4 DSL (Domain Specific Language) : un mini-langage sur mesure pour décrire quelque chose de précis. Par exemple, au lieu d’écrire “ce fichier gère l’authentification”, j’aurais pu définir des mots-clés comme @auth, @route, @db pour structurer les descriptions de façon standardisée. dédié à la description du projet, puis enchaîner plusieurs passes d’analyse. Première passe “grossière” pour balayer le code et obtenir une vue d’ensemble ; deuxième passe plus fine pour réinjecter ce premier résultat et raffiner le contexte. À terme, j’imaginais même des scans itératifs de plus en plus spécialisés, avec plusieurs modèles d’IA selon leurs points forts (résumé, structure, sémantique, etc.). En théorie, c’était solide : un contexte évolutif, enrichi et corrigé à chaque passe. En pratique, comme le premier scan était déjà long, l’approche multi‑passe devenait intenable matériellement sur ma machine. Je ne l’ai jamais menée jusqu’au bout, mais ce travail m’a fait toucher du doigt ce qu’une IA pourrait faire plus tard en se recontextualisant par itérations successives.

Le retour d’expérience reste précieux : j’ai clarifié pour moi l’importance du découpage hiérarchique et de l’agrégation sélective du contexte.

Début 2025 : Cursor, Sonnet 3.7 (pendant l’effort)

Je continue à utiliser Cursor intensivement. Parallèlement, Sonnet 3.7 (Anthropic) me bluffe sur certains aspects du code : je bascule progressivement vers Anthropic pour de la génération plus fiable. Très vite, je me rends compte qu’un modèle plus performant change l’expérience, mais ne règle pas tous les problèmes : la robustesse dépend toujours des règles et du contexte que je fournis.

Je commence alors à multiplier les fichiers .cursorrules et les répertoires .cursor/rules dans l’arborescence, pour harmoniser les conventions et mieux centraliser le contexte.

En parallèle, je lance un projet perso (au départ un simple site web) qui devient vite une application complète. Ce chantier devient un vrai terrain d’expérimentation : il m’oblige à tester les règles de contexte sur des cas concrets (gestion d’assets, workflows, multi-tenant léger). C’est là que je réalise à quel point les cursorrules et l’organisation par dossier sont critiques pour un workflow de production. L’objectif : poser une base cohérente qui guide Cursor sans devoir tout réexpliquer à chaque interaction. C’est aussi le moment où je comprends qu’il faut formaliser les règles humaines et techniques dans des fichiers lisibles par l’IA.

Printemps 2025 : Sonnet 4.0 & Opus 4.0 (autre saut)

Le 22 mai 2025, Anthropic annonce officiellement Claude Sonnet 4 et Claude Opus 4. Pour moi, c’est un nouveau tournant. Dès la sortie, j’ai testé les modèles et, convaincu par les capacités de reasoning et de codage, j’ai commencé à utiliser Claude Code, l’outil d’Anthropic pour travailler directement depuis le terminal / IDE. J’ai souscrit à l’offre Claude MAX afin de pouvoir itérer sans contrainte.

En une session intensive, je construis un site React complet, BDD incluse (une preuve de concept perso de ce qu’on peut sortir quand modèles et prompts sont alignés). Soyons clairs : ça reste du code de “vibe coding”, vite fait, mal fait. Excellent POC, mais impossible à maintenir tel quel en prod.

Au-delà de la technique, une certaine “culture IA” commence à me fatiguer : réponses pleines d’émojis, ton faussement cool, verbiage inutile. Je veux des outils sobres et efficaces, pas un chatbot qui me tape dans le dos.

Fin mai-juin 2025 : Migration Cursor → Claude Code : duplication puis liens symboliques

Au début avec Claude Code, je pars de ce que j’ai déjà : mes règles Cursor. Très vite, je copie/colle mes .cursorrules (et certains .cursor/rules importants) dans Claude.md pour garder le même cadre côté Anthropic. Résultat : deux versions des mêmes directives dans le repo (une côté Cursor, une côté Claude), avec seulement des noms/chemins différents.

Ce doublon ne me convient pas. Je veux une seule source de vérité : je crée donc un fichier AI.md (format neutre) qui contient le contexte « maître ». Pour Claude Code, c’est simple : je pose un symlink Claude.md → AI.md. Pour Cursor, en revanche, un simple lien symbolique ne suffit pas : les règles sont des fichiers .mdc avec frontmatter et contraintes propres (globs, scope, types de règles, etc.).

Avec ce système, Cursor charge la règle adéquate selon le dossier (via patterns/regex), et Claude récupère le même contenu via symlink, sans duplication. Ce n’était pas fragile en soi ; la robustesse venait justement de la standardisation AI.md + génération des .mdc.

En parallèle, dans Claude Code, j’expérimente l’auto‑inclusion des fichiers de contexte. C’est là que l’idée d’un chargement dit “lazy-loading” émerge : ne charger que le nécessaire, au bon moment. Cette piste (combinée à l’unification AI.md pour Claude et Cursor) m’amène à la phase suivante, beaucoup plus ambitieuse et chronophage : construire un système multicouches (voir la section L0 / L1 / L2) avec des passes successives pour raffiner le contexte.