Checklist d'isolation des locataires pour prototypes SaaS : éviter les pièges

Pourquoi l'isolation des locataires casse dans les prototypes SaaS

Une fuite de données entre locataires est facile à imaginer : un client se connecte, clique sur « Projets », et voit le nom d'un projet, une facture, un fichier ou la liste d'utilisateurs d'un autre client. Parfois c'est plus discret, comme une suggestion d'autocomplete contenant le contact d'une autre entreprise, ou un total de tableau de bord qui inclut silencieusement des données d'autres comptes.

Cela arrive dans les prototypes parce que « la connexion marche » n'est pas la même chose que « les données sont isolées ». Beaucoup de builds générés par IA ou livrés à la va-vite protègent les pages derrière une authentification, mais n'appliquent pas systématiquement les contrôles de locataire partout où les données sont lues, écrites ou traitées. Un endpoint filtre par user ID, un autre oublie le filtre. Un job d'arrière-plan s'exécute sans contexte locataire. Une clé de cache est partagée. L'interface a l'air correcte, mais les règles sous-jacentes sont inégales.

Quelques façons courantes dont les premières apps multi-tenant fuient des données :

• Endpoints API qui acceptent un ID d'enregistrement et le retournent sans vérifier qu'il appartient au locataire appelant
• Requêtes en base de données oubliant un filtre tenant dans un chemin de code (souvent écrans admin, exports, recherche)
• URLs de stockage d'objets ou chemins de fichier qui ne sont pas scoppés par locataire
• Jobs en arrière-plan qui traitent « tous les enregistrements » au lieu de « ceux du locataire »
• Événements analytics tagués avec le mauvais locataire, mélangeant les rapports entre clients

Le coût d'une petite fuite est rarement petit. La confiance chute vite, la charge support augmente, et le churn suit. Si vous traitez des données personnelles, une fuite peut aussi déclencher des notifications de violation, des problèmes contractuels ou des contraintes de conformité.

Une bonne isolation, pour un fondateur non technique, signifie une promesse claire : les données de chaque client se comportent comme si elles vivaient dans leur propre boîte, même si vous exécutez une seule application. Une checklist d'isolation des locataires pratique doit couvrir tous les endroits où les données peuvent circuler : API, base de données, fichiers, jobs, cache et analytics. Si vous héritez d'un prototype qui « marche en grande partie » mais semble risqué, FixMyMess peut auditer la base de code et pointer où l'isolation casse avant que vous n'embarquez plus de clients.

Principes de multi-tenancy et les frontières à définir

Single-tenant signifie que chaque client a sa propre app ou base de données isolée. Multi-tenant signifie que les clients partagent la même app (et souvent la même base), et votre code doit garantir la séparation. Les prototypes commencent souvent « presque bien » puis cassent silencieusement l'isolation quand une fonctionnalité rapide est déployée.

La première frontière à définir est l'identité du locataire : d'où l'app apprend à quel locataire appartient la requête ? Dans la plupart des apps SaaS, cela doit venir du contexte utilisateur authentifié (token ou session) vérifié par le serveur. Ce ne doit pas être quelque chose que le client peut modifier librement, comme une query string (par ex. ?tenantId=...), un champ du body, ou un header personnalisé.

Les frontières d'isolation à établir tôt

Pensez à l'isolation des locataires comme un ensemble de murs à bâtir à plusieurs endroits :

• Frontière de requête : chaque requête API résout un locataire, une seule fois, côté serveur
• Frontière de données : chaque lecture/écriture est scoppée à ce locataire (pas seulement les lectures)
• Frontière de stockage : les fichiers sont séparés par locataire et l'accès est vérifié côté serveur
• Frontière des jobs : le travail en arrière-plan s'exécute avec un contexte locataire explicite
• Frontière analytics : événements et dashboards ne mélangent jamais les locataires

