Non, les agents de code ne voleront pas votre métier : ils vont le démultiplier

L’arrivée des agents de code fait craindre à plusieurs ingénieurs la disparition de leur métier. L’histoire industrielle nous enseigne pourtant l’inverse : lorsqu’une ressource devient moins chère, nous en consommons généralement beaucoup plus. Le logiciel est sur le point de passer de la rareté à l’abondance.

Il existe aujourd’hui environ 48 millions de développeurs dans le monde pour près de 900 millions de travailleurs du savoir, développeurs compris. Autrement dit, une personne capable de bâtir du logiciel pour environ 18 personnes qui en dépendent directement ou indirectement. 

Ce ratio définit notre industrie depuis des décennies.

Presque toutes les organisations ont plus d’idées, de problèmes à régler et de processus à numériser que de capacité de livrer des logiciels. Nous sommes en forte demande, précisément parce que la capacité de produire du logiciel demeure une ressource rare.
Mais be nouvelle machine industrielle vient d’arriver. Et elle change complètement l’économie de la production logicielle.

Ratio mondial des développeurs et travailleurs du savoir : 48 M de développeurs pour 900 M de travailleurs du savoir.

La machine arrive : qu’est-ce qu’un agent de code, vraiment?

Un agent de code n’est pas un chatbot auquel on demande de corriger une fonction. Ce n’est pas non plus un autocomplete plus intelligent.

Un véritable agent reçoit une intention, analyse son contexte, construit un plan, choisit entre différentes options, produit un livrable et vérifie ensuite son propre travail. Il peut lire une base de code, modifier plusieurs fichiers, exécuter des tests, interpréter les erreurs et recommencer jusqu’à atteindre le résultat demandé.

La distinction importante est celle entre le vibe coding et le développement spec-driven.

Le vibe coding, c’est : « Construis-moi un portail client moderne. » Le modèle improvise à partir d’une intention vague. Le résultat peut être impressionnant dans une démonstration, mais il est rarement reproductible, gouvernable ou suffisamment sécuritaire pour une organisation complexe.

L’approche spec-driven part du même besoin, mais le transforme en une spécification structurée : objectifs d’affaires, utilisateurs, comportements attendus, contraintes réglementaires, architecture, interfaces, dépendances et critères d’acceptation.

Le résultat spec-driven n’est donc pas simplement du meilleur code. Il est différent en nature : structuré, multidisciplinaire, vérifiable et reproductible.

Les premières études sur les outils de génération de code montrent déjà des gains importants. Dans une expérience contrôlée, GitHub a observé que les développeurs utilisant Copilot terminaient une tâche 55 % plus rapidement. McKinsey a, pour sa part, mesuré des gains allant jusqu’à deux fois la vitesse habituelle sur certaines tâches bien circonscrites.

Mais la même recherche montre également que l’outil seul ne suffit pas. Plus le problème devient complexe, plus le contexte, l’expertise humaine et la qualité des instructions deviennent déterminants.

Le paradoxe de Jevons : pourquoi moins cher veut dire plus, pas moins

En 1865, l’économiste William Stanley Jevons observe un phénomène qui semble, à première vue, 
complètement illogique.

Les améliorations apportées à la machine à vapeur réduisent radicalement la quantité de charbon nécessaire pour produire une unité de puissance. On aurait donc pu croire que la consommation totale de charbon allait diminuer.

C’est exactement l’inverse qui s’est produit.

Parce que l’énergie mécanique devenait moins coûteuse, elle devenait rentable dans davantage d’usines, de mines, de navires et de chemins de fer. La Grande-Bretagne n’a pas utilisé moins de charbon. Elle a trouvé des milliers de nouvelles façons d’utiliser la puissance rendue disponible par ce charbon.

C’est le paradoxe de Jevons : lorsqu’une ressource devient plus efficace et moins coûteuse, son utilisation totale peut augmenter plutôt que diminuer.

Machines à vapeur Newcomen et Watt illustrant le paradoxe de Jevons accompagnées des repères sur la consommation de charbon.

Le parallèle avec le logiciel est direct.

Si une application coûte dix fois moins cher et prend dix fois moins de temps à produire, les entreprises ne vont probablement pas maintenir exactement le même portefeuille de projets avec dix fois moins de développeurs.

Elles vont construire beaucoup plus de logiciels.

Nous le vivons déjà chez Vooban. Nos équipes des finances, des ressources humaines et du marketing bâtissent maintenant leurs propres outils : rapports financiers plus poussés, recrutement mieux outillé, campagnes à plus grande portée. Des logiciels que nous n’aurions jamais crus possibles, ni rentables, auparavant.

Une ressource devenue abondante ouvre des catégories entières de produits et de services. Le cargo à vapeur n’a pas seulement réduit le coût du transport maritime : il a fait naître un commerce mondial de marchandises qui, jusque-là, ne valaient pas le voyage.

Selon les données historiques du Maddison Project, le PIB réel par habitant aux États-Unis a été multiplié par plus de vingt depuis 1820. Cette croissance ne provient pas uniquement de machines plus efficaces. Elle provient de tout ce que ces machines ont soudainement rendu possible.

Le logiciel est sur le point de vivre le même phénomène.

De l’exécution à la conception : Apple, Nvidia et le nouveau métier

Apple ne réalise pas manuellement toutes les étapes nécessaires à la fabrication d’un iPhone. Nvidia n’exploite pas elle-même les usines qui fabriquent ses processeurs.

Ces entreprises conçoivent des produits, des architectures, des systèmes, des interfaces et des standards extrêmement précis. Des réseaux de machines et de partenaires exécutent ensuite une partie importante de la production.

Elles ont déplacé la valeur de l’exécution vers la conception.

