Définition du «terminé» pour les corrections de bugs : checklist pratique

Ce que «terminé» signifie pour une correction de bug (en termes simples)

Un bug n'est pas terminé parce que le code compile, ou parce qu'il fonctionne sur un seul ordinateur. «Ça marche sur ma machine» signifie souvent que le test était trop limité, que la configuration était différente, ou qu'un cas limite a été oublié. Les vrais utilisateurs n'ont pas exactement votre navigateur, vos données, votre réseau ou vos permissions.

Clore un ticket trop tôt transforme de petits problèmes en plus gros : augmentation des tickets support, perte de confiance des collègues envers les releases, et accumulation de correctifs rapides sur des correctifs rapides. Le coût réel n'est souvent pas le bug initial, mais le temps passé à réapprendre le même problème et à nettoyer le bazar.

Pour une correction de bug, «terminé» devrait signifier quatre choses : vérifié, sûr, observable et explicable.

• Vérifié : vous pouvez reproduire le bug de façon fiable, et vous pouvez montrer de façon fiable qu'il a disparu.
• Sûr : vous avez pris en compte la perte de données, la sécurité et les effets de bord non voulus.
• Observable : vous savez quoi surveiller après la mise en production et ce qui justifierait un rollback.
• Explicable : quelqu'un d'autre peut lire le ticket et comprendre ce qui s'est passé, ce qui a changé et pourquoi.

Un exemple simple : le total du panier est faux uniquement pour les utilisateurs récurrents avec d'anciens coupons. Si vous ne testez qu'avec un compte neuf, vous n'avez rien corrigé pour les personnes réellement affectées.

Avant de toucher au code : confirmez le bug et son impact

Beaucoup de «corrections rapides» échouent parce que l'équipe corrige la mauvaise chose. Séparez ce que l'utilisateur voit (le symptôme) de ce que vous pensez être cassé (la cause). Le symptôme est un fait. La cause est une supposition tant que vous ne l'avez pas prouvée.

Notez l'impact avant d'ouvrir votre éditeur. Si ce bug survient une fois par mois chez un utilisateur, vous le traitez différemment d'un bug qui bloque les inscriptions aujourd'hui. La gravité n'est pas «à quel point ça sonne mal», c'est combien de personnes sont affectées, à quelle fréquence, et ce qu'elles ne peuvent pas faire.

Capturez le contexte exact. Beaucoup de bugs existent uniquement dans un environnement précis : une version de navigateur, un appareil mobile, une base de staging ou une nouvelle release. Si vous ne pouvez pas nommer où ça arrive, vous ne pouvez pas dire avec confiance que c'est corrigé.

Une petite checklist pré-code à coller dans un ticket :

• Symptôme : ce que l'utilisateur voit, avec ses mots
• Portée : qui est affecté et à quelle fréquence
• Environnement : version de l'app, appareil, navigateur/OS et type de compte
• Comportement attendu : ce qui devrait se produire à la place
• Énoncé du problème en une phrase : «Quand X, Y se produit, mais Z devrait se produire.»

Exemple : un fondateur dit «la connexion est cassée». Vous le reproduisez et découvrez que cela échoue uniquement sur Safari après une réinitialisation de mot de passe. Le travail change. Vous ne «corrigez pas la connexion», vous corrigez un flux spécifique de session ou de cookies.

Étapes de reproduction qui reproduisent vraiment (un modèle simple)

Un rapport de bug n'est utile que si quelqu'un d'autre peut provoquer le bug. Si vos étapes de repro fonctionnent uniquement pour la personne qui l'a trouvé, c'est difficile à corriger et encore plus difficile à confirmer.

Rédigez les étapes comme si un nouveau coéquipier devait les suivre sans poser de questions. L'important est l'état de départ : qui est l'utilisateur, quelles données existent et quel environnement vous avez utilisé.

Un modèle simple pour les repros

Utilisez ce modèle et remplissez-le avec des détails réels (pas des placeholders) :