Si vous construisez une checklist d'isolation des locataires, considérez chaque mur comme obligatoire. En manquer un seul suffit pour provoquer une fuite.

Tables partagées vs bases séparées

Les tables partagées (une base, une colonne tenant_id) se construisent plus vite et coûtent moins cher, mais nécessitent des garde-fous stricts comme un scoping et des contraintes appliqués. Des bases séparées (ou des schémas séparés) réduisent le rayon d'impact et facilitent la conformité, mais ajoutent une surcharge opérationnelle (migrations, reporting, gestion des connexions).

Une règle simple : si vous attendez un petit nombre de locataires à forte valeur avec des exigences strictes, envisagez une séparation physique plus forte. Si vous attendez beaucoup de petits locataires, les tables partagées sont courantes, mais seulement si vous appliquez le scoping partout, pas « la plupart des endroits ».

Où les fuites de données arrivent le plus souvent

La plupart des fuites de données entre locataires dans les prototypes ne viennent pas d'« attaquants ». Elles surviennent quand une erreur honnête transforme une hypothèse single-tenant en bug multi-tenant. C'est pourquoi une checklist d'isolation des locataires porte moins sur des attaques sophistiquées que sur la suppression des pièges évidents.

D'abord, décidez ce qu'est un « locataire » dans votre produit (org, workspace, account). Écrivez-le, mettez-le dans des commentaires de code, et utilisez la même signification partout. Beaucoup de fuites commencent quand l'UI parle de « workspace », l'API de « org », et la base de données de « account_id ».

Les chemins de fuite les plus courants sont ennuyeux mais se retrouvent partout :

• Deviner des IDs et accès direct aux objets : un endpoint charge /invoices/123 sans vérifier que la facture 123 appartient au locataire appelant.
• Requêtes mal scoppées : une requête filtre par user_id mais oublie tenant_id, donc des utilisateurs partageant un domaine d'email ou un rôle voient des lignes en trop.
• Buckets ou dossiers de stockage partagés : les fichiers sont stockés sous des clés prévisibles, et les règles d'accès n'incluent pas le contexte locataire.
• Jobs en arrière-plan sans contexte locataire : un job exécute « send weekly report » pour le mauvais locataire parce que la charge n'incluait pas tenant_id.
• Raccourcis admin et support : endpoints « temporaires », panels de debug, ou exports qui contournent le chemin d'autorisation normal.

Les fuites indirectes sont encore plus faciles à rater car personne ne « voit » les enregistrements bruts. Surveillez les fonctionnalités comme la recherche, l'autocomplete, les dashboards analytics et les exports CSV. Un seul total, top result ou liste « récents » peut révéler qu'un autre locataire a un client nommé X ou un projet appelé Y.

Si vous héritez d'un prototype généré par IA, considérez chaque requête, job et accès stockage comme suspect jusqu'à ce que vous puissiez pointer un contrôle clair de frontière locataire.

Comment appliquer l'isolation dans vos API (pas à pas)

L'isolation des locataires échoue en général dans les API parce que le contexte locataire est géré « parfois » au lieu de « toujours ». L'approche la plus sûre est de traiter le contexte locataire comme l'authentification : une source de vérité unique, appliquée à chaque requête.

Un pattern API répétable

Commencez par décider où le contexte locataire est autoritaire. Choisissez exactement une source : claims du token (courant avec JWT) ou session côté serveur. Tout le reste n'est qu'entrée.

Puis implémentez une garde unique qui s'exécute pour chaque endpoint :

1. Lisez l'utilisateur authentifié et le locataire depuis votre source de vérité choisie.
2. Ignorez tout tenantId venant du client (body, query string, headers). Si vous en avez besoin pour le routage, traitez-le comme un indice et comparez-le au locataire authentifié.
3. Exécutez une vérification d'autorisation cohérente (l'utilisateur appartient au locataire, rôle autorisé pour l'action).
4. Passez le contexte locataire dans les méthodes de service, pas seulement dans les contrôleurs. Évitez les helpers « globaux » qui peuvent s'exécuter sans locataire.
5. Retournez la même forme d'erreur pour « not found » et « not allowed » quand un mismatch de locataire pourrait révéler des données (par exemple, répondre comme si l'enregistrement n'existait pas).

