> ## Content Index > Fetch the complete content index at: https://www.sfeir.dev/llms.txt > Use this file to discover other available public pages before exploring further. # Bootstrap IA - URL: https://www.sfeir.dev/ia/bootstrap-ia/ - Published: 2026-11-13T14:35:29.000Z - Updated: 2026-11-13T14:35:29.000Z - Description: Vos assistants IA improvisent, modifient trop de fichiers et perdent le fil dès que la session s'allonge ? Découvrez ia (bootstrap-ia), une CLI Node.js sans dépendance qui structure vos dépôts pour discipliner Claude Code ou Cursor : la conversation devient jetable, votre repo devient la mémoire. - Author: Fouad OUDJIT - Tags: IA, Bootstrap IA # Un socle de dev piloté par une IA : le framework « stateless » qui remet de l'ordre dans vos sessions Claude *Comment une poignée de fichiers Markdown et une CLI sans dépendance transforment un agent de code bavard et amnésique en collègue discipliné.* ![](https://storage.ghost.io/c/0b/31/0b31478e-a66a-46f1-8c34-d44388e21192/content/images/2026/11/image-2.png) --- ## Le problème : l'agent qui improvise Vous connaissez la scène. Vous demandez à votre assistant de code de « rajouter un filtre sur la liste ». Il explore la moitié du repo, modifie huit fichiers, réécrit un utilitaire « au passage », oublie un test et conclut par un résumé enthousiaste. Trois heures plus tard, la session fait 200 messages, le contexte est saturé, et l'agent ne se souvient plus de la décision prise ce matin. Deux causes : 1. **La mémoire est dans la conversation.** Tout ce que l'IA « sait » du projet vit dans un historique volatil, qui s'étire, se dégrade et disparaît au prochain `/clear`. 2. **Il n'y a pas de processus.** Concevoir, coder et recetter se mélangent dans le même élan, sans garde-fou. Pour répondre à ça, j'ai construit **`ia`** (package `bootstrap-ia`) : une petite CLI Node.js qui génère dans n'importe quel projet un **socle de développement géré par une IA**. Elle ne contient aucune dépendance et ne parle à aucun LLM. Elle dépose des fichiers, et ce sont ces fichiers qui disciplinent l'agent (Claude Code, Cursor, Cline…). ## Le principe : « Stateless » La règle fondatrice tient en une phrase, écrite en tête du routeur `CLAUDE.md` généré : > *Ta seule vérité se trouve dans les dossiers `.context/` et `.skills/`. Ne te fie jamais à l'historique de la conversation.* Autrement dit : **la conversation est jetable, le dépôt est la mémoire.** On peut vider le contexte à tout moment, l'agent repart de l'état documenté. D'ailleurs, **chaque étape se termine par un `/clear`** : le ticket du backlog porte tout le contexte utile à la suivante. ![](https://storage.ghost.io/c/0b/31/0b31478e-a66a-46f1-8c34-d44388e21192/content/images/2026/11/image-3.png) *Comme un poisson rouge qui tiendrait son journal de bord : la mémoire vit dans le dépôt, pas dans le bocal.* ## Ce que `ia init` génère `npm install -g git+https://gitlab.com/oudjit.f/bootstrap-ia.git` (voir « Pour essayer » en fin d'article) `cd mon-projet` `ia init` La commande détecte la stack (Node, TypeScript, Express, React, Python, Docker…), pose quelques questions (base de données, commande de test, fichiers « No-Touch », pitch produit, nombre max de fichiers par ticket…) et produit : ![](https://storage.ghost.io/c/0b/31/0b31478e-a66a-46f1-8c34-d44388e21192/content/images/2026/11/03-arborescence.png) Deux familles de fichiers cohabitent : - les **données projet** (`ARCHITECTURE`, `PRODUCT`, `DECISIONS`, `RULES`, `BACKLOG`) : c'est la mémoire du projet, que l'IA lit et enrichit ; - les **fichiers de méthode** (`CLAUDE.md`, `PROCESS.md`, `FEASIBILITY.md`, les skills) : le mode d'emploi de l'agent, **régénérable** et que l'on n'édite pas à la main. ## Le cycle : trois étapes, trois personas Le routeur `CLAUDE.md` impose un aiguillage strict : l'utilisateur annonce un **Cas**, l'IA charge *uniquement* la skill associée, et ne mélange jamais les étapes. Entre deux étapes, on fait un `/clear` : Cas 1, `/clear`, Cas 2, `/clear`, Cas 3, commit, `/clear`. Rien ne se perd, puisque tout est dans le ticket. ![](https://storage.ghost.io/c/0b/31/0b31478e-a66a-46f1-8c34-d44388e21192/content/images/2026/11/image-4.png) ### Cas 1 — Conception (Tech Lead & PO) > « Cas 1 ajouter l'export CSV » L'IA a l'**interdiction de générer du code**. Elle lit le contexte, ouvre au plus 3 fichiers cibles (pas de grep, pas d'exploration large : sinon elle délègue à un sous-agent pour garder son contexte propre), puis rédige un ticket dans le backlog selon un gabarit imposé : fichiers, plan, critères de validation vérifiables, cause racine, risque, décisions déjà tranchées, inconnues, dépendances, pièges applicables, prérequis techniques bloquants. Détail que j'aime bien : le **tri des inconnues**. Un arbitrage produit ou UX est posé à l'humain ; un fait vérifiable dans le code est noté « à vérifier en Cas 2 » plutôt que résolu à la volée. Et si le ticket dépasse la limite d'atomicité (3 fichiers par défaut), l'IA doit le **découper tout de suite**. Elle s'arrête ensuite et attend votre accord. Une fois vos arbitrages donnés, un seul `Edit` du backlog les intègre, sans nouvelle exploration : on ne rouvre pas l'enquête pour une virgule. ### Cas 2 — Exécution (Senior Software Engineer) > « Cas 2 CSV-01 » L'IA ne lit que le ticket actif, applique le plan et aligne les tests. Trois garde-fous : - **Atomicité** : si un fichier de plus que la limite est nécessaire, **STOP** et demande de redécoupage ; - **Limite d'itérations** : si un test échoue encore après N allers-retours (2 par défaut, configurable), l'IA expose le blocage et demande un arbitrage humain au lieu de s'acharner ; - **Hors périmètre** : un autre problème repéré n'est pas corrigé, il devient un *ticket candidat*. Elle ne coche rien et ne commite pas : elle annonce que le ticket est prêt pour la recette. ### Cas 3 — Recette & audit (QA & SecOps) > « Cas 3 CSV01 » Un autre persona prend le relais : rejouer les tests et linters, annoncer **OK ou KO avec la preuve** pour chaque critère de validation, puis **contrôler le diff** (`git diff --stat`). Les fichiers modifiés correspondent-ils à ceux du ticket ? Aucun secret, aucune zone protégée touchée ? Tout écart est signalé avant de continuer. Si un bug a été résolu, l'IA consigne le piège dans `RULES.md` : *c'est la boucle d'apprentissage du socle*. Chaque erreur résolue devient une règle que les futurs tickets liront (champ « Piège applicable »). Ensuite : ticket coché, `ia clean` pour purger le backlog, proposition de commit (Conventional Commits par défaut, scope = ID du ticket, **jamais de push**) exécutée après validation humaine, et enfin la demande de `/clear`. ### Cas 4 — La voie rapide Pour une typo ou un fix d'une ligne, passer par trois étapes serait absurde. Le Fast Track lit seulement `RULES.md` et `PROJET.md`, corrige, teste la zone touchée, propose un commit et s'arrête. Si ça touche plusieurs fichiers ou de la logique métier, il bascule automatiquement en Cas 1. ## Les cas « 0 » : migrer, sauver, mettre à jour Un framework qui ne marche que sur du neuf serait peu utile. Trois cas gèrent la vie réelle : - **Cas 0.1 – Migration** : vous avez d'anciens `OLD_*.md` ? L'IA les ventile dans les bons fichiers de `.context/`. - **Cas 0.2 – Memory Dump** : vous êtes à 150 messages d'une session riche en décisions ? L'IA transforme l'historique en documentation pérenne (stack, règles métier, pièges, ADR, reste à faire), vous le fait valider, puis vous ordonne un `/clear`. On bascule d'une mémoire volatile à une mémoire durable. - **Cas 0.3 – Mise à jour de la méthode**, le plus intéressant techniquement. ## `ia update` : mettre à jour la méthode sans écraser le projet ![](https://storage.ghost.io/c/0b/31/0b31478e-a66a-46f1-8c34-d44388e21192/content/images/2026/11/image-5.png) La méthode évolue (j'ai durci les cas 1, 2 et 3 à plusieurs reprises). Comment propager ça à des projets existants dont certains fichiers de méthode ont été personnalisés ? `ia update` stocke dans `.context/.ia.json` le **hash** de chaque fichier de méthode tel que généré, et le compare à l'état actuel : | Situation | Action | | -------------------------------- | ------------------------------------------------------------------------------------------------------------- | | Fichier absent | créé | | Identique à la nouvelle version | « à jour » | | Non modifié depuis la génération | remplacé automatiquement | | Modifié par vous | la nouvelle version est déposée en .new(sauf si la méthode n'a rien de neuf : le fichier est laissé tel quel) | Pour les `.new`, c'est… l'IA qui fusionne (Cas 0.3), et **sans vous poser de question** : en cas de doute, elle tranche en gardant la règle projet dans `PROJET.md` et le dit dans son résumé. Vous n'avez qu'un « Valider ? » à confirmer. Sa skill est précise : le `.new` devient la version finale, et tout ce qui était propre au projet dans l'original est **déplacé dans `.context/PROJET.md`**, une ligne par règle, préfixée par le cas concerné (`[Cas 3] lancer le linter X avant la recette`). Les valeurs de configuration (langue, limite de fichiers, format de commit) sont reportées dans `.ia.json`. Puis `ia update --adopt` enregistre les fichiers fusionnés comme gérés : **les prochaines mises à jour seront automatiques**. Dernier détail : `.ia.json` mémorise la configuration et l'état de chaque fichier, donc pensez à le commiter. Le résultat est une séparation propre : la **méthode** est standard et mise à jour par la CLI, la **personnalisation** vit dans `PROJET.md` (plafonné à une dizaine de règles pour éviter la dérive), les **données** vivent ailleurs. ## Ce que ça change en pratique - **Contexte maîtrisé** : chaque cas ne charge que ce dont il a besoin, et le `/clear` en fin de ticket évite la dérive des longues sessions. - **Revue facilitée** : un ticket atomique, un diff contrôlé par rapport au ticket, un commit au scope clair. - **Savoir cumulatif** : pièges dans `RULES.md`, décisions dans `DECISIONS.md`. Un nouveau venu, humain ou IA, lit les mêmes fichiers. - **Humain dans la boucle aux bons endroits** : validation du ticket, arbitrage après N échecs, validation du commit. L'IA ne push jamais. - **Agnostique** : ce sont des fichiers Markdown. Claude Code lit `CLAUDE.md` nativement ; avec Cursor ou Cline, il suffit de dire « Exécute le Cas 1 ». ## Les limites ![](https://storage.ghost.io/c/0b/31/0b31478e-a66a-46f1-8c34-d44388e21192/content/images/2026/11/image-6.png) Soyons honnêtes : - Le cadre repose sur le **respect des consignes par le modèle**. Il n'y a pas de garde-fou technique : un agent peut dévier, et la validation humaine reste le vrai filet. - Le gabarit de ticket est **lourd** pour de petites tâches (d'où le Cas 4). - Les textes sont écrits en français et pensés pour un workflow Git classique. - Le framework est jeune : il évolue au rythme de mes retours d'expérience, et chaque version durcit ce qui a dérapé en vrai. ## La CLI en quatre commandes La CLI reste volontairement minuscule : - `ia init` génère le socle (`.context/`, `.skills/`, `CLAUDE.md`) ; - `ia update` met à jour la méthode (avec `--adopt` après la fusion du Cas 0.3) ; - `ia clean` purge les tickets cochés du backlog ; - `ia help` affiche l'antisèche. `ia help` mérite un mot : c'est l'aide-mémoire à garder sous la main. Elle liste chaque Cas avec la phrase exacte à taper à l'IA (« Exécute le Cas 2 »), rappelle que la méthode ne s'édite pas (vos règles vont dans `PROJET.md`) et affiche la règle d'or : un `/clear` entre chaque Cas. Pratique quand on revient sur un projet après trois semaines. ## Pour essayer `npm install -g git+https://gitlab.com/oudjit.f/bootstrap-ia.git` Ou, sans installation globale : `npx --yes git+https://gitlab.com/oudjit.f/bootstrap-ia.git init`. Le code est sur [GitLab](https://gitlab.com/oudjit.f/bootstrap-ia?ref=sfeir.dev) (licence MIT) : issues et retours bienvenus. `cd votre-projet` `ia init` : génère `.context/`, `.skills/` et `CLAUDE.md` `ia help` : l'antisèche des cas Il faut Node.js 18 ou plus. Puis, dans votre assistant : *« Exécute le Cas 1 pour \[votre idée\] »*. Relisez le ticket, validez, faites un `/clear`, enchaînez avec le Cas 2, `/clear`, puis le Cas 3 et le commit. ## Conclusion Le gain principal de cet outil ne vient pas d'un modèle plus puissant mais d'une **ingénierie de contexte** : déplacer la mémoire hors de la conversation, découper le travail en étapes avec un rôle et des limites chacune, et transformer chaque erreur en règle écrite. Le code est aussi simple que possible (des gabarits de texte et un peu de hachage). Ce qui compte, c'est la discipline qu'il impose à l'agent, et à nous par la même occasion.