Le 31 décembre 2027, la maintenance standard de SAP ECC s'arrêtera. Une maintenance étendue prendra le relais jusqu'à fin 2030. Sur le papier, les DSI ont donc deux échéances : 2027 et 2030. Pourquoi, dans ce cas, faudrait-il considérer que 2026 est déjà l'année où tout se joue ?
La réponse ne se trouve pas dans le calendrier officiel de SAP, mais plutôt dans l'arithmétique des projets.
L'écart entre la décision et la bascule
Un projet de migration vers S/4HANA ne démarre pas le jour où la décision est prise. Il démarre après un cadrage, la rédaction d'un appel d'offres, le choix d'un intégrateur, la construction de l'équipe projet et l'accord final du Comité de Direction sur le budget.
Cette phase amont représente typiquement 3 à 6 mois selon la taille de l'organisation et la maturité de sa gouvernance SAP.
Ensuite vient l'exécution.
Une migration simple, sur un périmètre ECC limité et sans forte adhérence aux processus métier, peut se faire en 5 à 6 mois.
Une migration de taille moyenne, avec plusieurs filiales, quelques développements spécifiques et des interfaces à refondre, demande 9 à 12 mois.
Une migration complexe, pour un grand groupe industriel ou une administration disposant de multiples environnements et d'une forte dette technique, atteint 12 à 24 mois, parfois davantage.
L'addition de ces deux phases fait apparaître une réalité pratique.
En 2026, les organisations qui n'ont pas encore tranché disposent encore d'une marge de manœuvre, mais cette marge n'aura plus la même forme en 2027.
Décider plus tard, c'est composer avec les contraintes du marché : ressources plus rares, calendriers d'intégrateurs plus chargés, recours à la maintenance étendue comme amortisseur planifié.
Les deux trajectoires restent praticables. Elles n'offrent simplement pas la même latitude.
Ce que « décider » signifie vraiment
Décider de migrer vers S/4HANA n'est pas en soi une décision, mais plutôt un point de départ. La vraie décision se compose de quatre choix imbriqués.
Le périmètre. Migration complète en mode big bang, approche progressive par filiale ou par module, un lift&shift directement vers Rise. Chacune a des implications budgétaires et de gouvernance très différentes.
L'approche technique. Greenfield (nouvelle implémentation), brownfield (convertir l'existant) ou hybride. Ce choix conditionne directement la durée et le coût du projet, ainsi que la possibilité ou non de repenser les processus.
Le modèle d'hébergement. Cloud public, cloud privé, on-premise, cloud souverain. Chacun répond à des logiques propres et engage des compromis différents, même si le choix d’aller vers “Rise” semble être du bon sens.
Le choix du partenaire. Nature de l'intégrateur, modèle d'engagement, partage des responsabilités avec les équipes internes.
Ces quatre décisions sont liées. On ne peut pas arbitrer l'une sans déterminer les autres. Un cadrage, quelle que soit sa durée, consiste justement à rendre ces arbitrages cohérents entre eux. Sa profondeur varie selon le contexte :
Deux postures face à 2027
Sur le terrain, je distingue aujourd'hui deux profils d'organisations.
Les premières ont identifié 2026 comme l'année pour engager leur décision. Elles lancent leurs cadrages, sélectionnent leurs partenaires, structurent leurs équipes. Leur bascule se fera probablement en 2027 ou début 2028, avec un usage ciblé de la maintenance étendue pour absorber le glissement.
Les deuxièmes font un choix différent : utiliser la maintenance étendue jusqu'en 2030 comme un délai stratégique assumé. Cette option est pleinement valable lorsqu'elle résulte d'un arbitrage explicite entre coût supplémentaire et temps gagné. Elle devient plus exposée lorsqu'elle s'installe sans avoir été vraiment arbitrée.
Le vrai coût de l'attente
La maintenance étendue n'est pas une simple prolongation. Elle représente un surcoût direct et significatif du montant des licences de support et des coûts des infrastructures. Sur trois ans, pour un grand compte, l'addition peut atteindre plusieurs millions d'euros sans produire aucune valeur nouvelle. Ce n'est pas un investissement, c'est un loyer payé pour rester sur une technologie figée.
Le second coût est moins visible mais plus structurant. Les organisations qui choisiront de ne pas migrer vers Rise en 2026 accèderont aux nouveautés produit SAP, notamment sur l'IA générative et les services de la Business AI Platform, mais avec un décalage de deux à trois ans sur celles qui auront basculé plus tôt. Ce décalage peut être acceptable ou pénalisant selon les secteurs : neutre pour des métiers stables, sensible pour des activités exposées à une forte pression d'innovation.
Le troisième coût tient à la saturation prévisible de l'écosystème. Plus les projets se concentrent entre 2026 et 2028, plus les ressources qualifiées se raréfient, plus les calendriers s'étirent, plus les tarifs grimpent. Les organisations qui décident tardivement se retrouveront en concurrence, sur le même marché de compétences, avec celles qui auront anticipé.
Ce que 2026 impose réellement
L'année 2026 n'est pas la dernière année pour migrer. C'est la dernière année pour décider sans contrainte.
Décider en 2026, c'est conserver le choix du périmètre, de l'approche, du modèle d’hébergement et du choix du partenaire.
La différence n'est donc pas calendaire, mais une question de latitude stratégique.
Pour chaque DSI, il reste une interrogation à poser dès maintenant : où en est concrètement ma décision, au regard des quatre dimensions qui la composent ?