Migration ERP : ce que ça coûte vraiment et comment ne pas la rater

Le premier lundi après une bascule, la question qui remonte des équipes n'est presque jamais « comment on saisit une commande ». C'est « pourquoi le stock affiche 340 alors qu'on en a douze en rayon ». Le logiciel fonctionne. Les écrans répondent. Ce sont les données qui racontent n'importe quoi, et personne ne sait à quel moment elles ont dévié.

Sur les projets qui dérapent, la cause tient rarement au produit retenu. Elle tient à ce qu'on a versé dedans. Un référentiel article avec trois orthographes pour la même référence produit trois lignes de stock distinctes. Un fichier client rempli de doublons produit des relances envoyées deux fois. Le facteur déterminant n'est presque jamais l'outil : c'est l'état de vos données.

Cet article ne redéfinit pas les termes. Notre lexique le fait déjà pour la migration ERP et pour l'intégration ERP, si vous cherchez une définition courte. Ce qui suit traite ce qu'une définition ne porte pas : les déclencheurs réels, les stratégies de bascule, le périmètre de reprise, la décomposition du coût, le calendrier et les situations où migrer est une mauvaise idée. Un ERP, pour rappel utile, est le logiciel unique qui porte les ventes, les achats, les stocks et la comptabilité d'une entreprise.

Ce qui déclenche réellement une migration ERP

Une précision de vocabulaire avant tout le reste, parce qu'elle change le budget d'un facteur dix. Passer de la version 17 à la version 19 du même logiciel n'est pas une migration ERP : c'est une montée de version, une opération outillée par l'éditeur. La documentation d'Odoo sur les mises à niveau décrit ainsi un enchaînement standardisé de trois temps, base de test, validation, puis production. Changer d'éditeur est un autre exercice : rien n'est outillé, tout est à reconstruire.

Personne ne change d'ERP pour le plaisir. Dans les projets que nous voyons arriver, le déclencheur appartient presque toujours à l'une des cinq familles suivantes. Identifier laquelle vous concerne change le cadrage, le budget et surtout l'urgence.

L'éditeur arrête le support. C'est le déclencheur le plus fréquent et le plus mal anticipé. Une version cesse d'être maintenue, les correctifs de sécurité s'arrêtent, l'expert-comptable signale que le format d'export n'est plus accepté. L'entreprise se retrouve à conduire en douze mois un projet qu'elle aurait dû étaler sur vingt-quatre. Le calendrier devient subi, et cela se paie sur la qualité de la recette.

La croissance a fait sortir l'outil de son cadre. Le logiciel a été choisi pour une entreprise mono-site, mono-société, mono-devise. Elle est devenue multi-entrepôts et vend sur trois canaux. Le symptôme est reconnaissable : les fichiers Excel se multiplient à côté de l'ERP pour compenser ce qu'il ne sait pas faire. Chez IDC Pharma, dix-sept sites de vente sont unifiés dans un système de gestion d'entrepôt multi-entrepôts, un périmètre qu'une organisation éclatée n'absorbe pas.

Un rachat ou une fusion impose la convergence. Deux sociétés, deux ERP, une consolidation à produire chaque mois. C'est le cas de figure le plus coûteux, parce qu'il combine la migration technique et l'harmonisation des référentiels de deux organisations qui ne codifient pas leurs articles de la même manière. La convergence des référentiels est précisément ce qui coûte le plus dans ce cas de figure.

Une obligation réglementaire rend l'existant non conforme. La facturation électronique en est l'exemple actuel. À compter du 1er septembre 2026, toutes les entreprises françaises assujetties à la TVA devront être en mesure de recevoir des factures électroniques, et les grandes entreprises ainsi que les entreprises de taille intermédiaire devront les émettre à cette même date, les PME et micro-entreprises suivant au 1er septembre 2027, selon la documentation de l'administration fiscale. Un ERP qui ne sait pas produire un format structuré et dialoguer avec une plateforme agréée devient un problème daté. Notre lexique détaille le fonctionnement de la facturation électronique.

Le coût de maintenance de l'existant dépasse le coût du remplacement. Ce calcul est rarement fait, et il est pourtant le plus honnête. Additionnez la maintenance annuelle, les développements spécifiques que chaque évolution exige, les journées de prestataire pour des corrections, et le temps interne passé à contourner l'outil. Comparez à un budget de migration amorti sur cinq ans. La réponse n'est pas toujours celle qu'on croit, dans un sens comme dans l'autre.

