Authentification et gestion des accès : les bons droits, pour les bonnes personnes, au bon moment.
Un accès n'est jamais figé.
Connexion, rôles, sessions, arrivées, changements de fonction et départs : nous organisons qui accède à vos applications, à quoi, et jusqu'à quand.
Fiche d'accès d'une collaboratrice fictive, identifiant U-0418, compte actif, double authentification activée. Son rôle passe de chargée de clientèle à responsable d'équipe ; le changement est validé par sa responsable et appliqué par l'administrateur des accès. Dans le CRM, consulter et modifier sont conservés, exporter est ajouté. Dans l'application métier, l'accès à son seul portefeuille est retiré ; les dossiers de l'équipe et la réaffectation d'un dossier sont ajoutés. Dans l'espace documentaire, la lecture est conservée et la contribution ajoutée. L'administration n'est pas attribuée. Sa session en cours est maintenue.
Un changement de fonction, en cinq étapes
Des accès qui suivent les personnes, pas l'inverse.
Les applications changent peu ; les équipes changent tout le temps. Sans organisation, les accès s'accumulent, et personne ne sait plus très bien qui peut faire quoi.
Des comptes d'anciens collaborateurs encore actifs
Le départ a été traité dans l'outil principal, pas dans les autres.
Des droits qui s'additionnent de poste en poste
Chaque changement ajoute, rien n'est jamais retiré.
Des comptes partagés
Un identifiant pour plusieurs personnes : impossible de savoir qui a fait quoi.
Des accès techniques sans responsable
Une clé d'API ou un compte de service créés pour un projet, puis oubliés.
Ces situations ressortent souvent d'un audit de sécurité ; les corriger, et éviter qu'elles reviennent, relève de la gestion des accès.
Qui se connecte, ce qu'il peut faire, jusqu'à quand : trois sujets distincts.
On les confond souvent. Ils se conçoivent pourtant séparément, et chacun a ses propres mécanismes.
Qui se connecte ?
Authentification
Vérifier l'identité revendiquée avec le dispositif prévu : un mot de passe, une double authentification, le compte de l'entreprise.
Que peut-il faire ?
Autorisation
Les opérations permises par son rôle, et parfois selon la ressource : ses dossiers, ceux de son équipe. L'application doit ensuite vérifier ces droits à chaque requête.
Jusqu'à quand ?
Gestion des habilitations
Attribuer les droits à l'arrivée, les modifier quand la fonction change, les retirer au départ. Les accès temporaires et les situations exceptionnelles entrent aussi dans ce cycle.
La double authentification protège la connexion ; elle ne dit rien de ce qu'on peut faire une fois connecté.
Exemple d'autorisation par rôle : sur la plateforme Wolfo, le client, les agents, les managers et les partenaires disposent chacun de leur espace, et ne voient d'un même dossier que ce qui relève de leur rôle.
Une collaboratrice, des droits qui évoluent : de l'arrivée au départ.
Scénario fictif : une chargée de clientèle rejoint l'entreprise, devient responsable d'équipe, puis la quitte. Choisissez une étape pour voir ses applications, ses droits, ses sessions et les validations nécessaires.
Étapes du parcours
Outil tiers : messagerie d'équipe
4. Changement de fonction · 4 ajoutés, 1 retiré, 1 en attente · outil tiers à traiter
Étape 4 sur 5, Changement de fonction, messagerie d'équipe non intégrée. Compte actif, le même compte. 4 ajoutés, 1 retiré, 1 en attente · outil tiers à traiter. Messagerie d'équipe non intégrée : le changement de fonction ne lui parvient pas. Son rôle reste celui de chargée de clientèle tant qu'il n'est pas mis à jour à la main.
- Identité
- Identifiant U-0418 · collaboratrice fictive
- Compte
- actif, le même compte
- Fonction
- Responsable d'équipe, auparavant chargée de clientèle
- Rôle
- Encadrement d'équipe
- Applications accessibles
- 4 sur 5CRM, Application métier, Espace documentaire, Messagerie d'équipe
- À cette étape
- 4 ajoutés, 1 retiré, 1 en attente · outil tiers à traiter
Attention : Messagerie d'équipe non intégrée : le changement de fonction ne lui parvient pas. Son rôle reste celui de chargée de clientèle tant qu'il n'est pas mis à jour à la main.
Habilitations par application
CRMclients et contacts
- Consulter, conservé
- Modifier, conservé
- Exporter, ajouté
Application métierdossiers clients
- Son portefeuille de dossiersaccès limité à ses seuls dossiers, retiré
- Dossiers de l'équipe, ajouté
- Réaffecter un dossier, ajouté
Espace documentaireprocédures, modèles
- Lecture, conservé
- Contributiondu nouveau rôle, ajouté
Administrationparamètres, comptes
- Paramètres de l'équipevalidation requise, en attente
Messagerie d'équipeoutil tiers
- Compte, conservé
- Rôle de membreinchangé, conservé
- Rôle d'animatriceà attribuer à la main, à traiter
Authentification et sessions
- fait : Session maintenue. Selon l'application, les nouveaux droits s'appliquent aussitôt ou à la prochaine connexion.
- en attente : Nouvelle authentification demandée avant la première action d'export.
Validations, demandes, interventions
- fait : Nouvelle fonction validée par la direction commerciale.
- fait : Droits de l'ancien poste retirés et droits du nouveau ajoutés par l'administrateur des accès, le même jour.
- fait : Demande de contribution temporaire close : la contribution fait désormais partie du rôle.
- en attente : Accès aux paramètres de l'équipe : en attente du responsable sécurité, non accordé.
- à traiter : Messagerie d'équipe sans intégration : le changement de fonction ne lui parvient pas. Son rôle reste à mettre à jour à la main.
Un changement de fonction retire aussi : les droits de l'ancien poste ne s'additionnent pas aux nouveaux.
- ajouté
- conservé
- retiré
- en attente
- à traiter
Scénario fictif : aucun compte ni système réel, aucune messagerie interrogée. Les droits ne changent jamais d'eux-mêmes : une administration, un circuit de validation ou une automatisation configurée les modifie.
Les mécanismes, choisis selon vos usages et mis en place avec mesure.
Selon l'application, ses utilisateurs et le périmètre convenu, ces mesures se combinent. Aucune n'est utile partout ; aucune ne suffit seule.
Se connecter
- Mots de passe bien gérés, ou connexion avec les comptes de l'entreprise
- Double authentification lorsque c'est pertinent, renforcée pour les droits sensibles
- Récupération et réinitialisation des accès sans contourner la sécurité
Être autorisé
- Rôles et permissions, au plus près des fonctions réelles
- Principe du moindre privilège : les droits nécessaires, rien de plus
- Droits liés aux ressources quand le rôle ne suffit pas
- Comptes administrateurs séparés et mieux protégés
Durer, retirer, tracer
- Sessions qui expirent, et invalidation lorsque c'est prévu
- Comptes techniques et clés d'API identifiés, limités, renouvelables
- Révocation des accès, y compris dans les outils reliés
- Journal des événements utiles : connexions, changements de droits, retraits
La double authentification réduit fortement le risque d'un mot de passe volé ; elle ne supprime pas à elle seule tout risque de compromission. Sa forme se choisit selon l'application et ses utilisateurs.
Toutes ces mesures ne sont pas comprises d'office : le périmètre retenu est écrit au devis. Les données elles-mêmes relèvent de la protection des données ; l'accès d'administration aux serveurs, de la sécurisation des infrastructures web.
Avec les comptes de votre entreprise, sans tout reconstruire.
La plupart des applications ont déjà des comptes et des rôles. Le point de départ est ce qui existe.
Une application existante
On reprend ses comptes, ses rôles et ses droits ; on retire ce qui ne sert plus, on ajoute ce qui manque, sans tout reconstruire. Que ce soit une plateforme métier ou un CRM ou un ERP, les règles d'accès s'écrivent avec ses fonctionnalités.
Un système d'identité déjà en place
Une connexion avec les comptes de l'entreprise est possible lorsque l'application et ce système sont compatibles et que le périmètre le prévoit. Les échanges entre outils relèvent des API et intégrations.
Un système d'identité règle la connexion, pas les droits dans chaque application. Les retraits dans les outils tiers demandent une intégration, ou une étape prévue dans la procédure de départ.
Définir, mettre en place, puis vérifier que chaque retrait fonctionne.
Un droit qu'on ne sait pas retirer est un droit acquis. Chaque étape se termine par une vérification, retraits compris.
Cadrage
Applications, utilisateurs, profils, systèmes d'identité : le périmètre est écrit avec vous.
Cartographie des droits
Qui a quoi aujourd'hui, et ce qui devrait changer.
Conception
Profils, droits par défaut, validations, durée des sessions, comptes administrateurs et techniques.
Mise en œuvre
Dans l'application, et dans les intégrations prévues.
Vérification
Chaque droit attribué, chaque retrait, chaque session coupée est essayé.
Documentation
La politique d'accès est écrite pour vos équipes. Une revue périodique des accès peut être prévue au contrat : maintenance et suivi de sécurité.
La vérification porte sur les mécanismes mis en place ; elle ne remplace pas un audit de sécurité complet de l'application. Nous n'administrons pas vos comptes au quotidien, sauf prestation prévue à cet effet.
Questions fréquentes sur l'authentification et la gestion des accès
Les questions qui reviennent avant de revoir les accès d'une application.
Quelle différence entre authentification et autorisation ?
L'authentification vérifie qui se connecte : un mot de passe, une double authentification, le compte de l'entreprise. L'autorisation décide de ce que cette personne peut faire une fois connectée : consulter, modifier, valider, administrer. Les deux sont nécessaires et distinctes : une connexion parfaitement vérifiée ne donne pas, à elle seule, le droit d'agir sur toutes les données.
À quoi sert l'authentification multifacteur ?
Elle demande une preuve en plus du mot de passe, par exemple un code ou une validation sur un appareil enrôlé. Un mot de passe volé ne suffit alors plus à se connecter. Elle réduit fortement ce risque, sans supprimer tous les autres : elle ne règle ni les droits excessifs, ni les comptes oubliés, ni les sessions laissées ouvertes.
Peut-on utiliser les comptes existants de l'entreprise ?
Souvent, oui : l'application peut confier la connexion au système d'identité déjà utilisé par vos équipes, lorsqu'ils sont compatibles et que le périmètre le prévoit. Les utilisateurs gardent un seul compte. En revanche, les droits dans l'application restent à définir : le système d'identité dit qui se connecte, pas ce que chacun peut y faire.
Comment retirer les accès lorsqu'un collaborateur quitte l'entreprise ?
Par une procédure de départ prévue à l'avance : le compte est désactivé à la bonne date, les droits sont retirés, les sessions ouvertes et les jetons délivrés sont invalidés lorsque l'application le permet, et les comptes techniques qu'il gérait changent de responsable. Les outils tiers demandent une intégration ou une étape explicite, sinon leurs accès restent actifs.
Peut-on gérer plusieurs rôles et niveaux de permission ?
Oui. Les rôles regroupent les droits d'un poste, comme chargé de clientèle, responsable d'équipe ou administrateur, et des niveaux plus fins s'ajoutent quand le rôle ne suffit pas : l'accès aux seuls dossiers de son équipe, par exemple. Le principe reste le même : chacun reçoit les droits dont il a besoin, et rien de plus.
Comment gérer les comptes techniques et les clés d'accès aux API ?
Ce sont des accès comme les autres, souvent plus puissants et moins surveillés. Chacun a un responsable identifié, des droits limités à son usage, des clés renouvelables et stockées hors du code, et un journal de ses actions. Les comptes administrateurs restent séparés des comptes de travail quotidiens. Une revue régulière supprime ceux qui ne servent plus.
Des accès définis, suivis et retirés au bon moment.
Une politique d'accès ne tient pas dans un tableau de permissions : elle suit les personnes. Nous la rédigeons avec vous, phase par phase, avant de la mettre en œuvre.
Politique d'accès
votre entreprise · à rédiger ensemble
À l'arrivée
création, attribution
- Qui valide l'attribution des accès ?
- Quels profils et quelles applications sont concernés ?
- Quels droits sont nécessaires, par défaut, pour chaque poste ?
Au changement de fonction
de poste, d'équipe
- Qui autorise les changements ?
- Quels droits retirer, et pas seulement ajouter ?
- Quelles validations pour les droits sensibles ?
Au départ
retrait, révocation
- Comment traiter les sessions actives et les jetons ?
- Comment retirer les accès aux systèmes tiers ?
- Comment vérifier que les retraits sont effectifs ?
Tout au long du cycle
- Quels événements doivent être journalisés ?
- Connexion et double authentification
- Durée des sessions
- Comptes administrateurs et techniques
- Comptes temporaires
- Systèmes d'identité à relier
- Revue périodique, si le contrat la prévoit
Une première réunion pose ces questions à partir de vos applications et de votre organisation réelle.
Vous repartez avec les profils, les droits et les étapes à mettre en place, et ce qui relève de vos outils existants.