Un exemple concret : un endpoint comme GET /invoices/:id paraît inoffensif, mais si le handler charge Invoice.findById(id) avant de vérifier le locataire, vous pouvez fuir des données en devinant des IDs. La correction consiste à scopper la requête : « trouver la facture par id ET par tenant ». Faites de même pour les mises à jour et suppressions.

Test rapide à deux locataires

Pendant le développement, gardez deux locataires ouverts dans des profils de navigateur séparés. Créez des enregistrements similaires dans les deux, puis essayez de copier-coller des IDs entre locataires. Si quelque chose apparaît, votre checklist vient de trouver un bug réel.

Si vous héritez d'un prototype généré par IA, c'est un mode d'échec fréquent que FixMyMess rencontre en audit : le contexte locataire existe, mais il n'est pas appliqué de manière cohérente sur tous les endpoints.

Isolation en base de données : requêtes, contraintes et garde-fous

La plupart des fuites surviennent parce que la base accepte une requête qui « semble correcte » mais a oublié un filtre. Si vous voulez une checklist pratique, commencez ici : rendez difficile l'exécution d'une requête non scoppée, même par accident.

D'abord, supposez que chaque chemin de lecture sera utilisé pour des listes et de la recherche. Ce sont les endroits où les développeurs écrivent souvent une requête réutilisable et oublient la condition tenant. Une bonne règle : si une table est possédée par un locataire, chaque requête doit inclure tenant_id, y compris les counts, exports, autocompletes et « récents ».

Garde-fous qui attrapent les erreurs

Les vérifications côté appli aident, mais les règles base attrapent les erreurs quand le code change. Ajoutez tenant_id à chaque table possédée par un locataire et appliquez-le par contraintes et index. Par exemple, utilisez des uniques composites comme (tenant_id, email) pour les utilisateurs, et assurez-vous que les clés étrangères incluent le scope tenant (ou validez la correspondance tenant dans des triggers quand les FK composites ne sont pas pratiques).

Garde-fous rapides à ajouter tôt :

• Ajouter tenant_id NOT NULL sur les tables possédées par un locataire.
• Utiliser des index composites commençant par tenant_id pour accélérer les requêtes scoppées.
• Utiliser des contraintes uniques composites pour éviter les collisions inter-locataires.
• Bloquer les fallbacks de « tenant par défaut » en production.

Row-level security (RLS) et tables « globales »

La RLS peut aider quand plusieurs services ou chemins de requête touchent les mêmes tables. Elle fonctionne mieux quand chaque connexion définit un contexte locataire et que vous pouvez la tester de façon fiable. Ce n'est pas un substitut à une bonne autorisation, mais cela réduit le rayon d'impact quand quelqu'un oublie un filtre.

Pour les tables « globales » comme plans ou templates, séparez les données vraiment globales des personnalisations locataires. Un pattern sûr courant : les lignes globales n'ont pas de tenant_id, les personnalisations locataires vivent dans une table différente possédée par le locataire.

Enfin, prévoyez l'accès admin/support. Utilisez un rôle ou endpoint séparé, exigez une sélection explicite du locataire, et journalisez chaque lecture/écriture admin avec qui, quand et quel locataire. Si vous héritez d'un schéma généré par IA où c'est confus, FixMyMess peut auditer les requêtes et contraintes rapidement et montrer où l'isolation peut casser.

Fichiers et stockage d'objets : éviter l'accès croisé accidentel

Les fichiers sont un endroit où les prototypes fuient souvent des données. Le code fonctionne fréquemment avec un bucket unique et un dossier unique, puis casse quand un second locataire téléverse un fichier du même nom ou quand une URL partagée est transmise.

