Quality Gates : les six qui comptent, les douze qui vous ralentissent

La plupart des chaînes d’intégration que nous auditons contiennent entre douze et vingt contrôles bloquants. Presque toutes souffrent du même symptôme : les équipes ont appris des chemins de contournement.

Ce n’est pas un problème de discipline. C’est une conséquence prévisible de gates mal conçues.

Ce qui distingue une gate d’un péage

Une gate utile répond à trois conditions, simultanément :

1. Elle dit ce qui ne va pas. Pas « qualité insuffisante », mais « cette fonction a une complexité de 34, seuil à 15, ligne 212 ».
2. Elle dit comment sortir. Un message d’échec sans chemin de correction transforme un contrôle en obstacle.
3. Son échec signifie toujours la même chose. Une gate qui échoue une fois sur trois pour des raisons d’infrastructure n’est plus lue.

Une gate qui ne remplit pas ces trois conditions est un péage : elle prélève du temps sans produire d’information.

Les six qui comptent

1. La compilation et les types

Bloquante. Sans exception.

C’est la gate la moins discutée et la plus rentable. Un projet TypeScript en mode strict, ou un projet Java qui compile sans avertissement, élimine une classe entière de défauts avant même qu’un test ne s’exécute.

Coût : quelques secondes. Aucune raison de s’en priver.

2. Les tests unitaires

Bloquante, avec une exigence sur le temps : moins de deux minutes.

Au-delà, les développeurs cessent de les lancer en local et découvrent les échecs dans la chaîne — ce qui annule tout l’intérêt. Si votre suite unitaire dépasse deux minutes, le problème n’est pas la gate : ce sont des tests qui n’en sont pas. Un test unitaire qui touche une base de données ou le réseau est un test d’intégration mal rangé.

3. Les tests d’intégration sur les chemins critiques

Bloquante, sur un périmètre explicitement choisi.

Le mot important est choisi. Tout intégrer rend la gate lente et instable. Le bon périmètre est celui des invariants dont la violation serait un incident : autorisations, transactions, cohérence des données.

Chez nous, la suite qui vérifie la matrice d’autorisation — chaque rôle × chaque ressource × chaque opération — est la plus importante de tout le projet. Elle est aussi la moins spectaculaire.

4. Le balayage de secrets

Bloquante. Aucune dérogation possible.

Un secret versionné est compromis définitivement, même supprimé au commit suivant : l’historique Git le conserve, et les dépôts publics sont scrutés en continu.

Coût : quelques secondes. Gain : évite l’incident qu’on ne rattrape pas.

5. Les vulnérabilités de dépendances, en niveau élevé et critique

Bloquante sur high et critical. Informative en dessous.

Le choix du seuil est ce qui rend cette gate soutenable. Bloquer sur les vulnérabilités low produit un bruit tel que l’équipe finit par tout ignorer — y compris les critiques.

6. L’accessibilité automatisée

Bloquante sur les violations sérieuses et critiques.

Les outils automatiques ne détectent qu’environ un tiers des obstacles réels. Mais ce tiers est composé de régressions triviales à corriger sur le moment et coûteuses à rattraper six mois plus tard : contraste insuffisant, champ sans libellé, bouton sans nom accessible.

C’est une gate à installer tôt, quand la dette est nulle. L’installer sur un projet existant produit des centaines de violations et finit désactivée.

Les douze qui ralentissent

Le seuil de couverture global

« 80 % de couverture minimum » est la gate la plus répandue et la plus contre-productive.

Elle mesure les lignes exécutées, pas les comportements vérifiés. Un test sans assertion augmente la couverture. Une équipe sous pression écrit donc des tests qui exécutent du code sans rien vérifier — et le tableau de bord passe au vert.

Ce qu’on peut faire à la place : mesurer la couverture, l’afficher, ne pas en faire un critère de blocage global, et exiger une couverture sur les chemins critiques nommés. Ce n’est pas un pourcentage, c’est une liste.

Les tests de bout en bout complets à chaque commit

Une campagne de quarante minutes exécutée sur chaque proposition de modification produit deux effets : les développeurs ouvrent moins de propositions, et l’infrastructure coûte cher.

Un sous-ensemble de fumée à chaque commit, la campagne complète avant la mise en production : le compromis est presque toujours le bon.

La revue obligatoire par deux personnes

Sur une équipe de cinq, la deuxième revue est presque toujours une approbation de complaisance. Elle ajoute du délai et pas de qualité.

Les autres

• le respect d’un format de message de commit, bloquant ;
• l’interdiction de toute augmentation de la taille des lots JavaScript, sans arbitrage possible ;
• les avertissements de lint traités comme des erreurs sans distinction de gravité ;
• une gate de performance dont le seuil a été fixé une fois, sans jamais être réévalué ;
• l’analyse statique exécutée sur l’intégralité du dépôt à chaque commit, plutôt que sur le diff ;
• une gate de licences bloquante sans liste d’exceptions ;
• la génération de documentation bloquante ;
• un contrôle de nommage des branches ;
• une approbation manuelle à une étape où personne n’a d’information nouvelle à apporter.

Le test qui révèle une mauvaise gate

Posez la question suivante à trois personnes de l’équipe :

La dernière fois que cette gate a bloqué quelque chose, qu’est-ce que c’était ?

Si personne ne s’en souvient, la gate ne détecte rien. Si tout le monde répond « un faux positif », elle détruit de la confiance. Si quelqu’un répond « un bug qui serait parti en production », gardez-la.

Le chiffre qui compte

Ce n’est pas le nombre de gates. C’est le temps entre la soumission et le retour.

Au-delà de quinze minutes, les développeurs passent à autre chose, perdent le contexte, et reviennent une heure plus tard. Le coût de correction d’un défaut ne dépend pas de sa gravité : il dépend du temps écoulé depuis qu’on l’a écrit.

Six gates bien conçues qui rendent leur verdict en huit minutes protègent mieux que vingt gates qui mettent quarante minutes et qu’on apprend à contourner.