Agentification : ce que les agents IA changent à votre stratégie data

L’IA générative a fait entrer dans le vocabulaire des entreprises un terme encore peu connu il y a quelques années : l’agentification. Derrière ce mot se trouve une ambition claire, faire évoluer des logiciels qui exécutent mécaniquement une séquence d’instructions vers des systèmes capables d’interpréter une demande, de chercher les informations utiles, d’utiliser des outils et de proposer une suite d’actions. Cette évolution peut transformer la manière d’exploiter les données, mais elle ne dispense ni de méthode ni de contrôle.

Pour une direction data, la question n’est donc pas seulement de savoir quel agent IA déployer. Elle est de déterminer quelles décisions peuvent être assistées, avec quelles données, sous quelles limites et avec quel responsable humain. Car un agent qui recommande une action financière, alerte sur une anomalie ou interagit avec plusieurs applications élargit nécessairement la surface des erreurs possibles.

Automatisation et agentification : deux logiques différentes

L’automatisation consiste à confier à un système l’exécution répétée d’une tâche selon des règles préétablies. Un script peut, par exemple, extraire chaque nuit des données d’un logiciel, les transformer dans un format convenu puis les charger dans un entrepôt de données. Si les conditions d’entrée sont connues et stables, ce type de chaîne est rapide, reproductible et facile à auditer.

L’agentification désigne plutôt l’intégration d’agents intelligents dans les processus et les systèmes de données. Un agent fondé sur un modèle de langage peut décomposer un objectif en sous-tâches, consulter une base documentaire, appeler une application par une interface de programmation, analyser le résultat puis ajuster sa prochaine action. Il ne se limite donc pas à appliquer une branche « si ceci, alors cela » écrite à l’avance.

Cette différence ne signifie pas qu’un agent est autonome au sens humain du terme, ni qu’il comprend parfaitement le monde. Son raisonnement apparent est produit à partir des informations et des outils auxquels il a accès. Il peut se tromper, mal interpréter une instruction ou produire une réponse plausible mais fausse. En outre, l’adaptation d’un agent à une situation ne doit pas être confondue avec un apprentissage automatique permanent : dans beaucoup de cas, le modèle sous-jacent ne se réentraîne pas au fil de l’usage.

Pourquoi les données deviennent un système vivant

Dans un pipeline classique, les données sont principalement une entrée : elles arrivent, sont nettoyées, transformées puis livrées à un tableau de bord ou à une application. Avec des agents, elles deviennent aussi un élément de dialogue et de décision. L’agent doit savoir quelle source consulter, distinguer une information récente d’une information obsolète, comprendre les droits d’accès associés et, idéalement, indiquer les éléments qui ont fondé sa recommandation.

Prenons le cas d’un copilote financier. Au lieu de signaler uniquement qu’un indicateur s’écarte d’un seuil, il pourrait rapprocher une variation de ventes, une dépense inhabituelle et un commentaire saisi dans un outil métier. Il pourrait ensuite suggérer une vérification ou une optimisation. La valeur ne vient pas uniquement de la vitesse de calcul : elle vient de la capacité à relier des données hétérogènes dans un contexte métier. Mais la recommandation doit rester vérifiable par l’utilisateur qui prendra la décision.

Cette promesse place la qualité des données au premier plan. Une information exacte mais mal datée, sortie de son contexte ou accessible à la mauvaise personne peut conduire à une décision erronée. Les équipes data doivent donc examiner plusieurs dimensions à la fois :

• La fiabilité, c’est-à-dire l’exactitude, la complétude et la fraîcheur des informations.
• La signification, avec des définitions métier cohérentes pour éviter que deux indicateurs semblables recouvrent des réalités différentes.
• La provenance, afin de savoir d’où vient une donnée, comment elle a été modifiée et qui en est responsable.
• Les autorisations, pour qu’un agent ne contourne pas les restrictions qui s’appliquent normalement à un utilisateur ou à une application.

