Liste de preuves après déploiement : quoi demander après une correction

Pourquoi vous devriez demander des preuves après qu’une correction soit en ligne

Après un déploiement, les corrections peuvent être difficiles à voir. L’application a la même apparence, le bug est difficile à reproduire, ou il n’apparaît que pour un compte spécifique ou à un moment précis. Donc quand vous entendez « c’est corrigé », vous restez à deviner : le changement a‑t‑il atteint la production, et a‑t‑il résolu le bon problème ?

Sauter l’étape des preuves, c’est approuver du travail qui n’a pas réellement atterri là où sont les utilisateurs. Une correction peut être mergée mais pas déployée, déployée dans le mauvais environnement, ou livrée mais masquée par du cache ou un feature flag. Parfois elle ne couvre qu’un cas, et le bug existe toujours dans un flux légèrement différent. Pour des zones à fort impact comme l’authentification, les paiements ou les correctifs de sécurité, cette incertitude peut coûter de l’argent, entamer la confiance ou créer un risque légal.

Une courte liste de preuves après déploiement enlève les suppositions sans ajouter de réunions. Elle transforme une mise à jour vague en un petit ensemble de reçus : ce qui a changé, où ça tourne, et comment cela a été vérifié. Avec cela en main, vous pouvez la parcourir rapidement, la transférer à un cofondateur et signer en toute confiance. Il ne s’agit pas de « surveiller les développeurs », mais de rendre le travail visible.

Vous avez le plus besoin de preuves quand :

• Le problème s’est produit en production (pas seulement en préproduction)
• La correction touche la connexion, les permissions ou les données de compte
• De l’argent est en jeu (checkout, abonnements, factures)
• La sécurité a été mentionnée (secrets exposés, risque d’injection)
• Des utilisateurs ont signalé le bug à plusieurs reprises ou vous avez promis un délai

Exemple : un développeur dit « la connexion est corrigée ». Une liste de preuves inclurait la version/build en production, l’heure du déploiement, et une capture d’écran ou un court enregistrement du flux précis qui échouait et qui fonctionne maintenant (plus un test négatif, par exemple un mot de passe incorrect).

Ce qu’est une “liste de preuves” (et ce que ce n’est pas)

Une liste de preuves est un petit ensemble d’éléments factuels qui prouvent qu’une correction a bien été déployée au bon endroit et qu’elle fonctionne comme attendu. C’est le minimum nécessaire pour faire confiance à un changement sans lire le code.

Une liste de preuves doit confirmer trois choses :

• Comportement : le bug a disparu
• Périmètre : ce qui a été touché (et ce qui ne l’a pas été)
• Temps : quand le changement a atteint l’environnement qui vous intéresse

Elle doit rester légère. Pour la plupart des corrections, 5 à 10 éléments suffisent, tant que chaque élément est précis et facile à vérifier. Elle doit aussi vivre là où vous suivez déjà le travail (le même ticket, fil d’e‑mail ou doc partagé) pour ne pas disparaître.

Une liste de preuves inclut généralement :

• Horodatage du déploiement et environnement (production vs préproduction)
• Les étapes exactes utilisées pour vérifier la correction (2 à 5 étapes, écrites simplement)
• Captures d’écran ou courts enregistrements montrant le comportement critique
• Un petit ensemble de logs clés, messages d’erreur ou instantanés de monitoring qui ont changé
• Notes sur l’impact (par exemple « seulement la connexion » vs « auth et facturation »)

Une liste de preuves n’est pas un remplacement du QA complet, et ce n’est pas un tas d’artefacts techniques incompréhensibles. Elle doit rendre le résultat plus clair.

Ce que ce n’est pas :

• Un message vague comme « corrigé » ou « déployé » sans preuve
• Un long plan de test que personne n’exécutera
• Un dump de code ou une liste de fichiers que vous ne pouvez pas valider
• Des notes de version écrites uniquement pour les développeurs
• Une promesse que « ça devrait aller » sans montrer les résultats

Exemple : si un développeur a corrigé un bug de checkout, la liste de preuves devrait montrer un achat test réussi (en production ou dans votre sandbox paiement), l’heure du déploiement, et l’erreur qui n’apparaît plus.

