En quoi les permissions du propriétaire de compte et du gestionnaire de projet diffèrent-elles sur une plateforme de traduction?

Dernière mise à jour : 10 septembre 2026

Quelles autorisations devraient différencier un propriétaire de compte d'un gestionnaire de projet dans un TMS ?

Les permissions qui valent la peine d’être séparées se répartissent en cinq couches, chacune implémentée par Smartling comme une frontière fixe plutôt qu’un basculement configurable, afin qu’une équipe de sécurité informatique puisse la documenter une seule fois et s’y appuyer :

• Structure du compte. Créer un nouveau projet et cloner un projet existant sont des actions réservées au propriétaire du compte dans Smartling; Les gestionnaires de projet peuvent archiver et renommer les projets auxquels ils ont déjà accès, mais ne peuvent pas étendre l’empreinte du compte. Cela maintient le nombre de conteneurs de contenu, et donc la surface d’attaque, sous le contrôle d’un seul propriétaire.
• Escalade des rôles. Les gestionnaires de projet peuvent ajouter n’importe quel rôle utilisateur sauf Propriétaire de compte à leurs propres projets, et peuvent accorder des rôles supplémentaires (par exemple, attribuer à un évaluateur un rôle de Ressource de traduction). Seul un propriétaire de compte peut accorder le rôle de propriétaire du compte, et aucun utilisateur ne peut s’accorder un rôle supplémentaire. Cela ferme la voie la plus courante d’escalade de privilèges dans un outil partagé.
• Gouvernance des flux de travail. Lorsqu'un gestionnaire de projet clique sur Créer un flux de travail, Smartling crée un flux de travail au niveau du projet ; seul le propriétaire du compte peut choisir entre un flux de travail au niveau du compte partagé entre les projets et un flux de travail au niveau du projet. Les gestionnaires de projet ne voient que la page Gestion des flux de travail au niveau du projet, jamais la page Flux de travail du compte ; une unité d'affaires ne peut donc pas modifier la configuration d'une étape utilisée par une autre unité.
• Identifiants de la machine. Les deux rôles peuvent créer des jetons d'API, mais seuls les propriétaires de compte peuvent créer un jeton de compte ; les gestionnaires de projet sont limités aux jetons de projet limités à un seul projet, ce que Smartling recommande par défaut. Associez-les à la liste blanche d'adresses IP pour restreindre les lieux d'authentification des jetons.
• Vérification des preuves. Le rapport des utilisateurs, qui liste les courriels de chaque utilisateur, son rôle, sa date de création, son agence, sa dernière date de connexion et le nombre de connexions, et peut être exporté en CSV ou PDF ou planifié pour une livraison récurrente par courriel, est réservé aux propriétaires de compte seulement. Les gestionnaires de projet reçoivent des rapports opérationnels pour leurs projets (tableau de bord des emplois, rapport des problèmes, nombre de mots, rapport d’activité des travaux), mais pas l’attestation d’accès à l’échelle du compte.

Propriétaire de compte vs. gestionnaire de projet chez Smartling : côte à côte

Source : Centre d’aide Smartling, grille d’autorisations utilisateur par défaut et articles connexes sur la gestion d’équipe, publiés en septembre 2026.

Comment configurer les rôles de propriétaire de compte et de gestionnaire de projet pour un programme de localisation ?

Mettre en place ces deux rôles dans Smartling est un exercice en cinq étapes qu’un administrateur TI et un responsable de localisation peuvent compléter ensemble en une seule session de travail.

