Adopt vs Adapt : Comment l’IA redéfinit votre transformation ERP Retail

Pourquoi « Adapt » séduit (et piège)

Adapter l’ERP aux processus existants rassure les opérationnels. On ne change pas leurs habitudes. Les équipes adhèrent plus facilement.

Mais le prix est lourd :

• Des spécifiques coûteux à construire et à maintenir dans le temps.
• Des montées de version bloquées ou dramatiquement chères.
• La perte des évolutions fonctionnelles et de la roadmap de l’éditeur.
• Une dette technique qui s’accumule silencieusement au cœur du système.

Par exemple une enseigne avait tellement customiser son ERP que la montée de version est devenue un projet à part entière : plusieurs trimestres, une équipe dédiée, et finalement le choix de rester sur une version non supportée parce que migrer coûtait trop cher. Le spécifique d’hier est devenu la prison d’aujourd’hui.

Car jusqu’ici, adapter un processus voulait dire une seule chose : modifier le cœur de l’ERP. Les deux étaient indissociables. Retenez ce point, l’IA va précisément le remettre en cause.

« Nos processus sont uniques » : conviction, héritage ou nécessité concurrentielle ?

C’est l’argument que nous entendons dans chaque projet, chez chaque enseigne. Et il est légitime ! Chaque distributeur a effectivement construit ses propres façons de faire, souvent depuis des décennies.

Mais la vraie question est celle-ci : ces processus sont-ils uniques par conviction, par héritage d’une organisation qui n’existe plus, ou par nécessité concurrentielle réelle ?

• Un processus de gestion des promotions qui se différencie de la concurrence et génère un avantage commercial mesurable : oui, il mérite un spécifique.
• Un processus d’approvisionnement « à notre façon » hérité d’une organisation révolue : non. C’est souvent là que le travail de cadrage est le plus délicat, et le plus précieux.

Pourquoi « Adopt » est difficile (mais souvent gagnant)

Adopter les processus standards de l’ERP accélère la construction de la solution. L’éditeur a déjà pensé les processus, capitalisant sur de nombreux déploiements Retail. Pas de spécifiques, pas de développements lourds.

Mais soyons honnêtes : adopter a aussi un prix. Le standard, ce sont les compromis d’un éditeur, alignés sur sa feuille de route commerciale autant que sur votre métier. Une « best practice » est parfois une pratique moyenne, pensée pour le plus grand nombre, pas l’optimum pour votre enseigne. Adopter, c’est accepter d’hériter du modèle d’un autre.

Et c’est demander aux équipes métier de changer des habitudes parfois ancrées depuis 20 ans. La conduite du changement devient alors le vrai projet, et c’est là que beaucoup sous-estiment la complexité et l’investissement nécessaire pour transformer les pratiques.

C’est inconfortable. Ça génère de la résistance. Mais quand le standard couvre correctement le besoin, le gain est réel :

• Hériter de processus déjà éprouvés sur de nombreux déploiements Retail, sans les concevoir ni les maintenir soi-même.
• Réduire fortement les coûts de maintenance, car il n’y a pas de code spécifique à porter dans le temps.
• Rester dans le rythme des évolutions de l’éditeur, sans rupture à chaque montée de version.

La vraie question n’est donc pas « standard ou spécifique ? », mais : sur ce processus précis, le coût d’adoption, changement compris, est-il inférieur au coût de possession d’un spécifique sur la durée ? Le plus souvent, oui. Pas toujours.

Ce que l’IA change vraiment (et l’illusion du « sans risque »)

Quoi qu’on en dise, l’IA ne crée pas de troisième voie. Le choix reste binaire : sur chaque processus, standard ou spécifique. Mais ce qu’elle change est ailleurs, et c’est plus subtil.

Jusqu’ici, garder son processus et modifier le cœur de l’ERP, c’était la même chose : adapter le processus obligeait à adapter le cœur. L’IA découple enfin ces deux gestes, dans une limite précise : tant que le besoin n’oblige pas à modifier le modèle de données de l’ERP. Sous cette condition, le spécifique se traite en dehors de l’ERP, par des agents ou des applications qui exploitent ses données sans y toucher. On adopte le cœur ET on adapte le processus. L’ERP reste standard, les montées de version ne sont plus bloquées.

C’est cette frontière qui commande tout. Tant que l’extension lit, calcule et orchestre autour des données existantes, elle vit à côté sans risque direct pour le socle. Dès que l’ERP lui-même doit stocker ou gérer nativement un nouvel objet métier, on a franchi la limite : on est retombé dans le spécifique embarqué, avec tous ses inconvénients.

Exemple dans le Retail

Pour optimiser la démarque sur les produits frais en fin de vie, plutôt que de développer un algorithme lourd et sur-mesure au sein du moteur de tarification natif de l’ERP (ce qui détruirait le standard), on déploie un agent IA en périphérie. Cet agent analyse les stocks et la météo locale via une API, puis propose des remises dynamiques que l’ERP applique de façon standard. Le cœur transactionnel reste inchangé, l’intelligence métier vit à côté.