Que mettre dans une liste de preuves

Une liste de preuves après déploiement est un petit ensemble de reçus qui répondent à trois questions simples : qu’est‑ce qui a changé, où peut‑on le voir, et quand cela a changé. Si vous pouvez vérifier ces éléments rapidement, vous avez moins de chances d’approuver une correction qui n’a fonctionné que sur l’ordinateur de quelqu’un.

Restez concentré sur les preuves, pas sur une longue histoire. Une page suffit généralement.

L’essentiel (le kit « faire confiance mais vérifier »)

Demandez ceci à chaque fois, même pour de petites corrections :

• Ce qui a changé (en français simple) : une à trois phrases décrivant le changement de comportement. Exemple : « La connexion bloque désormais les utilisateurs inactifs et affiche un message clair. »
• Où le voir : l’environnement exact (production vs préproduction), le nom de l’écran, et le rôle utilisateur requis (admin, utilisateur normal, invité). Si un compte de test est nécessaire, indiquez lequel.
• Preuve du résultat : captures d’écran ou court enregistrement montrant les étapes clés et l’état final (message d’erreur, nouveau bouton, mise en page corrigée).
• Quand et qui a vérifié : heure du déploiement, heure du test, et nom de la personne qui a testé.
• Ce qui a été testé (bref) : happy path plus les cas limites importants (mot de passe erroné, session expirée, formulaire vide, réseau lent).

Quand c’est possible, incluez un simple « avant vs après ». Une capture avant et une après convainquent souvent plus qu’un paragraphe.

Bonus utiles (quand vous voulez des preuves plus solides)

Ils ne sont pas toujours nécessaires, mais comptent quand la correction touche la sécurité, les paiements ou les données :

• Identifiant commit/build : un hash de commit ou numéro de build qui relie la preuve à la version déployée.
• Log ou note de monitoring : une capture montrant que l’erreur a cessé, ou une métrique revenue à la normale.
• Note de rollback : une phrase expliquant comment annuler le changement si un nouveau problème apparaît.

Si vous héritez de code produit par l’IA, demandez la liste de preuves plus une courte note sur ce qui a été nettoyé (par exemple : « secret exposé supprimé, validation côté serveur ajoutée »).

Comment la demander (pas à pas)

Commencez par des critères d’acceptation en une phrase. Restez clair et testable, par exemple : « Les utilisateurs peuvent se connecter avec email et mot de passe, et restent connectés après rafraîchissement. » Cela donne au développeur une cible claire et vous quelque chose à vérifier sans supposer.

Ensuite, demandez une liste de preuves après déploiement qui corresponde à chaque critère d’acceptation. Évitez un simple « Corrigé et déployé ». Vous voulez des preuves par item, car une partie peut sembler correcte alors qu’une autre est encore cassée.

Une demande simple à envoyer

Vous pouvez demander sans paraître technique :

• Partagez les critères d’acceptation (une phrase, plus les cas limites qui vous importent).
• Demandez une preuve par item (numérotée, pour que vous puissiez répondre à l’item 3 si c’est flou).
• Demandez à la fois : la preuve et les étapes exactes de vérification (pour que vous puissiez répéter la vérif plus tard).
• Spécifiez l’environnement et le niveau d’accès (production vs préproduction, admin vs utilisateur normal, compte de test vs compte réel).
• Fixez un format et un délai (ex. : « 10 courts points d’ici la fin de la journée, chacun avec preuve horodatée »).

Précisez aussi ce qui compte comme preuve. « Les captures d’écran conviennent, mais incluez l’heure et le compte utilisé. » Si la correction est purement backend, une capture d’écran peut montrer peu. Dans ce cas, demandez l’effet visible par l’utilisateur (un checkout réussi, un email reçu, une métrique de dashboard mise à jour).

Réduisez l’ambiguïté en choisissant l’environnement exact. « Déployé en préproduction » peut sembler rassurant alors que la production reste cassée. Si vous avez besoin d’une correction en production, dites‑le.

Format de preuve suggéré (facile à scanner)

Demandez‑leur d’utiliser le même mini‑template pour chaque item : ce qui a changé, où cela a été testé, étapes exactes, preuve (capture ou court enregistrement), et horodatage.

