Un DSI d’une entreprise manufacturière de 600 collaborateurs vient d’enchaîner trois démonstrations en une semaine. SAP S/4HANA avec Joule. Microsoft Dynamics 365 avec Copilot. Et un éditeur récent qui se revendique “natif IA”. Les trois présentations étaient convaincantes, les trois ont employé le mot “agentique”. La question n’est pas de savoir laquelle était la meilleure : c’est de déterminer quelle architecture correspond réellement à la situation de l’entreprise, à son profil de risque et à ses investissements ERP existants.
“Natif IA” est l’expression la plus galvaudée du marketing logiciel d’entreprise aujourd’hui. Cet article vous propose un test technique applicable à n’importe quelle promesse d’éditeur, sept critères pour structurer votre évaluation, et une matrice de décision par profil : vous repartirez avec une position concrète, pas un cadre de cadres.
Périmètre : ETI de 200 à 2 000 collaborateurs qui évaluent ou renouvellent un ERP en 2026. La méthode prime sur les marques, les noms d’éditeurs n’apparaissent qu’à titre illustratif.
Le spectre IA dans l’ERP : du module ajouté à l’architecture native
Ce que “natif IA” signifie vraiment (et ce que ça ne signifie pas)
Un ERP natif IA est conçu depuis son modèle de données avec l’IA comme composant d’exécution de premier ordre, et non comme un module ajouté a posteriori sur un socle transactionnel. Trois critères techniques séparent le natif IA du IA greffé :
Architecture des données. Dans une plateforme véritablement native IA, chaque objet métier (facture, commande d’achat, fiche collaborateur) est stocké dans un format conçu pour l’inférence IA en temps réel. Dans un système legacy avec une couche IA, les fonctionnalités IA appellent une API qui interroge la base transactionnelle via des connecteurs standards, avec toute la latence, l’impédance de schéma et les effets de lot que cela implique.
Localité des données d’entraînement. Les plateformes natives IA sont conçues pour affiner les modèles sur vos données métier réelles dans le cadre du contrat produit. Les systèmes IA greffés s’appuient généralement sur un LLM généraliste (OpenAI, Anthropic, Google) qui n’a aucune connaissance intrinsèque de votre plan de comptes, de vos données de référence ou de vos workflows de validation, sauf si vous construisez vous-même l’ingénierie de prompts.
Orchestration des agents. Un ERP natif IA orchestre des workflows agentiques multi-étapes au sein d’un unique moteur d’exécution : l’agent dispose d’un accès en écriture aux objets métier comme capacité native, avec des pistes d’audit intégrées. Un système IA greffé passe par un framework d’agents externe (SAP BTP Orchestration, Microsoft Copilot Studio, LangChain) qui communique avec l’ERP via des API, introduisant des points de défaillance supplémentaires et une complexité de gouvernance accrue.
Le test marketing : demandez à l’éditeur si ses agents IA peuvent déclencher une transaction en écriture (création, mise à jour, libération) sans quitter le moteur d’exécution central de l’ERP. Si la réponse implique une couche d’orchestration externe qui rappelle l’ERP via REST, vous regardez une architecture en greffe, quel que soit le contenu du slide de présentation.
Trois patterns architecturaux à connaître
IA embarquée (intégration la plus profonde) : la logique IA s’exécute dans le même moteur d’exécution que le système transactionnel. L’agent Oracle Fusion pour la clôture financière en est un exemple représentatif : il pilote la clôture de période subledger par subledger dans le runtime Fusion, sans appel API externe à chaque étape.
IA en greffe (le cas le plus courant aujourd’hui) : un module IA est ajouté à un ERP existant comme service séparé. Il reçoit des données du système central, les traite via un modèle IA, et renvoie les résultats. La plupart des fonctionnalités IA annoncées par les éditeurs ERP pour le segment ETI en 2024-2025 entrent dans cette catégorie. L’expérience utilisateur peut paraître fluide ; l’architecture ne l’est pas.
Couche d’orchestration (approche middleware) : une plateforme IA externe orchestre les interactions entre l’ERP et les modèles IA. C’est l’architecture la plus flexible pour les stratégies d’ERP composable, mais aussi celle qui requiert le plus d’ingénierie et produit la posture d’audit la plus complexe.
Panorama des éditeurs en 2026
Les grands acteurs avec des couches IA : SAP Joule, Oracle AI Agents, Microsoft Copilot for Finance
SAP Joule fonctionne exclusivement sur SAP AI Core pour les clients disposant de contrats RISE with SAP ou GROW with SAP (documentation architecture SAP). Les installations on-premise ECC n’y ont pas accès, quelle que soit leur maturité. Joule Studio 2.0, annoncé en mai 2026, permet le développement d’agents orientés intention avec un runtime managé qui gère l’exécution, le scaling et la sécurité. L’architecture est profondément intégrée dans S/4HANA Cloud Public Edition ; sur Private Edition, elle fonctionne davantage comme une couche d’orchestration.
Oracle Fusion AI Agents représente l’intégration agentique la plus profonde parmi les éditeurs ERP de premier rang, avec plus de 400 agents embarqués nativement dans Fusion Cloud Applications (Oracle Fusion AI Agents). L’agent de clôture financière et l’agent de gestion des notes de frais sont en disponibilité générale sans surcoût de licence pour les clients Fusion Cloud. Oracle utilise principalement Cohere et ses propres modèles pour les cas d’usage financiers sensibles, hébergés entièrement sur Oracle Cloud Infrastructure : un choix délibéré de souveraineté des données.
Microsoft Copilot for Dynamics 365 est une couche d’orchestration par conception : Azure OpenAI, Copilot Studio et Dynamics 365, avec l’écosystème Microsoft 365 comme colonne vertébrale d’intégration. La valeur métier est réelle pour les organisations standardisées sur Microsoft, mais l’architecture est explicitement en greffe. Copilot for Finance en standalone est tarifé à 50 $/utilisateur/mois, ou 20 $/utilisateur/mois en bundle avec Microsoft 365 Copilot (tarification Microsoft 365 Copilot).
Plateformes ETI avec IA native : Odoo, Axelor, Sage Copilot
Odoo a introduit une App IA dédiée dans la version 19 (avril 2025) permettant aux administrateurs de créer des agents personnalisés dans le runtime Odoo. La caractéristique clé : Odoo mise sur la configurabilité en libre-service plutôt que sur des agents prêts à l’emploi. Un non-développeur peut créer un agent de scoring de leads ou un workflow de classification des factures, mais Odoo ne fournit pas d’agent de clôture comptable comparable à Oracle ou Sage. Les fonctionnalités IA natives nécessitent une licence Odoo Enterprise.
Axelor a lancé sa couche IA agentique nativement intégrée en juin 2026, avec support multi-LLM (GPT, Claude, Mistral, modèles locaux). L’option auto-hébergée est un vrai différenciateur pour les ETI des secteurs réglementés qui ne peuvent pas faire transiter leurs données financières par des fournisseurs de modèles externes.
Sage Copilot se concentre sur la fonction finance, en particulier dans Sage Intacct. Le Close Assistant (suivi en temps réel de l’état de clôture des subledgers) et l’analyse automatisée des écarts constituent une IA réellement embarquée. Le Finance Intelligence Agent est en mode early adopter à partir de Sage Intacct 2026 Release 1 (Rand Group, Sage Intacct 2026 R1).
Nouveaux entrants “IA first” ciblant les ETI
Une catégorie de plateformes conçues après 2018, comme Rippling et ses équivalents européens, a construit ses modèles de données avec l’IA comme postulat fondateur. Elles disposent d’un avantage architectural réel sur des cas d’usage ciblés (analytique des effectifs, automatisation de la paie, scoring des achats), mais manquent généralement de la profondeur fonctionnelle requise par les entreprises manufacturières, les distributeurs multi-entités ou les sociétés de services à l’affaire. Considérez-les comme des couches fonctionnelles dans une stratégie d’ERP composable, pas comme des remplacements full-suite.
7 critères de décision
1. Profondeur architecturale IA : dans quelle mesure l’IA est-elle ancrée dans les processus ?
Le test n’est pas le nombre de fonctionnalités : c’est l’accès en écriture. Posez la question à l’éditeur : quelles actions initiées par IA peuvent écrire dans les objets métier de production sans intermédiaire humain ? Si la réponse ne couvre que les opérations en lecture (résumés, explications, recommandations), vous avez un copilote de niveau 1. Si elle inclut des actions d’écriture délimitées (rapprochement, libération de commande, validation de paiement) avec des seuils d’approbation configurables, vous êtes en architecture de niveau 2 ou 3. Pour les ETI, le niveau 2 (exécution guidée avec validation humaine en un clic) est la cible de production adaptée en 2026.
2. Propriété des données et entraînement IA : où vont vos données ?
Quand une fonctionnalité IA traite vos factures, bons de commande ou données RH, trois scénarios s’appliquent : (a) les données sont traitées dans votre tenant sur l’infrastructure de l’éditeur avec isolation contractuelle ; (b) les données sont envoyées à une API LLM tiers partagée selon des conditions d’utilisation standard ; (c) les données servent à améliorer le modèle partagé de l’éditeur entre clients. Les scénarios (b) et (c) nécessitent un examen explicite du DPA au titre du RGPD. Pour les ETI dans la finance, la pharma ou la défense, le scénario (a) est le minimum acceptable. Demandez l’avenant IA à votre contrat ERP avant de signer : de nombreux éditeurs ne le fournissent que sur demande.
3. Coût total de la capacité IA : licences, compute, ingénierie de prompts
Les tarifs IA publiés ne sont jamais complets. Les frais de licence ne constituent que le premier poste. Ce qui n’apparaît pas dans le prix affiché : les heures d’ingénierie de prompts pour configurer les agents sur votre contexte métier, les coûts de conduite du changement pour les utilisateurs qui apprennent à travailler avec des sorties générées par IA, et les frais de dépassement de compute déclenchés par les cas d’usage à fort volume (rapprochement à trois voies à grande échelle, prévision de la demande en temps réel, rapprochement en continu). Budgétez un multiplicateur de 1,5 à 2 sur le devis de l’option IA de l’éditeur pour couvrir le coût total de la capacité IA en première année.
4. Complexité d’intégration : connecteurs vs workflows natifs
Dans une architecture IA greffée, les agents communiquent avec l’ERP via des API. Chaque point d’intégration est une défaillance potentielle : limites de débit, changements de schéma, incompatibilités de version, expirations d’authentification. Pour une ETI qui a déjà consacré trois ans à connecter son ERP à son WMS, son TMS et son CRM, ajouter une couche d’orchestration IA signifie ajouter un nouveau jeu de connecteurs à maintenir. Les architectures natives IA éliminent entièrement cette catégorie de risque : l’agent est dans le système. Si votre paysage d’intégration est déjà complexe, l’architecture native présente un avantage opérationnel qui n’apparaît pas dans les modèles TCO standard.
5. Auditabilité et conformité AI Act : un chantier urgent
Ce critère est plus urgent que la plupart des DSI d’ETI ne l’admettent actuellement. L’AI Act européen classe certaines décisions ERP pilotées par IA comme systèmes à haut risque en vertu de l’Annexe III, déclenchant des évaluations de conformité obligatoires, une documentation technique, des mécanismes de surveillance humaine et un enregistrement dans la base de données européenne.
Deux catégories s’appliquent directement aux cas d’usage ERP :
- Décisions RH (sélection par IA au recrutement, évaluation de la performance, attribution de tâches sur la base de données comportementales) : Annexe III, Point 4. L’échéance de conformité pour ces systèmes était le 2 août 2026 (obligations AI Act emploi).
- Scoring de crédit et évaluation de solvabilité : Annexe III, Point 5(b). Échéance : 2 décembre 2027.
La nuance critique : la loi ne requiert pas une automatisation complète pour que la classification à haut risque s’applique. Un système IA qui produit un score ou un classement qui influence matériellement une décision RH ou de crédit, même avec une validation humaine formelle, entre dans son champ d’application. Demandez à votre éditeur ERP quelles fonctionnalités IA génèrent des sorties relevant de l’Annexe III, si elles produisent des journaux d’audit horodatés immuables, et si une évaluation de conformité a été réalisée. Les pénalités pour non-conformité atteignent 30 M€ ou 6 % du chiffre d’affaires annuel mondial.
6. Crédibilité de la roadmap éditeur : démo vs déploiement en production
Gartner prédit que plus de 40 % des projets IA agentique seront abandonnés d’ici fin 2027, citant des attentes mal calibrées entre les capacités en mode démo et les systèmes prêts pour la production. Dans l’ERP en particulier, l’écart entre une démo IA convaincante et la disponibilité générale sur votre version, votre région et votre modèle de déploiement est souvent de 12 à 24 mois.
Le test décisif : demandez des références clients en production, non des programmes pilotes ni des early adopters, mais des clients payants disposant d’un agent IA en production depuis au moins six mois sur le même modèle de déploiement que celui que vous évaluez. Un éditeur qui ne peut pas fournir trois telles références vous demande de servir de pilote de production.
7. Risque de migration : coût de sortie de votre ERP actuel
Si vous passez à une plateforme native IA, vous changez d’ERP intégralement. L’avantage architectural est réel, mais il s’accompagne d’une migration ERP complète : conversion des données historiques, refonte des processus, formation et baisse de productivité pendant la transition. Pour une ETI de 400 collaborateurs avec sept ans d’historique ERP, c’est un projet de 12 à 24 mois, pas une mise à jour IA.
Évaluez explicitement l’avantage architectural IA face au coût de migration. Si votre ERP actuel est fonctionnellement adéquat et que votre éditeur dispose d’une roadmap IA crédible, l’avantage de l’architecture native ne justifie peut-être pas le coût de migration sur un horizon TCO de 3 ans. Si votre ERP était déjà en retard de remplacement, l’option native IA devient nettement plus attractive : vous ne payez le coût de migration qu’une seule fois.
Matrice de décision : quel profil doit choisir quoi
Vous êtes sur SAP ECC, en migration vers S/4HANA
Restez dans l’écosystème SAP. Joule est la couche IA la plus contextuelle disponible pour les organisations à forte empreinte SAP : elle comprend les modèles de données et la sémantique des processus SAP sans ingénierie personnalisée. RISE with SAP Cloud Public Edition délivre la pleine capacité Joule. Votre investissement en expertise Basis, en remédiation Clean Core et en intégrations tierces n’est pas transférable vers une plateforme concurrente. Le risque de migrer vers un nouvel entrant natif IA tout en gérant une échéance de fin de support ECC n’est pas justifié par le gain architectural.
Vous êtes une ETI en croissance sans dette ERP
Vous disposez de la plus grande liberté architecturale. Une entreprise de 200 à 600 collaborateurs qui évalue son premier ERP structurant peut légitimement analyser des options natives IA aux côtés des plateformes ETI traditionnelles. Conduisez un POC structuré sur 2 à 3 éditeurs, centré sur vos processus les plus pénibles : clôture de période, rapprochement à trois voies, attribution des coûts main-d’oeuvre aux projets. Si une plateforme native IA résout de manière démontrable vos trois premiers points de douleur avec une profondeur fonctionnelle comparable, la logique en faveur de l’architecture native est solide.
Vous utilisez un ERP vertical de niche
Les ERP spécialisés dans la construction, l’agroalimentaire, les services professionnels ou le secteur juridique reconstruisent rarement leur coeur entier pour l’IA. La question pratique : pouvez-vous atteindre vos objectifs IA via une couche d’orchestration (une plateforme IA ETI connectée à votre ERP vertical par API), ou vos exigences imposent-elles une architecture native ? Dans la plupart des cas, une couche d’orchestration est plus rapide, moins coûteuse et moins risquée qu’un remplacement de plateforme complet.
Checklist d’évaluation pratique : 5 questions à poser aux éditeurs
-
Audit des accès en écriture : “Listez chaque action initiée par IA pouvant modifier les données de production dans notre environnement. Montrez-moi le journal d’audit pour chacune.” Un éditeur qui détourne cette question en démontrant des fonctionnalités en lecture seule n’est pas prêt pour la production autonome.
-
Résidence des données : “Où nos données sont-elles traitées quand une fonctionnalité IA est invoquée ? Utilisez-vous un modèle partagé entraîné sur les données de plusieurs clients ? Fournissez l’avenant IA à votre DPA standard.” Obligatoire avant tout achat IA impliquant des données personnelles ou financières au titre du RGPD.
-
Cartographie du périmètre AI Act : “Quelles fonctionnalités IA de votre ERP déclenchent des obligations au titre de l’Annexe III ? Avez-vous réalisé une évaluation de conformité ? Pouvez-vous partager la documentation technique ?” C’est une question d’audit pour tout éditeur qui vend aux ETI européennes.
-
Référence client sur votre profil : “Fournissez les coordonnées de trois clients sur le même modèle de déploiement (édition cloud, région, taille d’entreprise) qui ont cet agent IA en production depuis au moins six mois.” Non négociable pour toute capacité agentique évaluée pour une exécution autonome.
-
Modèle de coût du compute IA : “Fournissez une projection de coût à l’usage pour nos volumes de transactions : X factures/mois, Y bons de commande, Z fiches de paie. Quelles sont les conditions de dépassement ?” Évite les mauvaises surprises en année 2.
Conclusion
La distinction entre ERP natif IA et ERP à IA greffée est architecturalement significative et commercialement conséquente. Gartner prédit que l’IA embarquée dans l’ERP cloud permettra une clôture financière 30 % plus rapide d’ici 2028, mais uniquement pour les organisations qui déploient les fonctionnalités IA en production à grande échelle, pas pour celles qui font encore tourner des démos.
Pour la majorité des DSI d’ETI, le cadre de décision est direct : si vous êtes dans l’écosystème SAP ou Oracle, embarquez l’IA dans votre architecture existante. Si vous repartez de zéro ou planifiez un remplacement complet, pondérez sérieusement les options natives IA. Si vous construisez un ERP composable, traitez l’IA comme une couche d’orchestration plutôt que comme une raison de remplacer votre système central.
Dans tous les cas, la conformité AI Act n’est pas une préoccupation future. Si votre ERP génère des sorties IA qui influencent des décisions RH ou de crédit, l’horloge réglementaire tourne déjà.
Pour aller plus loin :
