Comment une entreprise exploite une académie pour quinze organisations clientes

Un organisme de formation qui exploite une académie pour quinze organisations clientes exploite seize organisations, pas une. Chaque client veut sa propre marque, son propre domaine, ses propres administrateurs et son propre reporting. L'entreprise, elle, veut un seul endroit où concevoir un cours et une seule vue sur les quinze. Ces deux volontés tirent en sens contraire, et toute la conception tient en une phrase : le contenu descend le long de l'arborescence, les personnes et les résultats ne la traversent jamais latéralement.

Placez cette limite au mauvais endroit et les symptômes sont prévisibles. Soit vous maintenez à la main quinze copies du même cours à chaque changement de réglementation, soit un administrateur client ouvre un rapport et y trouve les collaborateurs d'un autre client. Le premier cas coûte cher. Le second met fin au contrat.

La structure est simple : une organisation parente — l'organisme de formation — et quinze organisations clientes à l'intérieur, chacune libre de contenir ses propres sites ou services.

Training company (parent)      authors everything, sees everything
├── Client 1                   learn.client1.com · own admins · own report
│   ├── Operations
│   └── Retail network
├── Client 2                   academy.client2.io · own admins · own report
├── …
└── Client 15                  academy.client15.co · own admins · own report

Seize nœuds, une installation, un seul cycle de mises à jour. Le schéma est la partie facile. Qui modifie la formation sécurité incendie ? Qui voit les chiffres d'achèvement du client 7 ? Que se passe-t-il quand le client 3 veut un autre seuil de réussite ? Ces trois questions, c'est tout le travail.

Ce qui est partagé et ce qui est séparé

Deux listes. Presque toutes les discussions opérationnelles sur ce sujet sont des désaccords sur la liste à laquelle appartient telle ou telle chose. Partagé vers le bas de l'arborescence, en un seul exemplaire, maintenu par l'organisme :

• Les programmes, les modules et les leçons, conçus une seule fois au niveau du parent.
• La banque de questions et les évaluations qui en sont issues — quinze copies d'une question, c'est quinze occasions pour le corrigé de diverger.
• Les référentiels de compétences, pour que compétent en manutention manuelle veuille dire la même chose dans chaque organisation cliente.
• Les modèles de certificat — la mise en page, les règles de validité, la page publique de vérification.
• Les choses que vous ne voulez jamais voir varier : les règles de conservation, le journal d'audit, le cycle de mises à jour, le travail d'accessibilité.

Séparé latéralement, un par client, jamais mis en commun :

• Les utilisateurs et leur connexion. Une personne appartient à une seule organisation cliente.
• Les inscriptions, la progression, les tentatives, les notes, les certificats délivrés.
• La marque, et le domaine que les collaborateurs d'un client saisissent dans un navigateur.
• Les administrateurs, et les rôles qui leur donnent leurs droits.
• La portée du reporting — chaque chiffre que voit un client est borné par son propre nœud.
• L'adresse depuis laquelle partent les notifications, pour que les relances atteignent les collaborateurs d'un client depuis le domaine du client.
• Les registres de consentement, et tout ce dont le service juridique du client doit répondre.

Reste le milieu inconfortable : les choses qui ressemblent à du contenu mais qui portent l'identité d'un client. Le certificat en est le cas le plus net. La mise en page, la durée de validité et la page de vérification sont à vous ; le logo, le signataire et l'organisation qui y est nommée appartiennent au client. Une plateforme qui traite un certificat comme un objet indivisible vous oblige à dupliquer le modèle quinze fois pour changer un logo. La règle qui vous évite cela : la marque est une configuration posée sur le nœud du client, jamais une copie du contenu. La marque blanche est une surface de configuration, pas une surface de conception.

Concevoir une fois, diffuser à quinze clients

L'organisation parente détient la bibliothèque maîtresse. Un cours y est écrit, relu et publié. C'est ce qui se passe ensuite qui distingue les plateformes, et il n'existe que deux mécanismes.