Si les corrections semblent risquées, demandez une brève note « avant vs après » pour une revue rapide.

Questions à poser selon le type de correction

La liste de preuves doit varier suivant ce qui a été corrigé. Si vous posez toujours les mêmes questions, vous manquerez le détail important (comme un bug UI qui n’apparaît que sur un navigateur, ou un bug API lié à une requête précise).

Utilisez ces invites pour obtenir des preuves que vous pouvez contrôler en quelques minutes.

Questions par type de correction

• Bug UI (visuel ou flux de clic) : « Pouvez‑vous montrer une capture avant/après de l’écran exact, plus le navigateur et l’appareil utilisés ? » Demandez aussi : « Quelles étapes avez‑vous suivies pour reproduire le bug, et quelles étapes montrent maintenant qu’il est corrigé ? » Si le bug est intermittent, demandez un court enregistrement.

• Bug backend (API, base de données, erreur serveur) : « Quelle requête exacte échouait, et quelle réponse obtient‑on maintenant ? » Demandez un exemple réel avec horodatage et environnement. S’il y avait un code d’erreur : « Quel code avions‑nous avant, et quel code avons‑nous maintenant ? »

• Correction d’authentification / permissions : « Quels comptes de test avez‑vous utilisés, et quels rôles ont‑ils ? » Ensuite, demandez les cas limites : « Avez‑vous testé la connexion, la déconnexion, les sessions expirées et un utilisateur qui ne devrait pas avoir accès ? » Si des tokens ou cookies étaient impliqués : « Qu’est‑ce qui a changé pour empêcher l’échec précédent ? »

• Correction de sécurité (vulnérabilité) : « Qu’est‑ce qui était vulnérable en termes simples, et ce qu’un attaquant pouvait faire ? » Poursuivez par : « Qu’est‑ce qui a été changé pour le bloquer ? » et « Comment avez‑vous validé la correction ? » (tentative de test qui échoue désormais, résultat d’un scan, ou note d’examen de code). Si des secrets ont été exposés : « Les clés ont‑elles été remplacées, et comment sait‑on que les anciennes ne fonctionnent plus ? »

• Correction de performance (pages lentes, timeouts) : « Quelle métrique s’est améliorée, et où a‑t‑on mesuré cela ? » Demandez des chiffres avant/après et la période. Demandez aussi : « Le test a‑t‑il été fait sur des données et un trafic proches de la production, ou sur un petit échantillon ? »

Si vous traitez du code généré par l’IA, les corrections de sécurité méritent des preuves supplémentaires car de petits changements peuvent cacher de gros risques.

Après avoir reçu la preuve, vérifiez une chose vous‑même (un écran, un compte, un flux). Cette vérification rapide attrape souvent les malentendus avant qu’ils ne deviennent un nouveau problème en production.

Comment réviser la preuve rapidement (sans être très technique)

Considérez la liste de preuves comme un contrôle rapide de confiance, pas comme un audit complet. Votre but est de confirmer que la correction est réelle, qu’elle est dans le bon environnement, et qu’elle correspond à ce que vous avez demandé.

Commencez par l’item à risque le plus élevé et limitez‑vous à cinq minutes. Si le risque est « les utilisateurs ne peuvent pas se connecter » ou « les paiements échouent », vérifiez cela en priorité.

Flux de revue en 5 minutes

Lisez la preuve une fois, puis faites une vérification ciblée :

• Identifiez l’action utilisateur la plus importante (connexion, checkout, réinitialisation de mot de passe).
• Confirmez le périmètre en termes simples : ce qui a changé et ce qui n’a pas été touché.
• Vérifiez les horodatages par rapport à la fenêtre de déploiement prévue.
• Testez avec la même configuration que vos utilisateurs : type d’appareil, rôle de compte et environnement.
• Posez une question de suivi : « Que dois‑je surveiller dans les prochaines 24 heures ? » Une bonne réponse nomme un ou deux signaux, par ex. pic d’erreurs ou tickets de support sur un écran précis.

