Un même logiciel, quatre marchés : comment nous déclinons une plateforme par verticale

Quand nous avons livré notre première plateforme de gestion pour une école de danse, je savais qu’un club de football nous demanderait bientôt la même chose. La question n’était pas si, mais comment : refaire un produit, ou décliner celui-ci ?

Nous avons choisi de décliner. Trois ans plus tard, le même socle fait tourner quatre marques. Voici ce que j’en retiens — y compris ce que je ferais différemment.

Le point de départ

Une école de danse et un club de football n’ont pas le même vocabulaire. L’une parle de cours, de professeurs et de galas ; l’autre d’entraînements, de coachs et de matchs. Un dirigeant d’association reconnaît immédiatement un logiciel conçu pour le voisin.

Mais si l’on regarde ce que le logiciel doit faire, la liste est presque identique : inscrire des adhérents, encaisser des cotisations, gérer un planning et des salles, vendre des billets et des articles, donner un espace aux familles et un back-office au bureau.

C’est exactement le cas de figure où une plateforme multi-marques a du sens — et exactement celui où l’on se trompe le plus facilement, en mutualisant ce qu’il ne fallait pas.

Ce qui est mutualisé

Le socle technique, dans sa totalité : authentification, modèle de données, moteur de paiement, génération des documents, back-office, règles de sécurité, chaîne de déploiement.

Un correctif de sécurité écrit une fois protège les quatre marques. Une amélioration du tunnel de paiement profite aux quatre. C’est là que se trouve tout le gain, et il est considérable : ouvrir une nouvelle verticale ne coûte plus le prix d’un produit, mais celui d’une déclinaison.

Concrètement, cela veut dire que la décision d’attaquer un nouveau marché ne se prend plus sur un critère technique. Elle se prend sur la seule question qui compte : y a-t-il des clients ?

Photo : Tom Sodoge — licence CC0.

Ce qui ne doit jamais l’être

Le vocabulaire. Un club sportif à qui l’on parle de « cours » et de « professeurs » sent immédiatement qu’il utilise un logiciel conçu pour quelqu’un d’autre. Chaque marque a ses libellés, jusque dans les e-mails transactionnels et les messages d’erreur. C’est un détail qui n’en est pas un : c’est ce qui fait la différence entre « un outil fait pour nous » et « un outil qu’on a adapté ».

Le domaine et la marque. Vibe-it et Moove-IT sont deux sites, deux identités, deux discours. Un prospect ne doit jamais avoir à se demander si le produit est fait pour lui. Cela coûte un peu en effort marketing, et cela rapporte énormément en taux de conversion.

Les parcours spécifiques. Une école de danse gère des galas avec placement numéroté ; un club sportif gère des convocations et des feuilles de match. Ces parcours sont propres à chaque univers et le resteront.

Où se situe la limite

La mutualisation cesse d’être rentable quand les divergences deviennent structurelles plutôt que lexicales. Le signal d’alerte est facile à repérer, et je le surveille de près : dès qu’une fonctionnalité demande une condition du type « si marque = X alors » au cœur du modèle de données, ce n’est plus une déclinaison — ce sont deux produits qui cohabitent mal dans le même dépôt.

Notre règle : la variation vit dans la configuration et le contenu, jamais dans la logique métier. Quand elle commence à remonter dans le code, il faut arbitrer — soit renoncer à la spécificité, soit assumer un produit distinct. Les deux réponses sont acceptables ; ne pas trancher ne l’est pas.

Ce que la mutualisation coûte vraiment

On ne parle jamais assez du revers. Un socle partagé n’est pas gratuit, et il faut connaître sa facture avant de s’engager.

Chaque déploiement engage quatre marques. Une régression introduite dans le socle ne casse pas un produit, elle en casse quatre — simultanément, chez des clients qui ne se connaissent pas. Cela impose une discipline de tests bien supérieure à celle d’un produit isolé, et un pipeline capable de déployer verticale par verticale plutôt que d’un bloc.

Les priorités entrent en concurrence. Quand une école de danse demande une fonctionnalité qui n’intéresse pas les clubs sportifs, il faut arbitrer : la faire pour tout le monde, la faire seulement pour une verticale, ou ne pas la faire. Aucune des trois réponses n’est confortable, et c’est un arbitrage hebdomadaire.

La complexité se déplace, elle ne disparaît pas. Un socle configurable est plus difficile à comprendre qu’un produit dédié. Un développeur qui arrive doit assimiler non seulement le métier, mais aussi le mécanisme de variation. Le temps d’intégration augmente.

Mon estimation, à la louche : la mutualisation coûte 20 à 30 % d’effort supplémentaire sur le premier produit, et les rend à partir du deuxième. Si vous n’êtes pas certain qu’il y aura un deuxième marché, ne mutualisez pas — faites un bon produit dédié, quitte à extraire le socle plus tard.

Photo : Karol Dach — licence CC0.

Le test que j’applique avant de mutualiser

Avant d’ouvrir une verticale, je me pose trois questions, dans cet ordre.

Est-ce que le modèle de données tient ? Pas « peut-on le faire tenir », mais : est-ce que les entités principales — adhérent, séance, paiement, lieu — ont le même sens dans le nouveau métier ? Si un « adhérent » devient une famille plutôt qu’une personne, ce n’est pas une déclinaison.

Est-ce que les parcours critiques se recouvrent ? L’inscription, le paiement et le planning doivent fonctionner de la même façon. Si l’un des trois change de nature, le gain fond.

Est-ce que la marque tient toute seule ? Une verticale qui n’a pas son propre discours, son propre domaine et ses propres prospects n’est pas un marché : c’est une option de configuration, et elle ne mérite pas une marque.

Ce que je ferais différemment

J’isolerais le vocabulaire dès la première ligne. Nous l’avons extrait dans un second temps, et cette reprise a coûté plusieurs semaines. Si vous pensez qu’il y aura une deuxième verticale un jour, sortez les libellés du code immédiatement — même si vous n’avez qu’une marque.

Je testerais la deuxième marque plus tôt. Tant qu’un socle ne sert qu’un seul usage, on ne sait pas ce qui est générique et ce qui est spécifique : on le croit seulement. La deuxième verticale est le vrai test d’architecture, et il vaut mieux le passer tôt, quand le code est encore petit.

Je documenterais les points de variation. Aujourd’hui, ajouter une marque suppose de savoir où toucher. Cette connaissance est dans la tête de trois personnes. C’est un risque, et c’est la prochaine chose que nous corrigeons.

Pourquoi ça compte même sans être éditeur

Ce raisonnement ne concerne pas que les produits. Beaucoup d’entreprises nous demandent une application pour une entité, une filiale ou un pays, en sachant qu’il y en aura d’autres.

La question à poser en cadrage n’est alors pas « comment fait-on la première ? » mais « qu’est-ce qui sera commun aux suivantes ? ». Une réponse claire à cette question, prise avant la première ligne de code, change l’architecture — et divise le coût de la deuxième.

C’est le genre d’arbitrage qui ne se rattrape pas après coup.