Revue de code : utiliser des captures d’écran
Un diff seul juge mal les changements d’interface. Un petit jeu de captures — avant / après, annotées, avec l’état qui compte — rend une pull request lisible et vérifiable.
Une pull request qui change le comportement d’un bouton, la validation d’un formulaire ou un état de chargement est difficile à juger à partir d’un diff. Les relecteurs finissent par récupérer la branche, recompiler et chercher l’écran dont vous parlez. Un petit jeu de captures bien fait supprime ce travail.
Capturez avant et après
Pour tout changement visible, capturez le même écran deux fois :
- Sur la branche de base, capturez la zone concernée.
- Sur votre branche, capturez la zone identique à la même taille de fenêtre et au même zoom.
- Gardez les deux captures ; ne recadrez pas l’une plus que l’autre.
Aligner la fenêtre d’affichage, le zoom du navigateur et la taille de fenêtre rend la comparaison pertinente. Si la mise en page est responsive, capturez les largeurs qui comptent (par exemple 1280 et 390) et étiquetez-les.
N’annotez que la différence
Le relecteur doit savoir où regarder, pas faire le tour complet :
- Des numéros pour plusieurs changements sur une même capture : 1 est le nouvel état vide, 2 le message d’erreur.
- Des formes pour entourer la zone qui a changé.
- Du texte pour le comportement attendu, court.
- Mosaïque ou flou pour tout ce qui est privé : noms de clients, e-mails, jetons, URL internes.
N’annotez pas tout l’écran. Si le changement tient à un contrôle, une flèche et une phrase suffisent.

Enregistrez l’interaction quand une image fixe ne suffit pas
Certains changements n’ont de sens qu’en mouvement : un menu déroulant qui se fermait trop tôt, un indicateur de chargement qui se résout désormais, une interaction par glisser. Enregistrez 10 à 20 secondes avec Enregistrement rapide, puis joignez le MP4 ou, pour une revue lisible en ligne, un GIF (Pro).
- Montrez d’abord le comportement défaillant, puis le comportement corrigé, dans un seul clip si possible.
- Coupez le microphone sauf si une voix ajoute quelque chose ; un clip silencieux se lance sans risque.
- Gardez le clip assez court pour être regardé deux fois.
Mettez les preuves dans la pull request
Une structure prévisible fait gagner du temps au relecteur :
- Ce qui a changé en une phrase.
- Les images avant / après, côte à côte ou empilées, toujours dans le même ordre.
- Comment reproduire l’état de la capture, si ce n’est pas l’écran par défaut.
- Ce qu’il faut vérifier — la ou les deux choses qui pourraient régresser.
- L’environnement, s’il compte : OS, navigateur, échelle d’affichage.
Joignez les images directement à la pull request plutôt que de renvoyer vers un drive personnel. Si vous utilisez un lien de partage, rappelez-vous qu’il peut expirer ou demander un mot de passe ; pour une revue de code, une pièce jointe est généralement préférable.
Gardez le jeu de captures petit
Les relecteurs survolent. Trois captures ciblées sont lues ; quinze défilent sans être vues.
- Une paire par changement visible.
- Recadrez la barre du navigateur et les panneaux sans rapport.
- Compressez ou redimensionnez les images qui ne servent qu’au contexte ; gardez la résolution complète pour les changements au pixel près.
- Supprimez les captures qui répètent le même état sous un angle légèrement différent.
Une liste de contrôle avant de soumettre
| Vérification | Pourquoi |
|---|---|
| Même fenêtre d’affichage et même zoom avant / après | Sinon la comparaison est invalide |
| Un changement par image | Plus facile à discuter et à résoudre |
| Les annotations pointent vers le changement | Pas de chasse au trésor |
| Les données privées sont masquées | Les pull requests sont souvent visibles par plus de monde que prévu |
| Un clip seulement là où le mouvement compte | Court et regardable |
| Des pièces jointes, pas des liens personnels | Les relecteurs ne devraient pas avoir besoin d’un compte |
Questions fréquentes
Faut-il joindre des captures ou un enregistrement d’écran ?
Des images fixes pour les états, un court clip pour les interactions. Un enregistrement de 10 à 20 secondes suffit à montrer une transition ; au-delà, on saute généralement.
Comment masquer les données clients dans une capture de revue ?
Utilisez la Mosaïque avec un réglage fort pour les noms et les identifiants, un cache plein pour les secrets, ou recadrez la zone. Le flou est plus faible que la mosaïque et ne doit pas servir pour quoi que ce soit de sensible.
Faut-il Pro pour faire des captures de revue ?
Non pour la capture, l’annotation, la numérotation, la mosaïque et l’enregistrement MP4 de base. L’export GIF, l’Effacement intelligent et les effets de l’éditeur vidéo sont des fonctions Pro, mais un jeu d’images fixes plus un MP4 couvre la plupart des revues gratuitement.
Autres articles du blog

Comment ajouter du texte à une capture d’écran et le rendre lisible
Ajoutez étiquettes, titres et légendes à une capture avec un contraste lisible, la bonne taille et un placement propre, puis modifiez-les plus tard sur Mac et Windows.
25 octobre 2026
Zoom automatique des enregistrements d’écran : à quoi il sert
Le zoom automatique d’InSnap suit vos clics pendant un enregistrement d’écran, l’intensité modifie le cadrage, et voici quand une vidéo statique est préférable.
25 octobre 2026
Comment créer une image de comparaison avant / après
Une seule image vaut mieux que deux pièces jointes : capturez les deux états à la même taille, assemblez-les côte à côte, étiquetez-les et envoyez une comparaison lisible.
25 octobre 2026