Bizzi passe au multi-tenant : la fin de la dette technique
Bizzi refonde son architecture en multi-tenant pour éliminer la dette technique et devenir une véritable plateforme SaaS scalable.
Bizzi passe au multi-tenant : la fin de la dette technique
Depuis sa création, Bizzi portait les stigmates d'une architecture monolithique pensée pour un seul client. Onyx Infos était littéralement gravé dans le code. Aujourd'hui, la plateforme franchit un cap décisif en devenant une véritable solution multi-tenant, capable de servir plusieurs clients sans refonte majeure. Pascal Repir, qui a piloté cette transformation, détaille les enjeux et les bénéfices de cette refonte architecturale.
Pouvez-vous nous expliquer en quoi consistait le problème initial avec l'architecture de Bizzi ?
Le code de Bizzi avait Onyx Infos hardcodé un peu partout. C'était une architecture monolithique pensée pour un seul tenant. Nous avions des identifiants figés dans le code, comme MARC_AGENT_ID ou DEFAULT_TENANT_ID, et même l'adresse email d'envoi était celle d'Onyx Infos en dur. C'était une approche bricolée, qui fonctionnait pour un cas d'usage unique, mais qui rendait impossible toute évolution vers une plateforme multi-clients. Cette dette technique accumulée constituait un véritable frein à la scalabilité.
Qu'est-ce qui a bloqué pendant longtemps l'adoption d'une architecture multi-tenant ?
Essentiellement la dette technique elle-même. Chaque élément était tellement imbriqué dans les spécificités d'Onyx Infos qu'il aurait fallu une refonte complète pour s'en détacher. Les constantes hardcodées, les chemins de configuration figés, les dépendances implicites — tout cela rendait le code fragile et peu flexible. Il n'y avait pas de contrat clair entre la plateforme et ses clients. C'était du cas par cas, du patch sur patch.
Comment avez-vous résolu ce problème ?
Nous avons mis en place un véritable contrat de configuration basé sur le YAML. Désormais, au lieu d'avoir des valeurs hardcodées, chaque tenant dispose de son propre fichier de configuration qui définit ses paramètres spécifiques. Cela signifie que la plateforme peut supporter n'importe quel tenant sans modification du code source. C'est l'essence même du multi-tenant SaaS : une base de code unique, plusieurs configurations distinctes.
Quel est l'intérêt concret pour des clients comme Lesdemocrates ou Airbizness ?
L'avantage est considérable. Quand on active un nouveau tenant, il n'y a zéro refactorisation à faire. Aucune ligne de code à modifier, aucun déploiement spécifique. Il suffit de remplir un fichier YAML avec les paramètres du nouveau client — ses identifiants, ses adresses email, ses configurations métier — et la plateforme fonctionne immédiatement. C'est une réduction drastique du temps de mise en marché et des risques d'erreur lors de l'onboarding d'un nouveau client.
Cela signifie-t-il que Bizzi est maintenant prête à accueillir de nouveaux clients à grande échelle ?
Oui, c'est exactement le point. Avant cette refonte, chaque nouveau client aurait nécessité une adaptation du code, des tests spécifiques, des déploiements risqués. Maintenant, le processus est standardisé et reproductible. La plateforme peut croître sans que l'équipe technique soit submergée par des demandes de customisation. C'est une vraie transformation du modèle économique : on passe d'une logique de projets à une logique de produit SaaS.
Quels ont été les défis majeurs lors de cette migration ?
Le principal défi a été d'identifier toutes les dépendances implicites — tous les endroits où Onyx Infos était supposé être le client par défaut. Il y en avait beaucoup plus qu'on ne l'imaginait au départ. Il a fallu systématiquement les extraire, les paramétrer, et les tester pour chaque tenant. C'était un travail de fourmis, mais nécessaire pour garantir que la solution fonctionne réellement de manière multi-tenant.
Pensez-vous que cette architecture peut évoluer à l'avenir ?
Absolument. Le YAML offre une flexibilité suffisante pour les besoins actuels, mais on peut imaginer des évolutions — des configurations plus granulaires, des webhooks tenant-spécifiques, ou même une interface de gestion des configurations. L'important est que le fondement soit solide. Maintenant que nous avons un vrai contrat multi-tenant, les améliorations futures seront bien plus simples à implémenter.
Cette refonte marque un tournant pour Bizzi. En éliminant la dette technique et en adoptant une architecture multi-tenant véritablement découplée, la plateforme se transforme d'un outil monolithique en une solution SaaS scalable. Pour les clients comme Lesdemocrates et Airbizness, cela signifie une intégration plus rapide et plus fiable. Pour Bizzi elle-même, c'est l'opportunité de croître sans être entravée par des choix architecturaux du passé. C'est un exemple concret de la manière dont l'investissement dans la qualité technique peut débloquer des opportunités commerciales.