Mon usine logicielle à l'heure de l'IA

À retenir

1. ⭐ La grille des trois questions — l'apport le plus réutilisable. tout l'outillage 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, sans improviser ? » (skills, procédures), « Qu'est-ce qui l'arrête quand il se trompe ? » (hooks, tests d'architecture, quality gates). Grille d'audit immédiate : posée devant n'importe quelle installation agentique, elle révèle en trois minutes laquelle des trois est vide. La troisième l'est presque toujours.
2. ⭐⭐ Le principe directeur, à retenir mot pour mot. « 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. » Décliné ailleurs de façon encore plus nette à propos des tests d'architecture : « ça ne peut pas être contourné, à l'inverse d'une rule ». → Une rule est une intention, un test est une garantie. C'est la même thèse que l'anneau de contraintes de [[sfeir-code-review-anneau-contraintes-2026-07-30]] (publié deux jours plus tard) et que le harness d'[[osmani-agent-harness-engineering-2026-04-19]], mais démontrée sur un dispositif réel et solo, pas énoncée en doctrine.
3. Contre le vibe coding, explicitement. « 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. » Et la clause de responsabilité qui en découle : « Même si je n'écris pas le code, j'en suis responsable et je dois garder le contrôle dessus. » Cf. [[karpathy-vibe-coding-agentic-engineering-software-3-0-2026-04-29]].
4. La qualité logicielle n'est pas la qualité du code. elle inclut l'intention (pourquoi, pour qui) et les quatre risques de Marty Cagan — Value, Usability, Feasibility, Viability — plus performance et fiabilité. C'est ce qui justifie la couche 6 (process produit) et explique pourquoi une usine logicielle purement technique passe à côté du sujet.
5. Couche 1 — contexte, et le geste à copier. trois niveaux séparés par leur moment de chargement. CLAUDE.md racine (architecture, conventions transverses, index des specs) → permanent et court ; .claude/rules/.md → conditionnels, activés par un frontmatter paths: (la rule Kotlin ne se charge que si on touche api//) ; .agents/.md → contexte non technique (positionnement produit, personas, ton). ⭐ La rule vue en entier est une table de routage : elle ne contient pas les procédures, elle liste neuf skills avec la tâche qui les déclenche, à n'ouvrir qu'au besoin. « Si l'IA ne fait pas de changement de schéma, aucun intérêt d'aller ouvrir la skill db-migration. » → Le contexte permanent porte l'index, pas le contenu.*
6. ⭐ La contrainte de long terme encodée comme contexte et comme test. — le meilleur exemple du texte : 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 (aucun fichier du côté « ouvert » ne référence le côté « propriétaire » ; tout fichier de production appartient à l'un des deux côtés). « Écrire une contrainte future dans le contexte évite de payer une refonte plus tard. » → Une décision qui n'existe pas encore peut déjà être garantie mécaniquement.
7. La phrase qui tue le prompt magique. « Inutile de dire à une IA d'"écrire du code de qualité", ça ne rime à rien. Il faut expliciter ses propres contraintes. » Assortie d'une honnêteté rare : « Une contrainte c'est propre à un projet et à une personne… C'est pas mieux ou moins bien de faire du feature flag, mais c'est ma préférence. »
8. Couche 2 — skills. « une procédure écrite une fois, rejouée à l'identique ». Critère d'existence : la troisième répétition. Une trentaine, en six familles (backend, frontend, données, cycle produit, exploitation/runbooks, écriture). Deux apprentissages : 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 »), et les skills « doc à jour » sont critiques sur du code qui bouge vite. ⚠️ Nuance opérationnelle : « Ce chargement automatique peut parfois échouer. Dans ce cas, il faut demander explicitement d'utiliser la skill. » Cf. [[shihipar-claude-code-lessons-building-skills-2026-06-03]], [[agent-skills-anthropic-2025-10-16]], [[vincent-superpowers-agentic-skills-framework-github-2026-04-02]].
9. Sous-agents, en recul. réservés aux tâches « qui génèrent beaucoup de lecture sans beaucoup de décision » (audit, exploration large, rédaction de doc) — ils « consomment leur propre contexte et rendent une conclusion, pas un dump de fichiers ». Mais : « Je les utilise de moins en moins, les agents récents font eux-mêmes des délégations assez ciblées. » Signal d'évolution : une pratique d'outillage rendue partiellement caduque par le modèle.
10. ⭐ Couche 3 — GitNexus, l'outil le plus intéressant du dispositif. le dépôt est indexé en graphe (symboles, relations, flux d'exécution), ce qui donne impact(symbole) avant de modifier (rayon d'explosion, appelants, niveau de risque), detect_changes() avant de commiter (« est-ce que je n'ai touché que ce que je voulais ? »), la recherche d'un flux d'exécution plutôt qu'un grep de nom de fonction, et le renommage via le graphe d'appels plutôt qu'en find-and-replace. Et la justification, qui vaut plus que l'outil : « Le vrai sujet c'est pas la vitesse, c'est de détecter tous les effets de bord d'une modification. » → repris en règle n° 4 : « Mesurer les impacts avant et après l'édition. On veut éviter l'effet "1 bug résolu, 10 de produits". » À rapprocher du contexte structuré du graphe de code face au RAG vectoriel — même famille d'argument que le résultat Compare the Market cité dans [[sfeir-code-review-anneau-contraintes-2026-07-30]].
11. MCP, avec réserve de coût. « J'essaie d'éviter les MCP qui sont plus consommateurs en contexte, mais j'en ai quand même quelques-uns » — IDE JetBrains (build, inspections, refactorings, recherche indexée), GitNexus, services métier (paiement, monitoring), base de données, navigateur. Le MCP est traité comme une dépense de contexte à justifier, pas comme un acquis.
12. Couche 4 — hooks : la définition qui compte. « des scripts déclenchés par le harness de l'agent, pas par l'agent lui-même ». Deux usages en production : avant un appel shell, refuser le build natif et rediriger vers le build IDE (plus rapide, erreurs structurées) en expliquant le fallback ; après une écriture de fichier, lancer le formateur/linter. Autres usages cités : bloquer l'édition de fichiers générés, exiger un test à côté de tout nouveau module, interdire un pattern dangereux.
13. ⭐ Lint de patterns — la distinction à retenir. ESLint pour la syntaxe, ast-grep pour les décisions d'architecture (exemple : interdire tout appel à fetch sans passer par le client OpenAPI), typecheck pour le typage. → Une décision d'architecture peut devenir une règle de lint. C'est le chaînon manquant entre « on a décidé » et « c'est appliqué », et il coûte quelques lignes.
14. Couche 5 — la gate. push sur main → quality gate (lint → lint de patterns → typecheck → tests) → build image docker → push registry → webhook de déploiement. Le point structurel : le job de déploiement a un needs: sur le job de qualité. « Rien ne part en production sans passer la gate. C'est indispensable en règle générale, encore plus pour du code produit automatiquement. » Cinq étages de tests : unitaire (massivement), 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. Cf. [[williams-adlc-3-tests-are-the-spec-2026-06-12]] et [[williams-adlc-2-two-human-gates-2026-06-12]].
15. Couche 6 — le process produit, et l'étape que tout le monde oublie. specs numérotées (une par domaine fonctionnel, indexées dans le contexte permanent) encadrées par deux skills — une pour rédiger la spec et son plan, une pour la clôturer en la mettant à jour avec ce qui a réellement été construit. « Sans elle, les specs deviennent obsolètes en six mois », et en règle finale : « La doc de spec meurt si sa clôture n'est pas dans le process. » ⭐ La clôture est la partie du cycle documentaire qui n'existe presque jamais ailleurs.
16. Règle anti-hallucination de spécification. « Si une spec est floue ou incohérente avec l'existant, l'agent doit poser la question, pas deviner. » Une ligne de contexte qui traite le mode d'échec le plus coûteux du développement agentique.
17. Livraison par étapes, et sa raison. la spec est faite pour être livrée par étapes protégées par feature flag, « ç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é si elle se remplit trop ». → Le découpage produit est ici dicté par la dégradation du contexte long, pas par la gestion de projet. Distinction utile : feature flipping (Unleash — activer/désactiver sans redéployer : rollout, kill-switch, maintenance) vs gating (table de configuration + service — restreindre selon le contrat client ou le plan). Deux mécanismes, deux besoins, et une skill pour que les agents ne les confondent pas.
18. Par où commencer (ordre donné, et il est bon). (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 fur et à mesure 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 sécurité : « tout skill, MCP, code repris depuis l'extérieur doit être scruté. Ce sont des dépendances qui peuvent être des vecteurs d'attaques. » À rapprocher de la surface d'attaque agentique décrite dans [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]].
19. ⚠️ Les limites vécues — la section qui rend la page crédible. 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. » → Le contexte accumulé se périme au rythme des modèles, et rien n'outille cette péremption. C'est le vrai trou méthodologique de tout le domaine, et il est nommé ici sans solution. 2. Le rabbit hole. Une rule boyscout.md (« laisser le code toujours un peu meilleur… signale-moi des améliorations ») 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é, partiellement automatisé. → Une bonne consigne d'amélioration continue devient un générateur de dérive quand l'agent ne s'arrête pas de lui-même. 3. Pas de packaging. Skills et rules sont copiés-collés d'un projet à l'autre, parfois dépendants du poste. Manque : un moyen de packager pour déployer et centraliser la maintenance. 4. Dépendance à Claude, jugée « risque modéré » (« tout l'écosystème bouge vers le haut »), avec envie de tester des modèles open weight — bloquée par le matériel. Et l'IDE devenu inadapté : « j'utilise encore IntelliJ mais je ne le trouve plus adapté à notre époque. Je n'ai pas encore vu une alternative intéressante. »
20. ⭐⭐ L'aveu de fond, à citer tel quel. « Les dernières versions d'Opus sont de plus en plus autonomes… C'est limite flippant et plus rigoureux que 99 % des humains. 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. » → C'est exactement la comprehension debt d'[[osmani-cognitive-surrender-comprehension-debt-2026-05-05]], formulée de l'intérieur par quelqu'un qui a construit le harnais le plus complet possible et qui constate que le harnais ne résout pas ce problème-là. Le dispositif garantit que le code est correct ; il ne garantit pas que l'humain le comprenne encore. La question ouverte du texte : « Je dois trouver un moyen pour contrôler a posteriori les designs, de m'approprier le résultat. »
21. ⚠️ Portée à ne pas surestimer. 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é ou d'audit — la couche « qui valide » est occupée par une seule personne qui est aussi l'auteur des règles. Ce qui se transpose en entreprise : la grille des trois questions, le principe de l'exécutable, la clôture de spec, le lint de patterns. Ce qui ne se transpose pas tel quel : l'absence totale de gate humaine autre que soi.
22. Méta / à relier. démonstration praticienne de [[osmani-agent-harness-engineering-2026-04-19]] et cousine directe de [[sfeir-code-review-anneau-contraintes-2026-07-30]] (publiée 2 jours après, même thèse : la qualité vit dans l'anneau de contraintes, pas dans le code) ; même vocabulaire d'« usine logicielle » que [[wescale-usine-logicielle-augmentee-juge-strategique-2026-05-03]], mais à l'échelle d'un individu ; s'oppose au vibe coding de [[karpathy-vibe-coding-agentic-engineering-software-3-0-2026-04-29]] ; converge avec [[klaassen-teach-ai-think-senior-engineer-every-2025-11-07]] sur l'explicitation des contraintes ; à lire avec [[shihipar-claude-code-lessons-building-skills-2026-06-03]] côté skills et [[williams-adlc-3-tests-are-the-spec-2026-06-12]] côté tests.