Title: <short, specific>
Environment: <prod/staging/local>, <browser/app version>, <device>
Starting state: <logged in/out>, <account role>, <sample record id>, <feature flags>
Steps to reproduce:
1) ...
2) ...
3) ...
Expected result: ...
Actual result: ...
Evidence: <error message>, <log snippet>, <screenshot description>
Frequency: <always / 3 out of 10>, Triggers: <only after refresh, only on slow network>

Quand c'est possible, incluez le texte d'erreur exact. «La connexion échoue» est vague, mais «400: invalid_grant after password reset» donne un vrai indice au réparateur.

Si le problème est intermittent, dites-le et décrivez ce qui semble le déclencher. Mentionnez le timing, le type d'appareil, les extensions de navigateur ou tout changement récent (nouvel utilisateur, données importées, changement d'offre).

Faites un contrôle rapide en donnant vos étapes à quelqu'un d'autre. S'il ne peut pas reproduire en 5 minutes, le rapport a besoin d'une passe supplémentaire.

Critères d'acceptation : comment savoir que c'est corrigé

Les critères d'acceptation répondent à : «Que doit-il se passer après le déploiement ?» Pour les corrections de bugs, ils transforment «je pense que c'est corrigé» en «nous pouvons prouver que c'est corrigé.»

Décrivez ce à quoi ressemble le «bon» en termes simples et testables. Reliez-le au résultat utilisateur, pas à l'implémentation. Exemple : «L'utilisateur peut se connecter avec un mot de passe correct et arrive sur le tableau de bord en moins de 2 secondes.»

Puis listez les cas limites souvent oubliés : états vides, timeouts, mauvaises entrées, réessais et échecs partiels.

Une checklist simple à copier :