Commencez par une règle : chaque objet stocké a besoin d'une frontière de locataire non ambiguë. Le pattern le plus simple est un préfixe tenant requis dans la clé de stockage (par exemple, tenants/<tenant_id>/...) et l'app doit refuser de lire ou d'écrire quoi que ce soit qui ne correspond pas au locataire courant.

Évitez les buckets publics et les URLs publiques longue durée par défaut. Si vous avez besoin de partage, préférez des URLs signées courtes générées seulement après que votre serveur vérifie l'identité et l'appartenance au locataire. Ne faites jamais confiance à un chemin de fichier ou une clé d'objet fournie par le client.

Vos endpoints de téléchargement et d'aperçu sont les véritables gardiens. Un bug courant : GET /files/:id charge un enregistrement DB par id, puis retourne le fichier, mais la requête oublie WHERE tenant_id = ?. Un filtre manquant devient une fuite inter-locataires. Traitez cela comme partie de votre checklist.

Surveillez aussi les métadonnées. Noms de fichiers, EXIF, propriétés PDF ou champs « uploaded_by » peuvent exposer des noms de locataires, IDs internes ou adresses email quand les fichiers sont partagés.

Un audit rapide à mener aujourd'hui :

• Confirmer que chaque clé d'objet inclut un préfixe locataire et que c'est appliqué côté serveur.
• Vérifier que chaque lookup de fichier inclut tenant_id dans la requête et dans l'autorisation.
• S'assurer que l'accès partagé utilise des URLs signées courtes, pas des objets publics.
• Supprimer ou réécrire les métadonnées sensibles à l'upload (surtout images et PDFs).
• Définir des règles de rétention et de suppression par locataire, et vérifier la suppression complète à l'offboarding.

Si vous héritez d'un prototype généré par IA (Lovable/Bolt/v0/Cursor/Replit), FixMyMess trouve souvent des règles de stockage qui semblent correctes dans le code mais ne sont pas appliquées de façon cohérente en production.

Jobs en arrière-plan et queues : conserver le contexte locataire

Le travail en arrière-plan est l'endroit où l'isolation casse silencieusement. La requête API avait le tenant ID et les permissions, mais une fois que vous déléguez du travail à une queue, ce contexte peut disparaître. Alors un worker récupère un job, s'exécute avec des accès « système », et touche les données du mauvais locataire.

Une règle simple aide : chaque job doit porter son contexte locataire dans la payload lors de sa création. Cela signifie généralement tenant_id plus les identifiants minimaux nécessaires (comme user_id ou invoice_id), et rien qui puisse être « recherché plus tard » sans vérifications.

Ne comptez jamais sur le « current user » dans un worker. Les workers n'ont pas d'utilisateur réellement connecté, et tout état global partagé (comme un utilisateur mis en cache ou un schéma de base par défaut) peut pointer vers le dernier job exécuté. Au lieu de cela, le worker doit explicitement définir le scope locataire au début du job et le valider avant toute opération.

Les retries peuvent aussi causer des fuites. Si un job échoue et est retenté, assurez-vous que la payload de retry inclut toujours le tenant ID et que le worker réapplique le scoping à chaque tentative. Idem pour les dead-letter queues : quand vous inspectez ou rejouez des jobs échoués, le contexte locataire doit rester présent et visible.

Les queues partagées vont bien, mais les logs mixtes par locataire sont risqués. Si votre worker loggue des bodies de requêtes, des erreurs SQL ou des dumps d'objets complets, vous pouvez déverser par accident les données d'un locataire dans des logs que d'autres employés (ou outils) peuvent voir. Logguez avec des tenant IDs et des identifiants courts, pas des enregistrements complets.

Vérifications rapides qui attrapent la plupart des problèmes :