Qu'est-ce qui fait vraiment dérailler une migration ERP ?

L'état des données reprises, très loin devant le produit retenu. Deux entreprises comparables migrent vers le même ERP, avec le même intégrateur, sur le même périmètre : l'une bascule en dix semaines, l'autre en sept mois. L'écart vient de ce qu'il a fallu réparer avant de pouvoir importer quoi que ce soit.

Une donnée sale ne se voit pas dans l'ancien système, parce que les utilisateurs ont appris à vivre avec. Ils savent que la référence « ADH-200 » et la référence « ADH200 » désignent le même produit. Ils savent que le client « Martin SA » et « SA Martin » sont la même entité. Le nouvel ERP ne le sait pas. Il applique les règles. Et c'est précisément à ce moment que les vingt années de tolérance accumulée deviennent visibles, toutes en même temps.

Cinq tests à faire avant de choisir un logiciel

Ces vérifications se font sur des extractions du système actuel, avant même d'ouvrir une discussion produit. Elles demandent une journée à un contrôleur de gestion et déterminent une part importante du budget à venir.

• Le taux de doublons sur le fichier client. Triez sur le numéro SIRET, puis sur la raison sociale normalisée. Un fichier de deux mille comptes qui contient trois cents doublons n'est pas un fichier de deux mille comptes.
• Les articles sans famille, sans unité, sans prix. Comptez les lignes du référentiel article dont un champ structurant est vide. Ce sont autant de lignes qui devront être complétées à la main ou écartées.
• L'écart entre stock théorique et inventaire physique. Si le dernier inventaire a révélé un écart supérieur à quelques pourcents sur les références qui tournent, la reprise du stock devra passer par un comptage complet, pas par un import.
• Les factures non lettrées en comptabilité. Un compte client avec des règlements non rapprochés depuis trois ans produit une balance auxiliaire qu'on ne peut pas reprendre telle quelle.
• Les champs libres détournés de leur usage. Le champ « commentaire » qui contient en réalité le code transporteur, le champ « adresse ligne 3 » qui contient le contact logistique. Chacun de ces détournements est un développement de reprise à écrire.

Tout le reste du chiffrage découle de ces cinq mesures. Une migration où ces cinq tests sont bons se déroule dans les fourchettes basses de budget. Une migration où trois d'entre eux sont mauvais coûte le double, quel que soit le logiciel cible.

Quelle stratégie de bascule choisir pour une migration ERP ?

Quatre approches sont praticables : le big bang, la bascule par module, la bascule par site ou par société, et la double saisie temporaire. Ce choix structure tout le reste, la durée, le coût, la charge sur les équipes et le niveau de risque accepté, et il se décide en cadrage. Voici ce que chacune implique réellement.

Stratégie	Principe	Durée indicative	Risque principal	Profil adapté
Big bang	Tous les modules et tous les utilisateurs basculent à une date unique, l'ancien système est arrêté	La plus courte, souvent 2 à 4 mois de projet sur un périmètre PME simple	Aucun retour arrière praticable, un défaut bloquant arrête l'activité	Structure mono-site, processus homogènes, direction disponible pendant la bascule
Par module	Ventes puis achats puis comptabilité, avec des interfaces temporaires entre ancien et nouveau	Plus longue, chaque palier ajoute des semaines de recette et d'interface	Les interfaces temporaires coûtent cher et créent des écarts entre les deux systèmes	Périmètre fonctionnel large, équipes qui ne peuvent pas tout absorber en une fois
Par site ou par société	Un site pilote bascule seul, les suivants reprennent le paramétrage validé	Longue au global, mais chaque vague est courte après la première	Coexistence prolongée de deux systèmes, consolidation compliquée entre-temps	Multi-sites, multi-sociétés, groupes issus de croissance externe
Double saisie temporaire	Les opérations sont saisies dans les deux systèmes pendant quelques semaines pour comparer	Courte dans le temps, mais très coûteuse en charge interne	Épuisement des équipes, saisies divergentes, abandon en cours de route	Activités où une erreur comptable ou logistique n'est pas rattrapable

