Le métier de développeur à l'ère de l'IA

Pendant longtemps, apprendre à coder voulait dire suivre une liste de technologies dans l'ordre : HTML, puis CSS, puis JavaScript, puis un framework. Au bout de la liste, on se sentait légitime. Les assistants de code ont bousculé cet ordre en quelques années : ils produisent en quelques secondes, dans presque tous les langages, du code qu'on mettait longtemps à écrire.

Le métier n'a pas disparu pour autant. Ce qui change, c'est la part du travail qui consiste à écrire du code, et celle qui consiste à le lire, le juger et le relier au reste. Ce cours n'apprend pas un outil : il montre ce qui a été mesuré sur l'effet de ces assistants, ce qui l'est moins, et comment s'en servir pour progresser plutôt que pour se dispenser d'apprendre.

Pour qui : tu n'as besoin de rien, même pas d'avoir déjà codé. Si tu codes déjà avec un assistant, les deux études du milieu du cours risquent de te surprendre.

Le fil du cours : Inès code depuis un an. On lui demande d'ajouter à une application de musique en streaming la vérification de l'abonnement : quand il a expiré, l'application repasse en version gratuite. Elle s'aide d'un assistant de code et d'une bibliothèque de dates qu'elle n'a jamais utilisée. On la suit de la première demande jusqu'au bug qui passe tous les tests.

Ce qui a basculé

Les feuilles de route classiques ne sont pas fausses. Elles sont rigides : trois mois de syntaxe avant de toucher un vrai projet, alors qu'un assistant produit cette syntaxe à la demande. Connaître un framework par cœur n'est plus ce qui distingue quelqu'un ; savoir s'il faut l'utiliser, et repérer quand le code proposé fait fausse route, l'est davantage.

L'adoption est massive. Dans l'enquête Stack Overflow 2025, 84 % des répondants utilisent ou comptent utiliser des outils d'IA pour développer, et 51 % des développeurs professionnels s'en servent chaque jour. La même enquête montre l'autre face : 46 % se méfient de la justesse de leurs réponses, contre 33 % qui s'y fient.

Les juniors y perdent leur terrain d'entraînement. Corriger un petit bug, écrire un test de base, recopier du code répétitif : c'est là qu'on forgeait ses réflexes, et ce sont précisément les tâches qu'un assistant avale en un instant. Le premier barreau de l'échelle a sauté. Cela ne veut pas dire que le métier disparaît : quelqu'un doit encore décider quoi construire, vérifier ce qui revient et répondre de ce qui part en production. Mais on y entre autrement.

Du profil en I au profil en T

Pendant longtemps, la meilleure stratégie de carrière était la spécialisation : devenir la personne qui connaît tout d'une technologie. On parle d'un profil en I : très profond, très étroit. Un assistant de code écrit aujourd'hui du code correct en interface, côté serveur, sur une base de données ou pour une mise en ligne, sans être spécialiste d'aucun. La rareté se déplace vers un profil en T : une base large, qui permet de lire et de relier toutes les pièces, et de la profondeur là où l'on juge.

La figure dessine les deux silhouettes, bloc par bloc. Allume « avec un assistant de code » : quels blocs l'assistant écrit-il aussi, et que reste-t-il à faire à la personne ?

Les blocs hachurés sont ceux où l'assistant produit, lui aussi, du code correct : les bases et le niveau avancé d'une techno, mais aussi le code de chaque domaine du T. Ce qui n'est jamais hachuré, ce sont les jonctions dorées entre les domaines, et le produit : savoir pourquoi une donnée lente rend l'interface lente, ou quelle fonction ne vaut pas la peine d'être écrite. La profondeur garde sa valeur là où il faut juger une réponse : l'expertise, le fonctionnement interne, les pièges rares. C'est pour cela que le T a encore une jambe.

Trois compétences qui ne s'automatisent pas

