La fin du SaaS standard, l'avènement du logiciel taillé sur l'organisation

Le SaaS générique a tenu vingt ans. Il s'apprête à céder la place à autre chose. Pas un retour à l'on-premise des années 2000, pas un nouveau cycle de cloud public, mais un déplacement plus profond : le logiciel cesse de demander à l'organisation de s'adapter à lui. C'est l'inverse qui se produit. Le software devient l'écriture exécutable de la réalité métier, et cette réalité n'a aucune raison d'être identique d'une organisation à l'autre.

Pourquoi le SaaS générique arrive en bout de course

Le pari fondateur du SaaS, formulé entre 2005 et 2015, tenait en trois propositions. Mutualiser les coûts d'infrastructure entre des milliers de clients. Standardiser les processus pour que tous bénéficient des bonnes pratiques codifiées dans le produit. Externaliser la maintenance pour libérer les DSI de la plomberie. Sur ces trois propositions, deux sont devenues des commodités, et la troisième se retourne contre les éditeurs.

L'infrastructure ne coûte plus rien. AWS, GCP et Azure ont rendu trivial ce qui demandait dix ingénieurs il y a vingt ans. La standardisation, elle, est devenue le problème principal des grandes organisations. Quand SAP, Salesforce ou Workday imposent leur modèle de données et leurs processus, l'entreprise paie une dette d'adaptation continue. Chaque exception métier devient un projet de configuration coûteux. Chaque évolution du SaaS oblige à retoucher le contournement. Et l'externalisation de la maintenance se traduit, du point de vue de l'utilisateur, par un produit qui change sans son consentement, qui ajoute des fonctionnalités qu'il n'a pas demandées et retire celles qu'il utilise.

Le coût total de possession du SaaS standard, intégré honnêtement, dépasse souvent celui d'un logiciel sur-mesure bien construit. La différence, c'est qu'il est invisible. Il s'appelle dette d'adaptation, perte de productivité, frustration des équipes métier, intégrations Zapier qui craquent. Pris individuellement, chacun de ces postes est mineur. Cumulés, ils représentent la moitié de la valeur que le SaaS prétendait apporter.

Ce qui rend possible le retour du sur-mesure

Le sur-mesure n'a jamais été abandonné parce qu'il n'avait pas de valeur. Il a été abandonné parce qu'il coûtait trop cher à produire et trop cher à maintenir. C'est précisément cette équation qui s'est retournée entre 2023 et 2026.

• La génération assistée par IA divise par cinq à dix le coût de production du code, et permet à des profils business de participer activement à la conception du produit.
• Les architectures event-sourcées et le métamodèle DDD offrent une stabilité dans le temps qui était impossible avec les architectures sur-mesure des années 2000.
• Les protocoles standards comme MCP rendent les briques métier interopérables, ce qui élimine le risque de réinvention permanente.
• Les agents IA gouvernés permettent d'automatiser la maintenance évolutive sans rebâtir une équipe d'éditeur en interne.

La conséquence est mécanique. Le coût du sur-mesure devient comparable à celui d'un SaaS standard. Sa valeur, en revanche, est radicalement supérieure. Parce que le sur-mesure encode ce que la standardisation efface : l'expertise métier réelle, les particularités d'organisation, les frictions spécifiques que l'équipe veut effacer.

Encoder l'expertise métier réelle, pas la moyenne du marché

Une expertise métier ne se laisse pas réduire à un workflow standard. Un cabinet d'avocats spécialisé en M&A n'a pas les mêmes points de friction qu'un cabinet de droit social. Une PME industrielle qui produit des pièces unitaires n'a pas les mêmes contraintes qu'une PME de série. Un hôpital de proximité ne suit pas les mêmes parcours qu'un CHU. Le SaaS standard, par construction, optimise pour le cas moyen. Il pénalise les cas particuliers, qui sont précisément ceux qui ont une raison d'exister.

Encoder l'expertise réelle signifie modéliser dans le logiciel les concepts que les experts manipulent quotidiennement, avec leurs définitions précises et leurs règles d'évolution. Pas une approximation. Pas une traduction vers un modèle générique. Le concept exact, avec sa terminologie exacte, ses invariants, ses transitions d'état. C'est ce que la communauté DDD appelle l'ubiquitous language : un vocabulaire partagé entre les experts métier et le code, sans glissement de sens.

