Le logiciel qui survit à la vague de l'IA n'est pas le moins cher, mais le plus difficile à abandonner
Il existe une expérience de pensée qui vaut la peine d'être menée avant de parler de stratégie produit : prenez votre stack logiciel et posez-vous une question sur chaque outil. Si demain il disparaît, combien de temps vous faudrait-il pour le remplacer par un agent d'IA bien instruit ? Si la réponse est « une après-midi », le produit se trouve sur un terrain fragile. Si la réponse est « des mois de migration, de validation réglementaire et de reconstruction d'historique », ce produit possède quelque chose qui vaut bien plus que son interface.
Cette expérience est en train de cesser d'être hypothétique. Dans les premiers mois de 2026, des entreprises de toutes tailles ont commencé à la mener sérieusement, et les résultats sont en train de redessiner quelle partie du marché du logiciel a un avenir et laquelle ne peut tout simplement plus justifier son prix lorsqu'un modèle de langage bien configuré fait la même chose pour une fraction du coût.
Le phénomène a un nom : certains l'appellent la « SaaSpocalypse ». Le terme est accrocheur, mais le diagnostic qui le sous-tend n'est pas apocalyptique, il est chirurgical. Ce n'est pas le logiciel en tant que catégorie qui est en train de mourir. C'est une couche spécifique du logiciel qui disparaît — la plus coûteuse à construire en termes de marketing et la plus facile à remplacer en termes de fonction. Ce qui reste debout, c'est ce qui a toujours été véritablement difficile à construire : des données qui s'accumulent, des flux de travail qu'on ne peut pas débrancher sans conséquences, et une connaissance opérationnelle qu'aucun modèle ne peut inférer à partir de zéro.
L'économie qui a changé d'un coup
Pour comprendre l'ampleur du mouvement, il est utile de mettre des chiffres sur la table. En février 2026, le secteur SaaS a perdu l'équivalent de 300 milliards de dollars de capitalisation boursière en une seule séance. Quelques mois plus tard, un article de Forbes décrivait comment le secteur avait effacé près de mille milliards de dollars de valeur avant de se stabiliser avec un rebond partiel de 13 %. Ce rebond n'était pas le signe que le problème s'était résolu. C'était le signe que les marchés avaient commencé à distinguer entre le logiciel qui dispose d'un fossé défensif et celui qui n'en a pas.
Le mécanisme de pression vient de deux fronts simultanés. D'un côté, les agents d'IA matures peuvent aujourd'hui exécuter des flux de travail complexes qui nécessitaient auparavant des licences de logiciels spécialisés. De l'autre, les outils de développement assistés par l'IA ont réduit le coût de construction de logiciels personnalisés à un point tel qu'ils rendent viables des alternatives qui étaient auparavant économiquement absurdes.
Une société immobilière de taille moyenne a remplacé un contrat de CRM d'entreprise à six chiffres annuels par une application construite avec des outils d'IA. Le système de remplacement coûte environ 300 dollars par mois de maintenance, ce qui représente une économie proche de 100 000 dollars par an. Une startup de 45 personnes appelée Atonom a réalisé un mouvement équivalent : elle a abandonné un contrat Salesforce évalué à 40 000 dollars par an et migré vers un CRM maison dont le coût devrait s'élever à environ 1 200 dollars par an. Ce ne sont pas des expériences marginales. Une enquête de Retool portant sur 817 équipes produit a révélé que 35 % d'entre elles avaient déjà remplacé au moins un outil SaaS par une construction interne, et que 78 % déclaraient avoir l'intention de construire davantage d'outils propriétaires au cours de l'année 2026.
Ce que ces chiffres révèlent n'est pas l'effondrement du modèle SaaS. Ils révèlent l'effondrement du logiciel qui n'a jamais eu d'autre défense que son prix d'acquisition initial et l'inertie du client. Quand cette inertie cède, le produit se retrouve exposé.
Où se trouve le fossé qu'un agent ne peut pas franchir
La logique de ce qui survit et de ce qui ne survit pas a une structure assez claire lorsqu'on la regarde sous l'angle de la disposition réelle à payer par rapport à la disposition à migrer.
Les données propriétaires accumulées constituent l'actif le plus difficile à répliquer. Un modèle de langage peut générer des formulaires de conformité, rédiger des contrats ou analyser des tendances de marché. Ce qu'il ne peut pas faire, c'est générer cinq ans d'historique d'approbations réglementaires croisées avec des signatures départementales et des versions auditées de documents cliniques. Cet historique n'existe qu'à un seul endroit : la plateforme qui l'a capturé. Lorsqu'une entreprise pharmaceutique doit démontrer la traçabilité devant un régulateur, le logiciel qui détient ces enregistrements n'est pas interchangeable avec quoi que ce soit de construit en une après-midi avec de l'IA. Le coût de migration n'est pas seulement technique ; il comprend la revalidation, le risque de conformité et la responsabilité juridique. Personne ne signe cela volontairement.
C'est le schéma qu'a articulé Bain & Company dans ses recherches de 2026 : les produits qui survivent sont ceux qui « capturent les décisions et les résultats de chaque exécution pour construire un fossé durable de données d'exécution qui se compose avec le temps ». L'idée n'est pas nouvelle en théorie, mais peu d'entreprises l'ont construite consciemment. La plupart ont supposé que la valeur résidait dans l'interface ou dans la fonction, et c'est précisément ce que les agents d'IA attaquent en premier.
La profondeur d'intégration dans les flux de travail opérationnels définit le coût de sortie. Il existe une différence structurelle entre un logiciel qui accomplit une tâche et un logiciel qui est intégré dans la manière dont une organisation prend ses décisions. Le premier est en concurrence sur le prix et la commodité ; le second est en concurrence sur le risque d'interruption. Lorsqu'un outil est intégré dans le processus d'approbation de crédit, dans la chaîne de décisions d'achat, ou dans le système de suivi de la qualité de fabrication, le remplacer n'est pas une décision logicielle. C'est une décision de refonte opérationnelle qui implique plusieurs équipes, des audits et des mois de tests parallèles.
Les investisseurs en logiciels traitent déjà cette réalité. L'analyse de la Harvard Business Review publiée en mai 2026 soulignait un fossé croissant entre les outils basés sur des règles — plus vulnérables à la construction interne assistée par l'IA — et les plateformes dotées de données propriétaires et d'une forte intégration dans les flux de travail, qui affichent une plus grande résilience face à la pression concurrentielle.
La responsabilité humaine n'est pas un overhead ; c'est le dernier pare-feu. Lorsqu'un agent d'IA commet une erreur dans un processus critique, le client ne cherche pas un autre agent. Il cherche quelqu'un qui peut assumer la responsabilité du problème, connaître le contexte spécifique du compte et le résoudre. Cela requiert des personnes qui savent non seulement utiliser l'outil, mais qui comprennent suffisamment l'activité du client pour distinguer une erreur triviale d'une erreur qui s'aggrave. Les équipes qui ont appris à utiliser l'IA pour automatiser 90 % du volume routinier peuvent consacrer leurs forces humaines aux 10 % restants, qui est précisément là où le client forme son opinion sur si le fournisseur mérite de rester ou non.
Comment distinguer un vrai fossé d'un fossé supposé
L'erreur la plus fréquente que j'observe dans les équipes produit n'est pas de ne pas avoir de données propriétaires. C'est de supposer qu'elles en ont alors qu'en réalité elles possèdent des données qui sont propriétaires dans leur forme mais génériques dans leur contenu.
Il existe un test pratique qui s'avère utile : prendre le cœur de la fonctionnalité du produit et demander à un développeur compétent disposant d'outils d'IA de le reproduire en une semaine. Ce qu'il réussit à reproduire ne constitue pas le fossé, quelle que soit la durée qu'il a fallu pour le construire à l'origine. Ce qu'il ne réussit pas à reproduire — que ce soit parce que cela dépend de données accumulées historiquement, d'intégrations avec des systèmes propriétaires tiers, d'une logique réglementaire spécifique à l'industrie ou de la connaissance tacite des utilisateurs — c'est ce qui définit le périmètre défendable.
Bain affirme que les entreprises qui veulent saisir ce qu'elle appelle le « prochain marché de 100 milliards de dollars » dans l'IA agentique doivent prendre des décisions explicites sur quelles données elles veulent posséder, quels flux de travail elles veulent instrumenter pour capturer ces données, et si elles doivent construire ces capacités, les acquérir ou s'associer pour les obtenir. La question n'est pas de savoir si le produit actuel utilise l'IA. La question est de savoir si le produit actuel devient plus précieux chaque fois qu'un client l'utilise, ou s'il se contente de traiter une transaction et de l'oublier.
Deloitte ajoute une autre dimension à l'analyse : les entreprises doivent également décider si elles vont miser sur un écosystème d'agents spécifique, construire une couche d'orchestration neutre ou adopter un modèle fédéré. Cette décision a des conséquences sur l'endroit où se situe le contrôle des données d'exécution et, par conséquent, sur qui accumule le fossé avec le temps.
Le logiciel sans histoire n'a pas de prix
Il y a quelque chose que les entreprises qui traversent bien ce cycle ont en commun, et ce n'est pas d'avoir adopté l'IA avant leurs concurrents. C'est d'avoir construit des produits où l'accumulation d'usage génère quelque chose qui n'existait pas avant cet usage.
Un système de gestion d'essais cliniques qui capture depuis cinq ans des versions de documents, des signatures croisées et des approbations réglementaires n'est pas précieux parce que son interface est meilleure que ChatGPT. Il est précieux parce qu'il contient une histoire qui ne peut pas être reconstruite de l'extérieur et qui possède une valeur juridique et réglementaire concrète. Un CRM qui a traité dix ans d'interactions avec des clients industriels de niche — avec tous les schémas de comportement, l'historique de négociation et les données d'après-vente intégrées — ne concurrence pas sur le prix un outil construit en une semaine. Il concurrence sur le coût de perdre cet historique.
Les modèles de langage sont probabilistes : ils génèrent des réponses plausibles basées sur des schémas statistiques. Les données propriétaires accumulées sont déterministes : elles contiennent l'enregistrement de ce qui s'est produit. Cette distinction n'est pas philosophique. Elle a des conséquences directes sur qui peut auditer un processus, qui peut démontrer la conformité devant un régulateur et qui peut reconstruire une décision prise il y a trois ans.
Le marché du logiciel n'est pas en train de s'effondrer. Il est en train de se différencier avec une précision qui n'était pas possible auparavant, parce que le coût de construction d'alternatives était suffisamment élevé pour maintenir en vie des produits qui n'avaient pas de fossé défensif. Ce coût n'existe plus de la même façon. Ce qui reste après cette différenciation, c'est ce qui a toujours mérité d'être construit : des systèmes qui en savent davantage chaque année qui passe, qui sont intégrés dans des décisions qui comptent et qui disposent d'un humain responsable lorsque quelque chose tourne mal. Le logiciel qui ne peut pas démontrer au moins l'une de ces trois caractéristiques fait face à une pression tarifaire qui ne va pas se relâcher.