1. Par référence. L'organisation cliente reçoit un accès au cours du parent. Il n'y a toujours qu'un seul exemplaire : une coquille que vous corrigez atteint donc tous les clients dès la publication. Les inscriptions et les résultats restent dans le nœud du client, parce qu'ils n'ont jamais été partagés.
2. Par copie. Le cours est copié en profondeur dans le nœud du client — modules, leçons, questions, réglages. Le client dispose alors d'un objet distinct qui peut évoluer de son côté, et plus rien de ce que vous faites en amont ne l'atteint. Un vrai programme est un objet volumineux : cette copie s'exécute donc comme une tâche de fond.

La référence est le choix par défaut, et s'en écarter devrait être inconfortable. Dès qu'un cours existe en quinze exemplaires, la mise à jour réglementaire de l'année suivante représente quinze modifications, quinze relectures et quinze occasions d'en oublier une.

Quand un client demande une modification d'un cours partagé

C'est cette demande qui décide du coût de la troisième année. Elle arrive de façon informelle — pouvez-vous ajouter notre procédure de déclaration d'incident au module 3 — et elle appelle quatre réponses honnêtes.

1. C'est une correction. Le contenu est faux, ou périmé, pour tout le monde. Corrigez l'exemplaire de référence et tous les clients l'ont. Plus de demandes qu'on ne le croit relèvent en réalité de ce cas, et le client qui l'a repéré a en général raison.
2. C'est une question de présentation. Ils veulent leur logo, leurs couleurs, leur terminologie. Rien de tout cela n'est du contenu. C'est de la configuration sur leur nœud, et si la plateforme vous oblige à dupliquer un cours pour changer un logo, la faute en revient à la plateforme, pas à la demande.
3. C'est un ajout. Ils veulent quelque chose en plus, pas quelque chose de différent — c'est la réponse que la plupart des organismes manquent. Placez un module propre au client dans sa propre organisation, à côté du programme partagé. Le cours partagé reste partagé, et le client peut souvent entretenir lui-même le support supplémentaire.
4. C'est une vraie divergence. Leur régulateur fixe le seuil de réussite à 80 là où le vôtre est à 70. Là, vous dupliquez — et la copie reçoit une date, un responsable et une ligne dans un registre, parce que dans dix-huit mois quelqu'un demandera pourquoi la version du client 9 diffère, et je crois qu'un client l'avait demandé n'est pas une réponse.

Les accès : leurs administrateurs, leurs personnes, celles de personne d'autre

Un administrateur client a une mission étroite : ajouter et retirer ses propres collaborateurs, les inscrire, relancer ceux qui n'ont pas terminé, et extraire un rapport que son conseil acceptera. Tout cela sans vous écrire, et rien de tout cela en dehors de sa propre organisation.

Ce qui rend cela peu coûteux, c'est une portée qui se propage : attribuez un rôle sur un nœud et il s'applique à tout ce qui est en dessous. Le directeur formation d'un client, c'est une attribution sur l'organisation cliente, et ses services sont inclus automatiquement. Un responsable de site, c'est une attribution sur le site. Quand un service ferme, vous supprimez le nœud au lieu de partir à la chasse aux attributions qui lui ont survécu.

La moitié la plus difficile, ce sont vos propres équipes, pas les leurs. Votre équipe de conception travaille sur les contenus de tous les clients et n'a rien à faire dans les dossiers des apprenants. Le chargé de clientèle des clients 1 à 5 a besoin de leurs résultats et de rien qui vienne des clients 6 à 15. Un rôle d'administrateur unique au niveau du parent donne tout à tout le monde, et c'est ainsi qu'un organisme se retrouve avec une douzaine de personnes capables d'exporter la liste des collaborateurs de n'importe quel client. Des rôles sur mesure construits à partir d'un catalogue de droits, attribués sur le bon nœud, coûtent un après-midi.

Le reporting, des deux côtés

Ce que voit le client

Ses propres personnes et celles de personne d'autre : qui est inscrit, qui a terminé, qui est en retard, qui a échoué deux fois à une évaluation — répartis par ses services, exportables, à sa propre marque. La portée de ce rapport est la même frontière de nœud que celle qui le protège : un seul mécanisme fait donc les deux travaux, au lieu d'un modèle de sécurité et d'un modèle de reporting qui doivent s'accorder.

