Où les agents IA s’intègrent à la plateforme et aux données d’entreprise

Dès lors qu’un agent doit agir et non plus seulement répondre, les questions décisives ne portent plus sur le choix du modèle. Elles deviennent : à quelles données et à quels systèmes l’agent peut-il accéder, que peut-il déclencher, quel contexte reçoit-il et sous quels contrôles opère-t-il ? Ces questions relèvent de l’architecture, de l’intégration et de la gouvernance. Cela explique pourquoi de nombreuses organisations disposent déjà d’une partie des fondations sans avoir construit le moindre agent. Les plateformes de données, les services d’intégration, les moteurs de workflow, les outils d’observabilité, les passerelles d’API et la gestion des accès sont tous directement liés à la maturité agentique.

Commençons par un exemple concret. Imaginons une requête provenant d’un client ou du back office et adressée à un agent. Pour la traiter, l’agent commence par rassembler le contexte : les données de référence client issues du CRM, le statut d’une commande ou d’un stock dans l’ERP, les données d’un dossier ou d’un contrat dans une application métier spécifique, ainsi que les passages pertinents d’une base de connaissances interne. C’est la couche de contexte, et sa qualité est déterminante. Si ces données sont fragmentées, obsolètes ou ne reflètent pas certains états essentiels, la qualité des décisions se dégrade rapidement. C’est pourquoi, le véritable travail consiste de plus en plus à décider quelles données, quels états et quelles informations un agent doit voir à chaque étape, plutôt qu’à formuler un prompt. Ceci est parfois appelée context engineering.

Une fois le contexte réuni, l’agent planifie et choisit une action. Cette couche de raisonnement et d’orchestration décide de ce qui doit se passer et dans quel ordre. Pour exécuter l’étape, il communique avec la couche d’action et appelle un outil ou une API afin de vérifier un droit d’accès, de mettre à jour un enregistrement ou de déclencher un workflow. Avant toute exécution, un point de contrôle s’applique : l’agent vérifie les autorisations, consigne l’action, puis réalise une opération encadrée ou transmet le cas à une personne, accompagné de la trace complète. Ces quatre couches, contexte, raisonnement, action et contrôle, sont le lieu où l’écosystème de l’entreprise devient l’environnement opérationnel de l’agent et non un simple arrière-plan.

Deux éléments assurent cette cohésion et méritent une attention architecturale. Le premier est la manière dont les agents se connectent aux systèmes. Plutôt que de développer une intégration sur mesure pour chaque système, les agents y accèdent de plus en plus par des interfaces d’outils et de fonctions définies. Chaque interface fonctionne comme un contrat : elle précise ce que l’agent peut appeler et ce qu’il obtient en retour. Des conventions ouvertes et partagées pour ces interfaces émergent aujourd’hui. Le Model Context Protocol en est un exemple. Ces conventions rendent les connexions plus cohérentes et réutilisables d’un système à l’autre. L’identité a également sa place ici. Un agent est un acteur machine ; il devrait hériter d’autorisations limitées et auditables plutôt que de fonctionner sous un compte de service trop large.

Le second élément est l’orchestration. La valeur pour l’entreprise provient rarement d’une seule inférence. Elle naît de la coordination fiable de plusieurs étapes : récupérer le contexte, choisir un outil, exécuter une action, vérifier le résultat, puis décider de poursuivre, de suspendre ou d’escalader. C’est ici que la discipline opérationnelle, déjà pratiquée par les équipes plateforme, devient essentielle. Les étapes ont besoin de délais d’expiration et de relances sûres et idempotentes, afin que la répétition d’un appel échoué ne crée pas une commande ou un paiement en double. Chaque étape devrait également émettre des signaux exploitables par la supervision, allant de la latence et du taux de réussite des appels d’outils jusqu’aux résultats inattendus. Les équipes peuvent ainsi repérer les dérives de comportement au lieu de les découvrir après coup. Tous les processus n’ont pas non plus besoin d’un agent au comportement ouvert. Les processus stables et bien définis sont souvent mieux servis par des workflows structurés, plus faciles à tester et à auditer, les agents étant réservés aux cas qui requièrent réellement des décisions flexibles guidées par un modèle.

Plus les agents se rapprochent de l’action, plus l’identité, les autorisations, l’observabilité et l’application des politiques font partie intégrante de la conception. Chaque action de l’agent devrait être enregistrée : ses entrées, les outils appelés et le résultat. Cette piste d’audit soutient la traçabilité et, si nécessaire, la reconstitution du déroulement. Dans les secteurs suisses réglementés tels que la banque, l’assurance, la santé et le secteur public, c’est ce plan de contrôle qui rend les agents viables en premier lieu. La traçabilité, des autorisations limitées et des points clairs de validation humaine font du contrôle un levier plutôt qu’un frein. Et la question architecturale sous-jacente reste la même, que la plateforme repose sur Microsoft Fabric, Databricks, Snowflake ou une pile cloud native.

Cela suggère une étape concrète pour les organisations qui ont déjà dépassé le stade des assistants isolés. Avant de choisir un modèle ou de dresser une liste ambitieuse de cas d’usage, l’exercice le plus utile consiste en un examen honnête de l’adéquation architecturale, mené processus par processus : où un contexte fiable existe déjà, où des chemins d’action sûrs sont déjà en place, et où les mécanismes de contrôle font encore défaut. Cet examen montre généralement qu’une partie des fondations est déjà présente et il met clairement en évidence les écarts qu’il convient de combler en priorité. C’est là que commence le chemin de l’expérimentation de l’IA vers une capacité d’entreprise fiable.