# lassiege-usine-logicielle-heure-ia-2026-07-28

## Veille

Page de référence publiée sur **eventuallycoding.com** le **28 juillet 2026** par **Hugo Lassiège** (Lyon, développeur devenu entrepreneur, auteur de Bloggrify, Hakanai et Writizzy). L'auteur l'annonce comme telle : *« Ce sera plus une page de référence qu'un article »*, destinée à sa propre page ressources. **Objet** : la description exhaustive et outillée d'une **usine logicielle solo** où *« le code produit est désormais quasi 100 % généré »*, sur plusieurs monorepos polyglottes (Nuxt, Kotlin, JS — Hakanai, Writizzy, Bloggrify) en **déploiement continu en production**. **Distinction posée d'entrée** : ce n'est pas du **vibe coding** au sens de Karpathy (expérimentation, se laisser porter) mais du **context engineering** — *« donner tout le contexte nécessaire, au bon moment, pour que le logiciel corresponde à une intention et soit contrôlé systématiquement »*, avec la phrase qui fonde la responsabilité : *« Même si je n'écris pas le code, j'en suis responsable et je dois garder le contrôle dessus. »* **L'outillage entier répond à trois questions**, et c'est la grille de lecture la plus réutilisable du texte : *« 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). **Six couches détaillées** : (1) **contexte** — `CLAUDE.md` racine + `.claude/rules/*.md` thématiques à chargement conditionnel par `paths:` + `.agents/*.md` pour le non-technique (personas, positionnement, ton) ; (2) **skills** — une trentaine, critère d'existence *« si j'explique la même chose une troisième fois »* ; (3) **outils** — MCP IDE JetBrains, **GitNexus** (graphe de code : `impact(symbole)`, `detect_changes()`), Claude-mem, wrapper de filtrage RTK, Sentry, base en lecture seule ; (4) **garde-fous exécutables** — hooks du harness, **tests d'architecture**, lint de patterns (**ast-grep** pour les décisions d'architecture, pas seulement ESLint) ; (5) **usine** — quality gate bloquante avec `needs:` sur le job de qualité, cinq étages de tests ; (6) **process produit** — specs numérotées avec skill de rédaction **et skill de clôture**, design dans Claude Design, livraison par étapes sous feature flag, distinction **feature flipping** (Unleash) vs **gating** (contrat client). **La règle qui résume tout** : *« Ce qui compte doit être exécutable. Une consigne est suivie "la plupart du temps"… Un hook ou un test est suivi tout le temps. »* ⚠️ **Rareté du texte** : une section « À améliorer » qui expose quatre limites vécues — l'**impossibilité de mesurer l'obsolescence d'une rule** (*« j'ai aucun moyen de savoir si une ancienne rule est devenue obsolète »*), le **rabbit hole** créé par une règle boyscout, l'**absence de packaging** des skills entre projets, et surtout l'aveu de tension : *« je suis de moins en moins utile sur les phases d'implémentation »*, *« partagé entre la satisfaction d'avoir une usine de plus en plus efficace et le risque de perdre la connaissance »*.

## Titre Article

Mon usine logicielle à l'heure de l'IA

## Date

2026-07-28

## URL

https://eventuallycoding.com/p/mon-usine-logicielle-a-l-heure-de-l-ia

## Keywords

usine logicielle, context engineering, vibe coding, Karpathy, code 100% généré, solo dev, monorepo, polyglotte, Nuxt, Kotlin, déploiement continu, CLAUDE.md, rules, chargement conditionnel, paths, agents.md, personas, contexte permanent, budget de contexte, économie de tokens, skills, procédure rejouable, sous-agents, délégation, MCP, JetBrains, GitNexus, graphe de code, impact, rayon d'explosion, detect_changes, flux d'exécution, Claude-mem, mémoire persistante, RTK, filtrage des sorties, Sentry, base en lecture seule, garde-fous exécutables, hooks, harness, tests d'architecture, frontière open source, lint de patterns, ast-grep, ESLint, typecheck, quality gate bloquante, GitHub Actions, needs, étages de tests, conteneurs jetables, testcontainers, end-to-end, process produit, spec numérotée, clôture de spec, Claude Design, maquette, feature flag, Unleash, feature flipping, gating, trunk based, Marty Cagan, quatre risques, obsolescence des rules, rabbit hole, boyscout, packaging des skills, perte de connaissance, Hugo Lassiège

## Authors

**Hugo Lassiège** — développeur devenu entrepreneur, basé à **Lyon**, écrit du code depuis 2001 et tient **eventuallycoding.com** (le blog a porté le nom `hakanai.free.fr` avant de devenir *Eventuallycoding* en 2013). *Eventuallycoding* est le nom-parapluie qui regroupe ses projets, sa chaîne YouTube et ses blogs.