L’enjeu est aussi architectural. Les pipelines rigides ne disparaissent pas, mais ils sont complétés par des échanges plus dynamiques : événements déclenchés par une action métier, interfaces de programmation permettant d’interroger des applications, et couches d’orchestration qui distribuent les tâches entre agents et humains. Cette souplesse ne doit pas créer un maillage opaque de connexions impossibles à contrôler.

De l’exécution à la recommandation : où placer les limites ?

Plus un agent peut agir, plus les garde-fous doivent être précis. Il existe une différence importante entre un agent qui résume un dossier, un agent qui prépare une proposition d’action et un agent qui modifie directement une base de données, envoie un message ou déclenche un paiement. Ces trois usages ne présentent pas le même niveau de risque ni les mêmes exigences de validation.

Une stratégie raisonnable consiste à distinguer les capacités de lecture, de recommandation et d’exécution. Dans un premier temps, l’agent peut consulter des sources autorisées et produire une synthèse. À l’étape suivante, il peut préparer une action qui devra être approuvée. L’exécution automatique ne devrait être envisagée que pour des opérations très encadrées, réversibles si possible, et assorties de contrôles robustes.

La gouvernance des données doit documenter les décisions

La gouvernance ne se réduit plus à cataloguer les jeux de données et à fixer des règles de conservation. Lorsqu’un agent intervient dans une activité opérationnelle, l’organisation doit pouvoir reconstituer son parcours : quelle demande a été formulée, quelles données ont été consultées, quels outils ont été utilisés, quelle réponse a été produite et quelle action a finalement été validée ou refusée.

Cette traçabilité est utile à plusieurs titres. Elle permet de corriger une erreur, de détecter un comportement inattendu, de répondre à une question d’audit et d’améliorer progressivement le système. Elle évite aussi de transformer l’agent en boîte noire organisationnelle, à laquelle les collaborateurs feraient confiance sans pouvoir vérifier ses conclusions.

La documentation doit être proportionnée à l’usage, mais elle gagne à couvrir au minimum les éléments suivants :

• le cas d’usage, son objectif et les décisions que l’agent est autorisé ou non à influencer ;
• les sources de données et les règles de mise à jour qui s’y appliquent ;
• les modèles, outils et interfaces mobilisés dans le processus ;
• les personnes responsables du suivi, de la validation et de l’arrêt du système ;
• les tests réalisés, les erreurs connues et les conditions de reprise manuelle.

Il est particulièrement important de ne pas promettre une explicabilité que la technologie ne fournit pas réellement. Un historique d’outils appelés ou de documents consultés peut aider à comprendre une réponse. Il ne constitue pas forcément une explication complète du fonctionnement interne d’un modèle de langage. L’entreprise doit être claire sur ce qu’elle peut démontrer, et sur ce qu’elle ne peut pas garantir.

Ce que l’AI Act implique réellement pour les agents IA

Au 6 août 2025, le règlement européen sur l’intelligence artificielle, couramment appelé AI Act, est entré en vigueur depuis le 1er août 2024. Son application est progressive. Certaines dispositions, dont les interdictions de pratiques jugées inacceptables et les obligations liées à la culture de l’IA, s’appliquent depuis le 2 février 2025. Les règles relatives aux modèles d’IA à usage général s’appliquent depuis le 2 août 2025. D’autres obligations, notamment une grande partie du régime concernant les systèmes à haut risque, suivent leur propre calendrier.

Il serait toutefois inexact d’affirmer que tout système reposant sur un agent est automatiquement « à haut risque ». L’AI Act classe les systèmes selon leur finalité et leur contexte d’utilisation, pas selon le seul fait qu’ils soient agentiques. Un agent utilisé pour organiser des notes internes n’a pas la même portée qu’un système qui contribue à prendre des décisions dans un domaine sensible.

Dans les secteurs comme la finance, la santé, l’emploi, l’éducation ou l’accès à certains services essentiels, il faut donc examiner très précisément l’usage envisagé. Un système peut être concerné par des obligations renforcées lorsqu’il entre dans les catégories à haut risque prévues par le règlement. Les attentes portent notamment sur la gestion des risques, la qualité des données, la documentation technique, la tenue de journaux, la transparence, la surveillance humaine, ainsi que l’exactitude, la robustesse et la cybersécurité.

