Blog › Tutoriels

Rédiger les étapes de reproduction : 5 exemples (2026)

🔧 Tutoriels · 8 min de lecture · 9 octobre 2026
Pourquoi « je n'arrive pas à reproduire » est presque toujours un problème d'étapes 5 règles pour des étapes qui fonctionnent Quel niveau de détail pour les étapes ? 5 exemples complets Exemple 1 : connexion et authentification (5 étapes) Exemple 2 : paiement et codes promo (6 étapes) Exemple 3 : tactile sur mobile (5 étapes) Exemple 4 : API et données (4 étapes) Exemple 5 : bug intermittent (avec probabilité et timing) 7 erreurs qui rendent vos étapes inutilisables Checklist avant envoi FAQ Les étapes, c'est vous. Les preuves peuvent être automatiques. Pour aller plus loin

Pourquoi « je n'arrive pas à reproduire » est presque toujours un problème d'étapes

De bonnes étapes de reproduction = un point de départ clair + une action par étape + des données réelles + ce que vous avez observé à chaque étape. Si quelqu'un peut les lire à voix haute et arriver sur le même écran, elles sont assez bonnes. Ci-dessous : 5 règles, un test de niveau de détail, 5 exemples complets (dont la rédaction d'un bug intermittent) et une checklist avant envoi.

