Construire redevient moins cher qu'acheter

Quand un opérationnel a besoin d’un outil pour son quotidien, le réflexe est devenu mécanique. Quelqu’un demande s’il existe un SaaS pour ça. Quelqu’un d’autre lance la veille fournisseurs. Trois mois plus tard, une licence supplémentaire s’ajoute aux deux cents déjà en place, dont la moitié sera inutilisée. Ce réflexe a été rationnel pendant vingt ans. Il vient de cesser de l’être.

Pourquoi nous avions cessé de construire

La rationalité d’hier était simple. Développer un outil sur-mesure coûtait six chiffres et plusieurs mois. Acheter un SaaS générique coûtait un abonnement et une formation. Le calcul ne se posait même plus. On achetait, on adaptait les équipes à l’outil, et on absorbait la friction comme un coût normal d’exploitation.

Cette logique a produit des résultats massifs. Selon Zylo, la grande entreprise gère en moyenne 305 applications SaaS, et 30 à 50% des licences achetées ne sont jamais sérieusement utilisées. La dépense annuelle moyenne dépasse 55 millions de dollars par grande entreprise. La consolidation, quand elle se produit, ne réduit que marginalement la facture, parce qu’elle ne touche pas la cause.

La cause, c’est la friction qu’on a inscrite dans le quotidien. Une étude relayée par la Harvard Business Review documente 1 200 bascules entre applications par jour pour un knowledge worker moyen, soit une toutes les 24 secondes. Les travaux de Gloria Mark à UC Irvine montrent qu’il faut 23 minutes et 15 secondes pour se reconcentrer après une interruption. Le résultat agrégé tient en un chiffre. Un salarié dispose en moyenne de 2 heures et 53 minutes de productivité réelle par journée de huit heures.

Pendant vingt ans, cette friction n’a pas été un échec du marché. Elle a été le prix à payer pour ne pas avoir à coder.

Ce qui s’est effondré en dix-huit mois

Le coût marginal de construction d’une application métier vient de passer de plusieurs mois-homme à quelques heures. Claude Artifacts, Bolt, v0, Lovable, Replit Agent, Cursor : ces outils ne sont plus des démonstrations. Ils sont en production.

Un témoignage récent publié sur Hacker News illustre la bascule. Une PME non-tech rapporte sept applications maison construites avec ces outils, en usage quotidien, dont deux qui remplacent des SaaS payants. Ce n’est pas un cas isolé. C’est le scénario qui se répète à bas bruit dans des milliers d’organisations.

Forrester, qui n’est pas connu pour ses titres provocateurs, publiait en février 2026 une note intitulée SaaS As We Know It Is Dead. Le cabinet y cite explicitement le vibe coding comme érodant trois douves classiques des éditeurs : le catalogue de features accumulé sur dix ans, le réseau d’intégrations entre outils, et le coût de switching pour le client. Quand ces trois douves disparaissent, ce qui reste d’un abonnement à 200 euros par mois et par utilisateur, c’est essentiellement une rente.

Le signal le plus intéressant vient des éditeurs eux-mêmes. Salesforce a lancé Agentforce Vibes en octobre 2025, qui permet aux clients de générer leurs propres applications à l’intérieur de la plateforme. Les éditeurs SaaS ont compris ce que beaucoup d’acheteurs n’ont pas encore intégré : la valeur ne se trouve plus dans le catalogue, elle se trouve dans la capacité à construire.

flowchart LR
  A[Besoin métier identifié] --> B{Calcul d'achat}
  B -->|Hier| C[Acheter un SaaS générique]
  B -->|Aujourd'hui| D[Construire un outil sur-mesure]
  C --> E[Adapter l'équipe à l'outil]
  D --> F[Outil adapté à l'équipe]
  E --> G[Friction quotidienne]
  F --> H[Friction supprimée]

La nouvelle question, et le nouveau goulot

Le build-versus-buy redevient une vraie question, pas un réflexe. Et avec lui, une compétence devient critique : savoir formuler ce qui mérite d’être construit. Tout le monde peut désormais générer du code. Personne n’a appris à diagnostiquer la friction qui justifie un nouvel outil, à cadrer ce qui doit exister, à arbitrer entre dix solutions techniquement valides mais stratégiquement opposées.

Le code est tombé du podium des compétences rares. Le diagnostic métier y est monté.

Nous l’avons documenté il y a quelques jours côté conseil et agences : le coût de produire s’effondre, le coût de savoir quoi produire ne bouge pas. La même bascule se rejoue à l’intérieur de chaque entreprise, à chaque fois qu’un dirigeant doit choisir entre acheter un SaaS et construire son propre outil. Le talent qui valait cher était celui qui savait livrer. Le talent qui vaut cher est désormais celui qui sait quoi livrer.

Cette compétence ne s’achète pas dans un cabinet. Elle s’incarne dans quelqu’un qui connaît assez bien le métier pour savoir où sont les quatre clics inutiles, et assez bien les outils pour savoir ce qu’on peut désormais construire à leur place. C’est un profil rare, parce qu’on a passé vingt ans à séparer ceux qui comprenaient le métier de ceux qui savaient construire. Cette séparation n’a plus de raison d’être.

Construire pour une personne, pas pour un million d’utilisateurs, demande un type d’attention que les éditeurs SaaS n’ont jamais eu besoin de pratiquer. C’est cette attention qui devient l’actif rare.

---

Le réflexe “il y a sûrement un SaaS pour ça” reste valable, parfois. Mais il a cessé d’être la réponse évidente. La paresse intellectuelle de l’achat par défaut a maintenant un coût mesurable. 305 abonnements, dont la moitié inutilisée, et 1 200 bascules par jour pour vos équipes. Construire redevient moins cher qu’acheter, sur tout un pan du logiciel d’entreprise. Encore faut-il savoir construire ce qui mérite de l’être.