Mon usine logicielle à l'heure de l'IA

À retenir

1. Date / source. 28 juillet 2026, eventuallycoding.com, Hugo Lassiège. Page de référence assumée comme telle, décrivant le dispositif avec lequel l'auteur fait tourner ses propres produits en production, seul.
2. Cadrage clé. ce n'est pas du vibe coding — « Le vibe coding tel que défini par Karpathy c'était de l'expérimentation et le fait de se laisser porter. Ici, je vais parler de context engineering. » Avec la clause de responsabilité : « Même si je n'écris pas le code, j'en suis responsable et je dois garder le contrôle dessus. » ### La grille des trois questions Tout l'outillage répond à trois questions, et c'est l'apport le plus réutilisable du texte : | Question | Ce qui y répond | |---|---| | Qu'est-ce que l'agent sait ? | contexte, mémoire, graphe de code | | Qu'est-ce qu'il sait faire de façon déterministe ? | skills, procédures | | Qu'est-ce qui l'arrête quand il se trompe ? | hooks, tests d'architecture, quality gates | Posée devant une installation agentique, elle révèle laquelle des trois est vide. Principe directeur associé : « Ce qui compte doit être exécutable. Une consigne est suivie "la plupart du temps", mais elle peut être oubliée. Un hook ou un test est suivi tout le temps. » Et sur les tests d'architecture : « ça ne peut pas être contourné, à l'inverse d'une rule. » ### Les six couches | # | Couche | Contenu | |---|--------|---------| | 1 | Contexte | CLAUDE.md racine permanent et court (architecture, conventions, index des specs) ; .claude/rules/.md conditionnels activés par frontmatter paths: ; .agents/.md pour le non technique (positionnement, personas, ton) | | 2 | Skills | une trentaine, six familles ; critère d'existence : la troisième répétition | | 3 | Outils | MCP IDE JetBrains, GitNexus (graphe de code), Claude-mem, Sentry, base en lecture seule | | 4 | Garde-fous | hooks du harnais, tests d'architecture, lint de patterns (ast-grep) | | 5 | Usine | quality gate bloquante, cinq étages de tests | | 6 | Process produit | specs numérotées, skill de rédaction et skill de clôture, feature flags | Couche 1 — le contexte permanent porte l'index, pas le contenu : la rule vue en entier est une table de routage listant neuf skills avec la tâche qui les déclenche. « Si l'IA ne fait pas de changement de schéma, aucun intérêt d'aller ouvrir la skill db-migration. » Couche 2 — les skills « procédure multi-fichiers » sont les plus rentables : « ajouter un bloc à l'éditeur de contenu touche trois surfaces de rendu ; sans skill, l'agent en oublie systématiquement une ». Nuance : « Ce chargement automatique peut parfois échouer. Dans ce cas, il faut demander explicitement d'utiliser la skill. » Sous-agents en recul, réservés aux tâches « qui génèrent beaucoup de lecture sans beaucoup de décision » — « Je les utilise de moins en moins, les agents récents font eux-mêmes des délégations assez ciblées. » Couche 3 — GitNexus indexe le dépôt en graphe et donne impact(symbole) avant de modifier, detect_changes() avant de commiter, la recherche d'un flux d'exécution plutôt qu'un grep, et le renommage via le graphe d'appels. Justification de l'auteur : « Le vrai sujet c'est pas la vitesse, c'est de détecter tous les effets de bord d'une modification. » MCP traité comme une dépense de contexte à justifier : « J'essaie d'éviter les MCP qui sont plus consommateurs en contexte. » Couche 4 — les hooks sont « des scripts déclenchés par le harness de l'agent, pas par l'agent lui-même » : refuser le build natif et rediriger vers le build IDE, lancer le formateur après écriture. Distinction du lint : ESLint pour la syntaxe, ast-grep pour les décisions d'architecture (interdire tout appel à fetch sans passer par le client OpenAPI), typecheck pour le typage. Couche 5 — push sur main → quality gate (lint → lint de patterns → typecheck → tests) → build image → registry → webhook de déploiement, le job de déploiement portant un needs: sur le job de qualité. Cinq étages : unitaire, intégration avec conteneurs jetables (« base de données et broker réels, pas de mock »), architecture, composants front, end-to-end sur les parcours critiques uniquement. Couche 6 — specs encadrées par deux skills, dont une pour clôturer en mettant la spec à jour avec ce qui a réellement été construit : « La doc de spec meurt si sa clôture n'est pas dans le process. » Règle anti-hallucination : « Si une spec est floue ou incohérente avec l'existant, l'agent doit poser la question, pas deviner. » Livraison par étapes sous feature flag, motivée par la dégradation du contexte long — « ça me permet de faire plusieurs petites sessions d'implémentation plutôt qu'une grosse session, qui a tendance à se dégrader en qualité ». Distinction feature flipping (Unleash : rollout, kill-switch) vs gating (contrat client, plan). ### Le geste le plus instructif : une contrainte future déjà garantie L'auteur prévoit d'open-sourcer une partie du code. La règle « le code destiné à l'open source ne doit jamais dépendre du code propriétaire » est écrite dans les rules et vérifiée par un test d'architecture. « Écrire une contrainte future dans le contexte évite de payer une refonte plus tard. » ### Par où commencer, dans l'ordre donné 1. La quality gate d'abord si elle n'existe pas. 2. Un CLAUDE.md léger décrivant l'essentiel et le pourquoi. 3. Des rules au fil de l'eau sur les patterns d'architecture importants. 4. Des skills dès qu'une procédure revient. 5. CLI et MCP pour les outils principaux. Avertissement : « tout skill, MCP, code repris depuis l'extérieur doit être scruté. Ce sont des dépendances qui peuvent être des vecteurs d'attaques. » ### Les quatre limites vécues 1. L'obsolescence des rules n'est pas mesurable. « Milieu 2025, "écris un test pour chaque nouveau service" faisait sens. Aujourd'hui c'est du bruit et Claude le fait naturellement… J'ai aucun moyen de mesurer et de savoir si une ancienne rule est devenue obsolète. » 2. Le rabbit hole. Une rule boyscout.md produit « des sessions sans fin » et de la surcharge cognitive ; correctif envisagé, router ces constats vers une TODO list et déplacer la maintenance dans un workflow séparé. 3. Pas de packaging. Skills et rules sont copiés-collés d'un projet à l'autre, parfois dépendants du poste. 4. Dépendance à Claude, jugée « risque modéré », et IDE devenu inadapté : « j'utilise encore IntelliJ mais je ne le trouve plus adapté à notre époque. » ### L'aveu de fond « Les dernières versions d'Opus sont de plus en plus autonomes… Soyons honnête, je suis de moins en moins utile sur les phases d'implémentation, mais je ne veux pas perdre le contrôle du code produit. Je suis partagé entre la satisfaction d'avoir une usine logicielle de plus en plus efficace et le risque de perdre la connaissance. » Le dispositif garantit que le code est correct ; il ne garantit pas que l'humain le comprenne encore. Question laissée ouverte : « Je dois trouver un moyen pour contrôler a posteriori les designs, de m'approprier le résultat. » Même problème que celui posé par [[osmani-cognitive-surrender-comprehension-debt-2026-05-05]]. ### Portée Dispositif solo, sur des produits personnels, avec un seul décideur : aucune coordination multi-développeurs, aucune revue par un pair, aucune contrainte de conformité. Se transposent en entreprise la grille des trois questions, le principe de l'exécutable, la clôture de spec et le lint de patterns ; ne se transpose pas l'absence de gate humaine autre que soi. Même thèse, énoncée en doctrine deux jours plus tard, dans [[sfeir-code-review-anneau-contraintes-2026-07-30]].