Les fondamentaux. Même quand la machine écrit le code, il faut comprendre ce qu'elle écrit. En 2006, l'informaticienne Jeannette Wing a appelé pensée computationnelle la capacité à découper un problème en étapes, à prévoir les cas limites et à choisir une représentation qui rend le problème facile. C'est elle qui te permet de savoir si ce que te rend l'assistant est bon. Sans elle, tu ne peux que le croire.

L'orchestration. Diriger un assistant, ce n'est pas écrire des consignes alambiquées. C'est exprimer une intention claire, puis exercer un esprit critique sur ce qui revient : « ça marche, mais c'est trop lent » ; « c'est illisible, réécris-le plus simplement » ; « explique-moi pourquoi tu as choisi cette structure ». La qualité du résultat tient à la qualité de ce dialogue, et à ta capacité à dire non.

Le jugement. Comprendre ce dont un utilisateur a besoin, peser un risque de sécurité, renoncer à une fonction qui complique tout sans rien apporter, travailler avec d'autres. Aucun assistant ne prend ces décisions à ta place, parce que personne ne lui en confie la responsabilité. C'est ce qui sépare quelqu'un qui génère du code de quelqu'un qui mène un projet jusqu'au bout.

Lire dix fois plus que tu n'écris

Le constat est ancien : en 2008, dans Clean Code, Robert C. Martin estimait qu'on passe bien plus de dix fois plus de temps à lire du code qu'à en écrire. Avec un assistant, la proportion grimpe encore, puisque c'est lui qui écrit. Ce cours en tire une règle de travail, qui est une adaptation et pas une loi : pour chaque ligne que tu écris, lis-en dix produites par l'assistant, et demande-lui pourquoi elles sont ainsi. Les deux étapes surlignées sont celles où l'on apprend.

La figure suit Inès sur sa vérification d'abonnement. Avant de lancer la lecture : selon toi, à quelle étape apprend-elle vraiment quelque chose sur la bibliothèque de dates ?

L'apprentissage se fait dans la lecture et dans la question « pourquoi ? », pas dans la génération : l'assistant propose en une seconde, mais c'est en relisant qu'Inès découvre que la bibliothèque compare des dates et pas du texte. La flèche en pointillés compte aussi : un test qui casse renvoie à la proposition, et chaque tour de boucle est une occasion de comprendre. Sauter la lecture, c'est valider du code qu'on ne saurait pas réparer. Le commit, enfin, garde une trace : c'est le sujet du cours Git : garder l'historique de son code.

Mesurer plutôt que ressentir

En 2025, l'organisme de recherche METR a mené un essai randomisé, la méthode des essais cliniques, sur seize développeurs expérimentés. Chacun travaillait sur un projet open source qu'il connaissait bien, et chaque tâche était tirée au sort : avec ou sans IA. Au total, 246 tâches ont été chronométrées. Avant de regarder le résultat, parie.

Avec l'IA, les tâches ont pris 19 % de temps en plus, alors que les mêmes développeurs prévoyaient d'aller 24 % plus vite, et se sentaient encore 20 % plus rapides après coup. L'intervalle de confiance, de 2 % à 39 % de temps en plus, ne contient pas zéro : le ralentissement est net. La leçon n'est pas « l'IA ralentit ». Elle est que ton impression de gagner du temps est un mauvais instrument de mesure, même quand tu es expérimenté.

METR a recommencé fin 2025, avec 57 développeurs et les outils de l'époque. Le second graphique montre ses deux estimations : 18 % et 4 % de temps gagné, mais avec des intervalles qui traversent le zéro. METR juge lui-même ce signal peu fiable, pour une raison précise : de plus en plus de développeurs refusaient de participer, parce qu'ils ne voulaient plus travailler sans IA. C'est un biais de sélection : l'étude ne voit que ceux qui acceptent d'y entrer.

La figure suivante simule quarante développeurs, chacun avec le temps qu'il gagnerait grâce à l'IA. Personne ne refuse au départ. Glisse le seuil vers la gauche : au-delà de ce gain, on refuse de travailler sans IA. Que devient le gain mesuré ?