Le big bang a mauvaise réputation, souvent à tort. Sur une PME mono-site avec des processus lisibles, c'est la stratégie la moins chère et la plus lisible pour les équipes. Ce qui la rend dangereuse tient à une seule chose : la choisir sans avoir mené une recette sérieuse. La bascule par module, elle, séduit par sa prudence apparente et coûte régulièrement plus cher que prévu, parce que chaque interface temporaire entre l'ancien et le nouveau système est un développement jetable qu'il faudra maintenir puis supprimer.

La double saisie mérite d'être considérée pour ce qu'elle est : une assurance, avec une prime. Elle a un sens sur trois à quatre semaines, sur un périmètre restreint, avec un objectif de comparaison précis. Au-delà, elle épuise les équipes et produit deux jeux de données qui divergent, ce qui est exactement le problème qu'elle prétendait éviter.

La reprise de données : ce qu'on reprend, ce qu'on laisse

C'est la conversation la plus importante du projet, et souvent la plus courte. La demande initiale est presque toujours « on reprend tout ». Elle est presque toujours mauvaise. Reprendre tout signifie importer dans un système neuf des années d'écritures dont personne ne consultera jamais le détail, en payant le développement, le contrôle et le temps de traitement associés.

Type de donnée	Décision courante	Raison
Référentiel clients et fournisseurs actifs	Reprise complète, après dédoublonnage	Base de tout, et donnée que les équipes utilisent chaque jour
Référentiel articles actifs	Reprise complète, après nettoyage et recodification si nécessaire	Une codification incohérente reprise telle quelle contamine le nouveau système
Comptes clients et fournisseurs inactifs depuis plusieurs années	Non repris, conservés dans l'archive	Charge de contrôle sans usage opérationnel
Stocks	Repris par inventaire physique à la date de bascule, pas par import du théorique	Le stock théorique de l'ancien système est rarement exact
Commandes clients et fournisseurs en cours	Reprise obligatoire, souvent partiellement manuelle	Ce sont des engagements vivants, une commande perdue est un client perdu
Balances comptables et à-nouveaux	Repris	Nécessaires pour tenir la comptabilité dans le nouveau système
Historique détaillé des écritures comptables	Rarement repris au-delà de l'exercice en cours et du précédent	L'obligation de conservation se satisfait de l'archive, pas de l'ERP actif
Pièces jointes et factures PDF	Décision au cas par cas, selon le volume et l'usage réel	Poste sous-estimé : plusieurs centaines de milliers de fichiers à rattacher au bon enregistrement
Historique CRM et échanges commerciaux	Repris sur une profondeur limitée, souvent douze à vingt-quatre mois	Au-delà, la valeur commerciale devient marginale

La ligne « pièces jointes » est celle qui surprend le plus. Personne ne la chiffre au cadrage. Elle représente pourtant, sur des entreprises qui dématérialisent depuis dix ans, un volume de fichiers considérable, avec un travail de rattachement automatique à écrire et à contrôler. Posez la question tôt : ces documents sont-ils consultés, et par qui.

Le nettoyage préalable, et qui doit le faire

Le nettoyage ne peut pas être délégué entièrement à l'intégrateur. Un prestataire sait détecter des doublons probables, normaliser des adresses, repérer des incohérences de format. Il ne sait pas dire si « Martin Distribution » et « Martin Distri » sont deux clients ou un seul. Cette décision appartient à quelqu'un qui connaît le portefeuille.

La méthode qui fonctionne consiste à découper le nettoyage par référentiel, avec un responsable nommé pour chacun : le commerce pour les clients, les achats pour les fournisseurs, le bureau d'études ou la production pour les articles, la comptabilité pour les comptes. Chacun reçoit un fichier d'anomalies, tranche, et renvoie. Compter plusieurs semaines calendaires pour cette étape sur un périmètre PME, en parallèle du reste du projet, est réaliste. Prévoir deux jours pour cette étape relève de l'erreur de cadrage.

Techniquement, l'import se fait ensuite par lots. La documentation d'Odoo sur l'import de données recommande explicitement de fractionner les exports et imports volumineux, sous peine d'erreurs de traitement, et insiste sur la conservation de la colonne d'identifiant externe pour éviter les doublons lors des imports successifs. C'est cet identifiant qui permet de rejouer un import corrigé sans tout dupliquer.

