« Le logiciel est mort » : une exagération (et comment le marché a tout lu de travers)
Cette année, le marché a décidé que le logiciel se meurt.
Les gros titres parlent d'une sorte d'apocalypse du SaaS : des dizaines d'éditeurs de logiciels cotés ont vu fondre une part énorme de leur capitalisation — des milliers de milliards de dollars, tout compris — sous une thèse aussi simple que tranchante. Si un agent d'IA peut faire le travail que faisait ton produit, pourquoi continuerait-on à payer pour ton produit ? L'argument est net, il tient dans un tweet, et il a déplacé énormément d'argent.
Et, comme presque toutes les thèses nettes qui déplacent beaucoup d'argent, c'est lire à l'envers ce qui se passe vraiment.
Je n'écris pas ça du fauteuil de l'investisseur, mais de celui de qui construit. Je livre du logiciel en production depuis assez longtemps pour avoir assisté à l'enterrement de cette industrie plusieurs fois, et toujours selon le même scénario : une technologie nouvelle rend évidente une pièce de la valeur, le marché confond cette pièce avec l'ensemble, et pendant que tout le monde est à l'enterrement, le vrai travail file en douce vers une autre couche de la stack. Cette fois n'a rien d'exceptionnel. Ce qui a baissé de prix, ce n'est pas le logiciel. C'est le modèle.
Le marché n'a pas tué le logiciel ; il a revu le prix du modèle
Le malentendu de fond, c'est de traiter « modèle » et « logiciel » comme si c'était la même chose. Ça ne l'est pas, et toute l'histoire tient dans cette différence.
Un modèle de langage est un moteur statistique impressionnant et, trimestre après trimestre, de moins en moins cher et de plus en plus interchangeable. Aujourd'hui tu en as une demi-douzaine, à la frontière de l'état de l'art, qui font à toutes fins utiles un travail équivalent, et tu remplaces l'un par l'autre en changeant une ligne de configuration. C'est, littéralement, la définition d'une marchandise (commodity) : un input puissant, certes, mais sans fossé défensif, parce que ton concurrent dispose du même input au même prix.
Ce que le marché a sanctionné, ce n'est pas la mort du logiciel, mais la découverte — soudaine et mal digérée — que le modèle n'est pas un fossé. Et il avait raison de sanctionner les entreprises qui avaient convaincu tout le monde du contraire. Là où il se trompe, c'est à l'étape suivante : supposer que, si le moteur est bon marché, la voiture entière vaut zéro.
Quiconque a construit de vrais systèmes sait que le moteur a toujours été la partie facile.
Ce film, on l'a déjà vu
Au début des années 2000, quand le SaaS s'est mis à dévorer le logiciel packagé, la peur était identique : le cloud va transformer le logiciel en marchandise, les marges vont s'évaporer, les géants sont périmés. Les licences perpétuelles, les CD d'installation, les serveurs chez le client : tout ça allait mourir. Et c'est bel et bien mort.
Et pendant ce temps, l'industrie du logiciel s'est multipliée. Ce qui était un marché de quelques centaines de milliards de dollars par an en est venu à brasser autour de mille cinq cents milliards en un peu plus d'une décennie. Les prétendus cadavres — Microsoft, Adobe, Oracle — n'ont pas seulement survécu : ils sont devenus plusieurs fois plus gros qu'avant la disruption censée les achever.
La leçon n'est pas « tout finira par s'arranger ». Certaines entreprises sont bel et bien mortes, et beaucoup de postes précis ont vraiment disparu. La leçon est plus fine : disruption n'est pas synonyme de mort. Ce qui s'est passé avec le cloud n'a pas été une contraction du logiciel, mais un changement de forme — et, au passage, une explosion de tout ce qu'il restait à construire. Qui a confondu « mon modèle d'affaires d'il y a dix ans se meurt » avec « le logiciel se meurt » a vendu au pire moment de l'histoire pour le faire.
« L'IA ne remplacera pas le logiciel : elle l'utilisera »
Voici la phrase qui retourne toute la thèse pessimiste, et il vaut la peine de la lire lentement : l'agent d'IA n'est pas un substitut au logiciel. C'est son nouvel utilisateur, et le plus exigeant.
Demande-toi ce dont un agent a réellement besoin pour abattre du travail utile contre tes systèmes. Il lui faut une API propre et versionnée à appeler. Il lui faut des permissions granulaires, parce que tu ne vas pas lui confier les clés de tout. Il lui faut de l'idempotence, parce qu'un agent réessaie. Il lui faut des rate limits, parce qu'un agent coincé dans une boucle peut marteler un endpoint mille fois par seconde. Il lui faut de la traçabilité et de l'audit, parce que le jour où une action automatique touchera la comptabilité d'un client, quelqu'un devra pouvoir reconstituer qui l'a décidée et pourquoi. Il lui faut des guardrails, du sandboxing, et une surface d'outils conçue pour qu'un acteur non déterministe ne fasse pas de dégâts.
Rien de tout ça n'apparaît tout seul. Tout ça, c'est du logiciel, et ce sont des ingénieurs qui le construisent. Quand ton utilisateur le plus vorace cesse d'être une personne qui clique sur un bouton et devient un agent qui déclenche mille actions par minute, la surface de logiciel que tu dois construire et exploiter ne rétrécit pas : elle explose. Chaque capacité que tu cachais hier derrière une interface humaine, il faut désormais l'exposer, la sécuriser, la borner et la surveiller comme un outil de premier plan. Ça, c'est plus d'ingénierie, pas moins.
Le centre d'appels qui répond aux questions avec un script, oui, l'agent le remplace pour de bon, et faire semblant du contraire n'aide personne. Mais le système que l'agent utilise pour résoudre le cas pour de vrai — consulter la commande, valider la règle, émettre le remboursement sans rien casser — quelqu'un doit le construire, et il ne se construit pas tout seul.
La valeur monte dans la stack, elle ne s'évapore pas
Si le modèle est le moteur bon marché et interchangeable, où atterrit la valeur ? Elle monte. Vers la couche que le modèle ne peut pas te donner : tes données et, surtout, tes workflows de confiance.
Un modèle de frontière ne sait pas comment ton entreprise traite un retour, quelles sont tes règles de compliance, ce que veut dire « client à risque » dans ton secteur, ni quelle étape de ce processus à six maillons est celle qu'on ne saute jamais. Tout ce savoir — codifié, vérifié, intégré à tes vrais systèmes — est précisément ce qu'on ne télécharge pas chez un fournisseur de modèles. C'est le fossé. Et c'est, comme par hasard, la partie la plus difficile et la plus chère à construire : l'intégration, la qualité des données, la vérification, les guardrails, le discernement de savoir quand passer la main à un humain.
J'ai déjà détaillé pourquoi cette couche — le harness qui entoure le modèle — est l'endroit où vit vraiment l'ingénierie, et pourquoi sa complexité croissante annonce plus de travail pour les ingénieurs, pas moins, dans Agentic-as-a-Service et le retour de l'ingénieur. Le résumé, pour les pressés : le modèle banalise les 80 % faciles, et la différenciation migre tout entière vers le système qui l'entoure. Et ce système ne se génère pas tout seul.
Le prix change de forme ; il ne disparaît pas
L'autre moitié de la panique, c'est le modèle d'affaires. Si tu arrêtes de vendre des « sièges » parce qu'il n'y a plus d'humains assis devant l'écran, comment factures-tu ?
Eh bien tu changes d'axe. Au lieu de facturer par utilisateur, tu factures au travail accompli : à l'action de l'agent, au cas résolu, au résultat. Et ce basculement, loin d'être une menace, c'est le rêve de quiconque vend du logiciel qui fait vraiment des choses : tu cesses de facturer le nombre de gens qui ouvrent l'app pour facturer la valeur qu'elle produit. Les entreprises déjà engagées dans cette transition rapportent qu'une part substantielle du nouveau chiffre d'affaires ne se vend plus au siège. Ce n'est pas la fin de la monétisation du logiciel. C'est une façon plus honnête de le monétiser.
Un modèle d'affaires qui évolue, ce n'est pas une industrie qui meurt. C'est une industrie qui grandit assez vite pour faire peur à ceux qui la regardent de l'extérieur.
Ce que je ferais si j'étais ton CTO ce trimestre
Trois paris concrets, parce qu'un diagnostic sans action n'est qu'un avis qui a de l'allure :
- Ne mise pas ton fossé sur le modèle. Si ta différenciation dépend du LLM que tu utilises, c'est que tu n'en as pas — ton concurrent peut louer le même demain. Place le fossé là où ça ne se loue pas : tes données, tes workflows, ta vérification, ton intégration.
- Traite chaque agent comme un utilisateur de premier plan. Conçois les API, les permissions, l'audit et les guardrails en partant du principe que ton client principal sera non déterministe et infatigable. Ce que tu bâtis ici, c'est précisément ce qu'on aura le plus de mal à te copier.
- Fais grimper le compte d'ingénieurs, pas baisser. La tentation du gros titre, c'est de tailler parce que « l'IA s'en charge ». Le pari de qui a déjà vu le film est l'inverse : l'explosion de la surface de logiciel réclame plus de gens capables de raisonner sur des systèmes probabilistes sous charge, pas moins. Qui taille aujourd'hui passera 2027 à réembaucher, comme l'ont déjà vécu ceux qui avaient devancé la mode des licenciements.
La ligne que je défends est la même que toujours, et le marché me l'illustre aujourd'hui avec un enterrement hors de prix : l'IA ne remplace pas le logiciel, elle l'utilise ; et elle ne remplace pas l'ingénieur, elle le démultiplie. Ce qui est mort, c'est l'idée confortable que le moteur était le fossé. Tout le reste — la voiture entière — reste à construire, et il n'y a jamais eu autant à construire.
La mort du logiciel, comme celle de ce fameux écrivain, a été très exagérée. Et ceux qui sauront la lire à l'endroit seront ceux qui livreront les systèmes qui comptent vraiment cette décennie.
Tu construis la couche qui fait vraiment la différence — workflows, intégration, vérification — et tu as besoin d'ingénieurs seniors qui savent où l'IA augmente et où elle ne fait rien ? Parle avec un CTO pour déployer un squad nearshore qui construit le fossé, pas seulement qui branche le modèle.
