Prétendre que l’intelligence artificielle permettrait désormais aux entreprises de développer leurs propres outils logiciels en quelques semaines ou quelques mois, là où il fallait auparavant des budgets considérables, est simpliste. Une révolution présentée comme la promesse d’économies massives sur les abonnements SaaS. Mais derrière les démonstrations spectaculaires, quel est le véritable coût de cette supposée indépendance ? Quelles conséquences sur les relations commerciales ?
La tentation de s’affranchir des éditeurs
Nous sommes ici en plein dans mes concepts théoriques sur la transition sociétale du modèle du 20e siècle reposant sur le travail en raison de l’automatisation due à l’intelligence artificielle et l’intelligence distribuée, où l’IA agit en interface de collecte, de répartition et de contribution au travers des terminaux de la connaissance humaine. Chaque humain qui produit quelque chose vient alimenter l’IA, qui le fait interagir avec les connaissances d’autres, ce qui amplifie les possibilités, qui deviennent accessibles à d’autres. Et les conséquences macro-économiques sont évidemment considérables. Mais il faut savoir raison garder. La fin du modèle du tout emploi n’implique pas la fin des infrastructures et des compétences afférentes, juste que les moyens à allouer aux diverses fonctions sont moindres et techniquement plus élevés.
Et le phénomène prend de l’ampleur. Des entreprises commencent à remplacer certaines applications professionnelles par leurs propres logiciels, développés avec l’assistance de l’intelligence artificielle. CRM, gestion des stocks, facturation, automatisation, outils de ressources humaines ou applications internes : les possibilités semblent pratiquement illimitées.
Le 6 novembre 2026, La Tribune consacrait un article à ces entreprises capables de développer leurs logiciels en quelques mois pour échapper aux abonnements coûteux des grands éditeurs. Le même jour, Clubic présentait le mouvement OccupySaaS, regroupant des initiatives visant à reconstruire, avec l’IA, des alternatives open source à des plateformes professionnelles comme Salesforce ou Auth0.
Le mouvement est symboliquement puissant. Des développeurs, dont certains se présentent comme victimes des licenciements dans l’industrie technologique, entendent concurrencer les logiciels de leurs anciens employeurs grâce à la technologie qui a contribué à transformer leur métier. Les premières réalisations montrent une capacité impressionnante à produire du code. Ce qui ne signifie pas qu’elles constituent forcément des solutions suffisamment éprouvées pour une exploitation généralisée. Mais la tendance est là et la perspective est exaltante au regard des tarifs des plateformes ou applications professionnelles.
Dans un autre registre, Soft Atlas présente le cas de MerciYanis, une entreprise ayant développé son propre outil de gestion en quatre mois, pour environ trente journées de travail, puis reconstruit son site Internet en moins d’une semaine, pour un coût annoncé d’environ 1 000 euros. Une dizaine d’applications internes auraient ainsi été créées pour répondre à différents besoins opérationnels.
Ces expériences sont intéressantes. Elles témoignent d’une rupture réelle : le développement d’applications spécifiques, historiquement réservé aux organisations disposant de moyens importants, devient accessible à des structures beaucoup plus modestes. Mais les récits qui accompagnent cette transformation présentent un défaut récurrent : ils mettent méthodiquement et systématiquement en avant le coût et la rapidité de fabrication, puis suggèrent que les économies obtenues sur les licences en découlent presque naturellement.
Or, le coût de fabrication d’un logiciel et le coût d’exploitation d’un service informatique sont deux réalités profondément différentes. Démontrer qu’un logiciel peut être développé pour une fraction de son coût historique pour établir qu’il sera économiquement préférable à une solution SaaS sur cinq ou dix ans est clairement très insuffisant et trompeur.
Ce que l’on oublie en comparant un abonnement avec du code
Le modèle SaaS, Software as a Service, ne consiste pas simplement à louer un programme informatique. L’entreprise cliente achète un service dont la fourniture mobilise une infrastructure, des compétences et une organisation permanente. L’éditeur doit assurer l’hébergement, la disponibilité de la plateforme, la maintenance corrective, les mises à jour, l’évolution fonctionnelle, la sécurité, la supervision, les sauvegardes et les capacités de restauration. Il doit également gérer l’assistance technique, les changements réglementaires éventuels et la continuité du service.
Toutes ces prestations ne sont évidemment pas garanties au même niveau par chaque fournisseur, et certaines responsabilités, notamment celles qui concernent la protection des données, restent partagées avec le client. La CNIL rappelle d’ailleurs que la répartition des responsabilités dépend de l’architecture et des prestations contractuelles. Mais l’essentiel demeure : le tarif d’un SaaS finance une organisation qui ne se résume pas au développement initial du logiciel. Derrière la façade de la plateforme, il y a des infrastructures, des dépendances à d’autres services et des compétences.
Lorsqu’une entreprise décide de produire elle-même son application, elle ne s’affranchit pas de ces nécessités, elle les internalise, ou doit en confier l’exécution à d’autres prestataires. Il lui faut disposer de compétences capables de comprendre le code, de dépanner l’application lorsqu’elle ne fonctionne plus, de corriger les vulnérabilités, de suivre les évolutions des technologies employées, d’adapter le logiciel aux nouveaux besoins, de contrôler les accès, de sauvegarder les données et de restaurer le fonctionnement après incident. Lorsqu’un service informatique payant est défaillant, il doit agir rapidement, parce que ses clients se retournent contre lui. Si c’est la propre solution interne qui est en panne, l’entreprise ne peut s’en prendre qu’à elle-même.
Et ces compétences doivent être disponibles durablement, pas uniquement pendant les quelques semaines nécessaires à la création de la première version puis sa mise en route. Le recours à l’IA peut accélérer considérablement la programmation et certaines opérations de maintenance. Il n’élimine cependant ni la responsabilité technique ni la nécessité de vérifier les résultats. Elle peut générer une application fonctionnelle, proposer des correctifs et même fournir la documentation correspondante.
Mais quelqu’un doit toujours pouvoir déterminer si son architecture est pertinente, si les corrections introduisent de nouvelles anomalies, si les données sont protégées et si le système fonctionne conformément aux exigences de l’entreprise. La distinction est fondamentale : savoir produire du code n’équivaut pas à disposer d’une capacité permanente d’ingénierie informatique. Et cette capacité représente un coût, même lorsqu’elle n’est mobilisée que ponctuellement. Pour être mobilisée ponctuellement, encore faut-il qu’elle existe et soit disponible.
Le bus factor, ou la fragilité des logiciels qui reposent sur une personne
À cette dimension économique s’ajoute un risque organisationnel rarement mis en évidence dans les présentations commerciales : le bus factor. Cette expression désigne le nombre de personnes dont la disparition soudaine de l’équipe rendrait un projet difficile, voire impossible, à poursuivre. Un bus factor de 1 signifie qu’une seule personne détient une part critique de la connaissance nécessaire à sa continuité. Imaginez une entreprise qui engage un·e stagiaire qui lui réalise son application et s’en va à la fin du contrat. Puis l’application nécessite une correction, elle ne fonctionne plus suite à une mise à jour de l’hébergement en raison de risques sécuritaires déclarés, ou une de ses dépendances, une API, a connu une modification. Et personne dans l’entreprise n’a la moindre connaissance du logiciel, alors que l’entreprise a renoncé à sa relation commerciale avec la plateforme qui lui fournissait cette prestation avant la création de son propre logiciel.
Le problème concerne naturellement les logiciels développés de manière traditionnelle, on a pas attendu le vibe coding pour développer des solutions en interne. Mais il prend une dimension particulière lorsque les applications sont construites très rapidement par un collaborateur, un indépendant ou une petite équipe utilisant intensivement l’IA. Une entreprise peut ainsi disposer d’un outil, avec l’objectif qu’il soit parfaitement adapté à son activité sans réellement posséder les compétences nécessaires pour le maintenir ou le faire évoluer, au risque qu’au gré du développement de l’entreprise il devienne tout simplement obsolète.
Le développeur initial quitte l’organisation, change d’activité, devient indisponible, un simple accident de vélo en venant au travail qui le cloue au lit durant deux ans, ou, tout simplement, cesse de collaborer, pour une raison ou une autre, qui reprend le logiciel ? Qui connaît ses choix d’architecture, ses dépendances, ses particularités et les raisons pour lesquelles certaines fonctions ont été construites comme ceci ou comme cela ?
Le fait que le code soit disponible ne résout pas automatiquement le problème. Reconstituer la compréhension d’un système peut demander des investigations approfondies, surtout lorsque la documentation est lacunaire ou que les modifications ont été produites par des générations successives d’agents IA. Le développeur de remplacement peut alors devoir consacrer davantage de temps à comprendre et fiabiliser l’existant qu’il n’en aurait fallu pour développer certaines fonctionnalités à neuf. Sans compter qu’il devra être de compétence supérieure, parce que celui qui a développé le logiciel, l’a fait avec l’IA, il n’avait potentiellement que peu de compétences en codage. Son remplaçant, lui, doit comprendre ce qui a été réalisé.
On entre ici dans le domaine de la dette technique : les économies de temps réalisées lors du développement initial peuvent se transformer en charges futures. Le rapport DORA 2025 de Google rappelle d’ailleurs que l’IA agit surtout comme un amplificateur des forces et des faiblesses de l’organisation qui l’emploie. Une entreprise techniquement structurée peut en tirer d’importants bénéfices. Une organisation dépourvue de procédures solides ne résout pas ses fragilités en produisant du code plus rapidement.
L’IA peut donc démocratiser la fabrication de logiciels sans démocratiser dans les mêmes proportions la capacité de les administrer durablement. Pire, elle peut favoriser une prolifération d’applications internes créées avec enthousiasme, mais dont personne n’a organisé la maintenance, la documentation et la succession des responsables.
Une indépendance technologique relative
Un autre aspect mérite une attention particulière : les dépendances externes. Fabriquer son propre logiciel ne signifie pas nécessairement disposer d’un système autonome. Une application développée en interne peut continuer de s’appuyer sur des API tierces pour communiquer avec un CRM, transmettre des messages, gérer les paiements, authentifier les utilisateurs ou automatiser certaines opérations. Elle peut également dépendre de services externes de bases de données, de stockage, d’hébergement ou d’exécution de traitements.
L’exemple de MerciYanis est instructif à cet égard. Le témoignage publié par Soft Atlas mentionne explicitement la conservation de plusieurs outils SaaS, dont HubSpot et Axonaut. Certaines applications internes communiquent avec ces plateformes au moyen d’API et de webhooks. L’entreprise utilise également des outils externes pour le développement, la gestion du code et le déploiement, notamment Claude, GitHub et Vercel. Cela n’enlève rien à l’intérêt de sa démarche, qui ne prétend d’ailleurs pas remplacer intégralement son environnement logiciel. Mais cela montre que le développement interne peut conduire à une recomposition des dépendances plutôt qu’à leur disparition et relativise les économies imaginées généralement.
L’entreprise ne paie plus le même abonnement, mais elle l’a dispatché dans une infrastructure technique et contractuelle distribuée entre plusieurs fournisseurs, ce qui était réalisé par la plateforme à laquelle elle était abonnée. Les API peuvent évoluer, être facturées différemment, devenir incompatibles ou perdre certaines fonctions. L’hébergeur peut modifier ses tarifs ou ses conditions d’utilisation. Une interruption de service chez un prestataire peut perturber des applications internes qui en dépendent. Tout cela incombe désormais à l’entreprise elle-même, en interne.
Il faut également distinguer l’IA utilisée pour développer le logiciel de celle qui reste nécessaire à son fonctionnement. Une application produite avec un modèle de langage peut parfaitement fonctionner ensuite sans aucune IA. En revanche, lorsqu’elle utilise en permanence des modèles externes, leurs coûts d’inférence, leurs évolutions et leur disponibilité s’ajoutent aux charges d’exploitation. Dans tous les cas, l’indépendance doit être évaluée sur l’ensemble de l’architecture, non sur la simple propriété du code source.
Quant à l’infrastructure d’hébergement, elle ne se limite pas au prix mensuel d’un serveur. Elle comprend les ressources nécessaires, leur administration, les sauvegardes et leur vérification, la supervision, la sécurité, les performances et la capacité à rétablir le service après une défaillance. L’hébergement peut être un serveur au sein de l’entreprise, ou une location externe. Mais sans un serveur quelque part, suffisamment puissant pour que l’utilisation de l’application développée en interne soit utilisable par l’ensemble du personnel.
Il faut aussi considérer le coût d’une interruption d’activité. Une panne de quelques heures peut être insignifiante pour un petit outil documentaire, mais avoir de lourdes conséquences lorsqu’elle immobilise la gestion des commandes, la facturation ou une chaîne opérationnelle. Enfin, le développement de clones de logiciels propriétaires soulève parfois des questions de licences, de propriété intellectuelle et de compatibilité. Les démarches de réimplémentation doivent être distinguées de la reproduction de code protégé. L’utilisation de l’IA ne dispense pas de ces précautions.
La disparition d’une facture SaaS ne constitue donc pas la preuve de la disparition des coûts et des dépendances qui lui étaient associés. Le développement à l’interne transfère les coûts à l’interne et sur les dépendances, assumées par la plateforme Saas remplacée.
Le véritable calcul économique se fait sur plusieurs années
Pour déterminer si l’opération est rentable, il faut établir un coût total de possession, ou TCO (Total Cost of Ownership), sur une période suffisamment longue. Du côté du SaaS, on doit prendre en compte les abonnements, les frais d’intégration, les éventuels développements complémentaires, la formation des utilisateurs, les évolutions tarifaires et les coûts liés aux limites fonctionnelles du produit.
Du côté du logiciel développé en interne, il faut additionner le coût initial de conception, la programmation, les tests, la migration des données, l’hébergement, la maintenance, les mises à jour, la sécurité, l’assistance, la documentation, la formation et les dépenses de renouvellement technique. Il faut aussi intégrer le temps mobilisé par les collaborateurs pour administrer ces outils et résoudre les problèmes, ainsi que les risques de défaillance et les coûts de réversibilité.
Cette approche commence à apparaître dans certaines analyses. Le 7 juillet 2026, Le Monde Informatique publiait un article sur la réduction de la facture SaaS grâce à l’IA, distinguant explicitement le coût de construction du logiciel et celui de son exploitation. C’est la bonne méthode. Mais elle ne fournit pas, à elle seule, la démonstration que l’internalisation est généralement plus avantageuse. Parce que les résultats dépendent de paramètres très variables : la complexité fonctionnelle, le nombre d’utilisateurs, la criticité de l’application, les exigences de sécurité, les coûts de licence, les compétences déjà disponibles et la fréquence des évolutions nécessaires.
Une petite application autonome, destinée à quelques collaborateurs et remplissant des fonctions stables, peut parfaitement présenter un avantage économique. Il en va autrement d’un système de gestion complexe, fortement interconnecté et indispensable au fonctionnement quotidien de l’entreprise.
Les éditeurs SaaS bénéficient en outre d’un atout structurel considérable : la mutualisation. Les coûts de conception, de maintenance, de sécurité et d’infrastructure sont répartis entre un grand nombre de clients. Une correction de vulnérabilité ou une amélioration fonctionnelle peut profiter simultanément à des milliers d’entreprises.
Cette économie d’échelle ne disparaît pas avec l’intelligence artificielle. L’IA peut réduire les coûts de développement pour une entreprise particulière, mais elle réduit également ceux de l’éditeur qui fournit le service à des milliers de clients et qui lui aussi dispose de cette capacité. D’un côté le fait de perdre des clients augmente ses coûts opérationnels par client en réduisant la mutualisation, d’un autre il dispose des mêmes capacités technologiques d’évoluer pour répliquer. Rien ne garantit donc que le différentiel économique évoluera durablement en faveur de l’internalisation.
Au contraire, je serais tenté de parier que les économies promises seront souvent bien plus modestes qu’annoncé, voire inexistantes sur la durée, dès lors que tous les coûts seront correctement comptabilisés. Et si le SaaS baisse ses tarifs en prenant conscience de la nécessité de s’adapter, il faudra en plus considérer que le développement en interne est une perte sèche, puisque l’intérêt pourra être de retourner sur la plateforme SaaS. Cela ne signifie pas que le développement interne soit forcément une mauvaise décision, mais sa véritable justification doit probablement être recherchée ailleurs que dans la seule possibilité offerte de le faire.
La grande faiblesse du SaaS : contraindre les entreprises à s’adapter au logiciel
Depuis des années, les éditeurs de logiciels professionnels ont progressivement constitué des plateformes de plus en plus vastes, accumulant les fonctionnalités, les modules et les niveaux d’abonnement. Elles cherchent évidemment à répondre aux besoins des entreprises, mais avec une vision générique, qui rend volontiers les plateformes complexes et fastidieuses, voire rébarbatives, quand bien même l’entreprise n’en n’utilise qu’une infime fraction. Cette évolution répond en partie à la diversité des besoins des clients, mais également à une logique commerciale : multiplier les fonctions permet d’élargir les marchés, de différencier les offres et de justifier des tarifs professionnels parfois considérables.
Le résultat incident est paradoxal. Une entreprise utilise une petite fraction des fonctionnalités disponibles, mais doit composer avec une plateforme conçue pour répondre à une multitude de besoins qui ne sont pas les siens. Les paramètres prolifèrent et les procédures nécessitent davantage de formation qu’elles ne devraient. Pendant ce temps, certaines fonctions pourtant essentielles à l’activité particulière de l’entreprise demeurent absentes.
Il faut alors bricoler des solutions de contournement, connecter des services supplémentaires, détourner des fonctions existantes ou modifier ses propres processus pour s’adapter aux contraintes du logiciel. L’entreprise paie ainsi pour des fonctionnalités dont elle n’a pas besoin, tout en supportant le coût organisationnel de celles qui lui manquent.
C’est précisément ici que l’IA change la donne. Lorsqu’une entreprise devient capable de développer un logiciel spécifique à un coût initial raisonnable, elle peut envisager un outil dont chaque fonction répond à un besoin réel, dont l’ergonomie correspond à ses pratiques et dont les processus épousent son organisation. Elle n’a plus nécessairement à supporter l’accumulation de fonctionnalités imposées par les besoins d’autres entreprises, ni à attendre qu’un éditeur accepte d’ajouter une fonction jugée secondaire dans sa feuille de route.
Un logiciel comportant vingt fonctions pertinentes peut être beaucoup plus efficace qu’une plateforme en proposant deux cents, dont une grande majorité n’est jamais utilisée. Et cet avantage ne se mesure pas seulement en dépenses informatiques. Il se traduit par une réduction des manipulations, des erreurs, des formations inutiles et des adaptations organisationnelles. Il peut améliorer la productivité, la qualité du travail et les capacités d’initiative des collaborateurs.
Le bénéfice principal du logiciel sur mesure n’est donc pas nécessairement de coûter moins cher. Il est de mieux répondre à ce que l’entreprise attend de lui. C’est une différence fondamentale, parce qu’elle replace l’outil au service de l’activité, plutôt que d’imposer à l’activité de se conformer aux contraintes de l’outil.
Et si les éditeurs SaaS finissaient par comprendre le message ?
C’est ici qu’apparaît une perspective beaucoup plus intéressante que l’annonce d’une disparition prochaine du SaaS. Face à des clients désormais capables de développer leurs propres alternatives, que feront les éditeurs ? Ils ne vont évidemment pas rester immobiles. Eux aussi disposent de l’intelligence artificielle. Eux aussi peuvent réduire leurs coûts de programmation, automatiser des opérations de maintenance, accélérer les évolutions fonctionnelles et personnaliser leurs produits.
…Et, surtout, ils disposent déjà de l’infrastructure, des équipes, des connaissances métier, des procédures et de la clientèle nécessaires à la fourniture d’un service professionnel. Pourquoi ne proposeraient-ils pas, dès lors, des solutions beaucoup plus modulaires, configurables et adaptables ?
L’IA peut rendre économiquement envisageable ce qui était jusqu’ici difficile à industrialiser : des adaptations fonctionnelles et ergonomiques répondant aux particularités de chaque entreprise, sans devoir développer et maintenir une application entièrement distincte pour chaque client. On peut imaginer des plateformes dont l’interface serait configurée en fonction des usages réels, avec des modules activés à la demande, des fonctionnalités spécifiques générées ou adaptées rapidement et des processus métier beaucoup plus librement personnalisables.
Le logiciel conserverait ainsi son infrastructure mutualisée, sa maintenance centralisée, ses garanties contractuelles et ses mécanismes de sécurité, tout en offrant une expérience beaucoup plus proche du sur-mesure. Naturellement, cette personnalisation aurait ses limites. Un éditeur doit préserver la cohérence de sa plateforme, éviter la multiplication de variantes impossibles à maintenir et respecter les contraintes de sécurité et de compatibilité. Mais ces exigences ne sont pas incompatibles avec une architecture modulaire, des extensions encadrées, des API ouvertes et des outils de configuration assistés par IA.
Les modèles tarifaires pourraient alors évoluer. Plutôt que de vendre systématiquement des ensembles de fonctionnalités surdimensionnés, les éditeurs auraient intérêt à proposer des offres davantage proportionnées aux usages, aux services effectivement consommés et à la valeur apportée. La concurrence ne porterait plus seulement sur la richesse des catalogues de fonctionnalités, mais sur la capacité des fournisseurs à répondre précisément aux besoins de leurs clients.
Ce ne serait pas la disparition du SaaS. Ce serait une nouvelle génération de SaaS avec un nouveau modèle économique hybride, où la plateforme SaaS fournirait la base, l’infrastructure, le logiciel, les compétences, et l’entreprise cliente assumerait son besoin spécifique en collaboration avec la plateforme. Une transformation dans laquelle la mutualisation des infrastructures resterait économiquement pertinente, tandis que la personnalisation deviendrait beaucoup plus accessible.
Autrement dit, les éditeurs pourraient conserver leurs avantages industriels tout en corrigeant une part importante des rigidités qui poussent aujourd’hui certaines entreprises à développer leurs propres logiciels. Rien ne garantit que tous les fournisseurs sauront ou voudront évoluer dans cette direction. Certains resteront prisonniers de leurs architectures historiques, de leurs modèles de licences ou de leurs positions commerciales. D’autres pourraient perdre des clients au profit de nouveaux entrants plus agiles. Mais c’est précisément ainsi que fonctionne une transformation concurrentielle. Il y a ceux qui la sous-estiment et disparaissent, et ceux qui en profitent.
Une révolution du rapport de force qui ne compromettrait pas nécessairement le modèle économique
L’une des conséquences les plus importantes de l’IA pourrait finalement se produire sans qu’une majorité d’entreprises remplace effectivement ses logiciels SaaS. Jusqu’ici, les éditeurs bénéficiaient d’une forme de captivité de leurs clients. Changer de plateforme représentait un investissement important, avec les risques de migration, de perte de données, de réorganisation, de formation et d’incompatibilités. Développer un logiciel alternatif nécessitait des budgets et des compétences rarement disponibles.
L’éditeur pouvait donc imposer ses conditions, ses augmentations tarifaires, ses limites fonctionnelles et son calendrier d’évolution en sachant que le coût de sortie constituait un puissant facteur de fidélisation forcée. Une situation que l’IA commence à corriger. Elle facilite le développement d’alternatives, mais également la création de connecteurs, la transformation des données, la migration entre plateformes et l’adaptation de solutions concurrentes.
Même lorsqu’une entreprise n’a aucune intention de devenir durablement responsable de ses propres applications, elle peut désormais considérer plus crédible de changer de fournisseur. Et cette possibilité seule suffit parfois à modifier la négociation. L’article du Monde Informatique rapporte ainsi le cas d’un éditeur ayant renoncé à une augmentation tarifaire de 15 % après qu’un client a présenté un prototype crédible de solution alternative construite avec l’IA. Il s’agit d’un cas rapporté, non d’une démonstration statistique, mais le mécanisme est particulièrement révélateur.
Le client n’a pas eu besoin de remplacer son SaaS. Il a simplement démontré qu’il pouvait envisager de s’en passer. La perspective d’une perte de clientèle a rendu l’éditeur plus conciliant. Le phénomène pourrait se généraliser à mesure que le développement d’alternatives devient plus accessible. Les entreprises disposeraient alors d’une capacité de négociation qui leur faisait largement défaut. On assisterait à une redistribution du pouvoir commercial, les clients étant moins contraints d’accepter des prestations imparfaites au motif qu’ils n’ont pas d’autre choix.
Cette évolution pourrait également favoriser les éditeurs qui sauront développer une relation plus coopérative avec leurs clients, en adaptant leurs services plutôt qu’en cherchant à maximiser la dépendance. La transformation serait alors plus profonde qu’une simple réduction des budgets informatiques : elle toucherait à la structure même des relations entre fournisseurs et utilisateurs professionnels.
Le SaaS n’est par conséquent pas condamné, il est contraint d’évoluer
Cette perspective n’est d’ailleurs pas entièrement absente des analyses sectorielles. Dans une publication de juillet 2026, Gartner évoquait une transformation du marché SaaS plutôt que sa disparition. Une autre analyse publiée le 30 octobre soulignait que les systèmes de gestion fondamentaux des entreprises conserveraient vraisemblablement leur place, les nouvelles applications et les agents IA continuant d’avoir besoin de leurs données, de leurs règles métier et de leurs infrastructures.
Ce qui est cohérent avec la réalité économique. La mutualisation des moyens, la spécialisation des compétences et la fourniture de services professionnels constituent des avantages structurels qui ne disparaissent pas juste parce qu’un outil de production devient plus accessible. Ce serait même un étrange paradoxe que de voir des milliers d’entreprises consacrer individuellement des ressources humaines et techniques à maintenir des systèmes similaires, alors que les technologies permettent précisément de mutualiser ces efforts. A l’échelle, une telle perspective s’avérerait vite non rentable et inefficiente.
L’IA peut rendre la programmation beaucoup moins coûteuse, mais elle ne rend pas pour autant systématiquement rationnelle la duplication de toutes les organisations nécessaires à l’exploitation des logiciels. En revanche, elle rend beaucoup moins acceptable la rigidité des solutions proposées par les éditeurs. C’est là que se trouve, à mon sens, la véritable rupture.
Le modèle SaaS a longtemps permis aux entreprises d’accéder à des logiciels sophistiqués sans devoir financer leur développement et leur exploitation. C’était, et cela reste, un progrès économique considérable. Mais ce modèle s’est aussi accompagné d’une standardisation parfois excessive, de politiques commerciales rigides et d’une complexification fonctionnelle qui ont fini par éloigner certains logiciels de leur finalité première. L’intelligence artificielle remet aujourd’hui ces compromis en question. Elle ne condamne pas le principe du service logiciel mutualisé. Elle rend simplement plus difficile de justifier qu’un client doive adapter durablement son entreprise à un outil qui ne répond qu’imparfaitement à ses besoins.
Demain, certains logiciels internes auront disparu au profit de SaaS beaucoup plus adaptables. D’autres auront été remplacés par des solutions spécifiques, lorsque leurs avantages fonctionnels ou économiques le justifieront réellement. D’autres encore prendront la forme de modules développés sur mesure autour de plateformes mutualisées. Il n’y a aucune raison de penser qu’un seul modèle doive nécessairement l’emporter. La diversité des solutions pourrait au contraire devenir la conséquence naturelle de la réduction des barrières technologiques.
La fin du « ici, c’est comme ça »
On présente actuellement l’IA comme une technologie qui permettrait aux entreprises de se débarrasser de leurs abonnements logiciels en fabriquant elles-mêmes des équivalents moins coûteux. On a vu que cette perspective existe donc bel et bien, mais sa pertinence économique de long terme reste largement à démontrer. Les économies initiales sont faciles à mettre en avant ; les coûts cumulés de maintenance, de sécurité, d’évolution, d’hébergement et de continuité opérationnelle le sont beaucoup moins.
En revanche, la possibilité de créer rapidement un outil répondant exactement aux besoins d’une organisation constitue un changement majeur. Et les éditeurs SaaS auraient tort de ne pas en tirer les conséquences.
Je fais donc un pari : la généralisation du développement assisté par IA conduira moins à la disparition des plateformes SaaS qu’à leur transformation, sous la pression de clients redevenus capables de choisir.
Les éditeurs qui sauront faire preuve de modularité, de souplesse tarifaire et d’adaptabilité fonctionnelle conserveront probablement une grande partie de leur pertinence économique. Ceux qui continueront à imposer leurs logiciels, leurs pratiques et leurs tarifs sans considération suffisante pour les besoins des utilisateurs s’exposeront à une concurrence qu’ils ne pouvaient auparavant qu’assez facilement écarter, ce qui ne sera plus possible, sauf à avoir une vraie valeur ajoutée qui leur est spécifique.
La véritable révolution n’est peut-être pas que chaque entreprise puisse désormais fabriquer son propre logiciel, mais que les fournisseurs ne pourront plus aussi facilement répondre à une exigence : « Ici, c’est comme ça. »
