Comment gouverner l’accès de l’IA aux systèmes ERP et financiers
L’IA se trouve désormais au cœur de vos systèmes financiers, prenant des décisions à une vitesse machine avec accès à des données qui étaient auparavant étroitement contenues dans les ERP. Si vous ne régissez pas explicitement comment les copilotes et les agents IA interagissent avec les systèmes critiques tels qu’Oracle, SAP, etc., vous vous exposez à des flux de données opaques, à des violations de la Ségrégation des Devoirs (SoD) invisibles, et à des identités « fantômes » qui persistent au-delà des projets et des personnes.
Les dirigeants financiers et informatiques subissent une pression croissante pour « mettre l’IA au travail » dans des domaines tels que la comptabilité générale (GL), les comptes fournisseurs (AP), les comptes clients (AR), et les prévisions. Les copilotes ERP natifs, les agents IA externes, et les assistants d’analyse lisent désormais des données financières, rédigent des écritures comptables, proposent des ajustements, et même initient des flux de travail que vos contrôles existants n’avaient jamais anticipés. Le problème est que les modèles d’accès traditionnels supposent des humains derrière des écrans. Lorsque l’IA devient l’utilisateur, vous obtenez des tokens à long terme, des clés API, ou des comptes de service au lieu de sessions éphémères, des comptes « bot » partagés au lieu d’identités responsables, et des chaînes d’accès complexes où vous ne pouvez plus répondre à des questions de base : qui a accédé à quoi, sous quelle politique, et au nom de qui.
Comment l’IA touche réellement les données ERP et financières
En pratique, l’IA accède à votre paysage ERP à travers trois principaux modèles.
Copilotes ERP natifs et IA intégrée
Les grands fournisseurs ERP expédient des copilotes intégrés et des fonctionnalités IA directement à l’intérieur du locataire ERP. Ces assistants fonctionnent souvent sous des attributions qui ressemblent à des rôles humains puissants ou bénéficient d’un large accès en lecture au nom de « meilleures informations », sans être modélisés comme des identités distinctes avec des privilèges distincts. Cela crée deux risques immédiats. D’une part, un assistant intégré peut voir bien plus que nécessaire pour exécuter son cas d’utilisation, y compris des livres sensibles, des entités ou des données RH qui ne devraient pas être dans son champ d’application. D’autre part, comme il n’est pas traité comme une identité gouvernée à part entière, son activité est difficile à distinguer du comportement des utilisateurs humains dans les journaux et les examens.
Agents IA externes et copilotes via API et connecteurs
Le deuxième modèle concerne les agents IA externes, copilotes, et plateformes d’automatisation qui se connectent à l’ERP via des API, des plateformes d’intégration, des connecteurs ou des outils de flux de travail. Ici, l’IA n’est pas « à l’intérieur » de l’ERP, mais elle a un accès puissant aux données et aux transactions par le biais de voies techniques initialement conçues pour l’intégration système à système, et non pour la prise de décision autonome. Ces architectures s’appuient souvent sur des clés API à long terme, des comptes de service partagés, ou des utilisateurs d’intégration avec des permissions larges. Lorsque plusieurs flux de travail IA partagent la même identité technique, il devient impossible d’attribuer de manière fiable des actions, de réaliser des analyses de SoD, ou d’aligner l’accès avec des cas d’utilisation spécifiques approuvés, ce qui rend presque impossible de démontrer un contrôle efficace aux auditeurs ou aux régulateurs.
IA fantôme autour de l’ERP
Le troisième modèle est l’IA fantôme : les équipes financières exportent des données ERP dans des feuilles de calcul, des outils BI, ou des lacs de données, puis alimentent ces données dans des outils IA non gérés. Aucun de ces outils ne fait peut-être partie de votre pile IA sanctionnée, et pourtant ils détiennent désormais des données financières et RH sensibles qui restent sous le coup de la réglementation. Comme ces flux contournent souvent les canaux d’intégration officiels, ils contournent également vos contrôles et votre surveillance existants.
Le fil conducteur : identités et données
Malgré les différences techniques, ces trois modèles se réduisent au même problème sous-jacent : des identités non gérées avec un accès puissant à des données financières sensibles. Que ce soit un copilote natif, un agent externe, ou un flux de travail IA fantôme, vous devez savoir quelles identités existent, quelles données elles peuvent atteindre, quelles actions elles peuvent exécuter, et comment ces privilèges sont approuvés, surveillés et révoqués au fil du temps.
Ce à quoi « bien » ressemble : principes de conception
Lorsque vous briefez le conseil d’administration ou votre comité d’audit, vous souhaitez montrer que l’IA suit la même discipline que celle que vous revendiquez déjà pour les utilisateurs privilégiés. Cela commence par trois principes :
Les agents IA sont des identités de premier plan. Chaque copilote, agent ou automatisation est défini comme sa propre identité avec un propriétaire, un but commercial, et un profil de risque, et non comme un compte technique partagé.
Accès basé sur des politiques, pas sur des tickets ad hoc. L’accès IA est accordé et modifié par le biais de flux de travail standard régis par des politiques et des règles de SoD, et non par des approbations ponctuelles enfouies dans des emails.
Des pistes prêtes pour l’audit de bout en bout. Pour chaque identité IA, vous pouvez montrer où elle réside, quels systèmes et données elle peut toucher, qui l’a approuvée, et quand elle a été examinée pour la dernière fois.
JML pour l’IA : Intégration, Changement, Départ
Pour la direction, il est utile de cadrer l’accès à l’IA dans le même langage de cycle de vie Intégration–Changement–Départ utilisé pour les personnes.
Intégration : onboarding d’un nouveau cas d’utilisation IA
Lorsque de nouveaux cas d’utilisation IA apparaissent— »agent IA pour le codage des factures AP », « copilote pour l’analyse GL », « assistant pour l’application des paiements »—vous souhaitez un chemin prévisible plutôt qu’une construction ponctuelle. D’abord, vous intégrez le cas d’utilisation. Capturez quel processus il soutient, quelles données il nécessite, quels ERP et modules il touche, et quelles réglementations s’appliquent. Soyez explicite sur le fait que l’IA est purement analytique (lecture seule) ou qu’elle peut initier ou approuver des transactions financières.
Ensuite, vous assignez la propriété et le risque. Chaque identité IA doit avoir un propriétaire commercial nommé et une classification de risque claire. Un assistant analytique en lecture seule pour des centres de coûts non sensibles n’est pas le même qu’un agent qui peut saisir des journaux dans le grand livre. La classification détermine la rigueur de vos contrôles, approbations et surveillances nécessaires.
Troisièmement, vous accordez l’accès par le biais de politiques. Au lieu de rassembler manuellement des rôles ERP et des permissions API, vous utilisez votre plateforme de gouvernance d’identité pour appliquer des politiques : quels rôles sont autorisés, quelles règles de SoD s’appliquent, quels approbateurs doivent signer, et quelles conditions sont attachées.
Changement : évolution du périmètre de l’IA
À mesure que les agents IA s’étendent à de nouvelles régions, entités ou modules, leur accès doit changer de manière contrôlée et examinable. Ici, vous définissez des déclencheurs pour les changements de périmètre. De nouveaux codes d’entreprise, des droits de publication ajoutés, l’accès à de nouveaux livres ou des domaines de données supplémentaires doivent automatiquement envoyer cette identité IA à un flux de travail de « changement ». Cela signifie que votre plateforme de gouvernance reconnaît le changement demandé comme un événement de risque, et non comme un simple ajustement de configuration.
Ensuite, vous réévaluez le risque et la SoD. Le moteur de gouvernance d’identité effectue à nouveau des contrôles de SoD et une notation des risques pour le nouveau périmètre. Si l’agent passe de lecture seule à écriture ou d’un grand livre à faible risque à une entité réglementée, les approbations s’intensifient en conséquence—souvent vers un propriétaire commercial plus senior ou un comité des risques.
Enfin, vous maintenez des privilèges stricts. Les agents analytiques restent en lecture seule. Les agents capables de transactions sont limités à des processus spécifiques, des entités et des seuils de montant. Le message pour la direction : vous disposez d’un mécanisme pour empêcher les agents IA d’accumuler discrètement des pouvoirs que vous n’autoriseriez jamais un humain à détenir.
Départ : mise à la retraite des agents IA
Les cas d’utilisation IA prennent fin, les fournisseurs changent, les pilotes échouent—l’accès doit disparaître avec eux. Vous commencez par définir des déclencheurs de départ. Lorsqu’un projet se termine, qu’un contrat expire, ou qu’un flux de travail IA n’est pas utilisé pendant une période définie, l’identité IA entre dans un chemin de départ standard, tout comme un employé partant. Vous souhaitez que cela soit déclenché par un événement et automatique, et non pas dépendant de quelqu’un se souvenant de soumettre un ticket.
Ensuite, vous révoquez tous les identifiants. Les clés, tokens, certificats, et rôles liés à cette identité IA sont révoqués à travers l’ERP, les plateformes de données, les couches d’intégration, et les services IA. C’est également le moment d’éliminer les comptes « bot » partagés en les décomposant en identités distinctes et gouvernées ou en les supprimant entièrement.
Enfin, vous préservez les preuves, mais non l’accès à celles-ci. Les journaux et les instantanés de configuration sont conservés pour les périodes de rétention d’audit et réglementaires requises, mais la capacité d’agir sur des systèmes et des données est supprimée. Pour votre comité d’audit, cela démontre que le cycle de vie de l’identité IA est bouclé : il ne reste pas indéfiniment avec un accès orphelin.
Le plan de contrôle des identités IA
Pour exécuter tout cela à grande échelle, vous avez besoin d’un plan de contrôle qui voit chaque identité—humaine, machine, et IA—à travers l’ERP et les systèmes connectés, et les gouverne de manière cohérente.
Ce plan de contrôle doit vous fournir :
Un inventaire pour toutes les identités. Un inventaire unique et autoritaire des identités, y compris les agents IA et les comptes non humains, avec propriété, but et classification de risque. Cet inventaire s’étend à l’ERP, aux SaaS, aux plateformes de données, et aux services IA.
Décisions pilotées par des politiques. Les politiques définissent qui peut demander un accès IA, quels contrôles s’appliquent, et quelles combinaisons de privilèges ne sont jamais autorisées. La plateforme appliquera automatiquement ces politiques à travers des flux de travail d’approbation, des vérifications de SoD, et des modèles de rôles bien définis, plutôt que de laisser les décisions à un jugement ad hoc.
Examens continus et surveillance. Les agents IA apparaissent dans des examens d’accès réguliers et des certifications, aux côtés des utilisateurs humains. Les propriétaires commerciaux valident périodiquement que chaque agent est toujours nécessaire et correctement défini. Les capacités d’analyse et de détection d’anomalies mettent en lumière des modèles d’accès inhabituels ou des combinaisons de privilèges risquées pour enquête.
Le message pour la direction est simple : au lieu de poursuivre des bots, scripts et clés éparpillés, vous disposez d’un endroit unique pour voir, gouverner, et prouver le contrôle sur l’accès de l’IA à vos systèmes financiers.
Liste de contrôle pratique en 10 points
Pour conclure, vous pouvez utiliser une liste de contrôle que les CISOs, CFOs et présidents d’audit peuvent utiliser dans les comités de pilotage et les paquets de conseil :
Produire un inventaire unique des agents IA et autres identités non humaines ayant accès aux données ERP et financières.
Attribuer un propriétaire, un but commercial, et une évaluation des risques à chaque identité IA.
Intégrer les identités IA dans vos flux de travail standard d’Intégration–Changement–Départ, de sorte qu’aucun agent ne soit ajouté ou retiré en dehors de vos contrôles de cycle de vie.
Définir des politiques d’accès spécifiques à l’IA et des règles de SoD pour les processus financiers clés (GL, AP, AR, paie, trésorerie).
Remplacer les comptes de service partagés et les clés à long terme par des identités IA gouvernées pouvant être approuvées, surveillées et révoquées individuellement.
Exiger des approbations pilotées par des politiques pour tout accès IA à des données financières et RH sensibles ou réglementées.
Inclure les agents IA dans les examens d’accès programmés et les certifications, avec des propriétaires commerciaux attestant de la nécessité continue et du périmètre approprié.
Activer la surveillance continue et la détection d’anomalies pour l’activité IA dans l’ERP et les systèmes adjacents, en se concentrant sur les transactions et mouvements de données à haut risque.
Assurer que les flux de travail de désactivation révoquent les identifiants IA et suppriment les accès orphelins lorsque les projets prennent fin ou que les agents deviennent inactifs.
Rapporter régulièrement les métriques d’accès IA aux comités de risque et d’audit : nombre d’identités IA, permissions à haut risque, violations de SoD impliquant l’IA, et statut des examens.
Géré de cette manière, l’IA à l’intérieur de l’ERP cesse d’être une expérience incontrôlée et devient une autre classe d’identité que vous gérez avec discipline. Vous pouvez avancer plus rapidement sur les initiatives IA tout en fournissant à votre conseil d’administration et aux régulateurs quelque chose qu’ils obtiennent rarement dans cet espace : une histoire claire, étayée par des preuves, sur qui (ou quoi) a accès à vos systèmes et données financières les plus critiques, et comment cet accès est gouverné au fil du temps.
