Migration ERP 2026 : moderniser SAP, Sage et Cegid avec l'IA

#L'ERP en 2026 : pourquoi migrer devient urgent pour les ETI françaises

Les ETI françaises vivent une situation paradoxale avec leur ERP. Le système qui a structuré leur croissance — parfois depuis 15 ou 20 ans — est devenu leur principal frein opérationnel. Beaucoup d'ETI européennes opèrent sur un ERP dont la version installée a plus de huit ans.

Les symptômes sont bien connus des DSI et DAF :

• Intégrations impossibles ou artisanales : connecter Salesforce, HubSpot, une plateforme e-commerce ou un outil de BI moderne à un SAP Business One version 9.x ou un Sage X3 < 12 exige des développements spécifiques coûteux que l'éditeur ne supporte plus.
• Coûts de maintenance en croissance non linéaire : les consultants capables d'intervenir sur les versions anciennes se raréfient. Les tarifs des experts des versions anciennes ont tendance à monter.
• Fenêtres de fin de support qui se ferment : Les éditeurs annoncent des fins de support par version (SAP Business One, Sage X3, Cegid XRP Flex vers XRP Ultimate) : vérifiez la feuille de route officielle de votre éditeur pour votre version.
• Impossibilité de tirer parti de l'IA : les ERP modernes — SAP S/4HANA, Sage X3 v12+, Dynamics 365 — intègrent des capacités d'IA nativement (prévision de demande, détection d'anomalies comptables, automatisation des rapprochements). Les versions anciennes n'ont aucune de ces capacités et ne peuvent pas les recevoir par mise à jour.
• Risque réglementaire : la facturation électronique obligatoire en France (déploiement progressif 2026-2027), la DSN, le RGPD et les obligations de traçabilité des données imposent des mises à niveau que les vieilles versions ne supportent techniquement pas.

Ces facteurs convergent en 2026 pour créer une fenêtre d'urgence que la plupart des ETI ne peuvent plus ignorer. La question n'est plus tactique — elle est stratégique : quelle approche choisir, dans quel délai, avec quel budget réaliste ?

---

#Inventaire des ERP les plus fréquents dans les ETI : SAP B1, Sage X3, Cegid, Dynamics 365

Quatre ERP dominent le marché des ETI françaises avec des profils de risque et de coût de migration très différents.

#SAP Business One (B1)

Profil typique : ETI industrie, distribution, retail, 20 à 500 utilisateurs. Version la plus répandue en parc : 9.3 et 10.0 on-premise.

SAP Business One est un ERP robuste mais profondément personnalisable via des User-Defined Fields, des UDO (User-Defined Objects) et du code Visual Basic / Crystal Reports qui s'accumule depuis des années. Ces personnalisations sont le principal risque de migration : elles ne sont documentées nulle part, le développeur qui les a écrites a souvent quitté l'entreprise, et certaines encodent des règles métier critiques (calculs de prix, workflows de validation, règles de stock).

La migration vers SAP S/4HANA Cloud Public Edition ou SAP Business One Cloud (version SaaS) implique de reprendre ces personnalisations une à une. L'IA peut automatiser l'inventaire et la documentation — c'est d'ailleurs l'usage le plus immédiatement productif des outils comme GitHub Copilot ou Claude sur un périmètre ERP.

#Sage X3 (Enterprise Management)

Profil typique : ETI industrie manufacturière, agroalimentaire, distribution spécialisée, 50 à 2 000 utilisateurs. Versions en parc : v6, v9, v11 — toutes potentiellement hors support ou en fin de vie.

Sage X3 est plus complexe à migrer que SAP B1 parce que ses personnalisations reposent sur un langage propriétaire — le langage 4GL de Sage, maintenant rebaptisé Sage X3 Script. Les scripts de personnalisation peuvent représenter des dizaines de milliers de lignes sur les installations les plus anciennes, et la migration vers X3 v12+ ou vers Sage Intacct (version SaaS pure) exige une réécriture partielle ou totale de ces scripts.

Les outils d'IA générative peuvent accélérer cette réécriture : en soumettant des blocs de code Sage 4GL à des LLM comme Claude, on obtient une compréhension et une première traduction vers des équivalents modernes, qu'un consultant relit et valide.

#Cegid XRP (ex-Yourcegid)

Profil typique : ETI services, expertise comptable, cabinets conseil, distribution, 20 à 500 utilisateurs.

Cegid pousse activement ses clients vers XRP Ultimate (anciennement Cegid Business) qui est une refonte architecturale complète en multi-tenant cloud. La migration depuis XRP Flex (ancienne génération) ou depuis Cegid PMI implique une requalification de tous les paramètres, des états personnalisés et des intégrations. Cegid fournit des outils de migration semi-automatisés, mais ils couvrent rarement tout le périmètre réel.

#Microsoft Dynamics 365 Business Central

Profil typique : ETI tous secteurs, 10 à 500 utilisateurs, souvent issues d'une migration depuis Dynamics NAV (Navision) ou Dynamics GP.

Business Central est l'ERP Microsoft qui connaît la plus forte croissance en France sur le segment ETI. Sa position dans l'écosystème Microsoft (Teams, Azure, Copilot for Microsoft 365) en fait le choix naturel pour les ETI déjà ancrées dans l'univers Microsoft. Les migrations depuis NAV sont techniquement bien documentées, mais les extensions AL (ancien C/AL) peuvent créer des points de blocage similaires aux autres ERP.

---

#Migration vs modernisation vs remplacement : matrice de décision

Trois approches structurent la réponse à une problématique ERP vieillissant. Elles ne sont pas interchangeables et le choix conditionne budget, risque et valeur sur 10 ans.

#Migration (montée de version chez le même éditeur)

On reste sur le même ERP et le même éditeur, mais on passe à la version actuelle. SAP B1 9.3 → SAP B1 10.0 Cloud, Sage X3 v9 → v12, Cegid XRP Flex → XRP Ultimate.

Quand c'est le bon choix : l'ERP répond fonctionnellement aux besoins, les personnalisations sont raisonnables (< 20 % du code), l'équipe IT a la capacité de gérer la transition, et l'éditeur propose un chemin de migration documenté.

Risques : les personnalisations ne migrent pas automatiquement. Les tests de régression sont chronophages. La durée réelle dépasse systématiquement les estimations initiales de l'éditeur.

#Modernisation (ajout d'une couche d'intégration ou d'IA sans remplacement complet)

L'ERP existant reste en place mais on l'enrichit : couche d'API pour connecter les outils SaaS, middleware iPaaS (MuleSoft, Boomi, Make), agents IA qui automatisent les processus manuels autour de l'ERP, front-end moderne pour certains cas d'usage spécifiques.

Quand c'est le bon choix : l'ERP est fonctionnellement solide mais techniquement isolé. Le budget et la capacité organisationnelle ne permettent pas un remplacement complet à court terme. On cherche un retour rapide avant un remplacement à moyen terme.

Risques : si la modernisation devient une accumulation de rustines, la dette technique augmente plutôt que de diminuer. L'approche doit être architecurée comme une première phase, pas comme une solution finale.

#Remplacement (changement d'ERP)

On abandonne l'ERP existant pour un nouveau système — soit chez un autre éditeur, soit vers un ERP cloud-native (NetSuite, Pennylane, Odoo 17+).

Quand c'est le bon choix : l'ERP actuel ne peut pas couvrir les besoins fonctionnels actuels (manque de verticalisation sectorielle, absence de capacités multi-pays, impossibilité de connecter les outils modernes), le coût de migration chez l'éditeur actuel est proche du coût de remplacement, ou l'organisation veut repartir d'une base propre.

Risques : le remplacement est le projet le plus risqué. La perte de règles métier implicites encodées dans l'ancien ERP, la résistance des utilisateurs au changement d'interface et la complexité des reprises de données historiques sont les trois sources principales de dérapage.

#La matrice de décision en pratique

Dans notre expérience sur le segment ETI, la modernisation est souvent la réponse sous-estimée : elle délivre de la valeur rapidement tout en préparant le terrain pour un remplacement maîtrisé à moyen terme. C'est l'approche que nous documentons dans notre article sur le strangler fig pattern appliqué aux systèmes legacy.

---

#Comment l'IA accélère la migration ERP : analyse de code, documentation automatique, tests

L'IA ne remplace pas les consultants ERP — elle démultiplie leur productivité sur les tâches les plus chronophages de chaque migration.

#Inventaire et analyse automatique du code de personnalisation

La première phase de toute migration ERP est l'audit du périmètre de personnalisation. Sur un SAP B1 installé depuis 10 ans, cela peut représenter des centaines de User-Defined Tables, des dizaines de Crystal Reports, des UDO complexes et du code Visual Basic embarqué dans des add-ons maison. Sur Sage X3, des milliers de lignes de scripts 4GL.

Avant l'IA, cet inventaire mobilisait des semaines de travail d'un consultant senior. Avec des outils comme Claude ou GitHub Copilot configurés en mode d'analyse statique, il se fait bien plus vite. L'IA catégorise chaque personnalisation (critique, fonctionnelle, cosmétique), estime sa complexité de migration et génère une documentation en langage naturel de ce que fait chaque bloc de code.

#Documentation automatique des règles métier

C'est peut-être l'usage le plus précieux de l'IA dans une migration ERP. Les règles métier implicites — prix dégressifs négociés avec des clients spécifiques, workflows de validation à plusieurs niveaux, calculs de commission non documentés — sont encodées dans le paramétrage et les scripts de l'ERP sans jamais avoir été formalisées dans un cahier des charges.

En soumettant le code de personnalisation à un LLM avec les bonnes instructions système, on obtient en quelques heures une liste structurée des règles métier détectées, que les équipes fonctionnelles peuvent valider ou corriger. Ce processus complète, et raccourcit, les ateliers de recueil des besoins traditionnels.

#Génération des tests de non-régression

Les tests de non-régression sont la phase la plus sous-estimée et la plus chronophage de toute migration ERP. Sur un périmètre de plusieurs centaines de processus métier, écrire les cas de test manuellement prend des semaines. L'IA peut générer une grande partie de ces cas de test à partir de la documentation des règles métier et des logs de transactions historiques.

Les outils spécialisés comme Worksoft Certify, Tricentis Tosca ou les solutions d'automatisation SAP intègrent maintenant des modules IA qui génèrent les scripts de test directement depuis les captures d'écran de l'ancien système et les comparer au comportement du nouveau. Le gain de temps est réel — mais la validation humaine des cas de test générés reste indispensable.

#Accélération de la reprise de données

La migration des données est systématiquement le poste qui dépasse le budget prévu. Nettoyer 15 ans de données clients en doublon, normaliser les référentiels articles qui ont été créés sans règles de gouvernance, réconcilier les soldes comptables entre l'ancien et le nouveau système — ces tâches sont pénibles et répétitives.

L'IA peut détecter automatiquement les doublons dans les référentiels (clients, fournisseurs, articles) mieux que les outils de déduplication classiques sur des jeux de données non normalisés, ce qui réduit le temps de nettoyage.

---

#Intégration API : connecter l'ERP legacy aux nouveaux outils SaaS

Même sans migration complète, connecter un ERP vieillissant aux outils SaaS modernes est devenu une priorité absolue. Un ERP qui ne parle pas à votre CRM, votre outil de BI, votre plateforme logistique ou votre marketplace est un silo qui coûte des heures de ressaisie manuelle chaque semaine.

#L'approche API-first appliquée à l'ERP

La modernisation ERP passe par l'exposition des données et des processus ERP via des API REST ou GraphQL, consommables par n'importe quel outil externe. SAP Business One dispose d'une API de type OData documentée (Service Layer). Sage X3 propose depuis v11 une API REST native. Dynamics 365 Business Central est nativement API-first avec une documentation OpenAPI complète.

Pour les ERP qui ne disposent pas d'API native moderne (versions anciennes, ERP verticaux), la solution est une couche middleware : un iPaaS comme MuleSoft, Boomi, Make ou n8n expose les données ERP via des connecteurs JDBC/ODBC et les met à disposition des applications consommatrices sans modifier l'ERP lui-même.

#Les intégrations prioritaires pour une ETI en 2026

ERP → CRM (Salesforce, HubSpot) : synchronisation des devis, commandes et historiques clients. Un commercial qui doit basculer entre l'ERP et le CRM perd du temps chaque jour en ressaisie. L'intégration le supprime presque.

ERP → BI (Power BI, Tableau, Looker) : extraction automatique des données financières, commerciales et opérationnelles pour le reporting décisionnel. Sans intégration, les tableaux de bord sont reconstruits manuellement chaque semaine à partir d'exports Excel — avec tous les risques d'erreur que cela implique.

ERP → plateforme e-commerce (Shopify, Magento, PrestaShop) : synchronisation des stocks, des prix et des commandes en temps réel. Sur une ETI qui fait 20 % ou plus de son CA en ligne, un décalage de stock entre l'ERP et la boutique en ligne peut coûter des milliers d'euros de pénalités logistiques et de perte de clients.

ERP → portail fournisseurs et EDI : automatisation des flux de commandes d'achat, confirmation de livraison, rapprochement de factures. L'IA peut désormais lire et interpréter des factures PDF fournisseurs pour les réconcilier automatiquement avec les commandes d'achat ERP — un cas d'usage dont le gain se mesure rapidement.

Cette approche API-first est détaillée dans notre guide API-first design pour le B2B en 2026 qui couvre les patterns d'architecture et les outils recommandés.

---

#Le rôle des agents IA dans l'automatisation des processus ERP

Au-delà de l'accélération de la migration elle-même, les agents IA représentent la transformation la plus profonde des usages ERP en 2026. Un ERP modernisé devient la base de données opérationnelle que des agents autonomes manipulent sans intervention humaine sur les tâches routinières.

#Qu'est-ce qu'un agent IA dans le contexte ERP ?

Un agent IA est un programme autonome qui observe un état, prend des décisions et exécute des actions via des outils — dont les API de l'ERP. Contrairement à un simple chatbot ou à une automatisation RPA classique, un agent IA peut enchaîner plusieurs étapes logiques, gérer des exceptions, consulter des données externes et produire une réponse adaptée au contexte.

Appliqué à l'ERP, cela donne par exemple : un agent qui surveille les niveaux de stock, génère automatiquement des propositions de réapprovionnement, consulte les délais fournisseurs via l'API du portail achats, et crée les commandes d'achat dans l'ERP après validation d'un email automatique envoyé au responsable achats.

#Les 5 cas d'usage les plus déployés en ETI

1. Rapprochement automatique des factures fournisseurs : l'agent lit les factures PDF reçues par email, extrait les données clés (montant, IBAN, référence commande), les réconcilie avec les bons de commande et les bons de réception dans l'ERP, et soit valide le paiement automatiquement (< montant seuil), soit soumet pour validation humaine.

2. Prévision et réassort automatique : l'agent analyse les historiques de vente, les tendances saisonnières et les délais fournisseurs pour générer des propositions de réassort optimisées. On mesure l'effet sur le taux de rupture et sur le capital immobilisé en stock.

3. Qualification et relance crédit clients : l'agent surveille les encours clients dans l'ERP, identifie les retards de paiement, envoie des relances automatiques graduées (email J+5, appel J+15, mise en demeure J+30) et met à jour les notes de risque crédit dans le CRM. On suit l'évolution du DSO (Days Sales Outstanding).

4. Génération automatique des reporting mensuels : l'agent extrait les données de l'ERP en fin de mois, génère les tableaux de bord financiers et opérationnels au format PowerPoint ou PDF, et les envoie aux bonnes personnes sans intervention humaine. Le CFO reçoit son reporting à 7h le 1er du mois.

5. Support utilisateur ERP de premier niveau : un agent conversationnel connecté à la documentation de l'ERP et à la base de connaissances interne répond aux questions des utilisateurs ("Comment créer un avoir ?", "Pourquoi ma commande est bloquée ?") et déclenche des procédures standard sans mobiliser le support IT. On mesure la baisse des tickets de support ERP.

Notre analyse du ROI des agents IA en entreprise couvre la méthode de calcul pour justifier ces projets auprès des directions générales.

---

#Budget et planning : fourchettes réelles par taille d'entreprise

Les budgets ERP sont systématiquement sous-estimés lors de la prise de décision initiale. Ils se composent des mêmes postes quelle que soit la taille, mais pas dans les mêmes proportions. Ils se chiffrent sur devis, en 48 h après un premier échange.

#ETI de 50 à 150 salariés — Migration ou modernisation

Périmètre typique : SAP B1 ou Sage X3 avec quelques dizaines d'utilisateurs, quelques personnalisations significatives, intégrations limitées.

Postes du budget : licences (SaaS, sur 3 ans), intégration et paramétrage, reprise de données, formation des utilisateurs, tests et recette.

Durée : plusieurs mois. Risque principal : les personnalisations non documentées qui surgissent en phase de recette.

#ETI de 150 à 500 salariés — Migration complète avec intégrations

Périmètre typique : SAP B1, Sage X3 ou Dynamics 365 avec plusieurs dizaines à plus d'une centaine d'utilisateurs, personnalisations étendues, intégrations CRM/BI/logistique.

Postes du budget : licences (SaaS, sur 3 ans), intégration et paramétrage, personnalisations et API, reprise de données, formation et conduite du changement, tests et recette, contingence.

Durée : de 8 à 18 mois. Les projets qui durent plus de 18 mois subissent régulièrement une dérive fonctionnelle liée aux évolutions de l'entreprise pendant le projet.

#ETI de 500 à 2 000 salariés — Remplacement complet

Périmètre typique : remplacement d'un ERP on-premise (SAP ECC, Sage X3 multi-sites) par SAP S/4HANA Cloud ou Dynamics 365 Finance & Operations.

Le budget dépend de la complexité sectorielle et du nombre de filiales. Ces projets nécessitent une direction de projet dédiée, un comité de pilotage mensuel au niveau CODIR et un budget de conduite du changement significatif.

Pour comprendre comment dimensionner précisément votre budget, notre article Budget projet IA et transformation digitale 2026 détaille la méthode d'estimation par composant.

---

#Les 5 erreurs classiques des migrations ERP et comment les éviter

Ces erreurs sont observées sur la quasi-totalité des projets ERP qui dérapent. Les éviter ne garantit pas le succès, mais les commettre garantit l'échec ou le dépassement de budget.

#Erreur n°1 — Sous-estimer les personnalisations existantes

Ce qui se passe : l'audit initial estime une quinzaine de personnalisations à migrer. En phase de recette, on en découvre beaucoup plus, dont certaines sont critiques pour la production.

Pourquoi : les personnalisations accumulées sur 10 ans ne sont répertoriées nulle part. Le consultant qui les a faites n'est plus là. Les utilisateurs ne savent plus que certaines fonctions sont des personnalisations et pas des fonctions standard.

Comment l'éviter : audit de personnalisation assisté par IA en phase 0, avant tout engagement contractuel avec l'intégrateur. Notre service modernisation legacy inclut systématiquement cet audit.

#Erreur n°2 — Négliger la reprise de données

Ce qui se passe : la reprise de données est estimée à quelques semaines, elle prend plusieurs mois. La date de go-live est repoussée. Les équipes s'épuisent à nettoyer des données que personne n'avait regardées depuis des années.

Pourquoi : 15 ans de données ERP contiennent des milliers de doublons clients, des référentiels articles incohérents, des unités de mesure multiples pour les mêmes articles, des soldes comptables non réconciliés. Ce travail de nettoyage est fastidieux et non compressible.

Comment l'éviter : démarrer l'audit des données 3 à 6 mois avant le démarrage du projet de migration. Utiliser des outils de dataquality (Talend, OpenRefine, ou des scripts IA) pour évaluer le niveau de qualité réel du référentiel avant de lancer la reprise.

#Erreur n°3 — Coupler migration et évolutions fonctionnelles

Ce qui se passe : les équipes métier profitent du projet ERP pour demander des améliorations fonctionnelles. Le périmètre du projet grossit. Le budget et le délai dérapent. L'intégrateur facture des avenants.

Pourquoi : une migration ERP est un moment de visibilité exceptionnelle pour les équipes métier. Elles voient le nouveau système et réalisent qu'elles pourraient en faire plus. La tentation est forte de traiter ces demandes dans le projet en cours.

Comment l'éviter : séparer contractuellement et budgétairement la migration «à comportement identique» des évolutions fonctionnelles. Créer un backlog d'évolutions distinct, à prioriser et budgéter séparément après le go-live. Cette discipline est décrite dans notre approche de la dette technique.

#Erreur n°4 — Sous-investir dans la formation et la conduite du changement

Ce qui se passe : Quelques jours de formation sont prévus pour les utilisateurs. Les utilisateurs arrivent le jour J sans savoir utiliser le nouveau système. La productivité s'effondre pendant plusieurs mois. Des erreurs de saisie créent des anomalies comptables. La direction regrette la migration.

Pourquoi : la conduite du changement est toujours la première victime des économies de fin de projet. "On fera une formation rapide, les utilisateurs s'adapteront."

Comment l'éviter : budgéter une part significative du budget total en conduite du changement et formation. Impliquer les utilisateurs clés dès la phase de paramétrage (key users). Prévoir un support renforcé pendant les 3 premiers mois après le go-live.

#Erreur n°5 — Choisir l'intégrateur sur le seul critère du prix

Ce qui se passe : l'intégrateur le moins cher remporte l'appel d'offres. Il sous-traite à des consultants juniors sans expérience sectorielle. Les délais explosent. L'ETI doit faire appel à un second intégrateur pour corriger le travail du premier. Le coût final est plus élevé que l'offre initiale la plus chère.

Pourquoi : le prix journalier d'un consultant ERP senior avec expérience sectorielle est nettement plus élevé que celui d'un consultant junior. Les intégrateurs qui proposent des prix bas le font en positionnant des profils moins expérimentés.

Comment l'éviter : évaluer les intégrateurs sur leurs références sectorielles, la seniorité des profils positionnés sur le projet (exiger des CV nominatifs), et leur méthode de gestion des risques. Un audit de transformation digitale préalable permet de poser les bases d'un appel d'offres rigoureux.

---

#Le rôle de l'architecture dans la réussite d'une migration ERP

Une migration ERP n'est pas seulement un projet de remplacement logiciel — c'est une décision d'architecture qui engage l'entreprise pour 10 à 15 ans. Deux questions d'architecture sont critiques.

#Monolithe ERP vs architecture modulaire

Les ERP traditionnels sont des monolithes : comptabilité, stocks, production, ventes, achats dans une seule application. Cette approche a l'avantage de la cohérence et de la simplicité — une seule base de données, un seul référentiel, un seul contrat de support.

L'alternative émergente est l'architecture composable (ou best-of-breed) : un ERP financier solide (NetSuite, Cegid) complété par des applications spécialisées pour la production (MES), la logistique (WMS) et les ventes (CRM), le tout intégré via une couche API. Cette approche offre plus de flexibilité mais exige une gouvernance d'intégration rigoureuse.

Notre article sur monolithe vs microservices traite des critères de choix architecturaux qui s'appliquent également au périmètre ERP.

#L'ERP comme hub d'événements

Les ERP modernes (SAP S/4HANA, Dynamics 365) publient des événements métier en temps réel — une commande créée, un stock mis à jour, une facture validée. Ces événements peuvent être consommés par d'autres systèmes via une architecture event-driven, éliminant les synchronisations batch nocturnes et les délais de mise à jour entre systèmes.

Cette approche, détaillée dans notre guide event-driven architecture pour l'entreprise, transforme l'ERP d'un système d'enregistrement passif en un hub actif qui orchestre les processus de l'entreprise en temps réel.

---

#Exemple de situation : ETI industrielle, de Sage X3 vers un modèle hybride

Cet exemple est une situation type, construite pour illustrer la démarche. Ce n'est pas un client réel et il ne contient aucun résultat chiffré.

Une ETI industrielle du secteur des équipements mécaniques fait face à une situation critique : Sage X3 dans une version ancienne, de nombreuses personnalisations en scripts 4GL dont la moitié ne sont pas documentées, une fin de support éditeur qui approche, et une intégration manuelle hebdomadaire avec sa plateforme e-commerce B2B (exports CSV, ressaisie) qui mobilise plusieurs personnes.

#Diagnostic initial

L'audit assisté par IA du périmètre Sage X3 révèle typiquement :

• bien plus de personnalisations actives que celles recensées par l'équipe IT ;
• des personnalisations critiques qui encodent des règles de tarification client (remises négociées, coefficients sectoriels, prix nets contractuels) ;
• des scripts défaillants tolérés depuis des années, avec des contournements manuels ;
• des doublons dans le référentiel clients-prospects ;
• des références articles actives avec des données incomplètes ou incohérentes.

#Décision d'architecture

Un remplacement complet par SAP S/4HANA représenterait un projet long et coûteux, hors de portée de la fenêtre de contrainte de l'éditeur. La solution retenue dans cet exemple : un modèle hybride en 3 phases.

Phase 1 : migration vers Sage X3 v12 Cloud (même éditeur, chemin documenté) avec réécriture assistée par IA des personnalisations critiques en format natif. Les scripts défaillants sont remplacés par des fonctions standard de la v12.

Phase 2 : couche d'intégration API via un iPaaS (Make, par exemple) qui connecte Sage X3 à la plateforme e-commerce B2B, au CRM et à l'outil de BI. Fin des exports CSV manuels.

Phase 3 : déploiement de quelques agents IA — réassort automatique, relance crédit, réconciliation de factures fournisseurs.

#Ce qu'on mesure

Pour juger la démarche : la conformité au support éditeur rétablie avant l'échéance, le temps libéré sur les tâches d'intégration manuelle, l'évolution du DSO, le taux de rupture de stock et le respect du budget initial. Ces indicateurs se calculent sur les données de l'entreprise, avant et après.

Le facteur clé de succès : avoir conduit l'audit de personnalisation en phase 0, avant de définir l'approche. Sans cet audit, une migration directe lancée sur la base de l'estimation d'un intégrateur découvre la complexité des personnalisations en phase de recette.

Ce type d'approche progressive s'inscrit dans la logique de modernisation sans big bang que nous documentons systématiquement sur les projets legacy. Pour les ETI qui veulent évaluer leur situation avant de s'engager, notre service modernisation legacy propose un diagnostic préalable.

Photos : ThisIsEngineering, RDNE Stock project sur Pexels.