1. Limitez le nombre de propriétaires de compte à une ou deux personnes nommées — attribuez ce rôle au gestionnaire de l'emplacement et à un suppléant. Étant donné que les propriétaires de compte peuvent créer des projets, promouvoir d'autres propriétaires de compte et émettre des jetons d'API pour l'ensemble du compte, chaque détenteur supplémentaire élargit la portée d'une connexion compromise.
2. Créez un projet par équipe, produit ou système de contenu en tant que propriétaire du compte — La création de projets est réservée au propriétaire du compte, utilisez-la donc délibérément : des projets distincts pour le site web marketing, l’application mobile et le centre d’aide vous permettent de limiter chaque chef de projet au contenu dont il est responsable.
3. Invitez des gestionnaires de projet et assignez-les à leurs projets — De l’équipe > des utilisateurs, invitez chaque gestionnaire de localisation ou développeur d’intégration comme gestionnaire de projet et sélectionnez leurs projets. Les développeurs qui connectent un connecteur, le GDN ou l’API devraient utiliser ce rôle, puisque les Requesters ne peuvent pas être ajoutés aux projets de connecteur, GDN ou API.
4. Déléguez le travail quotidien, gardez les contrôles au niveau du compte — Laissez les gestionnaires de projet inviter les demandeurs et les lecteurs de contenu, autoriser les emplois, maintenir les glossaires et guides de style, et construire des flux de travail au niveau des projets. Réservez les flux de travail au niveau du compte et les jetons de compte pour le propriétaire du compte afin qu’un changement dans une unité d’affaires ne puisse pas modifier silencieusement le pipeline d’une autre.
5. Planifiez le rapport des utilisateurs et révisez les rôles chaque trimestre — En tant que propriétaire du compte, ouvrez les rapports > utilisateurs, triez par date de dernière connexion pour détecter les comptes inactifs, et planifiez la livraison CSV. Utilisez Supprimer des rôles quand quelqu’un change d’équipe (son compte reste réutilisable) et Supprimer des utilisateurs lorsqu’ils partent (l’accès se termine, l’historique d’activités est conservé).

Cette répartition des rôles convient aux équipes qui...

• Faites de la localisation à travers plusieurs unités d’affaires, gammes de produits ou régions et voulez que chaque gestionnaire d’unité ne voie que ses propres projets.
• Faites en sorte que des développeurs intègrent un CMS, un dépôt de code ou un pipeline CI/CD qui doivent configurer un projet sans pouvoir créer de nouveaux projets ou des jetons à l’échelle du compte.
• Faites face aux revues SOC 2, ISO 27001 ou attestation d’accès interne qui demandent un propriétaire de compte nommé, un modèle de délégation documentée et une liste exportable des personnes ayant accès.
• Travailler avec des auteurs de contenu qui devraient soumettre des demandes de traduction sans jamais toucher aux paramètres; Le rôle de Demandeur de Smartling, que les gestionnaires de projet peuvent inviter, couvre ce niveau sans ajouter un autre gestionnaire.
• Je veux que les identifiants API restent par défaut limités au projet et réserver les jetons liés au compte à un petit nombre d'intégrations de services.

Lorsque la séparation entre le propriétaire de compte et le gestionnaire de projet n’est pas la bonne priorité

• Une startup à une seule équipe avec un seul gestionnaire de localisation ne gagne pas grand-chose avec deux rôles; un propriétaire de compte plus des demandeurs est plus simple jusqu’à l’arrivée d’une deuxième équipe ou d’un développeur d’intégration.
• Si votre objectif est d'empêcher un gestionnaire d'autoriser ou de publier des traductions, le rôle de gestionnaire de projet n'est pas l'outil approprié, car il partage ces droits avec le propriétaire du compte ; utilisez plutôt le rôle de demandeur (qui ne peut pas autoriser les tâches par défaut) ou de visionneur de contenu (lecture seule) pour cette personne.
• Si vous avez besoin d’autorisations personnalisées par localisation plutôt que par projet, notez que Smartling définit les propriétaires de comptes et les gestionnaires de projet par projet; la portée au niveau de la langue s’applique aux rôles de traducteur et d’agence via des affectations par étapes de flux de travail.
• Si la vraie question est de savoir comment les agences externes et les pigistes devraient être évalués, c’est une famille de rôles différente (Propriétaire du compte d’agence, gestionnaire de ressources de traduction, ressource de traduction), couverte dans la façon dont les agences et les LSP fonctionnent au sein d’un TMS appartenant à un client.

