La question la plus fréquente que nous posent d'autres fondateurs ne porte pas sur les prix ni sur la mise sur le marché. C'est une question discrète, légèrement méfiante : comment une équipe de votre taille parvient-elle à maintenir 150 modules sans que tout s'effondre ? La réponse honnête, c'est que nous ne maintenons pas 150 modules. Nous maintenons une seule plateforme et une couche très fine par-dessus. L'astuce, c'est d'être impitoyable sur la couche à laquelle appartient chaque tâche.
Le calcul qui fait peur.
Si vous imaginez 150 modules comme 150 petites applications – chacune avec son propre modèle de données, ses propres autorisations, sa propre facturation, ses propres notifications – alors 22 personnes, c'est évidemment fou. Cela représente six modules par ingénieur, chacun étant un produit à part entière. Aucune équipe n’y survit. La crainte est correcte, pour cette architecture.
Mais ce n'est pas l'architecture réelle. Un CRM, un outil de facturation et un service d'assistance ressemblent à trois produits distincts pour l'utilisateur. En dessous, ce sont les mêmes quelques briques de base : des enregistrements, des relations, une chronologie d'événements, des rôles et des permissions, de l'argent, des documents et un bus de notifications. Les différences tiennent surtout au vocabulaire et à la présentation, pas au fonctionnement.
Nous ne construisons pas 150 produits exceptionnels. Nous construisons un petit nombre de primitives bien conçues, configurées de 150 façons différentes.
La séparation noyau / module.
Tout ce qui est difficile réside dans le cœur, et il n'est construit qu'une seule fois : l'identité, les autorisations, la couche de données relationnelle, les paiements, le stockage de fichiers, la recherche, le journal d'audit, le système de notifications, le moteur d'export. Ce sont les éléments réellement difficiles et réellement partagés. Un bug corrigé ici est corrigé pour les 150 modules à la fois. Une capacité ajoutée ici — par exemple les signatures électroniques — devient instantanément disponible pour chaque module qui le souhaite.
Un module est donc délibérément mince. Il s'agit d'un schéma de données, d'un ensemble de vues, d'un ou deux flux de travail et du vocabulaire d'une tâche. "CRM" est une configuration qui dit : ces types d'enregistrements sont des prospects et des transactions, ceci est la vue du pipeline, voici les étapes, voici ce que signifie une conversion. Il repose entièrement sur le noyau. Un nouveau module est principalement une déclaration, pas du code.
La règle absolue : méritez votre singularité.
La discipline qui empêche cela de pourrir tient en une seule règle, appliquée à la revue : un module n'a pas le droit d'être spécial tant qu'il ne l'a pas vraiment mérité. Chaque fois qu'un module réclame son propre modèle de permissions sur mesure, son propre format de notification ponctuel, sa propre manière privée de stocker une date — la réponse par défaut est non. Intégrez-le au cœur du système comme une capacité générale, ou ne le faites pas.
C'est agaçant sur le moment et décisif sur la durée. La plupart des demandes du type « il nous faut quelque chose de sur mesure ici » sont en réalité des « nous n'avons pas assez réfléchi au cas général ». Lorsque vous imposez le cas général, le cœur s'enrichit, chaque module en profite, et la surface à maintenir reste à peu près stable même quand le nombre de modules augmente.
Ce à quoi nous avons renoncé.
Cette approche a un coût réel, et il faut le nommer. Un outil ponctuel le meilleur de sa catégorie, conçu par une équipe obsédée par une seule tâche, surpassera notre module équivalent sur cette tâche précise. La plateforme d'e-mailing la plus poussée dispose d'automatisations que nous n'avons pas. L'outil de gestion de projet le plus poussé offre des vues que nous n'avons pas. Nous ne prétendons pas le contraire.
Ce que nous échangeons contre cette profondeur, c'est la cohérence — des modules qui partagent un seul modèle de données, une seule connexion, une seule facture, un seul export et une seule couche de notifications. Pour une équipe de 5 à 50 personnes, cette cohérence vaut plus que les derniers 20 % de profondeur de n'importe quelle catégorie. Pour une équipe dont toute l'activité tient dans cette seule catégorie, ce n'est pas le cas. Nous savons exactement à qui nous nous adressons, et cette architecture est la raison pour laquelle nous pouvons les servir avec 22 personnes.