Pourquoi l'IA ne remplacera pas le besoin d'ingénieurs : le paradoxe de Jevons s'invite en ingénierie logicielle 

Des comptables, kinés et agents immobiliers construisent aujourd’hui leurs propres applications fonctionnelles en quelques jours. Ces applications répondent à des besoins réels mais tournent sur des infrastructures précaires, sans sécurité RGPD, sans tests, sans stratégie de déploiement. 

Cette démocratisation du développement va créer une explosion cambrienne du logiciel. Chaque métier, chaque niche voudra “son” application. Et transformer ces prototypes en systèmes fiables, sécurisés et maintenables nécessitera plus d’ingénieurs que jamais. 

Le paradoxe de Jevons : quand l’efficacité crée la demande 

En 1865, l’économiste britannique William Stanley Jevons publie “The Coal Question”. Sa thèse est contre-intuitive : les améliorations de l’efficacité des machines à vapeur, loin de réduire la consommation de charbon, l’ont au contraire fait exploser. Le mécanisme est limpide : un moteur plus efficient rend le charbon plus rentable à utiliser, ce qui pousse à l’adopter dans des contextes où il n’aurait jamais été envisagé auparavant, ce qui au final augmente la demande globale. 

C’est le paradoxe de Jevons : quand une ressource devient plus facile à exploiter, on ne l’économise pas, on en consomme davantage. 

Deux exemples modernes pour fixer les idées. Les autoroutes d’abord : on élargit une voie pour fluidifier le trafic, mais de nouveaux trajets deviennent “acceptables”, de nouveaux usagers apparaissent, et la saturation revient. L’offre a généré sa propre demande.

Le stockage numérique ensuite : dans les années 90, un disque dur de 1 Go semblait infini. Aujourd’hui, nous jonglons avec des téraoctets et manquons toujours de place. Le coût au gigaoctet a chuté de façon vertigineuse ; notre consommation a suivi exactement la même courbe, mais à la hausse. 

Le mécanisme est toujours le même : rendre quelque chose plus accessible ne réduit pas le besoin, ça le démultiplie. 

Le kiné qui livre une application en un week-end grâce aux agents de code 

Quelque chose d’inédit se produit en ce moment, et j’en observe les signes au quotidien. Des professionnels qui n’ont jamais écrit une ligne de code construisent des applications fonctionnelles autour de leur métier.

Un comptable qui automatise la réconciliation de ses notes de frais. Un kiné qui crée un outil de suivi de rééducation pour ses patients. Un agent immobilier qui se bricole un outil de gestion de la relation client sur mesure, calé sur les spécificités de son marché local. 

Et le plus troublant : ça marche. Pas “ça marche un peu, pour un non-développeur”. Ça répond réellement à leur besoin, parfois mieux qu’un produit du marché, et infiniment mieux que ce qu’un développeur externe aurait pu leur livrer.

La raison est structurelle : ce comptable connaît les cas limites de son métier, ceux qu’aucun cahier des charges n’aurait jamais capturés. Il sait que tel client envoie systématiquement ses factures dans un format aberrant, que tel calcul de TVA a une exception propre à son secteur. Ce savoir métier est un avantage qu’un cahier des charges, aussi bien mené soit-il, ne capture qu’imparfaitement. L’expert métier ne se contente pas de décrire son besoin. Il le vit, avec ses exceptions, ses raccourcis, ses irritants du quotidien qu’il ne penserait même pas à formaliser. 

Ces applications sont des victoires réelles. Elles résolvent des problèmes concrets, pour des audiences restreintes, avec une précision chirurgicale. Et elles n’existaient tout simplement pas il y a deux ans. 

La cabane et l’immeuble : du prototype au système en production 

Sauf que l’application du comptable, elle tourne sur un hébergement précaire qui tombera au premier pic de charge. Il n’y a pas de gestion d’erreurs robuste, pas de supervision, pas de chaîne de déploiement, pas de tests automatisés, pas de stratégie de migration de données. La sécurité est au mieux naïve, au pire inexistante. Les données personnelles des patients du kiné sont probablement stockées en clair, sans chiffrement, sans conformité RGPD, sans traçabilité des accès. 

Et c’est normal. Ce n’est pas un reproche, c’est un constat de terrain. On retrouve ici exactement le phénomène que j’évoquais dans un précédent article sur l’ingénierie de contexte : l’IA produit du code qui fonctionne, mais elle n’a aucune conscience de l’écosystème dans lequel ce code doit vivre. Elle ne pense pas “système”. Elle répond à une instruction. 

Construire un logiciel qui tient la route en production, qui passe à l’échelle, qui résiste aux pannes, qui protège les données de ses utilisateurs et qui se maintient dans le temps, c’est un métier. Un métier qui ne se résume pas à “écrire du code qui passe les tests sur ma machine”. 

C’est la différence entre construire une cabane dans son jardin et concevoir un immeuble. Les deux sont utiles. Les deux répondent à un besoin réel. Mais l’un des deux nécessite un architecte, un ingénieur, une structure, et un permis de construire. 

Le charbon, la vapeur, et nos lignes de code : le paradoxe de Jevons appliqué à l’ingénierie logicielle 

