Transformez l'IA en relecteur exigeant sur la lisibilité, les bugs et la sécurité, et musclez votre jugement en défendant vos choix face à ses remarques.
Ouvrir cette leçon dans KodokonLa revue de code par des pairs est l'un des accélérateurs de progression les plus documentés du métier - et l'un des plus difficiles d'accès quand on travaille seul. L'IA offre un relecteur disponible en permanence, à une condition : la configurer. Par défaut, un modèle est complaisant : il salue vos efforts, signale deux broutilles et conclut que « globalement, c'est du bon travail ». Ce n'est pas une revue, c'est une caresse. Le mauvais usage, symétrique, consiste à demander « réécris mon code proprement » : vous obtenez du code que vous n'avez pas pensé, et vous n'apprenez rien. Le bon usage : exiger une critique structurée - lisibilité, bugs, sécurité - avec sévérité calibrée et justifications.
Tu es un relecteur senior exigeant, comme lors d'une revue de code en équipe. Ton objectif est de me faire progresser, pas de me ménager.
Voici mon code ([langage], contexte : [à quoi il sert, contraintes du projet]) :
[coller le code]
Analyse-le selon trois axes :
1. Lisibilité : nommage, structure, complexité inutile, intentions obscures.
2. Bugs : cas limites non gérés, erreurs silencieuses, états incohérents, concurrence.
3. Sécurité : entrées non validées, injections, données sensibles exposées, permissions.
Format de sortie : pour chaque remarque - la ligne ou le bloc concerné, l'axe, la sévérité (bloquant / important / mineur), et le POURQUOI en une ou deux phrases.
Contraintes : ne réécris pas mon code. Maximum 8 remarques, les plus graves d'abord. Si un choix discutable peut se défendre selon le contexte, dis-le explicitement au lieu de le compter comme un défaut.Notez le plafond de 8 remarques classées par gravité : sans lui, vous recevez 25 points de détail où l'oubli d'une validation d'entrée pèse autant qu'une préférence de nommage. Notez aussi la clause sur les choix défendables : elle force le modèle à distinguer le défaut objectif de la convention discutable. Vient ensuite la partie la plus formatrice, celle que presque tout le monde saute : défendre ses choix. Une revue n'est pas un verdict à appliquer, c'est un dialogue. Quand une remarque vous semble injustifiée, argumentez. Soit vos raisons tiennent et vous les avez enfin explicitées, soit elles s'effondrent et vous découvrez que ce « choix » n'était qu'une habitude.
Reprenons ta remarque numéro [X] : tu considères que [reformuler la remarque].
Je ne suis pas d'accord, et voici mes raisons : [vos arguments - contrainte de performance mesurée, cohérence avec le reste du code, simplicité volontaire, délai...].
1. Évalue honnêtement chacun de mes arguments : lesquels tiennent, lesquels sont des rationalisations ?
2. Donne le meilleur contre-argument possible à ma position, comme le ferait un collègue expérimenté en désaccord.
3. Conclus : dans MON contexte précis, le changement vaut-il son coût ? Réponds par oui ou non, puis justifie en trois phrases maximum.
Ne cherche pas à me donner raison : si mes arguments sont faibles, dis-le sans détour.Deux pièges classiques de la revue par IA. Premier piège : les fausses alertes assénées avec assurance - le modèle signale une condition de course impossible dans votre architecture, ou un « bug » qui n'en est pas un dans votre version du langage. Traitez chaque remarque comme celle d'un collègue brillant mais qui n'a pas accès à tout le contexte : plausible, à vérifier. Second piège : la sécurité en trompe-l'œil. L'IA repère très bien les motifs classiques (injection SQL, XSS, secrets en clair) mais passe à côté des failles de logique métier - un contrôle d'autorisation manquant sur une route, un état intermédiaire exploitable. Une revue IA complète, elle ne remplace ni un audit ni votre connaissance du domaine.