Les développeurs reçoivent beaucoup de bug reports qui se résument à une image et aux mots « c’est cassé ». La capture fait la moitié du travail ; l’autre moitié vient de la façon dont elle a été capturée, annotée et présentée. Ce guide est un modèle pratique pour faire porter aux captures tout leur poids.

Ce que contient un bon rapport basé sur une capture

L’état lui-même : l’écran réel montrant le problème, pas sa description.
Un pointeur : une flèche ou un cadre identifiant l’élément exact concerné.
Les métadonnées de contexte : quelle app et quelle version, quel OS, et idéalement la résolution, pour que le développeur puisse écarter un rendu propre à l’environnement.
Les étapes de reproduction : numérotées, courtes, dans l’ordre. La capture est l’étape N ; le lecteur a besoin des étapes 1 à N-1.
Attendu vs réel : une ligne chacun. « Attendu : le menu déroulant reste ouvert. Réel : le menu se ferme immédiatement. »

Tout le reste est optionnel. Résistez à l’envie de joindre cinq captures quand une seule annotée plus trois étapes de reproduction raconte toute l’histoire.

Capturer spécifiquement pour un bug report

Capturer la bonne portée

Une zone, pas l’écran entier, dans la plupart des cas. Un recadrage serré autour du composant cassé se lit plus vite sur mobile et expose moins votre environnement.
Plein écran seulement quand la position compte, par exemple un bug de mise en page où la relation entre les panneaux est justement ce qui compte.
Capturez les deux états pour les bugs de transition. Si cliquer sur X fait disparaître Y, il vous faut l’avant et l’après. Deux petites captures valent mieux qu’une seule ambiguë.

Annoter avec intention

Le guide d’annotation détaille les outils ; pour un rapport, vous avez surtout besoin de :

Annotation	Quand l’utiliser
Flèche	Un élément précis est faux. Le choix par défaut.
Rectangle	Une zone ou un conteneur se comporte mal (espacement, débordement, rognage).
Étiquette texte	Numéros d’étapes dans les reproductions multi-étapes ; encarts « attendu » vs « réel ».
Flou	Tout ce qui est sensible et sans rapport avec le bug. Toujours.
Recadrer	Retirer l’espace vide après annotation pour que le marquage occupe davantage le cadre.

Deux règles de bon sens :

Une flèche par capture. Si vous en avez besoin de trois, il vous faut probablement trois captures.
Floutez avant l’upload. Tokens, noms de clients et URL internes sont floutés dans l’éditeur avant que l’image ne quitte votre machine (comment s’y prendre). Il n’y a pas de dé-floutage après partage.

Inclure les métadonnées qui aident

Une page de partage qui affiche les dimensions, la taille du fichier et la date de capture évite un aller-retour du type « quelle résolution aviez-vous ? ». Les pages de partage de Shotivo affichent largeur × hauteur, taille du fichier, date de création et expiration. Ainsi, coller le lien transmet ce contexte automatiquement.

Dans le corps du rapport lui-même, ajoutez :

Nom de l’app + version (ex. « Shotivo 1.x » ou le numéro de build du produit concerné)
OS + version (« macOS 15.2 »)
Une ligne d’environnement si pertinent (« écran externe 4K », « VPN activé »)

Le workflow : trois secondes pour obtenir une capture partageable

Avec un utilitaire de capture de barre des menus (valeurs par défaut de Shotivo) :

⌘⇧9 : faites glisser le curseur sur la zone cassée. L’éditeur s’ouvre instantanément.
Cliquez sur l’outil flèche, marquez l’élément ; floutez tout ce qui est sensible ; recadrez serré.
⌘↩ (Partager) : envoie l’image et copie un lien shotivo.app/s/… dans votre presse-papiers.
Collez le lien dans le ticket, suivi des étapes de reproduction.

Total depuis la première touche jusqu’au lien prêt à coller : trois à cinq secondes environ. Les liens Gratuit expirent après 7 jours ; les liens Pro peuvent rester actifs jusqu’à 90 jours (90 jours par défaut). Téléchargez l’original si le ticket doit conserver une copie locale durable. Comment fonctionne la rétention selon l’offre, si vous ne savez pas quelle limite s’applique à vous.

Modèle

[App] [Composant] · [résumé en une ligne]

Étapes :
1. …
2. …
3. Observer : <ce qui se passe>

Attendu : <ce qui devrait se passer>

Capture : <coller le lien de partage>
Env : macOS 15.2 · build de l'app 1.x · <note d'écran si pertinent>

Remplissez le modèle en moins d’une minute et vous avez produit un rapport sur lequel un développeur peut agir sans appel de suivi. La capture montre ; les trois lignes expliquent.

Erreurs fréquentes

« Voir la pièce jointe. » sans étapes de reproduction. Le développeur doit deviner le chemin menant à l’état.
Capture plein écran d’un problème minuscule. La flèche pointe vers 2 % du cadre.
Secrets non floutés. Le rapport est transféré, archivé, indexé. Votre token est désormais public.
Cinq captures du même état. Une bonne capture accompagnée de texte vaut mieux que cinq médiocres.
Capture prise après avoir « corrigé ». Capturez l’état cassé d’abord ; vous pouvez toujours recapturer plus tard.

Le niveau d’exigence est modeste et mérite d’être atteint : un développeur qui n’a jamais vu cette app peut-il atteindre l’état cassé à partir de votre texte seul, et voir exactement ce qui ne va pas à partir de votre image ? Si oui, le rapport est fait.

Rédiger de meilleurs bug reports avec des captures d'écran