Aller au contenu
T.E.N.E.G.T.A
Langue
All case studies

Technologie financière · Plateforme SaaS d'entreprise — du pilote avec 3 clients à la production avec 40+ institutions

Du pilote à la production : concevoir un SaaS pour une vraie mise à l'échelle

Comment nous avons re-architecturé une plateforme d'entreprise passée de 3 à 40+ clients en 6 mois — réduisant la latence p95 de 60 % et activant une cadence de 12 déploiements/mois.

10 min read

Problem

La plateforme fonctionnait correctement avec 3 clients pilotes. Mais quand l'équipe a essayé de la mettre à l'échelle pour 40+ institutions, les vrais problèmes ont émergé : - Chaque nouveau client nécessitait des modifications manuelles du code (configurations en dur) - Le schéma de base de données partagé faisait fuir des données entre tenants dans des cas limites - Les temps de réponse augmentaient de façon non linéaire avec la charge - L'équipe de 8 développeurs passait 40 % de son temps en déploiement manuel et correction d'environnements différents Le code "fonctionnait" — mais il n'était pas conçu pour la croissance.

What we built

Nous avons commencé par un "Audit d'Architecture" honnête — sans vendre de solution avant de comprendre la cause profonde. Lors des deux premières semaines, nous avons cartographié chaque dépendance et chaque point faible. Première décision stratégique : ne pas réécrire from scratch. Améliorer ce qui existe de façon incrémentale sans arrêter la production. Plan en 3 phases : 1. **Isolation** — séparer les données des tenants de manière sécurisée (Row-Level Security + schema-par-tenant pour les clients sensibles) 2. **Performance** — réécrire les requêtes N+1, cache Redis, connection pooling 3. **Automation** — pipeline CI/CD complet, Infrastructure as Code, onboarding d'un tenant en moins de 10 minutes

Outcome

En 6 mois : passage de 3 à 40+ institutions sur une plateforme, latence p95 réduite d'environ 60 %, et 12 déploiements production par mois sans interruption — isolation des tenants vérifiée en tests.

Architectural decisions

  • Row-Level Security plutôt que filtrage au niveau application

    Le filtrage applicatif peut être contourné par un seul bug. Le RLS dans la base de données rend les fuites de données impossibles même en cas d'erreur dans le code — car la base de données elle-même impose les limites.

  • Développement trunk-based + Feature Flags

    L'ancienne façon : branches longues causant le merge hell. La nouvelle : toute l'équipe écrit sur un trunk avec des feature flags contrôlant l'activation — permettant 12 déploiements/mois sans chaos.

  • Observabilité d'abord — pas monitoring

    Le monitoring vous dit qu'il y a un problème. L'observabilité vous dit pourquoi. Nous avons déployé OpenTelemetry sur tout le stack — traces, métriques, logs en un seul endroit — car debugger en multi-tenant sans observabilité, c'est creuser dans le noir.

Technical challenges

  • Migration des données de 3 clients existants vers le nouveau schéma sans interruption

    Nous avons utilisé le pattern Expand-Contract Migration : ajouté le nouveau schéma à côté de l'ancien, écrit dans les deux pendant la transition, puis basculé après vérification — sans arrêter la production.

  • Certains clients entreprise refusant les données partagées même avec RLS

    Nous avons construit un modèle hybride : schema-par-tenant pour ceux nécessitant une isolation complète, schema partagé + RLS pour les autres — les deux tournant sur le même codebase avec une seule configuration.

Architecture

Node.jsTypeScriptPostgreSQLPrismaRedisDockerKubernetesGitHub ActionsOpenTelemetryGrafanaTerraformNext.js

Results

−60%

Réduction de la latence p95

12×

Cadence de déploiement mensuelle

< 10 min

Temps d'onboarding d'un nouveau tenant

6 months

Passage pilote à production

Je craignais que 're-architecturer' signifie 'retard d'un an'. T.E.N.E.G.T.A a prouvé qu'une bonne re-architecture ne vous ralentit pas — elle vous libère.
Directeur technique Plateforme SaaS d'entreprise

Representative quote for discussion — composite scenario, not a named client endorsement unless stated otherwise.

These case studies are illustrative summaries for discussion. They are not guarantees of results for your organization unless confirmed in a separate agreement.