Un billet publié sur Lobsters et marqué du tag vibecoding a rassemblé 114 votes et 71 commentaires. Intitulé simplement « On AI », il renvoyait vers un article sur jcs.org (actuellement inaccessible). Cependant, la discussion elle-même est rapidement devenue le point focal des préoccupations de la communauté des développeurs.
En tête de fil, l’utilisateur tmcb a proposé une métaphore marquante :
« C’est comme être Sisyphe, mais sur une colline voisine, des gens s’amusent à regarder une grue soulever des rochers jusqu’au sommet avec une précision douteuse, tout en écrasant un spectateur de temps en temps. Il faut imaginer Sisyphe furieux. »
Cette comparaison a obtenu 93 votes positifs parce qu’elle touche du doigt une inquiétude grandissante : les outils de programmation IA sont devenus si « pratiques » qu’on en vient à se demander si l’on apprend encore quoi que ce soit.
Cet article examine ce qui se passe lorsque vous déléguez l’écriture du code à une IA, et où s’évapore ce processus d’« apprentissage incidentel ».
Image : Dans les environnements de développement modernes, la génération de code par IA est devenue une infrastructure standard. Mais derrière les gains de productivité, le coût sur l’apprentissage est souvent ignoré.
L’étape d’apprentissage effacée par magie
L’utilisateur duck_tape a résumé le cœur du sujet dans un commentaire salué par 38 votes :
« Il y a quelque chose auquel nous n’avons pas encore vraiment fait face : une grande partie de notre apprentissage se faisait “incidemment”, comme un sous-produit de nos tâches quotidiennes. En implémentant une fonctionnalité au hasard ou en configurant la CI pour une nouvelle cible de compilation, il était impossible de ne pas apprendre. Aujourd’hui, nous pouvons faire disparaître ces étapes comme par magie. Nous pouvons “créer” directement ce que nous avons en tête. Mais nous ne pouvons plus apprendre “au passage”. Il est devenu très difficile de rester impliqué pendant que le LLM résout un bug à votre place. »
L’« apprentissage incidentel » (incidental learning) n’est pas un concept obscur réservé aux théoriciens de la pédagogie. Il décrit la manière la plus naturelle d’apprendre chez l’être humain : acquérir une compétence involontairement en cherchant à accomplir une autre tâche. La programmation a toujours reposé sur ce principe.
Prenons le cas d’un développeur débutant chargé de corriger un bug réel. Son objectif est uniquement de résoudre le problème. Pourtant, en chemin, il est contraint de comprendre la structure de la base de code, d’apprendre à manier un débogueur, d’assimiler pourquoi ce bug ne se déclenche que dans des conditions particulières et de retenir l’usage des API associées. Il n’a pas entrepris d’« étudier » ces sujets de manière délibérée : l’apprentissage a eu lieu au passage.
Depuis le lancement officiel de GitHub Copilot en 2022, le nombre d’utilisateurs a dépassé les 20 millions en 2025. Selon les données de Microsoft, environ 46 % du code écrit par les utilisateurs provient désormais de l’IA (ce chiffre atteignant 61 % dans certains projets Java). Et cette proportion continue de grimper.
L’IA rompt cette boucle de rétroaction. Son mécanisme d’interaction court-circuite précisément la boucle de l’« apprentissage par la pratique ». Vous saisissez un prompt, elle génère du code.
Lorsque ces occasions manquées s’accumulent, l’étape d’apprentissage effacée par la magie de l’automatisation finit par disparaître complètement.
Image : La complétion de code par IA fait passer le développeur du rôle de « créateur » à celui de « réviseur » — réviser est plus rapide qu’écrire, mais la profondeur de compréhension diminue.
Pourquoi ce n’est pas un simple « Stack Overflow 2.0 »
Une objection classique consiste à rappeler : lorsque Stack Overflow est apparu, certains prédisaient déjà que les développeurs ne sauraient plus lire une documentation ; à l’arrivée de l’autocomplétion dans les IDE, on affirmait qu’ils ne retiendraient plus les API. Pourtant, l’industrie du logiciel ne s’est pas effondrée.
Cependant, cette analogie est imparfaite. L’utilisateur bendmorris apporte une nuance essentielle :
« Il y a bien sûr toujours eu des développeurs qui s’en sortaient en copiant-collant depuis Stack Overflow sans vraiment comprendre ce qu’ils faisaient. Dans la bulle d’emplois de l’ère des taux d’intérêt zéro, cela pouvait passer, et aujourd’hui ces développeurs peuvent utiliser des LLM pour améliorer la qualité moyenne de leur production. Je ne pense pas que le résultat soit formidable pour autant : l’humain n’apporte presque plus aucune valeur réelle dans cette équation. »
Stack Overflow et l’autocomplétion de l’IDE amélioraient l’efficacité sur la base de structures de connaissances déjà existantes. Il fallait toujours comprendre la réponse trouvée pour juger de son adéquation ; l’autocomplétion ne fonctionnait que si l’on connaissait déjà le nom de la fonction à appeler. Ces outils accéléraient l’exécution sans faire l’impasse sur la compréhension.
La génération de code par IA, elle, fait l’impasse sur la compréhension même. On n’apprend pas automatiquement la logique d’un extrait simplement en le regardant défiler — d’autant plus lorsqu’il s’agit de 30 lignes d’abstractions inédites.
La psychologie cognitive met en avant deux notions fondamentales : l’illusion de fluidité (fluency illusion) et les difficultés désirables (desirable difficulties). Les chercheurs en sciences cognitives de l’UCLA Elizabeth et Robert Bjork ont démontré dès les années 1990 que les méthodes d’apprentissage qui paraissent « faciles » sont précisément celles qui offrent la plus faible rétention à long terme. À l’inverse, un apprentissage exigeant un effort — devoir se souvenir activement, résoudre un problème par soi-même — garantit une assimilation bien plus durable.
Les outils de programmation IA offrent une fluidité maximale pour un effort minimal. C’est un choix de conception de produit efficace, mais l’apprentissage en fait les frais.
En 2025, un essai contrôlé randomisé a testé cette hypothèse. Les chercheurs ont divisé les apprenants en deux groupes : l’un utilisait ChatGPT pour accomplir ses tâches, l’autre s’appuyait sur des méthodes traditionnelles. Les résultats montrent que le groupe assisté par l’IA a mieux réussi les tâches immédiates, mais a obtenu des scores nettement inférieurs lors des tests autonomes ultérieurs. Cela valide la théorie de la « décharge cognitive » (cognitive offloading) : un cerveau qui obtient des réponses trop facilement choisit de ne pas stocker l’information.
« Je veux toujours apprendre, mais je ne veux pas être un simple relecteur »
Un autre commentaire très soutenu (29 votes) émane de zetashift, qui décrit une lassitude générale dans la communauté technique :
« Je me rends compte que je ne clique même plus sur les liens GitHub. Lorsque je vois qu’un dépôt contient des fichiers comme
CLAUDE.mdouAGENTS.md, je ferme l’onglet par réflexe. … Après avoir codé avec un LLM, je n’éprouve aucun attachement pour ce que j’ai créé. Je n’ai pas du tout l’impression que ces résultats m’appartiennent et je n’ai aucune envie de les approfondir. »
Ce sentiment est loin d’être isolé. L’utilisateur gered a répondu qu’après avoir essayé le vibe coding, il ressortait avec une sensation « sale » (“I almost feel dirty afterwards”). L’utilisateur lake a partagé son expérience :
« J’ai passé un an et demi sur mon projet open source principal. Puis j’ai vu d’autres projets émerger et atteindre en quelques mois ce que j’espérais accomplir. Je suis ravi que ces outils existent, mais s’ils avaient existé avant que je ne commence, je n’aurais peut-être jamais lancé ce projet. Je me dis : il y aura des gens pour apprécier du code fait main. Je me dis : l’open source n’est pas une compétition. Mais regarder les autres vous doubler à toute vitesse est franchement décourageant. »
Derrière ces émotions se cache un problème structurel sous-estimé. Lorsque des développeurs séniors — riches de dix ou vingt ans d’expérience — utilisent l’IA, ils possèdent le recul nécessaire pour juger de la qualité de la production, détecter les erreurs aberrantes et refactoriser 50 lignes générées en 10 lignes de logique claire. Un développeur débutant ne possède pas cette capacité de jugement.
Le constat de bendmorris est sans détour :
« Quelqu’un comme Andreas Kling peut facilement passer aux LLM parce qu’il a accumulé suffisamment de compétences pour garantir la qualité et résoudre les bons problèmes. Mais comment la prochaine génération de développeurs atteindra-t-elle ce niveau si elle utilise des LLM dès le départ ? Les travaux de base qui construisent les compétences sont précisément les plus faciles à automatiser. L’industrie est en train de se tirer une balle dans le pied. »
Le vrai problème n’est pas l’IA, mais le flux de travail déconnecté de la compréhension
Une distinction s’impose ici. Il ne s’agit pas de soutenir que « l’IA est un mauvais outil » — une telle posture serait stérile et contraire aux faits. Les assistants de code apportent une hausse indéniable de productivité, permettant à de petites équipes de réaliser des projets qui réclamaient autrefois dix fois plus d’effectifs. Ils permettent à des non-spécialistes de concevoir des applications simples en langage naturel. Ces bénéfices sont réels.
La vraie question est la suivante : lorsque le fonctionnement de l’outil contourne la boucle d’apprentissage, qui s’assure que l’apprentissage continue d’avoir lieu ?
Aujourd’hui, presque tous les modèles d’interaction des outils IA suivent la séquence Besoin → Code → Validation. L’outil est conçu pour l’exécution, non pour favoriser la compréhension de l’utilisateur.
Le papier de recherche Agents That Teach: Towards Designing Incidental Learning Back into AI-Assisted Software Development (arXiv:2607.06101) a formalisé ce problème en introduisant le concept de « Dette de Connaissance » (Knowledge Debt) :
Lorsque des agents IA exécutent des modifications de code que le développeur ne comprend pas totalement, ces lacunes de compréhension s’accumulent au fil du temps. Aujourd’hui l’IA résout un bug que vous ne comprenez pas, demain elle génère une optimisation obscure. Un an plus tard, votre système fonctionne correctement, mais vous êtes incapable de le maintenir — parce que vous ne savez pas comment il fonctionne au juste.
Cette dette est plus insidieuse que la dette technique classique. La dette technique se traduit dans des métriques de qualité de code ou d’analyse statique. La dette de connaissance ne laisse pas de trace dans le dépôt : elle réside dans l’esprit du développeur et ne se révèle que lorsqu’il doit résoudre un problème de façon autonome.
Le coût de l’externalisation de la réflexion
La question de l’utilisateur pyj touche au cœur de la pratique quotidienne :
« Mon problème personnel avec l’IA est que je retiens beaucoup moins de choses. La tâche est accomplie, mais ce que j’apprends et retiens est bien inférieur à avant. Existe-t-il de bonnes stratégies pour préserver l’apprentissage tout en utilisant des outils d’IA ? »
C’est une interrogation à laquelle personne n’a encore apporté de réponse satisfaisante. Quelques développeurs expérimentés partagent leurs astuces — comme laisser Claude générer un prototype initial, puis le refactoriser manuellement vers une architecture plus propre. Mais cela exige de savoir déjà à quoi ressemble une « architecture propre ».
Le débat sur Lobsters s’est finalement séparé en deux courants. L’un estime que « le codage manuel devient un artisanat, à l’image de la menuiserie ou de la musique acoustique » — libre à chacun d’utiliser des outils électriques ou un rabot manuel, sans jugement de valeur. L’autre s’inquiète du fait que lorsque les incitations de l’industrie penchent massivement vers la vitesse de l’IA, le coût du codage manuel devient si élevé que seuls les plus aisés ou les plus passionnés pourront encore se le permettre.
Ces deux visions comportent leur part de vérité, mais elles contournent la question essentielle : si le chemin de l’« apprentissage incidentel » est coupé, combien de détours la nouvelle génération de développeurs devra-t-elle faire pour atteindre le niveau que la précédente atteignait simplement en faisant son métier ?
Personne n’a apporté de réponse définitive dans ce fil. Mais avoir posé la question avec autant de clarté possède déjà bien plus de valeur que n’importe quel discours marketing sur l’IA.
Liens de référence :
- Lobsters: On AI (114△, 71 comments) (item?id=zljfgp/on_ai)
- Joshua Stein: On AI (jcs.org)
- Hacker News: On AI discussion
- Bjork & Bjork (2011): Desirable Difficulties in Theory and Practice
- Anthropic: ChatGPT as a Cognitive Crutch
- arXiv 2607.06101: Agents That Teach
- Bjork (1994): Memory and Metamemory Considerations in the Training of Human Beings
- GitHub Research: Quantifying GitHub Copilot’s Impact on Developer Productivity and Happiness
