Vous avez un outil qui fonctionne pour un client, et vous voulez le vendre à dix autres. C’est le bon réflexe : le développement est déjà payé, chaque client supplémentaire coûte moins cher que le premier. Reste une question d’apparence technique, mais dont la réponse est commerciale : est-ce que chaque client a son application, ou est-ce que tout le monde partage la même ?
Les deux modèles existent, portent des noms différents, et ne coûtent pas la même chose.
Le modèle « marque blanche » : une application par client
Une seule base de code, mais autant d’applications publiées que de clients. Chacun a la sienne : son nom, son logo, ses couleurs, sa fiche sur les magasins d’applications. Ses utilisateurs ne savent pas — et n’ont pas besoin de savoir — que la même base fait tourner dix autres organisations.
Ce que ça vous apporte. Votre client existe auprès de ses propres membres. Pour une association, un club ou une franchise, c’est souvent tout l’argument : l’outil ne ressemble pas à un abonnement souscrit chez un tiers, il ressemble à quelque chose que l’organisation a fait pour les siens.
Ce que ça vous coûte. Chaque client est une publication de plus. Une mise à jour de sécurité, ce sont dix soumissions sur deux magasins d’applications, dix revues éditoriales à passer, dix jeux de captures d’écran à tenir à jour. La vraie facture de la marque blanche n’est pas dans le code, elle est dans la distribution.
Le modèle « multi-tenant » : une seule installation pour tout le monde
Une seule application, un seul serveur, une seule base de données. Les clients y cohabitent, cloisonnés : chacun ne voit que ses données. C’est le modèle de la quasi-totalité des logiciels vendus par abonnement.
Ce que ça vous apporte. Un client de plus ne coûte presque rien : pas de publication, pas de serveur supplémentaire, pas de version à maintenir à part. Vous corrigez un défaut une fois et tout le monde en bénéficie le jour même.
Ce que ça vous coûte. Le cloisonnement des données devient la question la plus importante du projet. Une seule erreur — une requête qui oublie de filtrer sur le bon client — et une organisation voit les données d’une autre. C’est le genre d’incident dont on ne se remet pas commercialement, et il ne se traite pas en fin de projet : il se décide dans les premières semaines, au niveau de la structure même des données.
La question qui tranche vraiment
Elle n’est pas technique :
Votre client doit-il apparaître comme l’éditeur de l’outil auprès de ses propres utilisateurs ?
Si oui — association, club, fédération, franchise, réseau d’agences — la marque blanche s’impose, et il faut accepter le coût de distribution qui va avec.
Si non — vos clients assument d’utiliser un logiciel du marché, comme ils assument leur logiciel de comptabilité — le multi-tenant est presque toujours le bon choix, et le seul qui permette d’ajouter un client sans y passer une semaine.
Les deux se combinent d’ailleurs très bien : il est courant qu’un même serveur multi-tenant alimente plusieurs applications en marque blanche. C’est même la configuration la plus confortable, à condition de l’avoir décidée avant d’écrire le premier écran.
Le piège qui tue les deux modèles
Il est identique dans les deux cas, et il est toujours commis pour de bonnes raisons.
Un client demande un ajustement. Ce n’est pas grand-chose. On le code « juste pour lui », dans sa version à lui. Six mois et trois clients plus tard, il existe quatre variantes du même logiciel, et chaque correctif doit être écrit, testé et publié quatre fois. Le produit est mort avant d’avoir été rentable.
La discipline qui l’évite tient en une règle : rien de spécifique à un client n’entre dans le code métier. Un client ne possède qu’une configuration et des images. Tout le reste est générique — et si une demande ne peut pas être formulée de façon générique, c’est presque toujours qu’elle a été mal comprise.
Nous appliquons cette règle sur nos propres produits : une suite applicative déclinée en marque blanche pour des associations d’un côté, une plateforme multi-tenant pour des clubs de l’autre. Ce sont deux réponses différentes à la même question, et le choix a été fait avant la première ligne de code.
Vous en êtes là ? C’est exactement le type d’arbitrage que traite une phase de conseil et d’architecture : quelques jours au début du projet qui déterminent ce que coûtera votre dixième client. Parlons-en — le premier échange est gratuit.