Ce que vous voyez

Tous les nœuds à la fois. Les chiffres sur lesquels vous pilotez l'activité traversent les clients et sont invisibles depuis l'intérieur d'un client donné : quels clients n'ont inscrit personne depuis six semaines, lesquels approchent du nombre de places prévu au contrat, quel cours échoue partout et relève donc d'un problème de contenu plutôt que d'un problème de client. Ce dernier point est l'argument le plus fort en faveur d'un tenant unique plutôt que de quinze installations séparées, où le même constat est un tableur que quelqu'un reconstruit chaque trimestre, quand il le fait.

La fonctionnalité suivante, tentante, c'est la comparaison : dire au client 4 qu'il se situe dans le premier quartile. Réglez deux choses d'abord. Sur le plan contractuel, savoir si chaque client a accepté que ses résultats agrégés soient comparés à ceux d'autres organisations. Sur le plan technique, un effectif minimal, pour qu'une comparaison portant sur quelques petits clients ne puisse pas être retournée en une affirmation sur l'un d'eux.

Où se situe Lurno, et ce que la structure ne règle pas

Lurno est construit pour cette forme. Une organisation contient des sous-organisations, chacune avec sa propre marque et son propre domaine personnalisé avec TLS automatique, si bien que les collaborateurs d'un client se connectent à l'adresse du client. À l'intérieur d'une organisation, il existe une seconde arborescence de branches pour les sites et les services de ce client, et un rôle attribué sur une branche s'y propage vers le bas. Les contenus sont conçus une seule fois au niveau du parent, puis partagés vers une organisation cliente ou copiés en profondeur dans celle-ci.

La frontière de tenant est appliquée dans Postgres plutôt que dans le code applicatif : 868 politiques de sécurité au niveau des lignes réparties sur 676 migrations. Un point d'entrée qui oublie son filtre ne renvoie rien au lieu des collaborateurs de quelqu'un d'autre — c'est l'affirmation qui mérite d'être testée chez n'importe quel éditeur, le nôtre compris. Une configuration 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.

Quatre choses ne sont pas réglées par une arborescence bien dessinée. Elles sont énoncées ici pour Lurno ; posez les mêmes quatre questions à n'importe qui d'autre.

• Facturer le client. Les paiements et le paiement en ligne sont en cours de développement. Aujourd'hui, un client est facturé en dehors de la plateforme, et la plateforme enregistre ce à quoi il a droit. Cela correspond à la façon dont l'argent circule déjà chez la plupart des organismes, mais le paiement par carte au moment de l'inscription est une conversation, pas une fonctionnalité.
• Faire entrer les personnes. Les comptes sont créés par invitation ; l'inscription en autonomie est en cours de développement. La réponse pratique, c'est un administrateur client qui importe lui-même ses personnes au lieu de vous envoyer un tableur.
• L'authentification. L'authentification partenaire (SSO silencieux) est disponible : le système du client transmet un utilisateur avec une assertion signée. 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 collaborateurs s'authentifient, posez la question à la première réunion plutôt qu'à la cinquième.
• Les standards. SCORM, xAPI et LTI sont modélisés dans le produit, mais le moteur d'exécution est en cours de développement. Un client qui tient à apporter ses propres paquets SCORM est bloqué par ce point, et il faut le dire tôt.

La version côté organisme de ce modèle est exposée sur organismes de formation. La version interne — où les sous-organisations sont vos propres régions plutôt qu'une autre entreprise — est sur entreprise.

La version courte

Partagez le contenu vers le bas de l'arborescence. Séparez latéralement les personnes, les résultats, la marque et le reporting. Référencez un cours partagé plutôt que de le copier, et traitez chaque duplication comme une décision que quelqu'un a signée. Donnez à chaque client un administrateur cantonné à son propre nœud, et vérifiez où cette portée est appliquée. Puis construisez votre propre vue sur les seize nœuds : les questions qui font vivre l'activité — quel client s'est tu, quel cours échoue partout — ne peuvent être posées que depuis le sommet.