À qui est-il plus facile d’expliquer une tâche : à l’IA ou à un développeur ?

Comme je continue à programmer tout en dirigeant des équipes de développeurs, je me pose depuis un moment une question étonnamment simple : à qui est-il plus facile d’expliquer une tâche – à une IA ou à un développeur humain ?

La réponse n’est pas aussi évidente qu’il y paraît. Mais y réfléchir a changé ma façon de concevoir le développement logiciel, et ma façon de constituer des équipes.

Dans les années 1990 et au début des années 2000, le développement logiciel était encore une industrie relativement jeune. Les processus évoluaient vite, les méthodologies changeaient, et beaucoup d’équipes fonctionnaient selon des règles qui pouvaient changer presque du jour au lendemain.

Quelque part après 2011, le développement logiciel est devenu beaucoup plus structuré. Les processus, les rôles, les méthodologies et les attentes se sont progressivement établis.

Du moins d’après mon expérience, les développeurs avec qui je travaillais à cette époque pouvaient recevoir une tâche décrite en une seule phrase ou en un court paragraphe. Le chef de projet donnait la direction, et le développeur trouvait comment y parvenir.

Au cours des 15 dernières années, c’est progressivement l’inverse qui s’est produit. Les besoins doivent de plus en plus être traduits en spécifications détaillées par des business analysts ou des responsables d’équipe – des personnes plus expérimentées, censées anticiper, prévoir les cas limites et définir précisément le comportement du système. Et les développeurs sont de plus en plus devenus les exécutants silencieux de ces spécifications.

Demandez à un développeur : « Pourquoi le système se comporte-t-il de façon aussi absurde ? » La réponse est souvent : « Parce que c’est ce qui était écrit dans le cahier des charges. » Pour les chefs de projet, cela peut transformer le quotidien du développement en cauchemar.

Ces derniers temps, je me suis surpris à passer beaucoup trop de temps à gérer des différends entre spécialistes techniques, analystes et chefs de projet, au lieu de me concentrer sur la construction d’un bon produit.

Il y a des désaccords, des frustrations, des bugs, des fonctionnalités incomplètes, des malentendus et des discussions sans fin pour savoir qui était responsable. Et très souvent, une cause profonde étonnamment humaine se cache derrière tout cela : l’ego. Le besoin intérieur de prouver : « J’avais raison. C’est lui qui a causé le problème. Ou elle. Ou quelqu’un d’autre. »

C’est un comportement profondément humain. Et c’est précisément là que le développement logiciel avec l’IA change la donne.

À partir de 2024 environ, j’ai commencé à utiliser l’IA de manière beaucoup plus intensive dans mon propre travail de développement. Et je me suis surpris à avoir une pensée plutôt dérangeante.

Si un développeur a besoin d’une spécification technique entièrement détaillée, d’une architecture, d’un modèle de base de données, de cas de test, de cas limites et de critères d’acceptation précis avant de pouvoir commencer à travailler – pourquoi ne pas confier tout cela à l’IA ?

L’IA ne discute pas. L’IA ne prend pas les exigences personnellement. L’IA peut repérer les contradictions dans une spécification. Et au lieu d’attendre des semaines qu’un développeur implémente quelque chose, on peut souvent obtenir un prototype fonctionnel en quelques heures.

Même lorsque le résultat est faux, modifier les instructions et réessayer peut être bien plus simple que de changer le comportement d’un développeur humain qui a déjà passé des jours à implémenter son interprétation initiale.

J’ai commencé à procéder ainsi de façon répétée, et les résultats ont été presque stupéfiants. Tout semblait soudain tellement plus simple. C’est l’une des raisons pour lesquelles je pense que le développement avec l’IA transforme non seulement notre façon d’écrire du logiciel, mais aussi notre façon d’organiser des équipes entières.

Il y a ici une distinction importante. L’IA ne rend pas nécessairement un bon développeur inutile. Au contraire, les développeurs qui utilisent l’IA peuvent devenir considérablement plus productifs que ceux qui travaillent sans.

Un développeur qui comprend le problème métier, sait raisonner sur l’architecture et sait valider du code généré par l’IA travaille à un tout autre niveau de productivité.

La compétence n’est plus simplement « Savez-vous écrire le code ? ». Elle devient de plus en plus « Savez-vous comprendre le problème, l’expliquer à l’IA, évaluer le résultat et l’améliorer ? ». C’est un ensemble de compétences fondamentalement différent.

Comme beaucoup de mes collègues, j’ai découvert un effet secondaire de cette nouvelle productivité. L’IA n’a pas réduit ma charge de travail. Elle l’a augmentée.

À première vue, cela semble absurde. Si l’IA rend les développeurs considérablement plus productifs, les managers ne devraient-ils pas avoir moins à faire ? D’après mon expérience, c’est parfois l’inverse.

Au début des années 2000, je dirigeais une dizaine de programmeurs. Ils n’avaient pas besoin de spécifications extrêmement détaillées de ma part. Je leur donnais une direction, et ils trouvaient eux-mêmes l’implémentation. Je me sentais leader technique.

