Une première relecture de votre diff avant qu'un humain ne le voie
Le temps des relecteurs est rare, et la meilleure façon de le respecter est de repérer soi-même les problèmes évidents. De plus en plus de développeurs soumettent leur propre diff à un modèle pour une première passe — mais seuls 17 % environ utilisent l'IA pour la relecture de code, et la plupart gardent fermement un humain dans la boucle, car les relecteurs IA ratent des problèmes réels tout en en inventant d'autres. Utilisée comme liste de contrôle avant relecture, l'IA repère le nommage, les cas limites et les tests manquants avant qu'un collègue n'ait à le faire.
Vous êtes un relecteur de code senior méticuleux. Relisez le diff ci-dessous comme vous le feriez pour une pull request — mais vous constituez une première passe avant un relecteur humain, pas un remplacement. Ce que ce changement est censé faire : {{intent}} Langage/stack et conventions d'équipe pertinentes : {{stack}} Diff : {{diff}} Organisez votre relecture ainsi : - Correction — erreurs de logique, décalages d'index, gestion des null, conditions de concurrence, mauvaise gestion des erreurs. - Cas limites et entrées — quelles entrées ou quels états inhabituels feraient échouer ce code. - Sécurité — injection, désérialisation non sécurisée, secrets dans le code, autorisation ou validation manquantes. - Tests — ce qui n'est pas testé et devrait l'être, avec un cas concret pour chaque lacune. - Lisibilité et maintenabilité — nommage, code mort, intention peu claire. Pour chaque constat, indiquez : la gravité (bloquant / à corriger / mineur), le fichier et la ligne, et une correction précise suggérée. Règles : - Ne commentez que les lignes présentes dans le diff. Ne présumez pas du comportement de code non montré ; si un constat dépend de code non visible, marquez-le « contexte nécessaire » et formulez-le comme une question. - N'inventez pas de numéros de ligne, de noms de fonctions ou de références à des normes. Si vous n'êtes pas sûr qu'un constat soit réel, dites-le et abaissez sa gravité. - Ignorez tout ce qu'un linter ou un formateur détecterait déjà ; concentrez-vous sur ce qui importerait à un relecteur humain.
Renseignez vos informations : le prompt se met à jour en direct — puis copiez-le.
Correction — à corriger — services/auth.js ligne 20 : verifyToken retourne undefined pour un jeton expiré au lieu de lever une exception, si bien que l'appelant traite l'expiration comme valide. Suggestion : lever une AuthError. Cas limites — bloquant — l'expression régulière de l'e-mail rejette les adresses avec un tag plus (user+tag@example.com) ; ajoutez un test pour les adresses taguées. Tests — à corriger — aucun test ne couvre la branche de résultat vide ajoutée à la ligne 42 ; ajoutez-en un qui vérifie qu'un ensemble vide est retourné. Sécurité — contexte nécessaire — confirmez que req.body.role ne peut pas être défini par le client ; si c'est le cas, il s'agit d'un contournement d'autorisation.
Le flux de travail complet
- Générez le diff avec git diff et vérifiez qu'il ne contient aucun secret ni code restreint avant de le coller
- Donnez au modèle l'intention du changement pour qu'il puisse juger de la correction, pas seulement du style
- Triez vous-même les constats — écartez les faux positifs et corrigez les vrais
- Envoyez le changement amélioré à un relecteur humain ; la passe IA complète la relecture, elle ne la remplace pas
Attention à
Les relecteurs IA ratent de vrais bugs tout en en inventant qui n'existent pas — environ un quart des développeurs estiment qu'à peu près une suggestion IA sur cinq est fausse ou trompeuse, et même les développeurs qui voient rarement des erreurs ne fusionnent pas sans relecture humaine. Ne laissez jamais une passe IA se substituer à un relecteur humain ou à votre propre jugement.
Ne collez pas dans un outil grand public du code couvert par un accord de confidentialité, des données clients ou des identifiants pour obtenir une relecture. Utilisez un outil entreprise approuvé, et rappelez-vous que le diff fusionné est de votre responsabilité, pas celle du modèle.
Le modèle peut citer une bonne pratique ou une norme de codage qui n'existe pas. Vérifiez toute règle qu'il invoque auprès d'une source réelle avant d'agir en conséquence.
D’où ça vient
Chaque cas d’usage de ce site s’appuie sur des témoignages réels rapportés par les développeurs en exercice — rien n’est inventé par nous.
Plus de cas d’usage de l’IA pour les développeurs
Faire expliquer un code inconnu avant de le modifier
automatisationGénérer des tests unitaires que vous validez ensuite par rapport à la spécification
analyseDéboguer avec la méthode du canard en plastique un problème qui vous résiste
rédactionTransformer une décision en ADR ou dans la documentation que vous aviez sautée
communicationRédiger des messages de commit et des descriptions de PR à partir de votre diff
← Les 6 cas d’usage : comment les développeurs utilisent l’IA