**Les trois produits cités sont les siens**, et c'est ce qui donne son poids au texte : **Bloggrify** (générateur de blog statique, open source), **Hakanai** (application de newsletter pour blogs statiques) et **Writizzy** (plateforme de blogging — qui propulse la page elle-même, *« Propulsé par Writizzy »* en pied de page). Il ne décrit donc pas une méthode conseillée à des clients mais **le dispositif avec lequel il fait tourner ses propres produits en production**, seul.

## Ton

**Profil** : **page de référence technique** assumée comme telle — *« Ce sera plus une page de référence qu'un article et je vais la référencer sur la page ressources du site »*. Registre de **praticien solo** documentant son propre poste de travail : ni thought leadership, ni retour d'expérience d'entreprise, ni tutoriel. Public : développeurs qui outillent déjà des agents et cherchent une configuration de référence à comparer à la leur.

**Style** : **architecture en couches numérotées** (1 à 6), chacune ouverte par sa fonction, densément **tabulée** — la page compte une dizaine de tableaux à deux colonnes (fichier/contenu, famille/ce qu'elles encodent, déclencheur/effet, étage/couverture, besoin/mécanisme). C'est une **fiche technique**, pas une démonstration : les tableaux portent l'information, la prose porte les raisons. Extraits de configuration réels et non maquillés (une `rule` complète avec son frontmatter `paths:` et son tableau de routage vers neuf skills, le schéma ASCII du pipeline CI, le contenu de `boyscout.md`).

**Trois traits qui distinguent le texte de la littérature ambiante** :

1. **La modestie sur la portée des règles.** *« Une contrainte c'est propre à un projet et à une personne. C'est pas une question de qualité logicielle au sens strict. »* L'auteur refuse explicitement de présenter ses conventions comme des bonnes pratiques universelles — rare dans un genre qui verse vite au prescriptif.
2. **L'auto-évaluation honnête des outils.** Sur Claude-mem : *« j'ai honnêtement un peu de mal à mesurer l'impact négatif ou positif. J'ai pas encore assez de recul »*. Sur le wrapper RTK : *« le gain est parfois annulé car Claude lance deux fois la commande »*. Sur les sous-agents : *« je les utilise de moins en moins »*. **On lit ce qui ne marche pas, ou plus.**
3. **L'aveu final, non résolu.** *« Je suis de moins en moins utile sur les phases d'implémentation »*, *« c'est limite flippant et plus rigoureux que 99 % des humains »*, *« partagé entre la satisfaction d'avoir une usine logicielle de plus en plus efficace et le risque de perdre la connaissance »*. Le texte se termine sur un problème ouvert, pas sur une conclusion.

**Formules-marqueurs** : *« Même si je n'écris pas le code, j'en suis responsable »*, *« Inutile de dire à une IA d'écrire du code de qualité, ça ne rime à rien. Il faut expliciter ses propres contraintes »*, *« Ce qui compte doit être exécutable »*, *« Le contexte est un budget »*, *« 1 bug résolu, 10 de produits »*, *« La doc de spec meurt si sa clôture n'est pas dans le process »*, *« si j'explique la même chose une troisième fois, ça devient une skill »*, *« ça ne peut pas être contourné, à l'inverse d'une rule »*.

## Pense-betes

- **⭐ 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.

- **⭐⭐ 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.

- **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]].

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

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

- **⭐ 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.**

- **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. »*

- **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]].

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

- **⭐ 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]].

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

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

- **⭐ 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.

- **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]].

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

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

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

- **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]].

- **⚠️ 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. »*

- **⭐⭐ 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. »*

- **⚠️ 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.

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

## RésuméDe400mots

Page de référence publiée le **28 juillet 2026** par **Hugo Lassiège** sur eventuallycoding.com, documentant son **usine logicielle solo** pour des produits en production (Hakanai, Writizzy, Bloggrify) dont *« le code produit est désormais quasi 100 % généré »*.

**Le cadrage.** Ce n'est pas du **vibe coding** — qui était, chez Karpathy, de l'expérimentation — mais du **context engineering** : *« donner tout le contexte nécessaire, au bon moment, pour que le logiciel corresponde à une intention et soit contrôlé systématiquement »*. La responsabilité ne se délègue pas : *« Même si je n'écris pas le code, j'en suis responsable. »* Et la qualité logicielle dépasse le code — elle inclut l'intention et les **quatre risques de Marty Cagan**.

**La grille.** Tout l'outillage répond à trois questions : ce que l'agent **sait** (contexte, mémoire, graphe de code), ce qu'il sait faire **de façon déterministe** (skills), et **ce qui l'arrête** quand il se trompe (hooks, tests, gates).