Vers 2015, je dirigeais une vingtaine de programmeurs, ainsi que plusieurs analystes et chefs de projet. Mon rôle ressemblait de moins en moins à celui d’un leader technique et de plus en plus à celui d’un psychologue – et parfois d’une baby-sitter.

Et aujourd’hui, en 2026, il se passe quelque chose de complètement différent. Avec l’IA, je peux faire moi-même ce qui nécessitait auparavant de nombreux développeurs sur plusieurs projets en parallèle. Et au lieu que les développeurs m’apportent des solutions, j’entends de plus en plus : « Donnez-moi les exigences. » « Donnez-moi la spécification. » « Dites-moi exactement ce que je dois construire. »

Le goulot d’étranglement s’est déplacé. L’IA a rendu l’implémentation bien moins chère et plus rapide. Mais mon cerveau d’ingénieur et d’architecte est surchargé de conception, d’analyse, d’invention, de validation et de prise de décision. Une sorte de réaction inverse semble se produire.

Cela a aussi des implications majeures pour l’IA dans la gestion de projet. Pendant des années, les chefs de projet et les responsables techniques ont consacré énormément de temps à traduire des idées en tâches, à décomposer les besoins, à lever les ambiguïtés, à rédiger des critères d’acceptation, à coordonner les développeurs et à dissiper les malentendus.

L’IA peut désormais participer à bon nombre de ces activités. Elle peut aider à transformer une idée métier en exigences techniques. Elle peut repérer les informations manquantes. Elle peut générer des user stories et des critères d’acceptation. Elle peut proposer des architectures et des approches d’implémentation. Elle peut même créer un premier prototype fonctionnel.

L’IA dans la gestion de projet ne se limite donc pas à automatiser des tâches administratives. Elle peut transformer l’ensemble de la relation entre les besoins métier, les chefs de projet, les architectes et les développeurs.

Mais il y a un piège. Quelqu’un doit encore réfléchir.

Cela nous ramène à la question initiale. Pour de nombreuses tâches, la réponse est clairement : à l’IA.

L’IA est remarquablement tolérante envers les instructions détaillées. Elle ne se vexe pas lorsque les exigences changent. Elle peut remettre en question les contradictions, explorer des alternatives, générer des prototypes, tester des idées et itérer extrêmement vite.

Aux entreprises qui, pour une raison ou une autre, évitent encore les technologies de développement logiciel basées sur l’IA, je fais une prédiction assez ferme : elles vont rencontrer de sérieux problèmes de compétitivité dans un avenir proche.

C’est particulièrement important lorsqu’on parle de développement logiciel sur mesure en 2026. Le modèle traditionnel – une grande équipe de développeurs passant des semaines à traduire des spécifications détaillées en code – est déjà remis en cause par un nouveau modèle dans lequel des équipes plus petites accomplissent bien davantage grâce à l’IA.

Mais une autre conclusion est tout aussi importante. Remplacer les programmeurs humains par l’IA n’est pas la solution. Cela ne ferait que créer une nouvelle crise.

La véritable opportunité consiste à augmenter la proportion de développeurs capables de penser de manière analytique. Nous avons besoin de développeurs qui ne se demandent pas simplement « Que dit exactement la spécification ? », mais plutôt « Quel problème cherchons-nous vraiment à résoudre ? ».

Ce sont ces personnes qui adopteront l’IA au lieu de la craindre. Elles l’utiliseront comme un amplificateur de leur propre intelligence, de leur créativité et de leur expérience d’ingénieur.

Et lorsque cela se produira, la productivité du développement logiciel n’augmentera pas seulement de quelques pour cent. Elle pourrait croître de manière exponentielle.

Les meilleurs développeurs de demain ne seront peut-être pas ceux qui tapent du code le plus vite. Ce seront peut-être ceux qui réfléchissent le mieux, posent les meilleures questions et travaillent le plus efficacement avec l’IA.

Je crois que nous entrons dans une ère où le coût de la programmation n’est plus l’obstacle principal. Écrire du code devient de moins en moins cher.

La partie difficile et précieuse se déplace ailleurs : concevoir, inventer, comprendre, décider et imaginer ce qui doit être construit en premier lieu. Le véritable avantage concurrentiel appartiendra à ceux qui sauront allier la créativité et la pensée analytique humaines aux énormes capacités d’exécution de l’IA.

C’est particulièrement significatif pour les entreprises de développement logiciel sur mesure en 2026. L’avantage concurrentiel viendra peut-être de moins en moins du nombre de développeurs, et de plus en plus de la présence de meilleurs penseurs qui savent tirer parti de l’IA.

L’avenir du développement logiciel ne consiste donc peut-être pas à remplacer les programmeurs par l’IA. Il pourrait plutôt consister à permettre aux programmeurs de penser comme des architectes, des inventeurs et des concepteurs de produits – pendant que l’IA prend en charge une part croissante de l’implémentation. Et c’est peut-être là la véritable transformation que nous commençons à peine à percevoir.