Portails, sous-comptes et organisations imbriquées : la question du multi-tenant pour les organismes de formation

Quand un organisme de formation remporte un client qui veut sa propre académie à sa marque, l'architecture de la plateforme en dessous décide si c'est un après-midi de paramétrage ou un projet de six semaines. Trois choses différentes sont vendues sous le nom de multi-tenant : les portails, les sous-comptes, et les organisations réellement imbriquées. Seule la troisième donne à un client son propre domaine, ses propres administrateurs, ses propres rapports, et une frontière de données qui tient encore quand un développeur oublie un filtre.

La distinction se lit comme une anecdote d'éditeur jusqu'au jour où un client demande quelque chose que le modèle ne sait pas exprimer. Elle devient alors un problème commercial, parce que ce que vous pouvez vendre est borné par ce que vous pouvez séparer.

Ce qu'un client demande réellement

Dépouillez le cahier des charges et il reste quatre demandes. Elles arrivent à peu près dans cet ordre, et presque tous les clients qui vous paient pour former leurs collaborateurs les formulent.

1. Leur propre domaine. `learn.acmecorp.com`, pas `votreentreprise.editeur-lms.com/acme`. Avec un certificat qui ne fait pas râler le navigateur.
2. Leurs propres administrateurs. Quelqu'un côté client qui puisse ajouter des utilisateurs, publier un cours et extraire un rapport sans vous écrire d'abord.
3. Leurs propres rapports. Des chiffres sur leurs collaborateurs et personne d'autre, dans une forme qu'ils puissent présenter à leur propre conseil.
4. Leurs données séparées de celles des autres clients. Posée en général comme une question de sécurité, toujours celle que le service achats fait remonter.

Chaque architecture répond à certaines de ces demandes et échoue sur d'autres. Les échecs sont prévisibles dès qu'on sait sur quel modèle on se tient.

Trois architectures, trois plafonds

Les trois modèles ci-dessous ne forment pas une échelle de maturité. Ce sont des produits différents pour des acheteurs différents, et chacun a un point précis où il s'arrête.

Les portails

Un portail est une porte d'entrée distincte sur un même stock de contenus et d'utilisateurs. Vous définissez une audience — salariés, partenaires, une entreprise cliente —, vous lui donnez une URL et un thème, et vous y affectez des personnes. Plusieurs plateformes d'entreprise sont construites sur cette forme ; LearnUpon en est l'exemple le plus net, avec la diffusion multi-portails au cœur du produit.

Les portails répondent bien à la première demande. Un client obtient une porte d'entrée qui ressemble à la sienne, et les apprenants qui s'y connectent ne voient jamais les autres audiences. Pour une entreprise qui forme des salariés, des partenaires et des clients depuis un seul compte, c'est souvent la bonne dose de structure.

La liste des portails est plate, et c'est là que cela s'arrête. Un client avec trois régions et un directeur formation au niveau du groupe n'est pas un portail, et ce n'est pas non plus trois portails sans lien entre eux. Les organismes qui restent sur un modèle plat finissent par encoder la hiérarchie manquante dans les noms — `Acme`, `Acme - EMEA`, `Acme - APAC` — puis par reconstituer la vue groupe à la main dans un tableur chaque trimestre. Les rôles d'administrateur ont le même problème : les droits sont accordés par portail, si bien que le directeur groupe reçoit trois attributions que personne ne pense à révoquer quand une région ferme.

Les sous-comptes

Les sous-comptes viennent en général du système de facturation plutôt que du modèle de données. Un compte payeur possède des comptes enfants, normalement sur un seul niveau, qui partagent une table d'utilisateurs, un abonnement et souvent un domaine unique avec un chemin par enfant. TalentLMS reconnaît franchement qu'il s'agit là d'une séparation plus légère qu'un multi-tenant complet avec domaines personnalisés par tenant, et pour une petite équipe qui forme ses salariés, cette légèreté est une qualité, pas un défaut.

La question qui mérite d'être posée est celle du lieu où la frontière est appliquée. Si un sous-compte est une colonne sur une ligne, alors la séparation vaut ce que le code applicatif pense à filtrer.

-- A boundary that lives in application code
select * from enrolments where account_id = :current_account;