• Créez un job et confirmez que tenant_id est stocké dans la payload et visible dans les logs worker.
• Dans le worker, échouez vite si tenant_id est manquant ou ne correspond pas au locataire de l'enregistrement récupéré.
• Sur retry et dead-letter handling, vérifiez que le scoping locataire est réappliqué et non « mémorisé ».
• Ajoutez des limites par locataire ou une équité de queue pour qu'un locataire bruyant ne prive pas les autres.

Si vous héritez d'un prototype généré par IA, les workers sont souvent l'endroit où le contexte locataire est implicite et dangereux. FixMyMess peut auditer rapidement les chemins de queue et worker et réparer les problèmes d'isolation avant qu'ils ne deviennent incidents.

Cache, sessions et notifications : risques cachés de traversée de locataires

Le caching et les sessions sont faciles à « configurer et oublier » dans les prototypes. C'est pourquoi ils sont une cause fréquente d'échec d'une checklist d'isolation en production. La requête d'un locataire réchauffe le cache, et le locataire suivant reçoit la même réponse.

Un exemple simple : votre API retourne /settings pour l'utilisateur courant. Vous mettez en cache sous la clé settings pendant 5 minutes. Le locataire A l'appelle en premier, puis le locataire B voit le logo, le plan ou l'email de facturation du locataire A. Personne ne vous a « hacké » : c'est juste une clé de cache aveugle au locataire.

Clés de cache, invalidation et objets « partagés »

Faites correspondre l'identité du cache à l'identité des données. Si les données sont scoppées par locataire, le cache doit l'être aussi, y compris l'invalidation.

• Incluez tenant_id (et souvent le rôle utilisateur) dans les clés de cache pour les réponses API.
• Invalidez par locataire quand les données changent, pas seulement par endpoint.
• Faites attention aux caches « globaux » (feature flags, templates) qui contiennent discrètement des champs spécifiques à un locataire.
• Préférez mettre en cache des IDs et vérifier l'accès à la lecture quand les données sont sensibles.

Sessions, notifications et logs

Les sessions peuvent aussi traverser les frontières si vous ne les liez pas fortement. Un token de session doit mapper à un user et un tenant, et chaque requête doit confirmer les deux.

Avant la mise en production, vérifiez ces zones :

• Le stockage des sessions empêche la réutilisation entre locataires (token -> user_id + tenant_id, vérifié à chaque requête).
• Les resets de mot de passe, invitations et magic links incluent le contexte locataire et expirent rapidement.
• Email, SMS et notifications in-app vérifient que le destinataire appartient bien au locataire au moment de l'envoi.
• Les logs ne stockent jamais de secrets (API keys, tokens) ou de données sensibles clientes « pour déboguer ».

Si vous héritez d'un prototype généré par IA, ces problèmes se cachent souvent dans le glue code. FixMyMess peut réaliser un audit rapide pour trouver caches aveugles aux locataires, sessions faibles et chemins de notification non sûrs avant la production.

Exemple : une petite fuite de données et comment elle arrive

Une petite agence et une boulangerie locale s'inscrivent sur le même prototype SaaS. Les deux créent des « clients » dans l'app et utilisent une page de liste simple pour les retrouver.

Le prototype stocke des enregistrements comme clients(id, tenant_id, name, email). L'endpoint API paraît inoffensif : GET /api/clients?search=ann.

Le bug : la requête filtre par terme de recherche, mais oublie le tenant.

Donc l'agence recherche « Ann » et obtient aussi la « Ann Smith » de la boulangerie. Personne ne remarque au début parce que ça n'arrive que quand les noms se chevauchent.

Ça empire dans les endroits qui réutilisent la même requête. Un export CSV récupère « tous les clients correspondants » et inclut des lignes inter-locataires. Un job en arrière-plan qui envoie le « résumé hebdo des clients » utilise la même logique et attache les mauvais enregistrements. Un widget de dashboard compte « nouveaux clients cette semaine » pour tout le monde, donc la boulangerie voit des chiffres gonflés et l'agence voit une baisse inexplicable.

