Plusieurs projets, une seule équipe : accès et facturation quand la localisation dépasse une application

La plupart des installations de localisation commencent simplement : une application, un projet, trois personnes qui se connaissent toutes. Rien dans cet article ne s’applique à cela, et si c’est là que vous en êtes, la suite est prématurée.

Cela change avec la deuxième application. Puis viennent un client mobile, un site marketing, un portail client, un outil d’administration interne. Chacun est légitimement un projet à part : son rythme de livraison, ses langues, son plan. Et quelque part entre le deuxième et le cinquième, le travail cesse d’être de la traduction et devient de l’administration.

Ce qui casse vraiment quand le deuxième projet arrive

Les mêmes invitations, encore et encore. Huit collègues, cinq projets, quarante invitations, et chaque nouvelle recrue répète le rituel. C’est pénible plutôt que dangereux, et c’est précisément pour cela que personne ne le corrige avant qu’autre chose ne tourne mal.

L’offboarding devient un jeu de mémoire. Quelqu’un quitte l’entreprise, ou passe dans une équipe qui n’a plus rien à voir avec le portail. La question devient : à quels projets cette personne a-t-elle été ajoutée un jour ? Si la réponse ne vit que dans la liste d’utilisateurs de chaque projet, retirer l’accès revient à se souvenir de tous les projets existants, et le prix d’un oubli est une personne qui modifie encore vos textes en production des mois plus tard. C’est le moment où un désagrément administratif devient un constat de sécurité.

La facture se fragmente. Cinq projets, cinq abonnements, cinq dates de renouvellement, cinq justificatifs à rapprocher. La comptabilité demande pourquoi une entreprise paie cinq fois un prestataire de localisation, et la réponse honnête est que l’outil n’avait aucune notion d’entreprise.

Les externes obtiennent plus d’accès que prévu. La traductrice indépendante a besoin de l’italien sur le site marketing. Le chemin le plus court lui donne un rôle qui va plus loin que cela, parce que restreindre projet par projet demande du travail. Multipliez par chaque prestataire et chaque contact d’agence sur quelques années.

Personne ne peut dire qui a accès à quoi. Non pas parce que la donnée manque, mais parce qu’elle est répartie sur N listes d’utilisateurs sans aucun endroit qui les agrège. La première fois que cette question est posée sérieusement, elle vient en général d’un auditeur, d’un questionnaire de sécurité client, ou d’un incident.

Pourquoi les contournements habituels ne tiennent pas

Un grand projet avec des namespaces. Tentant, parce que cela dissout le problème administratif instantanément. Cela dissout aussi tout ce pour quoi vous aviez séparé les applications : un namespace est une tranche de contenu à l’intérieur d’un projet, il partage donc ses versions, sa publication, son plan et ses règles d’accès. Deux produits livrés des jours différents ne peuvent pas partager un rythme de livraison, et "le stagiaire peut modifier le texte marketing mais pas le tunnel de paiement" ne s’exprime pas dans une structure où les deux sont des namespaces de la même chose.

Un identifiant partagé. Il règle le problème des invitations en détruisant la traçabilité, rend l’authentification à deux facteurs vide de sens, et transforme chaque départ en rotation de mot de passe. Il apparaît plus souvent que personne ne l’admet.

Un tableur de qui a quoi. Correct le jour où il est écrit. Dès qu’un accès est accordé quelque part sans que le tableur soit mis à jour, il est pire que rien, car c’est désormais un document qui affirme quelque chose de faux avec assurance.

À quoi la structure devrait ressembler

Le motif qui tient est une couche compte placée au-dessus des projets, qui possède les deux choses qui sont des faits sur l’entreprise et non sur une application : les personnes et la facture. Quatre propriétés la font fonctionner.

Une équipe, héritée dans chaque projet. Vous invitez un collègue une fois, sur le compte, avec le rôle qu’il doit avoir dans toute l’entreprise. Il apparaît dans chaque projet de ce compte avec ce rôle. On accorde à un endroit, on retire à un endroit. C’est ce qui fait de l’offboarding une action unique plutôt qu’une recherche.

Deux sortes de rôles, et un seul est hérité aveuglément. Les rôles qui pilotent le compte (administration et facturation) appartiennent au compte et portent partout par définition. Les rôles de travail (gérer, publier, traduire) sont hérités eux aussi, mais un projet doit pouvoir dire "pas cette personne ici" : la restreindre à une seule langue sur ce projet, ou la bloquer entièrement. Sans cette exception, une équipe héritée est trop grossière pour être utilisée, et les équipes reviennent aux invitations projet par projet.

