Le vrai risque d’un changement d’ERP n’est pas le week-end de bascule. C’est le lundi matin, quand une commande urgente arrive, qu’un stock doit être corrigé ou qu’une facture doit partir. Un guide de migration ERP sans interruption doit donc traiter la continuité opérationnelle avant la technologie. Pour une PME, quelques jours de désorganisation peuvent suffire à retarder les encaissements, créer des erreurs de livraison et entamer la confiance des équipes.

Migrer vers un nouvel ERP, notamment Odoo, peut simplifier durablement l’entreprise. Mais le projet ne se résume pas à importer des fichiers Excel et à former quelques utilisateurs. Il faut décider ce qui doit être repris, ce qui doit être corrigé et ce qui doit disparaître. La différence entre une migration maîtrisée et une migration subie se joue dans ces décisions, prises assez tôt et par les bonnes personnes.

Commencer par protéger les opérations critiques

Avant de parler de données ou de paramétrage, identifiez les opérations qui ne peuvent pas s’arrêter. Elles diffèrent selon le modèle de l’entreprise. Pour un distributeur, il peut s’agir de la prise de commande, de la préparation, de l’expédition et de la facturation. Pour un fabricant, la planification, la disponibilité matière et la traçabilité peuvent primer. Pour une société de services, le temps presté, les contrats et la facturation récurrente seront souvent au centre.

L’objectif n’est pas de reproduire chaque habitude dans le futur ERP. C’est une erreur fréquente et coûteuse. Il s’agit de définir le niveau de service minimal à maintenir pendant la transition, puis d’organiser le projet autour de ce socle. Une commande peut-elle être saisie temporairement dans un outil contrôlé ? Qui valide les expéditions si une donnée manque ? Comment traiter les paiements ou avoirs en cours ? Ces questions doivent recevoir des réponses concrètes, écrites et testées.

Cette étape met parfois en évidence une dépendance excessive à une personne ou à un fichier local. C’est utile. Une migration n’est pas seulement un changement de logiciel : c’est l’occasion de rendre l’activité moins fragile.

Construire un périmètre réaliste pour la migration ERP

Le périmètre d’un ERP grandit vite si personne ne le tient. Chaque département a une exception légitime, chaque ancien rapport semble indispensable et chaque intégration paraît urgente. Pourtant, vouloir tout reprendre au premier lancement est souvent le moyen le plus sûr de retarder le projet ou de fragiliser la bascule.

Séparez clairement trois catégories : ce qui est indispensable au démarrage, ce qui peut suivre dans une phase courte après lancement, et ce qui doit être abandonné. Cette dernière catégorie mérite une attention particulière. Des références articles inactives, des clients doublonnés, des listes de prix obsolètes ou des processus de validation sans valeur opérationnelle ne doivent pas être transportés par défaut.

Le bon périmètre dépend de la capacité de l’entreprise à absorber le changement. Une PME avec une saison haute proche aura intérêt à limiter le premier lot aux fonctions essentielles. Une entreprise qui remplace plusieurs outils instables peut, au contraire, avoir intérêt à regrouper certaines fonctions pour éviter une double saisie prolongée. Il n’existe pas de règle universelle. Il existe un arbitrage entre ambition, risque et calendrier commercial.

Décider ce qui doit être migré

Toutes les données n’ont pas le même rôle. Les données de référence - clients, fournisseurs, produits, unités de mesure, tarifs, conditions de paiement - doivent être propres et cohérentes. Les soldes comptables, les factures ouvertes, les stocks et les commandes en cours exigent une méthode de reprise précise, car ils ont un effet direct sur l’activité et la comptabilité.

L’historique complet est différent. Reprendre dix ans de documents dans le nouvel ERP peut rassurer, mais représente souvent beaucoup de travail pour une utilisation limitée. Dans de nombreux cas, conserver l’ancien système en lecture seule ou archiver les documents de façon structurée est plus raisonnable. La bonne question n’est pas « pouvons-nous migrer cette donnée ? », mais « quelle décision opérationnelle ou légale exige sa présence dans le nouvel ERP ? ».

Préparer des données fiables avant la bascule

Une migration ne corrige pas automatiquement les données. Elle rend surtout leurs défauts plus visibles. Si les articles ont des codes incohérents, si les fiches clients sont incomplètes ou si les règles de TVA sont mal appliquées, le problème sera transféré dans un environnement plus intégré - donc avec des conséquences plus rapides.

La préparation doit être confiée à des responsables métier, pas uniquement à l’équipe informatique ou au partenaire ERP. La finance valide les comptes, taxes et soldes. Les opérations valident les articles, entrepôts et règles logistiques. Le commerce valide les comptes clients, conditions tarifaires et opportunités actives. Le prestataire structure les fichiers, contrôle les formats et exécute les imports, mais il ne peut pas deviner quelle donnée est fiable.