Quand un développeur répond « je n'arrive pas à reproduire », c'est rarement de la mauvaise volonté. Il manque quelque chose dans les étapes, et c'est le plus souvent l'un de ces trois points :

  • Le point de départ manque : aucun prérequis écrit. Vous étiez connecté en compte entreprise, le développeur a utilisé un compte personnel — deux chemins de code différents.
  • Les actions ont été fusionnées : une étape dit « remplir le formulaire et valider », mais le bug se produit dans l'enregistrement automatique entre les deux.
  • Les données manquent : des descriptions génériques à la place de valeurs réelles — et le bug n'apparaît que lorsque l'e-mail contient un +.

    • En une phrase : les étapes ne sont pas un compte rendu pour vous, mais un itinéraire pour les autres.

    5 règles pour des étapes qui fonctionnent

  • Énoncez le point de départ : état de connexion, état des données et URL d'entrée vont dans les prérequis, pas coincés dans l'étape 1.
  • Une action par étape : chaque numéro fait exactement une chose, pour que le lecteur puisse les cocher une à une.
  • Utilisez de vraies données : écrivez user+test@x.com, pas « une adresse e-mail ».
  • Notez ce que vous observez (recommandé) : après les étapes clés, ajoutez « ici la page affiche X », pour que le développeur voie où ça diverge.
  • Mettez l'environnement dans son champ, ou déclarez-le en première ligne : navigateur, OS, appareil, largeur de viewport — en oublier un peut faire échouer la reproduction.

    • Quel niveau de détail pour les étapes ?

    Niveau Exemple Problème
    Trop grossier « Ouvrir le paiement, supprimer un article, le compteur est faux » Trois actions dans une phrase — impossible de savoir où ça casse
    Juste « 1. Aller sur /cart 2. Cliquer sur Supprimer à côté du produit 3. Regarder le badge en haut de page » Une action par étape, chacune vérifiable
    Trop fin « 1. Déplacer le pointeur sur le bouton 2. Appuyer sur le bouton gauche 3. Relâcher » Des actions physiques découpées : plus difficile à lire, pas plus simple

    Le test : après rédaction, posez-vous deux questions. ① Quelqu'un d'autre peut-il arriver au même écran sans ma capture ? ② Un développeur peut-il dire en deux minutes s'il s'agit du front, de l'API ou des données ? Deux « oui » signifient que le niveau de détail est bon.

    5 exemples complets

    Exemple 1 : connexion et authentification (5 étapes)

    Prérequis : compte test@example.com déjà inscrit et actif. Environnement : Chrome 120 / macOS 14 / ordinateur / 1920×1080 / fenêtre de navigation privée.

  • Ouvrir https://app.example.com/login
  • Saisir test@example.com avec le mot de passe correct
  • Saisir trois fois de suite un captcha image erroné
  • Au quatrième essai, saisir un captcha valide puis cliquer sur « Se connecter »
  • Observer le message affiché

    • Attendu : un message « Captcha incorrect, veuillez réessayer », le compte restant déverrouillé. Obtenu : le message « Compte verrouillé, réessayez dans 24 heures » — alors que le captcha était correct.

    Exemple 2 : paiement et codes promo (6 étapes)

    Prérequis : 2 articles dans le panier pour un total de 1 299 € ; compte de type entreprise. Environnement : Chrome 120 / Windows 11 / ordinateur / 1440×900 / compte entreprise.

  • Ouvrir /cart et vérifier que le total est de 1 299 €
  • Cliquer sur « Passer au paiement »
  • Saisir le code promo SAVE100 dans le champ dédié (expiré depuis trois jours)
  • Cliquer sur « Appliquer »
  • Observer le bandeau en haut de page et l'état du panier
  • Recharger la page et observer de nouveau

    • Attendu : un message « code promo expiré », panier inchangé. Obtenu : le message « code appliqué » et 100 € sont déduits ; au clic sur « Appliquer », les deux articles disparaissent du panier.

    Exemple 3 : tactile sur mobile (5 étapes)

    Prérequis : connecté, 1 article dans le panier. Environnement : iPhone 14 / iOS 17.2 / Safari / viewport 390×844.

  • Ouvrir https://shop.example.com/cart
  • Faire défiler jusqu'au formulaire d'adresse en bas de page
  • Toucher le champ « Nom du destinataire » pour ouvrir le clavier
  • Regarder le bouton « Valider la commande » au-dessus du clavier
  • Essayer de toucher ce bouton

    • Attendu : le bouton remonte au-dessus du clavier et reste cliquable. Obtenu : le clavier masque environ 60 % du bouton, et les appuis dans cette zone restent sans effet.

    Exemple 4 : API et données (4 étapes)

    Prérequis : jeton d'environnement de test disponible ; la base contient 12 400 commandes, dont 12 correspondent au mot-clé. Environnement : https://api-test.example.com / curl 8.x.

  • GET /api/orders/export?month=2026-08 avec l'en-tête Authorization: Bearer <token>
  • Attendre la réponse
  • Observer le code HTTP et le corps de la réponse
  • Réessayer avec month=2026-08-01~2026-08-07

    • Attendu : 200 avec un identifiant de tâche d'export, ou 202 si la tâche est mise en file. Obtenu : 504 (timeout de passerelle) ; avec une plage réduite, 200 est renvoyé — le seuil dépend donc du volume de données.

    Exemple 5 : bug intermittent (avec probabilité et timing)

    Prérequis : compte sans solde ; carte de test associée à l'utilisateur de test. Environnement : Chrome 120 / macOS 14 / réseau bridé en 3G.

  • Ouvrir /checkout et renseigner les informations de paiement
  • Ouvrir les DevTools et passer le panneau Network en bridage 3G
  • Double-cliquer rapidement sur « Confirmer le paiement » (intervalle d'environ 300ms)
  • Observer la liste des commandes et le journal des paiements

    • Attendu : une seule commande créée ; les clics répétés doivent être dédupliqués côté client ou bloqués par l'idempotence de l'API. Obtenu : 3 fois sur 10, deux commandes ont été créées (conditions : intervalle <500ms et latence réseau >1s). L'enregistrement du panneau Network et les identifiants des deux appels POST /api/orders sont joints.

    Comment rédiger un bug intermittent :

    • Donnez une probabilité, pas le mot « intermittent » : « 3 fois sur 10 » est cent fois plus utile.
    • Donnez le timing ou le seuil : « intervalle <500ms », « latence >1s » — ces conditions sont souvent l'indice de la cause.
    • Donnez le type de preuve : l'enregistrement d'écran et les logs console sont les seules preuves durables qu'un bug intermittent peut emporter.

    7 erreurs qui rendent vos étapes inutilisables

  • Commencer par « ouvrir la page d'accueil » : la navigation est du remplissage, les cinq premières étapes sont du bruit.
  • Plusieurs actions dans une étape : « remplir le formulaire et valider » — impossible de localiser la panne.
  • Descriptions génériques : « saisir le bon identifiant et mot de passe », alors que ces valeurs exactes sont la variable clé.
  • Prérequis de données manquants : combien d'articles, quel type de compte, si un remboursement a déjà eu lieu.
  • Jargon interne : « passer par l'ancien flux », « utiliser un compte plan B » — indéchiffrable pour un intervenant externe.
  • Résultats attendus glissés dans les étapes : « à l'étape 3, une popup devrait s'afficher » — cela appartient à un champ dédié.
  • Spéculation dans les étapes : « l'étape 4 échoue parce que le cache est périmé » — les hypothèses vont dans les notes, marquées « suspecté ».

    • Checklist avant envoi

    • Prérequis écrits (état de connexion + état des données) ?
    • La première étape est une action métier, pas « ouvrir un navigateur » ?
    • Exactement une action par numéro ?
    • Des valeurs réelles plutôt que des génériques ?
    • Observations notées après les étapes clés ?
    • Résultat attendu et résultat obtenu séparés ?
    • Pour un bug intermittent : probabilité et timing indiqués ?

    FAQ

    Combien d'étapes doit comporter une reproduction ?

    En général 3 à 8. Moins de 3 signifie souvent des prérequis manquants ; plus de 8 peut presque toujours être raccourci — déplacez la navigation dans les prérequis et ne gardez que les actions qui déclenchent le problème.

    L'environnement va-t-il dans les étapes ou dans un champ dédié ?

    Dans un champ dédié. Placé dans les étapes, il casse le rythme de lecture et devient infiltrable. Si le format n'a pas de champ environnement (un e-mail, par exemple), déclarez-le sur une ligne en tête des étapes : « Environnement : Chrome 120 / macOS 14 / 1920×1080 ».

    Faut-il inclure des actions inutiles comme « cliquer sur Retour » ou « fermer la popup » ?

    Uniquement si elles font partie des conditions de reproduction. Testez : supprimez l'étape — le bug se produit-il toujours ? Si oui, retirez-la ; si non, elle doit rester.

    Comment rédiger les étapes d'un bug que je n'arrive pas à reproduire moi-même ?

    Écrivez honnêtement trois choses : ① les conditions essayées (quelles tentatives ont marché, lesquelles non) ; ② la meilleure preuve disponible (enregistrement, logs console, requêtes réseau) ; ③ les corrélations observées (« seulement quand le réseau est lent »). Marquez « conditions de reproduction non confirmées » dans le titre ou les notes, plutôt que de faire passer le bug pour systématique.

    Quelle différence entre étapes de reproduction et cas de test ?

    Un cas de test est une checklist conçue à l'avance — couvrant chemins nominaux, limites et exceptions, dans une logique de couverture. Les étapes de reproduction sont un chemin consigné après coup, dont le seul but est de rejouer le problème de façon fiable. Les deux s'enrichissent mutuellement, mais les objectifs diffèrent — pour la rédaction des cas de test, voir modèle de cas de test avec exemples.

    Les étapes, c'est vous. Les preuves peuvent être automatiques.

    Les étapes doivent venir de la personne qui a cliqué — vous seul savez ce que vous avez fait. En revanche, l'environnement et les preuves qui les accompagnent peuvent se remplir seuls :

    • Enregistrement d'écran : capture de l'onglet courant en un clic, avec découpe, pour que même les bugs intermittents emportent une preuve rejouable.
    • Données de diagnostic : les logs console de niveau erreur et les requêtes réseau en échec (HTTP ≥ 400) sont collectés, avec anonymisation des paramètres sensibles.
    • Contexte technique automatique : URL, navigateur, OS, résolution et viewport sont renseignés pour vous.
    • Captures annotées : sélectionnez une zone et ajoutez flèches, cadres et texte pour figer le problème.
    • Partager ou synchroniser : générez un lien de partage ouvrable sans inscription, ou poussez le rapport vers Feishu Bitable ou un webhook générique.

    Pour aller plus loin

    #steps to reproduce #bug reporting #QA #tutorial
    Partager

    Articles connexes