Un correctif rapide consiste à ajouter un filtre tenant à cet endpoint. Ça arrête la fuite immédiate, mais c'est fragile car le prochain endpoint peut répéter l'erreur.

Une vraie correction a généralement deux couches :

• Rendre le scope locataire automatique dans l'API (dériver tenant_id depuis l'utilisateur authentifié, pas depuis les params de requête).
• Ajouter des garde-fous en base (RLS ou contrainte tenant requise) pour que les requêtes non scoppées échouent.
• S'assurer que exports, emails et requêtes analytics utilisent le même chemin d'accès scoppé.

Pour éviter les régressions, gardez un test répétable qui échoue bruyamment : créez deux locataires, insérez un enregistrement portant le même nom dans les deux, appelez l'endpoint de liste en tant que Locataire A, et affirmez que chaque ligne retournée a le tenant_id de Locataire A. Exécutez-le pour l'API et pour le job d'export.

Si vous héritez d'un prototype généré par IA, ce motif est courant. Des équipes comme FixMyMess trouvent souvent la fuite dans un endpoint, puis la tracent jusqu'à des helpers de requête partagés et des jobs en arrière-plan pour la corriger une fois et partout.

Checklist d'audit : vérifications rapides à travers toute la stack

Une checklist d'isolation des locataires est la plus utile quand elle vous force à chercher la même erreur à différents endroits : « tenant id manquant ou ignoré ». Executez cet audit chaque fois que vous ajoutez une nouvelle fonctionnalité, un nouvel endpoint ou une nouvelle tâche en arrière-plan.

Commencez par ces vérifications rapides :

• APIs : le locataire doit être dérivé côté serveur (depuis la session utilisateur, le token, ou le sous-domaine), pas accepté du client comme champ de confiance. Chaque route qui lit ou écrit des données doit appliquer le scope locataire, y compris les endpoints « admin » et internes.
• Base de données : chaque table possédée par un locataire a une clé tenant, et on ne peut pas insérer une ligne sans elle. Les requêtes sont toujours scoppées par locataire, et il existe un garde-fou (contraintes, politiques ou tests) qui échoue bruyamment quand le scope manque.
• Fichiers et stockage d'objets : les chemins sont par locataire (par ex. préfixe tenant), l'accès est signé ou autrement restreint, et le mode « public par défaut » est désactivé. Ne comptez pas sur l'UI pour masquer les fichiers d'autres locataires.
• Jobs en arrière-plan : les jobs portent le contexte locataire explicitement, le valident avant de démarrer, et loggent de façon sûre (pas de secrets, pas de données clients brutes). Les retries ne doivent pas perdre le contexte locataire.
• Analytics et exports : les événements incluent des identifiants locataires, les dashboards sont filtrés par locataire, et les exports (CSV, emails, « download all ») ne peuvent pas contenir les données d'autres locataires.

Test smoke de 10 minutes

Créez deux locataires : « Acme » et « Beta ». Créez un enregistrement dans chacun (un utilisateur, une facture, un fichier, et un événement analytics). Puis tentez des attaques simples : changez un ID dans une URL, rejouez un appel API en étant connecté dans l'autre locataire, ou lancez un export depuis chaque locataire.

Si vous trouvez une lecture cross-tenant, traitez-la comme un blocage de production. Les équipes demandent souvent à FixMyMess un audit d'isolation rapide sur des prototypes générés par IA parce que ces lacunes se cachent dans des routes copiées-collées, des handlers de jobs, et des écrans admin « temporaires ».

Pièges multi-tenant courants à éviter

La plupart des fuites multi-tenant ne viennent pas d'une grosse erreur unique. Elles viennent de petits raccourcis qui semblent inoffensifs dans un prototype, puis sont déployés en production.

Pièges qui causent de vraies fuites

Surveillez ces motifs quand vous exécutez la checklist :

