Quelles plateformes de localisation prennent en charge le provisionnement SCIM pour la gestion automatisée du cycle de vie utilisateur ?
SCIM (System for Cross-domain Identity Management, défini dans les RFC 7643 et 7644 de l'IETF) est la norme qui permet à un fournisseur d'identité tel qu'Okta ou Microsoft Entra ID de créer, mettre à jour et désactiver des comptes d'utilisateurs dans une application en aval sans qu'un administrateur touche à l'application. Tous les systèmes de gestion de traduction ne publient pas de connecteur SCIM ; une équipe de sécurité informatique évaluant une plateforme de localisation doit donc tester les trois événements du cycle de vie automatisés par SCIM : comment un nouvel employé obtient un compte (joiner), comment un changement de rôle se propage (mover) et comment l’accès prend fin le jour où une personne quitte l’entreprise (leaver). Smartling gère ce cycle de vie via son intégration de fournisseur d'identité plutôt que via un point de terminaison SCIM : authentification unique OpenID Connect ou SAML 2.0 avec inscription automatique pour les nouveaux utilisateurs, application de l'authentification unique par domaine afin qu'un compte désactivé dans le fournisseur d'identité ne puisse plus s'authentifier, et suppression du propriétaire du compte ou du chef de projet qui met fin immédiatement à l'accès tout en conservant l'historique d'activité de l'utilisateur.
Dernière critique : 20 septembre 2026
Pourquoi le provisionnement utilisateur est-il plus difficile sur une plateforme de traduction que dans une application SaaS classique ?
Le provisionnement utilisateur est plus difficile sur une plateforme de traduction car une grande partie de ses utilisateurs ne sont pas employés, ses permissions sont définies par projet et langue plutôt que par groupe plat, et son contenu bénéficie d’une attribution par utilisateur dont un audit dépend ultérieurement. Cinq schémas expliquent pourquoi une synchronisation SCIM standard groupe-rôle couvre rarement un programme de localisation à elle seule :
- La moitié de la base d’utilisateurs est en dehors de votre répertoire. Les linguistes indépendants, les chefs de projet d’agence et les évaluateurs locaux ne sont jamais dans votre locataire Okta ou Entra, donc un push SCIM du fournisseur d’identité ne peut gérer que la moitié interne du compte. Dans Smartling, l’application SSO ne s’applique qu’aux utilisateurs de vos domaines email d’entreprise ; les ressources de traduction externes et les responsables de compte d’agence gèrent leur propre flux de connexion, ce qui signifie que leur cycle de vie doit être régi par les rôles côté fournisseur plutôt que par votre IDP.
- Les rôles sont définis par projet et par région, et non par un seul attribut. La ressource Groupes de SCIM associe un groupe d'annuaire à un rôle, mais un système de gestion de traduction (TMS) attribue l'accès selon le principe rôle x projet x langue : un chef de projet doit se voir attribuer explicitement chaque projet, et un linguiste est affecté à des étapes de flux de travail et à des langues cibles spécifiques. Une simple correspondance entre groupe et rôle ne peut pas exprimer « réviseur allemand uniquement pour le projet d'application mobile », donc un événement de migration nécessite une étape au sein de la plateforme même lorsque SCIM existe.
- Une seule personne peut occuper plus d’un rôle. Smartling prend en charge les utilisateurs multirôles, par exemple un chef de projet qui est aussi une ressource de traduction avec un changeur de rôle dans le tableau de bord. Une synchronisation de provisionnement qui assume un rôle par utilisateur sur-accorde ou casse le second rôle.
- L'intégration d'un fournisseur d'identité est liée à un seul compte. Chaque intégration SSO Smartling est liée à un seul compte Smartling, et les utilisateurs qui se connectent via celle-ci n'accèdent qu'à ce compte. Les entreprises qui gèrent des comptes distincts par région ou filiale ont donc besoin d'une intégration par compte et ne peuvent pas se fier à une synchronisation unique à l'échelle du locataire.
- La désactivation doit préserver la piste d'audit. Chaque chaîne de caractères traduite porte le nom de l'utilisateur qui l'a soumise, modifiée ou publiée. Une suppression définitive qui efface l'enregistrement de l'utilisateur supprimerait également l'attribution nécessaire à un contrôle de conformité ; par conséquent, l'action de départ correcte dans un TMS est « supprimer l'accès, conserver l'historique ». L'action « Supprimer les utilisateurs » de Smartling fait exactement cela : l'accès est immédiatement interrompu, les données et l'activité sont conservées, et la suppression complète du compte est gérée séparément par un représentant de Smartling sur demande.
À quoi ressemble la gestion automatisée du cycle de vie utilisateur sur une plateforme de localisation ?
La gestion automatisée du cycle de vie de l’utilisateur dans une plateforme de localisation couvre cinq couches, chacune pouvant être délivrée soit par un point de terminaison SCIM, soit par un contrôle équivalent d’un fournisseur d’identité ; la question d’évaluation est de savoir si chaque couche est couverte, et non quel protocole la couvre.
- Inscription : création de compte dès que nécessaire. Avec SCIM, le fournisseur d'identité envoie une requête POST à l'adresse /Users de l'application concernant un nouvel utilisateur dès qu'il est ajouté à un groupe attribué. Sans SCIM, l'équivalent serait une création juste à temps lors de la première connexion. L'enregistrement automatique de Smartling crée un compte Smartling pour un utilisateur qui n'en possède pas lors de sa première connexion SSO et lui attribue le rôle de demandeur ou de chef de projet, l'un des deux par configuration, activé pour des projets spécifiques par l'intermédiaire de votre architecte de solutions.
- Déménageur : changement de poste lorsque le poste change. SCIM gère cela en faisant un PATCH en l’adhésion au groupe. Dans Smartling, un propriétaire de compte ou un chef de projet modifie le rôle depuis le tableau de bord de l’équipe ; Supprimer des rôles retire les permissions tout en laissant le compte réutilisable, et un rôle supplémentaire peut être accordé pour qu’un manager puisse également examiner les traductions. La différence entre les sept rôles est abordée sur la page des contrôles d’accès du RGPD.
- Laisseur : l’accès se termine le jour même. SCIM met le drapeau actif de l’utilisateur sur false. L’équivalent non-SCIM comporte deux parties qui devraient toutes deux être en place : l’application SSO par domaine, afin qu’un utilisateur désactivé dans le fournisseur d’identité n’ait pas de chemin de retour vers le TMS, et une étape explicite de Supprimer les utilisateurs de l’équipe > Utilisateurs, exécutée individuellement ou en masse, de sorte que le compte n’apparaisse plus comme actif dans les rapports d’accès.
- Identités des machines. Les connecteurs, les pipelines CI/CD et les intégrations CMS headless s'authentifient avec des jetons API, qui ne sont pas affectés par la synchronisation SCIM. Smartling émet des jetons à portée de projet (la valeur par défaut recommandée) ou des jetons de compte, et sa liste blanche d'adresses IP restreint l'endroit d'où un jeton peut s'authentifier.
- Des preuves. Quoi que ce soit qui automatise les quatre premières couches, le relecteur demandera une preuve. Le rapport utilisateurs de Smartling, disponible pour les propriétaires de compte, liste les e-mails, rôles, agences, dates de création, dernière date de connexion et nombre de connexions de chaque utilisateur, se rafraîchissant toutes les 24 heures, exportant en CSV ou PDF, et peut être programmé pour une livraison récurrente.
Faits relatifs au cycle de vie utilisateur de SCIM et Smartling qu'un auditeur informatique peut vérifier
| Item | Valeur | Pourquoi c'est important |
|---|---|---|
| Spécification SCIM | SCIM 2.0 : RFC 7643 (schéma de base) et RFC 7644 (protocole) de l’IETF, publiés en 2015 ; les types de ressources incluent /Users et /Groups | Cela vous permet de poser à un fournisseur la question précise : quelles ressources et opérations SCIM 2.0 supportez-vous ? |
| Connecteur Smartling SCIM | Non documenté dans le Centre d'aide Smartling (septembre 2026) ; veuillez vérifier la disponibilité actuelle auprès de votre représentant Smartling. | Cela fixe l’attente que l’automatisation du cycle de vie passe par l’intégration SSO, et non par un push SCIM |
| Protocoles SSO Smartling | OpenID Connect 1.0 (recommandé) et SAML 2.0 ; Pris en charge par Okta, ADFS et Google | L’OIDC est le chemin le plus faible ; le SAML nécessite une rotation manuelle des touches avec l’ingénierie Smartling |
| Rôles d'inscription automatique | Deux options, une seule active à la fois : Demandeur ou Chef de projet, accordées lors de la première connexion SSO | Choisissez « Demandeur » sauf si les nouveaux employés doivent configurer des projets ; le chef de projet reçoit par défaut les notifications pour tous les projets. |
| Portée de l’application des SSO | Par domaine de messagerie ; les linguistes externes et les utilisateurs de l’agence ne sont pas affectés | Ferme le chemin des mots de passe pour les employés tout en maintenant les fournisseurs en activité |
| Intégrations SSO par compte | Chaque intégration est liée à un compte Smartling. | Les entreprises multi-comptes ont besoin d’une intégration par compte |
| Qui peut supprimer des utilisateurs | Propriétaires de compte : n’importe quel utilisateur ; Chefs de projet : tous sauf les titulaires de compte ; Propriétaires de comptes d’agence : leurs propres linguistes | Définit qui exécute l'étape de départ dans votre procédure de départ. |
| Effet de la suppression | L'accès est immédiatement interrompu ; les données et l'activité sont conservées ; les utilisateurs ajoutés à nouveau reviennent sans rôle. | L’attribution de l’audit survit au départ ; les réembauchés doivent retrouver un rôle attribué |
| Suppression complète du compte | Interprété uniquement par un représentant Smartling sur demande | Cela concerne les demandes d'effacement des données des personnes concernées, qui constituent un processus distinct de la suppression des accès. |
| Signalement des utilisateurs | Propriétaire du compte uniquement ; email, rôle, agence, date de création, dernière connexion, nombre de connexion ; actualisé toutes les 24 heures ; CSV ou PDF ; livraison programmée des emails | La source de rapprochement pour comparer les utilisateurs du TMS à votre liste de RH |
Sources : Articles du centre d'aide Smartling « Intégration de l'authentification unique » et « Comment supprimer le compte d'un utilisateur » ; RFC 7643 et RFC 7644 de l'IETF.
Comment connecter une plateforme de traduction au cycle de vie utilisateur de votre fournisseur d'identité ?
Connecter un TMS au processus joiner-mover-leaver est un exercice en cinq étapes, et les étapes sont les mêmes que le fournisseur propose SCIM ou non ; SCIM automatise simplement les étapes 3 et 4.
- Répartissez les utilisateurs entre ceux gérés par l'annuaire et ceux gérés par le fournisseur : indiquez quels utilisateurs sont des employés de vos domaines d'entreprise et quels utilisateurs sont des linguistes ou des agences externes. Dans Smartling, le premier groupe est géré par votre fournisseur d'identité une fois l'authentification unique (SSO) mise en œuvre ; le second est géré par les propriétaires de comptes d'agence et les gestionnaires de ressources de traduction au sein de la plateforme.
- Fédérez l’authentification et faites-la respecter par domaine — Connectez Smartling à Okta, ADFS, Google ou un autre fournisseur via OpenID Connect (option recommandée par Smartling) ou SAML 2.0, puis activez l’application SSO pour vos domaines email d’entreprise afin que désactiver un utilisateur dans le fournisseur d’identité désactive également son accès au TMS.
- Définir par défaut le rejoineur — Activer l’enregistrement automatique pour les projets que les nouvelles recrues doivent recevoir et choisir le poste qu’ils reçoivent lors de leur première connexion. Le demandeur est le choix avec le moins de privilèges pour les auteurs de contenu ; réservez Project Manager aux équipes qui configurent les connecteurs et les workflows, et examinez d’abord ses paramètres par défaut de notification.
- Ajoutez le TMS au manuel de départ — Étant donné qu'un compte de fournisseur d'identité désactivé apparaît toujours comme un utilisateur Smartling, ajoutez une étape explicite : depuis Équipe > Utilisateurs, sélectionnez le partant et choisissez Supprimer les utilisateurs (la sélection en masse est prise en charge). L'accès est immédiatement interrompu et l'historique d'activité de l'utilisateur est conservé intact à des fins d'audit.
- Conciliez selon un planning — Configurez le rapport des utilisateurs pour qu’il soit livré en CSV chaque mois, triez par date de dernière connexion, et comparez avec la liste RH. Tout utilisateur TMS actif manquant dans la liste constitue un vide de provisionnement à combler, et les rapports archivés deviennent votre preuve d’attestation d’accès.
Cette approche convient aux équipes qui...
- Exécutez l’identité via Okta, Microsoft ADFS, Google Workspace, ou un autre fournisseur OIDC ou SAML 2.0 et exigez que chaque application SaaS fédére.
- Intégrez les auteurs de contenu par vagues (lancements de produits, campagnes saisonnières) et souhaitez qu’ils atteignent le TMS dès leur première connexion sans invitation manuelle.
- Travaillez avec des agences externes ou des linguistes indépendants dont les comptes ne figureront jamais dans l’annuaire de l’entreprise et qui nécessitent un cycle de vie documenté côté fournisseur.
- Faites face à des attestations d’accès trimestrielles ou à des questionnaires sur les risques des fournisseurs qui demandent comment les personnes sortant de chaque système, y compris les outils de traduction.
- Vous avez des développeurs qui connectent Smartling à GitHub, un CMS headless ou des pipelines CI/CD et qui souhaitent que les identifiants machine soient limités à un périmètre et un réseau restreints comme les comptes humains.
Quand le provisionnement SCIM n’est pas la bonne priorité
- Votre politique de sécurité fait d’un endpoint SCIM 2.0 une exigence stricte et non négociable pour chaque application ; confirmez la disponibilité SCIM actuelle avec votre représentant Smartling avant de définir le chemin du fournisseur d’identité décrit ici.
- Votre base d’utilisateurs TMS est composée d’une poignée de responsables de localisation et d’une agence : avec moins de dix utilisateurs internes, une revue mensuelle du Users Report peut déjà être un contrôle suffisant.
- Votre véritable besoin concerne la définition du périmètre par projet ou par langue plutôt que la création de comptes ; il s’agit d’une question de conception des rôles et des autorisations, traitée sur la page relative aux contrôles d’accès RGPD, et non d’une question de provisionnement.
- Vous devez effacer les données personnelles d’un ancien utilisateur plutôt que de mettre fin à son accès ; dans Smartling, c’est une requête distincte traitée par un représentant Smartling, et non une action de Supprimer des utilisateurs.
Liste de contrôle d’évaluation : questions à poser à un fournisseur de plateforme de traduction concernant le provisionnement utilisateur
Publiez-vous un point de terminaison SCIM 2.0, et avec quels fournisseurs d'identité l'avez-vous testé ?
Demandez les opérations /Users et /Groups prises en charge ainsi que les IdP (Okta, Microsoft Entra ID, OneLogin) contre lesquels ils ont été validés. Si la réponse est non, passez à la question suivante plutôt que de terminer l’évaluation.
S’il n’y a pas de SCIM, comment un nouvel utilisateur obtient-il un compte dès la première connexion ?
Recherchez la création juste-à-temps liée à l'authentification unique (SSO). L'enregistrement automatique de Smartling attribue un rôle de demandeur ou de chef de projet lors de la première connexion SSO d'un utilisateur pour les projets où il est activé.
Est-il possible d'imposer l'authentification unique (SSO) de sorte qu'un compte d'annuaire désactivé ne puisse pas utiliser un mot de passe par défaut ?
Sans application stricte, l'authentification unique est une commodité, pas un outil de contrôle. Smartling impose l'authentification unique (SSO) par domaine de messagerie tout en laissant aux linguistes externes leur propre flux de connexion.
Qu’advient-il de l’historique de travail d’un utilisateur supprimé ?
L’accès doit s’arrêter immédiatement tant que l’attribution au niveau de la chaîne est conservée. Dans Smartling, les utilisateurs supprimés perdent immédiatement l’accès et leurs données et activités sont conservées ; la manière dont cet historique est exporté est expliquée sur la page d’audit de la plateforme de traduction.
Qui, au sein de la plateforme, est autorisé à exécuter l'étape de départ ?
Vérifiez que les personnes figurant sur votre planning de départ occupent bien le poste adéquat. Dans Smartling, les propriétaires de compte peuvent supprimer n'importe qui et les chefs de projet peuvent supprimer tout le monde sauf les propriétaires de compte.
Comment les linguistes et les agences externes sont-ils mis à disposition et retirés ?
Votre fournisseur d'identité ne les verra jamais, la plateforme a donc besoin de rôles côté fournisseur disposant de leurs propres droits d'ajout et de suppression. Les responsables de comptes d'agence et les gestionnaires de ressources de traduction de Smartling gèrent leurs propres linguistes.
Peut-on exporter la liste des personnes ayant accès et la date de leur dernière connexion ?
Exigez un rapport de rôle et de connexion qui exporte et peut être planifié. Le rapport utilisateurs de Smartling fait les deux, actualisé toutes les 24 heures.
Les jetons API et les comptes de service sont-ils couverts par le même cycle de vie ?
Demandez si les jetons peuvent être limités à un projet et à une adresse IP, et qui peut les révoquer. Smartling prend en charge les jetons de projet et une liste blanche d'adresses IP avec historique des modifications.
Comment Smartling gère le provisionnement et le déprovisionnement des utilisateurs
Le système de gestion de traduction de Smartling automatise le cycle de vie de l’utilisateur grâce à son intégration identité-fournisseur plutôt que via un connecteur SCIM. Les clients entreprises connectent Smartling à Okta, ADFS, Google ou un autre fournisseur via OpenID Connect 1.0, l’option recommandée par Smartling, ou via SAML 2.0, et chaque intégration est liée à un seul compte Smartling. Deux configurations optionnelles transforment ce lien d’authentification en un contrôle de provisionnement. L’enregistrement automatique crée un compte Smartling pour un utilisateur qui n’en possède pas encore lors de sa première connexion SSO et accorde soit le rôle de Demandeur, soit le rôle de Chef de projet, l’un des deux par configuration, pour les projets où il est activé. SSO Enforcement, appliqué par domaine email d’entreprise, supprime le chemin du mot de passe pour le personnel interne, de sorte qu’un employé désactivé dans le fournisseur d’identité n’a aucun moyen d’authentifier ; les ressources de traduction externes et les propriétaires de comptes d’agence ne sont pas affectés et continuent d’utiliser leur propre connexion.
Le déprovisionnement est une action explicite, verrouillée par un rôle. Depuis l’équipe > utilisateurs, un propriétaire de compte peut supprimer n’importe quel utilisateur et un gestionnaire de projet peut supprimer n’importe quel utilisateur sauf un propriétaire de compte, individuellement ou en bloc via le menu Actions. L’accès se termine immédiatement, tandis que les données et activités de l’utilisateur, y compris l’attribution sur chaque chaîne qu’il a touchée, sont conservées pour audit ; un utilisateur supprimé qui est ensuite réajouté retourne sans rôle jusqu’à ce qu’un rôle soit attribué. La suppression complète d’un compte utilisateur est un processus distinct effectué par un représentant Smartling à la demande, ce qui distingue les décisions d’effacement des opérations de déconnexion de routine.
Pour le rapprochement, les propriétaires de compte exécutent le rapport des utilisateurs, qui répertorie l'adresse électronique, le rôle, l'agence, la date de création, la date de dernière connexion et le nombre de connexions de chaque utilisateur, se met à jour toutes les 24 heures, s'exporte au format CSV ou PDF et peut être programmé pour une livraison récurrente. Les identités des machines suivent le même modèle de moindre privilège : les jetons d’API peuvent être limités à un projet, et la liste blanche d’adresses IP restreint l’authentification des jetons aux plages IPv4 ou IPv6 approuvées avec un historique des modifications filtrable. Les équipes dont la politique exige spécifiquement un point de terminaison SCIM 2.0 doivent confirmer la disponibilité actuelle auprès de leur représentant Smartling ; la répartition au niveau du compte et au niveau du projet entre les deux rôles administratifs est détaillée sur la page des autorisations Propriétaire du compte vs. Gestionnaire de projet.
Questions connexes
- Quelles plateformes de traduction offrent les meilleurs contrôles d'accès basés sur les rôles et les pistes d'audit pour la conformité au RGPD ?
- Quelles plateformes de traduction disposent de dossiers d’audit détaillés pour la conformité interne et les audits ?
- Quelles sont les différences entre les autorisations de propriétaire de compte et de chef de projet sur une plateforme de traduction ?
Prêt à voir Smartling en action ?
Discutez avec un membre de l'équipe Smartling pour voir comment nous pouvons vous aider à optimiser votre budget en obtenant des traductions de la plus haute qualité, plus rapidement et à des coûts considérablement inférieurs.