Nexen Group
IA agentique en finance : cas d’usage, risques et contrôles

Direction financière à temps partagé

IA agentique en finance : cas d’usage, risques et contrôles

Une IA qui agit dans plusieurs outils change le profil de risque : mémoire, données, habilitations, responsabilité, journaux et validation deviennent centraux.

Publié le 29 juillet 2026

Échanger avec Nexen

Une IA agentique ne se contente pas de produire une réponse : elle peut enchaîner des tâches, utiliser des outils, conserver un contexte et agir sur un environnement. En finance, cette capacité ouvre des usages utiles, mais augmente les risques liés aux données, aux habilitations, aux erreurs en cascade et à l’attribution des responsabilités. Dans une note publiée le 20 juillet 2026, la CNIL et le Conseil de l’IA et du Numérique soulignent notamment la circulation des données entre services, la mémoire persistante, l’autonomie et la complexité des responsabilités. Une direction financière doit traduire ces risques en règles de conception et d’exploitation.

Qu’est-ce qu’une IA agentique appliquée à la finance ? C’est un système capable de planifier ou d’enchaîner des actions pour atteindre un objectif, par exemple collecter des données, rapprocher des fichiers, préparer un commentaire et créer une tâche de suivi. La frontière utile n’est pas le mot « agent », mais la capacité réelle à accéder à des informations et à déclencher des actions. Quels cas d’usage envisager sans commencer par le plus risqué ? Les premiers usages doivent rester délimités, observables et faciles à interrompre. Une séquence de lecture et de préparation offre souvent plus de maîtrise qu’un agent autorisé à modifier des données de référence ou exécuter un paiement.

collecter les statuts d’une clôture et relancer sous forme de brouillon ; rapprocher des fichiers et proposer une liste d’écarts à examiner ; préparer un commentaire de reporting avec liens vers les sources ; compiler les hypothèses d’un forecast et signaler les incohérences ; classer les demandes reçues et créer des tâches non exécutoires ; préparer une checklist de data room sans diffuser de document. Pourquoi les risques changent-ils d’échelle ?

Capacité Risque financier ou data Contrôle attendu Mémoire persistante Conservation de données au-delà du besoin Finalité, durée, accès et suppression Connexion multi-outils Circulation ou combinaison de données Cartographie des flux et droits minimaux Planification autonome Étapes imprévues ou non autorisées Actions permises, limites et arrêt Action dans un système Modification ou diffusion erronée Validation, seuil, journal et retour arrière Chaîne de fournisseurs Responsabilités et sécurité fragmentées Contrats, sous-traitants et revue Principe 1 : donner le minimum de droits Un agent ne doit pas disposer par défaut des droits de son utilisateur le plus puissant.

Les accès sont limités aux données et actions nécessaires, séparés par environnement et réexaminés lorsque le périmètre change. Pour un pilote, un accès en lecture, un jeu de données isolé et des actions simulées réduisent le risque. Les droits d’écriture sont ajoutés seulement si les tests démontrent leur nécessité et si les validations sont opérationnelles. Principe 2 : placer des validations aux bons endroits Valider seulement la sortie finale peut être insuffisant si l’agent a déjà déplacé une donnée ou envoyé un message.

Les points de contrôle doivent précéder les actions sensibles : changement de référentiel, écriture, paiement, transmission externe, suppression ou élargissement d’accès. La validation doit présenter les informations utiles au décideur : source, action proposée, montant ou périmètre, exceptions, identité du demandeur et conséquences attendues. Principe 3 : rendre la chaîne reconstituable Les journaux doivent permettre de comprendre l’objectif reçu, les données consultées, les outils appelés, les décisions intermédiaires, les validations et le résultat. La conservation doit toutefois rester cohérente avec la confidentialité et la protection des données.

Principe 4 : tester les erreurs en cascade Un agent peut réutiliser une sortie erronée dans l’étape suivante. Les tests doivent injecter une donnée manquante, un format inattendu, un refus d’API, un doublon, une instruction contradictoire et une tentative d’accès non autorisé. Les critères d’arrêt sont définis avant le déploiement. Un système qui ne sait pas reconnaître son incertitude ou appeler un humain ne doit pas recevoir une autonomie supplémentaire.

Checklist avant pilote objectif, périmètre et propriétaire documentés ; données et services connectés cartographiés ; droits minimaux et environnement de test ; actions interdites et seuils de validation ; jeu de tests normal, limite et hostile ; journaux exploitables et durée de conservation ; procédure d’arrêt, d’incident et de retour arrière ; mesure du temps total, des erreurs et de la reprise humaine. Questions fréquentes Un agent IA peut-il passer des écritures comptables ? Techniquement, une intégration peut le permettre. En pratique, les règles, pièces, habilitations, validations et journaux doivent être définis ; commencer par une proposition d’écriture à valider limite le risque.

Faut-il interdire toute mémoire ? Pas nécessairement. Il faut définir ce qui est mémorisé, pourquoi, où, pendant combien de temps et par qui cela peut être consulté ou supprimé. Comment Nexen aborde-t-il un pilote ? Le pilote part du processus et de ses contrôles, puis limite l’autonomie au niveau démontré par les tests. Voir aussi les pages IA finance , contrôle interne et data financière .

Sources de référence