Un pipeline au vert répond à une question précise : les vérifications configurées ont réussi dans les conditions de leur exécution. Il ne démontre pas que les bonnes vérifications existent, qu’elles portaient sur la version à livrer ou que l’équipe peut rétablir le service si le changement se comporte autrement en production.
Une revue utile rend ces limites explicites. Elle aboutit à une décision portée par une personne responsable, appuyée par des preuves et accompagnée d’un relevé des risques résiduels. La grille proposée ici structure cette discussion. Elle ne constitue ni une certification ni un remplacement du jugement d’ingénierie.
Définir d’abord le périmètre de la livraison
Avant d’attribuer des cotes, décrivez ce qui change. Précisez l’artefact ou le commit, les services touchés, les changements de configuration, les migrations de schéma, la stratégie de déploiement et les parcours clients concernés. Le résultat d’un test sur l’application d’hier ne s’applique pas nécessairement à la version d’aujourd’hui.
Retenez un petit ensemble de parcours critiques. Il s’agit des comportements dont l’échec rendrait la livraison inacceptable, et non simplement des parcours qui comptent le plus de tests automatisés. Selon le produit, examinez l’accès aux comptes, les permissions, les transactions importantes, l’intégrité des données et la gestion des défaillances d’intégration.
Pour chaque parcours, désignez une personne responsable et les preuves disponibles. Ces preuves peuvent provenir de tests automatisés, d’observations exploratoires, de vérifications de contrat, d’une répétition de migration ou d’un exercice de rétablissement. La méthode doit correspondre à l’incertitude à résoudre.
Examiner huit domaines de preuve
Utilisez la grille interactive de préparation à la mise en production pendant la revue. Chaque domaine pose une question distincte.
- Exigences et parcours critiques : le comportement attendu est-il clair, y compris les refus, les délais d’attente et les permissions? Une implémentation conforme à une exigence ambiguë reste risquée.
- Couverture fondée sur les risques : les risques importants sont-ils reliés à des tests ou à une investigation? Distinguez ce qui est démontré de ce qui est supposé couvert.
- Fiabilité de l’automatisation : les échecs sont-ils reproductibles, les données isolées et les assertions pertinentes? Une réussite après reprise n’équivaut pas à une réussite à la première exécution.
- Gestion des tests instables : chaque test en quarantaine a-t-il un responsable, une date de révision et une preuve de remplacement?
- Signaux CI/CD : les contrôles pertinents ont-ils porté sur l’artefact réellement destiné à la production? Les résultats et les exceptions sont-ils compréhensibles?
- Anomalies et responsabilité de la décision : qui peut accepter un risque connu? La gravité tient-elle compte des conséquences pour les clients et des mesures d’atténuation?
- Observabilité en production : comment détecter un effet négatif pour les utilisateurs et qui interviendra? Une alerte sans réponse définie est un contrôle incomplet.
- Retour arrière et incidents : quels changements sont réversibles, lesquels nécessitent une correction vers l’avant et quelles données exigent une procédure distincte?
Les conseils de Google sur la surveillance des systèmes offrent un vocabulaire utile autour de la latence, du trafic, des erreurs et de la saturation. Reliez ces signaux aux comportements touchés par la livraison : des indicateurs globaux satisfaisants peuvent masquer un parcours client défaillant.
Rendre les inconnues visibles
Attribuez une cote de 0 à 3 à chaque domaine. Choisissez 0 lorsque les preuves sont absentes ou la situation inconnue; 1 lorsque les preuves sont partielles et les lacunes importantes; 2 lorsque les preuves sont à jour et les responsables des lacunes désignés; 3 lorsque les preuves couvrent aussi les scénarios d’échec et de rétablissement pertinents.
La grille donne un résultat rouge dès qu’un domaine reçoit 0. Le résultat est jaune si un domaine reçoit 1 ou si le total est inférieur à 20 sur 24. Le vert exige au moins 2 partout et un total d’au moins 20. Ces seuils structurent la discussion; ils ne correspondent pas à des probabilités de risque validées. La décision doit tenir compte du produit, du changement et des conséquences d’un échec.
Ne laissez pas le calcul effacer un obstacle critique. Une interface bien testée ne compense pas une migration destructive non vérifiée. S’il manque un contrôle essentiel, réduisez le périmètre, obtenez les preuves, adaptez le déploiement ou reportez le changement concerné. Consignez la raison plutôt que de modifier une cote pour justifier la décision souhaitée.
Exemple : un changement de forfait d’abonnement
Prenons un exemple fictif : une livraison SaaS modifie le passage à un forfait supérieur. Les tests UI et API du parcours nominal réussissent. Le changement touche aussi le traitement des notifications de paiement et un cache de droits d’accès.
Que se passe-t-il si la notification de paiement est reçue deux fois, arrive en retard ou n’arrive jamais? Un client peut-il accéder aux droits d’un autre locataire? Un échec laisse-t-il la facturation et les accès dans des états incompatibles? Le retour arrière rétablit-il le code tout en laissant des données incompatibles?
Les preuves pertinentes pourraient combiner des tests d’intégration API, des vérifications d’idempotence, une séance exploratoire ciblée et une répétition contrôlée du rétablissement. Ajouter des tests de navigateur sur le même parcours nominal ne résoudrait pas toutes ces questions.
La revue peut révéler une lacune dans la récupération d’une notification manquante et désigner un responsable pour la vérifier avant le déploiement. C’est un résultat utile, même si le pipeline était déjà au vert : une décision jusque-là implicite devient visible.
Conserver une trace courte de la décision
Consignez la version candidate, les liens vers les preuves, les risques non résolus, les mesures d’atténuation, le responsable et les conditions de pause ou de retour arrière. Précisez qui observe la production et pendant quelle période les contrôles propres à la livraison sont nécessaires. Une tâche planifiée, par exemple, peut ne pas s’exécuter immédiatement après le déploiement.
Il n’est pas nécessaire que chaque partie prenante examine chaque test. Chaque responsable de preuve doit résumer le résultat pertinent et ses limites. La personne qui décide a besoin d’une vue cohérente des risques, pas d’un dossier volumineux de captures d’écran sans explication.
Après la livraison, comparez les hypothèses de la décision aux observations réelles. Si un défaut révèle une frontière non testée, actualisez la carte des risques et les questions de revue. Si une approbation obligatoire n’influence jamais la décision, examinez sa valeur réelle.
L’objectif est une discussion reproductible qui soutient des décisions proportionnées. Si les liens entre parcours critiques, tests fiables, responsabilités et rétablissement restent flous, une évaluation de l’ingénierie de la qualité peut déterminer lesquels établir en priorité.