Transition : du Build or Buy vers le Rent + Build
Et si on ré-internalisait certains SaaS ?
La digitalisation des métiers s’est largement appuyée sur les logiciels SaaS. CRM, gestion de projet, support client, RH, finance, reporting, collaboration, e-commerce ou outils spécialisés : à mesure que les entreprises se digitalisaient, elles ont adopté des solutions capables de répondre rapidement à leurs besoins sans mobiliser une équipe de développement interne.
Le SaaS a joué un rôle majeur dans cette accélération. Construire soi-même prenait du temps, nécessitait des compétences difficiles à mobiliser et obligeait surtout à conserver la capacité de maintenir et de faire évoluer la solution. Louer un logiciel existant était souvent la décision la plus rationnelle.
Cette mécanique a aussi produit un empilement considérable. Certaines entreprises utilisent aujourd’hui plusieurs dizaines, parfois plusieurs centaines de solutions différentes, chacune avec son abonnement, ses données, ses intégrations et ses contraintes.
L’arrivée des agents de développement IA ne rend pas soudainement cet empilement obsolète. Elle modifie en revanche un élément important de l’équation : le coût d’accès à la fabrication du logiciel.
La barrière que constituait le temps de développement est en train de céder. Des travaux qui demandaient des semaines peuvent désormais être réalisés en quelques jours, parfois beaucoup moins, tout dépend de qui est aux commandes.
McKinsey décrit précisément cette évolution : les agents interviennent désormais sur la spécification, l’écriture du code, les tests et jusqu’au déploiement. Le cabinet observe également des équipes qui passent de six à dix personnes à deux ou trois lorsque ce mode de production est réellement intégré au cycle de développement. Dans le même temps, McKinsey insiste sur ce qui devient alors le nouveau goulot d’étranglement : définir ce qu’il faut construire, contrôler le résultat et prendre les bonnes décisions d’architecture.
C’est aussi ce qui différencie cette vague des promesses précédentes du low-code, du no-code ou de l’offshore. Ces approches avaient déjà réduit certains coûts de fabrication. Les agents peuvent aujourd’hui intervenir sur une part beaucoup plus large du cycle : explorer une base de code existante, développer, modifier, tester, documenter, refactorer ou corriger. La rupture ne tient donc pas uniquement à une manière plus rapide d’écrire une interface.
Cela ne signifie pourtant pas que le logiciel devient bon marché à posséder.
Louer pour apprendre
Le point intéressant se situe peut-être ailleurs que dans la seule baisse du coût de développement.
Une entreprise peut commencer par louer un SaaS parce qu’elle a besoin d’une solution immédiatement. Elle l’utilise pendant un an, deux ans ou davantage. Pendant cette période, quelque chose de précieux se produit : elle apprend.
Elle découvre les fonctionnalités réellement utilisées, celles qui ne le sont jamais, les contournements créés par les équipes, les limites de l’outil, les intégrations indispensables et les besoins spécifiques qui n’étaient pas visibles au moment de l’achat.
Le SaaS devient alors une sorte de spécification vivante.
Au lieu de construire à partir d’un cahier des charges qui tente d’anticiper les usages, on dispose de mois ou d’années d’expérience réelle. Cela réduit une autre source majeure de risque dans un projet logiciel : construire la mauvaise chose.
C’est à ce moment que le vieux débat Build or Buy devient plus intéressant. L’achat ou la location initiale n’interdit plus de reposer la question quelques années plus tard.
Une logique de Rent + Build devient possible : louer pour répondre immédiatement au besoin et apprendre, puis construire lorsque l’expérience acquise et l’économie du projet le justifient.
La conclusion peut très bien être de continuer à louer. Le Rent + Build n’est pas une doctrine d’internalisation systématique ; il ajoute simplement une dimension temporelle à une décision qui était souvent pensée comme définitive.
Retool observe déjà ce comportement dans sa propre population : dans une enquête menée auprès de 817 de ses clients et utilisateurs, 35 % déclarent avoir remplacé au moins une fonction SaaS par un développement spécifique et 78 % prévoient de construire davantage d’outils internes. Ces chiffres doivent être pris pour ce qu’ils sont : Retool commercialise précisément une plateforme permettant de construire des applications internes, et l’échantillon est donc particulièrement favorable au build. Ils constituent un signal d’usage, pas une mesure neutre de l’ensemble du marché.
Le coût de fabrication ne suffit pas
Le principal piège serait de comparer directement un abonnement annuel avec le prix initial d’un développement.
Un SaaS à 30 000 € par an ne vend pas seulement les écrans que ses utilisateurs voient. L’abonnement finance également l’infrastructure, la maintenance, les correctifs de sécurité, les évolutions réglementaires et techniques, le support, la supervision et une organisation chargée de faire vivre le produit.
Reconstruire une fonction revient à récupérer une partie de ces responsabilités.
L’équation pertinente oppose donc le coût total de la location au coût total de possession de la solution interne : conception, développement, hébergement, maintenance, sécurité, documentation, surveillance, évolutions et disponibilité des personnes capables d’intervenir plusieurs années plus tard.
L’IA peut réduire fortement le coût de développement initial et celui de certaines évolutions. Rien ne permet d’affirmer que le coût total de possession baissera dans les mêmes proportions.
Reuters apporte ici un contrepoint utile à la thèse de la réinternalisation. Dans une analyse publiée en août 2026, Karen Kwok souligne que la sécurité des données, l’auditabilité, la montée en charge et l’inertie organisationnelle continuent de donner un avantage important aux éditeurs établis. Le possible rachat de Workday par Silver Lake y est même présenté comme un signe que les inquiétudes sur une disparition rapide du SaaS peuvent être excessives.
Ce contre-argument ne contredit pas vraiment le Rent + Build. Il en fixe plutôt les limites.
Que faut-il réellement internaliser ?
Tout ne présente évidemment pas le même intérêt.
Les fonctions très standardisées, réglementées, critiques ou nécessitant une évolution permanente bénéficient souvent fortement de la mutualisation offerte par un éditeur. Paiement, comptabilité, certaines briques de sécurité ou infrastructures complexes sont des candidats assez évidents au maintien à l’extérieur.
Le calcul devient différent pour un workflow très spécifique, un back-office, une interface métier, un système de validation, un outil de reporting interne ou un petit CRM construit autour d’un processus particulier.
Dans mes propres domaines, la question commence également à pouvoir être posée pour certaines fonctions de tag management, de consent management ou d’analytics. Il ne s’agit évidemment pas de réécrire intégralement des plateformes matures, mais de regarder si toutes les briques louées restent économiquement justifiées lorsque l’usage réel est beaucoup plus ciblé.
Plusieurs critères permettent alors de raisonner : stabilité du besoin, coût cumulé de l’abonnement, importance des personnalisations, volume d’intégrations, maîtrise des données, facilité de migration, criticité du service et coût prévisible de la maintenance.
Le facteur temps devient central. Un SaaS très pertinent pendant les deux premières années peut devenir beaucoup moins intéressant après cinq ou dix ans, notamment si le besoin est désormais parfaitement connu et relativement stable.
La question n’est donc pas seulement de savoir combien coûte la reconstruction. Il faut savoir combien de temps il est pertinent de continuer à louer avant de refaire le calcul.
Il existe aussi un troisième chemin
L’évolution agentique introduit une autre possibilité : ne pas reconstruire le logiciel.
Gartner estime que jusqu’à 234 milliards de dollars de dépenses en logiciels d’entreprise, soit environ 20 % des dépenses SaaS applicatives à l’horizon 2030, pourraient être exposés à ce qu’il appelle l’« agentic arbitrage ». Le chiffre est intéressant justement parce qu’il ne décrit pas une disparition du SaaS : environ 80 % des dépenses ne sont pas concernées par cette estimation. Gartner parle d’ailleurs davantage de métamorphose que d’apocalypse.
Le mécanisme décrit est différent du Build.
Un agent peut travailler à travers plusieurs logiciels existants, utiliser leurs API, récupérer les informations nécessaires et accomplir un processus sans obliger l’utilisateur à naviguer successivement dans plusieurs interfaces. La valeur de certains SaaS pourrait alors se déplacer de leur interface vers leur rôle de système de données ou de système d’enregistrement.
Il y a donc au moins trois décisions possibles.
Louer le logiciel et continuer à l’utiliser tel quel. Construire certaines fonctions en interne. Ou conserver les systèmes existants tout en plaçant une couche agentique au-dessus pour orchestrer le travail.
Cette troisième option change encore l’arbitrage. Il n’est parfois pas nécessaire de remplacer une application pour réduire sa place dans le processus.
Le lock-in change de forme
Réinternaliser est souvent présenté comme une manière de reprendre son indépendance vis-à-vis d’un éditeur. Ce n’est vrai qu’en partie.
Une solution interne peut devenir dépendante de quelques personnes qui connaissent son architecture, d’une technologie difficile à remplacer ou d’une base de code produite rapidement et insuffisamment documentée. Un produit interne que plus personne ne souhaite maintenir trois ans après son lancement peut être un verrou beaucoup plus gênant qu’un SaaS bénéficiant d’un contrat de support.
Les agents ajoutent encore une dimension à cette question.
Gartner estime que la valeur future des logiciels agentiques reposera notamment sur leur capacité à conserver le contexte et la connaissance propres au client. Les éditeurs sont ainsi encouragés à capturer non seulement les données, mais aussi la connaissance spécifique accumulée au fil des usages.
Le prochain lock-in pourrait donc porter autant sur ce que le système a appris de l’entreprise que sur les données stockées dans ses bases.
La question de propriété devient alors plus large : à qui appartiennent les données, le code, les règles métier, les workflows, mais aussi le contexte et la mémoire accumulés par les systèmes qui les exécutent ?
Internaliser ne supprime pas cette dépendance. Il faut choisir celle que l’entreprise préfère assumer.
Le coût se déplace
Il reste enfin une contradiction apparente à résoudre.
Si quelques personnes expérimentées utilisant des agents peuvent désormais produire ce qui nécessitait autrefois une équipe beaucoup plus importante, les profils capables de piloter correctement cette production sont précisément des profils rares et chers.
Ce n’est pas réellement une contradiction. Le coût ne disparaît pas ; il se déplace.
Une part moindre de l’effort est consacrée à écrire manuellement le code. Une part plus importante se concentre sur la compréhension du problème, l’architecture, la décomposition du travail, les tests, le contrôle et les décisions.
McKinsey observe justement cette évolution vers des rôles plus proches de celui d’un tech lead : savoir définir la solution, découper le problème pour les agents et assumer la responsabilité de ce qu’ils produisent devient plus important à mesure que l’écriture elle-même s’automatise.
Produire rapidement une application fonctionnelle est déjà beaucoup plus facile. Produire un système fiable, sécurisé, maintenable et capable de vivre pendant dix ans reste un exercice technique.
Une démonstration convaincante ne dit rien de la qualité réelle du système qui se trouve derrière.
C’est peut-être finalement là que se situe la vraie rupture économique : non pas dans la disparition des développeurs ou du coût logiciel, mais dans la quantité de logiciel qu’un petit nombre de personnes expérimentées peut désormais concevoir, produire et maintenir.
La transition
Le SaaS a permis pendant vingt ans d’accélérer la digitalisation des métiers sans demander à chaque entreprise de devenir elle-même un éditeur de logiciels. Il n’y a aucune raison que cet avantage disparaisse.
Ce qui change, c’est la frontière.
Des développements qui étaient auparavant trop coûteux pour être sérieusement envisagés peuvent maintenant entrer dans le calcul. Une entreprise peut louer pour aller vite, apprendre de plusieurs années d’usage, conserver les briques pour lesquelles l’éditeur possède un avantage évident, reconstruire celles qui sont devenues suffisamment spécifiques et, dans certains cas, laisser simplement des agents orchestrer les systèmes existants.
Le choix devient moins définitif et beaucoup plus évolutif.
Le Build or Buy reste valable, mais le temps, l’apprentissage et désormais l’orchestration entrent dans l’équation Rent + Build.
Pour aller plus loin
Chiffres clés et sources
Marché SaaS
Dépenses mondiales en applications SaaS (Cloud Application Services) : environ 299,1 Md$ en 2025, prévision Gartner. https://quashbugs.com/blog/saas-statistics
Marché SaaS mondial : environ 408,21 Md$ en 2025, environ 465,03 Md$ en 2026, environ 1 367,68 Md$ en 2035, croissance annuelle moyenne de 12,85 % sur 2026-2035. Source Precedence Research. https://quashbugs.com/blog/saas-statistics
Dépenses public cloud mondiales : 723,4 Md$ en 2025 contre 595,7 Md$ en 2024, croissance de 21,5 %. Source primaire Gartner. https://www.gartner.com/en/newsroom/press-releases/2024-11-19-gartner-forecasts-worldwide-public-cloud-end-user-spending-to-total-723-billion-dollars-in-2025
Le SaaS représente plus de 40 % des dépenses public cloud. https://www.quantumrun.com/consulting/saas-industry-growth-statistics/
Dépenses IT mondiales : 6,15 T$ en 2026 (+10,8 %), prévision Gartner du 3 février 2026. Révisée à la hausse par Gartner le 22 avril 2026 : 6,31 T$ (+13,5 % sur 2025), tirée par les infrastructures IA (data centers +55,8 %) et le logiciel. Utiliser le chiffre d’avril si l’article sort maintenant, ou dater explicitement celui de février. https://www.gartner.com/en/newsroom/press-releases/2026-02-03-gartner-forecasts-worldwide-it-spending-to-grow-10-point-8-percent-in-2026-totaling-6-point-15-trillion-dollars (prévision février, 6,15 T$) https://www.gartner.com/en/newsroom/press-releases/2026-04-22-gartner-forecasts-worldwide-it-spending-to-grow-13-point-5-percent-in-2026-totaling-6-point-31-trillion-dollars
Empilement des outils
Environ 275 applications SaaS par entreprise (Zylo, base de plus de 40 millions de licences), environ 342 selon Productiv, environ 106 selon BetterCloud. https://www.breeze.pm/articles/saas-tool-sprawl-statistics
Environ 152 applications dans les petites structures contre environ 660 dans les groupes de plus de 10 000 salariés. Zylo 2025. https://tools8020.com/blog/saas-sprawl-2026/
Environ 7 nouvelles applications entrent chaque mois, soit environ 33 % de croissance annuelle du portefeuille si rien n’est géré. 84 % des applications et 74 % de la dépense échappent à la DSI. https://zylo.com/blog/saas-stats-it-strategy
Les métiers pilotent environ 70 % de la dépense SaaS, la DSI environ 26,1 %. Redondances typiques : 15 outils de formation en ligne, 11 outils de gestion de projet, 10 outils collaboratifs. https://tools8020.com/blog/saas-sprawl-2026/
Gaspillage et coût
Attention : les deux chiffres Zylo ci-dessous viennent de deux éditions différentes de l’index, avec des définitions d’« inutilisé » différentes. Ne pas les présenter comme contradictoires, bien étiqueter l’édition à chaque fois.
Édition 2025 (données 2024) : 52,7 % des licences achetées ne sont pas utilisées, gaspillage moyen d’environ 21 M$ par an et par organisation. Productiv (donnée distincte) : environ 40 % de licences inutilisées sur près de 100 millions analysées. Vertice (donnée distincte) : sous-utilisation moyenne de 33 %, environ 1 M$ par an pour une organisation d’environ 600 salariés. https://www.mi-3.com.au/17-01-2025/licence-spill-multimillion-dollars-saas-wasteland-cmos-can-not-afford-ignore (relais des trois études)
Édition 2026 : l’utilisation des licences est passée de 47 % en 2024 à 54 %, ce qui a réduit le gaspillage de 20,9 M$ à 19,8 M$ (baisse de 5,3 %). Le taux d’« inutilisé » de cette édition (46 %) diffère donc du 52,7 % de l’édition 2025 par construction, pas par contradiction. https://zylo.com/blog/saas-statistics
Dépense SaaS de 4 830 $ par salarié, en hausse de 21,9 % sur un an. https://zylo.com/news/2025-saas-management-index
Précaution : Zylo, Productiv et Vertice commercialisent des plateformes de gestion et d’optimisation SaaS. Leurs chiffres constituent un signal fort sur le gaspillage, pas une mesure neutre.
Coût total de possession
Maintenance = 50 à 80 % du coût total de possession. https://idealink.tech/blog/software-development-maintenance-true-cost-equation
IEEE Computer Society : 60 à 80 % du coût de cycle de vie. Gartner : 55 à 80 % des budgets IT consacrés à maintenir l’existant. https://pegotec.net/software-maintenance-cost-percentage-2026-industry-benchmarks/
Estimations académiques : 67 % (Schach, 1999), 75 % (Galorath, 2022), plus de 80 % (Pigoski, 2001), plus de 90 % (Erlikh, 2015). Règle des 60/60 d’O’Reilly : environ 60 % des dépenses de cycle de vie vont à la maintenance. ScienceSoft : 70 à 90 % du TCO pour un logiciel d’entreprise on-premise complexe, 30 à 60 % pour une application cloud. https://www.codestringers.com/articles/software-maintenance-costs-explained
Sur la durée de vie complète, la maintenance représente deux à quatre fois l’investissement de développement initial (exemple : 150 000 $ de build, 300 000 à 600 000 $ de maintenance sur huit ans). https://adevs.com/blog/software-maintenance-costs/
Coût de fabrication et IA
55,8 % de réduction du temps de complétion d’une tâche, expérience contrôlée GitHub/Microsoft/Accenture (p=0,0017, IC 95 % [21 %, 89 %]). Étude primaire arXiv. https://arxiv.org/pdf/2302.06590
53,2 % de probabilité en plus de passer les 10 tests unitaires d’un exercice de code, étude contrôlée distincte de GitHub (202 développeurs, novembre 2024). Amélioration également mesurée sur lisibilité (+3,62 %), fiabilité (+2,94 %), maintenabilité (+2,47 %), concision (+4,16 %), et taux d’approbation (+5 %). Le “78 % de chances en plus de réussir” qui circule dans certains relais ne figure dans aucune des deux études primaires et semble être une confusion ; à ne pas réutiliser sans le retrouver dans une source vérifiable. https://github.blog/news-insights/research/does-github-copilot-improve-code-quality-heres-what-the-data-says/
Environ 41 % du code écrit était généré par IA en 2025 (et non 2026, contrairement à un relais qui datait mal ce chiffre). https://www.index.dev/blog/developer-productivity-statistics-with-ai-tools
Sentiment positif envers l’IA retombé à 60 % en 2025 (contre plus de 70 % en 2023 et 2024) ; 46 % des développeurs distants activement de la précision des outils IA contre 33 % qui leur font confiance, seulement 3 % “font pleinement confiance”. Enquête menée du 29 mai au 23 juin 2025, 49 009 réponses dans 166 pays. Source primaire Stack Overflow, 2025 Developer Survey. https://survey.stackoverflow.co/2025/ai https://stackoverflow.co/company/press/archive/stack-overflow-2025-developer-survey/
Contrepoint Uplevel (environ 800 développeurs, télémétrie d’ingénierie réelle) : aucun gain de productivité mesuré (cycle time et débit de PR inchangés avec l’accès à Copilot), mais hausse de 41 % du taux de bugs dans les pull requests des utilisateurs de Copilot. Ne pas présenter comme “aucune évolution” sur les bugs : c’est l’inverse, une dégradation significative. https://paddo.dev/blog/ai-developer-productivity-myth/