La conversation commence toujours pareil. Tu veux que l'IA fasse quelque chose d'utile de tes commandes, de tes factures ou de tes tickets, et quelqu'un —un intégrateur, un commercial, un conseiller de bonne foi— t'explique qu'il faut d'abord mettre de l'ordre dans la maison : migrer vers une plateforme neuve, moderne, avec API, et ensuite on montera les agents dessus. Ça sonne comme du bon sens. Et pour une entreprise de vingt mille personnes, ça l'est probablement. Pour une de deux cents, c'est un détour de dix-huit mois pendant lequel l'IA ne touche pas un seul processus et où le business se fige le temps du déménagement.
La décision de fond, ce n'est pas quel outil acheter. C'est celle-ci : est-ce que le vieux système est vraiment ce qui te bloque, ou seulement ce qu'il est le plus facile d'accuser ?
Migrer le système legacy ou poser des agents IA dessus : deux routes, et aucune n'est gratuite
Il y a deux chemins et il vaut mieux les appeler par leur nom, parce que le marketing les mélange exprès.
- Replatform (migrer). Tu remplaces le système de registre —l'ERP, le CRM, le logiciel métier— par un autre. La donnée déménage, les processus se refont, l'équipe se rééduque. L'IA arrive après, si elle arrive.
- Overlay (poser dessus). Tu laisses le système où il est et tu montes une couche d'agents qui lit et écrit contre lui par API, par MCP ou par le connecteur disponible. Le système de registre ne change pas ; ce qui change, c'est qui fait le travail autour.
Le piège habituel, c'est de présenter l'overlay comme un pansement et le replatform comme la solution sérieuse. C'est faux : ce sont deux paris différents avec deux factures différentes, et les deux ont leurs petites lignes. Ce qui suit, ce sont les symptômes pour savoir dans lequel tu es.
Le détour de dix-huit mois a un chiffre derrière
L'argument du « on migre d'abord » repose sur une promesse : que le projet se termine quand le plan le dit. Les données du secteur ne suivent pas. Le rapport annuel de Panorama Consulting Group sur les projets de logiciel d'entreprise, publié le 4 mars 2026, a trouvé que plus d'un quart des organisations a dépassé son budget de projet, et pointe comme cause principale le besoin de technologie supplémentaire.
Le détail intéressant, ce n'est pas le pourcentage : c'est le mécanisme décrit. Selon le rapport lui-même, les organisations découvrent les désajustements graves tard dans le projet, et leur réaction est de recourir à plus de technologie, d'élargir le périmètre et de construire des développements sur mesure. Autrement dit : le surcoût ne vient pas d'avoir mal choisi le logiciel, il vient d'avoir découvert trop tard que ça ne collait pas. Source : The 2026 ERP Report, Panorama Consulting Group, 4 mars 2026.
Traduit dans ta décision : si tu migres pour pouvoir mettre de l'IA, tu paries que dans un an et demi tu auras une plateforme neuve et l'envie d'attaquer le projet d'IA. Les deux hypothèses sont optimistes en même temps.
Quand le vieil outil EST vraiment le goulot d'étranglement
Il y a quatre symptômes qui justifient de migrer, et aucun n'est « il est vieux ». On les reconnaît parce qu'ils bloquent le travail, pas parce qu'ils agacent :
- La donnée ne se lit pas. Pas d'API, pas d'export programmable, pas de base à laquelle se connecter. Rien que des écrans. Tu peux robotiser l'écran, mais ça s'appelle du RPA et ça casse chaque fois que l'éditeur déplace un bouton.
- La licence meurt. L'éditeur a annoncé une fin de support avec une date, ou le système tourne sur une version que plus personne ne patche. Ici, ce n'est pas toi qui décides du calendrier : on te l'a imposé.
- La conformité t'y oblige. Une nouvelle règle exige quelque chose que le système ne sait pas faire —un registre inaltérable, une traçabilité, un format de transmission— et aucun correctif n'y suffit.
- Le système est le processus. Il ne se contente pas de stocker la donnée : la logique métier vit dedans, dans des développements que personne n'a documentés et que seule comprend une personne qui part à la retraite dans deux ans.
Si tu es dans l'un de ces quatre cas, migre. Et si tu migres, fais-le pour la bonne raison et ne le déguise pas en projet d'IA : ce sont deux budgets, deux calendriers et deux équipes.
Quand il ne l'est pas, et que tu achètes l'agenda de quelqu'un d'autre
Le cas de loin le plus fréquent est l'inverse : le vieux système marche, il garde bien la donnée et il a une API raisonnable, mais il est moche, l'interface date de 2014 et personne ne prend plaisir à s'en servir. Ce n'est pas un goulot d'étranglement : c'est un agacement. Et un agacement ne justifie pas dix-huit mois.
Le signal d'alarme le plus fiable, c'est qui apporte la proposition. Si la route « migrer d'abord » est proposée par celui qui vend la plateforme d'arrivée ou par celui qui facture la migration, tu ne reçois pas un diagnostic : tu reçois son agenda commercial, qui est légitime mais qui n'est pas le tien. Pose la seule question qui sépare les deux : quel processus concret ne peut pas être automatisé aujourd'hui sans migrer, et pourquoi ? Si la réponse est générique —« pour avoir une base solide », « pour être prêts »—, la réponse est que si, on peut.
Il y a une nuance qui revient de plus en plus : certaines plateformes embarquent déjà leurs propres agents, donc migrer semble apporter l'IA incluse. Elles en apportent une partie, et cette partie a sa propre facture. Dans Dynamics 365 Business Central, par exemple, les agents natifs se facturent à la consommation et la documentation de Microsoft est explicite : quand le quota est épuisé, la capacité d'IA cesse d'être disponible jusqu'à ce qu'on en rajoute. Ce n'est pas une raison de ne pas migrer ; c'est une raison de ne pas compter l'IA native comme si elle était gratuite. Ce calcul, dans ce cas précis, est détaillé dans automatiser Business Central avec l'IA. Source : Manage consumption-based billing for agent capabilities, Microsoft Learn, mis à jour le 8 juillet 2026.
Le coût caché de l'overlay, qu'on ne te raconte pas non plus
Ce serait malhonnête de vendre l'overlay comme l'option sans facture. Il a trois coûts réels et il vaut mieux les regarder avant, pas après :
- Dette d'intégration. Chaque connexion que tu montes est une pièce qu'il faut maintenir. Quand le fournisseur change son API ou son modèle, quelqu'un doit réparer — et cette ligne budgétaire, c'est exactement la maintenance des automatisations IA, celle que personne ne budgète.
- Permissions éparpillées. L'agent a besoin d'identifiants dans le vieux système, et les vieux systèmes ont souvent un modèle de permissions en tout ou rien. Bien le résoudre coûte du travail ; mal le résoudre coûte un incident.
- Double source de vérité. Si la couche d'agents se met à garder son propre état —sa mémoire, sa file, ses décisions—, tu finis avec deux endroits où regarder. La règle est simple : le système de registre reste le système de registre, et la couche ne garde rien qu'elle ne puisse reconstruire.
Et il y a un quatrième coût qui n'est pas de maintenance mais de propriété : la couche que tu poses dessus périme aussi. OpenAI a présenté Agent Builder, son canevas visuel pour monter des agents, en octobre 2025 ; il en a annoncé la dépréciation le 3 juin 2026 et fixé l'extinction au 30 novembre 2026. Treize mois. C'est pour ça que la question de savoir sur quelle couche tu montes l'overlay et ce qu'on te laisse emporter n'est pas mineure, et elle est développée dans sur quelle couche vit ton agent et ce que coûte la sortie. Source : Agent Builder, documentation OpenAI, consultée le 7 septembre 2026.
La règle, en une phrase
Presque toutes les entreprises moyennes qui se posent cette question sont dans le second cas et croient être dans le premier. La différence se vérifie en une après-midi : essaie de sortir par API les cent derniers enregistrements du processus qui te fait mal. S'ils sortent, tu n'as pas besoin de migrer pour commencer. S'ils ne sortent pas, tu sais pourquoi tu migres — et tu sais aussi que l'IA est le deuxième projet, pas le premier.
Comment trancher cette semaine, sans comité
- Choisis un processus, pas une stratégie. Celui qui bouffe le plus d'heures. Un seul.
- Vérifie l'accès à la donnée. Est-ce qu'on peut lire et écrire par API ou par connecteur ? Une demi-après-midi de travail technique répond à ça, et y répond pour de vrai.
- Mets une date sur les obligations. Fin de support, changements réglementaires, contrats qui arrivent à échéance. S'il y a une date réelle, c'est elle qui commande.
- Estime les deux routes pour CE processus. Pas pour l'entreprise entière : pour ce processus. L'overlay s'estime en semaines ; si ton estimation d'overlay sort elle aussi en trimestres, quelque chose est mal posé.
- Décide et écris-le. Avec le motif. Dans un an, quelqu'un va demander pourquoi, et « on nous l'a recommandé » n'est pas une réponse.
Nous, on fait presque toujours la seconde, et pas par dogme : parce que dans la plupart des cas qui nous arrivent la donnée est déjà lisible et ce qui manque, c'est que quelqu'un fasse le travail. On monte la couche contre le système que tu as déjà —c'est comme ça qu'on intègre l'IA avec les systèmes que tu utilises déjà—, on mesure ce que ça économise et, si en chemin apparaît l'un des quatre symptômes du dessus, on le dit. On ne vend pas de migrations. On ne vend pas non plus l'idée qu'il ne faut jamais migrer.