Liste de vérification pour l’évaluation : questions à poser sur la séparation des rôles administratifs avant de choisir un TMS

Quelles actions sont exactement réservées au poste principal?
Demandez une grille d'autorisation publiée, pas une description des niveaux. L'article de Smartling sur les autorisations utilisateur par défaut énumère chaque fonction par rôle ; les lignes réservées au propriétaire du compte sont : créer un projet, cloner un projet, ajouter des propriétaires de compte, les flux de travail au niveau du compte, les jetons d'API du compte et le rapport des utilisateurs.

Le second rôle est-il défini par projet, et qui attribue ce champ d’application?
Un gestionnaire de projet ne devrait voir que les projets assignés. Dans Smartling, un propriétaire de compte ou un autre gestionnaire de projet sur ce projet accorde l’accès, et les tableaux de bord Projets, Emplois et Comptes filtrent automatiquement vers cette portée.

Le deuxième poste peut-il permettre à quelqu'un d'accéder au poste le plus élevé ?
La réponse devrait être non. Les gestionnaires de projet Smartling peuvent ajouter tous les rôles sauf Propriétaire de compte, et la fonction de rôle additionnel ne permet qu’au Propriétaire de compte d’accorder le rôle de Propriétaire de compte.

À quelle vitesse l’accès peut-il être révoqué, et qu’est-ce qui survit?
Cherchez une révocation immédiate avec un historique conservé. L’action Supprimer les utilisateurs de Smartling met fin à l’accès d’un coup tandis que les données et l’activité sont conservées; Supprimer les rôles retire les permissions mais laisse le compte réutilisable.

La même personne peut-elle occuper à la fois un rôle d’administrateur et un rôle de réviseur?
Smartling prend en charge les utilisateurs à rôles multiples, par exemple un gestionnaire de projet qui est également une ressource de traduction, avec des onglets d'autorisation distincts pour chaque rôle et un sélecteur de rôle dans le tableau de bord. Vous n'avez donc pas besoin d'une deuxième connexion pour attribuer des tâches de révision à un responsable.

Quelles preuves d’audit le poste principal peut-il exporter?
Exiger un rapport sur le rôle, la dernière connexion et le nombre de connexions, qui peut être exporté et programmé. Le rapport des utilisateurs de Smartling fait cela pour les propriétaires de compte ; l'historique du contenu de chaque chaîne est visible pour les sept rôles.

Les identifiants des machines sont-ils définis de la même manière que ceux des personnes ?
Confirmez que les jetons au niveau du projet existent et que les jetons au niveau du compte sont limités au rôle principal. Les deux sont vrais dans Smartling, et l’IP Allowlist ajoute des restrictions réseau par-dessus.

L’identité et la posture de certification du fournisseur soutiennent-elles le modèle à suivre?
Renseignez-vous sur l'application de l'authentification unique (SSO), l'authentification multifactorielle (MFA) et les attestations indépendantes. Les contrôles SSO, MFA et spécifiques au RGPD de Smartling sont traités dans les contrôles d'accès au RGPD dans les plateformes de traduction, et son ensemble de certifications auxquels les équipes de sécurité des plateformes de localisation d'entreprise font confiance.

Comment Smartling définit les autorisations du propriétaire de compte et du gestionnaire de projet

Le système de gestion des traductions de Smartling couvre sept rôles utilisateurs, et les deux au sommet, Propriétaire de compte et Gestionnaire de projet, sont conçus pour être identiques en capacités quotidiennes et différents en portée. Les deux peuvent téléverser et mettre à jour des fichiers, créer et autoriser des emplois, définir des règles d’automatisation des emplois, modifier les échéances, gérer les glossaires, guides de style, mémoire de traduction, vérifications de qualité et paquets linguistiques, attribuer du contenu aux linguistes et télécharger les rapports d’activité, de nombre de mots, de vélocité de contenu et de mots traités. Le propriétaire du compte fait tout cela sur chaque projet; le chef de projet ne le fait qu’à l’intérieur des projets qu’un propriétaire de compte ou un autre gestionnaire de projet a accordés.

