Migration S/4HANA terminée – et maintenant ? Pourquoi la…

La migration vers S/4HANA domine l’agenda IT. Mais tandis que les entreprises investissent des milliards dans de nouveaux systèmes, les anciens restent souvent simplement en place. Cela coûte de l’argent, crée des risques de conformité et mobilise des ressources qui manquent ailleurs. Le Data Decommissioning résout ce problème, mais il est systématiquement oublié dans la plupart des projets de migration.

L’essentiel en bref

SAP ECC : le support arrive à échéance, les systèmes restent

SAP a clairement communiqué son calendrier. Pour les versions ECC EHP 0 à 5, le support standard a déjà pris fin fin 2025. Les versions EHP 6 à 8 suivront fin 2027. Ensuite, il ne restera que l’Extended Maintenance, avec un supplément de 9 % sur les coûts de licence actuels.

La réalité est différente de la feuille de route. Selon une enquête de la DSAG de février 2026, près de la moitié des utilisateurs SAP germanophones prévoient de continuer à exploiter leurs systèmes ECC au-delà de 2027. Les raisons sont compréhensibles : les migrations vers S/4HANA durent plus longtemps que prévu, coûtent plus cher que budgété et mobilisent les meilleurs profils de l’équipe.

Ce qui est souvent négligé : même les entreprises qui migrent avec succès vers S/4HANA laissent souvent simplement les anciens systèmes continuer à fonctionner. L’exploitation opérationnelle est terminée, mais les données historiques doivent rester accessibles. Les délais de conservation prévus par les GoBD exigent un accès conforme aux exigences d’audit pendant une période pouvant aller jusqu’à dix ans. Les délais de suppression imposés par le RGPD doivent être respectés. Et lors de transactions M&A, des demandes de garantie peuvent encore nécessiter l’accès à d’anciennes données plusieurs années plus tard.

L’étape oubliée : ce qui se passe après le go-live

Une migration S/4HANA se compose de deux moitiés. La première capte l’attention, le budget et les équipes projet : migration des données, customizing, tests, go-live. La seconde est reportée : que se passe-t-il avec les anciens systèmes ?

Dans la pratique, cela signifie que les instances ECC, les systèmes Navision, les applications AS/400 et les applications mainframe restent dans le centre de calcul. Ils consomment des licences, des ressources serveur et de la capacité d’administration. Des correctifs doivent être appliqués, même si plus aucun utilisateur ne travaille dessus en production. Le savoir-faire relatif à ces systèmes s’amenuise, tandis que les coûts restent constants.

Les responsables IT connaissent bien ce problème. Mais il existe rarement un budget dédié pour „arrêter les anciens systèmes“. Le decommissioning n’apparaît dans aucune roadmap, parce qu’il ne livre aucune nouvelle fonctionnalité et ne remplit aucun business case sur une diapositive. Pourtant, le calcul est simple : chaque euro qui ne part pas dans la maintenance de systèmes morts est disponible pour l’innovation.

Trois scénarios typiques pour le Data Decommissioning

Le Data Decommissioning répond à des situations auxquelles les départements IT de la région DACH sont régulièrement confrontés. Voici trois scénarios tirés de la pratique.

Scénario 1 : post-migration. Une entreprise a achevé sa transformation vers S/4HANA et consolide en parallèle plusieurs systèmes legacy. Les données opérationnelles des deux dernières années ont été migrées. Mais les données historiques issues d’ECC et de Navision doivent rester accessibles, car les auditeurs, les conseillers fiscaux et l’audit interne doivent pouvoir y accéder. Au lieu de continuer à exploiter les deux anciens systèmes, les données sont transférées dans un système d’historisation. Le système source est arrêté.

Scénario 2 : transaction M&A. L’entreprise A vend une division à l’entreprise B. Les données opérationnelles sont migrées, mais les deux parties doivent continuer à pouvoir accéder aux données historiques, notamment pour les droits de garantie et la conformité GoBD. Une copie système serait la solution coûteuse. Un outil d’historisation qui conserve les données de manière conforme aux exigences d’audit et maintient l’accès logique constitue l’alternative plus légère.

Scénario 3 : évacuation du centre de calcul. Les serveurs doivent quitter le centre de calcul d’ici la fin de l’année. Une AS/400 et un mainframe contiennent des données historiques critiques pour l’entreprise, qui ne peuvent pas être supprimées pour des raisons réglementaires. Les applications ne sont pas compatibles avec le cloud. La solution : exporter les données, les stocker dans un outil d’historisation basé sur le cloud et arrêter l’ancien matériel.

Comment fonctionne un décommissionnement moderne

L’approche a évolué ces dernières années. Autrefois, la norme consistait à utiliser l’archivage SAP avec ILM ou à exploiter des copies en lecture seule. Ces deux approches ont leurs limites : ILM est complexe, nécessite des licences SAP en continu et ne couvre que les données SAP. Les copies en lecture seule doivent être corrigées et administrées.

Les plateformes modernes d’historisation, comme Historia de SDD Group, adoptent une autre approche. Les données sont exportées depuis le système source et stockées dans un data store basé dans le cloud. L’accès se fait via une application web qui reproduit la logique métier de l’ancien système. Les utilisateurs voient les données dans la structure qui leur est familière, même si le système source n’existe plus.

Le modèle tarifaire repose sur le volume de stockage, et non sur le nombre d’utilisateurs. Utilisateurs illimités, authentification unique, contrôle d’accès basé sur les rôles. Pour les services informatiques, cela signifie : plus de coûts de licence récurrents pour les anciens systèmes, plus de surcharge d’administration, plus de gestion des correctifs pour les logiciels en fin de vie.

Un Retention Manager garantit le respect des délais de suppression prévus par le RGPD et la suppression ou l’anonymisation automatique des données à l’expiration de l’obligation de conservation. Dans les secteurs réglementés comme les services financiers et l’industrie pharmaceutique, les autorités de surveillance le contrôlent activement.

Pourquoi le sujet doit maintenant être inscrit à l’agenda

La combinaison de la fin du support SAP, de la hausse des coûts du cloud et du durcissement des exigences de conformité crée une pression à agir qu’il n’est plus possible d’ignorer. Les entreprises qui continuent d’exploiter des systèmes ECC au-delà de 2027 en mode Extended Maintenance paieront 9 % de plus pour un système qui ne recevra plus de nouvelles fonctionnalités.

Dans le même temps, la pression réglementaire augmente. La conservation conforme à la GoBD, les obligations de suppression du RGPD et les exigences sectorielles comme DORA dans le secteur financier font d’une historisation structurée des données une obligation. „Laisser simplement tourner“ n’est pas une stratégie de conformité.

Pour les responsables informatiques et les DSI, le décommissionnement n’est pas un sujet glamour. Il n’apporte ni innovation, ni fonctionnalités d’IA, ni projet prestigieux pour la prochaine présentation au comité de direction. Mais il libère du budget, réduit les risques et simplifie le paysage informatique. Ce sont ces sujets qui feront la différence dans douze mois.

Questions fréquentes

Source de l’image : générée par IA (avril 2026)

Traduit de l’original allemand par intelligence artificielle. La version allemande fait foi.