Gouverner les accès numériques : rôles, responsabilités et révocations

Séparer propriétaire, responsable métier, administrateur et utilisateur

Le propriétaire contractuel ou organisationnel n’est pas forcément l’administrateur quotidien. Le responsable métier définit les règles et accepte les risques. L’administrateur applique la configuration et les droits. L’utilisateur agit dans le périmètre accordé. Un support externe peut intervenir temporairement sans devenir propriétaire des données.

Dans une petite structure, une personne peut porter plusieurs rôles. Le registre les distingue tout de même afin de préparer un relais et d’éviter qu’un compte personnel devienne l’unique clé de l’organisation.

Pour chaque rôle, définissez qui l’attribue, quelles preuves sont exigées, quels conflits sont interdits et comment il est revu.

Construire une matrice d’accès à partir des objets et actions

Listez les objets : dossier, mission, document, calendrier, configuration, membre, journal et export. Pour chaque rôle, indiquez lire, créer, corriger, valider, supprimer, partager et administrer. Évitez un rôle “tout faire” utilisé par commodité.

Le périmètre compte autant que l’action : ses propres objets, une équipe, une organisation ou tout le système. Un droit de lecture global ne doit pas être déduit d’un droit de correction local. Les exports, suppressions et changements de rôles reçoivent des contrôles renforcés lorsque leur impact est large.

La matrice reste compréhensible par le responsable métier. Si elle ne peut être relue sans le code, elle n’est pas une preuve de gouvernance.

Complément vérifié le 14 octobre 2026 — une liste familiale peut aussi avoir besoin de droits distincts. Pour préparer des cadeaux, séparez la personne qui propose des idées, celle qui organise ou modifie la liste, les personnes qui achètent et la personne qui recevra le cadeau. Décidez qui peut voir les idées, voir les réservations, réserver, corriger ou retirer une réservation et inviter quelqu’un. Ces capacités sont à vérifier dans le service choisi ; le nom « acheteur » ou « destinataire » ne prouve pas les permissions effectives. Le destinataire du cadeau n’est pas nécessairement le destinataire autorisé du lien de coordination.

Avant de diffuser, contrôlez le compte et l’espace ouverts, la liste exacte, le rôle proposé, la durée éventuelle et l’état de l’invitation : préparée, envoyée, acceptée, expirée ou retirée selon les états disponibles. Posséder une URL ne démontre pas un rôle nominatif : certains liens donnent un accès à toute personne qui les détient, d’autres exigent un compte autorisé. Si cette différence reste inconnue, demandez la documentation ou utilisez un canal plus limité avant d’y placer des informations privées. La CNIL recommande de restreindre les échanges aux destinataires dûment autorisés. Ne publiez pas le lien privé dans une page, un groupe élargi, un nom de fichier ou une capture.

Préserver la surprise n’est pas une garantie de confidentialité. Un titre, un aperçu de messagerie, une notification sur un appareil partagé ou une copie déjà reçue peut révéler une idée même si la réservation est masquée dans la liste. Vérifiez le canal et son contenu avant envoi, limitez noms, adresses, dates et préférences personnelles au besoin réel, puis confirmez seulement la visibilité effectivement connue. Retirer une invitation ou changer un lien ne rappelle pas automatiquement les messages, captures et fichiers déjà transmis. Cette vérification ne suppose aucune notification ou fonction de surprise disponible dans un produit particulier.

Cas fictif : le groupe Atelier prépare deux idées de cadeau, un livre et un jeu, pour un participant. Une personne organise la liste, deux autres coordonnent les achats ; le participant ne doit pas recevoir cette conversation de coordination. Avant tout envoi, l’organisateur vérifie que la vue réservée aux acheteurs et le message choisi correspondent à ce choix, si le service permet cette séparation. Sinon, il garde la coordination sur un support distinct aux seuls participants autorisés. Une invitation envoyée reste en attente tant que son acceptation n’est pas confirmée. Aucun lien réel, identité personnelle, achat ou message externe n’est utilisé dans cet exemple.

Complément de méthode du 14 octobre 2026 — confirmation absente après une réservation ou un achat. Une idée présente dans la liste, sa réservation par un proche, une commande passée chez un commerçant et la confirmation de chacune sont quatre faits distincts. Deux idées de même nom peuvent désigner des variantes différentes ; deux lignes différentes peuvent aussi désigner le même cadeau. Rapprochez la liste, la référence de l’idée ou sa description utile et le statut connu, sans ajouter de coordonnées privées dans la discussion collective.