L’idée centrale est simple : la conformité ne peut pas être ajoutée à la fin d’un projet. Si un agent est appelé à intervenir dans une décision sensible, les mécanismes de contrôle doivent être intégrés dès sa conception. Cela passe par des droits d’accès limités, des validations avant exécution, des journaux exploitables et une procédure claire lorsqu’un résultat paraît douteux.

Les compétences humaines restent décisives

L’essor des agents IA modifie le travail des spécialistes de la donnée, mais aussi celui des équipes métier. Les premiers ne sont plus seulement chargés de construire des flux et des tableaux de bord. Ils doivent contribuer à définir les sources fiables, les règles d’accès, les métriques d’évaluation et les mécanismes de surveillance. Les seconds doivent apprendre à formuler une demande de manière précise, à vérifier une réponse et à ne pas déléguer un jugement critique à un système.

Savoir rédiger une instruction utile peut aider, mais la compétence la plus importante est l’évaluation critique. Un collaborateur doit pouvoir repérer une recommandation insuffisamment étayée, demander les éléments utilisés, signaler une erreur ou choisir de ne pas suivre la proposition. La supervision humaine ne consiste pas à cliquer machinalement sur « approuver ». Elle suppose le temps, l’information et l’autorité nécessaires pour intervenir réellement.

Cette organisation implique de désigner clairement les responsabilités. Qui valide le périmètre de données d’un agent ? Qui surveille ses résultats ? Qui décide de suspendre son accès à un outil ? Qui traite les incidents ? Sans réponse opérationnelle à ces questions, l’autonomie affichée par un système risque surtout de disperser la responsabilité.

Comment adopter l’agentification sans fragiliser sa stratégie data

Une adoption progressive est généralement plus solide qu’un déploiement généralisé. L’entreprise peut commencer par identifier un processus où les variations de contexte sont fréquentes, où l’accès à plusieurs sources apporte une valeur réelle, mais où la décision finale reste humaine. Les cas de préparation de dossiers, de recherche dans une documentation maîtrisée, de détection d’éléments à vérifier ou de génération de brouillons sont souvent plus adaptés qu’une action irréversible sur un système critique.

Avant le lancement, l’équipe peut établir un cadre de test comprenant des situations normales, des données incomplètes, des demandes ambiguës, des tentatives d’accès non autorisées et des cas où l’agent doit refuser d’agir. Les résultats doivent être comparés à une référence humaine ou à des règles métier connues. Il faut aussi mesurer non seulement la rapidité, mais la qualité, le taux de correction humaine et les incidents évités ou générés.

Enfin, une bonne stratégie ne cherche pas à rendre tous les logiciels « agentiques ». Elle combine les approches : automatisation déterministe là où elle est efficace, analyse humaine là où le jugement est irremplaçable, et agents IA là où leur capacité à relier des informations et à assister la décision apporte un bénéfice mesurable.

Ce qu’il faut surveiller dans les prochains mois

L’agentification pousse les entreprises à considérer leur infrastructure de données comme un ensemble vivant, traversé par des utilisateurs, des applications, des modèles et des règles de conformité. Cette vision peut favoriser une meilleure réactivité et des décisions plus informées. Elle expose aussi les faiblesses longtemps masquées par des processus séparés : données mal définies, droits d’accès trop larges, responsabilités floues ou contrôles insuffisants.

Les projets les plus crédibles seront ceux qui démontrent une valeur concrète sans confondre autonomie et absence de contrôle. La priorité consiste à choisir des usages proportionnés, à documenter les parcours de décision, à tester les limites du système et à préserver une supervision humaine capable d’agir. Dans cette transition, les fondations de l’automatisation traditionnelle restent précieuses : elles apportent la stabilité sur laquelle les agents peuvent, avec prudence, ajouter de la flexibilité.