Quand vous apprenez à coder, le programme que vous terminez n'est qu'un effet secondaire. Ce que vous construisez, c'est un modèle mental : une image, dans votre tête, de ce que fait le code et de la raison pour laquelle il casse. L'IA peut produire le code en quelques secondes. Elle ne peut pas construire cette image à votre place. Si vous la laissez réfléchir pendant que vous apprenez, vous vous retrouvez avec des programmes qui fonctionnent et une compréhension superficielle de ces programmes. Le manque se révèle plus tard, quand quelque chose casse.
En bref
- Un code qui fonctionne peut donner l'impression de comprendre. Des débutants déjà en difficulté ont parfois terminé une tâche assistée par l'IA avec « une illusion de compétence », convaincus d'avoir mieux réussi qu'en réalité (Prather et al., ICER, 2024).
- Vous retenez moins ce que vous n'avez pas produit. Des personnes qui avaient rédigé des essais avec un LLM avaient du mal à citer leur propre texte quelques minutes plus tard, dans une étude qui n'a pas encore été évaluée par les pairs (Kosmyna et al., MIT Media Lab, 2025).
- Le délestage va de pair avec un esprit critique plus faible. Dans une étude portant sur 666 personnes, un usage plus intensif de l'IA était corrélé à un esprit critique plus faible, et le délestage cognitif jouait statistiquement le rôle de médiateur de ce lien (Gerlich, Societies, 2025).
- Les postes de débutant évoluent. L'emploi des développeurs de 22 à 25 ans a baissé de près de 20 % entre son pic de fin 2022 et septembre 2025 (Stanford Digital Economy Lab, 2025).
- Vos habitudes gardent la réflexion de votre côté. Essayez d'abord, demandez des indices plutôt que des réponses, réexpliquez le résultat, puis réécrivez-le à partir d'un fichier vide le lendemain.
Que signifie externaliser son cerveau à l'IA ?
Externaliser son cerveau, c'est laisser l'IA faire le travail mental que l'exercice est censé vous faire faire. Les psychologues appellent cela le délestage cognitif : confier à un outil une réflexion que vous auriez faite vous-même. Une calculatrice le fait pour l'arithmétique, une application de cartographie le fait pour l'itinéraire. Un développeur expérimenté peut déléguer le boilerplate sans grand coût, parce que la compréhension est déjà là. Pour quelqu'un qui apprend, ce travail mental est justement ce qui forge la compétence. Le déléguer vous laisse avec le résultat, et pas grand-chose d'autre.
La question plus précise de savoir quand taper le code vous-même et quand accepter une suggestion a son propre article, Faut-il encore écrire du code à la main ?, qui passe en revue les essais contrôlés. Ici, la question est ce qui se passe dans votre tête quand vous apprenez avec un assistant, et ce que cela vous coûtera dans un an.
Pourquoi un code qui fonctionne donne-t-il l'impression de comprendre ?
Votre cerveau évalue votre compréhension en partie selon la fluidité avec laquelle les choses se déroulent, et l'IA rend tout fluide. Vous collez un prompt, vous obtenez du code, il s'exécute. Il est facile de confondre cette aisance avec de la compétence.
Les chercheurs en sciences de l'apprentissage mesurent cet écart depuis des décennies. Nicholas Soderstrom et Robert Bjork ont passé en revue la recherche et conclu que la performance pendant l'entraînement « est souvent un indicateur peu fiable » de l'apprentissage réel. Ils ont aussi constaté que « les gens interprètent souvent à tort leur performance pendant l'acquisition comme un guide fiable de l'apprentissage à long terme » (Soderstrom & Bjork, Perspectives on Psychological Science, 2015). Les conditions qui paraissent difficiles sur le moment, comme se remémorer une information au lieu de la relire, produisent souvent un apprentissage plus durable. Le laboratoire de Bjork les appelle des « difficultés désirables » (Bjork Learning and Forgetting Lab).
Les études sur l'usage de l'IA publiées en 2024 et 2025 vont dans le même sens.
Les débutants en difficulté peuvent finir avec une illusion de compétence
James Prather et ses collègues ont observé des programmeurs débutants résoudre un problème avec une IA générative à disposition, en combinant observation, entretiens et eye tracking sur 21 sessions en laboratoire. Vingt des 21 étudiants ont terminé le problème. Les étudiants déjà en difficulté avaient des problèmes métacognitifs au départ, et l'IA « peut les aggraver, voire introduire de nouvelles difficultés métacognitives ». Plusieurs d'entre eux « pensaient avoir mieux réussi qu'en réalité, et ont terminé avec une illusion de compétence » (Prather et al., ICER, 2024). Les étudiants dotés de meilleures compétences métacognitives, eux, utilisaient bien l'IA, d'où le titre de l'article, « The Widening Gap ».
Les développeurs expérimentés se trompent aussi. Dans l'essai de METR en 2025, ils ont mis 19 % de temps en plus avec l'IA tout en pensant être 20 % plus rapides (METR, 2025), un résultat détaillé dans Faut-il encore écrire du code à la main ?. Si des personnes qui ont des années d'expérience évaluent mal leurs propres progrès, un débutant dispose d'encore moins de repères.
Moins d'effort fourni, moins de souvenirs
Des chercheurs du MIT Media Lab ont demandé à 54 personnes de rédiger des essais avec un LLM, avec un moteur de recherche ou sans aucun outil, tout en enregistrant leur activité cérébrale par EEG. Le groupe sans outil présentait les réseaux cérébraux les plus actifs et les plus largement connectés. Les utilisateurs du moteur de recherche se situaient au milieu, et les utilisateurs du LLM montraient la connectivité la plus faible. Les utilisateurs du LLM avaient aussi « du mal à citer correctement leur propre travail », des essais qu'ils avaient écrits quelques minutes plus tôt (Kosmyna et al., MIT Media Lab, 2025). L'étude est une prépublication qui n'a pas encore été évaluée par les pairs, il faut donc la considérer comme une preuve préliminaire. Elle portait sur des essais, pas sur du code, mais le mécanisme est celui dont parle cet article : vous retenez moins ce que vous n'avez pas produit.
Une enquête de plus grande ampleur aboutit à un constat proche. Michael Gerlich a étudié 666 personnes et constaté « une corrélation négative significative entre l'utilisation fréquente d'outils d'IA et les capacités d'esprit critique, médiée par un délestage cognitif accru ». Les participants les plus jeunes s'appuyaient davantage sur l'IA et obtenaient des scores plus faibles (Gerlich, Societies, 2025). L'étude est corrélationnelle, elle ne prouve donc pas que l'IA affaiblit la réflexion. Elle montre en revanche que les personnes qui déclarent déléguer davantage obtiennent aussi des scores plus faibles en esprit critique.
Quand le raccourci se retourne-t-il contre vous ?
Vous ne remarquez pas la compréhension que vous avez sautée le jour où vous la sautez. Vous la remarquez plus tard, quand l'IA ne suffit pas ou n'est pas là.
Déboguer une panic que vous n'avez jamais comprise
Imaginons qu'un assistant ait écrit le cache en mémoire de votre premier service Go, avec un constructeur NewCache qui initialise tout, et qu'il ait passé tous les tests. Puis un nouveau chemin de code construit directement la struct :
example.gogotype Cache struct { items map[string]string } func (c *Cache) Set(key, value string) { c.items[key] = value } func main() { c := &Cache{} c.Set("session:42", "user-1893") }
example.texttextpanic: assignment to entry in nil map
Si vous aviez écrit des maps à la main quelques dizaines de fois, vous reconnaîtriez immédiatement le problème. La valeur zéro d'une map est nil. Lire dans une map nil fonctionne, mais y écrire provoque une panic. La correction consiste à rendre la valeur zéro utilisable avec une vérification de nil dans Set (c.items = make(map[string]string)), ou, si le cache vit dans son propre package, à garder items non exporté et à documenter que les appelants doivent passer par NewCache. var vs make en Go explique pourquoi la valeur zéro se comporte ainsi. Si vous n'aviez jamais fait qu'accepter du code de map, vous auriez sous les yeux une panic sur une ligne qui paraît tout à fait normale, sans aucune idée de par où commencer.
Une question de code review à laquelle vous ne savez pas répondre
Un relecteur vous demande pourquoi votre handler utilise un receiver pointeur, ou pourquoi vous passez un context.Context à une fonction qui ne le lit jamais. Si vous avez écrit le code, vous pouvez répondre, même si la réponse est « je me suis trompé ». Si vous l'avez accepté, vous n'avez rien à dire. Le même manque apparaît en entretien de live coding, où vous devez expliquer votre raisonnement pendant que vous tapez.
Lire une base de code que vous n'avez pas écrite
Un nouveau développeur passe une bonne partie de son temps à lire le code des autres : suivre une requête à travers les middlewares, trouver où une valeur de configuration est définie, comprendre pourquoi un worker pool a la taille qu'il a. L'IA peut résumer un fichier. Savoir où regarder ensuite vient du fait d'avoir écrit du code similaire et de se souvenir de l'endroit où vous aviez rangé les choses.
Pourquoi la compréhension compte-t-elle davantage aujourd'hui pour les développeurs juniors ?
Une raison probable est que les tâches que l'IA gère bien recoupent celles pour lesquelles on recrutait autrefois des juniors. Le Digital Economy Lab de Stanford a constaté que l'emploi des développeurs de 22 à 25 ans avait baissé de près de 20 % entre son pic de fin 2022 et septembre 2025, alors que l'emploi des profils plus expérimentés restait stable (Brynjolfsson, Chandar & Chen, Stanford Digital Economy Lab, 2025). La révision d'août 2026 situe l'emploi des jeunes travailleurs dans les métiers exposés à l'IA 19 % en dessous de ce qu'il aurait été autrement (Brynjolfsson, Chandar & Chen, 2026).
Les auteurs précisent que d'autres facteurs que l'IA peuvent jouer un rôle. Selon leur explication, l'IA « automatise peut-être les tâches codifiables et vérifiables qui justifiaient historiquement les postes de débutant », et elle « est peut-être moins capable de remplacer les connaissances tacites ». Les connaissances tacites, c'est la compréhension qu'on n'acquiert qu'en faisant le travail, et savoir pourquoi un code généré est juste ou faux en fait partie.
Pourquoi la difficulté productive est-elle le vrai travail ?
Le modèle mental se construit pendant que vous êtes bloqué. Vous ne comprenez pas, vous formulez une hypothèse, vous la testez, et souvent elle est fausse. Ces minutes semblent perdues, mais c'est là que vous apprenez.
Prenons un vrai bug. Vous écrivez une fonction qui récupère plusieurs URL en concurrence et qui s'arrête dès que l'une d'elles échoue :
example.gogotype result struct { body string err error } func fetchAll(ctx context.Context, urls []string) ([]string, error) { results := make(chan result) for _, u := range urls { go func() { body, err := fetch(ctx, u) results <- result{body, err} }() } var bodies []string for range urls { r := <-results if r.err != nil { return nil, r.err } bodies = append(bodies, r.body) } return bodies, nil }
Les tests passent. Une semaine plus tard, la mémoire du service grimpe lentement jusqu'à ce qu'il redémarre. Le résoudre à la main se passe à peu près comme ceci. Vous vérifiez runtime.NumGoroutine() et vous voyez le nombre augmenter. Vous prenez un profil des goroutines et vous trouvez des centaines de goroutines bloquées sur la même ligne, results <- result{body, err}. Vous vous demandez qui est censé recevoir sur ce channel, et la réponse est personne, parce que fetchAll est sortie à la première erreur. Le channel n'a pas de buffer, donc chaque émetteur restant est bloqué pour toujours.
La correction rapide tient en une ligne, results := make(chan result, len(urls)), pour que chaque goroutine puisse envoyer sa valeur et se terminer, que quelqu'un la lise ou non. Une meilleure correction annule aussi le context pour que les autres requêtes s'arrêtent plus tôt. Chercher cette ligne vous a appris plus que la ligne elle-même : un envoi sur un channel sans buffer attend un récepteur, un return anticipé peut laisser des goroutines en plan, et un profil des goroutines vous montre où elles sont bloquées. Un assistant aurait pu vous donner la version corrigée du premier coup, et vous auriez eu un code correct sans rien apprendre de tout cela. Le cours Concurrency Fundamentals vous fait écrire et corriger du code de channel qui se bloque de cette façon.
Comment apprendre à coder avec l'IA sans externaliser votre cerveau ?
Traitez l'IA comme un collègue senior patient. Quand vous êtes bloqué, demandez-lui des explications ou faites-lui vérifier votre raisonnement, et gardez l'exercice lui-même pour vous.
Essayez d'abord, avec une limite de temps
Accordez-vous 20 à 30 minutes sur un problème avant de demander de l'aide. Notez ce que vous avez essayé et l'endroit où vous avez bloqué. Cette note sert à deux choses : elle vous oblige à formuler clairement le problème, et elle donne à l'IA assez de contexte pour proposer un indice plutôt qu'une solution complète.
Demandez des indices, pas des solutions
Dites à l'assistant quel rôle jouer. Souvent, une seule phrase sépare un prompt qui fait le travail à votre place d'un prompt qui vous fait travailler :
| Prompt qui fait le travail à votre place | Prompt qui vous fait travailler |
|---|---|
| « Corrige cette panic de map nil. » | « J'apprends Go. N'écris pas de code. Donne-moi un seul indice sur la raison de cette panic, et pose-moi une question qui m'oriente vers la cause. » |
| « Réécris cette fonction pour qu'elle ne fasse plus fuir de goroutines. » | « Voici ma fonction. Ne la réécris pas. Quelle ligne regarderais-tu en premier si elle faisait fuir des goroutines sous charge, et pourquoi ? » |
| « Écris un worker pool en Go. » | « Je vais écrire un worker pool. Que dois-je décider avant de commencer, et qu'est-ce qui se passe mal en général ? » |
| « Explique-moi les maps en Go. » | « Pose-moi trois questions sur les maps en Go. Attends ma réponse avant de me dire si j'ai raison. » |
Dans la colonne de droite, l'IA explique ou pose des questions, et c'est toujours vous qui écrivez le code.
Réexpliquez le code avec vos propres mots
Si vous prenez du code chez un assistant, ne passez pas à la suite avant de pouvoir expliquer chaque ligne. Écrivez l'explication en commentaires, ou dites-la à voix haute. La ligne que vous ne savez pas expliquer est celle qu'il faut aller apprendre. Expliquer est aussi le moyen le plus rapide de savoir si vous avez compris quelque chose ou si vous l'avez seulement reconnu.
Réécrivez-le à partir d'un fichier vide le lendemain
Fermez le fichier, ouvrez-en un vide le lendemain et réécrivez la solution sans regarder. Ce sera plus lent, et vous bloquerez à certains endroits. Ces endroits sont ce que vous n'aviez pas encore appris. C'est la même pratique de récupération qui fait fonctionner les flashcards, appliquée au code.
Tenez l'IA à l'écart de la phase des fondamentaux
Pendant vos premières semaines avec un langage, écrivez les fondamentaux sans assistant : variables, boucles, slices, maps, structs, erreurs et vos premières goroutines. À ce stade, l'autocomplétion par IA remplit chaque ligne avant que vous ayez eu le temps d'y réfléchir vous-même. Une fois que les bases sont devenues automatiques, reprenez les outils pour les parties que vous comprenez déjà. Apprendre à coder en 2026 propose un plan plus complet pour cette première période, et 13 erreurs de débutant en programmation couvre les habitudes qui rendent n'importe quel code, généré ou non, plus difficile à déboguer.
LevelUpGo est construit autour du fait d'écrire le code vous-même. Chaque exercice place le concept à côté d'un vrai éditeur Go sans complétions IA, et il n'est validé qu'une fois que votre code compile et passe les tests. Commencez par les leçons gratuites de Go Basics, le premier cours du parcours Go Fundamentals. Entretenez ensuite la compétence avec les exercices indépendants du Training Ground.
Questions fréquentes
Est-ce tricher d'utiliser ChatGPT pour apprendre à coder ?
Ce n'est pas tricher, sauf si votre formation dit le contraire. Le risque est de sauter ce que l'exercice devait vous apprendre. Demander à une IA d'expliquer une erreur ou un concept revient à demander à un tuteur. Lui demander d'écrire la solution signifie que l'exercice n'entraîne plus rien.
Comment savoir si je comprends vraiment le code écrit par une IA ?
Essayez de le modifier sans aide. Ajoutez une fonctionnalité, gérez un nouveau cas limite ou dites ce qui se passe si l'on supprime une ligne. Si vous pouvez prédire ce que fera le code avant de l'exécuter, vous le comprenez. Si vous pouvez seulement l'exécuter pour voir, vous l'avez reconnu. Sur le moment, la reconnaissance donne l'impression de comprendre, et c'est exactement l'écart que décrivent Soderstrom et Bjork (Soderstrom & Bjork, 2015).
Qu'est-ce que le délestage cognitif en programmation ?
C'est laisser une IA décider de la structure, de l'algorithme ou de la correction au lieu de les trouver vous-même. C'est efficace une fois que vous maîtrisez la compétence. Tant que vous êtes encore en train de la construire, le délestage remplace la pratique, et la recherche associe un délestage plus important à un esprit critique plus faible (Gerlich, 2025).
À partir de quand un débutant peut-il utiliser librement les outils de code IA ?
Dès que vous savez écrire les bases sans rien chercher : boucles, fonctions, maps, structs, gestion des erreurs et un handler HTTP simple. À partir de là, l'IA vous accélère sur un travail que vous comprenez déjà. Revenez à l'écriture à la main chaque fois que vous abordez quelque chose de nouveau, comme votre premier code concurrent ou votre première couche d'accès à la base de données.
L'IA va-t-elle remplacer les développeurs juniors ?
La recherche indique une voie claire pour rester précieux. Les chercheurs de Stanford suggèrent que l'IA prend en charge les tâches codifiables et vérifiables, et qu'elle est moins apte à remplacer les connaissances tacites, cette compréhension qu'on n'acquiert qu'en faisant le travail (Stanford Digital Economy Lab, 2025). Cette partie-là dépend de vous. Un junior capable de déboguer, de relire et d'expliquer ce qu'écrit une IA apporte ce que l'outil n'apporte pas, et gagne en plus en vitesse grâce à l'IA.
Sources
- Prather et al., "The Widening Gap: The Benefits and Harms of Generative AI for Novice Programmers," ICER (2024) : https://arxiv.org/abs/2405.17739
- METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" (2025) : https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
- Kosmyna et al., "Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task," prépublication du MIT Media Lab (2025) : https://arxiv.org/abs/2506.08872
- Gerlich, "AI Tools in Society: Impacts on Cognitive Offloading and the Future of Critical Thinking," Societies 15(1) (2025) : https://doi.org/10.3390/soc15010006
- Brynjolfsson, Chandar & Chen, "Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence," Stanford Digital Economy Lab (2025, révisé en 2026) : https://digitaleconomy.stanford.edu/publications/canaries-in-the-coal-mine/
- Soderstrom & Bjork, "Learning versus performance: An integrative review," Perspectives on Psychological Science (2015) : https://doi.org/10.1177/1745691615569000
- Bjork Learning and Forgetting Lab, présentation des recherches sur les difficultés désirables : https://bjorklab.psych.ucla.edu/research/