Si la réponse manque après validation, n’en déduisez ni échec ni réussite et ne recommencez pas immédiatement depuis un autre appareil ou par un autre proche. Consultez la bonne liste depuis l’accès officiel et demandez au responsable de coordination si une réservation ou un achat a déjà été signalé. Pour une commande, vérifiez séparément l’état chez le commerçant par son canal officiel et la référence disponible : la liste familiale ne prouve pas l’exécution de l’achat. Un chargement incomplet ou une vue ancienne reste une limite de vérification, pas une liste vide. Si les états restent incertains, marquez l’action à clarifier dans le support de coordination convenu avant de décider d’un nouvel essai.

Cas fictif : le groupe Atelier prévoit un livre. Un proche valide sa réservation mais ne voit aucune confirmation ; un second envisage le même cadeau depuis un autre appareil. Ils consultent la liste et interrogent l’organisateur dans le canal réservé aux acheteurs avant de recommencer. Si le premier a déjà commandé, ils rapprochent la confirmation du commerçant avec le suivi de la liste sans publier reçu complet, adresse, moyen de paiement ou lien privé, ni prévenir le destinataire du cadeau par erreur. Sans preuve suffisante, ils gardent « réservation ou achat à confirmer » et ne créent pas une nouvelle action par simple supposition. Cette méthode humaine ne garantit pas qu’un service empêche les doublons ou rapproche automatiquement les appareils.

Traiter arrivée, changement de rôle, absence et départ

À l’arrivée, créez un compte nominatif, vérifiez le canal de récupération, attribuez le rôle minimal et confirmez le premier accès. Le changement de mission déclenche une revue : ajout nécessaire et retrait des anciens droits. Une absence peut justifier une délégation temporaire, jamais le partage d’un mot de passe.

Au départ, retirez les habilitations, sessions, clés, invitations et accès externes relevant de l'organisation et de la mission terminée. Transférez les responsabilités sans transférer les données personnelles inutiles. Fermer ou désactiver un compte professionnel nominatif géré par l'organisation suit sa procédure ; cela n'autorise pas à supprimer un compte personnel extérieur ni les accès légitimes conservés dans un autre périmètre. Les objets métier suivent leurs règles de rattachement et de conservation.

Conservez la preuve de la demande et de la révocation, pas une copie indéfinie de toutes les activités de la personne.

1. Nommer le changement et son responsable
2. Lister droits directs, groupes et intégrations
3. Préparer le relais métier
4. Révoquer sessions et secrets
5. Vérifier les refus
6. Mettre à jour le registre et la prochaine revue

Éviter les comptes partagés et protéger la récupération

Un compte partagé empêche d’attribuer une action, complique la révocation et diffuse le secret. Préférez des comptes nominatifs et des rôles adaptés. Lorsqu’un compte technique est indispensable, il possède un propriétaire, un coffre, une rotation et un périmètre non interactif.

La récupération est un accès privilégié. Vérifiez les canaux, les personnes autorisées et les codes de secours. Une boîte e-mail partagée ou un ancien numéro peut contourner tous les autres contrôles.

L’authentification multifacteur réduit certains risques mais ne corrige pas des droits excessifs. Elle doit utiliser un mécanisme officiel et prévoir une récupération contrôlée.

Préparez la continuité avant le retrait : désignez le propriétaire habilité qui reprend les dossiers, les alertes et les automatisations, puis vérifiez son accès propre et son moyen officiel de récupération. Ne transférez pas le compte personnel du sortant. Si une dépendance reste à remplacer, attribuez la décision et son échéance sans maintenir indéfiniment un droit injustifié.

Tenez une ligne par service et par périmètre : rôle à retirer, groupe ou invitation, session ou appareil à examiner, lien partagé éventuel, exécutant, date et résultat vérifié. Retirer un membre dans un outil ne ferme pas ses accès dans les autres. L’identité commune ou la connexion fédérée ne prouve pas une déconnexion universelle ; consultez les fonctions et la documentation de chaque service.

Pour un appareil hors ligne ou une copie locale déjà présente, consignez ce qui est connu et ce qui reste à confirmer. Un retrait côté service ne démontre pas que l’écran local s’est fermé ni que des fichiers déjà reçus ont disparu. Ne reconnectez pas un appareil ou un compte tiers pour tester sans autorisation. Demandez au responsable du service les effets documentés sur les sessions, les données locales et la prochaine connexion ; si la réponse manque, gardez ce point ouvert avec une prochaine action plutôt qu’un statut tout révoqué.

