Préparer son ERP à l'IA : les prérequis que personne ne mentionne

Votre ERP n'a pas été conçu pour parler à une IA

Quand on évoque l'intégration de l'IA dans les systèmes d'information, la conversation démarre souvent par les cas d'usage : automatiser les relances clients, prédire les ruptures de stock, générer des rapports financiers. Rarement par la question qui conditionne tout le reste : votre ERP est-il capable d'alimenter un agent IA en temps réel ?

La réponse, dans 90% des ETI françaises, est non. Pas par défaut technique insurmontable, mais parce que les ERP du marché — Sage, Cegid, SAP, Microsoft Dynamics — ont été pensés pour des utilisateurs humains qui consultent des écrans, pas pour des agents logiciels qui interrogent des données en continu.

Avant de signer le moindre contrat avec un intégrateur IA, trois couches doivent être diagnostiquées. Ce sont précisément celles que personne ne mentionne dans les présentations commerciales.

Premier prérequis : la cohérence des données maîtres

Un agent IA qui doit calculer la marge par client a besoin d'une chose simple : que le même client porte le même identifiant dans la comptabilité, la facturation et le CRM. Ce qui semble évident ne l'est presque jamais.

Dans la plupart des ERP déployés depuis plus de cinq ans, les données maîtres présentent des incohérences accumulées :

• Clients en doublon avec des codes différents selon les modules
• Articles référencés sous plusieurs nomenclatures non réconciliées
• Centres de coût renommés manuellement sans mise à jour des historiques
• Devises ou unités de mesure non standardisées entre filiales

Pour un utilisateur humain, ces approximations se contournent. On sait que "DURAND SA" et "DURAND S.A." désignent le même compte. Un agent IA, lui, ne devine rien. Il traite ce qu'on lui donne. Si les données sont incohérentes, les résultats le seront aussi — avec une confiance apparente qui rend l'erreur difficile à détecter.

Le travail de réconciliation des données maîtres n'est pas un projet IA. C'est un préalable. Il peut représenter plusieurs semaines de travail, mais il conditionne la fiabilité de tout ce qui suivra.

Deuxième prérequis : des interfaces exploitables en temps réel

La question technique centrale : comment un agent IA accède-t-il aux données de votre ERP ?

Trois scénarios existent :

• API natives : l'ERP expose des endpoints documentés, requêtables en temps réel. C'est le cas idéal, encore minoritaire dans les déploiements on-premise.
• Exports batch : l'ERP génère des fichiers (CSV, XML) à intervalles réguliers — toutes les nuits, toutes les heures. L'agent travaille sur une copie décalée dans le temps.
• Accès base de données direct : on connecte l'agent aux tables SQL de l'ERP. Techniquement possible, souvent risqué en termes de performance et de support éditeur.

La plupart des projets IA sous-estiment ce point. On imagine que "brancher une IA sur l'ERP" est une opération standard. En réalité, beaucoup d'ERP français tournent sur des versions qui n'exposent pas d'API modernes, ou uniquement pour certains modules.

Un exemple concret : une ETI industrielle souhaitait automatiser le suivi des commandes fournisseurs. L'ERP disposait d'une API pour les commandes clients, mais aucune pour les achats. Le projet a nécessité la création d'une couche d'extraction intermédiaire — six semaines de développement non anticipées.

Cartographier les interfaces disponibles avant de définir les cas d'usage évite ce type de surprise.

Troisième prérequis : la gouvernance des droits d'accès machine

Quand un collaborateur consulte une fiche client dans l'ERP, ses droits sont définis : il voit ce que son profil autorise. Quand un agent IA interroge le même système, sous quelle identité opère-t-il ?

Cette question de gouvernance est systématiquement négligée dans les phases de POC. On crée un compte technique avec des droits administrateur "pour aller vite". Le prototype fonctionne. Puis vient le passage en production, et les questions arrivent :

• L'agent peut-il accéder aux données salariales ?
• Qui est responsable si l'agent modifie une donnée par erreur ?
• Comment tracer les actions effectuées par l'agent versus celles des utilisateurs ?
• Les accès sont-ils conformes au RGPD si l'agent traite des données personnelles ?

La réponse ne peut pas être technique uniquement. Elle implique de définir une politique de droits pour les identités machines, au même titre qu'on gère les droits des utilisateurs humains. Cela suppose des choix de gouvernance, validés par la direction, documentés, auditables.

Sans ce cadre, le déploiement reste fragile. Un incident de sécurité ou une erreur de traitement peut remettre en cause l'ensemble du projet.

Ce que révèle un audit préalable

Ces trois couches — données maîtres, interfaces, gouvernance — ne sont pas des obstacles techniques marginaux. Elles déterminent si un projet d'IA agentique prendra trois mois ou dix-huit mois. Si les résultats seront fiables ou approximatifs. Si le système sera maintenable ou deviendra une dette technique supplémentaire.

C'est pourquoi tout engagement Lynakor commence par un diagnostic de ces fondations. Pas pour vendre du conseil préalable, mais parce que déployer des agents IA sur une infrastructure non préparée revient à construire sur du sable.

Le diagnostic couvre :

• L'état de cohérence des référentiels clés (clients, articles, plan comptable)
• La cartographie des interfaces disponibles par module ERP
• L'analyse des politiques d'accès et leur compatibilité avec des identités machines
• L'estimation réaliste du travail de préparation avant tout déploiement agentique

Ce travail prend généralement deux à trois semaines. Il produit une feuille de route chiffrée, sans surprise ultérieure.

Une organisation requêtable ne s'improvise pas

L'IA agentique promet d'interroger votre système d'information comme on pose une question à un collaborateur expert. Cette promesse est réelle — mais elle suppose que le système d'information soit en état de répondre.

On ne peut pas automatiser le chaos. Un ERP dont les données sont incohérentes, les interfaces limitées et les droits flous ne devient pas intelligent parce qu'on lui connecte un modèle de langage. Il devient un générateur d'erreurs sophistiquées.

Les ETI qui réussiront leur transition vers l'IA agentique sont celles qui auront investi dans cette préparation, souvent ingrate, rarement visible, toujours déterminante.