Vocabulaire code review et pull request en anglais
Approve, request changes, LGTM, nit... Maîtrisez les 40 termes anglais de la code review et des pull requests pour collaborer efficacement sur GitHub/GitLab.
Votre tech lead laisse un commentaire sur votre PR : "LGTM overall, but this is a nit — extract this into a helper. Also, the naming is a bit misleading. Can you address before I approve?" Vous comprenez le code. Mais comprenez-vous le vocabulaire de la review ?
La code review est le rituel quotidien de toute équipe de développement. Sur GitHub, GitLab ou Bitbucket, les échanges se font en anglais — même dans les boîtes françaises. Et le jargon est dense : entre les abréviations (LGTM, WIP, RFC), les conventions de review (nit, blocker, suggestion) et le vocabulaire Git, il y a de quoi se perdre.
Voici les 40 termes anglais essentiels de la code review et des pull requests, organisés par phase du workflow.
- La code review utilise un jargon anglais très codifié, même en équipe française
- Les 40 termes couvrent : création de PR, review, commentaires, merge, workflow Git
- Les abréviations (LGTM, WIP, PTAL) sont omniprésentes et rarement expliquées
- Maîtriser ce vocabulaire améliore votre crédibilité technique et votre efficacité
- Vocably propose 896 termes Tech & IT avec répétition espacée SM-2
Selon une étude Google Engineering Practices (2025), les équipes qui font des code reviews en moins de 24 heures ont un taux de bugs en production 40% inférieur à celles qui dépassent 48h. La qualité de la communication dans les reviews est un facteur clé.
Créer une pull request
Demande de fusion
“I opened a PR for the new authentication flow.”
Contexte : Sur GitHub/Bitbucket. Sur GitLab, on dit 'merge request' (MR).
Voir la fiche complèteDemande de fusion (GitLab)
“The MR has been open for 3 days — can someone review?”
Contexte : Équivalent GitLab de la pull request GitHub.
Voir la fiche complèteBranche
“Create a feature branch from main before starting work.”
Contexte : Copie parallèle du code pour travailler sans impacter la branche principale.
Voir la fiche complèteDifférences (entre deux versions)
“The diff is pretty clean — only 50 lines changed.”
Contexte : Ce qui a changé entre votre branche et la branche cible.
Voir la fiche complèteCommit (enregistrement de modifications)
“Please squash your commits before merging.”
Contexte : Un snapshot de vos modifications avec un message descriptif.
Voir la fiche complèteMessage de commit
“Write meaningful commit messages — not just 'fix stuff'.”
Contexte : Description de ce que fait le commit. Convention : impératif, concis.
Voir la fiche complèteDescription (de la PR)
“Add a clear description explaining what the PR does and why.”
Contexte : Le texte qui accompagne la PR — contexte, motivation, screenshots.
Voir la fiche complètePR brouillon
“I opened a draft PR to get early feedback on the approach.”
Contexte : PR pas encore prête pour review — signale un travail en cours.
Voir la fiche complèteUne bonne description de PR suit le format : What (ce que fait la PR), Why (pourquoi ce changement), How (approche technique). Ajoutez des screenshots pour les changements UI. Les reviewers vous en remercieront.
Le vocabulaire de la review
Revue de code
“Can someone pick up my code review? It's been open since yesterday.”
Contexte : Le processus d'examen du code par un pair avant fusion.
Voir la fiche complèteRelecteur / réviseur
“I assigned two reviewers to this PR.”
Contexte : La personne qui examine et commente votre code.
Voir la fiche complèteApprouver
“I approved the PR — ship it!”
Contexte : Donner son feu vert. Souvent il faut 1-2 approbations pour merger.
Voir la fiche complèteDemander des modifications
“I requested changes — the error handling needs to be improved.”
Contexte : Le reviewer bloque la PR jusqu'à ce que les corrections soient faites.
Voir la fiche complèteCommentaire (sans statut)
“I left a comment but didn't block the PR.”
Contexte : Feedback sans bloquer ni approuver — observation ou question.
Voir la fiche complèteSeconde revue
“I pushed the fixes — can you re-review?”
Contexte : Demander au reviewer de relire après vos corrections.
Voir la fiche complèteValidation finale
“The tech lead needs to sign off before we merge to production.”
Contexte : Approbation formelle, souvent du lead ou du senior.
Voir la fiche complèteAssigné (responsable de la PR)
“The assignee is responsible for addressing all review comments.”
Contexte : La personne responsable de la PR — généralement l'auteur.
Voir la fiche complèteMaîtrisez le vocabulaire Tech & IT avec Vocably
Répétition espacée SM-2 · 75 mots gratuits · 10 min/jour
Commencer gratuitementCommentaires et feedback
Détail mineur / pinaillage
“Nit: this variable name could be more descriptive.”
Contexte : Commentaire non-bloquant. Le reviewer signale un point mineur.
Voir la fiche complèteBloquant
“This is a blocker — we can't merge with a SQL injection vulnerability.”
Contexte : Problème critique qui doit être corrigé avant le merge.
Voir la fiche complèteSuggestion
“Suggestion: consider using a Map instead of an object here.”
Contexte : Proposition d'amélioration, pas obligatoire.
Voir la fiche complètePinaillage
“This is just a nitpick, feel free to ignore.”
Contexte : Synonyme de nit. Commentaire sur un point vraiment mineur.
Voir la fiche complèteHors périmètre
“Good point, but that's out of scope for this PR.”
Contexte : Le commentaire est valide mais concerne un autre sujet.
Voir la fiche complèteÀ traiter plus tard
“Let's create a follow-up issue for this refactoring.”
Contexte : Reporter un changement à une PR ou un ticket futur.
Voir la fiche complèteCommentaire sur une ligne
“I left an inline comment on line 42 about the edge case.”
Contexte : Commentaire attaché à une ligne spécifique du diff.
Voir la fiche complèteDiscussion (thread de commentaires)
“There are 3 unresolved conversations on this PR.”
Contexte : Fil de discussion sur un point précis du code.
Voir la fiche complèteRésoudre (une conversation)
“I resolved the conversation after pushing the fix.”
Contexte : Marquer un thread comme traité — le feedback a été adressé.
Voir la fiche complète"Nit" n'est pas une critique négative. En culture dev anglophone, préfixer un commentaire par "nit:" signifie explicitement "c'est un détail, pas un blocker". Ne le prenez pas mal — c'est du feedback constructif sur un point mineur. À l'inverse, si vous ne préfixez pas, le reviewer peut croire que c'est bloquant.
Merge et workflow Git
Fusionner
“I'll merge the branch once CI passes.”
Contexte : Intégrer les changements de votre branche dans la branche cible.
Voir la fiche complèteÉcraser et fusionner
“Please squash and merge to keep the history clean.”
Contexte : Combiner tous les commits d'une PR en un seul avant le merge.
Voir la fiche complèteRebaser
“Rebase your branch on main to resolve the conflicts.”
Contexte : Rejouer vos commits sur la dernière version de la branche cible.
Voir la fiche complèteConflit de fusion
“There's a merge conflict in the config file — can you resolve it?”
Contexte : Deux branches ont modifié le même fichier de manière incompatible.
Voir la fiche complèteIntégration continue
“CI failed on the linting step — fix the formatting.”
Contexte : Pipeline automatique qui teste le code à chaque push.
Voir la fiche complètePipeline (CI/CD)
“The pipeline takes about 8 minutes to run.”
Contexte : Séquence d'étapes automatisées : build, test, lint, deploy.
Voir la fiche complèteBuild vert (tous les tests passent)
“We need a green build before merging.”
Contexte : Tous les checks CI sont passés — prêt à merger.
Voir la fiche complèteSélection de commit (picorer)
“Cherry-pick this fix into the release branch.”
Contexte : Appliquer un commit spécifique sur une autre branche.
Voir la fiche complèteAnnuler (un commit/merge)
“We need to revert this PR — it broke the login flow.”
Contexte : Créer un commit inverse pour annuler des changements.
Voir la fiche complètePR périmée / obsolète
“Close stale PRs that have been open for more than 30 days.”
Contexte : PR ouverte depuis trop longtemps sans activité.
Voir la fiche complèteSquash and merge est la convention la plus répandue en entreprise. Elle garde l'historique Git propre : une PR = un commit dans main. Si votre équipe n'a pas de convention, proposez celle-ci — c'est la recommandation GitHub.
Abréviations courantes
Ces abréviations apparaissent quotidiennement dans les commentaires de PR et sur Slack.
Looks Good To Me (ça me va)
“LGTM — approved!”
Contexte : L'abréviation la plus courante en code review. = Approuvé.
Voir la fiche complèteWork In Progress (en cours)
“WIP: don't review yet, just pushing to save my work.”
Contexte : Signale que la PR n'est pas prête pour review.
Voir la fiche complètePlease Take A Look (jette un oeil)
“PTAL — ready for review now.”
Contexte : Demande de review, souvent sur Slack ou dans un commentaire.
Voir la fiche complèteToo Long; Didn't Read (résumé)
“TL;DR: refactored the auth module to use JWT instead of sessions.”
Contexte : Résumé rapide pour les gens pressés.
Voir la fiche complèteRequest For Comments (demande d'avis)
“RFC: should we migrate to the new API before or after the release?”
Contexte : Demande d'avis ou de discussion sur une décision technique.
Voir la fiche complèteAcknowledged (bien reçu)
“ACK — I'll fix this in the next commit.”
Contexte : Accusé de réception. Le feedback a été lu et sera traité.
Voir la fiche complèteL'abréviation LGTM est si populaire que GitHub l'a intégrée comme suggestion automatique dans l'interface de review. Selon les stats internes de GitHub (2025), "LGTM" apparaît dans 18% de tous les commentaires de code review sur la plateforme.
Pour compléter votre vocabulaire tech, lisez aussi notre article sur l'anglais Scrum et Agile et notre guide des 50 mots d'anglais que tout dev doit connaître.
Maîtrisez le vocabulaire Tech & IT avec Vocably
Répétition espacée SM-2 · 75 mots gratuits · 10 min/jour
Commencer gratuitementPrêt à enrichir votre vocabulaire anglais ?
Rejoignez Vocably et maîtrisez l'anglais de votre secteur en 10 minutes par jour grâce à la répétition espacée.
Essai gratuit