Plateformes réutilisables : le moteur qui alimente 5 verticales (et comment les concevoir)

Quand vous développez un deuxième ou troisième produit au sein d’une même famille, arrive le moment de vérité. Vous avez commencé par un CRM pour salles d’événements. Puis est venue une agence immobilière nécessitant une version adaptée. Ensuite un atelier mécanique, puis une clinique. Chacun semblait « totalement différent », mais 70 % du code se répétait.

C’est là qu’il faut songer à une plateforme réutilisable. Il existe une bonne et une mauvaise façon de procéder. Commençons par la mauvaise, car c’est la plus courante.

L’erreur : l’abstraction prématurée

L’erreur typique consiste à généraliser trop tôt. Après le premier produit, on se dit : « Ça peut servir à plein de métiers différents. » On investit alors du temps dans l’abstraction, à ajouter des configurations infinies et à rendre le code « générique ». Résultat, l’une de ces deux situations se produit :

• La plateforme devient si configurable qu’il faut apprendre un nouveau langage pour l’utiliser dans chaque cas.
• Les « configurations » couvrent 80 % des besoins, mais les 20 % restants imposent de modifier la plateforme, ce qui rompt la compatibilité avec les autres clients.

La règle d’or : abstraire après le troisième cas réel, jamais avant. Le premier produit résout un problème précis. Le second vous révèle ce qu’il a en commun avec le premier. Le troisième confirme le pattern. Avant cela, toute abstraction n’est qu’une spéculation.

Le pattern qui fonctionne : moteur + adaptateurs

Une plateforme réutilisable bien conçue repose sur deux couches :

1. Le moteur : ce qui est commun à toutes les verticales. Pipeline d’états avec transitions, propositions avec versions, gestion des contacts, calendrier, paiements, notifications, audit des modifications, multi-utilisateurs avec rôles, multi-tenancy isolé.

2. L’adaptateur par verticale : ce qui est spécifique à chaque métier. La définition des états (une salle d’événements a des états comme « visite programmée », un atelier mécanique a « véhicule réceptionné »), les règles de transition ( « impossible de facturer sans devis approuvé »), les champs personnalisés, les rapports spécifiques.

Le moteur doit être le plus opinionné possible sur la structure commune (pour éviter les ruptures entre verticales) et le plus flexible possible dans la configuration des verticales.

Comment nous l’avons appliqué chez La Carolina et au-delà

La Carolina a débuté comme un CRM pour salles d’événements. Le moteur que nous y avons développé sert aujourd’hui à :

• La restauration événementielle : même pipeline de commandes/devis/événement/paiement.
• Les agences immobilières : les états changent (visite, offre, contrat), mais la structure reste identique.
• Les services professionnels avec devis : cabinets comptables, agences de communication, cabinets de conseil.
• Les événements B2B : salons, congrès, formations.

Le moteur gère déjà : des états configurables, des devis avec versions, la synchronisation avec Google Calendar, des paiements fractionnés avec acompte, des notifications automatiques selon les transitions. Adapter une nouvelle verticale prend désormais quelques semaines, contre plusieurs mois auparavant.

Multi-tenancy : la décision architecturale clé

Si vous envisagez de vendre la plateforme à plusieurs clients (et non à différentes branches d’une même entreprise), chaque client doit voir uniquement ses propres données. C’est ce qu’on appelle le multi-tenancy, et il existe trois approches possibles :

1. Base de données par tenant : une base entière par client. Isolation maximale, mais coût et complexité élevés. Idéal pour des secteurs très réglementés (santé, finance) avec peu de clients mais de grande taille.

2. Schéma par tenant : une seule base avec des schémas séparés par client. Compromis intéressant : isolation correcte, coûts raisonnables, mais complexité opérationnelle accrue par rapport à un schéma unique.

3. Schéma partagé avec tenant_id : une seule base, une seule structure, avec une colonne identifiant le client. Solution la plus économique et la plus simple, mais exige une discipline absolue pour garantir l’isolation (c’est ici que la Row Level Security au niveau base de données entre en jeu, et non au niveau code).

Pour un SaaS B2B avec de nombreux clients moyens, schéma partagé + RLS offre le meilleur rapport coût/bénéfice. Mais l’isolation ne peut pas dépendre uniquement du code : elle doit aussi être garantie au niveau de la base de données.

Le compromis produit-plus-plateforme

Quand vous créez une telle architecture, vous avez deux types de clients :

• Ceux qui utilisent le produit vertical standard (licence mensuelle, configuration limitée).
• Ceux qui nécessitent des adaptations spécifiques (projet de mise en œuvre + licence, plus coûteux).

L’erreur serait de les traiter de la même manière. La solution : proposer un produit vertical standard avec une licence mensuelle pour les premiers, et des projets d’implémentation personnalisés pour les seconds. Deux modèles de tarification, deux types de contrats, deux équipes dédiées.

Quand une plateforme réutilisable n’est-elle pas adaptée ?

Toute chose ne bénéficie pas d’une approche plateforme. Cela n’a pas de sens si :

• Chaque client est très différent : si les « configurations » représentent 80 % du travail dans chaque cas, ce n’est pas une plateforme, mais des produits distincts déguisés en solution unique.
• Votre marché est restreint : si vous n’avez que 3 clients au total, une plateforme serait du sur-mesure.
• Le support et la mise en œuvre représentent l’essentiel du travail : si vous vendez surtout de la consultance avec un logiciel en support, vous faites plutôt du service professionnel que du SaaS B2B.

Conclusion

Les plateformes réutilisables sont magnifiques quand elles sont bien pensées, et un enfer quand elles sont mal conçues. La différence réside dans l’attente du troisième cas réel avant d’abstraire, dans la séparation claire entre moteur et adaptateurs, et dans la résolution du multi-tenancy dès le premier jour avec une sécurité intégrée au niveau de la base.

Si vous envisagez de construire votre propre moteur réutilisable, ou si vous vendez déjà un produit vertical et souhaitez vous étendre à d’autres verticales similaires, contactez-nous. Nous vous aidons à concevoir l’architecture avant d’écrire un code dont vous regretterez plus tard les modifications.

---

Par Esteban Aleart, Fondateur et Lead Engineer chez Pair Programming.