Retour aux articles

Apprendre avec l'IA sans créer de dette cognitive

10 min de lecture
iaapprentissageproductiviteeducationdeveloppeursagents-iametacognitioncognitive-debt

L'IA ne nous rend pas automatiquement meilleurs. Elle amplifie surtout la méthode avec laquelle on l'utilise pour apprendre.

Avec une bonne méthode, elle devient un partenaire d'entraînement redoutable — un coach disponible 24/7, capable d'expliquer une notion sous trois angles, de générer des exercices ciblés, de pointer ce qui cloche dans un raisonnement. Avec une mauvaise méthode, elle devient une béquille très confortable. Et c'est probablement là que le risque est le plus sous-estimé : pas dans le scénario spectaculaire d'une IA hors de contrôle, mais dans le scénario discret d'utilisateurs qui ne savent plus faire sans elle.

Le problème n'est pas d'utiliser l'IA pour apprendre. Le problème, c'est de l'utiliser pour éviter d'apprendre.

L'IA ne remplace pas l'apprentissage, elle révèle la méthode

Il y a une confusion qu'on voit revenir partout : confondre le résultat produit et la compétence acquise.

Un texte bien rédigé, un bout de code qui compile, une réponse plausible à une question d'examen — ce sont des résultats. Et un LLM peut produire ces résultats sans que la personne en face ait construit le modèle mental qui va avec. Sur le moment, tout semble fonctionner. Le devoir est rendu, la fonctionnalité tourne, la copie est cohérente.

Mais les lacunes s'accumulent dans l'ombre. Un étudiant peut rendre un devoir généré sans avoir compris le sujet. Un développeur junior peut livrer du code qu'il ne saura pas débugger trois semaines plus tard. Un profil non technique peut "manager" une IA sans savoir distinguer une bonne réponse d'une réponse seulement plausible.

Le plus piégeux : plus l'outil est performant, plus l'illusion de compétence est crédible. Quand la sortie est presque toujours correcte, on arrête de la questionner. Et c'est précisément à ce moment qu'on cesse d'apprendre.

La dette cognitive : le vrai risque discret

Le parallèle avec la dette technique est utile. Une dette technique, ce n'est pas un crash. C'est un raccourci pris aujourd'hui qui rendra demain plus coûteux. Sur le moment, tout marche. On n'en paie le prix que quand on essaie d'évoluer, de refactor, ou de comprendre ce qu'on a écrit six mois plus tôt.

La dette cognitive fonctionne pareil. Chaque fois qu'on laisse l'IA faire à la place de — plutôt que réfléchir avec — on s'épargne un effort. Cet effort, c'est précisément celui qui construit la compétence. La déléguer ne supprime pas l'apprentissage : elle le décale, et souvent elle l'annule.

L'étude Your Brain on ChatGPT du MIT Media Lab donne un signal intéressant sur ce point. Les chercheurs ont fait écrire des essais à trois groupes — un groupe assisté par LLM, un groupe avec un moteur de recherche, un groupe sans aide ("brain-only") — en mesurant l'activité cérébrale par EEG. Résultat : le groupe brain-only montre les réseaux neuraux les plus forts et les plus distribués pendant la tâche. Le groupe moteur de recherche se situe au milieu. Le groupe LLM affiche la connectivité la plus faible, et fait état du plus bas sentiment de propriété sur le texte produit — au point d'avoir du mal à citer précisément ce qu'il a "écrit".

