Outil interne : remplacer les comptes partagés par des accès individuels
Des accès individuels permettent d’attribuer les actions, de retirer un accès et d’appliquer des droits selon le rôle. Un compte partagé rend ces opérations plus difficiles, même si le mot de passe est régulièrement changé.
Quel problème le compte partagé crée-t-il ?
Plusieurs personnes agissent sous la même identité. Le journal ne permet plus de savoir qui a modifié une donnée et le départ d’un collaborateur impose une gestion collective du secret. Une activité enregistrée sous ce compte ne peut pas être attribuée avec certitude à une personne.
Les recommandations OWASP sur l’authentification constituent une référence technique pour construire les mécanismes d’accès. Le choix des rôles doit aussi correspondre à l’organisation réelle de l’entreprise.
Quels rôles définir ?
Partez des tâches : consulter, modifier, valider, exporter ou administrer. Ne donnez pas les droits d’administration à toute l’équipe pour éviter de concevoir une permission plus précise. Le cadrage des droits d’application aide à relier rôle et action.
| Situation | Contrôle attendu |
|---|---|
| Arrivée d’un collaborateur | Accès au rôle nécessaire |
| Changement de fonction | Révision des droits existants |
| Départ | Retrait de l’accès et des sessions selon le dispositif |
| Intervention externe | Périmètre et durée adaptés |
Le SSO résout-il tout ?
Une connexion via le fournisseur d’identité peut simplifier l’entrée et la sortie des utilisateurs si l’intégration est correctement faite. Elle ne définit pas automatiquement les autorisations métier dans votre application. Vérifiez aussi les comptes locaux résiduels et les accès techniques utilisés par les intégrations.
Séparez les comptes humains des comptes de service. Un traitement automatisé ne doit pas dépendre sans raison du compte personnel d’un salarié. Les secrets d’intégration doivent rester gérés selon leur usage, hors des écrans et journaux inutiles.
Comment migrer sans bloquer l’équipe ?
Inventoriez utilisateurs, rôles et traitements qui utilisent le compte commun. Créez les accès individuels, testez leurs droits et vérifiez la journalisation avant de retirer le compte partagé. Préparez une procédure de récupération maîtrisée.
Testez enfin un départ et une tentative d’action hors rôle. La réussite de connexion ne prouve pas que les accès sont correctement limités. Conservez les résultats par rôle, sans enregistrer les mots de passe ni les jetons dans la preuve de recette.
Sources
Documentation consultée le 24 octobre 2026.
Questions fréquentes
Un compte individuel suffit-il à tout sécuriser ?
Non. Il faut aussi des droits adaptés, une gestion des sessions et une procédure de retrait des accès.
Faut-il imposer le SSO ?
Le choix dépend des outils et de l’organisation. Vérifiez qu’il simplifie réellement la gestion tout en couvrant les accès locaux.
Comment traiter les automatisations ?
Identifiez les comptes de service et leurs permissions, sans les confondre avec les utilisateurs humains.
Que doit contenir le journal ?
Les actions utiles, leur date et l’identité concernée, avec une protection et une conservation adaptées aux données traitées.
Quel test révèle une permission trop large ?
Un utilisateur d’un rôle limité ne doit pas pouvoir exécuter une action interdite en appelant directement sa destination technique.