SharedCore: un cœur produit partagé, des modèles de base adaptés, une évolution commune

Résumé

Au fil des années, chaque client d’un ERP, d’un SIRH ou d’un logiciel de paie a obtenu ses propres adaptations: par la configuration, par du code écrit pour lui seul, par des mécanismes greffés autour du système. Le produit est devenu une collection de variantes, et chaque obligation légale, chaque correctif de sécurité, chaque montée de version se paie variante par variante. Trois pressions rendent ce modèle intenable: le chiffre d’affaires étant presque constant, la marge supplémentaire doit venir du coût de production; des réglementations comme le Cyber Resilience Act, DORA et NIS2 imposent de surveiller et de corriger chaque version maintenue; l’IA accélère ce qui est commun et bien décrit, mais bute sur ce que personne n’a documenté. Construire une plateforme moderne à côté de l’ancien système n’est pas une issue: l’éditeur maintient alors les deux, variantes comprises.

SharedCore conserve ce qui fonctionne, comme le moteur de calcul, et remplace le reste par un nouveau produit, vers lequel les clients migrent sans leurs variantes. Ce produit repose sur trois règles: un cœur partagé, qui ne change jamais pour un seul client; des modèles de base adaptés à chaque typologie de client; une évolution commune, avec une seule version, que l’éditeur fait évoluer et met à jour chez le client (on-premise) comme dans le cloud. Un seuil heuristique fixe la frontière du produit à environ 20% de composants modifiés ou développés. Avant tout chantier, cinq questions sont à trancher, à commencer par l’objectif, qui doit être une intention mesurable et non une action.

La preuve vient d’un cas réel: un ancien progiciel de gestion client-serveur, utilisé à distance par quelque 1 500 clients, que nous avons remplacé il y a quelques années. L’objectif était économique; l’obstacle était la migration, estimée à 70 jours de travail par client en moyenne. Les métiers, les architectes, le support et un panel de 10 à 12 responsables métier issus des clients ont conçu ensemble des modèles de base, un par typologie de client. Ces modèles couvraient 80% des besoins, et la migration d’un client est tombée à 6 jours, consacrés aux seules données qui lui sont propres. Sur 100 clients, 90 ont accepté d’emblée le modèle de leur typologie, 6 l’ont rejoint après un an d’accompagnement et 4 sont partis. L’article décrit ensuite l’inventaire assisté par l’IA, la migration par cohortes et la fermeté qu’exige la frontière, avant de poser la vraie limite de la stratégie: un changement de modèle économique, que seul le patron de l’entité peut décider.

Idées clés

• Un logiciel adapté client par client devient des centaines de produits, et chaque obligation légale, chaque correctif et chaque montée de version se paie une fois par variante. Une nouvelle plateforme construite à côté de l’ancien système ne retire rien; la convergence coûte d’abord, elle aussi, mais chaque client qui migre retire une part de l’ancien système, jusqu’à ce qu’on puisse l’éteindre.
• Rien ne se personnalise dans le code: un besoin que la configuration ne couvre pas devient une fonctionnalité offerte à tous, est construit par le client en dehors du produit, sur ses API, ou n’est pas fait; au-delà d’environ 20% de composants modifiés ou développés, le client ne relève plus du produit.
• Le modèle de base était la pièce qui manquait: conçu pour chaque typologie avec un panel de clients, il a fait passer la migration d’un client de 70 à 6 jours, et 90 clients sur 100 l’ont accepté d’emblée, parce qu’il avait été construit avec eux et que les contrats ne se renouvelaient plus que sur le nouveau produit.
• Le départ de 4 clients sur 100 est le prix de la frontière, et non un échec. Tenir cette frontière suppose une offre crédible et des clients accompagnés.
• La limite n’est pas technique: passer d’un logiciel adapté à chaque client à un produit unique change le modèle économique de l’éditeur, et seul le patron de l’entité peut en décider.

Pourquoi j’ai écrit cet article