• Le chemin principal fonctionne de bout en bout
• Les cas limites connus sont gérés (entrée vide, valeurs invalides, réseau lent, retry)
• Pas de nouvelles erreurs dans les logs et pas de nouveaux avertissements dans l'UI pour le même flux
• Le comportement de l'UI est clair (messages, états des boutons, indicateurs de chargement, redirections)
• Les données restent correctes (pas de doublons, pas d'écritures partielles, pas de suppressions inattendues)

Ajoutez des non-objectifs pour éviter l'élargissement du périmètre. Exemple : «Nous ne changeons pas la politique de mot de passe dans cette correction» ou «Nous ne redesignons pas la page de login, seulement le traitement des erreurs.»

Si la correction change du texte ou du comportement, notez-le. «Mauvais mot de passe» vs «Email introuvable» n'est pas qu'une question de formulation. Ça peut impacter le support et le risque sécurité.

Si possible, obtenez un accord rapide du demandeur. Une confirmation de 2 minutes évite une journée de retouches.

Un workflow pas-à-pas pour clore un bug en toute sécurité

Bien clore un ticket, c'est moins à propos du changement de code que de prouver que le bug a disparu sans en créer un nouveau.

1. Reproduire et capturer des preuves. Capture d'écran, texte d'erreur exact et environnement (version de l'app, navigateur/appareil, rôle utilisateur, état des feature flags). Si vous ne pouvez pas reproduire, resserrez le rapport avant de deviner.

2. Isoler la plus petite cause probable. Trouvez la condition qui fait basculer le comportement (une saisie, un état de compte, une réponse d'API). Cela évite des corrections qui «marchent» par accident.

3. Faire le plus petit changement sûr. Évitez les refactorings pendant une correction, sauf si le désordre en est la cause. Les petits changements sont plus faciles à relire, tester et rollbacker.

4. Vérifier à deux endroits. Tester localement, puis dans un environnement propre qui ressemble le plus possible à la production.

Une checklist rapide pour la fermeture du ticket :

• Repro confirmée et preuves sauvegardées
• Cause racine énoncée en une phrase
• Changement minimal effectué (et pourquoi c'est sûr)
• Vérifié localement et dans un environnement propre
• Notes ajoutées : ce qui a changé, ce qui n'a pas changé, et les zones à risque

Enfin, ajoutez des notes de rollout et de monitoring : comment déployer en sécurité, quelles métriques ou logs devraient s'améliorer, et ce qui justifierait un rollback (par exemple, une hausse des erreurs 500 ou des échecs de connexion dans l'heure qui suit).

Tests : quoi ajouter, quoi relancer, quoi documenter

Un bug n'est vraiment terminé que lorsque les tests disent la même histoire que vos étapes de repro. Essayez de laisser au moins une vérification automatisée qui aurait échoué avant la correction et qui passe maintenant.

Ajoutez ou mettez à jour un test qui correspond à la défaillance réelle. Gardez-le petit et ciblé pour qu'il reste lisible et non intermittent. Couvrez le chemin heureux, puis ajoutez un cas limite qui représente comment le bug est passé (champ manquant, problème de timing, cache obsolète, paramètre utilisateur rare).

Après que votre test ciblé passe, faites une courte passe de régression autour des flux proches que vous avez pu toucher :

• Le parcours utilisateur principal qui inclut le code modifié
• Un flux adjacent (par exemple, inscription si vous avez corrigé la connexion)
• Un contrôle basique des permissions (autorisé vs non autorisé)
• Pour les corrections UI : vérifier sur deux navigateurs/appareils pris en charge
• Pour les corrections backend : tester une entrée invalide qui doit échouer proprement

Documentez ce que vous avez exécuté et ce que vous n'avez pas fait. Si vous acceptez un manque de test, nommez-le et expliquez pourquoi (temps, outil, fixture manquante, exigences floues), plus ce qui pourrait le détecter plus tard (alerte de monitoring, tâche de suivi, checklist manuelle).

Exemple : si une correction de connexion impliquait le parsing du token, ajoutez un test pour un token valide et un autre pour un token malformé qui doit retourner une erreur propre sans enregistrer de secrets.

Vérifications de sécurité : risques sur les données à écarter

Un bug peut être «corrigé» et créer un problème plus grave : fuite de données, contournement de permissions ou logs contenant des informations privées. C'est la partie que les gens zappent quand ils sont pressés.

Passez en revue ce qui a changé autour des entrées, de l'auth et de tout ce qui touche la base de données. Beaucoup d'incidents viennent de petites modifications comme «ajouter juste un paramètre» ou «logguer plus de détails pour le debug».

Avant de marquer le ticket comme fait :

• Secrets : confirmez qu'aucune clé API, token ou identifiant n'a été ajouté au code, à la config, aux messages d'erreur ou aux bundles côté client.
• Traitement des entrées : validez et nettoyez les entrées, surtout celles utilisées dans des requêtes, filtres ou tris. Utilisez des patterns de requêtes sûrs pour éviter les injections SQL.
• Auth et permissions : revérifiez que le chemin corrigé applique toujours la connexion et les vérifications de rôle (et que le traitement des erreurs ne les contourne pas).
• Logging : assurez-vous que les logs n'incluent pas de mots de passe, tokens de session, liens de réinitialisation ou données personnelles. Si vous avez besoin de contexte, logguez un ID, pas la valeur brute.
• Cas d'abus : si un endpoint ou flux a changé, pensez aux limites de débit et aux tentatives par force brute (connexion, réinitialisation, codes promo, OTP).

Un exemple concret : vous corrigez un bug de connexion en changeant la réponse d'erreur pour inclure des «détails utiles» (comme savoir si un email existe). Cela peut permettre l'énumération de comptes. Préférez un message générique et gardez les détails en interne.

Posez quelques questions finales avant de clore :

• Ce changement peut-il exposer des données au mauvais utilisateur ?
• Facilite-t-il la découverte de comptes, tokens ou mots de passe ?
• Les nouveaux logs peuvent-ils divulguer des informations sensibles ?
• Un bot peut-il frapper cet endpoint plus vite qu'un humain ?

Notes de déploiement : quoi écrire pour que les releases ne surprennent personne

Les notes de déploiement sont l'alerte qui transforme un changement de code en une release sûre. Elles permettent à quelqu'un qui n'a pas travaillé sur le bug de comprendre ce qui a changé, comment ça se déploie, et que faire si quelque chose cloche.

Commencez par un court résumé pour des lecteurs non techniques : ce qui était cassé, ce que les utilisateurs verront maintenant et qui est affecté. Si le bug touche la facturation, la connexion ou les permissions, dites-le clairement.

Puis capturez les points de risque au moment du déploiement :

• Changements de config (nouvelle variable d'environnement, valeur modifiée, rotation de secret)
• Migrations BD (ce qui s'exécute, durée potentielle)
• Feature flags (nom, état par défaut, qui peut basculer)
• Plan de rollout (tout d'un coup, canary, progressif par % ou région)
• Plan de rollback (quoi revenir et comment vérifier)

Soyez précis sur les déclencheurs de rollback. «Rollback maintenant» doit signifier quelque chose d'observable, comme une hausse des échecs de connexion, une montée des tickets support ou une erreur claire dans les logs. Notez si le rollback est sûr en présence de migrations (certaines modifications de schéma ne sont pas facilement réversibles).

Listez aussi les changements visibles pour les clients, même mineurs : textes UI, e-mails, notifications ou messages d'erreur. Les équipes support s'appuient sur ces informations.

Exemple : «Correction de la gestion de session pour les utilisateurs legacy sur Safari. Pas de changements BD. Ajout d'une nouvelle variable d'env pour le timeout du fournisseur d'e-mails. Rollout : 10 % pendant 30 minutes, puis 100 % si le taux de réussite des connexions reste normal. Rollback si les erreurs de connexion dépassent le niveau de base.»

Après le déploiement : quoi surveiller et combien de temps

Un bug n'est pas terminé lorsque le code est mergé. Il est terminé lorsque le changement se comporte dans le monde réel, sous le trafic réel.

Définissez une fenêtre de surveillance pour chaque release. Pour les corrections peu risquées, 2 à 4 heures peuvent suffire. Pour tout ce qui touche l'auth, les paiements ou les données, prévoyez 24 à 72 heures. Nommez un propriétaire pour la fenêtre (pas «l'équipe»), et assurez-vous qu'il puisse rollbacker ou corriger rapidement si nécessaire.

Concentrez-vous sur les signaux qui montrent la douleur client rapidement :

• Taux d'erreur et principales nouvelles erreurs (par endpoint ou écran)
• Latence et timeouts (le p95 est souvent plus révélateur que la moyenne)
• Échecs de connexion et échecs de réinitialisation de mot de passe
• Échecs de paiement et abandons de checkout
• Tickets support et plaintes utilisateurs (ils comptent comme monitoring)

Définissez des seuils qui déclenchent une action avant le déploiement, pour éviter les débats après coup. Exemples : «échecs de connexion x2 pendant 10 minutes» ou «une nouvelle erreur parmi les 5 premières». Associez les alertes à une réponse simple : investiguer, rollback ou mettre la distribution en pause.

Surveillez aussi les changements discrets mais dangereux : moins de connexions complétées, moins de projets créés, plus de réessais. Cela peut signifier que le bug a été déplacé plutôt que supprimé.

Documentez ce que vous avez vérifié et le résultat : fenêtre temporelle, tableaux de bord/logs consultés, pics observés et décision finale.

Pièges courants qui font revenir un bug «corrigé»

Les bugs récurrents ne sont généralement pas une malchance. Ils apparaissent quand une correction est livrée sans les preuves et la communication qui transforment un changement en un résultat fiable.

Un échec courant est de fermer le ticket sans repro clair et critères d'acceptation. Si vous ne pouvez pas montrer le bug à la demande, vous ne pouvez pas être sûr qu'il est parti, ni sûr d'avoir corrigé la bonne chose.

Un autre est de corriger le symptôme sans traiter la cause racine. Exemple : ajouter un bouton retry pour une requête qui échoue alors que le vrai problème est un token expiré qui ne se rafraîchit jamais. Le retry masque le bug et habitue les utilisateurs à cliquer sans fin.

Les pièges qui font le plus souvent revenir une correction :

• Pas d'étapes reproductibles ou contrôles «ça marche chez moi» vagues
• Aucun test ajouté (ou le mauvais), permettant à un changement ultérieur de réintroduire le bug en silence
• Un «petit fix» qui introduit un gros refactoring, augmentant le risque et compliquant la revue
• Oublier les notes de déploiement, si bien que le support et les collègues ignorent le changement
• Vérifier uniquement le chemin heureux, pas un environnement réaliste

Le dernier point mérite une attention particulière. Une correction peut passer localement mais échouer en staging à cause des données réelles, des variables d'environnement manquantes, du cache ou de config d'auth différente. Essayez toujours un compte propre, une session navigateur propre et l'appareil le plus lent ou le plus ancien que vous pouvez raisonnablement tester.

Exemple : clore un bug de connexion sans casser la production

Scénario : après une mise à jour générée par IA, des utilisateurs signalent des échecs de connexion. Ça fonctionne pour le développeur, mais pas pour les clients réels.

De mauvaises étapes de repro ressemblent à : «La connexion est parfois cassée.» Ça fait perdre des heures car personne ne peut voir la défaillance de façon fiable.

De bonnes étapes de repro sont spécifiques et répétables :

1. Utiliser un utilisateur existant créé avant la dernière release.
2. Se déconnecter, puis tenter de se connecter sur mobile Safari.
3. Saisir l'email et le mot de passe corrects.
4. Observer : après validation, la page se recharge et vous êtes toujours déconnecté (aucune erreur affichée).

Les critères d'acceptation doivent être tout aussi clairs. Mauvais : «Les utilisateurs peuvent se reconnecter.» Mieux : «L'utilisateur arrive sur le tableau de bord, reçoit un cookie de session et reste connecté après rafraîchissement. Les mauvais mots de passe affichent le même message d'erreur qu'avant.»

Pour les tests, ajoutez une vérification ciblée et relancez une régression :

• Ajouter un test d'intégration pour le flux de connexion (identifiants corrects créent une session et retournent un succès).
• Vérification de régression : réinitialisation du mot de passe, logout et connexion dans le même navigateur qui échouait.

Les notes de déploiement peuvent être courtes mais concrètes : «Correction de la gestion de session pour les utilisateurs legacy sur Safari. Pas de changements BD. Si des problèmes surviennent, revenir à la build précédente et invalider les sessions.» Après la mise en production, surveillez le taux d'erreurs de connexion, la création de nouvelles sessions et les tickets support pendant 24 à 48 heures.

Le ticket est vraiment terminé quand : le bug se reproduit avant la correction, ne se reproduit plus après la correction, les tests couvrent la défaillance et les notes de déploiement indiquent ce qui a changé et quoi surveiller.

Prochaines étapes : faites-en votre standard et demandez de l'aide si besoin

Faites-en une habitude en collant cette checklist à l'endroit où vivent vos bugs (template de ticket, document partagé ou formulaire) pour que personne n'ait à s'en souvenir.

Faites un court point d'équipe pour vous aligner sur ce que «terminé» signifie. Les différences silencieuses comptent : une personne pense que «repro + fix» suffit, une autre attend tests, notes de déploiement et surveillance post-release. S'accorder une fois évite des réouvertures.

Essayez la checklist sur les trois prochaines corrections et ajustez selon ce qui a semblé lourd ou flou. Gardez-la courte, mais non négociable.

Une simple base à coller dans votre template de bug :

• Étapes de repro confirmées (et sauvegardées), plus attendu vs réel
• Critères d'acceptation rédigés en langage clair
• Tests ajoutés ou mis à jour, et tests clés relancés
• Notes de déploiement préparées (risque, qui prévenir, plan de rollback)
• Plan de surveillance post-release (quoi surveiller et combien de temps)

Si les bugs continuent de revenir même en suivant ça, la cause est souvent architecturale ou liée à la sécurité, pas une seule ligne de code. Si vous avez hérité d'une base générée par IA à partir d'outils comme Lovable, Bolt, v0, Cursor ou Replit, FixMyMess (fixmymess.ai) peut lancer un audit gratuit du code pour repérer des problèmes comme une authentification cassée, des secrets exposés ou une logique emmêlée avant votre prochaine release.