Apprendre à coder avec l'IA : ce que disent les études

Un assistant écrit en dix secondes la fonction qui t'aurait pris une heure. La question vient toute seule : à quoi bon apprendre à l'écrire ? Les avis tranchés ne manquent pas, dans les deux sens. Les mesures sont plus rares, et elles en disent plus qu'un simple oui ou non.

Que montre l'essai randomisé d'Anthropic ?

Qu'apprendre avec un assistant capable d'écrire le code à ta place fait moins bien retenir ce que tu viens de faire. L'étude, menée par Judy Hanwen Shen et Alex Tamkin et publiée le 29 janvier 2026, a réuni 52 participants, surtout des développeurs juniors. Tous utilisaient Python chaque semaine depuis plus d'un an, connaissaient un peu les assistants IA et n'avaient jamais touché à Trio, une bibliothèque Python de programmation asynchrone.

Chacun devait coder deux fonctionnalités avec Trio, puis passer un quiz, en sachant qu'il arriverait. Le tirage au sort décidait du groupe : l'un avait un assistant IA dans la barre latérale, capable de produire le code correct sur demande, l'autre codait seul.

Dix-sept points d'écart, et un écart qui tient au test statistique (p = 0,01). En face, le gain de temps du groupe avec IA était d'environ deux minutes en moyenne, trop faible pour être distingué du hasard. Le quiz mêlait lecture de code, écriture, concepts et débogage, et c'est sur le débogage que les deux groupes s'éloignaient le plus. Ce n'est pas très surprenant : quand l'IA corrige les erreurs à ta place, tu t'entraînes beaucoup moins à les corriger toi-même. Les auteurs en tirent une idée simple, que l'effort, y compris le fait de rester coincé un moment, joue probablement un rôle dans l'apprentissage.

Quelles façons d'utiliser l'IA ont le mieux réussi ?

Celles où l'IA servait à comprendre plutôt qu'à produire. Dans une analyse qualitative, les chercheurs ont rangé les participants du groupe IA en six façons de faire, et les scores se séparent nettement :

Le dernier groupe, le plus nombreux parmi les bons scores, a été le deuxième plus rapide des six, juste derrière ceux qui déléguaient tout. Chercher à comprendre ne l'a donc pas rendu lent. Garde quand même la mesure de ces chiffres : chaque groupe compte entre deux et sept personnes, et les auteurs précisent eux-mêmes que cette partie de l'analyse n'établit pas de lien de cause à effet. Elle donne une piste, pas une loi.

L'IA rend-elle les développeurs expérimentés plus rapides ?

Pas forcément, et surtout, ils se trompent sur leur propre vitesse. En juillet 2025, l'organisme METR a publié un essai sur 16 développeurs expérimentés, qui travaillaient depuis des années sur de gros projets open source. Sur 246 tâches réelles de leurs propres dépôts, tirées au sort avec ou sans IA, ils ont mis 19 % de temps en plus quand l'IA était autorisée. Avant l'étude, ils s'attendaient à gagner 24 %. Après, ils estimaient encore avoir gagné 20 %.

Ce résultat a ses limites, que METR rappelle lui-même : 16 personnes, des outils du début de 2025 (surtout Cursor avec Claude 3.5 et 3.7 Sonnet), un cadre très particulier. En février 2026, METR a annoncé que sa nouvelle expérience ne permettait plus de mesurer l'effet actuel, parce que beaucoup de développeurs refusaient désormais d'y participer, faute de vouloir travailler sans IA. L'organisme pense que le gain est probablement plus grand qu'au début de 2025, tout en reconnaissant que ses données n'en donnent qu'un indice très faible.

Pour toi qui apprends, la leçon tient moins au 19 % qu'à l'écart entre ressenti et mesure. Si des développeurs chevronnés se croient plus rapides au moment même où ils ralentissent, ton impression de « comprendre » en lisant du code généré mérite la même méfiance. Une mesure extérieure, comme des tests qui passent ou échouent, ne se laisse pas convaincre.

Que pensent les développeurs de l'IA en 2026 ?

Ils l'utilisent massivement et s'en méfient en même temps. En 2025, 84 % des répondants de l'enquête Stack Overflow utilisaient ou comptaient utiliser des outils d'IA pour développer, mais 46 % se méfiaient de la précision de leurs réponses, contre 33 % qui leur faisaient confiance. La frustration la plus citée, par 66 % d'entre eux : des solutions « presque justes, mais pas tout à fait ». Et 45 % trouvaient que déboguer du code généré par l'IA prend plus de temps.

L'édition 2026, publiée le 6 octobre 2026 avec plus de 30 000 répondants dans 169 pays, a posé la question de la confiance autrement :

Près d'un développeur sur deux pose donc la même condition : pouvoir vérifier. Une réponse « presque juste » est exactement le genre de bug qu'un débutant ne voit pas : le code compile, passe l'exemple de l'énoncé et rate le cas limite. Savoir coder, en 2026, c'est d'abord être capable de faire ce tri.

Comment apprendre à coder avec l'IA sans te court-circuiter ?

En reprenant ce que faisaient les participants qui ont le mieux réussi, et en te mesurant régulièrement sans aide :

1. 1

   Écris d'abord seul, même une version fausse. C'est en butant sur ton propre code que tu sais quelle question poser.

2. 2

   Demande des explications, pas des solutions. « Pourquoi scanf laisse-t-il le retour à la ligne dans le tampon ? » t'apprend quelque chose ; « écris-moi la fonction » ne t'apprend rien.

3. 3

   Si tu fais générer du code, interroge-le ligne par ligne jusqu'à pouvoir le réécrire sans le regarder. Puis réécris-le.

4. 4

   Débogue toi-même avant de demander. Lis le message d'erreur, lance gdb(1) ou valgrind(1), formule une hypothèse. C'est la compétence où l'écart était le plus grand dans l'étude d'Anthropic.

5. 5

   Teste-toi sans IA. Un exercice corrigé par des tests ne juge pas ton impression, il juge ce que fait ton code, cas limites compris.

Le quatrième point vaut un exemple concret. Face à un crash, la question « que veut dire ce message ? » t'apprend à lire un Segmentation fault ; coller le code en demandant « corrige » ne t'apprend rien sur le suivant. La méthode pour trouver soi-même la ligne fautive est dans Segmentation fault (core dumped) en C.

fix-the-warnings

Le fichier de départ ne compile pas : trois warnings, transformés en erreurs par -Werror. Les faire taire ne suffit pas, puisque (void)hi; efface une ligne du diagnostic et laisse les tests rouges : la branche qui devait utiliser hi n'a jamais été écrite. Fais-le sans assistant, c'est précisément du débogage.

Ouvrir l'exercice

Pour un test plus franc, les challenges tirent un exercice par niveau et te laissent un temps limité. Fais-les sans assistant : c'est ce qui en fait une mesure honnête de ce que tu sais faire seul, le jour où tu les passes.

Questions fréquentes