La fin de la rente SaaS : pourquoi le Build devient votre levier Comex
La réunion Comex qui a changé la donne
Décembre 2025. Un Comité Exécutif comme un autre, à cette nuance près : le Directeur Financier a préparé son support. Une diapositive unique, sans fioriture. Sur l'axe horizontal, les quatre dernières années. Sur l'axe vertical, la ligne budgétaire « licences SaaS » de l'entreprise. Une pente continue, régulière, têtue. Et au bas du graphique, deux chiffres mis en regard : le coût moyen d'un développeur interne en 2022 et le coût estimé d'un développeur assisté par IA en 2026. L'écart est vertigineux.
« Nous payons nos éditeurs au prix de 2022. Mais en 2026, le logiciel ne coûte plus rien à produire. Je n'arrive plus à justifier cette ligne au conseil d'administration. »
La phrase tombe, sans drame. Elle n'accuse personne. Elle constate. Et elle place le Directeur des Opérations Technologiques — que l'on appelait il y a peu le DSI — devant une question qu'il ne peut plus différer : continuons-nous à financer la dette technique de nos fournisseurs, ou commençons-nous à construire nos propres actifs ?
Ce qui suit n'est pas une tribune pour ressortir les vieux débats « Buy vs Build ». C'est une lecture économique, à hauteur de Comex, d'un basculement structurel du marché du logiciel. Le Build n'est pas un projet technique. C'est un levier de négociation, un outil de protection des marges, et désormais une condition de compétitivité.
La fin de la rente SaaS : trois basculements économiques
L'argumentaire qui permet de vendre en interne la reprise de contrôle technologique ne passe pas par l'architecture. Il passe par trois basculements économiques concomitants, visibles dans les comptes de résultat des éditeurs autant que dans les nôtres.
Premier basculement : l'obésité logicielle est financée par nos factures
Nous finançons aujourd'hui des suites logicielles obèses dont nous n'utilisons, en moyenne, que 20 % des fonctionnalités. Le constat est documenté depuis longtemps — l'étude historique de Pendo sur l'usage réel des logiciels d'entreprise avait déjà montré que les deux tiers des features livrées par les éditeurs ne sont jamais utilisées ou très rarement. Ce chiffre, loin de diminuer avec le temps, s'aggrave : à chaque release, l'éditeur ajoute des couches fonctionnelles pour justifier la prime de licence. Rares sont celles qui servent nos objectifs métier.
Concrètement, nous payons une prime de complexité pour une complexité qui ne travaille plus pour nous. Le coût de possession réel — licences, formation, intégration, maintenance — continue d'augmenter linéairement, pendant que la part utile de la suite stagne ou régresse. C'est, en comptabilité d'entreprise, la définition d'un zombie technologique : un actif qui consomme des ressources sans produire de valeur marginale différenciante.
Deuxième basculement : la déflation technologique a divisé le coût de production par dix
La thèse de la stratégie AI for IT défendue par SFEIR depuis dix-huit mois est désormais une réalité comptable. Le coût de production du logiciel a chuté d'un facteur dix — non pas par amélioration incrémentale des IDE, mais par l'émergence de harnais agentiques (Claude Code, Codex, Gemini CLI) qui transforment la nature même de l'ingénierie logicielle. Un ingénieur équipé en 2026 produit en une journée ce qu'il produisait en deux semaines en 2022. À périmètre constant.
Or les prix des éditeurs, eux, restent indexés sur des modèles de coûts hérités du passé. Ils tarifient la valeur d'un logiciel écrit avec les méthodes de 2022 — des équipes de dizaines d'ingénieurs, des cycles de release annuels, des coûts fixes massifs. Nous payons le prix fort pour une valeur qui se banalise. C'est l'écart, la zone hachurée du graphique ci-dessus, que toute direction financière finira par voir : l'indicateur économique le plus clair d'un marché en phase de correction.
Troisième basculement : le Per-Seat bascule vers le Forfait, et ce n'est pas un cadeau
Face à la déflation, les éditeurs ont commencé à changer de modèle de tarification. On ne paye plus strictement par utilisateur (Per-Seat) mais de plus en plus par forfait global : licence illimitée, plateforme entière, « unlimited users ». Microsoft 365 Copilot Enterprise a ouvert la voie, Salesforce Agentforce l'a suivie, ServiceNow et Workday s'y préparent. La bascule est présentée comme une simplification commerciale. Elle ne l'est pas.
Le Per-Seat avait une propriété défavorable pour les éditeurs à l'ère de l'IA : si vos agents remplacent progressivement vos utilisateurs humains, votre facture devrait mécaniquement baisser. Le Forfait neutralise ce mouvement. Il sanctuarise les revenus de l'éditeur indépendamment de votre productivité réelle. C'est, mot à mot, une stratégie de défense de leur rente, pas une proposition de valeur pour vous. Signer un forfait global en 2026 sans renégociation triennale, c'est accepter de payer demain le prix d'une productivité humaine qui aura disparu.
Le Build comme levier : reprendre le pouvoir de négociation
Poser le problème ainsi — en termes de rente, de prime de complexité, de défense de marge — change immédiatement le registre de la décision. Le Build cesse d'être une option technique discutée entre l'architecte et le responsable infrastructure. Il devient un instrument Comex, au même titre que la couverture de change ou la diversification fournisseur. Sa fonction première n'est pas de produire du code : c'est de restaurer un rapport de force.
| Dimension | Client captif | Client Build-capable |
|---|---|---|
| Pouvoir de négociation | Faible — pas d'alternative crédible | Fort — peut débrancher à échéance |
| Réponse aux hausses tarifaires | Subie — paie ou migre dans l'urgence | Choisie — négocie ou bascule à froid |
| Architecture | Boîte noire propriétaire | API-first, briques interopérables |
| Nature de la dépense | OpEx perpétuel (licence indéfinie) | CapEx amortissable (actif propriétaire) |
| Différenciation concurrentielle | Mêmes outils que ses concurrents | Briques métier non copiables |
La fin de la dépendance subie
Le Build n'est pas une volonté de tout réinventer. C'est une option stratégique — au sens financier du terme, comme une option d'achat ou de vente. Posséder la capacité de construire nos propres briques critiques nous redonne le pouvoir de négociation : nous ne sommes plus des clients captifs, mais des clients capables de débrancher l'éditeur si ses conditions deviennent déraisonnables. Dans la plupart des cas, nous ne débrancherons pas. Mais le seul fait de pouvoir le faire change la conversation contractuelle. Un éditeur qui sait que vous pouvez partir en six mois ne négocie pas comme un éditeur qui sait que votre migration prendrait dix-huit mois et plusieurs millions d'euros.
La neutralisation du risque fournisseur
En développant nos propres outils sur des architectures ouvertes — API-first, protocoles standardisés, formats d'échange documentés — nous nous protégeons contre trois classes de risques que les solutions fermées portent structurellement : les changements de roadmap (un éditeur qui retire une fonctionnalité clé parce qu'elle ne correspond plus à sa stratégie produit), les hausses de prix arbitraires (une refonte tarifaire qui multiplie la facture par trois en deux ans, comme plusieurs cas documentés en 2024-2025), et les failles de sécurité que nous ne pouvons ni auditer ni corriger dans une boîte noire. Le Design to Exit n'est pas un luxe d'architecte : c'est une assurance contre le risque de contrepartie technologique.
L'agilité comme avantage compétitif
Le Build nous permet de ne coder que ce qui nous différencie. Les 80 % de fonctionnalités standards — authentification, gestion documentaire, CRM générique — restent achetées, parce que personne ne gagne à les reconstruire. Les 20 % différenciants — l'algorithme de scoring qui capture vingt ans d'expérience métier, le workflow d'arbitrage que personne d'autre n'a, la règle de tarification propre à notre marché — deviennent un actif propriétaire que nos concurrents ne peuvent pas copier. La Matrice Souveraineté Agentique sert précisément à cartographier cette distinction, brique par brique, et à piloter l'effort de construction sur les 20 % qui créent de la valeur durable.
L'API, nouvelle interface : la commoditisation forcée des éditeurs
Il y a une raison structurelle pour laquelle les éditeurs ne pourront pas défendre éternellement leur rente. Elle ne vient pas d'une réglementation ni d'un concurrent disruptif. Elle vient de l'obligation, que les éditeurs s'imposent à eux-mêmes, de rendre leurs solutions agent-ready.
Le dilemme de l'éditeur
Pour survivre dans un marché où les clients orchestrent des agents IA, un éditeur SaaS doit impérativement exposer ses capacités via API et via Model Context Protocol (MCP). C'est une course obligatoire : celui qui n'est pas consommable par un agent sera contourné. Microsoft, Salesforce, ServiceNow, SAP — tous ont annoncé ou livré en 2025-2026 une couche MCP. Mais ce faisant, ils transforment leur interface utilisateur, leur valeur historique, en une commodité interchangeable. L'UI — ce qui les différenciait visuellement et ergonomiquement — devient un skin remplaçable. Demain, trois éditeurs concurrents exposent les mêmes données via MCP : le client ne paie plus une expérience, il paie un flux de données. Et un flux de données, ça se compare au litre.
L'entreprise Agent-Ready
Ce basculement a une implication stratégique directe : notre valeur ne résidera plus dans l'utilisation d'un logiciel tiers, mais dans notre capacité à orchestrer des agents IA qui consomment des données via API. Nous devons cesser d'acheter des interfaces pour commencer à acheter des flux. L'écran d'administration que vos équipes consultent aujourd'hui sera obsolète dans trois ans — non parce qu'il aura cessé de fonctionner, mais parce que vos agents, eux, consulteront l'API directement. L'intelligence métier se déplace de l'écran vers l'orchestration. Et l'orchestration, contrairement à l'écran, peut rester propriétaire.
La Software Factory comme stratégie d'intégration
L'objectif est de créer une unité interne capable d'assembler ces briques. C'est la promesse d'une Stack AI-Ready et d'une Software Factory dimensionnée : nous achetons la commodité (le socle), nous construisons la valeur (l'intelligence métier). Dans ce schéma, le Build n'est pas une régression vers l'ère des développements sur mesure coûteux. C'est une stratégie d'intégration intelligente : utiliser l'IA pour assembler rapidement des briques standardisées, et concentrer l'effort humain sur les règles métier qui font notre singularité. Un ingénieur augmenté d'aujourd'hui peut produire en quelques semaines ce qui aurait demandé un semestre à une équipe entière en 2022. Cette productivité change l'équation économique du Build.
Le coût de l'inaction et la réallocation de capital
L'argument inverse existe et mérite d'être pris au sérieux : pourquoi se précipiter ? Pourquoi ne pas attendre que le marché se stabilise, que les éditeurs ajustent leurs prix, que les standards convergent ? La réponse tient en trois mouvements, tous à horizon court.
Le risque de l'actif devenu toxique
Si nous continuons à accumuler des licences basées sur des coûts de 2024, nous finançons la dette technique de nos fournisseurs — la R&D qu'ils n'ont pas réinvestie, les équipes qu'ils ne rationalisent pas, les marges qu'ils défendent contre le marché. Pendant ce temps, des concurrents IA-native arrivent sur notre marché avec des structures de coûts substantiellement inférieures : pas de legacy, pas de dette de licences, une Software Factory dimensionnée pour l'ère agentique. L'écart peut atteindre, selon les verticaux et les estimations récentes, jusqu'à 80 % sur certaines lignes de coûts opérationnels. Continuer à signer des contrats pluriannuels indexés sur 2024, c'est acheter un actif toxique au pire moment du cycle.
L'alignement sur la réalité de 2026
Notre priorité n'est pas d'attaquer nos éditeurs — c'est d'aligner notre structure de coûts sur la réalité technologique actuelle. Le message que nous devons porter en négociation contractuelle est sobre : soit nos éditeurs s'adaptent à cette déflation, soit nous basculons progressivement vers nos propres solutions sur les briques critiques. Ce n'est ni une menace ni un idéologie du faire soi-même. C'est une discipline d'acheteur : nous refusons de subventionner une structure de coûts obsolète. Les éditeurs qui comprennent ce message ajusteront leurs offres. Ceux qui ne le comprennent pas verront leurs parts de marché s'éroder.
La réallocation de capital : OpEx vers CapEx
Et c'est le point le plus positif de l'argumentaire — celui qui doit clore toute présentation Comex : ce n'est pas une dépense informatique supplémentaire, c'est une réallocation de capital. Nous transformons des charges d'exploitation (les licences SaaS, qui disparaissent chaque année avec le chèque) en actifs technologiques (le code propriétaire et les agents métier, qui s'amortissent sur plusieurs années et peuvent être revalorisés). La bascule OpEx vers CapEx a trois effets comptables immédiats : elle améliore l'EBITDA, elle crée un actif mobilisable au bilan, et elle renforce la barrière à l'entrée concurrentielle. Pour un directeur financier, c'est le même argument que celui qui a, dans les années 2010, justifié le passage du leasing informatique à l'achat lorsque les prix du matériel ont décroché : acheter au creux du cycle produit un effet durable de marge.
Le Build n'est pas une idéologie : trois réserves à tenir
Un article honnête sur le Build doit aborder ce que le Build n'est pas. Il n'est ni une solution universelle, ni une posture morale. Trois réserves doivent encadrer la stratégie, sous peine de reproduire à l'intérieur les zombies qu'on a voulu éviter à l'extérieur.
Première réserve : les coûts cachés de maintenance. Un actif technologique construit en interne n'est pas un actif figé. Il exige des mises à jour, des patchs de sécurité, une gouvernance documentaire, une continuité de compétences. Un Build mal budgété devient, en trois ans, sa propre dette. La discipline comptable est claire : chaque brique construite doit avoir son coût annuel de maintenance provisionné dès l'amortissement.
Deuxième réserve : le risque de ré-inventer ce qui est déjà commoditisé. Reconstruire un système d'authentification, un moteur de règles générique ou une couche de stockage parce qu'on a envie de « maîtriser de bout en bout » est une faute économique. Le Build n'a de sens que sur les briques où notre contexte métier rend l'achat inefficace — soit parce que les solutions du marché n'existent pas, soit parce qu'elles nous obligent à tordre nos processus pour entrer dans leur modèle. Partout ailleurs, on achète.
Troisième réserve : la maturité Software Factory est un prérequis. Sans une équipe d'ingénierie augmentée par l'IA, sans pipeline CI/CD robuste, sans architecture modulaire, le Build retombe dans les pathologies des grands projets des années 2000 : délais qui s'étirent, dépassements budgétaires, dette technique auto-infligée. La stratégie décrite dans cet article suppose qu'une Software Factory est en place ou en construction. Sans ce socle, mieux vaut différer le Build que le rater.
Le Build comme levier durable : ce que nous observons chez SFEIR
Dans nos missions d'accompagnement DSI en 2025-2026, nous observons un schéma récurrent chez les organisations qui ont franchi le pas. Elles n'ont pas annoncé de « projet Build » au Comex — elles ont présenté une renégociation annuelle des contrats SaaS critiques adossée à une capacité démontrée de substitution partielle. Le calendrier typique : six mois pour cartographier les dépendances via la Matrice Souveraineté Agentique, douze mois pour construire deux à trois briques de substitution sur les contrats les plus onéreux, et une phase de renégociation continue qui rapporte, en moyenne observée, entre 15 % et 30 % sur les lignes SaaS concernées — parfois sans même activer la substitution.
Ce qui nous frappe, c'est que le Build change moins le SI qu'il ne change la posture. Les équipes qui ont redécouvert le geste d'ingénierie — même sur une brique de taille modeste — ne contractualisent plus comme avant. Elles lisent mieux les SLA, elles posent des questions sur la portabilité des données, elles exigent des clauses de réversibilité. Le levier ne se mesure pas uniquement en code produit. Il se mesure en clauses contractuelles obtenues.
Revenons au Comex de décembre 2025. Le Directeur Financier avait raison : on ne peut plus justifier, en 2026, une ligne de licences SaaS indexée sur les coûts de 2022. La question n'est pas de savoir s'il faut bouger — c'est de savoir comment, à quel rythme, et sur quelles briques d'abord. Le Build n'est pas un retour en arrière. C'est la modernisation du rapport de force entre l'entreprise et ses fournisseurs technologiques, dans un marché où l'un des deux a massivement bénéficié de l'IA et n'a pas, jusqu'ici, partagé le gain.
Nous ne construisons pas pour le plaisir de construire, nous construisons pour ne plus être les otages d'un modèle économique qui s'effondre.