Exemple fictif : une intervenante quitte un projet vendredi. Le responsable reprend les alertes avec son propre accès, l’administrateur retire le rôle sur le service A et vérifie le périmètre indiqué. Le service B nécessite une action séparée sur une invitation encore ouverte. Une tablette hors ligne n’a pas été contrôlée : le compte rendu mentionne cette limite et le responsable de la suite. Il ne conclut ni à l’effacement distant ni à la clôture de toutes les sessions. La preuve finale relie chaque action à son service, sa date et son résultat ; les copies déjà transmises suivent leur traitement distinct.

Tester les refus aussi sérieusement que les accès autorisés

Créez des scénarios négatifs : lecteur qui tente de modifier, membre d’une organisation qui ouvre un dossier étranger, ancien membre qui réutilise une session, intervenant temporaire après expiration, tentative de passage par un lien fédéré révoqué. Le résultat attendu est un refus clair sans fuite de titre, métadonnée ou existence d’objet.

Testez aussi ce qui doit rester autorisé : retirer un lien fédéré ne signifie pas supprimer le compte natif ni ses droits légitimes. Lorsqu’un accès direct autonome est prévu, vérifiez séparément qu’il reste utilisable si le compte, ses moyens d’authentification et ses habilitations restent valides. Le NIST distingue le retrait d’un identifiant fédéré, qui ferme cet accès, des moyens d’authentification directe au compte cible. Cette vérification ne rétablit ni le lien révoqué ni un droit retiré. Testez l’interface et l’API. Masquer un bouton ne protège pas l’opération. Une session déjà ouverte doit être invalidée selon la règle annoncée ; un cache privé ne doit pas être servi à un autre compte.

Documentez la version, le profil et le résultat sans conserver de donnée réelle. Une recette synthétique vérifie la séparation mais ne prouve pas à elle seule l’ouverture à tous les utilisateurs publics. Révoquer une session met fin à cet accès de session ; cela n'interdit pas nécessairement une nouvelle connexion si le compte et ses droits restent autorisés. Inversement, réussir une authentification ne rétablit pas une habilitation retirée. Le NIST distingue l'événement d'authentification et la session qui en résulte ; la CNIL demande de supprimer les permissions devenues injustifiées, selon le périmètre.

Organiser des revues déclenchées et périodiques

Une revue intervient lors d’un départ, changement de rôle, incident, ajout d’intégration ou évolution du périmètre. Une revue périodique traite les comptes dormants, invitations ouvertes, groupes trop larges, clés anciennes et administrateurs uniques.

Le responsable métier confirme les besoins ; l’administrateur fournit la liste et applique les changements ; une seconde personne contrôle les droits critiques lorsque le risque le justifie. La revue ne valide pas automatiquement l’existant par silence.

Mesurez le nombre d’écarts corrigés et le délai de révocation plutôt que le volume de comptes parcourus. Un écart non corrigé reçoit un responsable, une échéance et une mesure compensatoire.

Journaliser pour comprendre sans surveiller excessivement

Les événements utiles sont création de compte, changement de rôle, connexion à risque, export, révocation et action administrative. Le journal associe un identifiant, une date, une action, un résultat et un périmètre. Il évite de recopier le contenu des documents, messages ou formulaires.

Les accès au journal sont eux-mêmes bornés. La durée répond à une finalité et à un risque ; elle n’est pas illimitée par défaut. Une horloge cohérente et des identifiants stables facilitent l’enquête et la correction.

Le journal aide à établir une chronologie ; il ne prouve pas automatiquement l’intention ni la responsabilité d’une personne. Toute interprétation reste prudente et contextualisée.

Checklist de gouvernance des accès

• Responsabilités décrites avant les permissions.
• Comptes nominatifs et comptes techniques séparés.
• Propriétaire métier et administrateur identifiés.
• Matrice objet/action/périmètre lisible.
• Récupération et MFA contrôlés.
• Arrivées, changements, absences et départs documentés.
• Refus inter-rôles et inter-organisations testés.
• Sessions, clés et invitations révocables.
• Journaux minimisés, protégés et bornés.
• Revue déclenchée et périodique avec corrections attribuées.

Limites et autonomie des produits

Cette méthode ne remplace pas une analyse de risque, une obligation sectorielle ou un conseil juridique. Les droits nécessaires dépendent des données, des rôles et de l’impact réel des actions.

Chaque application DOHM conserve ses comptes, rôles, sessions et données métier. My DOHM est le service public de reconnaissance et de passage fédéré entre les applications, lorsque ce passage est disponible et qualifié pour le produit concerné. Il ne remplace pas l’inscription native ni l’accès direct. La révocation du rattachement ne doit pas fermer l’accès natif du produit.