Le développeur à l'ère de l'IA

C’est une question qui revient sans cesse, presque un classique de notre industrie, et la réponse est forcément subjective : qu’est-ce qu’un “bon” développeur ?

On peut voir cela comme un dilemme permanent, une tension entre deux écoles.

• D’un côté, il y a la maîtrise technique pure — la capacité à produire un code élégant, performant, une architecture qui résiste à la charge.
• De l’autre, il y a la capacité à comprendre un besoin, à cadrer un problème flou et à livrer une solution qui sert réellement les utilisateurs.

Pendant longtemps, chacun pouvait placer le curseur selon ses affinités, son expérience ou la culture de son entreprise.

Mais depuis l’arrivée de l’IA dans nos éditeurs de code, j’ai le sentiment que cette question prend une autre dimension. Elle ne nous demande plus seulement ce qu’on préfère faire, mais ce qui fera notre valeur durablement dans un monde où la production de code s’accélère de façon exponentielle.

La technique : un refuge confortable face à la complexité du réel

Quand j’ai commencé ce métier, la leçon était claire : le code n’est qu’un moyen. La finalité, c’est la résolution de problèmes. Il s’agissait de comprendre ce que quelqu’un cherche à accomplir et de traduire cela en solution technique, en tenant compte des contraintes réelles — budget, délais, politique interne.

Pourtant, au fil du temps, j’ai l’impression que cet équilibre s’est rompu.

Dans des organisations où les budgets étaient confortables et les équipes en hyper-croissance, on a pu consacrer une énergie démesurée à la technique, parfois au point d’en faire un refuge. Et c’est très humain : la technique a quelque chose de rassurant. Le code est binaire. Ça compile ou ça ne compile pas. Les tests passent ou ils échouent. C’est un univers de règles claires qui donne un sentiment immédiat de progression et de maîtrise.

À l’inverse, comprendre un besoin métier est rarement simple.

C’est une zone grise faite de nuances, de contradictions, de non-dits et de compromis. Cela demande d’écouter, de reformuler, et parfois d’avoir le courage de remettre en cause le cadrage initial. C’est une posture qui expose davantage que de rester “dans sa bulle” à dépiler des tickets bien spécifiés.

Ce repli sur l’exécution a sans doute été accentué par la dynamique du marché ces dernières années.

La multiplication des formations intensives et l’industrialisation du recrutement ont parfois réduit implicitement le métier à son socle technique visible. Sans juger les personnes — qui peuvent devenir d’excellents professionnels —, le modèle lui-même interroge. En formant à produire vite sur des stacks technologiques précises, donne-t-on toujours les clés pour comprendre le pourquoi, pour naviguer dans l’ambiguïté d’un projet ou pour faire équipe autour d’un objectif commun ?

On a parfois favorisé l’émergence de profils “exécutants”, très à l’aise avec la syntaxe, mais moins armés pour le reste.

L’IA comme révélateur : vers un nouvel équilibre ?

C’est précisément là que l’IA vient nourrir ma réflexion.

Elle rebat les cartes. Non pas en rendant les développeurs obsolètes, mais en réduisant drastiquement la valeur perçue de la production de code brute lorsqu’elle est isolée du contexte.

Si des outils sont désormais capables de générer, de documenter ou de refactorer des blocs entiers de code en quelques secondes, il devient difficile de se définir uniquement par “je code”. La barrière à l’entrée technique s’abaisse, et la question qui émerge est plus directe : qu’est-ce qui fait la différence une fois qu’on a enlevé la syntaxe ?

Paradoxalement, l’IA nous pousse peut-être à revenir à une définition plus complète, plus ancienne du métier. Celle qui inclut la technique, évidemment — car il faut savoir valider ce que la machine produit —, mais qui remet au centre ce qu’on a parfois sous-investi : la compréhension fine du métier, la capacité à dialoguer avec les parties prenantes, à faire des choix d’architecture éclairés et à assumer des compromis.

Au fond, le “bon” développeur de demain ne serait-il pas celui qui parvient à relier ces deux mondes ?

Il ne s’agit pas de choisir entre être un technicien brillant ou un expert fonctionnel, mais d’être celui qui fait le pont. C’est celui qui cherche à comprendre le besoin avant de foncer sur la solution, qui sait poser les questions qui fâchent pour éclaircir les zones d’ombre, et qui écrit du code maintenable non pas par dogmatisme, mais parce qu’il a compris les enjeux de long terme du projet.

C’est une piste de réflexion.

Mais j’ai l’impression que l’avenir appartient à ceux qui ne confondent pas l’activité (écrire des lignes) avec l’impact (résoudre des problèmes), et qui utiliseront l’IA pour se reconcentrer sur le cœur de leur métier : apporter de la valeur.