Faites ensuite un contrôle rapide des frontières. Vous n’avez pas besoin de comprendre le code, mais vous devez comprendre ce que le changement n’a pas touché. Une liste de preuves claire permet de dire : « Cela a touché la connexion, les sessions et les redirections, pas l’inscription, pas la facturation. »

Signes rapides qu’il y a un problème

Des signaux d’alerte qui méritent un suivi :

• La preuve est uniquement des mots comme « corrigé » sans captures, logs ou horodatages.
• Les preuves proviennent de la préproduction alors que vous avez demandé la production.
• Les captures d’écran évitent l’étape qui échouait (elles montrent la page d’accueil, pas le formulaire qui plantait).
• Les étapes utilisent un compte admin alors que la majorité des utilisateurs sont des comptes standards.

Exemple : pour une correction de connexion, demandez une capture d’écran d’une tentative de connexion réelle avec un utilisateur normal, l’horodatage du déploiement, et une courte note sur ce qui a changé (par ex. « paramètres cookie mis à jour » ou « boucle de redirection supprimée »).

Checklist rapide à copier et utiliser à chaque fois

Quand une correction est déployée, demandez une courte liste de preuves. Elle doit être rapide à lire, facile à répéter, et suffisamment précise pour que vous puissiez la vérifier en quelques minutes.

Utilisez cette checklist par défaut :

• Pour chaque item de preuve : environnement (prod ou préprod), étapes exactes, preuve (capture ou court clip), et horodatage.
• La preuve correspond à la revendication : elle montre l’écran exact, le type de compte et l’état lié au bug original (pas une page générique « ça marche »).
• Vous pouvez la reproduire : les étapes sont écrites pour qu’une personne non technique puisse les suivre et obtenir le même résultat.
• Les changements de config sont listés : variables d’environnement, feature flags, permissions ou réglages tiers changés sont nommés (et où ils ont été modifiés).
• Un plan de risque est inclus : si la correction touche l’auth, les paiements ou les données, incluez une note de rollback ou d’atténuation.

Si vous voulez un modèle prêt à coller, envoyez ceci :

Proof list request
1) Issue/Change:
2) Environment: production / staging
3) Location: page/feature + account used
4) Steps to verify:
5) Evidence: screenshot/clip + timestamp:
6) Related config changes (if any):
7) Rollback/mitigation (if high risk):

Si quelque chose vous paraît vague, insistez sur la pièce manquante. La plupart du temps, ce sont soit les étapes, soit la preuve qui manquent.

Pièges courants et comment les éviter

Le plus grand risque après un déploiement est de penser qu’une chose est corrigée parce que vous avez vu « quelque chose » changer. La preuve ne fonctionne que lorsqu’elle est précise et liée au problème réel.

Piège 1 : Une capture d’écran sans étapes

Une capture d’écran unique peut être réelle et néanmoins insignifiante. Elle peut montrer une page mise en cache, une course chanceuse, ou un flux différent de celui qui échouait.

Évitez‑le en demandant les étapes exactes suivies, les données utilisées (compte test ou enregistrement exemple), et un horodatage. Encore mieux : un court enregistrement du début à la fin.

Piège 2 : Preuve du mauvais environnement

Les gens testent en préproduction, puis annoncent que la correction est en ligne.

Évitez‑le en exigeant que l’environnement soit indiqué en clair et en incluant un horodatage de production. Si votre appli affiche un label de version en pied de page ou dans l’admin, demandez‑le inclus.

Piège 3 : Corrections d’auth qui ignorent les rôles et permissions

Les bugs de connexion fonctionnent souvent « pour moi » parce que le développeur a testé avec un compte admin.

Évitez‑le en demandant quel rôle utilisateur a été utilisé pour chaque test et quelles permissions ce rôle possède. Si votre appli a admin, membre et guest, obtenez des preuves pour chaque flux pertinent.

Piège 4 : Cas limites manquants

Beaucoup de bugs se cachent dans les entrées mauvaises et les états vides, pas dans le flux normal.

Évitez‑le en demandant des preuves pour quelques cas limites : champs vides, mot de passe erroné, session expirée, et un utilisateur sans données.

Piège 5 : Preuve d’un symptôme, pas de la cause

Parfois l’UI a l’air correcte, mais le problème sous‑jacent est toujours présent et reviendra.

