L'explosion contextuelle

Je passe des règles dispersées aux premiers systèmes. J’essaie d’automatiser le contexte, je me heurte vite aux limites de ma machine, puis je garde une idée qui va rester : une source unique, des formats dérivés.

Génération automatique de contexte

Début 2025

Je reprends les expérimentations IA à fond, mais avec une obsession plus précise : comment faire comprendre un projet à l’IA sans la noyer, et sans la laisser travailler à l’aveugle ? Si je lui donne trop peu, elle manque la forme du système. Si je lui donne tout, elle se perd.

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

Je transforme cette idée en script : une récursion bottom-up inspirée du pattern visitor (vieux réflexe de cours de compilation), qui visite l’arborescence, résume chaque morceau, puis remonte progressivement vers une vue d’ensemble.

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

Flux: fichiers → Ollama → résumés analyzed.yaml → agrégation bottom-up

Pour chaque fichier :
  lire le contenu
  demander un résumé structuré à Ollama
  écrire ce résumé dans analyzed.yaml du dossier

Puis, en remontant l'arbre :
  lire les analyzed.yaml des sous-dossiers
  les agréger dans analyzed.yaml du dossier parent
  répéter jusqu'à la racine du projet

Le principe me plaît : chaque fichier laisse une trace structurée (type, fonctions, dépendances, complexité), chaque dossier agrège les traces de ses enfants dans un fichier de contexte (un analyzed.yaml), et le projet finit par produire sa propre carte. Je peux descendre du global au détail sans tout charger d’un coup.

En pratique, ça coince vite. Tout est séquentiel : un appel HTTP par fichier vers Ollama, sur un modèle de raisonnement (DeepSeek R1 8B) qui pense avant de répondre. Sur un petit projet, j’attends déjà autour d’un quart d’heure. Sur un gros projet, le temps explose. Le principe reste intéressant, mais il ne passe pas à l’échelle sur mon matériel. Je mets le projet en pause. Le code reste là, figé en plein refactoring.

Ce que je garde, ce n’est pas le script. C’est l’idée d’un contexte qui peut se reconstruire par passes : une première lecture donne une carte grossière, puis les suivantes repartent de cette carte pour corriger et préciser.

Je visais aussi un petit langage pour décrire le projet, avec des scans de plus en plus spécialisés et plusieurs modèles selon leurs points forts : résumé, structure, sémantique. Sur le papier, chaque passe rendait la suivante moins aveugle. Dans les faits, la première passe était déjà trop lente. Ajouter des passes rendait le système intenable.

Je ne le mène jamais jusqu’au bout, mais le retour d’expérience reste précieux. Je clarifie pour moi l’importance du découpage hiérarchique, de l’agrégation sélective, et d’un contexte qui se construit par passes successives.

Cursor, Sonnet 3.7 (pendant l’effort)

Je continue à utiliser Cursor intensivement. Sonnet 3.7 (Anthropic) me bluffe sur certains aspects du code : je bascule progressivement vers Anthropic pour de la génération plus fiable. 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 à répartir des règles dans le projet : .cursorrules, puis .cursor/rules. Je cherche moins le bon prompt que le bon endroit où poser les conventions.

En parallèle, un projet perso grossit. Au départ, c’est un simple site. Puis ça devient une application complète, avec des assets, des workflows, des conventions par dossier. Les règles ne sont plus théoriques : je vois tout de suite quand elles aident, quand elles manquent, et quand je dois tout réexpliquer. C’est là que je comprends que les règles Cursor et l’organisation par dossier peuvent devenir une vraie surface de production.

Les règles deviennent elles aussi un système à maintenir : conventions humaines, contraintes techniques, emplacement dans l’arborescence, format attendu par chaque outil.

Sonnet 4 et Opus 4 (autre saut)

Printemps 2025

Quand Anthropic annonce Claude Sonnet 4 et Claude Opus 4, le saut se sent tout de suite. Claude Code existait déjà en preview, j’en avais entendu parler, mais je m’y mets vraiment à ce moment-là : l’outil devient généralement disponible, les intégrations IDE arrivent, et l’ensemble entre dans mon quotidien de dev. Je teste les modèles dès la sortie et je souscris à Claude Max pour pouvoir itérer sans contrainte.

En une session intensive, je construis un site React complet, BDD incluse (un POC perso, pour voir jusqu’où ça va). 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, blabla inutile. Je veux des outils sobres et efficaces, pas un chatbot qui me tape dans le dos.

Migration Cursor → Claude Code : duplication puis liens symboliques

Mai-juin 2025

Quand je passe à Claude Code, je ne repars pas de zéro. Je prends ce que j’ai déjà : mes règles Cursor. Je copie les .cursorrules, puis certains fichiers .cursor/rules, dans CLAUDE.md pour retrouver le même cadre côté Anthropic.

Le doublon devient vite pénible. Deux fichiers racontent la même chose, mais avec des noms et des formats différents. Je crée donc AI.md comme source neutre : le contexte maître vit là, les outils s’adaptent autour.

Pour Claude Code, c’est simple : CLAUDE.md peut pointer vers AI.md par lien symbolique. Côté Cursor, le lien symbolique ne suffit pas. Les règles ont leur format, leurs métadonnées, leurs globs. Il faut donc générer des fichiers .mdc à partir de la même source, au lieu de maintenir une deuxième version à la main.

Avec ce système, Cursor charge la règle adaptée au dossier, et Claude récupère le même contenu par lien symbolique. Je ne maintiens plus deux textes concurrents. La robustesse vient de là : une source, plusieurs formats dérivés.

Dans Claude Code, j’expérimente aussi 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 unification me pousse vers la suite : un système qui démarre léger, et qui descend dans les couches de contexte quand la tâche le demande.