🚀 Données d’entreprise & IA : accès aux données en 2026

L'intégration classique ne répond pas toujours au besoin

Les outils d'intégration ont surtout été conçus pour faire circuler des données entre applications. Ils connectent un système à un autre, souvent champ par champ, à partir de ce que l'éditeur accepte d'exposer. C'est pratique pour synchroniser des référentiels ou alimenter un entrepôt de données.

Mais un projet d'IA pose une question plus large : l'agent arrive-t-il à voir ce dont il a besoin, et comprend-il suffisamment le sens de l'information pour faire un travail correct ?

Dans la pratique, une API peut ne donner qu'une partie des données d'un logiciel. Un export peut être limité à certains rapports. Et une information affichée à l'écran dépend parfois de filtres, de règles ou d'un historique que l'interface restitue mal sous forme structurée. Le modèle n'est pas forcément « idiot » : il travaille juste avec une vue tronquée de l'entreprise.

Le coût du manque d'accès est déjà visible

On ne parle pas seulement d'un retard « futur ». Le manque d'accès se voit dans les opérations quotidiennes : des consultants passés à documenter des champs, des analystes qui récupèrent des rapports plafonnés avant de les recombiner dans des tableurs, des équipes techniques qui développent des flux spécifiques pour chaque système.

Dans ces conditions, un pilote d'IA peut produire une réponse qui sonne juste... tout en étant basée sur une fraction des données pertinentes. Et quand on s'en rend compte tard, la correction n'est pas gratuite.

L'IA accélère le sujet, elle ne le crée pas

Moderniser les systèmes centraux reste compliqué. L'entretien mentionne des chiffres attribués à Gartner : une partie des systèmes critiques fonctionne encore sur des infrastructures historiques, et certaines organisations évitent la modernisation par crainte du risque.

On retrouve souvent la même logique dans les grands groupes : un système ancien coûte à maintenir, mais il reste indispensable à la production.

L'IA rend cette réalité plus difficile à ignorer, parce que les attentes des directions évoluent plus vite que les systèmes. Attendre une refonte complète avant de tester un cas d'usage peut faire perdre des années. À l'inverse, ouvrir des accès sans cadre peut créer de nouveaux risques. La vraie question n'est donc pas seulement « comment connecter l'IA ? ». C'est plutôt : quelles données sont nécessaires, et avec quelles règles peut-on les exposer ?

Partir des interfaces réellement disponibles

Quand une application ne propose pas d'API exploitable, les utilisateurs ne sont pas pour autant « sans données ». Ils consultent des écrans, lancent des rapports, téléchargent des fichiers, ou utilisent parfois une ligne de commande.

Une approche consiste à s'appuyer sur ces interfaces existantes, plutôt que d'attendre un connecteur de l'éditeur ou le remplacement du logiciel.

Unfold dit s'appuyer sur ce que les utilisateurs peuvent déjà faire pour cartographier les données et construire des collecteurs en lecture seule. Cherniavsky explique aussi que l'IA sert à accélérer l'analyse du système, puis que l'entreprise produit une collecte déterministe. L'intégration annoncée peut aller jusqu'à quatorze jours. À mon avis, ce chiffre dépendra énormément du contexte : complexité du logiciel, qualité de la documentation, droits disponibles et contraintes de sécurité.

Lire les données sans toucher au cœur opérationnel

Le point fort, c'est de limiter le chamboulement du système source. Sur un ERP ancien, un logiciel métier spécialisé ou un progiciel sur site, réduire l'intervention aide à éviter des perturbations. Et une collecte en lecture seule est généralement plus simple à cadrer qu'un agent autorisé à modifier des commandes ou à agir sur des dossiers.

Cela dit, « lecture seule » ne veut pas dire « zéro risque ». Il faut définir les identités techniques, limiter strictement les permissions, tracer les accès, et contrôler la fréquence des extractions. Une interface pensée pour un usage humain n'est pas forcément faite pour des interrogations fréquentes ou massives. Avant de généraliser, les équipes doivent vérifier la charge générée et la façon dont le système est surveillé.

Choisir l'accès selon le système et l'usage