C’est exactement le glissement qui attend le génie logiciel.

Nous allons progressivement taper moins de code et diriger davantage les machines qui le produisent. Le métier ne disparaît pas. Il monte d’un niveau d’abstraction.

La compétence centrale devient la capacité de transformer une intention humaine en spécifications qu’un système peut comprendre, exécuter et vérifier.

Un projet récent chez nous l’illustre bien.

Une petite équipe vient de livrer en neuf semaines un produit qui aurait normalement demandé autour de dix-huit mois, de l’idéation jusqu’à une première cohorte de clients.

Ce n’était pas un prototype jetable construit pour une démonstration. C’était un produit réel, structuré, avec une architecture, une expérience utilisateur, des mécanismes de gouvernance et des utilisateurs externes.

Trois leviers expliquent cet écart. Un prototype se construit désormais en quelques heures plutôt qu’en quelques semaines, ce qui accélère notre compréhension de ce que le produit peut et doit être.

Des agents accélèrent la rédaction de nos spécifications, et d’autres couvrent la chaîne du développement : code, tests, déploiement. Nous sommes ainsi allés en marché en quelques semaines pour recueillir la rétroaction d’une première cohorte de clients. Le produit évolue maintenant vers une version 2.

Le plus intéressant est que nous n’avons pas simplement fait la même chose plus rapidement. Nous avons exploré davantage d’options. Nous avons testé plus d’hypothèses. Nous avons produit plus de versions et corrigé plus rapidement ce qui ne fonctionnait pas.

Et le paradoxe est là : je n’ai jamais autant bâti de logiciels de ma vie.

L’efficacité n’a pas réduit notre ambition. Elle l’a augmentée.

Comparaison entre 18 mois et 9 semaines de mise en marché, de l’idéation jusqu’à la première cohorte externe.

Ce qu’il faut apprendre maintenant

La première compétence est une compréhension minimale des grands modèles de langage.

Un LLM n’est pas une base de données et ne possède pas, par défaut, une mémoire persistante de votre organisation. Il travaille à partir d’une fenêtre de contexte limitée. Plus cette fenêtre est remplie d’informations inutiles, contradictoires ou mal structurées, plus la qualité du résultat peut se dégrader.

Il faut donc apprendre à sélectionner, organiser et actualiser l’information fournie aux modèles.

La deuxième compétence est une compréhension minimale de l’agentique : les agents, les skills, les outils et l’orchestration.

Un skill est une capacité spécialisée et réutilisable : lire un contrat, analyser une base de code, produire un calcul, vérifier une norme ou générer un rapport. Un agent combine plusieurs skills pour atteindre un objectif plus large.

J’aime dire que les skills et les agents sont l’Excel de l’IA.

Tout le monde pourra en bâtir, pas seulement les chercheurs et les développeurs spécialisés. Et comme Excel, ils transformeront éventuellement des millions de travailleurs en concepteurs de petits systèmes automatisés.

Les recherches récentes d’Anthropic montrent d’ailleurs que l’expertise demeure centrale dans cette nouvelle façon de travailler. Les utilisateurs qui comprennent réellement leur domaine arrivent à déléguer davantage aux agents et obtiennent de meilleurs résultats. L’agent ne remplace donc pas l’expertise. Il lui donne un levier.

La troisième compétence est la plus importante : apprendre à penser par spécification.

La spec devient la nouvelle unité de travail. Elle décrit l’intention, les contraintes, les décisions, les dépendances et les critères qui permettent de juger le résultat.

Sans spec, on obtient une machine extrêmement productive, mais qui peut aller très rapidement dans la mauvaise direction.

Durkheim s’intéressait déjà, à la fin du XIXe siècle, aux conséquences de la division du travail et au risque de séparer l’exécutant du sens de ce qu’il produit.

Le danger demeure.

L’ingénieur qui accepte aveuglément le code d’un agent devient l’opérateur d’une machine qu’il ne comprend plus. Celui qui maîtrise la spécification reste responsable de l’intention, des arbitrages et du système dans son ensemble.

Et le génie hors logiciel? Subir ou bâtir!

Cette transformation ne restera pas confinée au développement logiciel.

En génie civil, mécanique, électrique ou industriel, les mêmes patterns d’industrialisation cognitive arrivent déjà : simulation, analyse de conformité, optimisation de plans, préparation documentaire, modélisation et design génératif.

Les agents et les grands modèles de langage savent désormais opérer les outils d’ingénierie, dont la CAO, et accélérer les calculs. Autodesk a ouvert Fusion aux agents d’IA ; Siemens a intégré un copilote d’IA à NX. En simulation, Ansys SimAI prédit en quelques secondes des résultats qui exigeaient des heures, voire des jours de calcul.

La matière première change, mais la logique demeure.

Lorsque le coût d’explorer une option ou de produire un prototype diminue, nous n’en produisons pas simplement à moindre coût, nous explorons davantage d’options et nous testons plus d’hypothèses.

Le rôle de l’ingénieur se déplace lui aussi vers la formulation du problème, la conception du système et la validation des résultats.

Les agents vont automatiser une partie importante de l’exécution. Ils vont aussi rendre économiquement possibles des millions de projets qui ne l’étaient pas hier.

La vraie question n’est donc pas de savoir si la vague va arriver. Elle est déjà là.

Il reste deux options : subir ou bâtir.

Cette semaine, prenez une spécification, un ticket, une analyse, un calcul ou une petite fonctionnalité. Décrivez clairement le résultat attendu, les contraintes et les critères de validation. Puis confiez l’exécution à un agent.

Pas uniquement pour économiser une heure.

Pour commencer à apprendre le nouveau métier.