Suite à l’article IA en entreprise : ce que j’écrivais en 2023, ce que je pense en 2026
Dans l’article précédent, j’évoquais en passant un changement de fond : les modèles open source ont rendu accessible une capacité de traitement du langage qui n’existait sous forme produit que chez quelques grands éditeurs il y a encore deux ans. Ce changement a une conséquence qui mérite un article à part entière. Il repose sur la table un débat que la décennie SaaS croyait avoir enterré.
La décennie SaaS, le consensus qui s’est imposé et ce qu’il a coûté
Entre 2012 et 2022, la question « build or buy ? » avait trouvé une réponse confortable dans la plupart des DSI : buy SaaS, presque toujours. Les arguments étaient solides : time-to-market imbattable, maintenance déléguée, capex transformé en opex. Les projets « build » de la génération précédente avaient laissé des cicatrices : usines à gaz sous-documentées, développeurs devenus irremplaçables, migrations impossibles. Le SaaS a résolu ces problèmes réels.
Il en a créé d’autres, restés longtemps sous le radar. Dix ans de SaaS ont produit des processus métier qui se sont progressivement pliés aux contraintes de l’outil plutôt que l’inverse. On ne fait pas comme ça parce que c’est la meilleure façon de faire. On fait comme ça parce que l’ERP en place ne permet pas autre chose sans un projet de paramétrage à six chiffres. C’est du vendor lock-in, et il s’installe par accumulation de petites décisions raisonnables. L’organisation perd progressivement la capacité à modéliser ses propres processus. Elle délègue cette connaissance à l’éditeur, et quand l’éditeur change de politique tarifaire, elle se retrouve captive, sans même avoir vu venir le problème.
Le calcul financier qui a changé
L’argument financier reposait sur un prix de licence stable. Ce n’est plus le cas.
Selon le Vertice SaaS Inflation Index, l’inflation des prix SaaS atteint 11,4 % en 2025, soit cinq fois le taux d’inflation général des pays du G7. Le coût moyen par employé est passé de 7 900 à 9 100 dollars en deux ans ¹. Gartner constate que les budgets IT croissent de 2,8 % par an. L’écart est structurel : consolidation par des fonds de private equity dont le nombre de deals dans le logiciel a progressé de 28 % en 2024, hausses tarifaires sur base captive, fonctionnalités IA bundlées et facturées automatiquement qu’on les utilise ou non. VMware sous Broadcom illustre le cas extrême, avec des augmentations documentées dépassant 1 000 % sur certains périmètres. Mais Salesforce, Microsoft, ServiceNow et Atlassian ont tous suivi, à des degrés divers.
À cela s’ajoute ce que le prix affiché ne montre jamais : intégrations, paramétrages, formation, migration des données. Gartner estime que ces coûts cachés portent le TCO réel d’une solution SaaS à 150-200 % du prix de licence affiché.
Le tradeoff se recalcule donc sur trois variables :
- L’inflation de la rente. Un abonnement SaaS est une rente dont l’éditeur fixe le prix unilatéralement. Sur cinq ans à 10-12 % par an, la facture double presque, quand le coût de maintien d’un développement interne reste à 15-20 % du coût initial.
- Le coût du développement assisté par IA. Il a baissé structurellement, abaissant mécaniquement le seuil de rentabilité du build.
- Le coût d’opportunité de la dépendance. C’est le plus difficile à chiffrer, donc le plus souvent absent des business cases : combien coûte, sur cinq ans, l’impossibilité de faire évoluer un processus clé parce que l’outil ne le permet pas ?
Pourquoi 2026 est différent de 2016
Il y a dix ans, « build » voulait dire recruter des développeurs, choisir une stack, maintenir une équipe dans la durée. Un investissement lourd, une expertise rare. La plupart des organisations n’en avaient ni les moyens ni la culture.
Ce qui a changé, c’est le rapport entre l’intention métier et le code exécutable. Les outils de développement assisté par IA permettent aujourd’hui à un analyste ou un chef de projet capable de spécifier précisément son besoin de produire un prototype fonctionnel en jours plutôt qu’en mois. Les études le confirment : les développeurs complètent leurs tâches 55 % plus vite avec assistance IA, et 41 % du code produit dans le monde est aujourd’hui généré ou co-écrit par ces outils ². Le coût marginal du développement logiciel a chuté. Cette capacité n’est plus réservée aux organisations dotées d’une R&D logicielle interne.
L’angle mort des commentateurs
La plupart de ceux qui écrivent que « l’IA remplace les développeurs » n’ont jamais essayé de coder quoi que ce soit avec une IA. Pas même un site vitrine, qui est pourtant le cas d’usage le plus favorable : périmètre délimité, zéro contrainte d’intégration, données statiques, aucune règle métier. Même là, le résultat sans relecture compétente ressemble rarement à ce qu’on avait en tête.
Un backoffice robuste avec sa gestion des droits, ses règles de validation, ses dépendances entre objets métier, ses contraintes de performance sous charge, son historisation et sa reprise sur erreur, c’est une autre conversation. L’IA réduit la friction d’écriture du code. Elle ne remplace pas la capacité à concevoir un système qui tient dans le temps. Entre un prototype qui démontre un concept et une application en production à dix-huit mois, il reste une distance que l’enthousiasme des keynotes ne raccourcit pas.
Il y a un nom pour cette illusion : le vibecoding. Le terme, popularisé début 2025 par Andrej Karpathy, désigne une pratique qui consiste à décrire ce qu’on veut en langage naturel et à laisser l’IA générer le code sans nécessairement comprendre ce qu’elle produit. Le résultat peut être impressionnant sur une démo. Il peut aussi être un désastre silencieux en production : absence de validation des entrées, secrets hardcodés en clair, dépendances non maintenues, surface d’attaque béante. Le vibecoder enthousiaste qui déploie son application sur un serveur public sans audit de sécurité ne sait souvent pas ce qu’il expose, parce qu’il n’a jamais eu à le savoir pour arriver jusqu’ici.
Ce n’est pas une critique de la pratique en soi. C’est une description de ce qui arrive quand on dissocie la capacité à produire du code de la compréhension de ce que ce code fait dans un environnement réel. L’IA a rendu le premier accessible à presque tout le monde. Elle n’a pas rendu le second superflu.
Le rôle central de l’architecte
Dans un monde où le code devient bon marché, la valeur se déplace vers ce qui le précède : la capacité à concevoir un système cohérent avant d’en écrire la première ligne. Définir les frontières des composants, anticiper les points de friction à l’échelle, choisir les bonnes abstractions : c’est un travail que l’IA assiste très mal, parce qu’il exige une connaissance intime du contexte organisationnel et des dettes techniques héritées. Un LLM peut générer mille lignes de code fonctionnel sur une spec bien rédigée. Il ne peut pas décider si cette spec est la bonne.
Un système mal conçu dès le départ finit toujours par coûter plus cher que le SaaS qu’il était censé remplacer. L’IA ne change pas cette équation, elle l’accentue, parce qu’elle permet de construire mal beaucoup plus vite qu’avant. Ce qu’elle rend possible en revanche, c’est de libérer l’architecte des tâches d’implémentation répétitives pour le recentrer sur ce qu’il fait mieux que n’importe quel modèle : tenir la cohérence du système dans le temps et maintenir une vision d’ensemble. Dans les organisations qui réussiront leur virage « build », il y aura presque toujours un architecte, interne ou externe, qui aura posé les fondations avant que les outils IA n’entrent en jeu.
Ce que ça change concrètement pour les DSI
Le SaaS n’est pas mort. Sur les fonctions commoditisées, CRM généraliste, visioconférence, suite bureautique, le buy reste la réponse évidente. Gartner projette des dépenses mondiales SaaS à 299 milliards de dollars en 2025 ¹ : le marché ne s’effondre pas, il se segmente.
La question se pose sur les processus qui constituent un avantage compétitif réel, ou qui sont si spécifiques qu’aucun éditeur ne les couvre correctement. Sur ces périmètres, trois questions méritent d’être posées sérieusement avant de lancer un appel d’offres :
- Mon processus est-il réellement couvert par l’outil ? Ou vais-je passer deux ans à faire rentrer ma réalité dans ses cases, et modéliser mes processus selon les contraintes de l’éditeur plutôt que selon mes besoins ?
- Quel est le coût réel du lock-in sur cinq ans ? Licences, paramétrages spécifiques, friction lors des montées de version, et surtout coût d’opportunité des processus qu’on n’a pas pu faire évoluer parce que l’outil ne suivait pas.
- Ai-je dans mon écosystème la combinaison nécessaire : un architecte qui conçoit, et des outils IA qui implémentent ? Ce n’est plus « ai-je une équipe de développeurs ? », c’est une question plus fine, et souvent la réponse est plus proche de « oui » qu’on ne le croit.
La nouvelle compétence qu’on ne recrute pas encore
Le vrai sujet derrière build or buy n’est pas technique. Il est organisationnel.
La décennie SaaS a produit dans les DSI des équipes très compétentes pour intégrer, paramétrer et gouverner des produits tiers. Elle a moins investi dans la capacité à concevoir et à maintenir des systèmes propriétaires. Ce n’est pas un reproche, c’était la bonne réponse au contexte d’alors.
Le contexte a changé. La compétence qui manque maintenant n’est pas « savoir coder », les outils IA s’en chargent de mieux en mieux. Ce n’est pas non plus « recruter un architecte » au sens classique. C’est la capacité à articuler précisément un problème métier, à le décomposer en composants logiques, et à maintenir cette rigueur dans la durée : une compétence hybride, à la frontière du fonctionnel et du technique, que ni les équipes IT traditionnelles ni les équipes métier classiques ne possèdent naturellement.
Les organisations qui vont prendre de l’avance ne sont pas nécessairement celles qui recruteront le plus de développeurs. Ce sont celles qui sauront identifier les architectes capables de poser les fondations, leur adjoindre les bons outils, et laisser l’IA faire ce qu’elle fait bien : écrire du code sur une spec solide.
Ce que j’en retiens pour la pratique
En mission, la question build or buy ressurgit systématiquement en phase de cadrage. Ma conviction, forgée sur des cas concrets : le curseur n’est pas global, il est processus par processus. Pas pour conclure à « build » par principe, mais pour ne plus conclure à « buy » par défaut.
La décision reste complexe. Mais au moins, elle redevient une décision.
Le build or buy n’est qu’un symptôme parmi d’autres. L’IA est en train de redistribuer fondamentalement la façon dont chaque direction métier produit de la valeur, prend ses décisions, et justifie ses ressources. Direction financière, DRH, supply chain, commercial — chacune est traversée par ces questions, avec ses propres angles morts et ses propres résistances. Nous reviendrons sur ces impacts dans un prochain article : ce qui change vraiment dans les pratiques, ce qui résiste, et ce que les organisations qui avancent font différemment des autres.
Les commentaires sont ouverts si vous avez vécu ce dilemme, dans un sens ou dans l’autre.
Sources
¹ Vertice, SaaS Inflation Index 2026 / Zylo, 2025 SaaS Management Index / SaaStr, The Great SaaS Price Surge of 2025, octobre 2025 / Gartner via SaaStr : budgets IT en croissance de 2,8 % an vs inflation SaaS de 9-25 % — vertice.one / zylo.com / saastr.com
² GitHub / Accenture, études de productivité sur GitHub Copilot, 2023-2025 / Gartner, Forecast Analysis: Low-Code Development Technologies, Worldwide, 2026 — arxiv.org/abs/2302.06590 / gartner.com