Pendant vingt ans, la messe était dite :on achète en SaaS et on ne développe plus.
Le passage à l’an 2000 et à l’Euro, dont le coût d’adaptation avait été élevé, avait échaudé les grandes organisations et leurs grandes applications spécifiques. Le départ à la retraite des premiers développeurs Cobol a fini de l’achever. Les DSI sont devenues des centrales d’achats de progiciels et de SaaS. Et ce, pour le plus grand bénéfice d’une industrie du logiciel en croissance de plus de 10 % par an depuis plus de 30 ans.
Mais en 2026, l’IA vient reposer la question sur le plan économique . Car son développement joue sur deux facteurs clés de cette équation du « Make or Buy », créant pour GreenSI un effet ciseau assez unique :
Le coût de construire va s’effondrer avec l’automatisation du développement.De plus les infrastructures Cloud, PaaS internes ou externes, sont de plus en plus sophistiquées et le facilitent. Elles savent gérer les montées en charge, la performance et la sécurité, qui sont souvent les premiers freins rencontrés par les développements internes. Dans le même temps, celui de louer va s’envoler.Car l’IA met la pression sur les SaaS pour s’adapter. Cela va leur demander des investissements potentiels lourds, qui seront, en dernier ressort, payés par leurs clients, sans pouvoir renégocier (lock-in).
Or la période est au rééquilibrage des dépenses avec l’IA et les SaaS qui s’envolent. Et si réinternaliser son SI devenait le prochain acte de souveraineté budgétaire pour les DSI ?Que ce soit pour les DSI des grandes entreprises, mais, on va le voir, peut-être aussi pour ceux des collectivités locales ?
La semaine dernière, le DSI d’une grande organisation me confiait réfléchir à créer un « Département Engineering ».
Il y avait déjà une cellule innovation, et aussi depuis 2024 un lab-IA pour faire des démos au COMEX. Mais là, il me parlait d’un département d’ingénierie logicielle, avec des développeurs dedans, pour construire et posséder du logiciel !
Sur le coup, cela sonnait comme une évidence, mais en creux, il m’avouait qu’il n’avait plus un seul développeur dans ses équipes depuis plus de 10 ans. Or la pression montait pour regagner en souveraineté dans son SI.
Pourtant, dans une DSI française de 2026, la phrase « développer ses applications » sonne presque comme un anachronisme. Cela fait trente ans que le mouvement va dans l’autre sens : externaliser les études, forfaitiser les développements, puis acheter du SaaS pour ne plus rien développer du tout. Le DSI français est devenu un acheteur de capacité à bâtir, rarement un bâtisseur.
Alors quand une grande DSI recommence à dessiner un organigramme avec des ingénieurs dedans, c’est pour GreenSI le signal faible que l’équation économique du logiciel d’entreprise est en train de s’inverser. Sans aller nécessairement vers des systèmes d’information totalement spécifiques, comme certains ont pu les connaître, cela pose quand même une question stratégique pour la DSI : Make or buy ?
La courbe du « Buy » s’envole, plus vite que l’inflation,
GreenSI est allé chercher des chiffres qui décortiquent le marché français du SaaS pour le vérifier.
En 2023, c’est une hausse de plus de 6 % des prix des logiciels SaaS sur un an, soit une progression 1,8 fois plus rapide que l’indice des prix à la consommation. Côté américain, le constat est identique à plus grande échelle : la dépense SaaS moyenne d’une grande entreprise atteint 55,7 millions de dollars par an, en hausse de 8 %, alors que le portefeuille applicatif reste stable autour de 305 applications.
Oui, on paie plus cher pour le même nombre d’outils !
GreenSI y voit plusieurs raisons pour expliquer cette inflation :
La première, c’est le remplacement d’applications par d’autres applications, sans apporter nécessairement plus de valeur à l’entreprise. Mais ce qui émerge, c’est le surcoût d’IA tiers, intégrées aux applications et ajoutés aux abonnements. Des facturations à la consommation d’extensions qui sont imposées au renouvellement des contrats pour utiliser les nouvelles versions. Or le principe du SaaS, c’est quand même de toujours avoir un logiciel à jour. Sinon autant partir « on premise ».
L’exemple de référence c’est Microsoft Copilot qui se déploie sans demande des utilisateurs, dans les applications de l’éditeur.
L’autorité de la concurrence italienne vient d’ailleurs d’ouvrir une enquête sur l’intégration de Copilot et ses hausses de prix et migrations automatiques. Chaque DSI qui a vu sa facture M365 gonfler, sans avoir rien commandé, se reconnaîtra.Et ça risque de continuer avec l’introduction de l’IA dans les applications métiers et les ERP.
Mais Microsoft est cependant revenu en arrière sur l’intégration dans Windows 11 et l’envie de réintégrer les coûts de son IA dans les coûts de l’OS…
Car cette inflation frappe une dépendance des entreprises devenue quasi totale envers les éditeurs. Le marché SaaS français pèse plus de 8 milliards de dollars et file vers les 11 milliards à l’horizon 2028 (Statista). Selon le Top 250 d’EY, plus de 56 % du chiffre d’affaires des éditeurs de logiciels français est déjà réalisé en SaaS, et la bascule s’achève, puisque l’essentiel des solutions logicielles professionnelles est désormais distribué sous ce modèle.
Autrement dit, le SI français est passé en location généralisée au moment où le loyer se met à augmenter deux fois plus vite que les prix !
Aucun autre poste de dépense de l’entreprise n’accepterait une telle dérive sans déclencher une renégociation ou un déménagement, voire une rupture de service. C’est pour cela que GreenSI pense que la situation ne sera pas tenable, et que le SaaS ne restera pas éternellement irremplaçable.
Le coût du « Make / Build » s’effondre
La réalité c’est qu’avec l’IA, le coût de la construction chute. Même s’il est vrai que cela s’accompagne aussi de nouveaux coûts ailleurs (notamment dans le contrôle du code écrit par les IA).
Le développement assisté par IA a compressé le délai de l’idée au logiciel fonctionnel de trimestres en semaines. Les gains de productivité mesurés sur les tâches d’ingénierie courantes se situent entre 70 et 90 %, et dans plusieurs grandes entreprises technologiques, le code généré par IA représente déjà jusqu’à 40 % des nouveaux commits. Des workflows qu’il était hier trop coûteux de personnaliser deviennent économiquement viables à construire soi-même.Surtout si l’entreprise a une plateforme PaaS unifiée.
Le croisement des courbes n’est plus théorique.
Selon une étude récente de l’éditeur Retool (NB: source intéressée puisqu’elle vend des outils de développement interne), 35 % des équipes ont déjà remplacé au moins un outil SaaS par un développement interne, et 78 % prévoient d’en construire davantage dans l’année. Mais ce qui est intéressant dans leur étude c’est la typologie des problèmes auxquels on peut s’attaquer.
En tête des remplacements : les automatisations de workflow et les petits outils administratifs internes. Ces mêmes applications « de surface », sans forte connaissance métier, que des dizaines de plateformes SaaS facturent à l’utilisateur et au mois. Le gain est immédiat.
© Retool
Peut-on encore bâtir quand on a désappris ?
Car la réalité, au-delà de l’aspect économique qui va devenir évident pour le retour du « Make / Build », c’est comment on fait ?
Quand on a passé trente ans à désapprendre à construire, et à apprendre à acheter et louer, ce n’est pas évident de remettre en route la machine du Build ! La DSI française est structurellement l’une des plus externalisées d’Europe : forfaits, régie, centres de services. Les filières études-et-développement internes ont fondu au profit du pilotage de prestataires.
Construire redevient rentable, mais la compétence pour le faire n’est plus toujours dans les murs.
On pourrait aller la chercher dans les ESN ?Mais elles aussi ne savent plus construire. Sans marché pour les supporter, elles sont devenues des distributeurs indirects de progiciels.
C’est donc tout le sens de la question de ce DSI et de son département Engineering : le premier investissement du build n’est pas technologique, il est capacitaire. Recruter, ou re-former, des gens capables non pas de « vibe-coder » un prototype mais de posséder du logiciel dans la durée : le tester, le sécuriser, le documenter, le maintenir.
Créer un logiciel et posséder un logiciel sont deux métiers différents.L’IA n’a industrialisé que le premier.
C’est d’ailleurs dans le service public tout le débat qu’a suscité le lancement de « La Suite » pour remplacer Microsoft Office (tout en concurrençant notre industrie des suites collaboratives françaises). Ce qui nous amène à la question : l’État sait-il créer des logiciels et les maintenir dans le temps ?
Une opportunité pour les collectivités locales ?
C’est une question importante car elle amène un éclairage sur un problème de la décentralisation à la française. Toutes les communes de France font à peu près le même métier et sans concurrence entre elles. Pourtant, chacune a reçu la compétence de pouvoir créer son propre système d’information. Ce qui, avec le développement de l’informatique depuis les années 70s, coûte une fortune par rapport à des solutions qui auraient été centralisées.
Donc pour une collectivité territoriale, l’équation du « Build » possède un multiplicateur peu exploité : la mutualisation. Une façon de revenir en arrière sur la décentralisation du numérique. Donc au lieu d’avoir des éditeurs qui capitalisent sur des solutions vendues à chaque collectivités séparément, les collectivités ont le choix de n’avoir qu’une seule et même application pour chaque services local (petite enfance, comptabilité, gestion des cimetières, gestion des paiements sur la voirie, …)
Faisons le calcul. On dénombre plus d’une centaine de métiers différents dans les collectivités, liés à des compétences décentralisées — état civil, finances, urbanisme, social, éducation — dont certaines sont couvertes par des logiciels libres et d’autres par une poignée d’éditeurs métiers historiques. La dépendance avec ces éditeurs y est paradoxalement très forte, les marges confortables, pourtant elles ne migrent pas en masse vers du logiciel libre et préfèrent payer des coûts de logiciels en hausse. Paradox ?
Cela montre que l’évidence économique n’a jusqu’à présent pas suffi pas à faire basculer le modèle, du « Buy » vers le « Build ».
Ce qui va peut-être changer la donne, c’est la possibilité d’avoir un dispositif à un coût de développement suffisamment bas pour que la production de communs numériques locaux change d’échelle. C’est précisément ce que l’IA peut apporter.
Mais pour cela il faut que quelqu’un gouverne !
Car le build mutualisé sans ingénierie, c’est le pire des deux mondes. Et il ne faudrait pas troquer une dette (financière) contre une autre (technique). C’est donc un éclairage intéressant amené par le service public, qui cherche encore à tâtons sa gouvernance du numérique.
On sort donc de cette analyse avec deux axiomes importants pour la suite (sans jeu de mots 😉 même si « La Suite » devrait aussi y réfléchir):
Le code généré par IA n’est pas gratuit à posséder. Le build non gouverné produit sa propre dette.
Le coût total de possession est donc sous-estimé d’un facteur deux à trois, dans les deux sens d’ailleurs. Le coût de la location, lui cache ses limites dans les renouvellements et la consommation non maîtrisée à moyen terme.
La conclusion n’est donc pas reconstruisez TOUT votre SI.
Mais cette décision du « Make or Buy » est redevenue une vraie décision, après vingt ans où elle n’en était plus une. C’est donc certainement un arbitrage budgétaire à inscrire à l’agenda des budgets 2027. Remplacer des dizaines d’applications d’éditeurs « de surface » par des développements internes maîtrisés.
Et une vraie décision mérite une vraie instance pour la prendre. Elle passera par la réflexion sur ses capacités d’Engineering.
Pendant vingt ans, on a justifié l’externalisation par le « recentrage sur le cœur de métier ». L’IA vient de poser aux DSI une question dérangeante : et si construire son système d’information, c’était précisément ça, le cœur de métier de la DSI !
Source:
www.zdnet.fr