Voici ma conviction, et elle s’est renforcée mois après mois en observant nos équipes et notre écosystème : l’accessibilité nouvelle du développement logiciel – portée par les grands modèles de langage et l’IA générative – ne va pas remplacer les ingénieurs logiciels. Elle va créer un paradoxe de Jevons. 

Reprenons le mécanisme et filons la métaphore. Le charbon de Jevons, c’est le logiciel. La machine à vapeur améliorée, c’est l’IA générative. Aujourd’hui, le “coût” de production d’une application chute drastiquement : une instruction bien formulée, quelques itérations avec un modèle de langage, et on obtient une application qui fonctionne. La barrière d’entrée s’effondre. 

Et que se passe-t-il, selon Jevons, quand le coût d’exploitation d’une ressource chute ? La demande explose. Chaque métier, chaque niche, chaque besoin spécifique qui n’aurait jamais justifié un budget de développement devient un candidat légitime pour avoir “son” application. Le comptable, mais aussi l’artisan, le chercheur, l’enseignant, le responsable associatif…chacun avec ses outils sur-mesure. Nous allons assister à une explosion cambrienne du logiciel. 

C’est ici que le raisonnement “l’IA remplace les développeurs” s’effondre. Parce que cette explosion crée mécaniquement une cascade de besoins en ingénierie que personne n’anticipe : 

• L’interopérabilité. Ces milliers de nouvelles applications vont devoir, tôt ou tard, communiquer entre elles. Échanger des données de façon fiable entre l’outil de gestion artisanal de l’agent immobilier et le système d’information de son réseau, ça ne se résout pas par une instruction à un modèle. Ça se conçoit, avec des contrats d’interface, des protocoles, des stratégies de gestion d’erreur. 
• La sécurité et la conformité. Chaque nouvelle application qui manipule des données personnelles est un vecteur d’attaque potentiel et un sujet de conformité réglementaire. RGPD, NIS2, DORA selon les secteurs, autant de cadres que le comptable ne connaît pas et que le modèle de langage ne vérifie pas spontanément. 
• La résilience et le passage à l’échelle. Le prototype qui fonctionne pour 10 utilisateurs et le système qui en sert 10 000 n’ont rien en commun, ni en architecture, ni en exploitation. Quand l’application du kiné passe de son cabinet à un réseau de 200 praticiens, quelqu’un devra repenser le stockage, la mise en cache, la distribution, la supervision. 
• La maintenance dans le temps. C’est peut-être le point le plus sous-estimé. Le modèle qui a généré l’application aujourd’hui produira un code différent dans six mois. Les dépendances évoluent. Les interfaces tierces changent. Sans tests de non-régression, sans chaîne d’intégration continue, sans stratégie de gestion des versions, ces applications sont des châteaux de sable face à la marée. 
• La dette des systèmes historiques. Et il y a un pan entier que l’on oublie dans cette équation : les DSI regorgent de systèmes vieillissants qui tournent encore. Des calculateurs mainframe en COBOL, des progiciels dont la dernière mise à jour remonte à une décennie, des socles techniques obsolètes qui tiennent par habitude autant que par nécessité. Ces systèmes ne sont plus aux normes de sécurité, ne répondent plus aux exigences réglementaires actuelles, et personne n’ose y toucher faute de budget ou de compétences disponibles. Or, la démocratisation de l’accès au développement va libérer des budgets et des ambitions : si produire du logiciel neuf coûte moins cher, une partie de ces marges retrouvées sera naturellement redirigée vers la remise à niveau de ces patrimoines logiciels. Réécrire, moderniser, sécuriser ces fondations; c’est un chantier colossal qui, lui aussi, exige des ingénieurs. 

Qui va adresser tout cela ? Pas le comptable. Pas le kiné. Pas l’agent immobilier. Ils ont fait leur part – brillamment – en exprimant le besoin métier et en construisant le premier jet. Mais transformer ce prototype en produit fiable, c’est le métier des équipes de production logicielle. Et pas seulement de l’ingénieur.

Parce qu’un système qui tient, c’est aussi un parcours utilisateur pensé, testé, itéré. Et ça, c’est le travail du concepteur d’expérience utilisateur. C’est une accessibilité qui ne s’improvise pas. C’est une cohérence visuelle et fonctionnelle qui fait la différence entre un outil qu’on utilise une fois et un produit qu’on adopte.

L’explosion du logiciel va démultiplier le besoin pour l’ensemble de la chaîne : ingénieurs, concepteurs, responsables produit; toute l’équipe qui transforme une idée en expérience fiable. 

Côté ingénierie, cela exige de penser un système de façon holistique : déploiement, orchestration de services, patrons de conception comme outils de structuration de la complexité, pas comme réponses à un entretien technique, observabilité, performance, coût. Et, oui, la capacité à piloter intelligemment les modèles de langage, en sachant exactement quand ne pas leur faire confiance. 

Plus il est facile de créer du logiciel, plus on en crée. Plus on en crée, plus il faut de gens qui savent le faire vivre en production. L’IA rend le code accessible à tous. Mais elle rend l’ingénierie logicielle, la vraie, celle des systèmes, plus indispensable que jamais. 

Jevons aurait souri.