Cette ambition, technique en apparence, est en réalité organisationnelle. Elle suppose que les experts métier participent à la définition du modèle. Elle suppose que le logiciel évolue à mesure que la compréhension métier évolue. Elle suppose que la dette de traduction entre le métier et le code soit ramenée à zéro, ou aussi près de zéro que possible. Aucun SaaS standard ne peut atteindre ce niveau, parce que sa valeur économique vient justement du contraire : un modèle gelé, vendu identique à des milliers de clients.

Effacer les frictions, pas les déplacer

Une friction est un endroit où le travail réel rencontre une contrainte du logiciel. Un champ obligatoire qui n'a pas de sens dans certains cas. Une étape de validation qui ralentit sans rien valider. Un workflow rigide qui force des contournements. Une donnée saisie deux fois parce que deux outils ne se parlent pas. Une exception légitime qui demande un ticket support à chaque occurrence.

Les frictions ne sont pas des bugs, ce sont des écarts entre l'organisation telle qu'elle est et l'organisation telle que le logiciel la suppose. Dans un SaaS standard, on ne peut pas les effacer, parce que le logiciel ne sait pas qu'elles existent : il a été conçu pour le cas moyen, pas pour la situation locale. On peut au mieux les contourner, ce qui crée d'autres frictions ailleurs.

Le sur-mesure permet de regarder chaque friction et de décider : est-ce qu'on garde cette contrainte parce qu'elle protège quelque chose, ou est-ce qu'on l'efface parce qu'elle ralentit pour rien ? La question elle-même est interdite dans un SaaS, qui impose les contraintes par défaut sans dire pourquoi. Le sur-mesure rend la question possible, et donc rend l'optimisation possible.

L'organisation pensée avec un angle software

À horizon trois à cinq ans, le déplacement le plus profond ne sera pas l'arrivée de nouveaux outils. Ce sera le changement de la manière dont les dirigeants conçoivent leur organisation. Aujourd'hui, on dessine d'abord l'organigramme, on définit les processus, et on choisit ensuite des logiciels qui les supportent plus ou moins bien. Demain, on concevra l'organisation et son logiciel ensemble, comme deux faces d'un même artefact.

Cette idée n'est pas nouvelle. Conway l'avait formulée en 1968 sous une forme inverse : la structure des systèmes logiciels reflète la structure des organisations qui les conçoivent. Ce qui change en 2026, c'est que la formulation devient bidirectionnelle. La structure de l'organisation peut désormais être conçue en tenant compte des affordances que le logiciel rend possibles. Un workflow, une autorisation, une responsabilité, une boucle de décision : tous ces objets organisationnels deviennent négociables, parce que le logiciel qui les supporte est lui-même négociable.

Concrètement, cela veut dire qu'un dirigeant qui réfléchit à sa nouvelle ligne métier ne demandera plus aux DSI quels logiciels existent pour la supporter. Il décrira la ligne métier comme il la conçoit, et le logiciel sera fabriqué à partir de cette description. Si l'organisation évolue, la description évolue, et le logiciel évolue avec elle. Le software cesse d'être une infrastructure héritée pour devenir une matière vivante, à l'image des organisations qu'il sert.

Ce que ça change concrètement pour les directions

Le premier signal du basculement est déjà visible chez les directions financières et opérationnelles avancées. Elles arrêtent de payer des licences pour des fonctions qu'elles n'utilisent qu'à 30 %. Elles arrêtent d'engager des intégrateurs pour faire dialoguer leurs huit SaaS. Elles arrêtent de reproduire dans Excel les calculs que leur ERP est incapable d'effectuer. Elles externalisent la réflexion sur leur logiciel à des partenaires qui le construisent à partir de leur métier réel.

Ce mouvement n'est pas idéologique, il est économique. Le retour sur investissement d'un logiciel sur-mesure, calculé honnêtement sur cinq ans, dépasse celui d'un SaaS standard pour la majorité des organisations dont le métier est différencié. La condition est que le sur-mesure soit construit avec une architecture qui survit dans le temps, qui évolue par configuration plutôt que par réécriture, et qui produit des preuves d'audit nativement. C'est exactement ce que les frameworks event-sourcés modernes rendent possible, et ce que les organisations achetaient à perte aux éditeurs SaaS depuis vingt ans.