Plus le seuil descend, plus les grands gagnants manquent à l'étude, et plus la moyenne mesurée tombe sous la vraie. C'est exactement l'inquiétude de METR : son estimation de fin 2025 est sans doute trop basse, d'une quantité inconnue. Les données de cette figure sont simulées, mais le mécanisme est réel : avant de croire un chiffre, demande-toi qui a été mesuré, et qui manque.

Apprendre avec l'IA, pas à sa place

Le 29 janvier 2026, Anthropic a publié une étude sur 52 ingénieurs, surtout juniors, qui devaient apprendre Trio, une bibliothèque Python qu'ils ne connaissaient pas, pour coder deux fonctions. La moitié avait un assistant, l'autre codait à la main. Au quiz passé juste après, le groupe avec assistant a obtenu 50 % en moyenne, contre 67 % pour l'autre : un écart d'environ 17 points. Le gain de temps, lui, n'était que de deux minutes environ, et pas significatif. L'écart le plus fort portait sur le débogage, la compétence dont on a besoin quand le code généré casse.

Les auteurs ont aussi regardé comment chacun s'était servi de l'assistant, et ils ont trouvé six façons de faire. La figure en montre deux, par des échanges types écrits pour l'exemple sur la tâche d'Inès : même bibliothèque, même assistant, même fonction à écrire. À la lecture de ces échanges, quelle façon de faire a donné le meilleur quiz ?

Ceux qui ne posaient que des questions de fond ont obtenu en moyenne 65 % ou plus, en allant presque aussi vite : c'est la deuxième façon de faire la plus rapide des six. Ceux qui déléguaient tout ont fini les premiers, avec un quiz sous 40 %. Les premiers traitent l'assistant comme un binôme qui explique ; les seconds, comme un oracle qui répond à leur place. Une limite à garder en tête : ces deux groupes comptent sept et quatre personnes, et le quiz mesurait la compréhension juste après la tâche.

Les auteurs résument : l'effort cognitif, et même le fait de rester douloureusement bloqué, compte sans doute pour acquérir une vraie maîtrise. Certains outils sont construits sur cette idée. Le « canard » de CS50, le cours d'introduction à la programmation de Harvard, est un assistant conçu pour guider vers la réponse plutôt que la donner. Quelques habitudes qui en découlent :

• Demande des explications, pas seulement du code. « Comment cette bibliothèque compare-t-elle deux dates ? » t'apprend plus qu'« écris la fonction ».
• Écris la première version toi-même quand tu découvres un outil, puis compare avec celle de l'assistant.
• Débogue d'abord seul. Formule ton hypothèse avant de coller l'erreur dans la conversation.
• Relis tout ce que tu gardes, au point de pouvoir l'expliquer à quelqu'un d'autre.

Le code qui « marche »

Le 2 février 2025, Andrej Karpathy, un des fondateurs d'OpenAI, a donné un nom à une façon de faire : le vibe coding. On décrit ce qu'on veut, on accepte tout ce que l'assistant propose sans lire les modifications, et on colle les messages d'erreur jusqu'à ce que ça marche. Il le présentait lui-même comme « pas si mal pour des projets jetables du week-end ». L'expression a fait le tour du monde au point de devenir le mot de l'année 2025 du dictionnaire Collins.

Le danger commence quand ce code sort du week-end. L'enquête Stack Overflow 2025 nomme la première frustration des développeurs : des réponses « presque justes, mais pas tout à fait », pour 66 % d'entre eux. Un code presque juste passe les tests qu'on a pensé à écrire, et casse sur ceux qu'on n'a pas écrits. Voici la fonction que l'assistant a écrite pour Inès, avec ses trois tests, tous verts. La console exécute aussi une version juste. Arriveras-tu à faire diverger les deux ? Essaie une date de septembre écrite sans zéro, puis la même avec son zéro, puis un jour d'octobre avant le 14.

// écrite par l'assistant
function abonnementActif(
  expiration,
  aujourdhui = "2026-10-14",
) {
  return expiration >= aujourdhui;
}