**Six couches.** Le **contexte** est stratifié par moment de chargement : `CLAUDE.md` court et permanent, `rules` conditionnelles activées par chemin, `.agents/*.md` pour les personas et le positionnement — une rule servant de **table de routage** vers des skills à n'ouvrir qu'au besoin. Les **skills** (une trentaine) naissent à la troisième répétition ; les plus rentables sont celles qui couvrent une **procédure multi-fichiers**. Les **outils** délèguent le déterministe : MCP IDE, **GitNexus** qui indexe le dépôt en graphe pour mesurer le rayon d'explosion d'une modification — *« le vrai sujet c'est pas la vitesse, c'est de détecter tous les effets de bord »*. Les **garde-fous** sont exécutables : hooks déclenchés par le harness, **tests d'architecture** qui cassent la CI, et **`ast-grep`** pour transformer une décision d'architecture en règle de lint. L'**usine** impose une quality gate dont le job de déploiement dépend (`needs:`), avec cinq étages de tests. Le **process produit** part d'une spec numérotée, encadrée par une skill de rédaction **et une skill de clôture** — *« sans elle, les specs deviennent obsolètes en six mois »* —, livrée par étapes sous feature flag.

**Le principe.** *« Ce qui compte doit être exécutable. Une consigne est suivie "la plupart du temps"… Un hook ou un test est suivi tout le temps. »*

**Les limites, exposées.** L'obsolescence d'une rule n'est pas mesurable ; une règle boyscout produit des sessions sans fin ; les skills se copient-collent faute de packaging. Et l'aveu final : *« je suis de moins en moins utile sur les phases d'implémentation »*, partagé entre l'efficacité de l'usine et *« le risque de perdre la connaissance »*.

## GrapheDeConnaissance

- Hugo Lassiège —publie→ Mon usine logicielle à l'heure de l'IA (DOCUMENT, 0.98)
- Hugo Lassiège —a_créé→ Bloggrify (TECHNOLOGIE, 0.93)
- Hugo Lassiège —a_créé→ Writizzy (TECHNOLOGIE, 0.93)
- Hugo Lassiège —affirme_que→ ce qui compte doit être exécutable : une consigne est suivie la plupart du temps, un hook ou un test est suivi tout le temps (CITATION, 0.97)
- test d'architecture —surpasse→ une rule de contexte, parce qu'il ne peut pas être contourné (AFFIRMATION, 0.95)
- context engineering —s_oppose_à→ vibe coding (METHODOLOGIE, 0.95)
- Hugo Lassiège —affirme_que→ même sans écrire le code, l'humain en reste responsable et doit en garder le contrôle (CITATION, 0.95)
- Hugo Lassiège —recommande→ expliciter ses propres contraintes plutôt que demander à une IA d'écrire du code de qualité (AFFIRMATION, 0.95)
- usine logicielle —est_basé_sur→ trois questions : ce que l'agent sait, ce qu'il fait de façon déterministe, ce qui l'arrête quand il se trompe (AFFIRMATION, 0.94)
- contexte permanent —permet→ d'indexer les skills sans les charger, le contenu n'étant ouvert qu'au besoin (AFFIRMATION, 0.92)
- skill —est_instance_de→ procédure écrite une fois et rejouée à l'identique, créée dès la troisième répétition (AFFIRMATION, 0.94)
- GitNexus —permet→ de mesurer le rayon d'explosion d'une modification et d'en détecter tous les effets de bord (AFFIRMATION, 0.94)
- graphe de code —surpasse→ le grep de nom de fonction pour retrouver un flux d'exécution (AFFIRMATION, 0.9)
- hooks —fait_partie_de→ harness de l'agent (CONCEPT, 0.94)
- ast-grep —permet→ de transformer une décision d'architecture en règle de lint (AFFIRMATION, 0.93)
- quality gate —permet→ d'empêcher tout déploiement non validé, via une dépendance du job de déploiement au job de qualité (AFFIRMATION, 0.95)
- clôture de spec —résout→ l'obsolescence des specs, qui deviennent périmées en six mois sans elle (AFFIRMATION, 0.93)
- feature flag —permet→ de livrer une spec par étapes et d'éviter les longues sessions dont la qualité se dégrade (AFFIRMATION, 0.9)
- Unleash —s_applique_à→ l'activation et la désactivation de fonctionnalités sans redéploiement (AFFIRMATION, 0.9)
- Hugo Lassiège —affirme_que→ rien ne permet de mesurer si une ancienne rule est devenue obsolète (AFFIRMATION, 0.93)
- règle d'amélioration continue —s_oppose_à→ la terminaison d'une session, en produisant des sessions sans fin (AFFIRMATION, 0.88)
- Hugo Lassiège —affirme_que→ l'efficacité croissante de l'usine logicielle s'accompagne d'un risque de perdre la connaissance du code (CITATION, 0.94)
- skills et MCP repris de l'extérieur —s_oppose_à→ la sécurité de la chaîne, en constituant des dépendances vectrices d'attaques (AFFIRMATION, 0.9)
- qualité logicielle —est_basé_sur→ les quatre risques de Marty Cagan — valeur, utilisabilité, faisabilité, viabilité — au-delà de la production de code (AFFIRMATION, 0.92)
- sous-agents —s_applique_à→ les tâches à forte lecture et faible décision, rendant une conclusion plutôt qu'un dump de fichiers (AFFIRMATION, 0.9)

---
Canonical: https://www.thekb.eu/fr/fiches/lassiege-usine-logicielle-heure-ia-2026-07-28/