Archiver l'ancien système : un coût que personne ne budgète

Arrêter l'ancien ERP ne signifie pas l'effacer. Il faut pouvoir répondre à un contrôle, retrouver une facture de 2019, justifier une écriture. Trois options existent, et elles n'ont pas le même coût.

• Maintenir l'ancien système en lecture seule. Solution la plus simple à décider, la plus chère à tenir. Vous continuez à payer une licence, un hébergement, parfois une maintenance, pour un outil que trois personnes consultent quatre fois par an. Et il faut un poste capable de le faire tourner dans cinq ans.
• Extraire des exports plats horodatés. Fichiers de données brutes plus documents numérisés, déposés sur un stockage sécurisé. Peu coûteux, mais exploitable seulement par quelqu'un qui sait lire la structure. À documenter au moment de l'extraction, pas trois ans plus tard.
• Constituer une archive structurée et interrogeable. Une base de consultation dédiée, avec un accès simple par numéro de facture ou par client. Coût intermédiaire, confort réel, et c'est la solution qui vieillit le mieux.

Quelle que soit l'option, le coût doit apparaître dans le budget de migration. Il est le plus souvent découvert six mois après la bascule, au moment où l'éditeur historique envoie sa facture de renouvellement.

Ce que la loi vous oblige à conserver

Les livres et registres comptables ainsi que les pièces justificatives, bons de commande, bons de livraison et factures, doivent être conservés dix ans à compter de la clôture de l'exercice, selon service-public.fr. Cette obligation ne disparaît pas parce que vous changez de logiciel. Elle vous suit.

Pour une comptabilité tenue de façon informatisée, l'administration attend en outre de pouvoir se voir remettre une copie du fichier des écritures comptables, dans un format normé décrit sur la page de l'administration fiscale consacrée aux fichiers standards des écritures comptables. La conséquence pratique est simple : avant d'arrêter l'ancien système, produisez et conservez les fichiers des écritures comptables de chaque exercice encore dans la période de conservation. C'est une opération de quelques heures tant que le système fonctionne. C'est un problème sérieux une fois qu'il est éteint.

Combien coûte une migration ERP, poste par poste ?

Le budget se répartit sur une dizaine de postes, du cadrage jusqu'à l'archivage de l'ancien système, et un chiffre unique ne dit rien de cette répartition. C'est elle qui indique où le projet peut déraper. Voici les postes réels, indépendamment du logiciel retenu.

Poste	Ce qu'il couvre	Ce qui le fait varier
Cadrage et conception	Ateliers métier, description des processus cibles, arbitrages de paramétrage	Nombre de métiers concernés, niveau de désaccord interne sur les processus
Paramétrage	Configuration standard du logiciel sur le périmètre retenu	Nombre de sociétés, de devises, de plans analytiques, de règles de TVA
Reprise de données	Extraction, transformation, import, contrôle, itérations	Qualité des données de départ, volume, nombre d'itérations nécessaires
Développements spécifiques	Ce que le standard ne couvre pas et que le métier exige vraiment	Écart entre les processus actuels et le standard du logiciel
Interfaces et connecteurs	Liaison avec la boutique en ligne, la banque, le logiciel de paie, l'expert-comptable	Existence d'un connecteur standard ou nécessité d'un développement
Recette	Jeux d'essai, cas métier rejoués, correction des anomalies	Poste le plus souvent raboté, et premier responsable des bascules ratées
Formation	Sessions par métier, supports, référents internes	Nombre d'utilisateurs, écart d'ergonomie avec l'ancien outil
Assistance après bascule	Les quatre à huit semaines pendant lesquelles tout remonte en même temps	Qualité de la recette et de la formation en amont
Archivage de l'ancien système	Extraction, stockage, accès de consultation	Option retenue, volume de documents, durée de conservation restante
Charge interne	Le temps de vos équipes, rarement compté et pourtant réel	Disponibilité effective du chef de projet interne

Sur le seul périmètre comptable, qui est le socle de toute migration, voici les fourchettes indicatives que nous constatons. Elles supposent un accompagnement complet, cadrage inclus, et varient selon la qualité des données de départ.

