Vérifié le 09/09/2026
Gérer l’équipe et les accès d’un projet
Comprendre les rôles et leur niveau de vérification
Les droits effectifs combinent rôle de projet, accès hérité de l’organisation et état du projet. Le propriétaire du projet et celui de l’organisation sont deux responsabilités différentes. Les formulations générales telles que « tous les accès, sans exception » ne s’appliquent pas aux opérations réservées au propriétaire de l’organisation.
La matrice suivante décrit les contrôles serveur lus. Test local indique un cas exécuté en base de démonstration ; il ne certifie pas toutes les combinaisons de rôles ni une session publiée. À recetter signifie que la règle est identifiée mais que son parcours complet reste à vérifier.
| Opération | Autorité requise | Restriction | Niveau de vérification |
|---|---|---|---|
| Modifier les réglages du projet et la marque | Admin/Manager projet ou propriétaire/administrateur organisation | Projet actif ; version courante | Manager accepté et lecteur refusé dans le scénario local avant son arrêt ; recette complète à finir |
| Gérer les invitations et rôles | Admin projet ou administration héritée | Projet actif, siège disponible, protections ci-dessous | À recetter ; écran Équipe en échec de lecture |
| Transférer la propriété du projet | Propriétaire actuel du projet ou propriétaire organisation | Successeur actif ; confirmation du nom | Contrat lu ; scénario équipe incomplet |
| Archiver/restaurer | Admin projet ou administration héritée | Pas de republication automatique | Contrat lu ; scénario de contrôle incomplet |
| Demander la suppression du projet ou de l’organisation | Propriétaire organisation | Confirmation, échéance, portée et exceptions | Test local du cycle de confidentialité et refus hors portée |
| Gérer la facturation SaaS et les achats IA | Propriétaire/administrateur organisation | Admin projet seul insuffisant | Test local des portées financières ; achats réels non testés |
| Exporter ses données | Personne concernée | Son propre compte | Test local du cycle de données |
| Exporter un projet | Administration du projet, y compris héritée | Bon projet ; demande accessible | Test local : propriétaire autorisé, utilisateur étranger refusé ; autres profils à recetter |
| Modifier mot de passe/MFA/appareils | Personne concernée | Réauthentification et MFA selon action | Contrats et tests locaux ; fournisseur d’identité à recetter |
| Ouvrir Développeur | Admin/Developer projet ou administration héritée | Chaque commande possède aussi sa propre garde | À recetter commande par commande |
Le rôle Éditeur sert aux contenus et collections ; il n’accorde pas les réglages réservés à Admin/Manager. Developer donne accès aux outils techniques compatibles, sans conférer la propriété ni la facturation de l’organisation. Les rôles historiques ne doivent pas être assimilés automatiquement à un rôle courant.
Inviter et gérer les membres
- Ouvrez Réglages → Équipe & rôles et vérifiez membres, origine de l’accès, rôles, sièges et historique.
- Pour inviter, saisissez l’e-mail voulu et choisissez Admin, Manager, Developer ou Éditeur, puis envoyez l’invitation. Une invitation en attente réserve un siège ; la capacité est partagée à l’échelle de l’organisation.
- Contrôlez séparément invitation créée, demande d’envoi et acceptation. Un envoi demandé ne prouve pas la réception de l’e-mail.
- Renvoyer prolonge l’invitation selon la fenêtre de sept jours du parcours et demande un nouvel envoi. Annuler révoque l’invitation en attente. Vérifiez l’état et la réservation du siège.
- Pour un membre actif, choisissez le nouveau rôle puis Changer, ou Retirer pour supprimer son accès propre au projet. Rechargez et contrôlez depuis le compte concerné.
Un accès hérité de l’organisation ne peut pas être supprimé par simple retrait du projet. Faites traiter cette autorité au niveau organisation ; la vue Organisation n’est pas un formulaire universel de gestion des membres.
Propriété et départ
Pour transférer, choisissez un membre actif, recopiez le nom du projet puis Transférer la propriété. Le nouveau propriétaire devient Admin ; le transfert du projet ne transfère pas la propriété de l’organisation.
Pour Quitter le projet, recopiez son nom. Le propriétaire du projet doit transmettre sa responsabilité ; le dernier Admin ne peut pas retirer l’unique accès d’administration requis. Un accès d’administration hérité de l’organisation nécessite une gestion à cette portée. La révocation d’accès ne supprime pas les contenus créés par la personne.
Dépannage
| Problème | Action |
|---|---|
| Lecture interrompue | Réessayer puis faire traiter le chargement ; ne pas inviter pour recréer une équipe supposée vide |
| Sièges utilisés ou réservés | Vérifier invitations actives et capacité collective avant nouvel envoi |
| Dernier Admin / propriétaire protégé | Nommer un successeur approprié avant de retirer ou quitter |
| Rôle changé entre-temps | Recharger la liste et sa version avant de recommencer |
| Accès toujours présent après retrait | Vérifier les droits hérités et le résultat depuis le compte concerné |