-- A boundary that lives in the database
create policy tenant_read on enrolments
  for select using (org_id = any (current_org_scope()));

La première requête est correcte jusqu'au moment précis où quelqu'un construit un nouveau point d'export et oublie la clause `where`. La seconde reste correcte quand même, parce que la base de données refuse de renvoyer les lignes. C'est cet écart que le service achats cherche à tâter quand il demande comment les données des clients sont tenues à part, même lorsqu'il le demande dans le vocabulaire des certifications et des audits.

Les organisations imbriquées

Dans le troisième modèle, l'organisation est un enregistrement de première classe, et une organisation peut avoir un parent. Marque, domaine, utilisateurs, rôles, contenus, inscriptions et rapports y sont tous rattachés. Votre organisme de formation est une organisation. Chaque client est une organisation à l'intérieur de la vôtre. Les régions du client sont des organisations à l'intérieur de la sienne, aussi profond que descend sa structure réelle.

Your training company              you administer everything below
├── Acme Corp                      learn.acmecorp.com
│   ├── Acme EMEA                  regional admin, EMEA data only
│   └── Acme APAC
├── Borden Group                   training.bordengroup.com
│   └── Borden Manufacturing
└── Public catalogue               open enrolments, your brand

Deux conséquences en découlent, qu'un modèle plat ne peut pas vous donner. La première, c'est que la forme propre d'un client est représentable sans convention de nommage : vous n'encodez pas la hiérarchie dans des chaînes de caractères. La seconde, c'est la portée : un rôle attribué sur un nœud s'applique à tout ce qui est sous ce nœud. Le directeur formation d'Acme voit Acme et les deux régions. Le responsable EMEA voit EMEA. Vous voyez l'ensemble. Personne chez Borden n'en voit rien, et rien de tout cela n'est un rapport que quelqu'un a rédigé à la main.

Cela change aussi ce que veut dire la sortie d'un client. Quand un client quitte un système plat, quelqu'un déroule une liste de portails, d'utilisateurs, de groupes et de rapports en espérant qu'elle est complète. Quand un client est un sous-arbre, vous supprimez le sous-arbre, et tout ce qui y était rattaché part avec lui.

Comment chaque modèle répond aux quatre demandes

• Leur propre domaine. Portails : en général oui, un par portail, parfois moyennant un surcoût. Sous-comptes : souvent un chemin ou un sous-domaine du domaine de l'éditeur plutôt que celui du client. Organisations imbriquées : un domaine par organisation, à n'importe quelle profondeur, si la plateforme émet les certificats automatiquement.
• Leurs propres administrateurs. Portails : oui, mais cantonnés au portail concerné, si bien qu'un administrateur au niveau du groupe a besoin d'une attribution par portail. Sous-comptes : en général les administrateurs du parent avec une vue filtrée. Organisations imbriquées : un administrateur sur n'importe quel nœud, avec des droits qui se propagent à tout ce qui est en dessous.
• Leurs propres rapports. Portails : par portail, avec des consolidations inter-portails variables selon le produit. Sous-comptes : typiquement un rapport avec un filtre, ce qui convient très bien jusqu'à ce qu'un client demande à le consulter lui-même. Organisations imbriquées : chaque nœud est une portée de reporting, si bien que la vue groupe et la vue régionale sont la même requête à des hauteurs différentes.
• Leurs données séparées. Portails et sous-comptes : aussi séparées que le code applicatif les rend. Organisations imbriquées : aussi séparées que la plateforme l'applique en dessous de l'application — demandez précisément si la règle se trouve dans la base de données.

Rien de tout cela ne rend les portails mauvais. Cela en fait un produit différent pour un acheteur différent. L'erreur, c'est d'acheter un modèle à portails parce que la démonstration montrait un changement de logo, et de découvrir le plafond le jour où vous signez un client qui a des régions.

Cinq questions à poser à un éditeur