Périmètre	Fourchette indicative	Durée indicative
Comptabilité, plan simple, reprise limitée	3 000 à 7 000 €	2 à 3 semaines
Comptabilité, analytique multi-axes, banques multiples	7 000 à 15 000 €	4 à 6 semaines
Multi-sociétés, multi-devises, historique complet	15 000 € et plus	2 à 3 mois
Développement d'un connecteur sur mesure	2 000 à 15 000 €	2 à 8 semaines

Ces montants sont indicatifs et ne valent pas devis. Ils ne comprennent pas les licences du logiciel, qui relèvent de la grille tarifaire en vigueur chez l'éditeur : pour Odoo, elle est publiée sur odoo.com et évolue, il faut la consulter à la date du projet. Nous détaillons la structure d'un budget complet dans notre analyse du coût réel d'un projet Odoo, et le fonctionnement des liaisons dans notre guide de connexion entre Odoo et SAP.

Ce qui coûte, dans une migration, ce n'est pas le paramétrage : c'est la reprise et la recette. Sur les projets qui tiennent leur budget, ces deux postes sont dimensionnés au cadrage et défendus jusqu'au bout. Sur ceux qui dérapent, ils ont servi de variable d'ajustement pour tenir un prix d'appel.

Le calendrier réaliste, et les périodes où il ne faut pas basculer

Une migration de périmètre PME se compte en mois, pas en semaines, et la partie visible du projet est la plus courte. Voici un séquencement d'ordre de grandeur, à ajuster selon le périmètre et la disponibilité des équipes.

Phase	Ordre de grandeur	Mobilisation côté entreprise
Cadrage et conception	3 à 6 semaines	Forte : direction, responsables métier, comptabilité
Paramétrage et premiers imports	4 à 8 semaines	Modérée : réponses aux questions, arbitrages
Nettoyage des référentiels	En parallèle, 4 à 8 semaines	Forte, et c'est la phase la plus souvent sous-estimée
Recette	3 à 6 semaines	Très forte : les utilisateurs rejouent leurs cas réels
Formation	Quelques jours avant la bascule, jamais plusieurs semaines	Tous les utilisateurs concernés
Bascule	Un week-end ou une semaine creuse	Équipe restreinte, disponible en continu
Stabilisation	4 à 8 semaines	Forte au début, décroissante

Ces durées supposent un chef de projet interne réellement disponible. Si la personne désignée conserve 100 % de sa charge habituelle, allongez chaque phase, ou acceptez que la qualité baisse. Il n'y a pas de troisième option.

Deux lignes de ce tableau méritent une précision. La formation se cale au plus près du démarrage, quelques jours avant la bascule, le temps que les gestes soient encore frais le lundi matin. Et la stabilisation de 4 à 8 semaines désigne le pic d'incidents techniques et fonctionnels qui suit la bascule, quand tous les cas réels traversent le système pour la première fois. L'accompagnement au changement court plus longtemps, jusqu'à environ trois mois après le démarrage : deux notions distinctes, deux durées distinctes, que nous détaillons dans notre article sur la conduite du changement dans un projet ERP.

Les périodes à éviter absolument

Le choix de la date de bascule vaut plusieurs semaines de tranquillité, ou plusieurs mois de crise. Quatre périodes sont à écarter par principe.

• La clôture annuelle et les semaines qui l'entourent. La comptabilité ne peut pas piloter une bascule et produire un bilan simultanément. Une bascule au premier jour d'un exercice est confortable pour la reprise des à-nouveaux, mais elle ne doit pas coïncider avec la clôture du précédent.
• La haute saison de votre activité. Pour un distributeur, le dernier trimestre. Pour un acteur du bâtiment, le printemps. Pour une activité de rentrée, la fin de l'été. Basculer au pic revient à supprimer toute marge d'erreur au moment où elle est la plus nécessaire.
• Les périodes de congés. Basculer début août paraît malin parce que l'activité est calme. C'est aussi le moment où les référents métier sont absents et où l'intégrateur tourne en effectif réduit.
• La veille d'une échéance réglementaire. Avec l'entrée en vigueur de la réception obligatoire des factures électroniques au 1er septembre 2026, une bascule programmée fin août 2026 cumule deux chantiers sensibles sur la même semaine.

Les erreurs qui font déraper une migration

Reproduire à l'identique des processus cassés