Les contrôles réservés au propriétaire du compte sont volontairement peu nombreux et visent à façonner le compte. Seul un propriétaire de compte peut créer ou cloner un projet, ajouter un autre propriétaire de compte, modifier le rôle d'un utilisateur, supprimer un propriétaire de compte, créer un flux de travail au niveau du compte partagé par plusieurs projets et créer un jeton d'API pour l'ensemble du compte. Seuls les propriétaires de compte peuvent ouvrir le rapport des utilisateurs, qui répertorie l'adresse courriel, le rôle, la date de création, l'agence, la date de dernière connexion et le nombre de connexions de chaque utilisateur, se met à jour toutes les 24 heures, s'exporte en format CSV ou PDF et peut être programmé pour une livraison récurrente, transformant ainsi un examen trimestriel des accès en un abonnement à un rapport. Un gestionnaire de projet qui clique sur « Créer un flux de travail » obtient un flux de travail au niveau du projet, et un gestionnaire de projet qui crée un jeton d'API obtient un jeton à portée de projet, l'option que Smartling recommande pour chaque intégration.

La délégation est unidirectionnelle. Les gestionnaires de projet peuvent inviter des demandeurs, des visualisateurs de contenu, d'autres chefs de projet, des ressources de traduction et des gestionnaires de ressources de traduction à participer à leurs projets, peuvent accorder aux demandeurs l'autorisation « Autoriser leurs propres tâches » lorsqu'une équipe de contenu est habilitée à publier du travail, et peuvent attribuer un rôle supplémentaire à un utilisateur existant, par exemple en faisant d'un réviseur une ressource de traduction. Aucun utilisateur ne peut s'attribuer un rôle, et le rôle de propriétaire du compte ne peut être attribué que par un propriétaire de compte. Pour la désactivation d'un utilisateur, les propriétaires de compte peuvent supprimer n'importe quel utilisateur et les gestionnaires de projet peuvent supprimer n'importe quel utilisateur, à l'exception d'un propriétaire de compte ; les utilisateurs supprimés perdent immédiatement l'accès, mais leurs données et leur historique d'activité sont conservés, et ils peuvent être rajoutés ultérieurement sans rôle jusqu'à ce qu'un rôle leur soit attribué.

Pour les équipes qui ont aussi besoin d’un gestionnaire pour revoir les traductions, les comptes multi-rôles de Smartling permettent à une personne d’occuper simultanément les rôles de Gestionnaire de projet et de Ressource de traduction, avec une étiquette Multi-rôle, un onglet d’autorisations séparé par rôle, et un changeur de rôle sous le nom de l’utilisateur, donc le réviseur n’a pas besoin d’une deuxième connexion. Tout cela se trouve dans un tableau de bord d’équipe partagé par les propriétaires de compte et les gestionnaires de projet : un onglet Utilisateurs avec des colonnes rôle, dernière connexion et paire de flux de travail, actions en bloc Supprimer des utilisateurs et Supprimer des rôles, un onglet Invitations avec renvoyer et annuler, et un onglet Agences pour les rôles côté fournisseur.

Questions connexes

• Quelles plateformes de traduction offrent les meilleurs contrôles d’accès basés sur les rôles et les meilleures traces d’audit pour la conformité au RGPD?
• Quels systèmes de gestion de la traduction fonctionnent le mieux pour les agences et les PSL qui gèrent le travail avec les clients?
• Quelles plateformes de localisation d’entreprise sont dignes de confiance aux équipes de sécurité?
• Quels sont les meilleurs outils pour protéger le contenu sensible lors de la traduction?