1. Une organisation peut-elle en contenir une autre, et jusqu'à quelle profondeur ?
2. Si j'attribue à quelqu'un un rôle d'administrateur sur un nœud, s'applique-t-il à tout ce qui est en dessous, ou dois-je l'attribuer de nouveau à chaque niveau ?
3. La frontière de tenant est-elle appliquée dans la base de données ou dans le code applicatif ?
4. Chaque client peut-il avoir son propre domaine et son propre certificat, ou seulement un sous-répertoire du vôtre ?
5. Quand un client s'en va, qu'est-ce que sa suppression efface exactement — et pouvez-vous me le montrer ?

Demandez les réponses dans un document partagé plutôt qu'au téléphone. La deuxième question en particulier a tendance à produire la démonstration d'un écran plutôt qu'une réponse, et l'écart entre les deux vaut un an d'attributions manuelles.

Pourquoi la réponse décide de ce que vous pouvez vendre

Si votre plateforme ne sait habiller qu'une seule porte d'entrée, vous vendez des accès sur votre système. Les salariés du client se connectent à votre marque, le responsable formation du client vous réclame des chiffres, et chaque renouvellement est une conversation sur le coût par utilisateur de votre plateforme.

Si vous pouvez remettre à un client un domaine, des administrateurs, des rapports et une frontière qui survit à une revue de sécurité, vous lui vendez sa propre académie. C'est un autre contrat. Il se renouvelle autrement, parce qu'à ce stade le client a ses propres administrateurs avec leurs propres habitudes et ses propres contenus à l'intérieur, et il survit à un changement d'interlocuteur de son côté.

L'autre moitié est opérationnelle. Les organismes qui dépassent un modèle plat finissent souvent par exploiter une installation par client. Moodle est explicite : le multi-tenant ne fait pas partie du produit de base — séparer des campus ou des organisations clientes suppose Moodle Workplace, un contrat avec un partenaire, ou des installations parallèles. Des installations parallèles, ce sont des mises à jour parallèles, des sauvegardes parallèles, des correctifs de sécurité parallèles et une couche de reporting que vous reconstruisez en dehors de la plateforme. Cela fonctionne tant que vous avez plus de collaborateurs que de clients.

Où se situe Lurno

Lurno est construit sur le troisième modèle. Une organisation peut contenir des sous-organisations, chacune avec sa propre marque et son propre domaine personnalisé avec TLS automatique. À l'intérieur d'une organisation, il existe une seconde arborescence de branches, et un rôle attribué sur une branche se propage vers le bas — ce qui est la réponse à la deuxième question ci-dessus, et la raison pour laquelle un directeur formation groupe représente une attribution et non une par région.

La frontière est appliquée dans Postgres plutôt que dans l'application : 868 politiques de sécurité au niveau des lignes réparties sur 676 migrations, si bien qu'un filtre manquant dans un nouveau point d'entrée ne renvoie rien au lieu de renvoyer les apprenants de quelqu'un d'autre. C'est l'affirmation qui mérite d'être vérifiée chez n'importe quel éditeur, y compris le nôtre — les détails sont sur la page sécurité, et le volet marque et domaines sur marque blanche.

Deux configurations que cela fait déjà tourner, sans nommer personne : une académie d'entreprise qui assure la formation de 15 entreprises clientes depuis un seul tenant, et un éditeur K-12 qui exploite 114 établissements sur une seule plateforme. Les deux sont la même structure à des largeurs différentes.

Deux limites à énoncer clairement, parce qu'elles changent l'évaluation. Les paiements et le paiement en ligne sont en cours de développement — aujourd'hui, un client est facturé en dehors de la plateforme ; donc si vous avez besoin que les apprenants paient par carte au moment de l'inscription, c'est une conversation et non une fonctionnalité. Et l'authentification partenaire (SSO silencieux) est disponible, mais SAML et OIDC sont sur la feuille de route et ne sont pas livrés ; si la DSI d'un client a déjà décidé comment ses salariés s'authentifieront, posez la question avant toute autre chose. Le reste du modèle pour les organismes qui revendent de la formation est exposé sur la page organismes de formation.

La version courte

Les portails donnent à un client une porte d'entrée. Les sous-comptes donnent à un client une vue filtrée. Les organisations imbriquées donnent à un client une frontière, et une frontière est la chose sur laquelle on peut mettre un prix. Déterminez lequel vous achetez avant qu'un client ne vous demande la chose que votre modèle ne sait pas dire.