C'est l'erreur la plus coûteuse, et elle se présente toujours comme une demande raisonnable : « on veut retrouver exactement ce qu'on avait ». Le résultat est un ERP neuf paramétré pour reproduire les contournements d'un outil qu'on venait de quitter, avec les développements spécifiques que cela suppose. Vous payez deux fois : pour le développement, puis pour la maintenance de ce développement à chaque montée de version.

La bonne question, à chaque processus, est celle-ci : est-ce que cette règle existe parce que le métier l'exige, ou parce que l'ancien logiciel ne savait pas faire autrement. Sur une migration de périmètre moyen, cette question fait disparaître une part significative des spécifiques demandés en début de projet. Chez Isolbox, l'industrialisation du débitage et le pilotage commercial tournent à 100 % sur Odoo, règles revues plutôt que recopiées.

Sous-estimer la recette

La recette n'est pas une démonstration où l'intégrateur montre que le système fonctionne. C'est un exercice où vos utilisateurs rejouent leurs propres cas, y compris les cas tordus : la commande avec remise exceptionnelle, l'avoir partiel, la livraison en trois fois, le client qui paie en devise. Ces cas ne sont jamais dans le jeu d'essai standard, et ce sont exactement eux qui bloquent le lundi de la bascule.

Une recette sérieuse demande des utilisateurs libérés de leur charge courante pendant plusieurs jours. Si personne ne peut se libérer, le projet n'est pas prêt. Tout se joue sur la disponibilité des équipes.

Traiter la formation comme une variable d'ajustement

La formation est le premier poste raboté quand le budget se tend, parce qu'elle paraît reportable. Elle ne l'est pas. Un utilisateur non formé produit des données fausses dès la première semaine, et ces données fausses coûtent plus cher à corriger que la session de formation économisée. Le sujet dépasse d'ailleurs la formation aux écrans : c'est un travail de conduite du changement, que nous détaillons dans notre article sur la conduite du changement dans un projet ERP.

Garder l'ancien système « au cas où », indéfiniment

Laisser l'ancien ERP accessible en écriture après la bascule paraît prudent. C'est le contraire. Tant qu'il reste ouvert, une partie des équipes continue d'y travailler, les deux bases divergent, et personne ne sait plus laquelle fait foi. Une date d'arrêt en écriture doit être fixée au cadrage et tenue. L'accès en lecture, lui, se justifie le temps de l'archivage, ce qui est un sujet différent.

Dans quels cas vaut-il mieux ne pas migrer ?

Quatre cas de figure justifient de repousser le projet, ou de ne pas le lancer : un système actuel qui répond encore au besoin, une période de forte activité ou de transformation, l'absence de chef de projet interne disponible, et un référentiel trop dégradé pour que le gain couvre la remise en état. Un intégrateur qui répond « oui, migrons » à toutes les situations vous vend son carnet de commandes.

Le système actuel répond encore au besoin. Un ERP daté, mais maintenu par son éditeur, qui produit les documents attendus et que les équipes maîtrisent, n'est pas un problème. L'ancienneté n'est pas un motif. Le vrai signal, c'est le nombre de choses que vous faites en dehors de l'outil, et le coût cumulé de ces contournements. Tant que ce coût reste inférieur à celui du remplacement amorti, garder l'existant est la décision rationnelle.

Vous êtes en période de forte activité ou de transformation. Un déménagement d'entrepôt, un changement de direction, une levée de fonds en cours, une réorganisation commerciale : ajouter une migration ERP à cette liste revient à garantir que l'un des chantiers sera mal fait. Attendre six mois coûte moins cher qu'un projet mené sans arbitre disponible.

Aucun chef de projet interne n'est disponible. C'est le critère le plus discriminant, et il n'a rien à voir avec la taille de l'entreprise. Il faut une personne qui connaît les processus, qui a l'autorité pour trancher entre deux services, et qui dispose réellement de temps. Sans elle, l'intégrateur prend des décisions métier à votre place, par défaut, et vous les constatez à la recette. Nous préférons décaler un démarrage plutôt que lancer un projet dans cette configuration.

L'état des données rend le projet plus cher que le gain attendu. Il existe des situations où le coût de remise en état du référentiel dépasse ce que la migration fera gagner sur trois ans. Dans ce cas, la bonne séquence consiste à mener d'abord un chantier de qualité des données sur le système existant, pendant six à douze mois, puis à migrer avec un point de départ propre. C'est plus long. C'est nettement moins cher.

