En résumé
Les agents IA ne sont plus des outils : ce sont des acteurs qui agissent dans le système d’information. Ils ont des droits d’accès, des périmètres d’action, des capacités d’exécution. La gestion des identités et des accès devient le lieu où cette délégation se matérialise. Mais elle ne résout pas tout : elle trace, elle limite, elle sépare. Elle ne résout ni l’opacité, ni la compréhension, ni la responsabilité. La responsabilité, elle, reste humaine. En l’état actuel du droit et des cadres de gestion des risques, la réponse qui se dessine est qu’elle remonte au dirigeant qui a validé le déploiement, par le mécanisme du take. Cette réponse est discutable. Elle est la plus cohérente avec les cadres existants, mais elle n’est pas définitive.
La délégation n’est plus une abstraction
Pendant des années, la délégation de décision à l’IA est restée un sujet théorique. On parlait de modèles qui recommandaient, qui suggéraient, qui éclairaient. L’humain restait dans la boucle. Il validait, il corrigeait, il décidait.
Ce temps est révolu. Les agents IA ne se contentent plus de répondre. Ils consultent des données, appellent des API, modifient des enregistrements, lancent des campagnes. Ils agissent. Et leurs actions ont des conséquences réelles dans le système d’information.
Un agent IA qui a accès à un CRM peut modifier une fiche client. Un agent IA qui a accès à un ERP peut passer une commande. Un agent IA qui a accès à un dépôt de code peut modifier un programme. Ces actions ne sont pas des recommandations. Ce sont des actes. Et ces actes engagent l’organisation.
L’IA comme acteur dans le système d’information
Ce qui change avec les agents IA
Un compte de service classique exécute des tâches prédéfinies. Son comportement est connu. Ses droits sont limités. Ses actions sont prévisibles.
Un agent IA, lui, peut prendre des initiatives. Il peut décider de consulter une donnée, d’appeler une API, de modifier un enregistrement. Il peut le faire pour atteindre l’objectif qu’on lui a fixé, sans que personne n’ait anticipé chaque action individuelle.
Cela signifie que les droits d’accès ne sont plus seulement des permissions techniques. Ils deviennent des délégations de pouvoir. Accorder un droit à un agent IA, c’est lui donner la capacité d’agir sur le système. C’est une décision de gouvernance.
L’explosion des identités non-humaines
Dans un système d’information, toute entité qui agit possède une identité. Pendant longtemps, ces identités étaient humaines. Elles étaient créées pour des personnes, ou pour des applications dont le comportement était prévisible et documenté.
Les agents IA changent la donne. Ils ont besoin d’identités propres. Ils ont besoin de droits d’accès. Ils ont besoin d’être authentifiés, autorisés, tracés. Leur nombre explose. Une organisation qui comptait quelques centaines de comptes de service peut se retrouver avec des milliers d’agents IA, chacun avec ses propres droits.
Ce que la gestion des droits d’accès fait (et ne fait pas)
Ce qu’elle fait
La gestion des droits d’accès empêche les opérations effectuées par des intervenants qui n’ont pas le droit formel de les effectuer. Elle trace. Elle limite. Elle sépare. Elle attribue.
L’automatisation des requis de contrôle apporte deux gains mesurables. Le premier est la traçabilité : chaque opération est enregistrée, horodatée, attribuée. Le second est la garantie du respect du cadre de référence : les règles sont appliquées de manière systématique, sans dépendre de la mémoire ou de la discipline des intervenants.
Ce qu’elle ne fait pas
Elle ne vérifie pas que l’action est pertinente. Elle ne vérifie pas que le contexte est approprié. Elle ne vérifie pas que l’agent IA a bien interprété sa mission. Elle ne remplace ni le jugement humain, ni la supervision, ni l’audit.
La gestion des droits d’accès n’est pas un dispositif de contrôle interne à elle seule. C’est une barrière parmi d’autres. Elle fait ce pour quoi elle est faite. Elle ne prétend pas faire plus.
Le modèle de Reason : une barrière parmi d’autres
Le modèle de Reason décrit la sécurité comme une série de barrières superposées. Chaque barrière a des trous. Un accident survient quand les trous s’alignent. Aucune barrière n’est suffisante à elle seule.
La gestion des droits d’accès est l’une de ces barrières. Elle a ses trous : un agent IA peut avoir les bons droits mais agir dans un contexte imprévu ; un superviseur peut valider sans comprendre ; une règle peut être contournée. Elle ne remplace pas les autres barrières : le contrôle de supervision, l’audit, la formation, la culture de vigilance.
La gestion des droits d’accès s’inscrit dans une tradition de gouvernance des systèmes d’information, structurée par des cadres comme COBIT. Le contrôle interne et le management des risques s’inscrivent dans une autre tradition, structurée par des cadres comme COSO. Ces deux traditions sont compatibles et complémentaires. Elles ne répondent pas aux mêmes questions. La première organise les processus et les contrôles techniques. La seconde porte la responsabilité et définit l’appétence au risque.
La question de la responsabilité
Qui est responsable quand une IA agit ?
Si un agent IA modifie une fiche client, passe une commande, émet une facture, qui est responsable ?
Le manager qui a délégué la décision ? Il n’a pas fixé chaque action individuelle. Il a fixé un objectif.
L’éditeur du modèle ? Il n’a pas accès aux données de l’entreprise. Il ne connaît pas le contexte.
L’entreprise ? Elle a donné les droits d’accès. Elle a autorisé l’agent à agir.
La question n’est pas rhétorique. Elle a des implications juridiques, managériales et éthiques. Et aujourd’hui, elle n’a pas de réponse définitive.
Le take : la réponse qui se dessine
La responsabilité du bien-fondé des décisions de l’IA ne peut pas revenir à l’IA. Elle ne peut pas non plus être diluée dans la chaîne de supervision. En l’état actuel des cadres juridiques et des référentiels de gestion des risques, la réponse qui se dessine est qu’elle remonte à la personne qui a validé le déploiement : le dirigeant.
C’est un take au plus haut niveau. Le dirigeant accepterait le risque de déployer un système dont il ne peut pas comprendre toutes les décisions. Il accepterait que certaines actions de l’IA produisent des effets non anticipés. Il accepterait que la responsabilité lui revienne, même s’il ne contrôle pas chaque action.
Cette réponse s’appuie sur des notions déjà reconnues par la réglementation : l’appétence au risque, la responsabilité de la direction, l’obligation de rendre compte. Le déploiement de l’IA s’inscrirait dans ce cadre.
Elle est discutable. Elle sera contestée. Elle sera mise à l’épreuve. C’est le sort de toute réponse dans un domaine en évolution.
La supervision : unitaire et de supervision
La distinction
Le contrôle unitaire vérifie chaque opération. Il s’exerce en temps réel, au moment de l’action. Le contrôle de supervision vérifie que le dispositif de contrôle fonctionne. Il s’exerce a posteriori, sur la base des restitutions.
Cette distinction n’est pas nouvelle. C’est le fondement du contrôle interne.
Ce qui change avec l’IA
L’IA effectue le contrôle unitaire. Elle vérifie chaque action selon les règles qui lui ont été fixées. Le superviseur effectue le contrôle de supervision. Il ne vérifie pas tout. Il échantillonne. Il teste. Il conclut.
La supervision n’est pas la vérification unitaire de chaque opération. Ce n’est pas matériellement possible. Seule une approche par échantillonnage peut le résoudre. Le superviseur valide une synthèse produite par l’IA. Il ne peut pas reconstituer chaque contrôle unitaire. Il valide sur la base de ce qu’il peut vérifier, et sur la base de la confiance qu’il accorde au dispositif.
Cette validation est un acte de supervision, pas un acte de compréhension. Elle est nécessaire. Elle n’est pas suffisante.
Ce qui reste ouvert
L’opacité est insoluble
L’opacité des modèles de deep learning n’est pas un défaut de conception. C’est une propriété structurelle. On ne peut pas expliquer comment un réseau de neurones prend une décision, parce qu’il ne suit pas un raisonnement logique : il reconnaît une configuration. Cette opacité est insoluble. On ne cherche pas à la résoudre. On compose avec.
La formation des superviseurs
Superviser un agent IA demande des compétences nouvelles : comprendre ses limites, ses biais, ses angles morts. Ces compétences ne sont pas encore codifiées. Elles ne sont pas encore enseignées. C’est un chantier à ouvrir.
L’audit
L’audit devra se doter de nouveaux outils. Un système neurovégétatif de gestion des risques, qui analyse les données brutes et détecte les patterns, en fait partie. Mais il ne s’agit pas de deux IA qui se vérifient mutuellement. Ce sont deux IA qui analysent les mêmes éléments sous deux angles différents. L’auditeur humain les croise, les interprète, et conclut.
La législation
La législation évoluera avec du retard, mais elle évoluera. La réglementation a déjà validé le principe du take du dirigeant. Le déploiement de l’IA s’inscrira dans ce cadre. Les textes préciseront les obligations, les responsabilités, les sanctions. Mais le principe est déjà posé : la responsabilité ne peut pas être transférée à une machine.
Ce qu’il faut retenir
La délégation à l’IA déplace le centre de gravité de la gestion des risques. Le risque n’est plus seulement que l’IA se trompe. Il est qu’elle agisse sans que personne ne sache qui a autorisé quoi, et qui est responsable de quoi.
Le système de gestion des droits d’accès répond à une partie du problème. Il trace, il limite, il sépare. Mais il ne résout pas l’opacité, ni la compréhension, ni la responsabilité. Ces questions restent ouvertes. Elles sont intrinsèques à l’IA. On ne les résout pas. On compose avec.
La responsabilité, elle, n’est pas définitivement tranchée. Mais une réponse se dessine : elle remonterait au dirigeant qui a validé le déploiement, par le mécanisme du take. Cette réponse est cohérente avec les cadres existants. Elle sera discutée. Elle sera contestée. Elle sera mise à l’épreuve. C’est le sort de toute réponse dans un domaine en évolution.
Questions fréquentes
Qu’est-ce qu’une identité non-humaine ?
C’est une identité dans un système d’information qui n’est pas associée à une personne physique. Les comptes de service, les applications, et désormais les agents IA sont des identités non-humaines.
Pourquoi les agents IA changent-ils la gestion des accès ?
Parce qu’ils ne se contentent pas d’exécuter des tâches prédéfinies. Ils prennent des initiatives, dans le périmètre des droits qu’on leur a accordés. Leurs droits d’accès deviennent des délégations de pouvoir.
Qui est responsable quand un agent IA agit ?
En l’état actuel du droit et des cadres de gestion des risques, la responsabilité remonterait au dirigeant qui a validé le déploiement, par le mécanisme du take. Cette réponse est la plus cohérente avec les cadres existants, mais elle reste discutée.
Qu’est-ce que le take en gestion des risques ?
C’est l’acceptation d’un risque. Dans le cas de l’IA, le dirigeant accepterait le risque de déployer un système dont il ne peut pas comprendre toutes les décisions. Il l’assumerait. Il en répondrait. C’est la réponse qui se dessine aujourd’hui.
Qu’est-ce que le moindre privilège appliqué aux agents IA ?
C’est le principe selon lequel un agent IA ne doit avoir que les droits strictement nécessaires à ses fonctions. Son périmètre d’action doit être limité, documenté et révisable.
Qu’est-ce que la transparence des limites ?
C’est la documentation du périmètre d’action d’un agent IA : quelles données il utilise, quels objectifs il poursuit, quelles actions il peut entreprendre, quelles actions lui sont interdites.
Qu’est-ce que l’automatisation invisible ?
C’est une situation où une action a été entreprise par un agent IA sans que personne ne puisse dire où s’arrête le jugement humain et où commence la décision algorithmique. Elle crée un vide de responsabilité.
La gestion des droits d’accès suffit-elle à contrôler les agents IA ?
Non. Elle est une barrière parmi d’autres. Elle trace, elle limite, elle sépare. Elle ne résout ni l’opacité, ni la compréhension, ni la responsabilité.
Pourquoi la gestion des accès devient-elle un enjeu de gouvernance ?
Parce qu’elle définit ce que l’IA peut faire. Elle matérialise la délégation. Elle rend visible le pouvoir accordé aux agents. C’est une décision stratégique, pas seulement technique.
Faut-il interdire aux agents IA d’agir dans le système d’information ?
Non. Les agents IA apportent des capacités que l’humain ne peut pas égaler. Mais leur pouvoir doit être défini, limité et supervisé. C’est une question de gouvernance, pas de prohibition.
Pour aller plus loin
-
La délégation sans responsabilité : le risque invisible de l’IA
-
L’IA n’est pas un outil, c’est un acteur
-
Le nouveau contrat de pouvoir : gouverner par les contraintes
-
La gestion des risques en entreprise — le cadre, le processus et les limites.
-
Le contrôle interne — les dispositifs de maîtrise et leur articulation avec la gestion des risques.
-
Appétence au risque — ce que valider un niveau de risque veut vraiment dire.
-
Le Guide du manager à l’ère de l’IA — le nouveau contrat de pouvoir. À paraître.