Quality gate

Une quality gate (porte qualité) est un ensemble de conditions qu’une modification doit remplir avant de passer à l’étape suivante : merge, déploiement en staging ou mise en production. Chaque condition est mesurable et vérifiée automatiquement ; si l’une d’elles échoue, le pipeline s’arrête. La gate remplace « quelqu’un trouve que ça a l’air bien » par une barre explicite et convenue.

Conditions typiques d’une gate

• Tous les tests bloquants passent (unitaires, API, un sous-ensemble smoke des tests end-to-end).
• La couverture de lignes ou de branches du nouveau code ne descend pas sous un seuil convenu.
• Aucune nouvelle anomalie critique ou élevée remontée par l’analyse statique ou l’analyse des dépendances.
• Les seuils de performance tiennent, par exemple une latence p95 sous 500 ms lors d’un court test de charge.
• Le build est reproductible et l’artefact est signé ou versionné.

Exemple

Une gate de couverture dans Jest. Si la couverture passe sous ces valeurs, jest --coverage se termine avec un code non nul et le job de CI échoue :

// jest.config.js
module.exports = {
  coverageThreshold: {
    global: {
      branches: 80,
      lines: 85,
    },
  },
};

À lui seul, cela ne fait qu’échouer un job. Cela devient une gate lorsque le job est un status check obligatoire dans la protection de branche : le bouton de merge reste alors désactivé tant qu’il n’est pas au vert. Des outils comme SonarQube regroupent plusieurs conditions dans une gate nommée avec un résultat unique réussite/échec.

Pourquoi c’est important

Les gates rendent la définition de « prêt » visible et cohérente. Elles déplacent aussi les débats au bon moment : l’équipe discute du seuil une seule fois, en le fixant, au lieu de le faire à chaque livraison.

Erreurs fréquentes

• Une gate sur des chiffres faciles à manipuler. Une règle stricte de 90 % de couverture encourage des tests qui exécutent du code sans rien vérifier. Fixez la gate sur la couverture du nouveau code et relisez les tests eux-mêmes.
• Des contrôles flaky dans la gate. Une gate qui échoue au hasard finit par être contournée. Ne gardez bloquants que les contrôles déterministes ; exécutez le reste en non bloquant, avec des alertes.
• Trop de gates, trop tard. Dix conditions vérifiées seulement avant la release produisent une pile d’échecs que personne n’a le temps de corriger. Placez les contrôles peu coûteux tôt, sur chaque pull request.
• Des contournements silencieux. Si une gate peut être ignorée, journalisez qui l’a contournée et pourquoi.