Il y a aussi les cas où le bon choix est un autre outil que celui que nous intégrons. Une entreprise dont le métier repose sur une fonction très spécialisée, déjà couverte par un logiciel sectoriel mature, a souvent intérêt à conserver ce logiciel et à ne migrer que la gestion transverse, en connectant les deux. La vraie question porte sur le périmètre à migrer. Notre lexique décrit ce que recouvre concrètement un déploiement Odoo, et notre page dédiée à l'intégration Odoo précise notre façon de travailler si vous souhaitez comparer.

Questions fréquentes

Comment faire la migration des données ?

La séquence qui fonctionne comporte cinq temps : cartographier ce qui existe, décider du périmètre repris, nettoyer les référentiels avec les responsables métier, importer par lots avec des identifiants externes stables, puis contrôler par échantillonnage et par totaux. Le contrôle final se fait sur des indicateurs vérifiables, comme le total de la balance, le nombre de comptes actifs ou la valeur du stock, comparés entre l'ancien et le nouveau système avant de valider la bascule.

Comment changer d'ERP sans arrêter l'activité ?

En choisissant une fenêtre de bascule sur une période creuse, en ayant rejoué les cas métier réels en recette, et en prévoyant une assistance renforcée pendant les quatre à huit premières semaines. L'arrêt d'activité redouté vient presque toujours d'une recette insuffisante, pas de la bascule elle-même : les anomalies bloquantes existaient avant, elles n'avaient simplement pas été cherchées.

Quelle est la signification de ERP ?

ERP signifie Enterprise Resource Planning, traduit en français par progiciel de gestion intégré. C'est un logiciel unique dans lequel les ventes, les achats, les stocks, la production et la comptabilité partagent la même base de données, ce qui évite les ressaisies entre outils séparés.

Quels sont les 3 types de changement à gérer dans un projet ERP ?

Le changement d'outil, qui se règle par la formation. Le changement de processus, qui se règle par des arbitrages assumés en amont. Et le changement de rôle, qui est le plus délicat : une personne dont le poste consistait à consolider des fichiers voit sa mission se déplacer quand l'ERP produit la consolidation. Ce troisième niveau demande une discussion individuelle, pas une réunion de service.

Quel est l'ERP le plus utilisé en France ?

Le marché français est fragmenté entre des acteurs internationaux, des éditeurs nationaux historiques et des solutions open source, et les classements disponibles varient selon la méthode et le segment observé. La question utile n'est pas celle de la part de marché mais celle de l'adéquation à votre métier, à votre taille et à votre capacité à faire évoluer l'outil.

Quel est le meilleur ERP gratuit ?

Plusieurs ERP open source sont disponibles sans coût de licence, ce qui ne signifie pas sans coût total : l'hébergement, le paramétrage, la reprise de données et la maintenance restent à financer. Nous détaillons ce que recouvre exactement la gratuité dans notre article sur Odoo gratuit, Community et Enterprise.

Faut-il migrer avant l'échéance de la facturation électronique ?

Pas nécessairement. Si votre système actuel peut être raccordé à une plateforme agréée et produire les formats structurés attendus, l'échéance du 1er septembre 2026 ne justifie pas à elle seule un changement d'ERP. Elle justifie en revanche de poser la question à votre éditeur dès maintenant, par écrit, et de ne pas se satisfaire d'une réponse orale rassurante.

En résumé

Une migration ERP réussie se décide avant le choix du logiciel. Elle se joue sur trois arbitrages : le périmètre de données réellement repris, la stratégie de bascule adaptée à votre organisation, et la disponibilité effective d'un chef de projet interne. Le paramétrage, qui occupe l'essentiel des discussions commerciales, est rarement ce qui fait la différence entre un projet tenu et un projet qui s'enlise.

Les fourchettes de budget données ici sont indicatives et supposent un périmètre décrit. Le poste qui les fait varier le plus reste l'état du référentiel de départ, et il se mesure en une journée d'analyse. Si vous envisagez une bascule dans les douze prochains mois, commencez par là, avant même de comparer des solutions. Une fois ce chiffre posé, la discussion devient tout de suite concrète : écrivez-nous pour en parler sur un cas concret. Les enjeux comptables d'une reprise méritent souvent une discussion à part entière.