Cadrez l'IA pour qu'elle évalue votre travail par indices et barème, sans jamais réécrire votre code à votre place.
Ouvrir cette leçon dans KodokonVous avez terminé un exercice et vous voulez savoir ce qu'il vaut. Le réflexe naturel - coller votre code avec "corrige-moi ça" - est une erreur stratégique : l'IA va réécrire votre solution en mieux, vous allez la lire, hocher la tête… et n'avoir rien appris. Une correction utile vous dit où vous vous êtes trompé et vous laisse réparer vous-même. C'est exactement ce qu'il faut exiger.
Tu es un correcteur d'exercices de programmation. Voici l'énoncé, puis ma solution.
Énoncé : [collez l'énoncé ici]
Ma solution : [collez votre code ici]
Règles de correction, absolues :
1. Ne réécris JAMAIS mon code, ni en entier ni par fragments. Pas de version corrigée, même si je la demande.
2. Dis-moi d'abord si ma solution est correcte, partiellement correcte ou incorrecte.
3. Pour chaque problème : indique la ligne concernée et pose-moi une question qui m'oriente, sans donner la correction.
4. Classe les problèmes par gravité : bug réel, puis cas limite oublié, puis style.
5. Quand je te soumets une version corrigée par mes soins, réévalue-la selon les mêmes règles.
S'il n'y a aucun problème, dis-le clairement et propose-moi une contrainte supplémentaire pour rendre l'exercice plus difficile.La hiérarchie de la règle 4 est une habitude directement importée du monde professionnel : dans une revue de code, on distingue toujours ce qui casse (bug), ce qui cassera (cas limite : tableau vide, valeur négative, texte au lieu d'un nombre) et ce qui gêne (style, nommage). Apprendre à trier les retours par gravité vous prépare aux vraies revues de code que vous vivrez en équipe.
Pour aller plus loin qu'un simple "juste ou faux", demandez un barème. Une note décomposée en critères transforme une impression vague en diagnostic précis : vous voyez immédiatement si votre point faible est la correction fonctionnelle, la gestion des cas limites ou la lisibilité - et donc quoi travailler en priorité.
Évalue ma solution avec le barème suivant, sur 20 points :
- Correction fonctionnelle (8 pts) : le code produit-il le résultat attendu dans le cas général ?
- Cas limites (4 pts) : entrée vide, valeurs extrêmes, types inattendus.
- Lisibilité (4 pts) : noms de variables clairs, structure logique, pas de complexité inutile.
- Bonnes pratiques du langage (4 pts) : idiomes appropriés, pas de code redondant.
Pour chaque critère : la note, une justification en deux phrases maximum, et - si des points manquent - un indice pour m'améliorer SANS me donner la correction.
Termine par le point à travailler en priorité pour ma prochaine tentative.Le cycle de travail complet, à retenir comme une routine professionnelle : vous résolvez seul, vous soumettez avec le prompt correcteur, vous recevez des indices localisés, vous corrigez vous-même, vous resoumettez - et seulement quand votre version tient debout, vous pouvez demander : "Maintenant que ma solution est correcte, montre-moi comment un développeur expérimenté l'aurait écrite, et explique chaque différence." À ce stade, comparer ne remplace plus votre apprentissage : il le couronne.