Beaucoup de DSI pensent aborder un projet IT quand ils signent un upgrade majeur. Ils abordent en réalité un projet métier, déguisé en budget de maintenance. L’éditeur présente la nouvelle version comme une continuité, l’intégrateur évoque un coût « très inférieur à un projet neuf », et le CFO arbitre sur la base d’un chiffrage qui s’avèrera incomplet dès que les premiers tests de régression tomberont.
Cet article traite le sujet avec franc-parler. Il explique pourquoi passer de SAP ECC à S/4HANA, de Sage 200 à Sage X3 ou d’Odoo v13 à v17 n’est pas une simple mise à jour. Il chiffre les postes que la plupart des devis ignorent, pose une méthodologie en sept étapes, et aide à trancher la question qui revient toujours : upgrade ou re-implémentation.
Pourquoi on parle d’upgrade majeur, pas de mise à jour
Mises à jour mineures versus upgrades majeurs
Une mise à jour mineure corrige des bugs, apporte des améliorations ergonomiques et applique des patchs de sécurité. Le paramétrage reste intact, les spécifiques tournent, les utilisateurs ne voient presque rien. C’est un exercice récurrent, parfois automatisé, qui ne mobilise ni la direction métier ni le budget d’investissement.
Un upgrade majeur change la donne. Il porte le système d’une version N à une version N+1 (ou plus), avec des ruptures de compatibilité sur le modèle de données, les interfaces, voire l’architecture sous-jacente. Passer de SAP ECC à S/4HANA implique un changement de base de données (HANA remplace Oracle, DB2 ou SQL Server), une refonte du modèle financier (la table ACDOCA remplace BSEG et BKPF côté finance), et une nouvelle couche d’interface utilisateur (Fiori).
Le passage d’Odoo v13 à v17 change l’ORM, déprécie des API, réorganise la logique de facturation, transforme des champs en d’autres. Un module custom écrit en 2020 ne tourne pas tel quel en 2026.
Passer de Sage 200 à Sage X3 n’est même pas un upgrade : Sage l’a classé comme une nouvelle implémentation, les deux produits étant des plateformes distinctes (Mysoft).
Les trois scénarios qui déclenchent un upgrade majeur
Fin de support éditeur. C’est le déclencheur le plus dur à négocier : il a une date. La mainstream maintenance de SAP ECC 6.0 s’arrête le 31 décembre 2027, avec une extended maintenance payante disponible jusqu’à fin 2030 pour les clients EHP 6 à 8 (Rimini Street). Les Compatibility Packs de SAP S/4HANA on-premise ont été prolongés une dernière fois jusqu’au 31 mai 2026 (SAP News). Les clients RISE with SAP ou S/4HANA Cloud Private Edition conservent l’usage jusqu’au 31 décembre 2030.
Changement de stack technique. L’éditeur réécrit son socle, et la version précédente cesse d’être industriellement maintenable. SAP HANA en est l’exemple canonique : la base in-memory impose une refonte des performances et des états de restitution pour les clients venant d’ECC. Même logique chez Odoo quand l’éditeur refactore des modules cœur : v17 a modernisé la gestion des écritures comptables et du module achats par rapport à v13, au prix d’une migration de données non triviale.
Refonte UX ou architecturale. SAP Fiori, Salesforce Lightning, Dynamics Unified Interface : l’éditeur pousse une expérience utilisateur qui rend les écrans classiques obsolètes. L’upgrade devient alors un projet de conduite du changement : les utilisateurs réclament une formation, les responsables métier doivent revoir leurs procédures, le support interne explose pendant trois mois.
Le cas particulier : upgrade qui vire à la re-implémentation
Dans les faits, un upgrade majeur avec plus de 40 % de customisations par rapport au standard finit presque systématiquement en re-implémentation déguisée. Les équipes démarrent en conversion, constatent que les Z-tables SAP ou les modules Python custom ne passent pas, et basculent en mode refonte au bout de quelques mois. Le budget initial est alors dépassé d’un facteur deux ou trois, et le projet devient politiquement difficile à arrêter.
Les coûts cachés que personne ne budgétise
Un upgrade « officiel » est chiffré sur trois postes visibles : licences complémentaires, prestations de conversion, formation. Ces trois postes représentent typiquement 30 à 40 % du coût réel. Les 60 % restants sortent en cours de route.
Les customisations à refaire ou reprendre
Chaque spécifique est un candidat à la casse. Les Z-tables SAP écrites sur BSEG doivent être réécrites pour pointer sur ACDOCA. Les modules Odoo custom doivent suivre le cycle de refactor v14, v15, v16, v17, le service d’upgrade officiel d’Odoo ne reprend que les apps Odoo core, pas les modules tiers ou custom (Odoo documentation). Chaque version intermédiaire doit être testée, validée, documentée.
Impact typique : 30 à 45 % du coût total de l’upgrade, en fonction du volume de spécifiques et de l’âge du paramétrage.
Les intégrations qui cassent
Un ERP en production n’est jamais seul. Il parle à un CRM, à un WMS, à un portail fournisseurs, à un e-commerce, à un outil de paie, à un EDI. Chaque interface repose sur un contrat d’API ou un format de fichier. Un upgrade majeur rebat les cartes : les endpoints changent, les schémas évoluent, les webhooks ne déclenchent plus au même moment.
Recenser ces interfaces dès le début du projet est un exercice fastidieux que les équipes IT sous-estiment. Pour une ETI moyenne, compter 20 à 60 points d’intégration actifs à re-certifier. Chacun mobilise une équipe qui n’est souvent pas celle qui pilote l’upgrade.
La reprise de données quand le modèle change
Le passage de SAP ECC à S/4HANA change le modèle financier en profondeur. Les écritures comptables ne vivent plus dans BSEG et BKPF mais dans ACDOCA, avec un historique à reconstituer si l’on veut comparer les exercices. Les états figés par les contrôleurs de gestion depuis dix ans ne passent plus tels quels. Le mapping des comptes, des centres de coûts et des segments exige des semaines d’atelier avec le contrôle de gestion.
Côté Odoo, certaines montées de version ont refondu des modèles de champs : un champ monovalué en v13 devient une relation Many2many en v17. Une extraction brute ne suffit pas, il faut retraiter.
La formation utilisateurs et la résistance au changement
L’upgrade change l’ergonomie. Fiori n’est pas SAP GUI. L’interface Odoo v17 n’est pas celle de v13. Les habitudes de saisie, les raccourcis, les enchaînements d’écrans sont modifiés. Un utilisateur expert qui faisait son quotidien en 45 minutes va repasser à 2 heures pendant les premières semaines. C’est là que se jouent les grèves informelles : le commercial qui renvoie ses devis en Excel, la compta qui double la saisie dans un tableau de bord parallèle.
Budgétiser 3 à 5 jours de formation par utilisateur clé, plus un support rapproché sur 90 jours post-bascule. Souvent oublié dans le devis initial.
La régression de KPI métier pendant 3 à 6 mois
Un CFO mesure la performance d’une bascule ERP à une chose : le délai de clôture mensuelle. Un upgrade bien mené fait perdre 3 à 8 jours de clôture pendant le premier trimestre. Un upgrade mal préparé peut paralyser la clôture pendant un semestre. Ce coût n’apparaît pas dans un devis, mais il mobilise les équipes finance, alimente les rapports au comité exécutif, et justifie à lui seul un investissement sérieux dans la phase de tests.
Les trois grands scénarios d’upgrade
SAP ECC vers S/4HANA : brownfield, greenfield ou bluefield
SAP propose trois approches de transition, chacune avec des trade-offs très différents (SAP Community).
Brownfield (system conversion). L’approche la plus rapide : on convertit le système existant vers S/4HANA en conservant la configuration, les données historiques et les spécifiques compatibles. Convient aux clients avec peu de customisations et un paramétrage récent. Durée typique : 9 à 18 mois pour une ETI.
Greenfield (nouvelle implémentation). On repart de zéro avec le standard S/4HANA, on redessine les processus, on migre uniquement les données stratégiques. Convient aux organisations dont les processus de 2015 ne sont plus alignés avec la réalité 2026. Durée typique : 18 à 30 mois, coût le plus élevé à horizon court mais la meilleure trajectoire à 10 ans.
Bluefield (Selective Data Transition). L’approche hybride : on démarre un S/4HANA neuf, puis on migre sélectivement ce qui doit l’être (historiques, configurations, spécifiques). Approche officialisée par SAP en 2020 via le programme Selective Data Transition Engagement (SAP Support). Pertinente pour les groupes multi-sociétés qui veulent nettoyer leur paramétrage sans perdre leurs données.
L’outil officiel pour arbitrer est le SAP Readiness Check, complété par Fiori App Recommendations et le programme SAP Signavio pour l’analyse des processus. Ces outils ne remplacent pas un audit fit-gap, mais ils donnent une cartographie objective du delta entre l’existant et le standard.
Le contexte marché confirme la pression. Selon le DSAG Investitionsreport 2025 (association des utilisateurs SAP allemands, autrichiens et suisses), 51 % des répondants utilisent encore SAP Business Suite, contre 42 % déjà sur S/4HANA On-Premises, 33 % sur Private Cloud et 13 % sur Public Cloud. Surtout, 68 % envisagent d’investir dans S/4HANA Cloud dans les mois qui viennent, le mouvement s’accélère, mais une part significative des clients planifie encore la bascule pour fin 2030. La fenêtre est courte.
Sage 200 vers Sage X3 : rupture plus que migration
Les clients Sage 200 qui projettent une montée en puissance fonctionnelle (multi-sociétés, multi-devises, MES industriel) ne montent pas en version. Ils changent de produit. Sage 200 et Sage X3 sont deux plateformes distinctes (Mysoft) ; la transition est classée par Sage et ses partenaires comme une nouvelle implémentation, pas comme un upgrade.
Deux conséquences pratiques. Premièrement, les données ne se récupèrent pas automatiquement : un projet de migration de référentiels, d’historiques et d’encours doit être cadré. Deuxièmement, les spécifiques Sage 200 (macros, états Crystal, scripts) ne se portent pas, tout est à refaire.
Pour les clients qui restent sur Sage 200 et veulent monter en version R2, l’opération est plus légère, mais reste sensible aux développements custom et aux modules tiers. Le module Sage 200 Manufacturing n’est plus supporté depuis le 31 décembre 2025 (Mysoft), ce qui pousse mécaniquement une partie du parc vers X3 ou vers une alternative du marché.
Odoo v13-v16 vers Odoo v17
Odoo publie une version majeure par an. Odoo Online force la montée de version sous 2 ans ; Odoo Enterprise self-hosted donne plus de latitude mais pas indéfiniment. Le service officiel d’upgrade d’Odoo passe par le portail upgrade.odoo.com et traite une version à la fois : pour passer de v13 à v17, la base est d’abord montée en v14, puis v15, puis v16, puis v17.
Deux conséquences. Premièrement, chaque version intermédiaire est un test d’intégration complet. Deuxièmement, le service d’upgrade ne couvre que les applications Odoo core, les modules custom et les apps tierces (OCA, partenaires) restent à la charge du client ou de son intégrateur. Les modules custom sont marqués comme « to upgrade » dans la base résultante, à charge de les réécrire avant le go-live.
Pour les bases communautaires, OpenUpgrade (projet OCA) offre une alternative mais son périmètre est plus limité. Pour un client Enterprise avec 30 modules custom développés depuis 2018, un upgrade v13 vers v17 est clairement un projet d’intégration, pas une simple mise à jour technique.
Méthodologie : les 7 étapes pour ne pas se planter
Étape 1, Audit fit-gap avec la nouvelle version
Inventaire exhaustif des fonctionnalités utilisées, confrontées au standard de la cible. L’écart (gap) est la feuille de route de l’upgrade. Outils natifs SAP Readiness Check côté S/4HANA, analyse modulaire du code custom côté Odoo, revue manuelle côté Sage.
Étape 2, Inventaire des customisations
Combien de lignes de code spécifique ? Combien de tables custom ? Quels modules modifient le comportement standard ? Les éditeurs fournissent des outils d’analyse, SAP Custom Code Migration Worklist, Odoo l10n-community pour les modules OCA. L’objectif est de classer chaque spécifique en trois catégories : à garder en l’état, à refondre au standard, à abandonner.
Étape 3, POC en sandbox sur un périmètre réduit
Avant de commiter un budget à sept chiffres, monter un environnement cible avec 10 à 20 % du périmètre et faire tourner trois ou quatre processus métier critiques. La clôture comptable mensuelle, un cycle de vente, une prise de commande fournisseur. Cet exercice révèle 80 % des risques techniques en 6 à 10 semaines.
Étape 4, Stratégie de reprise de données
Décider quoi reprendre, à quelle profondeur, sous quelle forme. Les clients sous-estiment systématiquement le temps de nettoyage : dédoublonnage de tiers, cohérence de plan comptable, normalisation des référentiels articles. Prévoir 2 à 4 analystes métier dédiés pendant 3 à 6 mois.
Étape 5, Reconstruction ou migration des spécifiques critiques
Les spécifiques à garder sont réécrits ou recompilés dans la cible. Les spécifiques abandonnés sont documentés (audit trail pour la conformité). Les nouveaux spécifiques éventuels, imposés par la cible, sont cadrés, chiffrés, planifiés.
Étape 6, Tests de régression et UAT utilisateurs
Phase la plus sous-budgétée, systématiquement. Pour un upgrade SAP ou Sage X3, prévoir un cycle de tests de 8 à 16 semaines couvrant les processus de bout en bout, avec les utilisateurs métier pilotes. Ne pas sous-traiter cette phase intégralement : l’intégrateur n’a pas le recul métier pour valider un compte de résultat ou un état de stocks.
Étape 7, Go-live (big bang ou phased)
Arbitrage classique entre bascule en un week-end (big bang, court mais risqué) et bascule par sites ou modules (phased, plus long mais plus sûr). Pour un groupe multi-sites avec des fuseaux horaires différents, la bascule phased par site réduit le risque. Pour un mono-site avec des dépendances inter-modules fortes, le big bang reste souvent la seule option propre. Dans les deux cas, un plan de rollback documenté est non négociable, sinon, on dépend de la chance.
Upgrade ou re-implémentation : 4 critères d’arbitrage
| Critère | Upgrade possible | Re-implémenter |
|---|---|---|
| Ratio customisation | < 20 % du code standard | > 40 % |
| Âge du paramétrage | < 5 ans | > 8 ans |
| Alignement métier | Processus 2020+ toujours pertinents | Processus obsolètes ou contestés |
| Trajectoire éditeur | Modules cibles encore supportés en vN+1 | Modules supprimés ou refactorés en profondeur |
Un seul critère en zone rouge ne condamne pas un upgrade. Deux ou plus imposent l’ouverture du débat : continuer en upgrade revient alors à faire une re-implémentation dégradée, avec toutes les contraintes de l’existant et peu des bénéfices d’une refonte propre.
TCO upgrade versus TCO projet neuf
Comparer un upgrade à un projet neuf suppose d’empiler les postes de manière homogène. Voici un cadre de comparaison qu’un DSI peut présenter à son comité.
| Poste | Upgrade (SAP ECC → S/4HANA brownfield) | Projet neuf (S/4HANA greenfield) |
|---|---|---|
| Licences | Conversion de licences existantes + compléments | Licences S/4HANA complètes |
| Prestations intégrateur | Conversion + refonte spécifiques | Paramétrage complet + design processus |
| Reprise de données | Migration incrémentale, structure ACDOCA | Migration sélective, historique figé |
| Tests de régression | Élevés (couvrir l’existant) | Moyens (couvrir le nouveau) |
| Formation | Moyenne (changements UX) | Élevée (nouveaux processus) |
| Durée | 9 à 18 mois | 18 à 30 mois |
| Risque métier | Moyen (processus inchangés) | Élevé à court terme, faible à long terme |
Deux lectures possibles de ce tableau. Si la customisation est modérée et le paramétrage récent, l’upgrade brownfield reste l’option la plus économique à 3 ans. Si le code custom dépasse 40 % et si les processus datent d’avant 2017, un greenfield coûte plus cher en investissement initial mais évite de payer une dette technique pendant dix ans.
Les erreurs de gouvernance qui plombent un upgrade
Traiter l’upgrade comme un projet IT. C’est l’erreur mère. Un upgrade majeur touche la comptabilité, les ventes, les achats, la paie, le reporting. Sans sponsor direction métier et sans comité de pilotage opérationnel, l’upgrade devient une affaire de DSI, et les utilisateurs finaux le subissent.
Sous-budgéter les tests. La tentation est forte : le projet a du retard, on grappille sur les tests. Résultat : les bugs sortent en production chez l’utilisateur, et chaque bug coûte dix fois ce qu’il aurait coûté à détecter en UAT. Selon le Panorama Consulting Group 2025 ERP Report, les trois causes dominantes de dépassement budgétaire sont la sous-estimation du staffing (38 %), l’expansion du périmètre (35 %) et les problèmes techniques ou data (34 %), les trois convergent vers un même angle mort : les tests.
Conserver des customisations « juste au cas où ». Un spécifique non utilisé mais migré est une dette technique que vous paierez à chaque montée de version ultérieure. L’upgrade est le moment de nettoyer. Refusez la logique « on garde on ne sait jamais ».
Pas de plan de rollback. Si la bascule dérape, quelle est la procédure de retour à l’ancien système ? Combien d’heures pour restaurer ? Jusqu’à quelle heure de la bascule peut-on rollbacker sans perte ? Aucun projet ne devrait démarrer sans ces réponses documentées et testées.
Reconduire l’intégrateur historique sans remise en concurrence. Le partenaire qui a implémenté votre ERP en 2017 connaît votre paramétrage, c’est une force. Il connaît aussi les compromis historiques qu’il a lui-même créés, c’est une faiblesse. Une remise en concurrence, même symbolique, oblige à documenter l’existant et à comparer des approches. Elle fait aussi baisser les prix de 10 à 25 %.
Ce qu’il faut retenir
Un upgrade majeur n’est pas une mise à jour. Il touche l’architecture, le modèle de données, l’ergonomie, les processus. Il coûte proportionnellement plus qu’un projet neuf lorsque la customisation est élevée, et il est souvent le bon moment pour arbitrer la question « upgrade ou re-implémentation » plutôt que de la botter en touche.
La pression est réelle sur 2026. SAP ECC s’éteint en 2027 avec une rallonge payante jusqu’en 2030. Les Compatibility Packs S/4HANA on-premise se ferment en mai 2026. Sage 200 Manufacturing n’est plus supporté depuis fin 2025. Odoo pousse une version par an. Les DSI qui démarrent leur audit fit-gap aujourd’hui arrivent à temps pour planifier, budgéter et négocier. Ceux qui attendent juin 2026 pour commencer arbitreront en urgence, et l’urgence coûte cher.
Pour aller plus loin
Si cet article vous a servi, deux lectures complémentaires dans le blog :
- Migration ERP : guide complet du changement de système, la méthode globale quand on ne reste pas chez le même éditeur.
- SAP S/4HANA : la deadline des Compatibility Packs en mai 2026, la lecture contractuelle détaillée de la fenêtre SAP.
- Coût total de possession ERP : les 8 postes cachés, pour aller au-delà du prix de licence.
Pour valider votre hypothèse d’upgrade avant de signer, partez sur un POC sandbox de 6 à 10 semaines sur un périmètre réduit (une société, deux ou trois processus critiques). Budget typique : 40 à 80 K€. Livrable : une cartographie précise des gaps, un chiffrage documenté du spécifique à refaire, et un Go/No-Go factuel. C’est moins cher qu’un dérapage de deux trimestres sur un projet à sept chiffres.
