Sept stratégies qui dérisquent une sortie d'ERP hérité
Quitter Sage ou NetSuite est rarement une décision logicielle — c'est une décision CFO déguisée en décision IT. Les renouvellements grimpent, les personnalisations vieillissent en passifs, et la réunion du conseil du deuxième trimestre commence à demander pourquoi l'ERP est le deuxième poste SaaS. Les sept stratégies ci-dessous sont celles que nous appliquons sur chaque migration Sage ou NetSuite vers Odoo pour tenir le calendrier, fixer le budget et laisser l'équipe d'exploitation dormir. N'en sautez aucune.
Octura livre cela en migrations ERP à prix fixe, avec des ingénieurs seniors sur chaque projet — pas de consultants juniors facturés au tarif senior.
Le cadre en six phases avec fenêtre de lecture seule de 90 jours
Toutes les migrations réussies que nous avons livrées suivent les mêmes six phases : découverte → cartographie → configuration → migration des données → run parallèle → bascule. La règle non négociable qui protège le projet est la fenêtre de lecture seule de 90 jours maintenue après la bascule. Sage ou NetSuite reste accessible pour les consultations historiques, les réponses d'audit et la réémission de factures inévitable. L'exploitation n'écrit que dans Odoo dès le jour 1 ; le système hérité ne répond qu'aux questions. Sans cette fenêtre, la finance refuse de signer. Avec elle, le périmètre cesse de glisser vers « reconstruire tous les rapports hérités avant la mise en production ». Structure de mise en scène dans comment planifier une migration ERP.
Jamais de big-bang sur un déploiement multi-entités
Pour une entreprise mono-entité et mono-pays, une bascule big-bang est défendable. Pour tout le reste — multi-pays, multi-devises, inter-sociétés — c'est la cause la plus fréquente de retard d'un trimestre. Phasez par entité ou par module. Séquencez d'abord la plus petite entité la moins risquée (souvent une holding non opérationnelle ou une petite filiale), prouvez la configuration, puis dupliquez le même gabarit sur les entités opérationnelles. Ou phasez par module : finance et achats d'abord, ventes et stock ensuite, fabrication en dernier. La première entité enseigne au partenaire où sont les écarts de personnalisation avant qu'ils n'atteignent une filiale génératrice de revenus.
Décider délibérément ce qu'on reconstruit et ce qu'on abandonne
La cause la plus fréquente de dépassement sur une migration Sage ou NetSuite est l'hypothèse que chaque personnalisation héritée doit être reconstruite. C'est faux. Le premier livrable de la découverte est un inventaire des personnalisations avec trois colonnes : reconstruire (vrai besoin opérationnel), abandonner (utilisé une fois par an par une seule personne, ou contournement d'une limite héritée qu'Odoo couvre nativement), et différer (post-mise en production, phase 2). Sur une migration NetSuite typique, nous abandonnons 30–50 % des champs personnalisés et 60–80 % des recherches enregistrées parce que l'équivalent Odoo est standard. C'est cette liste d'« abandons » délibérés qui sauve le budget.
Verrou de nettoyage des données AVANT migration, pas après
Données sales en entrée, données sales en production. Trois jeux de données doivent passer un verrou de nettoyage avant d'entrer dans le pipeline : plan comptable (consolidé, mappé, sans compte orphelin d'une acquisition de 2018), base clients (dédupliquée — le même client n'apparaît plus comme ACME, ACME Inc. et ACME Corporation), et fichier articles (pas de SKU obsolètes, pas de doublons de références, pas d'UoM incohérentes). Le verrou est une signature, pas une recommandation. Sans lui, chaque rapprochement en run parallèle accuse les données et non la configuration, et le projet perd deux semaines en comptabilité légale. Checklist de nettoyage dans migrer de NetSuite vers Odoo.
Protocole de run parallèle — deux semaines minimum, rapprochement quotidien
Le run parallèle est l'endroit où la finance gagne en confiance et où la plupart des projets ERP tiennent ou s'effondrent. Le protocole qui fonctionne : deux semaines minimum, les deux systèmes en production, chaque transaction passée dans les deux, rapprochement quotidien (pas hebdomadaire) par un comptable nommé. Chaque jour produit un rapport de tolérance — les écarts sous seuil sont notés, les écarts au-dessus du seuil arrêtent le run jusqu'à analyse de cause racine. Les déclencheurs de repli sont écrits avant le début du run parallèle : plus de trois jours d'écart de tolérance non résolu, plus de 1 % d'écart GL cumulé, ou toute violation de frontière de période fiscale. Un chemin de repli documenté est ce qui permet au CFO d'autoriser la bascule ; sans lui, la réponse est « encore une semaine de run parallèle, s'il vous plaît ».
Prix fixe au départ — pas de régie
Le plus gros risque caché d'une migration héritée n'est pas la technologie — c'est le modèle commercial. La régie est un aspirateur à budget sur les sorties Sage ou NetSuite parce qu'aucune incitation ne pousse le partenaire à comprimer le périmètre, à abandonner les personnalisations inutiles ou à terminer la découverte efficacement. Exigez un prix fixe après une découverte payante. Le livrable de découverte est un cahier des charges écrit nommant les modules, les objets de données, les personnalisations et les critères d'acceptation. Les avenants existent — mais ils s'appuient sur une base de référence, pas sur un chèque en blanc. Nous livrons chaque migration Sage et NetSuite en migrations Odoo à prix fixe pour exactement cette raison.
Hyper-care après mise en production — ingénieur nommé, pas file de tickets
Les trente premiers jours après la bascule décident si le projet est mémorisé comme un succès ou comme une histoire de guerre. De J1 à J30, c'est l'hyper-care : un ingénieur senior nommé d'astreinte pour l'équipe projet, pas une file de tickets support partagée et pas un SLA de help-desk. L'ingénieur nommé a participé à la découverte, configuré les modules et piloté les rapprochements en run parallèle ; il sait à quoi doit ressembler chaque transaction et peut trier les anomalies en minutes. Après trente jours, le projet passe au support standard. Avant trente jours, tout ce qui n'est pas une ligne directe avec l'équipe de build ajoute des jours à chaque incident.
Comment évaluer un partenaire Odoo sans se faire avoir
Les fonctionnalités comptent ; le partenaire qui les livre compte davantage. Huit vérifications séparent les partenaires qui livrent de ceux qui apprennent sur votre budget :
- Certification Odoo officielle (Ready, Silver ou Gold) — pas seulement « nous travaillons avec Odoo ».
- La personne de la découverte est celle qui construit. Les passages de relais perdent le périmètre.
- Prix fixe après découverte. La régie est un aspirateur à budget en ERP.
- Ingénieurs seniors sur le projet. Octura ne livre qu'avec des seniors — demandez à tout partenaire potentiel qui écrit votre code.
- Deux clients de référence prêts à un appel. « Beaucoup de clients » sans nom est un signal d'alerte.
- Spécialité verticale en fabrication. Un généraliste qui livre une usine par trimestre n'est pas le partenaire.
- Méthodologie documentée multi-phases. Découverte → configuration → personnalisation → migration → mise en production → hyper-care.
- Tarifs publiés en toute transparence. « Devis sur mesure » est acceptable ; refuser un chiffre de départ ne l'est pas.
La version longue est dans l'audit partenaire Odoo.