L’IA ne rend pas les développeurs plus productifs ? Vous n’y êtes pas du tout.
Vous avez sans doute vu passer ces études qui affirment, statistiques sérieuses à l’appui, que l’intelligence artificielle ne fait strictement rien pour la productivité des développeurs. Zéro gain. Nada. Certains chercheurs vont même jusqu’à mesurer un léger ralentissement chez les équipes qui s’en servent. Et vous vous dites peut-être : tiens, encore un mirage technologique de plus, encore une révolution qui ne révolutionne que le discours marketing. Non, non. Vous n’y êtes pas du tout.
C’est à peu près la position que démonte, point par point et sans détour, Quentin Adam, le PDG de Clever Cloud, dans un entretien qui mérite qu’on s’y arrête. Sa thèse est simple, presque brutale dans sa clarté : ces études mesurent l’IA comme copilote — un gadget qu’on active de temps en temps pour terminer une ligne ou suggérer une fonction — alors que le vrai basculement se joue ailleurs, du côté de ce qu’il appelle les orchestrateurs de code.
Mais qu’est-ce que cela change, au juste, un orchestrateur par rapport à un simple assistant ? J’y viens.
L’assistant, celui qu’on connaît depuis deux ou trois ans, reste un outil qu’on sollicite. Vous tapez, il complète, vous validez ou vous jetez à la poubelle. L’orchestrateur, lui, prend en charge des chaînes entières de tâches : il écrit, il teste, il corrige, il recommence, et il ne revient vers vous que lorsque le travail ingrat — celui qu’aucun développeur senior n’a envie de faire à onze heures du soir — est terminé. Le développeur ne code plus tout, il dirige. Un peu comme le chef d’orchestre qui ne joue d’aucun instrument mais sans qui la symphonie ne serait qu’un joyeux brouhaha. L’analogie n’est pas de moi, mais elle est tellement juste que je me l’approprie sans complexe.
Et c’est précisément là, selon Adam, que se niche le malentendu des études sur la productivité : elles interrogent des juniors qui utilisent un copilote comme une béquille, quand les vrais gains se mesurent chez les seniors qui utilisent l’orchestrateur comme un multiplicateur de force. Ce n’est pas la même mécanique. Ce n’est même pas le même métier.
Vous allez me dire que déléguer autant à une machine, c’est prendre le risque d’une qualité au rabais. C’est exactement l’objection que l’entretien anticipe, et la réponse est intéressante : il ne s’agit pas de faire confiance à l’IA sur parole, mais de l’enfermer — le mot n’est pas trop fort — dans une architecture de tests et de simulations si stricte que la machine n’a tout simplement plus le droit de se tromper sans que ça se voie immédiatement. On ne demande plus à l’IA d’avoir raison du premier coup. On lui demande de produire, et on vérifie, encore et encore, avant que quoi que ce soit n’atteigne la production. Magique, dans le sens où ça marche, mais franchement laborieux à mettre en place. Et je parle en connaissance de cause : quiconque a déjà tenté de bâtir une suite de tests réellement exhaustive sait que c’est un métier à part entière, pas une case à cocher.
Ce qui m’amène à un point que l’entretien ne traite peut-être pas assez frontalement, mais qui saute aux yeux dès qu’on y réfléchit deux minutes : si l’IA produit du code à ce rythme, encadrée par ces filets de sécurité automatisés, alors le code hérité — ce fameux legacy que toute la profession traîne comme un boulet depuis des décennies — perd d’un coup toute sa sacralité. Pourquoi s’échiner à comprendre une base de code vieille de quinze ans, écrite par quelqu’un qui a quitté l’entreprise en 2011, quand on peut la faire réécrire, testée et simulée, par une machine qui ne se plaint jamais des commentaires absents ? La belle affaire, diront les puristes qui ont bâti leur carrière sur la maîtrise de ces vieux systèmes. Le monde change quand même.
Et ce changement-là, forcément, bouscule aussi la gestion humaine des équipes. On ne manage pas de la même façon une équipe qui écrit ligne à ligne et une équipe qui supervise des flux automatisés. Les cycles de développement se compressent, les rôles se redessinent, et les managers qui croient pouvoir appliquer les recettes de 2015 à des équipes de 2026 risquent de découvrir, courageusement mais pathétiquement, qu’ils dirigent un orchestre avec des partitions périmées.
Mais l’entretien ne s’arrête pas au strict cadre de l’entreprise. Il y a une dimension plus large, presque géopolitique, que Quentin Adam pointe et qui mérite qu’on s’y attarde : cette mutation représenterait une occasion historique pour la souveraineté numérique européenne. Rien moins que ça. L’idée n’est pas absurde : si le métier de développeur se réinvente autour de nouvelles architectures et de nouveaux outils, l’Europe a une carte à jouer avant que les positions ne se figent durablement autour des géants américains. Mais — et c’est un mais de taille — cela suppose des investissements stratégiques à la hauteur de l’ambition, et des clauses contractuelles qui protègent réellement les entreprises européennes plutôt que de les enfermer, une fois de plus, dans la dépendance à des plateformes qu’elles ne maîtrisent pas.
On entend aussi des petites voix de plus en plus nombreuses dire que tout cela n’est qu’un effet de mode de plus, un buzzword qui remplacera le précédent d’ici dix-huit mois. Peut-être. Mais l’histoire de l’informatique nous a déjà appris une chose : ce n’est jamais l’outil le plus bruyant qui gagne, c’est celui qui, discrètement, change la façon dont on travaille sans qu’on s’en rende compte. Je vous laisse méditer sur cela.