• Accepter un tenantId depuis l'UI, la query string ou le body, puis l'utiliser directement dans les requêtes. Le serveur doit dériver le contexte locataire depuis l'utilisateur authentifié ou le token, pas depuis l'entrée utilisateur.
• Sécuriser les endpoints CRUD principaux mais oublier les routes « secondaires » comme recherche, count, export, autocomplete et handlers de webhooks. Ils interrogent souvent des tables plus larges et sont faciles à manquer.
• Garder un endpoint admin partagé en supposant qu'il est sûr parce qu'il n'est pas exposé dans l'UI. Sans vérifications de rôle strictes et un scope locataire clair, il devient une porte dérobée universelle.
• Utiliser le caching pour des endpoints de liste sans clé de cache consciente du locataire. Une réponse mise en cache peut être servie à plusieurs locataires, surtout quand pagination et filtres interviennent.
• Laisser analytics mélanger les locataires, puis traiter les dashboards comme source de vérité. Une fois les données mélangées dans les rapports, les décisions s'appuient dessus et il est difficile de nettoyer.

Un exemple simple : votre API scoupe correctement /invoices par locataire, mais /invoices/export vérifie seulement « est connecté » et exécute une requête large. Un client clique sur Export et reçoit des lignes d'autres entreprises.

Si vous héritez d'un prototype généré par IA, ces problèmes apparaissent souvent parce que le code est dupliqué et « presque le même » à travers les routes. FixMyMess voit souvent un endpoint mis à jour avec le scoping locataire tandis que trois endpoints similaires fuient encore.

Une bonne règle : chaque requête, chaque requête SQL, chaque entrée de cache et chaque événement doit porter explicitement le contexte locataire, et échouer fermé quand il manque.

Étapes suivantes : durcir l'isolation avant la mise en production

Avant d'embarquer de vrais clients, décidez comment vous allez corriger l'isolation : patcher le prototype existant, ou reconstruire seulement les parties risquées (auth, couche d'accès aux données, jobs). Le patch est plus rapide quand l'architecture est globalement saine. Reconstruire est plus sûr quand les vérifications locataires sont dispersées dans le code, ou quand l'app mélange « qui est l'utilisateur » et « à quel locataire il appartient ».

Une façon pratique d'avancer est de traiter l'isolation comme un blocage de release et d'ajouter un petit plan de régression que vous pouvez lancer chaque fois que vous changez quelque chose de sensible. Même un simple « suite de test à deux locataires » attrape la plupart des fuites.

Plan simple d'une heure pour durcir

Travaillez ces étapes dans l'ordre :

• Choisissez deux locataires de test (Locataire A et Locataire B) et créez des données identiques dans les deux.
• Parcourez vos flux principaux en étant connecté en Locataire A et tentez d'accéder au Locataire B en changeant des IDs dans l'URL, le body de requête et les filtres.
• Déclenchez les jobs en arrière-plan (emails, exports, webhooks) et confirmez qu'ils touchent uniquement le locataire correct.
• Vérifiez les clés object storage et les URLs signées pour s'assurer qu'elles sont scoppées par locataire.
• Vérifiez que les événements analytics incluent le contexte locataire et ne peuvent pas être interrogés globalement par défaut.

Planifiez un audit court d'isolation juste avant le lancement. L'objectif n'est pas la perfection, mais la confiance que vos chemins les plus à risque sont couverts et que votre « checklist d'isolation des locataires » est réellement appliquée par le code, pas seulement par des conventions.

Si votre prototype a été généré par des outils comme Lovable, Bolt, v0, Cursor ou Replit, partez du principe que les frontières locataires n'ont pas été conçues soigneusement. FixMyMess peut exécuter un audit de code gratuit pour cartographier où le contexte locataire est perdu, puis durcir l'auth, l'accès aux données et la préparation au déploiement pour que vos premiers vrais clients ne deviennent pas votre banc d'essai.