Chapitre 11.5 — CI, sécurité & industrialisation
⏱️ TL;DR — Les hooks (P7) garantissent la qualité sur ta machine ; la CI (GitHub Actions) la garantit pour l’équipe et à distance — c’est la porte partagée que rien ne franchit sans être vert. La sécurité a son outil dédié :
/security-reviewrelit les changements en cours à la recherche de vulnérabilités (et le pluginsecurity-guidanceen fait un réflexe continu). Industrialiser, c’est empiler les filets — local (hooks) → partagé (CI) → humain (revue) — pour qu’aucune régression ne passe. L’agent écrit ta CI ; toi, tu décides des portes.
🎯 Objectifs
- Mettre en place une CI (GitHub Actions) qui rejoue lint/test/build.
- Comprendre pourquoi la CI complète (et ne remplace pas) les hooks.
- Faire une revue de sécurité avec
/security-review. - Voir l’industrialisation comme des filets empilés.
Hooks vs CI : local vs partagé
Un hook (P7) tourne chez toi : il garantit ta qualité, mais un collègue sans les mêmes hooks, ou un push depuis un autre environnement, y échappe. La CI ferme cette faille : elle rejoue les vérifications sur un serveur, à chaque push/PR, pour tout le monde. C’est la porte partagée — une PR ne se merge pas si la CI est rouge.
Les deux sont complémentaires : les hooks donnent un feedback immédiat (avant même le commit) ; la CI est le garde-barrière que personne ne contourne. Ensemble, « c’est testé » devient vrai localement et globalement.
L’agent écrit ta CI
Une CI GitHub Actions de base, c’est un fichier .github/workflows/ci.yml que l’agent rédige très bien :
« Écris un workflow GitHub Actions qui, sur push et PR : installe les deps, lance
npm run lint,npm run typecheck,npm test,npm run build. Échoue si l’un échoue. Cache les deps. »
Tu obtiens la porte partagée. Ton rôle : décider quelles portes (quels checks sont bloquants pour merger), pas taper le YAML. L’agent industrialise ; tu définis la politique.
💡 Réflexe d’architecte — Aligne CI et hooks sur les mêmes vérifications (lint, typecheck, test, build). Ainsi, ce qui passe en local passe en CI, et inversement — pas de surprise « vert chez moi, rouge en CI ». La cohérence local/CI évite les allers-retours frustrants. (Bonus : les mêmes commandes vivent dans le
CLAUDE.md, les hooks et la CI — une seule source de vérité pour « comment on vérifie ».)
La sécurité : /security-review
La correction et le style ne couvrent pas tout : reste la sécurité. /security-review relit les changements en cours à la recherche de vulnérabilités (injections, secrets exposés, contrôle d’accès défaillant, désérialisation dangereuse…). À lancer sur un diff sensible (auth, données utilisateur, entrées externes) avant de merger.
Pour en faire un réflexe continu, le plugin security-guidance (10.3) fait relire chaque changement sous l’angle sécurité et guide la correction en cours de session. Deux échelles : /security-review ponctuel sur un diff à risque, security-guidance continu en arrière-plan.
⚠️ Piège — Croire que « les tests passent » couvre la sécurité. Un code parfaitement testé fonctionnellement peut être vulnérable (une requête concaténée, un secret loggé, un contrôle d’accès oublié). La sécurité est un axe distinct de vérification — traite-la à part (
/security-review), surtout sur ce qui touche à l’auth, aux entrées externes et aux données sensibles.
Industrialiser = empiler les filets
Rassemble tout ce qu’on a construit : l’industrialisation, c’est une superposition de filets, du plus immédiat au plus large :
Chaque filet attrape ce que les précédents laissent passer (rappel du modèle en couches, 3.3, étendu à toute la qualité). Aucun n’est parfait seul ; empilés, ils rendent une régression très difficile à faire passer. C’est ça, « livrable » : pas « ça marche sur ma machine », mais « ça a franchi tous les filets ».
🧭 Sur TaskFlow — On dote TaskFlow d’une CI (lint/typecheck/test/build, alignée sur les hooks P7), et on passe
/security-reviewsur tout ce qui touchera à l’auth et aux données. Le fil rouge a désormais la pile qualité complète : types/lint (édition) → tests (conclusion) → revue (/code-review + reviewer) → sécurité → CI → revue humaine. TaskFlow n’est plus un exercice : c’est un projet industrialisé, pilotable par toi comme par une équipe.
✏️ Exercices
Exercice 1 — Ta CI en 10 minutes. Fais écrire à l’agent un workflow GitHub Actions (lint/typecheck/test/build) aligné sur tes hooks. Pousse une PR volontairement cassée : la CI la bloque-t-elle ?
✅ Solution
Une CI bien faite rejoue exactement tes vérifications locales et bloque une PR rouge. Le test « PR cassée bloquée » prouve que la porte partagée fonctionne. Aligner CI et hooks sur les mêmes commandes évite les surprises « vert local / rouge CI ».
Exercice 2 — Sécurité à part. Lance /security-review sur un diff qui touche à des entrées externes ou à l’auth. Trouve-t-il un point que les tests fonctionnels ne voyaient pas ?
✅ Solution
/security-review remonte souvent ce que les tests fonctionnels ignorent : une validation d’entrée manquante, un secret loggé, un contrôle d’accès trop permissif. Ça confirme que la sécurité est un axe distinct : « ça marche » ne veut pas dire « c’est sûr ».
🧠 Quiz de révision
1. Pourquoi la CI complète-t-elle les hooks ?
Les hooks garantissent la qualité localement (chez toi) ; la CI la garantit pour tous, à distance — c’est la porte partagée rejouée sur serveur à chaque push/PR, qu’aucun contributeur ne contourne.
2. Que doit décider l’humain sur la CI, vs l’agent ?
L’agent écrit le YAML du workflow ; toi décides la politique (quels checks sont bloquants pour merger). L’agent industrialise, tu définis les portes.
3. Pourquoi aligner CI et hooks sur les mêmes vérifications ?
Pour éviter les surprises « vert en local, rouge en CI ». Mêmes commandes (lint/typecheck/test/build) partout = une seule source de vérité pour « comment on vérifie ».
4. « Les tests passent » couvre-t-il la sécurité ?
Non : un code testé fonctionnellement peut être vulnérable (injection, secret loggé, contrôle d’accès oublié). La sécurité est un axe distinct → /security-review (ponctuel) et security-guidance (continu).
5. Qu’est-ce qu’« industrialiser » en une image ?
Empiler les filets : types/lint → tests → revue → sécurité → CI → revue humaine. Chacun attrape ce que les autres laissent passer ; ensemble, une régression a très peu de chances de passer. « Livrable » = a franchi tous les filets.
Fin de la Partie 11. TaskFlow est industrialisé. On prend maintenant de la hauteur : Partie 12 — Devenir architecte AVEC l’IA, le cœur de ta demande.