Prévoyez au moins une migration à blanc complète. Elle permet de mesurer les temps d’import, de repérer les valeurs impossibles, de contrôler les totaux et de tester les droits utilisateurs. Une seconde répétition est souvent justifiée lorsque les flux sont complexes, par exemple avec plusieurs entrepôts, des numéros de lot, de la fabrication ou des interfaces e-commerce.

Tester les scénarios, pas seulement les écrans

Un ERP peut sembler correct lors d’une démonstration et échouer dans les cas qui comptent réellement. Le test utile suit un scénario de bout en bout : un devis devient une commande, la commande réserve du stock, déclenche un achat ou une fabrication, est livrée, facturée et encaissée. Les exceptions doivent être testées avec le même sérieux : retour client, rupture de stock, remise exceptionnelle, paiement partiel, correction comptable ou annulation.

Les utilisateurs clés doivent participer à ces tests. Ce ne sont pas des figurants mobilisés à la fin du projet. Ils connaissent les cas réels, les contournements existants et les conséquences d’une erreur. Leur implication évite aussi un écart classique : un système techniquement fonctionnel, mais rejeté parce qu’il ne correspond pas au travail quotidien.

Conservez une liste de scénarios avec un résultat attendu, un responsable de validation et un statut. Cela apporte une discipline simple : un point n’est pas validé parce qu’il « semble fonctionner », mais parce que le processus a été exécuté et contrôlé.

Organiser la bascule sans arrêter l’entreprise

La bascule doit être préparée comme une opération métier avec un plan horaire, des responsables nommés et des critères de décision. Précisez à quel moment les saisies cessent dans l’ancien système, quand les données finales sont extraites, qui réalise les contrôles, et à quel instant le nouvel ERP devient la source de vérité.

Le fonctionnement en double système peut réduire le risque sur une période très courte, mais il crée aussi des écarts. Il faut donc l’encadrer strictement. Si des commandes continuent d’être saisies dans l’ancien outil pendant les tests finaux, une personne doit être responsable de leur reprise et de leur rapprochement. Sans cette règle, l’entreprise se retrouve avec deux vérités et aucune visibilité fiable.

Préparez aussi un plan de repli. Il ne signifie pas que vous anticipez l’échec. Il définit ce qui se passe si un contrôle critique échoue : qui décide de reporter, quelles opérations peuvent continuer manuellement, comment informer les équipes et comment éviter la perte de données. Un plan de repli crédible réduit la pression et favorise de meilleures décisions le jour J.

Les contrôles à valider le jour du lancement

Avant d’annoncer la mise en production, contrôlez au minimum les éléments qui ont un impact immédiat sur le chiffre d’affaires, les livraisons et la trésorerie : accès utilisateurs, clients et articles, stocks ou disponibilités, commandes ouvertes, règles de prix et de taxe, ainsi que les journaux et soldes comptables concernés.

Ne cherchez pas une perfection abstraite. Cherchez la preuve que l’entreprise peut vendre, acheter, livrer, produire si nécessaire et facturer correctement. Les améliorations de confort, les tableaux de bord secondaires ou les automatisations non critiques peuvent être planifiés après la stabilisation.

Prévoir un soutien renforcé après le démarrage

Les deux premières semaines révèlent les écarts entre le processus conçu et la réalité. C’est normal. Ce qui compte est la vitesse de traitement et la qualité du tri. Certaines demandes relèvent d’un incident à corriger immédiatement. D’autres sont des demandes d’évolution utiles, mais qui ne doivent pas perturber la stabilité du système.

Organisez un point quotidien court avec les responsables métier et le partenaire de mise en œuvre. Suivez les incidents, leur priorité, leur propriétaire et leur date de résolution. Mesurez aussi des indicateurs simples : commandes traitées, livraisons bloquées, factures émises, écarts de stock et temps de réponse. Ce suivi montre rapidement si l’activité est réellement sécurisée ou si les équipes compensent silencieusement les défauts du système.

Chez Agitech, l’approche consiste à traiter la migration comme un projet de performance opérationnelle, pas comme un simple transfert technique. Cela implique parfois de recommander une phase supplémentaire ou de refuser une reprise de données sans valeur. Cette franchise protège le budget, le calendrier et surtout la capacité de l’entreprise à continuer à travailler.

Un ERP réussi ne se juge pas au nombre de modules activés le jour du lancement. Il se juge quand les équipes retrouvent leurs repères, que les décisions reposent sur des chiffres fiables et que l’entreprise peut absorber sa prochaine étape de croissance sans recréer des fichiers parallèles.