L'accès par interface ne remplace pas toutes les intégrations. S'il existe une API stable qui fournit les champs utiles, c'est souvent la voie la plus simple à maintenir. Si les données doivent être partagées à grande échelle, un flux vers un entrepôt peut mieux convenir.

L'extraction via l'interface devient intéressante quand les méthodes standard ne couvrent pas le besoin, notamment dans des applications fermées ou très anciennes.

Avant de trancher, posez quatre questions :

• Le système expose-t-il déjà les données nécessaires via API, export ou rapports ?
• L'accès par interface est-il autorisé et assez stable dans le temps ?
• Peut-on limiter à une collecte en lecture seule, avec une trace exploitable ?
• Le bénéfice attendu vaut-il le coût de maintenance de ce mode d'accès ?

Cette façon de faire évite de fabriquer une « nouvelle couche opaque » juste pour gagner du temps. L'objectif n'est pas de contourner les systèmes à tout prix : c'est d'obtenir des données utiles sans fragiliser l'exploitation.

Les valeurs n'ont pas de sens sans contexte métier

Sortir une table ne dit pas automatiquement ce que la donnée représente. Un champ peut contenir un code de statut dont le sens n'est connu que par le métier. Le même client peut apparaître sous des identifiants différents selon les outils. Un chiffre peut renvoyer à une facture émise, à un montant restant dû, ou à une estimation - selon le système et le processus.

C'est là que beaucoup de projets sous-estiment le travail. Le modèle peut « traiter » ce qu'on lui donne, mais il ne peut pas deviner de façon fiable les règles locales, les exceptions ou le sens des abréviations. Une réponse en langage naturel devient utile seulement si elle s'appuie sur des définitions solides et sur des sources vérifiables.

Cartographier les objets, les relations et les règles

Pour rendre les données exploitables, il faut construire une représentation de leur signification : quels objets existent, comment ils se relient, quelles règles s'appliquent, et d'où vient chaque information (et où elle change).

Cette connaissance vit souvent à plusieurs endroits : équipes internes, intégrateurs, éditeurs. Et parfois, elle est surtout détenue par quelques personnes qui « savent où regarder ».

Une cartographie utile relie, au minimum :

• le nom technique du champ et sa définition métier ;
• les identifiants utilisés par chaque application ;
• les relations entre clients, sites, commandes ou dossiers ;
• les règles de calcul, les statuts et leurs exceptions ;
• la provenance de chaque donnée et les transformations appliquées.

La documentation n'a pas besoin d'être parfaite dès le départ. Elle doit permettre à une équipe de vérifier une réponse et de tracer d'où elle vient. Une fois posée, cette base sert aussi à la modernisation : on sait mieux ce que contient vraiment le système historique.

Normaliser ne signifie pas effacer les différences

Quand on rapproche plusieurs systèmes, on crée souvent un schéma commun. Un client codé dans un ERP peut correspondre à un compte dans un outil commercial. Un site peut avoir des identifiants différents selon les applications.

Oui, la normalisation aide à relier les objets. Mais elle ne doit pas masquer les divergences réelles. Gardez donc la correspondance avec les sources, la date de mise à jour, et les règles de rapprochement. Une donnée harmonisée sans traçabilité peut donner l'impression d'être cohérente tout en rendant les erreurs très difficiles à diagnostiquer.

Pour les usages sensibles, prévoyez des seuils de confiance et une validation humaine quand le rapprochement reste ambigu.

Gouvernance, RGPD et responsabilité

Le fait que les données restent dans les systèmes sources ne supprime pas les obligations de l'entreprise. Il faut savoir quelles données personnelles sont mobilisées, pour quelle finalité, avec quels droits d'accès, et combien de temps elles sont conservées. Les exigences du RGPD, les politiques internes de sécurité et les règles sectorielles s'appliquent aussi aux traitements qui alimentent un modèle ou un agent.

Et la précision technique ne garantit pas la pertinence. Les données peuvent être incomplètes, ou refléter des pratiques passées contestables. Pour un cas d'usage qui influence directement un client, un salarié ou un partenaire, définissez qui contrôle la réponse, comment une erreur est signalée, et si l'agent peut agir - ou seulement proposer une action.

