Début 2026, des chercheurs qui tentaient de mesurer l’effet de l’IA sur la productivité des développeurs se sont heurtés à un problème profondément humain : certains développeurs ne voulaient plus accepter de tâches qui pourraient les obliger à travailler sans IA.
Les chercheurs ont parlé de biais de sélection. Je ne peux m’empêcher d’y voir un petit aveu.
Il n’y a pas si longtemps, l’IA n’était qu’une expérience logée dans un panneau latéral. On l’ouvrait lorsque l’autocomplétion échouait ou qu’une expression régulière commençait à devenir embarrassante. Aujourd’hui, pour beaucoup de développeurs, elle fait simplement partie de la pièce. Elle est là quand nous ouvrons l’éditeur le matin, quand nous héritons d’un dépôt que personne n’a touché depuis des années, et quand un test passe au rouge tard dans la nuit.
Nous pouvons fermer le panneau. Nous pouvons couper l’agent. Nous savons toujours programmer.
Alors pourquoi travailler sans IA donne-t-il déjà l’impression qu’il nous manque une main ?
L’IA s’est emparée de nos pauses
L’IA n’est pas entrée dans le développement logiciel en annonçant qu’elle allait nous remplacer. Elle est arrivée sous la forme d’une succession de petits soulagements.
Elle a d’abord complété la ligne que nous allions écrire. Puis elle a rédigé le test que nous repoussions. Elle a expliqué une fonction inconnue, traduit une trace d’erreur en langage clair et retrouvé un paramètre enfoui dans une documentation que nous n’avions aucune envie de relire.
Rien de tout cela ne ressemblait à de la dépendance. Cela ressemblait à de l’élan.
Repensez à la dernière fois où votre assistant était indisponible. Ce qui vous a troublé n’était sans doute pas d’avoir oublié le langage. C’était le silence avant le premier geste. Il fallait décider seul où chercher. Porter l’incertitude sans aide. Regarder l’erreur assez longtemps pour qu’une hypothèse prenne forme.
Autrefois, ces pauses étaient ordinaires. Elles ressemblent désormais à de la friction.
C’est peut-être là que l’IA nous a le plus profondément changés. Elle n’a pas seulement transformé notre manière de produire des réponses. Elle a changé le temps que nous acceptons de passer seuls avec une question.
Le soulagement est réel
Il est facile de parler de dépendance à l’IA comme si les développeurs échangeaient leur discipline contre de la paresse. Cela ne dit rien de ce que l’outil représente depuis l’intérieur du travail.
Le développement logiciel contient une quantité étonnante de honte silencieuse. Il y a l’ingénieur senior qui a oublié la syntaxe d’une commande élémentaire. La nouvelle recrue qui craint qu’une question de plus confirme les doutes de tout le monde. Le développeur qui travaille dans une langue qui n’est pas la sienne, comprend parfaitement le problème mais ne trouve pas assez vite les mots pour l’expliquer. La personne qui rejoint une base de code vieille de dix ans, où chaque décision importante ne subsiste que dans la mémoire de quelqu’un d’autre.
L’IA se montre patiente avec chacun d’eux.
Elle ne soupire pas lorsqu’on répète une question. Elle ne dit pas : « Tu devrais déjà le savoir. » Elle répond à deux heures du matin et peut transformer un écran vide en quelque chose avec lequel débattre. Même imparfaite, une réponse change le poids émotionnel du commencement.
Cela compte. Parfois, ce qui ressemble à de la productivité est d’abord un soulagement : moins de peur de rester bloqué, moins de gêne, moins de solitude face à une machine qui refuse de s’expliquer.
Pour beaucoup, l’IA a aussi rendu de l’énergie aux parties du métier qui leur tiennent à cœur. Elle prend en charge le code répétitif, les tests routiniers, l’ossature d’une migration ou la centième variante d’un client API. L’esprit arrive moins épuisé devant le problème intéressant.
Il ne faut pas réduire cela à un simple raccourci. Un outil qui redonne aux gens le courage d’explorer produit quelque chose de réellement précieux.
Le problème, c’est que le réconfort et la dépendance poussent depuis la même racine.
Nous utilisons ce dont nous nous méfions
Les enquêtes menées auprès des développeurs décrivent toujours la même relation étrange : nous utilisons l’IA sans cesse, tout en restant méfiants envers ce qu’elle nous donne.
Quiconque a vu une réponse pleine d’assurance s’effondrer sur un seul cas limite connaît cette tension. Le code paraît juste. Les noms sont propres. L’explication est posée. Ce n’est qu’au troisième test en échec que l’on découvre que le modèle a inventé une méthode, mal compris une règle métier ou résolu un problème plus simple que le nôtre.
Et pourtant, la prochaine fois que nous bloquons, nous lui demandons encore.
Ce n’est pas de l’hypocrisie. La confiance n’est pas un bloc unique.
Nous ne lui confions peut-être pas la décision finale, mais nous lui demandons une première direction. Nous ne faisons pas confiance au patch, mais nous croyons à la conversation qui desserre le nœud dans notre pensée. Nous doutons de la réponse, tout en sachant qu’il y aura quelque chose à l’écran plutôt que rien.
L’IA est devenue ce collègue à qui nous ne donnerions jamais le droit de fusionner directement dans main, mais dont l’absence se fait étrangement sentir dès qu’il quitte la pièce.
Nous avançons plus vite parce que l’étape suivante apparaît aussitôt. Vérifier qu’elle supportera notre poids reste notre responsabilité.
Ce qui disparaît lorsque l’effort disparaît
Il existe un savoir qui ne naît qu’au moment où l’on se retrouve bloqué.
Avant l’IA, une erreur inconnue pouvait nous conduire de la trace d’exécution à l’appelant, puis vers la documentation, et enfin jusqu’à une hypothèse dont nous ignorions l’existence. Le chemin était inefficace. C’est pourtant ainsi qu’une base de code devenait un lieu plutôt qu’un ensemble de fichiers.
Nous nous souvenons des systèmes qui nous ont résisté.
Le bug qui a pris tout un après-midi nous apprend où vit réellement l’état. L’incident en production révèle pourquoi une protection ennuyeuse existe. La bibliothèque que nous avons mal comprise trois fois devient celle que nous saurons expliquer à quelqu’un d’autre.
Lorsque l’IA retire la résistance, elle peut aussi retirer l’histoire qui permet à la leçon de rester.
Une première étude menée auprès de développeurs découvrant une bibliothèque inconnue a observé quelque chose d’intuitif : ceux qui déléguaient entièrement la tâche apprenaient moins que ceux qui utilisaient l’IA pour poser des questions conceptuelles et éprouver leur propre compréhension. La vraie différence n’était pas « avec ou sans IA », mais de savoir si l’outil remplaçait la pensée ou y participait.
La question est particulièrement délicate pour les débutants. Les ingénieurs expérimentés reconnaissent une abstraction douteuse parce qu’ils ont autrefois construit la mauvaise. Ils sentent qu’un patch élégant n’a pas sa place dans le système parce qu’ils en connaissent les cicatrices. Mais où la prochaine génération acquerra-t-elle cet instinct si chaque aspérité est lissée avant même qu’elle puisse la toucher ?
Le mentorat n’a jamais consisté uniquement à transmettre des réponses. Il transmettait lentement le discernement : ce qui mérite notre inquiétude, le moment où il faut s’arrêter, le compromis qui coûtera cher plus tard, et la raison pour laquelle une solution fonctionnelle n’est pas encore prête.
L’IA peut expliquer toutes ces idées. Elle ne sait pas encore reproduire le sentiment que procure une personne qui choisit de rester à nos côtés pendant que nous les apprenons.
Le raccourci est peut-être réel. La compréhension doit malgré tout parcourir la distance.
Le code portait autrefois des empreintes
Un autre changement est plus difficile à mesurer, car il se produit entre les personnes.
Le code écrit par un humain conserve souvent des traces de son auteur. Une fonction utilitaire étrange peut porter le souvenir de l’incident qui l’a rendue nécessaire. Un commentaire maladroit peut révéler l’endroit où quelqu’un doutait. Pendant une revue, nous n’examinons pas seulement la modification : nous reconstruisons la pensée qui l’a produite. Nous posons des questions, et quelqu’un répond depuis le chemin qu’il a lui-même parcouru.
Le code généré par IA peut arriver sans ce chemin.
Il peut être soigné et techniquement plausible, tout en semblant étrangement sans propriétaire. L’auteur sait expliquer ce qu’il a demandé, mais pas toujours pourquoi le résultat a pris cette forme. Le reviewer doit alors reprendre une partie du travail qui appartenait autrefois à celui qui écrivait : reconstruire l’intention, vérifier les hypothèses et découvrir les bords cachés d’une décision que personne ne se souvient avoir prise.
C’est ce malaise qui traverse de nombreuses discussions dans la communauté autour des pull requests générées par IA. Le reproche n’est pas seulement que le code puisse être mauvais. Le mauvais code nous est familier. L’inquiétude plus profonde vient du fait que le contrat social a changé.
Une personne peut produire une modification importante en quelques minutes. Une autre doit toujours consacrer une attention humaine à la comprendre. Le temps gagné au clavier réapparaît silencieusement dans la revue, la maintenance, la sécurité ou cette nuit où le système tombe et où quelqu’un doit expliquer ce que le patch généré cherchait à faire.
Le code a toujours été un moyen de communication. Lorsque sa génération devient presque gratuite, l’attention devient rare. Et l’attention appartient aux humains.
Peut-être que le métier se déplace
Pour certains développeurs, rien de tout cela ne ressemble à une perte. Ils ont plutôt le sentiment de pouvoir enfin travailler au niveau auquel ils aspiraient.
Ils écrivent moins de lignes et passent davantage de temps à façonner le problème. Ils comparent plusieurs conceptions avant d’en choisir une. Ils pensent à l’utilisateur, à l’architecture, aux modes de défaillance et aux limites qu’un agent ne doit pas franchir. Le métier se déplace de la fabrication de chaque pièce vers la direction de l’ensemble.
Ce mouvement peut être une véritable évolution. Nous n’avons pas cessé d’être développeurs lorsque l’assembleur a remplacé le code machine ou lorsque les frameworks ont remplacé l’infrastructure construite à la main. Le logiciel s’est toujours élevé grâce à de nouvelles abstractions.
Mais toute abstraction dépend de quelqu’un qui comprend ce qu’il y a dessous.
Le développeur qui dirige une IA a toujours besoin de goût. Le reviewer a toujours besoin d’un modèle mental. L’architecte doit toujours savoir ce qui se passe lorsque son schéma propre rencontre un réseau lent, un message corrompu, une équipe épuisée ou un utilisateur inquiet.
Si l’IA écrit une plus grande part de l’implémentation, le jugement humain ne devient pas moins important. Il devient plus facile à négliger et plus difficile à cultiver.
La version optimiste de cet avenir n’est pas celle où les développeurs comptent moins. C’est celle où nous prenons davantage soin de ce que seuls les humains peuvent porter : le contexte, l’attention, le doute, la responsabilité et la capacité de reconnaître qu’une réponse techniquement correcte est mauvaise pour ce système précis et ces personnes précises.
Rester, sans disparaître
Pouvons-nous encore nous passer de l’IA ?
Individuellement, oui. Nous pouvons fermer le panneau demain. Professionnellement, la réponse est déjà plus complexe. Les attentes changent. Les bases de code se remplissent de travail généré. Les nouveaux développeurs rencontrent l’IA au début de leur carrière, et non plus à mi-chemin. Même ceux qui n’utilisent jamais d’assistant devront de plus en plus relire et maintenir du code qui en provient.
Il n’existe pas de chemin privé vers une industrie du logiciel d’avant l’IA.
Mais partir est peut-être une mauvaise mesure de la liberté. La question la plus importante est de savoir si nous pouvons rester présents pendant que l’outil, lui, reste.
Rester présents signifie lire le patch même lorsque tous les tests sont au vert. Demander pourquoi après que la réponse a fonctionné. Refuser de fusionner ce que nous ne pouvons pas expliquer. Donner aux débutants le temps de lutter sans traiter ce temps comme un gaspillage, et reconnaître le travail invisible des reviewers qui protègent le système contre des erreurs plausibles.
Cela signifie aussi préserver des moments où aucun assistant ne répond immédiatement. Non pas comme un rituel de pureté, mais pour entendre à nouveau notre propre pensée.
La plupart d’entre nous continueront à utiliser l’IA. Le soulagement est réel. Les possibilités sont réelles. Le malaise, la dépendance et la peur silencieuse de voir s’éloigner une part de ce que nous aimions dans ce métier le sont aussi.
Nous n’avons pas à choisir entre le déni et l’abandon.
L’avenir du logiciel ne sera pas décidé par le pourcentage de code écrit par l’IA. Il se décidera dans des moments plus petits : comprendre avant d’accepter, transmettre plutôt que simplement transférer une réponse, protéger l’attention d’une autre personne et continuer à assumer la responsabilité lorsque le code généré atteint le monde réel.
L’IA peut rester.
À nous de veiller à rester, nous aussi.
