Deux blocs de code côte à côte : trouve les 7 différences (espace, point-virgule, mauvaise variable). Œil de reviewer entraîné en 3 minutes top chrono.
Find the Diff — Code Review
ObservationPuzzle 1 / 6 JavaScript
↑ ↓ — naviguer | Espace / Entrée — marquer la ligne | N — nouveau puzzle
Les 7 catégories de différences à débusquer
Pour s'entraîner efficacement à la code review, il faut connaître les familles de bugs les plus fréquentes. Find the Diff couvre les 7 catégories suivantes — toutes inspirées de bugs réels observés en pull request.
1. La casse oubliée (case sensitivity)
L'erreur la plus sournoise : userName qui devient username ou UserName. En JavaScript, TypeScript, Python, PHP, ces deux variables sont distinctes et la confusion provoque un ReferenceError ou pire : la création silencieuse d'une nouvelle variable globale. Repérage à l'œil : comparez chaque identifiant lettre à lettre, surtout les suffixes Id vs ID et les préfixes is vs Is.
2. Le point-virgule manquant
Le grand classique JavaScript. Sans point-virgule, l'Automatic Semicolon Insertion peut produire des comportements imprévus, notamment quand la ligne suivante commence par (, [ ou +. En TypeScript et Java, c'est carrément une erreur de compilation. Repérage : scannez les fins de ligne en escalier vertical — un manque de ; saute aux yeux quand on regarde la colonne droite.
3. Les opérateurs inversés
+ vs -, * vs /, && vs ||, === vs !==, < vs <=. Ces inversions causent des bugs métier graves qui passent souvent les tests unitaires basiques mais cassent en production sur des cas particuliers (off-by-one, signe inversé). En review, marquez systématiquement chaque opérateur d'un coup d'œil — ils sont peu nombreux mais critiques.
4. Les espaces parasites
Un double espace dans une chaîne ("Hello world") ne plante pas mais affiche un texte aberrant pour l'utilisateur. Un espace avant une virgule (foo( bar, baz)) viole la convention du linter. Plus subtil : un caractère espace insécable (U+00A0) collé depuis une page web qui passe pour un espace normal mais casse le parser. Find the Diff inclut des espaces visibles et invisibles à débusquer.
5. Les variables permutées
Quand un développeur fait du copier-coller, il oublie souvent de renommer une variable : userId à la place de productId dans une boucle, response à la place de request dans un middleware. Ces bugs sont le pain quotidien des reviewers : ils compilent, passent les tests trop générique, et explosent en intégration. Repérage : suivez chaque variable de sa déclaration à son utilisation.
6. Les valeurs littérales modifiées
retries = 3 qui devient retries = 30, port = 8080 qui devient port = 8090, true qui devient false. Les constantes numériques sont les plus dangereuses car elles passent toutes les vérifications statiques. Une off-by-one (length vs length-1) coûte cher en production. Find the Diff vous force à les comparer ligne à ligne.
7. Les mots-clés substitués
let vs const en JavaScript change la mutabilité — un const assigné par erreur en let permet la mutation où on ne la veut pas. public vs private en TypeScript expose accidentellement une API. async oublié sur une fonction casse les await en aval. Ces mots-clés sont rares mais structurants — repérez-les en début de ligne.
Bénéfices pour un développeur professionnel
Au-delà du divertissement, Find the Diff développe des compétences directement transposables à la pratique professionnelle — au point qu'on peut considérer le jeu comme un véritable exercice d'entraînement.
1. L'attention sélective accrue
L'attention sélective est la capacité à se focaliser sur des détails pertinents dans un environnement chargé. C'est la compétence numéro un d'un bon reviewer : sur une PR de 300 lignes, savoir où poser le regard. Le jeu force à cette focale en imposant deux blocs visuellement quasi-identiques : votre cerveau apprend à activer les zones du cortex visuel qui détectent les anomalies. Quelques sessions et vous repérerez en production des bugs que vous auriez laissé passer.
2. La concentration soutenue
Une partie dure 1 à 3 minutes — soit la durée idéale d'une fenêtre d'attention profonde (deep work) selon les neurosciences. Pendant ces minutes, votre cerveau ne reçoit aucune notification, aucune sollicitation extérieure, juste deux blocs de code à comparer. C'est un excellent échauffement cognitif avant une session de review réelle ou de débogage complexe.
3. La rigueur de relecture
Beaucoup de développeurs survolent le code en review — ils cherchent les bugs structurels (architecture, perfs) et passent à côté des détails. Find the Diff vous oblige au contraire à lire chaque caractère. Cette habitude se transfère naturellement aux PRs réelles : vous deviendrez le reviewer qui repère les fautes de frappe que les autres ont laissé filer.
4. La mémoire de travail visuelle
Pour comparer deux blocs, votre cerveau doit maintenir en mémoire la version de gauche pendant qu'il scanne la droite. C'est de la mémoire de travail visuelle pure. Cette compétence est centrale en débogage (se souvenir de l'état du code avant un breakpoint), en refactoring (comparer avant/après) et en lecture de diff Git.
5. La résistance à l'impulsivité
L'envie de cliquer dès qu'on croit avoir vu quelque chose est forte — mais chaque erreur coûte 30 points. Le jeu vous apprend à vérifier avant de valider. Cette discipline — qu'on appelle aussi doubt-then-confirm — est exactement ce qui distingue un développeur senior d'un junior en revue de code.
6. Le repérage de patterns
À force de jouer, vous reconnaîtrez instinctivement les endroits où les bugs se cachent : conditions limites de boucles, signes des opérateurs, casse des identifiants, fins de ligne. C'est la même intuition que développe un médecin radiologue à force de lire des centaines de scanners. Votre cerveau construit des heuristiques de scan inconscientes.
Stratégies de reviewer expert
Trouver les 7 différences rapidement n'est pas qu'une question de talent visuel — il existe des méthodes systématiques qui démultiplient votre vitesse et votre précision.
Stratégie 1 : la lecture en escalier vertical
Au lieu de lire ligne par ligne (gauche puis droite, ligne 1, gauche puis droite ligne 2…), scannez verticalement chaque colonne caractère par caractère. Comparez d'abord les premiers caractères de chaque ligne, puis les seconds, etc. Cette méthode révèle instantanément les espaces parasites, les indentations cassées et les point-virgules manquants en colonne de droite.
Stratégie 2 : la recherche par catégorie
Faites plusieurs passes, chacune dédiée à une catégorie de bug :
- Passe 1 — uniquement les opérateurs (
+ - * / == === !=) - Passe 2 — uniquement les identifiants (variables, fonctions)
- Passe 3 — uniquement la ponctuation (
; , : ( ) [ ] { }) - Passe 4 — uniquement les littéraux (nombres, chaînes, booléens)
- Passe 5 — uniquement les espaces et l'indentation
C'est plus lent mais beaucoup plus exhaustif que la lecture globale. Idéal pour les puzzles difficiles ou les vraies pull requests critiques.
Stratégie 3 : l'usage parcimonieux des indices
Le bouton Indice révèle une ligne différente que vous n'avez pas encore trouvée — mais coûte 50 points. Règle d'or : ne l'utilisez qu'après au moins 90 secondes de recherche infructueuse. Avant cela, l'effort cognitif de chercher seul renforce votre apprentissage. Après, l'indice débloque sans frustrer.
Stratégie 4 : le mental git diff
Imaginez que vous lisez un git diff en couleur — rouge à gauche, vert à droite. Mentalement, surlignez chaque ligne suspecte avant de cliquer. Cette technique force votre cerveau à formuler une hypothèse claire avant l'action ("la ligne 4 a un + à la place du -"). Elle élimine 80% des erreurs impulsives.
Stratégie 5 : la logique du pareto
Les puzzles contiennent presque toujours :
- 1 ou 2 diffs évidentes (changement de mot, valeur littérale très différente)
- 3 ou 4 diffs intermédiaires (casse, opérateur)
- 1 ou 2 diffs sournoises (espace, point-virgule, signe d'opérateur)
Attaquez les évidentes en premier (gain de confiance + score), puis méthodiquement les intermédiaires, et terminez en mode "loupe" pour les sournoises. Ne sautez jamais les sournoises — elles sont la signature du reviewer expert.
Du jeu à la code review en production
Find the Diff est un jeu, mais ses leçons s'appliquent directement à la pratique de la code review professionnelle. Voici comment transposer.
La code review : 90% d'attention, 10% d'expertise
Beaucoup de développeurs juniors pensent qu'on devient bon reviewer en accumulant l'expertise technique. C'est faux à 90%. La majorité des bugs trouvés en review sont des erreurs visuelles que n'importe qui aurait vues en regardant attentivement. L'expertise technique sert à juger les choix architecturaux ; l'attention sert à attraper les bugs. Le jeu entraîne précisément la seconde — la plus payante au quotidien.
Le coût d'un bug en production
Une étude IBM des années 2000 (toujours actuelle) montre qu'un bug coûte :
- 1× en revue de code (avant merge)
- 6× en QA (après merge mais avant prod)
- 15× en production (incident utilisateur)
- 100× si le bug provoque une perte de données ou une faille de sécurité
Chaque diff que vous attrapez en review économise donc en moyenne 5 à 99 fois son coût de détection. Un bon reviewer est l'employé qui rapporte économiquement le plus à son équipe.
L'approche "pair programming asynchrone"
Considérez chaque review comme du pair programming différé. Vous n'êtes pas là pour critiquer, vous êtes là pour doubler les yeux sur du code qui partira en production. Find the Diff vous habitue à cette posture mentale : vous ne jugez pas l'autre, vous cherchez avec lui les détails qui ont pu lui échapper après plusieurs heures de travail.
Reviewer le code généré par IA
À l'ère de Copilot, ChatGPT et Claude Code, une part croissante du code n'est plus écrite par des humains. Toutes ces générations contiennent statistiquement des bugs subtils — variables hallucinées, mauvaises versions d'API, off-by-one, opérateurs approximatifs. Le rôle du reviewer humain devient critique. Find the Diff entraîne exactement la compétence requise : repérer les détails plausibles mais incorrects.
Exporter la méthode à d'autres domaines
Les compétences entraînées par Find the Diff débordent largement la programmation. Comparer deux contrats, relire un mail important, vérifier des chiffres dans un tableau Excel, contrôler un design avant impression : partout où il faut comparer deux versions ou repérer des anomalies, l'attention sélective entraînée fait la différence. Le jeu est un brain training universel déguisé en exercice de dev.
Questions fréquentes
Conclusion
Sept différences, deux blocs, quelques minutes : Find the Diff — Code Review condense en un format ultra-court l'exercice mental le plus précieux du métier de développeur. Que vous soyez junior cherchant à muscler votre œil de reviewer, senior voulant maintenir vos réflexes ou tech lead souhaitant former votre équipe à la rigueur de relecture, le jeu offre un retour sur investissement immédiat.
Et au-delà du score, c'est la transformation de votre regard sur le code qui compte. Quelques sessions et vous remarquerez un point-virgule manquant en diagonale d'écran, une casse erronée à dix lignes de distance, un opérateur inversé sans même y penser. Cette intuition se construit par la répétition — et chaque puzzle joué est un investissement dans la qualité du code que vous livrerez demain.
Comment jouer à Find the Diff Code Review
Find the Diff — Code Review est un jeu d'observation conçu spécifiquement pour les développeurs. Il transpose dans un format ludique l'exercice quotidien le plus exigeant du métier : la relecture de code. Deux blocs identiques en apparence sont affichés côte à côte ; sept détails subtils ont été modifiés. À vous de les retrouver le plus vite possible.
Le principe en trente secondes
Le bloc de gauche est l'Original — la référence à laquelle se comparer. Le bloc de droite est À reviewer : il contient exactement 7 différences par rapport à l'original. Chaque ligne du bloc de droite est cliquable. Quand vous repérez une différence, cliquez sur la ligne correspondante :
Les 6 puzzles disponibles
Le jeu inclut 6 puzzles dans des langages différents pour couvrir l'éventail des contextes que vous rencontrez en review réelle :
Score et performance
Chaque puzzle se joue contre la montre. Le score combine quatre facteurs : nombre de différences trouvées (+150 pts chacune), pénalités pour les erreurs (−30 pts), pénalités pour les indices utilisés (−50 pts), et bonus temps calculé sur 180 secondes. Le score maximum théorique est de 1230 points par puzzle, sauvegardé en LocalStorage.
Contrôles complets