La fonction compare les dates comme du texte, caractère par caractère. Tant que les dates portent leurs zéros, l'ordre du texte est celui du calendrier, et les trois tests passent. Écrite sans zéro, une date de septembre commence par « 9 », qui vient après le « 1 » d'octobre : un abonnement expiré passe pour actif. Aucun test ne l'avait vu, parce qu'aucun test n'avait essayé ce format. Lire le code, c'est la seule défense contre ce que les tests ne couvrent pas ; le cours Les tests : prouver que son code fait ce qu'on croit montre comment choisir les cas qui comptent.

Le même raisonnement vaut pour la sécurité et la dette technique. Un code généré peut oublier une vérification d'accès, dupliquer une logique en trois endroits ou affirmer avec aplomb qu'une fonction existe alors qu'elle n'existe pas. L'assistant n'en répond pas : c'est la personne qui valide qui en répond. Quand un assistant n'écrit plus une fonction mais enchaîne lui-même les actions, on parle d'agent ; le cours Les agents : un modèle qui agit montre comment fonctionne cette boucle.

Ce qu'on oublie souvent

• Le ressenti de vitesse n'est pas une mesure. Seize développeurs expérimentés se croyaient plus rapides en étant plus lents.
• Un chiffre a une date. L'effet des assistants de 2025 n'est pas celui de 2026, et une étude peut être faussée par ceux qui refusent d'y participer.
• Relire coûte du temps, et c'est normal. C'est là que se loge l'apprentissage, et c'est là qu'on attrape les erreurs.
• Ce qu'on n'a pas compris, on ne sait pas le déboguer. Le plus grand écart de l'étude d'Anthropic portait sur le débogage.
• Les outils changent tous les six mois, les fondamentaux non. Découper un problème, prévoir un cas limite, lire un test : rien de cela ne se périme.

Teste-toi

Quelques questions sur les idées du cours. La raison s'affiche après chaque réponse : c'est elle qui compte.

Le vocabulaire en un coup d'œil

Ce qu'il faut retenir

• Les assistants écrivent du code correct dans presque tous les domaines : la valeur se déplace vers le profil en T, qui relie les pièces et juge l'ensemble.
• Trois compétences ne s'automatisent pas : les fondamentaux, l'orchestration et le jugement.
• Pour une ligne écrite, dix lignes lues : on apprend en relisant et en demandant pourquoi.
• Mesure, ne ressens pas : chez METR, des développeurs se croyaient plus rapides en étant 19 % plus lents.
• Un chiffre se lit avec son intervalle et sa date, et en se demandant qui n'a pas été mesuré.
• L'assistant comme binôme fait progresser ; comme oracle, il fait gagner du temps sans faire apprendre.
• Un code qui passe ses tests n'est pas forcément juste : seule la lecture voit ce que les tests ne couvrent pas.

Pour aller plus loin

• METR (10 juillet 2025), Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, consulté le 14 octobre 2026.
• METR (24 février 2026), We are Changing our Developer Productivity Experiment Design : la suite de fin 2025 et le biais de sélection, consulté le 14 octobre 2026.
• Shen & Tamkin, Anthropic (29 janvier 2026), How AI assistance impacts the formation of coding skills, et l'article How AI Impacts Skill Formation, consultés le 14 octobre 2026.
• Stack Overflow, Developer Survey 2025, volet IA, consulté le 14 octobre 2026.
• Jeannette Wing (2006), « Computational Thinking », Communications of the ACM, 49(3), p. 33-35, doi:10.1145/1118178.1118215 ; traduction française de l'autrice.
• Robert C. Martin (2008), Clean Code, Prentice Hall : le rapport de plus de dix pour un entre le temps de lecture et le temps d'écriture du code.
• Martin Fowler, Vibe Coding : le message d'Andrej Karpathy du 2 février 2025 et ce qu'il en disait, consulté le 14 octobre 2026.
• Harvard CS50, l'assistant « canard » de CS50, consulté le 14 octobre 2026.