L'accès est une condition de l'IA utile. La gouvernance, elle, décide si l'IA peut être utilisée de façon responsable.

Des situations métier concrètes, pas une couche IA abstraite

Les exemples présentés par Unfold partent d'un blocage opérationnel. Un distributeur veut exploiter les données de caisse d'anciens systèmes pour détecter la fraude. Un assureur doit associer des champs de son outil de gestion des sinistres à ses bases avant d'automatiser l'analyse. Un groupe de concessions veut rapprocher les données de pièces, d'entretien et de garanties pour répondre à une question sur les montants dus.

Ces cas sont décrits par l'entreprise : ce ne sont pas des évaluations indépendantes. Mais ils illustrent un principe assez simple : choisir un processus où l'information existe déjà, mais reste enfermée dans des rapports ou répartie entre plusieurs outils. La valeur ne vient pas du fait qu'un agent « s'exprime bien ». Elle vient d'une réponse qui était jusque-là impossible, ou d'une baisse du travail manuel, ou d'un contrôle enfin réalisable.

Mesurer le résultat avant de multiplier les connexions

Avant de lancer, fixez une situation de référence. Combien de jours faut-il aujourd'hui pour produire l'information ? Combien d'interventions spécialisées sont nécessaires ? Quelle part du travail consiste à extraire et rapprocher les données ? Quel est le coût d'une réponse tardive ou d'un contrôle absent ?

Sans base de comparaison, le projet risque d'être jugé sur le nombre de systèmes connectés ou le volume de requêtes traitées - des métriques qui ne prouvent pas forcément une valeur métier.

En pratique, vous pouvez couvrir trois dimensions :

• Le temps : délai pour obtenir une réponse vérifiée, avant et après le projet.
• Le coût : heures d'analyse, prestations externes, maintenance des flux.
• Le résultat opérationnel : erreurs détectées, dossiers traités plus tôt, activité rendue possible.

Ajoutez des indicateurs de qualité : taux de réponses correctes, proportion de données traçables, fréquence des exceptions, et nombre de corrections humaines. Un système rapide qui répond faux ne crée pas de valeur : il déplace surtout le problème vers la vérification - voire vers la réparation des conséquences.

Une méthode de démarrage en cinq étapes

1. Choisissez un résultat métier précis. Par exemple, réduire le délai de rapprochement des données de garantie, plutôt que « déployer des agents IA ».
2. Repérez le système qui bloque le processus. Vérifiez les interfaces disponibles et la qualité réelle des données.
3. Limitez l'accès au strict nécessaire. Démarrez par les champs requis, avec des permissions adaptées et une collecte contrôlée.
4. Documentez le contexte et la provenance. Définissez les termes, les règles de rapprochement, et les cas où l'agent doit s'abstenir.
5. Testez d'abord sur des cas connus. Comparez les réponses aux résultats vérifiés par les équipes, et mesurez erreurs et gains.

L'intérêt, c'est de garder le projet proche de l'activité. Et cela aide à décider si la meilleure option est une API, un export, une intégration plus classique, ou une autre manière d'accéder aux données. Une fois le premier cas stabilisé, les composants réutilisables - définitions, correspondances, règles de contrôle - facilitent les suivants.

Ce que les agents peuvent faire ensuite

Quand les données et leur contexte sont accessibles, un agent peut répondre à des questions qui traversent plusieurs applications, ou aider un processus de bout en bout. Par exemple, il peut réunir des informations de commande, de stock et de facturation pour préparer une analyse.

Mais ça ne veut pas dire qu'il faut lui confier tout de suite l'exécution autonome. Une progression prudente distingue la consultation, la recommandation et l'action. Commencez par une réponse vérifiable, puis introduisez des propositions soumises à validation.

L'automatisation d'une action n'a de sens que quand les règles, les permissions, les exceptions et le mécanisme d'arrêt sont maîtrisés. Cette prudence compte particulièrement dans les opérations financières, les sinistres, la santé, ou tous les processus qui touchent directement des personnes.