CI/CD : les étapes qui protègent la main

Le principe : un entonnoir du rapide-pas-cher au lent-coûteux

Une bonne pipeline ordonne ses vérifications par coût croissant — échouer vite sur ce qui est bête, réserver le cher pour la fin :

stage quality (secondes)     lint, format, typage, lint SQL, secrets — parallèle, bloquant
stage test (minutes)         tests unitaires + intégration (vraie DB) — bloquant
stage arch                   import-linter, deptry — les frontières comme test
stage report (non bloquant)  dead code, couverture, benchmarks — informe sans bloquer
stage build                  images Docker — seulement si tout le reste est vert

L'ordre n'est pas cosmétique : un lint qui échoue en 10 s évite de lancer 8 min de tests. Et le parallélisme intra-stage (les 5 linters en même temps) réduit le temps mur sans réduire la couverture.

Bloquant vs informatif : le curseur qui compte

Chaque job est soit un gate (rouge = MR bloquée) soit un rapport (rouge = signal, MR passe). La règle de conception :

• bloquant : tout ce qui, cassé, ne DOIT pas atteindre main — types, tests, sécurité, frontières d'architecture, et le Quality Gate (couverture/smells du new code) ;
• informatif : ce qui guide sans arrêter — dead code, tendances, benchmarks de perf. Les rendre bloquants d'un coup paralyserait l'équipe sur la dette historique ;
• la stratégie « new code » : Sonar ne juge que ce que la MR ajoute — on améliore à la marge sans être otage du passé. C'est ce qui permet de rendre le gate bloquant sans tout réécrire.

Le contrat d'une MR

Le résultat, pour le développeur (humain ou agent, cours dédié) : une MR verte = le code respecte tous les invariants mécaniquement vérifiables. La revue humaine n'a plus à traquer un type manquant ou un import interdit — elle se concentre sur le sens et le design. La CI n'est pas une contrainte subie : c'est ce qui rend la revue rapide et la main sûre. Une équipe qui livre plusieurs fois par jour ne le fait pas malgré sa CI stricte, mais grâce à elle.