Les externes restent sur le projet. L’équipe du compte est faite pour vos propres collaborateurs. Une traductrice indépendante ou un contact d’agence reçoit une permission sur exactement le projet où elle travaille, et ne voit jamais que le reste du compte existe. Cette seule règle est ce qui garde l’héritage sûr : tout ce qui figure dans l’équipe du compte est délibérément valable pour toute l’entreprise, donc tout ce qui ne doit pas l’être n’y figure pas.

Un compte, un abonnement, une facture. Chaque projet se facture dans son compte. Quand un département a réellement besoin de sa propre facture, de son propre moyen de paiement ou de son propre ensemble de personnes, ce département est un deuxième compte et non un cas particulier dans le premier. Vouloir exprimer deux factures dans un seul compte, c’est le point où ces modèles deviennent en général quelque chose que plus personne ne sait démêler.

Par-dessus cela, quelques éléments n’ont de sens qu’au niveau du compte : le single sign-on (un fournisseur d’identité est un fait sur l’entreprise, pas sur une application), l’authentification à deux facteurs imposée, et un journal d’audit de ce qui a été accordé et retiré à qui. Les configurer par projet est à la fois du travail répétitif et un bon moyen de finir avec cinq postures de sécurité différentes dans une même entreprise.

Comment cela fonctionne dans Locize

C’est la forme des organisations dans Locize, et la raison pour laquelle nous les avons construites.

Votre organisation est la couche compte. Vous en obtenez une automatiquement avec votre premier projet, nommée d’après votre entreprise, et vous pouvez la renommer à tout moment. Tout ce qui précède décrit son comportement :

• L’équipe vit sur la page de l’organisation. Les membres sont invités une fois et héritent dans chaque projet, avec un badge "via organization" dans la liste d’utilisateurs de chaque projet, pour toujours distinguer un accès hérité d’un accès direct. Une permission directe sur un projet l’emporte pour les rôles de travail : vous pouvez donc restreindre ou bloquer quelqu’un sur un seul projet, et "inherit" le rend à la règle de l’organisation. Détails dans la gestion des utilisateurs.
• Admin et comptable n’existent que sur l’organisation. Les permissions de projet plafonnent à manager. C’est ce qui rend l’histoire de l’offboarding vraie : il n’existe aucun moyen d’accumuler un pouvoir valable dans toute l’entreprise projet après projet.
• La facturation appartient à l’organisation. Le premier projet qui souscrit crée l’abonnement, et chaque projet suivant le rejoint : une facture, alors que chaque projet garde son plan et ses limites. Le partage de facture est inclus à partir du plan Growth.
• Une facture séparée est une organisation séparée. Vous pouvez en créer une directement depuis le formulaire d’ajout de projet, et déplacer un projet existant avec un code de transfert à usage unique : l’admin qui reçoit voit quel projet arrive et de la part de qui avant de confirmer. Les tenants et les branches suivent automatiquement leur projet parent (multi-tenant).
• Le SSO est facturé une fois par abonnement, quel que soit le nombre de projets qui l’utilisent. L’authentification à deux facteurs imposée se règle pour toute l’organisation, et un projet peut la renforcer mais jamais l’affaiblir. Les admins d’organisation peuvent télécharger le journal d’audit des changements de membres et d’invitations, sur les plans qui l’incluent.

Si vous utilisiez déjà la facturation collective, rien de tout cela ne vous a rien demandé : votre groupe de facturation est devenu votre organisation, ses admins sont devenus admins de l’organisation, chacun a gardé les projets qu’il avait, et la facture est restée identique ou est devenue légèrement moins chère, puisque le SSO est désormais facturé une fois par abonnement au lieu d’une fois par projet.

Quand vous n’avez besoin de rien de tout cela

Une application, une ou deux personnes, pas de traducteurs externes, pas de questions de conformité : laissez tel quel. Un projet unique avec quelques permissions directes est la structure correcte, et ajouter une couche compte par-dessus n’apporte rien. Les signaux qu’il est temps sont concrets et vous les reconnaîtrez : le troisième projet, la première personne à retirer de plusieurs projets à la fois, la première question de la comptabilité sur la facture, le premier questionnaire de sécurité qui demande comment l’accès est accordé et retiré, ou le premier prestataire à qui vous avez dû donner plus d’accès que vous ne le vouliez.

L’intérêt de la couche compte n’est pas qu’elle gère vos traductions. C’est qu’elle empêche l’administration autour d’elles de grandir avec chaque produit que vous livrez.

Si plusieurs de ces signaux vous parlent, le plus rapide est de regarder votre propre installation : la page de l’organisation liste chaque projet, qui y accède et ce qu’il coûte sur la période. Commencez gratuitement avec Locize, ou lisez d’abord la documentation des organisations si vous préférez voir le modèle avant le produit.