Attention à l’illusion du « zéro dette »

Déporter le spécifique à l’extérieur ne l’annule pas. Si l’éditeur de l’ERP fait évoluer ses API standards lors d’une mise à jour majeure, toutes vos extensions périphériques peuvent casser d’un coup. De plus, connecter des agents IA aux données les plus sensibles de l’ERP (marges, tarifs d’achat, bases clients) exige un cadre de gouvernance et de sécurité informatique extrêmement rigoureux pour maîtriser l’accès aux flux de données.

Mais le piège, lui, se déplace

Car le levier qui rend l’adaptation accessible est exactement celui qui pousse à sur-adapter.

Si construire un spécifique devient simple et rapide, la tentation est de plaquer un outil sur chaque irritant, sans jamais se demander si le processus, lui, méritait d’être conservé. On habille des pratiques non optimisées au lieu de les transformer. On fige l’héritage au lieu de le questionner.

Le résultat est le piège d’hier, en pire : le spécifique IA mal gouverné, c’est le spécifique embarqué d’antan, en plus rapide à produire, donc en plus facile à multiplier. Au bout du compte, un ERP qui ne délivre pas la valeur attendue : on a payé pour les processus éprouvés de l’éditeur, et on continue de travailler exactement comme avant.

La facilité technique ne dispense jamais de la question de fond. Elle la rend plus urgente.

Le cadrage, seul vrai rempart

Si l’adaptation devient facile, c’est en amont que tout se joue. Le seul rempart contre la complexité qui revient, c’est un cadrage qui tranche, processus par processus. Pour chaque processus « maison », trois cas possibles :

1. Premier cas : il est un avantage concurrentiel différenciant et mesurable. On adapte, par choix stratégique assumé. C’est le seul qui mérite vraiment un spécifique.
2. Deuxième cas : il ne l’est pas, et le standard le couvre correctement. On adopte, et on investit sérieusement dans la conduite du changement. C’est le cas le plus fréquent, héritage compris.
3. Troisième cas : il ne l’est pas, mais le standard ne le couvre pas (obligation réglementaire locale, spécificité logistique ou fournisseur historique). On adapte, mais a minima et par nécessité, pas par stratégie. Juste de quoi combler le trou.

Les premier et troisième cas débouchent souvent sur la même solution technique : une extension portée par l’IA, ou un développement embarqué si le modèle de données l’impose. Mais l’intention est opposée : le premier cultive un avantage, le troisième bouche un trou. Les confondre, c’est traiter chaque irritant comme un différenciant, et rouvrir la porte à la sur-adaptation.

Ce travail n’est pas qu’une analyse fonctionnelle. Il s’agit de séparer, dans les pratiques actuelles, le différenciant qu’on veut conserver de l’héritage qu’on doit transformer. C’est inconfortable, c’est politique, et c’est là que se gagne, ou se perd, la transformation. C’est aussi le seul moyen d’éviter de plaquer demain des outils IA sur des processus qu’on aurait dû remettre à plat.

Et, c’est nouveau, la question « avec quelle technologie ? » se pose désormais pour chaque spécifique. On ne peut plus traiter le métier d’un côté et l’architecture de l’autre. Surtout, ce travail doit précéder l’appel d’offres. Car choisir la techno, c’est choisir le prestataire : un intégrateur ERP pur sait faire l’embarqué, pas forcément l’extension. Un appel d’offres rédigé sans cette clarté sélectionne le mauvais dispositif, et on s’en aperçoit toujours trop tard.

La méthode pour reprendre le contrôle

Pour naviguer dans cette nouvelle complexité, une démarche structurée en trois temps s’impose avant tout projet de transformation :

• L’audit de l’héritage : Cartographier sans concession les processus existants pour distinguer ce qui apporte une réelle valeur marchande de ce qui relève de la simple habitude historique.
• L’arbitrage de la frontière : Décider pour chaque besoin si l’écart au standard doit être traité dans le cœur de l’ERP (si le modèle de données l’exige) ou déporté sur une extension IA périphérique.
• La gouvernance de l’écosystème : Définir le cadre d’intégration (sécurité des données, pérennité des API, cycle de vie des agents) afin de s’assurer que la périphérie ne devienne pas une nouvelle prison technique.

C’est précisément cette approche, alliant l’expertise métier Retail, la maîtrise des architectures ERP et la capacité à bâtir des extensions IA de confiance, que nous mettons en œuvre chez Onepoint. Nous vous aidons à trancher, processus par processus, ce qu’on adopte, ce qu’on adapte, et de quel côté de la frontière.

Et vous, comment avez-vous tranché sur vos derniers projets ERP ?

Un projet, des questions, n’hésitez pas à nous contacter