Utiliser Claude Code ou Codex comme professeur, pas comme pilote automatique

TL;DR

Pour apprendre, ne demande pas systématiquement la solution. Demande une question, un indice, une comparaison ou une revue. L’agent devient réellement utile lorsqu’il s’adapte à ta compréhension et te force à formuler ton propre raisonnement.

Le meilleur professeur n’écrit pas toujours la réponse au tableau

Un agent de code sait produire rapidement une implémentation complète. C’est précisément pour cette raison qu’il faut parfois lui demander de ne pas le faire.

Si tu bloques sur la récupération des métriques de notre dashboard, la demande la plus rapide serait :

Écris la fonction qui récupère les métriques et affiche-les dans React.

Tu obtiendras probablement du code. Mais le blocage initial restera intact : où récupérer les données, comment représenter leur état et comment gérer une erreur ?

Un usage pédagogique commence par rendre ce blocage visible.

Le mode socratique : l’agent pose les questions

Je veux récupérer les métriques du serveur et les afficher dans le dashboard.
Ne donne pas la solution et ne modifie aucun fichier.

Pose-moi une question à la fois pour vérifier que je comprends :
- où effectuer l’appel ;
- comment représenter chargement, succès et erreur ;
- pourquoi une réponse TypeScript ne suffit pas à valider les données reçues.

Après chacune de mes réponses, corrige uniquement les incompréhensions importantes.

Cette méthode oblige le junior à récupérer ce qu’il sait déjà. Elle montre aussi précisément où commence l’incertitude.

Demander des indices progressifs

Une réponse complète est parfois nécessaire. Elle ne devrait pas être le premier niveau d’aide.

Je suis bloqué sur cette erreur.

Ne corrige pas le code immédiatement.
Donne-moi :
1. une question d’orientation ;
2. si je bloque encore, un indice conceptuel ;
3. ensuite seulement, un petit exemple indépendant ;
4. ne fournis la correction de mon fichier qu’à ma demande explicite.

L’agent devient alors un système d’échafaudage. L’aide augmente uniquement lorsque la tentative personnelle ne suffit plus.

Montrer sa tentative, même mauvaise

Une première version imparfaite est une excellente matière pédagogique :

export async function getMetrics() {
  const response = await fetch('/api/metrics')
  return response.json()
}

Au lieu de demander « améliore ce code », demande :

Voici ma première tentative.

Commence par reformuler ce que mon code fait réellement.
Indique ensuite :
- ce qui est correct ;
- les deux risques les plus importants ;
- une question qui m’aide à trouver moi-même la prochaine modification.

N’écris pas encore la version finale.

Le junior apprend ainsi que fetch peut échouer, qu’une réponse HTTP non réussie doit être traitée et que response.json() fournit une valeur externe qui nécessite une validation réelle.

Comparer plusieurs solutions

L’IA a tendance à présenter sa première proposition comme naturelle. Le développement contient pourtant des compromis.

Pour la récupération des métriques, demande deux approches : directement dans une page serveur, ou via une route intermédiaire. Puis exige une comparaison selon des critères concrets : simplicité, exposition des secrets, cache, testabilité et gestion des erreurs.

Le but n’est pas de choisir la solution la plus sophistiquée. Il est de comprendre pourquoi une solution convient au contexte actuel.

Faire expliquer le vocabulaire par le code

Les explications abstraites deviennent vite fragiles. Demande à l’agent de relier chaque notion au projet :

Explique la différence entre type statique et validation à l’exécution.

Utilise la réponse de l’API de notre dashboard comme exemple.
Montre ensuite une erreur que TypeScript ne peut pas empêcher seul.
Termine par une question courte pour vérifier ma compréhension.

Une notion est réellement apprise lorsqu’elle peut être reconnue dans un autre contexte, pas lorsqu’une définition a été mémorisée.

Transformer les erreurs en exercices

Après avoir résolu un bug, demande à l’agent de créer une variante :

À partir de l’erreur que nous venons de corriger, crée un exercice de dix minutes.
Change le contexte et les noms pour que je ne puisse pas recopier la solution.
Donne uniquement l’énoncé et les critères de réussite.

Si le problème initial concernait une valeur éventuellement absente, l’exercice peut utiliser un profil utilisateur ou une réponse de paiement. Le principe reste identique, mais le junior doit effectuer le transfert lui-même.

Terminer chaque session par une restitution

À la fin d’une tâche, demande :

Pose-moi cinq questions courtes sur les décisions prises aujourd’hui.
Ne révèle pas les réponses avant ma tentative.
Concentre-toi sur les notions transférables, pas sur les noms de fichiers.

Puis rédige toi-même une note : ce que tu pensais, ce qui était faux, comment tu l’as vérifié et dans quel autre cas cette connaissance pourrait servir.

Quand autoriser l’agent à écrire

Le mode pédagogique ne signifie pas qu’il faut tout taper manuellement pour toujours.

L’agent peut prendre en charge :

• une modification mécanique comprise ;
• la génération d’un squelette validé ;
• l’ajout de cas de test déjà définis ;
• une refactorisation dont les contraintes sont explicites ;
• une tâche répétitive dont le résultat est vérifiable.

Le niveau d’autonomie doit suivre la capacité de contrôle. Plus tu comprends le terrain, plus tu peux déléguer l’exécution sans déléguer la décision.

Le signe que la méthode fonctionne

Au fil des sessions, tes prompts devraient devenir plus précis et parfois plus courts. Tu connais mieux les frontières du problème. Tu repères plus vite une proposition inutile. Tu demandes moins souvent de tout régénérer.

L’objectif n’est pas de devenir indépendant de l’IA. Il est de ne pas devenir impuissant sans elle.

Dans le prochain article, nous verrons comment contrôler concrètement ce que l’agent produit grâce à Git, aux diffs et aux tests.