Reprendre les rôles et les droits de l'IA depuis la gestion des identités
Une plateforme d'IA devrait reprendre la connexion, les groupes et les rôles de la gestion des identités existante, par exemple Active Directory ou Entra ID, au lieu de gérer ses propres comptes. La connexion passe par les standards LDAP, OpenID Connect ou SAML. Arrivées, mutations et départs s'appliquent alors aussitôt dans l'IA, les mots de passe restent dans l'annuaire et les partages dans l'IA reposent sur des groupes existants. Peu de rôles et un second facteur sont essentiels.
Pourquoi l’IA ne devrait-elle pas avoir ses propres comptes ?
Chaque application qui gère ses propres comptes est un endroit de plus où l’on oublie des départs. Pour une plateforme d’IA qui accède aux documents, aux e-mails et aux logiciels métier, ce serait un risque. Dans le module ORP.4 de l’IT-Grundschutz, le BSI (l’office fédéral allemand de la sécurité informatique) exige que les identités et les droits soient attribués, modifiés et retirés de manière encadrée. Le plus sûr est que l’IA ne soit pas une source d’identités à part, mais qu’elle utilise la gestion des identités existante.
Quels standards existent pour la connexion ?
| Standard | À quoi il sert | Courant avec |
|---|---|---|
| LDAP | interroger un annuaire : personnes, groupes, attributs | Active Directory, OpenLDAP |
| OpenID Connect (OIDC) | connexion via un fournisseur d’identité central, sur la base d’OAuth 2.0 | Entra ID, Keycloak, de nombreux services cloud |
| SAML 2.0 | connexion via un fournisseur d’identité central, basé sur XML | fournisseurs d’identité plus anciens, portails de l’administration |
| SCIM | créer et supprimer automatiquement des comptes et des groupes | annuaires cloud |
Avec OIDC et SAML, l’application ne voit jamais le mot de passe : elle redirige vers le fournisseur d’identité pour la connexion et reçoit en retour une confirmation signée, souvent avec les groupes de la personne. Un second facteur peut y être imposé de façon centralisée.
Comment les groupes deviennent-ils des droits dans l’IA ?
La gestion des identités dit qui est une personne et à quels groupes elle appartient. Ce qu’un groupe peut faire dans l’IA est défini par la plateforme d’IA. Les bonnes pratiques :
- Peu de rôles : les personnes qui utilisent l’IA et les administrateurs qui la configurent. Chaque rôle supplémentaire doit être entretenu et contrôlé.
- Partages avec des groupes : apps, collections de connaissances et modèles sont partagés avec des groupes, pas avec des noms individuels. Si quelqu’un change de service, ses partages changent avec lui.
- Les droits des logiciels métier y restent : ce qu’une personne peut voir dans SharePoint, dans l’outil de tickets ou dans l’ERP reste décidé par ce système. L’IA lit avec le propre accès de la personne. Droits d’accès de l’IA aux documents →
- Pas de nouveaux profils : l’IA ne crée pas sur les personnes de caractéristiques propres allant au-delà de l’annuaire. Cela facilite aussi les échanges avec les représentants du personnel.
Que se passe-t-il à l’arrivée, à la mutation et au départ ?
- Arrivée : avec son compte dans l’annuaire, la personne peut se connecter ; ses partages découlent de ses groupes.
- Mutation : nouveau service, nouveaux groupes, nouveaux partages, sans intervention manuelle dans l’IA.
- Départ : bloquer le compte dans l’annuaire, et la connexion suivante à l’IA échoue. Vérifiez la durée des sessions et si les clés personnelles d’accès aux interfaces sont révoquées.
- Revue régulière : qui est administrateur de l’IA ? Quels groupes ont quels partages ? Une fois par trimestre est une bonne mesure.
Pour l’Autriche : la connexion d’ID Austria et du Portalverbund (le réseau de portails de l’administration autrichienne) est expliquée dans le guide ID Austria et IA.
Comment cela fonctionne-t-il avec basebox ?
La connexion à basebox passe par Keycloak avec OpenID Connect ; basebox elle-même ne voit jamais de mot de passe. Toute gestion des identités qui parle LDAP, OIDC ou SAML peut être connectée, par exemple Active Directory, Entra ID ou WSO2. Chacun se connecte avec le compte qu’il possède déjà ; groupes et rôles proviennent de votre gestion des identités, et ce qui y change s’applique aussi dans basebox. Un second facteur peut être activé par organisation, avec une application d’authentification ou, en option, par SMS via une passerelle que vous connectez. Les règles de mot de passe, la durée des sessions et le blocage après des tentatives infructueuses sont paramétrés par votre administrateur dans Keycloak.
basebox compte volontairement peu de rôles : personnes et administrateurs. Votre administrateur active ce qui est disponible ; la personne qui crée une app la partage avec des groupes ou des personnes, pour l’utiliser ou la modifier. Les modèles aussi peuvent n’être partagés qu’avec certains groupes. Les rôles proviennent de votre gestion des identités ; aucun nouveau profil n’est créé. Dans le cloud, chaque organisation dispose de sa propre gestion des identités (Keycloak). Les modifications de droits sont consignées dans le journal d’audit.
Questions fréquentes
Quelle est la différence entre LDAP, OIDC et SAML ?
LDAP est un protocole pour interroger un annuaire, par exemple sur les personnes et les groupes ; Active Directory le parle. OpenID Connect et SAML sont des méthodes de connexion via un fournisseur d'identité central : l'application ne voit pas le mot de passe, mais reçoit une confirmation signée de l'identité de la personne connectée, souvent avec ses groupes.
Faut-il créer de nouveaux groupes dans l'annuaire pour l'IA ?
Les groupes existants suffisent en général, par exemple les services ou les catégories professionnelles. De nouveaux groupes sont utiles si une app ou un modèle n'est destiné qu'à un cercle qui n'existe pas encore dans l'annuaire, par exemple un groupe de projet.
En combien de temps une personne perd-elle l'accès après son départ ?
Cela dépend de la méthode : si le compte est bloqué dans l'annuaire, la connexion suivante échoue immédiatement. Les sessions déjà ouvertes prennent fin à l'expiration de leur durée paramétrée. Ne fixez donc pas une durée de session trop longue.
Sources
Cet article a été créé avec l’aide de l’IA, sur la base des sources citées. Responsable du contenu : basebox GmbH. Ceci n’est pas un conseil juridique, aucune responsabilité. État de la recherche : 11 octobre 2026.