Évitez‑le en demandant une courte note « ce qui a changé et pourquoi » plus une preuve que l’échec original a disparu (par ex. un extrait de log avant/après).

Si vous voulez une demande standard simple, exigez :

• Environnement (production ou préproduction) et horodatage
• Étapes de reproduction testées (les mêmes que pour le bug original)
• Comptes et rôles utilisés (surtout pour l’auth)
• Cas limites testés (2 à 3 réalistes)
• Une courte note sur la cause racine et le changement exact apporté

Exemple : valider une correction de connexion déployée dans un vrai projet

Cas réaliste : votre appli a été générée par un outil IA, une mise à jour rapide est sortie, et maintenant certains utilisateurs ne peuvent plus se connecter. Ça marche pour vous, mais quelques clients voient une erreur ou restent bloqués.

Vous demandez une liste de preuves après déploiement pour savoir ce qui a changé et qui cela aide. Vous n’avez pas besoin d’un long rapport. Vous avez besoin d’une preuve en adéquation avec le risque : rôles, appareils et l’échec exact observé.

Preuve minimale à demander :

• L’identifiant build/release en production, plus l’heure du déploiement.
• Une capture d’écran d’une connexion réussie en tant qu’utilisateur normal, incluant l’écran d’atterrissage.
• Une capture d’écran d’une connexion réussie en tant qu’admin ou staff, incluant une page réservée aux permissions.
• Une capture d’un second type d’appareil (ex. Safari sur iPhone et Chrome sur Windows).
• Une preuve que l’erreur originale a disparu : capture des logs ou du tracking d’erreurs filtré sur les 30–60 dernières minutes.

Demandez aussi une courte liste numérotée : les étapes qui échouaient avant, et les mêmes étapes maintenant réussies, avec horodatages.

Comment décider :

• Passé : rôles et appareils fonctionnent, et le taux d’erreur baisse.
• Partiellement passé : ça marche pour un rôle ou un appareil seulement ; demandez une preuve ciblée supplémentaire.
• Demande de rollback : l’erreur persiste en production, ou un nouveau problème de connexion apparaît.

Étapes suivantes si vous n’êtes toujours pas rassuré

Si vous lisez la liste de preuves et que vous restez mal à l’aise, ne l’ignorez pas. Le plus souvent, soit la preuve est trop fine, soit la correction est correcte mais le périmètre de risque n’est pas couvert (cas limites, sécurité, monitoring, rollback).

D’abord, conservez ce que vous avez reçu. Gardez la liste de preuves avec vos notes de release, même si elle est incomplète. Des semaines plus tard, quand quelque chose casse à nouveau, ce document devient le moyen le plus rapide de répondre à ce qui a changé, quand, et ce qui a été vraiment vérifié.

Plan d’action simple :

• Écrivez en clair ce qui reste incertain.
• Demandez 1 à 2 éléments de preuve manquants qui régleraient le doute.
• Demandez un retest du chemin risqué, pas un « ça a l’air bon » général.
• Convenez d’un plan de rollback si le changement est à haut risque.
• Fixez un moment de suivi pour revoir les métriques et les tickets support.

Rendez‑le répétable. Si vous remarquez que vous demandez toujours les mêmes preuves, transformez‑les en template standard.

Quand escalader vers une revue indépendante

Si la correction touche du code généré par l’IA et que ça casse sans cesse, c’est souvent un problème de base de code, pas un seul bug. Les prototypes générés par l’IA peuvent cacher des problèmes comme une logique emmêlée, des secrets exposés, une authentification fragile, des requêtes non sécurisées, et des patterns non scalables. Vous pouvez corriger des symptômes pendant des semaines sans résoudre la cause.

Dans ce cas, une revue indépendante peut être le chemin le plus rapide pour retrouver la confiance. FixMyMess propose des audits gratuits pour identifier ce qui est cassé, puis répare la logique, durcit la sécurité, refactorise les zones en désordre et prépare des déploiements avec vérification humaine.

Si vous voulez une action claire : rassemblez les preuves que vous avez déjà, notez ce qui reste incertain, et décidez si vous avez besoin d’une remise en état plus profonde (pas seulement un autre patch).