Virginie Brard, RVP France & Benelux chez Fivetran
Autrement dit, les entreprises qui souhaitent permettre à des agents IA d’accéder directement à leurs données SAP par API devront le faire selon les conditions définies par l’éditeur. La nuance est importante. Il ne s’agit pas seulement d’une question technique, ni d’un ajustement documentaire de plus dans un contrat logiciel. C’est un signal envoyé à toutes les directions data, IT et métiers qui bâtissent aujourd’hui leur stratégie IA autour de leurs systèmes critiques.
L’accès aux données devient un enjeu stratégique
Le sujet illustre une tension plus large qui traverse tout le marché du logiciel d’entreprise. Les éditeurs historiques savent que la valeur de l’IA ne réside pas uniquement dans les modèles, mais dans leur capacité à exploiter les données opérationnelles comme les données financières, les achats, la supply chain, les ressources humaines, les ventes, les stocks ou encore la production. Ces données se trouvent souvent dans les ERP et les applications métiers qui structurent l’entreprise depuis des années.
Dans ce contexte, contrôler l’accès aux données revient à contrôler une partie décisive de la future chaîne de valeur de l’IA. Les entreprises veulent connecter leurs agents, leurs modèles, leurs outils analytiques et leurs environnements cloud aux données qui fondent leurs décisions. Les éditeurs, eux, cherchent à orienter ces usages vers leurs propres plateformes, leurs propres couches d’intégration et leurs propres services certifiés. Cette logique peut se défendre au nom de la sécurité, de la gouvernance ou de la qualité. Mais elle pose une question simple : qui doit définir l’architecture IA d’une entreprise ? Son éditeur d’ERP ou sa propre stratégie technologique ?
L’impact immédiat de ce type de politique peut sembler limité. Une politique n’est pas toujours un contrat. Son application dépend des interfaces concernées, des exceptions prévues et du calendrier de mise en œuvre. Mais le point décisif est ailleurs. Ce qui compte, c’est la direction prise, celle d’un accès aux données de plus en plus conditionné par les parcours validés par les grands éditeurs applicatifs.
Le coût caché du verrouillage
Les compromis apparaissent rarement au moment du choix initial. Ils deviennent visibles lorsque l’entreprise cherche à accélérer ses projets. Un premier risque tient à l’empilement des coûts. Lorsqu’une entreprise doit multiplier les produits, connecteurs, couches d’accès ou services certifiés pour faire circuler ses propres données, chaque nouveau cas d’usage IA devient plus complexe et plus coûteux à industrialiser.
Un deuxième risque concerne la flexibilité cloud. Une entreprise opérant déjà sur un ou plusieurs environnement Cloud peut se retrouver limitée aux services explicitement certifiés ou compatibles avec l’écosystème de son éditeur métier. Le problème n’est pas l’existence de chemins sécurisés. Le problème apparaît lorsque ces chemins deviennent les seuls possibles, au détriment des outils déjà validés par l’entreprise, de ses standards internes ou de ses choix d’architecture.
Le troisième risque le plus profond est le verrouillage architectural. Si la logique métier, les règles de sécurité, les modèles sémantiques et les flux de données restent trop étroitement liés à un environnement propriétaire, déplacer demain l’analyse, l’entraînement de modèles ou l’orchestration d’agents vers une autre plateforme imposera de reconstruire une partie du travail déjà réalisé. L’entreprise perd non seulement du temps et de la marge de manœuvre.
L’IA ne peut pas avancer au rythme d’un seul éditeur
Le sujet devient encore plus critique avec les agents IA. Contrairement à un tableau de bord ou à un rapport analytique, un agent doit pouvoir interroger plusieurs systèmes, croiser des informations, déclencher des actions et raisonner à partir de données distribuées. Dans une grande entreprise, ces données ne vivent jamais dans un seul environnement. Elles sont réparties entre ERP, CRM, applications métiers, plateformes cloud, data warehouse, data lake et outils spécialisés.
Si les agents IA ne peuvent accéder aux données critiques qu’à travers des chemins imposés par chaque fournisseur, leur efficacité dépendra moins des besoins de l’entreprise que du rythme, des priorités commerciales et des arbitrages techniques de ces fournisseurs. L’IA d’entreprise risque alors de devenir une promesse sous conditions, contrainte par les limites de l’écosystème choisi par l’éditeur.
C’est précisément pour éviter cette dépendance que les entreprises doivent repenser leur infrastructure data. L’enjeu n’est pas de contourner les règles de sécurité, ni d’ouvrir les systèmes sans contrôle. Il est de construire une architecture dans laquelle les données restent gouvernées, traçables et sécurisées, tout en pouvant être exploitées librement dans les outils, les plateformes et les environnements choisis par l’entreprise. Les formats ouverts, la séparation entre stockage et calcul, et la capacité à connecter plusieurs moteurs analytiques ou IA deviennent des prérequis stratégiques.
Une infrastructure de données ouverte repose sur un principe simple, selon lequel les données de l’entreprise doivent rester sous son contrôle. Elles doivent pouvoir être stockées dans un environnement maîtrisé, exploitées par différents moteurs de calcul et mises à disposition des outils BI, machine learning ou IA les plus adaptés. Les formats ouverts existants répondent à cette logique en réduisant la dépendance à une seule plateforme et en préservant la liberté de choix.
Les entreprises qui avanceront le plus vite sur l’IA ne seront pas seulement celles qui auront choisi le meilleur modèle ou le meilleur assistant. Ce seront celles dont les données seront disponibles, bien gouvernées et libres de circuler vers les usages pertinents.
L’architecture data héritée des cinq dernières années n’a pas toujours été conçue pour le monde qui arrive. Les prochains cas d’usage, qu’il s’agisse d’agents capables de raisonner entre plusieurs systèmes, de modèles entraînés sur des données longtemps sous-exploitées ou de décisions automatisées à grande échelle, exigeront davantage d’ouverture, de portabilité et de contrôle. La vraie question n’est donc pas de savoir si telle ou telle politique API aura un impact immédiat. Elle est de savoir si les entreprises veulent bâtir leur stratégie IA sur une architecture qu’elles maîtrisent, ou sur des accès que d’autres peuvent redéfinir.
L’accès aux données devient un enjeu stratégique
Le sujet illustre une tension plus large qui traverse tout le marché du logiciel d’entreprise. Les éditeurs historiques savent que la valeur de l’IA ne réside pas uniquement dans les modèles, mais dans leur capacité à exploiter les données opérationnelles comme les données financières, les achats, la supply chain, les ressources humaines, les ventes, les stocks ou encore la production. Ces données se trouvent souvent dans les ERP et les applications métiers qui structurent l’entreprise depuis des années.
Dans ce contexte, contrôler l’accès aux données revient à contrôler une partie décisive de la future chaîne de valeur de l’IA. Les entreprises veulent connecter leurs agents, leurs modèles, leurs outils analytiques et leurs environnements cloud aux données qui fondent leurs décisions. Les éditeurs, eux, cherchent à orienter ces usages vers leurs propres plateformes, leurs propres couches d’intégration et leurs propres services certifiés. Cette logique peut se défendre au nom de la sécurité, de la gouvernance ou de la qualité. Mais elle pose une question simple : qui doit définir l’architecture IA d’une entreprise ? Son éditeur d’ERP ou sa propre stratégie technologique ?
L’impact immédiat de ce type de politique peut sembler limité. Une politique n’est pas toujours un contrat. Son application dépend des interfaces concernées, des exceptions prévues et du calendrier de mise en œuvre. Mais le point décisif est ailleurs. Ce qui compte, c’est la direction prise, celle d’un accès aux données de plus en plus conditionné par les parcours validés par les grands éditeurs applicatifs.
Le coût caché du verrouillage
Les compromis apparaissent rarement au moment du choix initial. Ils deviennent visibles lorsque l’entreprise cherche à accélérer ses projets. Un premier risque tient à l’empilement des coûts. Lorsqu’une entreprise doit multiplier les produits, connecteurs, couches d’accès ou services certifiés pour faire circuler ses propres données, chaque nouveau cas d’usage IA devient plus complexe et plus coûteux à industrialiser.
Un deuxième risque concerne la flexibilité cloud. Une entreprise opérant déjà sur un ou plusieurs environnement Cloud peut se retrouver limitée aux services explicitement certifiés ou compatibles avec l’écosystème de son éditeur métier. Le problème n’est pas l’existence de chemins sécurisés. Le problème apparaît lorsque ces chemins deviennent les seuls possibles, au détriment des outils déjà validés par l’entreprise, de ses standards internes ou de ses choix d’architecture.
Le troisième risque le plus profond est le verrouillage architectural. Si la logique métier, les règles de sécurité, les modèles sémantiques et les flux de données restent trop étroitement liés à un environnement propriétaire, déplacer demain l’analyse, l’entraînement de modèles ou l’orchestration d’agents vers une autre plateforme imposera de reconstruire une partie du travail déjà réalisé. L’entreprise perd non seulement du temps et de la marge de manœuvre.
L’IA ne peut pas avancer au rythme d’un seul éditeur
Le sujet devient encore plus critique avec les agents IA. Contrairement à un tableau de bord ou à un rapport analytique, un agent doit pouvoir interroger plusieurs systèmes, croiser des informations, déclencher des actions et raisonner à partir de données distribuées. Dans une grande entreprise, ces données ne vivent jamais dans un seul environnement. Elles sont réparties entre ERP, CRM, applications métiers, plateformes cloud, data warehouse, data lake et outils spécialisés.
Si les agents IA ne peuvent accéder aux données critiques qu’à travers des chemins imposés par chaque fournisseur, leur efficacité dépendra moins des besoins de l’entreprise que du rythme, des priorités commerciales et des arbitrages techniques de ces fournisseurs. L’IA d’entreprise risque alors de devenir une promesse sous conditions, contrainte par les limites de l’écosystème choisi par l’éditeur.
C’est précisément pour éviter cette dépendance que les entreprises doivent repenser leur infrastructure data. L’enjeu n’est pas de contourner les règles de sécurité, ni d’ouvrir les systèmes sans contrôle. Il est de construire une architecture dans laquelle les données restent gouvernées, traçables et sécurisées, tout en pouvant être exploitées librement dans les outils, les plateformes et les environnements choisis par l’entreprise. Les formats ouverts, la séparation entre stockage et calcul, et la capacité à connecter plusieurs moteurs analytiques ou IA deviennent des prérequis stratégiques.
Une infrastructure de données ouverte repose sur un principe simple, selon lequel les données de l’entreprise doivent rester sous son contrôle. Elles doivent pouvoir être stockées dans un environnement maîtrisé, exploitées par différents moteurs de calcul et mises à disposition des outils BI, machine learning ou IA les plus adaptés. Les formats ouverts existants répondent à cette logique en réduisant la dépendance à une seule plateforme et en préservant la liberté de choix.
Les entreprises qui avanceront le plus vite sur l’IA ne seront pas seulement celles qui auront choisi le meilleur modèle ou le meilleur assistant. Ce seront celles dont les données seront disponibles, bien gouvernées et libres de circuler vers les usages pertinents.
L’architecture data héritée des cinq dernières années n’a pas toujours été conçue pour le monde qui arrive. Les prochains cas d’usage, qu’il s’agisse d’agents capables de raisonner entre plusieurs systèmes, de modèles entraînés sur des données longtemps sous-exploitées ou de décisions automatisées à grande échelle, exigeront davantage d’ouverture, de portabilité et de contrôle. La vraie question n’est donc pas de savoir si telle ou telle politique API aura un impact immédiat. Elle est de savoir si les entreprises veulent bâtir leur stratégie IA sur une architecture qu’elles maîtrisent, ou sur des accès que d’autres peuvent redéfinir.