Pouvez-vous provisionner et déprovisionner les utilisateurs de manière fiable ? Liste de contrôle pour les applications auto-hébergées
Une liste de contrôle pratique pour tester la création de comptes, les changements d’autorisations, la désactivation et les cas particuliers dans une application auto-hébergée.
Considérez le cycle de vie des comptes comme un processus opérationnel
Le provisionnement des utilisateurs ne se limite pas à la création d’un compte. Il peut aussi comprendre la mise à jour des comptes et leur suppression dans différentes applications et différents systèmes, comme le décrit [OneLogin](https://www.onelogin.com/learn/what-is-user-provisioning-and-deprovisioning/). La planification d’un déploiement de provisionnement automatique fait également l’objet de recommandations de [Microsoft Entra](https://learn.microsoft.com/en-us/entra/identity/app-provisioning/plan-auto-user-provisioning).
Pour une application auto-hébergée, documentez les étapes qui s’appliquent à votre méthode de gestion des comptes et vérifiez les comportements propres à l’application et au fournisseur d’identité dans leur documentation officielle.
- Invitation ou création du compte, puis activation
- Attribution et modification des rôles ou des groupes
- Suspension, départ et éventuelle réactivation
- Gestion des contenus, intégrations et identifiants associés au compte
Déterminez comment les comptes sont créés dans l’application
Documentez le processus réellement utilisé : saisie manuelle par un administrateur, invitation, intégration d’annuaire ou autre méthode. Ce sont des possibilités à examiner, pas des fonctionnalités à présumer.
Pour chaque méthode, indiquez qui lance l’action, quelles informations sont requises et comment confirmer que le compte est prêt à être utilisé. Les effets d’une invitation non acceptée — par exemple sur l’accès au contenu ou l’occupation d’une licence — sont à vérifier pour l’application concernée.
- Consignez la source de référence des attributs d’identité, comme le nom et l’adresse e-mail.
- Testez une invitation acceptée, une invitation non acceptée et une invitation envoyée à une adresse incorrecte.
- Avant de bâtir un processus autour d’une intégration, vérifiez qu’elle est documentée pour l’application.
Testez les rôles, les groupes et les changements d’attribution
Une connexion réussie ne suffit pas à confirmer que les autorisations sont correctes. Si l’accès dépend de rôles dans l’application, de groupes du fournisseur d’identité ou d’une correspondance entre les deux, suivez le parcours depuis l’attribution initiale jusqu’aux droits visibles dans l’application.
Testez aussi les modifications et les suppressions d’attributions. Définissez le résultat attendu selon la politique de votre organisation, puis vérifiez le comportement de l’application.
- Testez un nouvel utilisateur en lui accordant uniquement les accès nécessaires.
- Modifiez puis supprimez un groupe ou un rôle et vérifiez les autorisations obtenues.
- Modifiez une correspondance et déterminez si les comptes concernés sont mis à jour ou nécessitent une intervention.
- Documentez le traitement d’une attribution absente ou ambiguë.
Vérifiez ce que la désactivation révoque réellement
Ne confondez pas le statut du compte avec la révocation de tous les autres moyens d’accès. Dans un test contrôlé, vérifiez le comportement des sessions actives, des identifiants d’API, des jetons d’accès personnels et des comptes connectés, selon les mécanismes utilisés par votre équipe.
Examinez aussi les ressources associées au compte. Une personne qui quitte l’organisation peut être propriétaire de contenus ou d’intégrations dont d’autres ont encore besoin. Définissez si ces éléments doivent être transférés, conservés, supprimés ou examinés, et qui approuve la décision.
- Après la désactivation, testez une nouvelle connexion et une session existante.
- Inventoriez les identifiants et comptes connectés, puis vérifiez leur procédure de révocation.
- Vérifiez si la suppression du compte est réversible et si elle affecte les contenus ou l’historique d’audit.
- Désignez un responsable et un circuit d’approbation pour les ressources d’une personne qui quitte l’organisation.
Gérez les exceptions sans créer de comptes non maîtrisés
Les prestataires, collaborateurs temporaires, administrateurs, comptes de service et comptes d’accès d’urgence peuvent suivre un processus différent de celui des employés. Définissez la manière dont chaque catégorie est créée, examinée et supprimée.
Pour chaque exception, consignez un responsable, une finalité, les accès autorisés et une date de révision ou un déclencheur de suppression. Pour les accès d’urgence, documentez les protections et la manière dont l’utilisation est examinée.
- Indiquez quelles catégories sont gérées par la source d’identité principale.
- Attribuez à chaque compte non personnel un responsable humain et une finalité documentée.
- Fixez une date de révision ou d’expiration pour les accès temporaires et ceux des prestataires.
- Incluez les exceptions dans les revues d’accès et les procédures de départ.
Testez les défaillances et les changements d’identité
Préparez des tests contrôlés pour les délais, les interruptions de connectivité et les changements d’identité. Le résultat dépend de l’application et de l’intégration : établissez le comportement attendu à partir de leur documentation, puis comparez-le à ce que vous observez.
Vérifiez notamment comment le système traite un nom ou une adresse e-mail modifiés, une identité en double ou un compte supprimé puis recréé. Confirmez les règles de correspondance avant de les appliquer aux comptes réels.
- Si votre configuration le permet sans risque, mettez en pause un processus de synchronisation et observez comment le retard est détecté et résolu.
- Testez le comportement prévu en cas d’indisponibilité du fournisseur d’identité.
- Avec un compte de test, examinez les changements de nom ou d’adresse e-mail, les doublons et les échecs de provisionnement.
- Désignez la personne chargée d’examiner les défaillances et de confirmer le rétablissement de l’état attendu.
Élaborez une matrice de test reproductible
Transformez les scénarios prioritaires en un test d’acceptation. Les [recommandations de Microsoft Entra](https://learn.microsoft.com/en-us/entra/identity/app-provisioning/plan-auto-user-provisioning) aident à planifier un déploiement de provisionnement automatique ; complétez-les avec la documentation de l’application et du fournisseur d’identité. La matrice ci-dessous est un plan de vérification, et non une description des fonctions d’une application particulière.
Utilisez des identités de test distinctes des utilisateurs en production. Pour chaque scénario, consignez le résultat attendu et observé, les éléments de preuve et la personne chargée du suivi.
- Création et activation : le compte est-il créé et prêt à être utilisé par la méthode documentée ?
- Changement d’accès : les ajouts et retraits de rôles ou de groupes produisent-ils les droits attendus ?
- Départ et réactivation : que deviennent le compte, les sessions, les identifiants et les accès conservés ?
- Exceptions et défaillances : comment sont traités les retards, les identités modifiées ou en double et les mises à jour échouées ?
- Responsabilités : qui gère les comptes, les ressources et les problèmes non résolus ?
Attribuez les responsabilités et évaluez le modèle d’hébergement
Attribuez un responsable à chaque étape. Les administrateurs d’identité peuvent gérer les identités sources et les groupes ; les administrateurs de l’application peuvent gérer les rôles locaux, les contenus et les intégrations. Précisez comment les exceptions sont approuvées et comment les changements échoués ou retardés sont remontés.
L’hébergement géré peut réduire le travail lié à l’infrastructure, mais ne définit pas à lui seul la gestion des comptes ni la gouvernance des accès. Airbip propose le déploiement géré des applications de son catalogue sous forme de charges de travail Docker sur ses serveurs cloud, avec routage et automatisation TLS, vérifications DNS, gestion du cycle de vie des services et sauvegardes configurables. Ces capacités d’infrastructure ne constituent pas, à elles seules, une intégration de provisionnement des utilisateurs. Évaluez séparément les fonctions de l’application et le modèle de déploiement au regard de vos exigences.
- Désignez des responsables pour la source d’identité, les autorisations de l’application et les exceptions.
- Définissez qui examine les accès et résout les divergences.
- Prévoyez le traitement des données et intégrations appartenant à un utilisateur qui quitte l’organisation.
- Comparez les options de déploiement géré et autogéré à vos exigences opérationnelles.
Questions fréquentes
Que comprend le provisionnement des utilisateurs ?
Il peut comprendre la création de comptes, leur mise à jour et leur suppression dans différentes applications et différents systèmes. Les étapes précises dépendent de l’application et de la méthode de gestion des comptes.
Une intégration avec un fournisseur d’identité gère-t-elle automatiquement tout le cycle de vie des comptes ?
Ne le présumez pas. Vérifiez dans la documentation de l’application et du fournisseur d’identité la prise en charge des créations, mises à jour, changements d’accès, désactivations, sessions et identifiants.
Que faut-il tester avant d’adopter une application auto-hébergée ?
Testez la création et l’activation des comptes, les changements d’accès, la désactivation et la réactivation, les exceptions, les défaillances et les ressources liées aux utilisateurs. Consignez les résultats attendus et observés.
L’hébergement géré prend-il en charge la gestion des accès des utilisateurs ?
Pas nécessairement. Vérifiez les fonctions de gestion des comptes de l’application et définissez qui, dans votre organisation, gouverne les identités, les autorisations et les données des utilisateurs.
Sources et lectures complémentaires
- Plan an automatic user provisioning deployment for Microsoft Entra ID — Microsoft Learn
- What is User Provisioning & Deprovisioning? — OneLogin