Il faut manier ce résultat avec prudence : le contexte est spécifique (écriture d'essais éducatifs, 54 participants), et il ne dit pas que l'IA "rend idiot". Il dit autre chose, plus subtil : quand on délègue la production, on délègue aussi une partie de l'effort cognitif qui aurait permis de s'approprier le sujet. C'est exactement ce qu'un survey récent ("Thinking Less, Trusting More", 299 étudiants STEM) appelle un cognitive debt cycle : un usage routinier de l'IA, associé à un haut niveau de confiance dans ses réponses, corrèle avec un engagement cognitif plus faible.

Encore une fois, ces résultats ne ferment pas le sujet. Ils invitent simplement à regarder comment on utilise l'outil, pas seulement combien.

Apprendre demande trois boucles, pas une

La vidéo récente de Micode sur l'IA et l'apprentissage rappelle quelque chose de très simple, qu'on a tendance à oublier dès qu'on parle d'outils : apprendre, ce n'est pas un seul geste. C'est trois boucles imbriquées.

  1. La théorie : aller chercher l'information, comprendre les concepts, construire une carte du domaine.
  2. La pratique : essayer soi-même, se planter, recommencer, ressentir la friction du sujet.
  3. La métacognition : revenir sur ce qu'on a fait, comprendre pourquoi ça a marché ou pas, ajuster sa méthode.

C'est cette troisième boucle qu'on oublie le plus souvent. Micode la résume bien : "la pensée qu'on est capable d'avoir sur notre propre pensée". C'est elle qui transforme une expérience isolée en compétence transférable. Sans métacognition, on peut obtenir un bon résultat sans rien avoir vraiment appris. On a "résolu" l'exercice — on ne saura pas en résoudre un suivant légèrement différent.

Un bon professeur intervient aux trois étapes : il enseigne la théorie, il fait pratiquer, et — souvent l'étape la plus précieuse — il aide à corriger, comparer, raisonner sur l'erreur.

L'IA peut intervenir aux trois étapes aussi. Elle peut expliquer la théorie sous plusieurs angles, proposer des exercices, et discuter une erreur avec un niveau de patience qu'un professeur humain ne peut pas toujours offrir. Mais elle peut aussi court-circuiter ces trois boucles d'un coup, en donnant directement la réponse. Tout dépend de comment on l'utilise — et c'est exactement là que la méthode compte plus que l'outil.

Juniors, étudiants, autodidactes : le danger de déléguer trop tôt

Dans le code, on voit déjà cette distinction se cristalliser.

Un développeur senior peut déléguer beaucoup à l'IA, parce qu'il sait relire, simplifier, refuser, tester, corriger. Il ne suit pas l'outil aveuglément. Il l'encadre. Quand l'agent propose un design étrange, il le rejette. Quand le code compile mais sent mauvais, il le réécrit. Sa compétence préexiste à l'outil — l'IA agit comme un amplificateur.

Un junior qui délègue trop tôt risque l'inverse : il pilote une machine qu'il ne sait pas encore juger. Le code produit semble correct, donc il le commit. Trois bugs plus tard, il se retrouve devant un code qu'il n'a pas écrit, qu'il ne comprend pas, et qu'il doit pourtant maintenir. Le synthèse "Protecting Human Cognition in the Age of AI" (2025) le dit explicitement : le risque d'over-reliance est largement supérieur chez les novices, parce qu'ils n'ont pas encore le bagage pour vérifier la sortie.

Ça ne veut pas dire qu'il faut interdire l'IA aux juniors. Ce serait à la fois absurde, contre-productif et de toute façon impossible. Mais ça demande une méthode. Le bon réflexe n'est pas "l'IA m'a donné une réponse, je passe au suivant". C'est "l'IA m'a donné une réponse, est-ce que je la comprends, est-ce que je saurais la défendre, est-ce que je peux la modifier ?". Tant qu'on ne peut pas répondre oui aux trois, on n'a pas appris — on a juste produit.

Transformer l'IA en coach plutôt qu'en machine à réponses

C'est exactement le pari du skill /teach de Matt Pocock, et c'est ce qui le rend intéressant comme exemple concret.

Matt Pocock maintient un repo de skills — des petites méthodes composables, utilisables avec n'importe quel agent (Claude Code, Codex, ou autres) — qui visent à corriger les failure modes récurrents des agents : court-circuit du diagnostic, absence de feedback loops, perte de contexte, sur-engagement. L'angle est clair : ce ne sont pas des "prompts magiques", ce sont des méthodes qui réinjectent dans l'agent les fondamentaux d'une bonne pratique d'ingénierie.

/teach applique cette logique à l'apprentissage. L'idée n'est pas de transformer l'agent IA en machine à réponses. L'idée est d'en faire un environnement d'apprentissage persistant.

Concrètement, le skill s'appuie sur un workspace local avec une structure simple :

  • une mission (MISSION.md) reliée à un objectif réel — pas "apprendre Python", mais "savoir écrire un script qui traite mes CSV de facturation".
  • des ressources (RESOURCES.md) — livres, vidéos, docs — auxquelles l'agent peut renvoyer plutôt que d'inventer.
  • des learning records — la trace de ce qui a été abordé, compris, ou encore fragile.
  • des leçons courtes et ciblées, calibrées dans ce que la psychologie de l'apprentissage appelle la zone proximale de développement : ni trop facile, ni trop dur, juste assez inconfortable pour apprendre.
  • des références réutilisables que l'apprenant peut relire en autonomie.
  • des notes sur les préférences et le niveau (NOTES.md) que l'agent met à jour au fil des sessions.

Ce détail change beaucoup de choses. L'agent ne repart pas de zéro à chaque session. Il retrouve où vous en êtes, ce que vous avez compris, ce qui reste fragile. Il peut s'appuyer sur des principes que la recherche en pédagogie a validés depuis longtemps — retrieval practice (se forcer à rappeler avant de relire), spacing (espacer les révisions), interleaving (alterner les sujets), desirable difficulty (la difficulté qui aide à apprendre, par opposition à celle qui décourage).

La distinction la plus utile que le skill explicite : fluency strength vs storage strength. La fluidité ("je viens de le lire, je m'en souviens") n'est pas la même chose que la rétention durable. On peut être fluide sur un sujet pendant 20 minutes et avoir tout oublié une semaine plus tard. La vraie cible, c'est la rétention long terme — et elle se construit avec de la friction utile.

C'est exactement la différence entre une IA utilisée comme béquille et une IA utilisée comme partenaire d'entraînement.

Une règle simple : savoir expliquer, refaire ou corriger

À titre individuel, on n'a pas besoin d'un skill élaboré pour s'astreindre à une bonne méthode. Une question suffit.

La bonne question, ce n'est pas : "Est-ce que l'IA m'a donné la bonne réponse ?". C'est :

"Est-ce que je saurais expliquer, refaire ou corriger ce résultat sans elle ?"

On peut décliner cette question en une petite checklist concrète, à se poser chaque fois qu'on s'apprête à valider une sortie d'agent :

  • Expliquer : est-ce que je peux décrire ce que fait ce code (ou ce raisonnement), ligne par ligne, à quelqu'un qui n'a pas vu la conversation ?
  • Refaire : si je devais résoudre un problème similaire demain, sans l'agent, est-ce que j'aurais le squelette de la solution en tête ?
  • Corriger : si on me dit "il y a un bug ici", est-ce que je sais par où commencer à investiguer ?
  • Identifier les limites : est-ce que je vois dans quels cas cette solution ne marcherait plus ? Qu'est-ce que l'agent a choisi sans me le dire ?

Si la réponse aux quatre est non, ce n'est pas grave en soi. Mais c'est probablement le signal que l'apprentissage doit commencer là, pas plus loin. Plutôt que de passer à la tâche suivante, on revient en arrière : on demande à l'agent d'expliquer, on essaie de reproduire à la main, on lance des tests, on casse exprès pour voir ce qui pète.

L'enjeu n'est pas d'utiliser moins d'IA. L'enjeu est de mieux apprendre avec. La vraie productivité long terme, dans un monde où ces outils sont partout, viendra de ceux qui savent maintenir leur compétence — pas de ceux qui produisent le plus vite à court terme.

L'IA est une excellente prof. Encore faut-il accepter de rester l'élève.

Références