- L’usage massif des outils de codage par IA par les développeurs a amélioré la productivité, mais entraîne aussi des coûts cognitifs et organisationnels invisibles
- Des outils d’assistance initiaux comme Copilot et Cursor, on est récemment passé à des agents autonomes, avec un basculement vers un modèle où l’humain assiste l’IA
- Mais un usage fondé sur la délégation totale provoque une dette cognitive et une baisse des capacités de débogage, affaiblissant la résolution de problèmes et la compréhension du code chez les développeurs
- Une organisation où l’IA écrit le code et l’humain ne fait que le relire conduit à l’effondrement du parcours de formation des seniors et à la perte du flow créatif, ce qui érode à long terme les capacités techniques de l’organisation
- L’usage de l’IA est devenu indispensable, mais il faut définir soi-même un “seuil d’usage approprié” et l’ajuster de façon à préserver la compréhension et l’apprentissage humains
L’évolution de l’adoption du codage par IA
- Des outils comme Copilot et Cursor, apparus en 2022~2023, indexaient les bases de code pour offrir de l’autocomplétion contextuelle et des fonctions de chat
- Le recours à Google ou aux recherches sur StackOverflow est devenu inutile, et l’environnement d’IDE avec IA intégrée s’est largement diffusé
- Les workflows orientés agents apparus ensuite ont marqué le passage d’une assistance à l’humain à un développement piloté par l’IA
- Mais les agents posent des problèmes de fiabilité liés aux boucles, aux hallucinations et aux erreurs de dépendances
- Depuis Opus 4.5, le niveau d’automatisation a fortement progressé, au point que certaines entreprises ont des cas où les développeurs n’écrivent plus directement le code
- Exemple : le co-CEO de Spotify a indiqué que les ingénieurs demandent à Claude dans Slack de modifier et de déployer des fonctionnalités
Dette cognitive et dégradation des compétences
- Le texte cite les concepts de « Digital Dementia » de Manfred Spitzer et de « Cognitive Debt » de Margaret-Anne Storey
- Déléguer à l’IA les efforts de réflexion répétés affaiblit les circuits cognitifs et réduit la compréhension du code
- Étude de Shen et Tamkin (2026) : parmi 52 développeurs, le groupe assisté par l’IA a obtenu des scores inférieurs de 17 % en compréhension conceptuelle, débogage et lecture de code
- La baisse des capacités de débogage était particulièrement marquée, et une seule heure d’usage passif de l’IA suffisait à produire une érosion mesurable des compétences
- Quand l’IA prend en charge les défis à la place du développeur, cela provoque un état de « dark flow » plutôt qu’un « vrai flow », renforçant la dépendance sans apprentissage
Le paradoxe de la revue de code et l’effondrement des seniors
- Si l’IA écrit le code et que l’humain se contente de le relire, un paradoxe apparaît : la source même de la capacité de revue disparaît
- Les développeurs qui dépendent entièrement de l’IA travaillent vite, mais obtiennent les pires scores d’évaluation
- Storey propose que « les humains doivent comprendre pleinement les modifications générées par l’IA avant leur déploiement »
- L’IA fournit aux débutants des résultats de niveau senior, mais ce n’est qu’une reproduction sans compréhension
- Les seniors perdent en profondeur parce qu’ils n’écrivent plus directement le code, et les juniors ne progressent pas faute de passer par les essais et erreurs
- Au final, le pipeline de formation des seniors s’effondre
Les erreurs de jugement du management et les effets de bord organisationnels
- Des dirigeants de Microsoft, Anthropic, Google et d’autres prédisent que l’IA remplacera les ingénieurs en quelques mois
- Google a déclaré qu’à la fin de 2024, 50 % du nouveau code était généré par l’IA
- Mais ces chiffres relèvent d’une exagération destinée à vendre l’IA ou à soutenir le cours de Bourse, et ne sont pas applicables aux organisations ordinaires
- Certaines entreprises mesurent l’usage de l’IA comme KPI et l’imposent aux développeurs
- Cas de Reddit : des développeurs manipulaient les statistiques d’usage de l’IA avec des commandes dénuées de sens
- Résultat : la loi de Goodhart s’applique, et au lieu d’un gain de productivité, il ne reste qu’une conformité formelle
Le coût humain et la perte de créativité
- Écrire du code procure le plaisir de l’immersion et de la création, mais relire du code produit par l’IA provoque une fatigue mentale
- Quand la récompense dopaminergique de la création disparaît, le burn-out s’accélère
- Le développement est ramené à de la QA (assurance qualité), et le sentiment d’accomplissement créatif s’évanouit
- La situation est comparée à un monde où l’IA ferait tout l’art pendant que l’humain « ne ferait que plier le linge »
Le bon seuil d’usage de l’IA
- L’IA est un outil puissant, mais ce n’est ni le plus ni le moins d’usage qui est bon en soi
- L’étude de Shen et Tamkin distingue 6 types d’interactions avec l’IA, parmi lesquels
- la délégation complète, la dépendance progressive et le débogage confié à l’IA nuisent à l’apprentissage
- les demandes d’explication, les questions conceptuelles et la vérification après un codage autonome préservent l’apprentissage
- Le point essentiel est de maintenir l’engagement cognitif : ce qui compte n’est pas seulement d’utiliser l’IA, mais la manière de l’utiliser
- Ne pas utiliser du tout l’IA fait perdre en efficacité sur la recherche, le boilerplate et l’exploration,
tandis qu’un usage excessif dégrade la compréhension, la formation des seniors, la détection de bugs et la capacité d’immersion
Un déclin silencieux
- Sur les indicateurs, le nombre de PR, de fonctionnalités et le cycle time s’améliorent,
mais les compétences techniques profondes, la concentration et la capacité de résolution de problèmes s’affaiblissent peu à peu
- Les développeurs deviennent des « robots à beurre » qui cliquent sur approuver sans comprendre la structure produite par l’IA
- Simon Willison a lui aussi indiqué qu’en ne relisant pas les fonctionnalités produites par l’IA dans un projet,
il « ne comprend plus clairement le fonctionnement interne »
- Au final, ce n’est pas l’outil qui se dégrade, mais l’humain, et ce changement n’est ni mesuré ni piloté
- La dépendance à l’IA progresse comme une addiction et risque de déboucher sur un déclin technique silencieux mais bien réel
1 commentaires
Réactions sur Hacker News
J’aime toujours écrire moi-même le code et en dessiner la structure dans ma tête ; cela reste l’un des plaisirs de mon travail
Même le refactoring répétitif ou pénible a du sens pour moi
Ces moments difficiles deviennent une matière d’apprentissage qui m’aide à trouver de meilleures méthodes la fois suivante
Il me reste l’espoir qu’un jour cette dynamique revienne
Je crois qu’un jour, la valeur de ceux qui ont conservé la capacité de choisir et de juger par eux-mêmes sera de nouveau reconnue
Si un code est difficile à tester, il faut changer les abstractions ou les interfaces
Les tests sont la première forme de réutilisation du code ; si c’est pénible dans les tests, ce le sera aussi dans l’usage réel
Plus c’est moi qui ai écrit le code, plus il m’est facile de visualiser mentalement où le problème peut apparaître
Un LLM ne remplace pas cette intuition, même si on lui jette tous les logs possibles
Mais je me demande si cela ne risque pas de faire disparaître la motivation à améliorer l’écosystème front-end
Même les tâches que d’autres voudraient déléguer à un LLM me plaisent quand je les fais moi-même
Voir les entreprises nous retirer peu à peu ces petites joies me rend triste
J’ai beaucoup utilisé Claude Code au cours de l’année écoulée, et j’ai récemment senti chez mes collègues un changement émotionnel vis-à-vis de l’usage de l’IA
J’ai écrit un texte sur les coûts cachés d’un usage excessif de l’IA et rassemblé des données de plusieurs sources
Il n’y a pas encore de données vraiment claires, mais beaucoup de développeurs semblent éprouver la même chose
En revanche, l’idée que « le logiciel n’est qu’un outil » m’a toujours semblé étrange
Quand un outil peut se substituer à la pensée, peut-on encore l’appeler un « outil » ?
J’ai bien aimé l’expression franche de « dépendance au prompt ». Mais il serait aussi intéressant d’explorer l’aspect addiction comportementale
C’est rapide et on a l’impression de garder le contrôle, mais on le perd peu à peu
Le plus difficile, c’est de trouver « à quelle vitesse durable on peut l’utiliser »
J’ai écrit moi aussi un billet de blog sur un sujet voisin,
en l’abordant sous l’angle du rôle du dirigeant pour aider une organisation à trouver un équilibre durable
J’ai cherché des articles sur l’effet de la mémoire de travail (working memory) et du système de récompense sur l’apprentissage et l’attention soutenue
Par exemple, un article de Nature explique que la mémoire de travail présente une réactivité dopaminergique
Et un article de Scientific American indique que l’écriture manuscrite active davantage de zones cérébrales
Au final, la conclusion est que, dans les tâches passives à faible récompense, ces bénéfices cognitifs disparaissent presque totalement
Je pense donc qu’un bon critère d’usage de l’IA est : « à quel point la tâche est-elle pénible et peu gratifiante ? »
Je continue à écrire moi-même mon code et à en comprendre totalement le résultat
Le gain de vitesse m’importe peu. Ce qui compte, c’est ce sentiment de propriété : c’est mon code
J’aurais toujours pu sous-traiter avant, mais cela m’aurait mis sur la voie de quelqu’un qui se contente de lire du code
La plupart des développeurs autour de moi, et moi-même, ressentons cette pression
Utiliser un clavier ne nous fait pas oublier l’écriture manuscrite, et acheter du café ne nous fait pas oublier comment en préparer
J’ai appris à coder au début des années 80 en assembleur LSI-11, en mémorisant tous les opcodes en octal
Mais quand j’ai appris FORTRAN 83, ma productivité a été multipliée par dix, et je n’ai jamais regretté que ces compétences-là se soient atrophiées
Un jour, des langages comme C++ ou Java deviendront eux aussi des compétences dont on n’aura plus besoin
Le fait d’avoir manipulé des opcodes a forgé une capacité de raisonnement logique qui a ensuite facilité l’apprentissage d’autres langages
Cette façon de penser propre aux langages formels (formal language) est bien plus profonde cognitivement que la rédaction de prompts pour un LLM
tandis que la collaboration avec l’IA consiste à transmettre une intention au moyen d’un langage naturel ambigu
À moins d’écrire du pseudocode en anglais, on perd en précision
Et en plus, il y a cette fois la peur d’être remplacé
Si l’on respecte trois schémas pour bien utiliser l’IA, on peut gagner à la fois en productivité et en apprentissage
Mais si l’on suit des anti-patterns, on tombe dans la dépendance à l’outil, l’anxiété, la baisse des capacités de debugging et l’addiction à la récompense immédiate
Au final, cela crée un cercle vicieux de dégradation cognitive
J’ai récemment rejoint une entreprise centrée sur l’IA, où l’ambiance décourage presque totalement le code écrit à la main
J’ai demandé à Claude de lire la documentation d’une API et de générer un wrapper ; le résultat était parfait,
mais moi, je n’ai finalement rien compris de l’API, ni de sa structure
Cet état où l’on peut « faire beaucoup sans rien savoir » est inconfortable et vide
Aucune mémoire réflexe ne s’accumule. Je me reconnais donc profondément dans cet article
Je mène plusieurs side projects écrits par l’IA
Cela dit, c’est une sensation bizarre, du type « je pense que c’est bien, sans en être certain »
En conclusion, même quand on construit avec l’IA, il faut y laisser sa propre empreinte pour ressentir un accomplissement
Cela ne fait que 8 mois que j’ai commencé à coder, et c’est grâce à l’IA que j’ai appris
Mais quand Claude écrit du code pour moi, je n’en comprends qu’environ 70 %, et je laisse simplement passer le reste
La sensation de vitesse est addictive, mais la capacité à garder toute la structure en tête diminue
Malgré tout, sans l’IA je n’aurais pas pu produire ce que j’ai aujourd’hui ; j’accepte donc ce trade-off
Par exemple, elle abuse de code de fallback inutile
Quand on manque d’expérience, on peut ne pas voir que c’est une mauvaise pratique
Le niveau actuel des LLM est celui d’un développeur entre stagiaire et junior
Le goulot d’étranglement, ce n’est pas le modèle, c’est notre capacité à vérifier
TODO(human)dans le code tout en expliquant ce qu’il faitJe me demande s’il faut vraiment utiliser un LLM pour automatiser du boilerplate
Les outils existants de métaprogrammation ou de scripting ne suffisent-ils pas déjà ?
Et, à l’inverse, refuser l’IA par principe peut aussi être un choix satisfaisant
Utilisation de la souris et du clavier, navigation dans les fichiers, recherche de commandes : les bases sont souvent faibles
D’où la tentation de se dire : « autant demander directement au LLM »
Mais la vraie solution, c’est d’améliorer sa maîtrise des outils et d’apprendre les moteurs de templates
L’IA peut certes provoquer une dégradation des compétences,
mais si cela concerne une zone sur laquelle je ne veux pas me concentrer, cela me va
Par exemple, je n’ai pas besoin de connaître dans le détail les optimisations internes d’un compilateur
Pour comprendre les interactions entre systèmes, il faut tout de même connaître un minimum le fonctionnement d’un compilateur
Confier au LLM les parties dont on ne veut pas se soucier,
et concentrer ses ressources mentales sur les vrais problèmes importants