Guide sur les preuves de livraison

Quality gates fondées sur le risque dans le CI/CD

Une quality gate est un point de décision dans le flux de livraison. Une conception fondée sur le risque relie la gate au changement, aux preuves disponibles à ce stade et à l’action attendue lorsque les preuves sont incomplètes.

Publié:: 26 juillet 2026
Mis à jour:: 26 juillet 2026

Réponse directe

Une quality gate fondée sur le risque est une règle de livraison contextuelle, pas un score universel.

Elle précise la décision contrôlée, les changements concernés, les preuves requises, le traitement des preuves manquantes ou instables et la personne qui peut autoriser une exception.

Éléments à examiner

Définissez la décision avant la règle.

Précisez ce que la quality gate peut autoriser, bloquer ou soumettre à arbitrage, les changements auxquels elle s’applique et qui peut l’interpréter ou approuver une exception. La règle reste ainsi liée au contexte de livraison plutôt qu’à un score universel.

Contexte du changement: Les composants concernés, les dépendances, le type de changement et les risques pertinents pour la décision.
Seuil de preuve: Les contrôles et signaux requis à ce point, avec les conditions dans lesquelles ils restent valides.
Parcours d’exception: La manière de traiter les signaux manquants, instables ou indisponibles et de consigner la justification.
Responsabilité: Qui maintient la règle, examine le résultat et détient l’autorité de livraison.

Critères de décision

Une gate utile explicite cinq décisions.

Décision contrôlée: La gate indique si elle peut poursuivre, suspendre ou soumettre une décision de livraison à arbitrage.
Contexte du changement: La règle répond aux composants, dépendances, types de changement et risques concernés plutôt qu’à chaque changement de la même manière.
Validité du signal: Les contrôles requis ont des conditions définies de version, d’environnement, de données, de moment et d’actualité.
Parcours d’exception: Les preuves manquantes ou instables déclenchent une analyse désignée plutôt qu’un contournement silencieux.
Responsabilité: La maintenance de la règle, la revue, l’exception et la décision finale ont des responsables.

Checklist pratique

Examinez une gate avec cette checklist :

Nommez la décision de livraison contrôlée par la gate.
Définissez les contextes de changement qui activent la règle.
Listez les signaux requis et leurs conditions de validité.
Précisez le traitement des résultats manquants, anciens ou instables.
Attribuez la maintenance, la revue et l’autorité d’exception.
Consignez le résultat, la justification, l’incertitude et l’action suivante.

Comment les signaux se relient

Traitez la quality gate comme un élément du flux de preuves.

Les contrôles automatisés, l’état de l’environnement, les défauts connus, les approbations et l’incertitude résiduelle doivent suivre un chemin clair vers la gate. Celle-ci doit rendre visible le fondement de la décision, pas le masquer derrière un résultat accepté ou refusé.

Modes d’échec fréquents

Les quality gates échouent lorsque la règle perd son contexte.

Un seuil pour chaque changement: Un score universel ignore les différences de composants, dépendances, conséquences et preuves.
Un contournement sans dossier de décision: Le pipeline continue, mais la preuve manquante, le responsable, la justification et le suivi disparaissent.
Une gate verte mais obsolète: Le contrôle réussit alors que ses données, son environnement, sa version ou sa sélection de tests ne correspondent plus à la livraison.

Exemple illustratif

Une gate fictive sensible au changement

Scénario fictif · ne provient d’aucune mission client

Une livraison fictive modifie un parcours critique et une dépendance partagée. La gate s’applique parce que les deux figurent dans la limite de changement consignée.

Question de décision : la livraison peut-elle continuer avec les preuves actuelles ou le changement de dépendance exige-t-il un arbitrage ?

Signaux requis : contrôles automatisés ciblés, état de la dépendance, validité de l’environnement, revue des défauts connus et approbation assumée.

Un contrôle ciblé est instable. Son résultat n’est pas silencieusement compté comme réussi ; il reste une preuve non résolue.

Le responsable obtient une exécution valide ou consigne l’exception, sa justification, les preuves compensatoires et l’action de suivi.

Cette gate fictive illustre uniquement un modèle de décision. Ce n’est ni un pipeline client, ni un seuil universel, ni la preuve d’un résultat.

Limite des preuves

Une quality gate n’est pas une garantie.

Le passage d’une gate montre uniquement que ses conditions définies ont été satisfaites avec les preuves disponibles. Il n’établit pas l’absence de défauts et ne supprime pas le besoin de jugement et de responsabilité sur les exceptions.

Parcours associés

Examinez la gate dans son contexte de livraison.

Utilisez l’évaluation lorsque la décision, le seuil de preuve et les responsabilités doivent encore être définis ensemble.

Commencer par l’évaluation

Parcours associés

Présentation des services Vue d’ensemble des preuves de livraison Signaux d’automatisation des tests Explorer l’Intégration qualité CI/CD