Quality gates dans le pipeline CI/CD : une construction en quatre étapes

Une chaîne de contrôle efficace se répartit sur quatre étapes : quelques secondes au commit, quelques minutes à la pull request, en profondeur avant le merge, sans concession avant le déploiement. L’ordre obéit à un seul principe — plus tôt une erreur est détectée, moins elle coûte ; chaque contrôle doit donc être placé aussi tôt que sa durée d’exécution le permet.

Comment intégrer des quality gates dans un pipeline CI/CD ?

En quatre étapes, avec un budget de temps clair pour chacune. Le budget compte plus que l’exhaustivité : un pipeline qui prend quarante minutes sera contourné.

Quel contrôle va dans quelle étape ?

L’affectation suit la durée d’exécution, non l’importance. Un contrôle important qui prend dix minutes n’a malgré tout pas sa place à l’étape 1 — sinon l’étape 1 sera désactivée et tous les contrôles qu’elle contient disparaîtront avec elle.

• L’étape 1 doit passer inaperçue. Tout ce qui dure ici plus de quelques secondes est ressenti comme une gêne. Ne contrôlez que les fichiers modifiés, pas le projet.
• L’étape 2 est le véritable portail de qualité. C’est ici que se décide si une modification mérite seulement d’être discutée. Tout ce qui peut être tranché par machine a sa place ici — afin que la revue ne conserve que les questions pour lesquelles il faut un humain.
• L’étape 3 peut être coûteuse, car elle s’exécute rarement. Tests d’intégration contre de vraies dépendances, tests des parcours principaux dans le navigateur.
• L’étape 4 n’est pas un contrôle de code. Il s’agit ici de l’opération elle-même — plus d’informations ci-dessous.

Comment garder le pipeline rapide ?

Avec quatre mesures qui, ensemble, font la différence entre vingt minutes et trois.

• Ne contrôler que ce qui a changé. L’analyse statique et les linters ont besoin du diff, pas du dépôt.
• Mettre les états intermédiaires en cache. Les dépendances et les artefacts de build vont dans le cache, pas dans chaque exécution.
• En parallèle plutôt qu’à la suite. Les tests, l’analyse et le build n’ont aucune dépendance d’ordre.
• Interrompre tôt. Si le linter échoue à la troisième seconde, la suite de tests de douze minutes n’a plus besoin de s’exécuter.

Pourquoi le deploy gate est-il le plus important ?

Parce que c’est la seule étape où une erreur est non seulement coûteuse, mais immédiatement visible. Un code smell passé entre les mailles coûte du temps dans six mois. Une migration irréversible ou un fichier livré par erreur qui n’a jamais sa place sur un serveur coûte dès ce soir.

Un deploy gate contrôle donc d’autres choses que les étapes précédentes :

• Qu’est-ce qui est réellement transféré ? Chaque fichier du périmètre de transfert doit être classifié : a sa place sur le serveur, n’a sa place qu’en local, ne doit jamais aller sur un serveur. Les fichiers de configuration, les identifiants d’accès et les outils de développement relèvent du troisième groupe.
• Une modification de schéma est-elle incluse, et est-elle réversible ? Une migration sans contrepartie est une rue à sens unique. Au préalable : prouver l’existence d’une sauvegarde.
• Existe-t-il une voie de retour arrière, et a-t-elle été testée ? Une voie de retour arrière jamais éprouvée est une supposition.
• Quelque chose s’exécute-t-il ensuite pour vérifier le succès ? Un smoke test après le déploiement fait la différence entre « livré » et « fonctionne ».

Aucune de ces quatre questions ne peut être résolue par davantage de tests — elles portent sur l’opération, non sur le code. C’est pourquoi l’étape 4 a besoin de sa propre barrière, voir Qu’est-ce qu’un quality gate.

Comment introduire des gates sans bloquer l’exploitation courante ?

D’abord en observation, puis en blocage — et toujours uniquement pour le nouveau code.

• Semaines 1 à 2 : signaler seulement. Tous les contrôles s’exécutent, aucun n’interrompt. Vous voyez à quelle fréquence quel critère se déclencherait.
• Semaine 3 : activer les cas clairs. Les tests en échec et les secrets dans le code interrompent. Personne ne s’y oppose.
• Ensuite : tracer une ligne de base et durcir pour le nouveau. L’existant est gelé, la pleine rigueur s’applique aux lignes modifiées. La démarche figure dans l’article sur l’analyse statique du code.

Questions fréquentes sur les quality gates dans le pipeline

Quelle est la différence entre CI et CD ?

L’intégration continue (Continuous Integration) désigne la fusion fréquente et le contrôle automatique des modifications. La livraison continue (Continuous Delivery), ou le déploiement continu (Continuous Deployment), désigne la livraison automatisée de l’état contrôlé. Les gates des étapes 1 à 3 relèvent de la CI, l’étape 4 de la CD.

Le pipeline doit-il s’interrompre à chaque constat d’analyse ?

Non, seulement au-dessus d’un niveau de gravité défini et seulement pour les nouveaux constats. Interrompre à chaque remarque de style produit des contournements plutôt que de la qualité.

Comment traiter les tests peu fiables ?

Comme un problème à part entière, non comme du bruit. Un test qui est parfois rouge sans raison coûte plus qu’il ne rapporte : il entraîne l’équipe à relancer les exécutions rouges au lieu de les lire. Soit le réparer, soit le supprimer.

Ai-je besoin d’un hook Git pour l’étape 1 ?

Un hook local est la voie habituelle, mais il est contournable et se trouve sur la machine de chacun. Ne vous y fiez pas seul — ce qui est contrôlé à l’étape 1 devrait s’exécuter à nouveau à l’étape 2.

Quel fichier de votre dernier déploiement n’avait en réalité rien à faire sur le serveur ? Si vous ne pouvez pas répondre d’emblée, c’est précisément là la lacune. Code Guardian classifie chaque fichier du périmètre de transfert et traite chaque migration comme irréversible tant que le contraire n’est pas prouvé.

Sources

• OWASP Top 10:2025, catégorie A03 « Software Supply Chain Failures » (justification du contrôle des dépendances à l’étape 2).
• ISO/IEC 25010:2023 (caractéristiques de qualité comme cadre de référence pour les critères de gate).

Mise à jour : 27 juillet 2026. Mise en perspective technique générale ; les budgets de temps concrets dépendent de la taille du projet et de l’infrastructure.