Les données legacy comme actif d’IA : pourquoi les anciennes données SAP ne devraient pas rester piégées dans d’anciens systèmes ERP

Auteur : Audren Butery, Consultant SAP chez TJC Group

Les données SAP historiques peuvent prendre en charge le reporting financier, les audits fiscaux, l’analyse à long terme et les futurs cas d’utilisation de l’IA. Cependant, conserver des données précieuses ne signifie pas que les organisations doivent continuer à exploiter les systèmes obsolètes qui les contiennent. Une stratégie structurée de décommissionnement des systèmes peut préserver le contexte métier et l’accès contrôlé tout en réduisant les coûts, l’exposition à la sécurité et la complexité technique.

Introduction

Lorsqu’une organisation passe de SAP ECC à S/4HANA, consolide plusieurs plateformes ERP ou remplace une ancienne application métier, elle doit toujours décider ce qu’il advient des informations laissées derrière.

Maintenir le système d’origine disponible en mode lecture seule peut sembler l’option la moins chère et la plus simple. Cependant, cela pose des menaces de sécurité et des risques de conformité importants.

Grâce au décommissionnement des systèmes legacy, les organisations peuvent préserver les données historiques, les documents, les rapports et le contexte métier dont elles ont encore besoin tout en retirant la technologie qui les a créés.

L’objectif est de conserver les informations qui ont un objectif valide de reporting, de conformité ou d’analyse sans maintenir indéfiniment l’environnement legacy complet.

Pourquoi les données SAP legacy peuvent encore avoir une valeur commerciale

Les données ne perdent pas automatiquement leur valeur lorsqu’un système est remplacé. Les enregistrements des systèmes SAP tels qu’ECC ou S/4HANA, ainsi que d’autres applications SAP et non-SAP retirées, peuvent continuer à soutenir les décisions commerciales longtemps après que les transactions quotidiennes ont été déplacées ailleurs.

La valeur se répartit généralement en trois domaines :

Besoin métier	Exemples d’informations legacy utiles
Reporting et analyse	Transactions historiques, soldes, prix, performance des fournisseurs, mouvements de stock
Conformité et preuves	Factures, documents comptables, registres fiscaux, approbations, pistes d’audit
Analyse et IA	Modèles pluriannuels, exceptions, résultats, comportement client, historique opérationnel

La période de rétention appropriée, la méthode d’accès et le niveau de détail différeront pour chaque catégorie.

Reporting historique et analyse des tendances

Les rapports opérationnels ont tendance à se concentrer sur la période actuelle. L’analyse stratégique nécessite souvent une vision à plus long terme.

Les équipes financières peuvent comparer les marges, le fonds de roulement, l’activité de clôture ou le comportement de paiement sur plusieurs années. Les équipes d’approvisionnement peuvent évaluer la fiabilité des fournisseurs à travers plusieurs cycles économiques. Les équipes opérationnelles peuvent examiner les modèles de production, de stock et de maintenance avant et après un changement majeur.

Les rapports plus anciens peuvent devenir particulièrement précieux après une fusion, une restructuration ou une migration S/4HANA, lorsque le reporting actuel n’inclut plus chaque période ou entité juridique.

Par exemple, lors d’un programme S/4HANA, certaines données métier peuvent être transformées et chargées dans le nouvel environnement, tandis que les informations plus anciennes restent dans le système legacy ou sont extraites pour un accès gouverné à long terme. Étant donné que la migration implique souvent un processus ETL, les données utilisées dans S/4HANA peuvent ne plus représenter exactement la source d’origine. Pour l’audit, la réconciliation ou une référence future, les organisations peuvent toujours avoir besoin d’une extraction fidèle du système ECC d’origine, ainsi que des documents, des relations et du contexte nécessaires pour la comprendre.

Les données n’ont pas besoin de rester dans l’ERP d’origine pour prendre en charge ces tâches. Elles ont cependant besoin de suffisamment de contexte pour que les utilisateurs comprennent ce que signifient les chiffres.

Exigences d’audit, fiscales et de conformité

Les informations historiques peuvent également devoir rester disponibles pour les autorités fiscales, les audits légaux, les examens réglementaires, les litiges ou les enquêtes internes.

L’exigence est rarement limitée à une seule table ou à un total comptable. Les auditeurs peuvent avoir besoin de la transaction, de son document justificatif, de l’historique des approbations, des données de base pertinentes et de la preuve de la manière dont l’information a été conservée ou ultérieurement détruite.

Les exigences de rétention peuvent différer selon le pays, l’entité juridique, le type de document et l’industrie. Les règles de confidentialité peuvent également exiger que les données personnelles soient bloquées ou détruites lorsque leur objectif légal expire.

Les organisations doivent donc équilibrer la préservation et la suppression contrôlée.

Les informations doivent rester disponibles tant qu’une obligation légale, fiscale ou commerciale valide s’applique. Une fois cet objectif expiré, les données doivent être détruites pour se conformer aux lois sur la confidentialité des données. Le masquage des données peut aider à limiter la visibilité, mais il ne remplace pas la suppression car il est non destructif. Les environnements d’accès legacy ont donc besoin de mécanismes de confidentialité des données qui peuvent prendre en charge la suppression contrôlée lorsque les informations ont atteint la fin de leur période de rétention ou n’ont plus d’objectif valide.

Les contrôles SAP ILM et RGPD peuvent prendre en charge la rétention, le blocage, les suspensions légales et la destruction contrôlée. Des contrôles équivalents doivent rester efficaces après le retrait du système source.

Utilisation potentielle dans les modèles d’analyse et d’IA

Les données ERP historiques peuvent montrer comment l’entreprise s’est comportée dans différentes conditions.

Selon le cas d’utilisation, elles peuvent soutenir l’analyse du comportement de paiement des clients, la fiabilité des fournisseurs, les modèles de demande, les pannes d’équipement ou les exceptions financières.

Les informations pluriannuelles peuvent révéler des modèles qui n’apparaissent pas dans l’ERP actuel seul. Elles peuvent également aider les organisations à comparer les résultats dans différentes conditions de marché, structures organisationnelles ou politiques commerciales.

Préserver cet historique maintient les futures options analytiques ouvertes. La pertinence de l’information pour un cas d’utilisation particulier de l’IA doit être évaluée séparément.

Les données historiques contiennent des informations précieuses pour les prévisions, la chaîne d’approvisionnement et les tendances clients. Une curation appropriée alimente efficacement les modèles d’IA prédictive et générative.

Pourquoi les données précieuses restent souvent piégées dans les systèmes legacy

De nombreuses organisations conservent d’anciennes applications parce que les utilisateurs ont encore besoin d’un accès occasionnel à leurs données.

Une équipe financière peut avoir besoin d’une facture datant de huit ans. Une équipe fiscale peut avoir besoin d’enregistrements d’une entité juridique fermée. Un auditeur peut demander le rapport original derrière un solde historique. Une équipe de service client peut avoir besoin d’une transaction d’un ERP régional retiré.

L’organisation place donc le système en mode lecture seule et reporte le retrait.

Il s’agit d’une mise en veille plutôt que d’un décommissionnement complet. La mise en veille maintient l’application disponible, tandis que le décommissionnement préserve les informations requises ailleurs et retire l’application d’origine.

Les données restent souvent piégées parce que les rapports dépendent toujours de la logique de l’application d’origine ou parce que les documents sont stockés séparément des transactions sous-jacentes. Les tables personnalisées peuvent être mal documentées, les interfaces peuvent ne pas avoir été mappées, et les utilisateurs peuvent ne pas savoir quels enregistrements historiques ils devront utiliser plus tard.

L’organisation peut également manquer d’une plateforme alternative capable de préserver les transactions, les documents, les rapports et les relations sous une forme que les utilisateurs métier et les auditeurs peuvent comprendre.

Ces préoccupations devraient définir les exigences d’information et de validation du projet de décommissionnement. Elles ne justifient pas nécessairement de maintenir l’application complète opérationnelle.

Le coût et le risque de maintenir les anciens systèmes opérationnels

Un système legacy en lecture seule peut ne plus traiter de nouvelles transactions, mais il nécessite toujours une gestion continue.

L’entreprise continue de payer pour une application dont le but principal est la récupération historique occasionnelle.

Coût ou risque	Exigence continue
Infrastructure	Serveurs, bases de données, stockage, sauvegardes, reprise après sinistre
Logiciel	Licences d’application, de base de données, de système d’exploitation et de middleware
Opérations	Surveillance, réponse aux incidents, correctifs et administration des accès
Expertise	Spécialistes qui comprennent l’ancienne technologie et le modèle de données
Sécurité	Gestion des vulnérabilités, authentification et accès privilégié
Conformité	Rétention, suppression, preuves d’audit, contrôles de confidentialité et processus autorisés de suppression de données

Au fil du temps, l’environnement devient plus difficile à prendre en charge tandis que le niveau d’activité commerciale utile continue de baisser.

Coûts d’infrastructure, de licence et de maintenance

Les applications legacy peuvent dépendre de matériel obsolète, de versions de base de données non prises en charge, d’anciens systèmes d’exploitation ou d’arrangements d’hébergement dédiés.

Déplacer le système vers une infrastructure cloud ne supprime pas le coût. L’organisation peut toujours payer pour la capacité de calcul, le stockage, les sauvegardes, la surveillance, les licences logicielles, le support spécialisé, les interfaces et les arrangements de reprise après sinistre. Certains composants peuvent ne plus recevoir de correctifs réguliers ou de mises à jour du fournisseur, augmentant l’exposition à la cybersécurité au fil du temps.

Ces dépenses sont souvent réparties sur plusieurs budgets, ce qui peut masquer le coût total de la conservation de l’application.

L’impact financier du maintien des systèmes legacy devrait donc être évalué au niveau du portefeuille. Une organisation peut avoir des dizaines d’applications retirées ou semi-retirées, chacune consommant de l’argent et de l’attention technique.

Ensemble, elles peuvent détourner des ressources des programmes S/4HANA, SAP BTP, d’analyse, de sécurité et d’IA.

Risques de sécurité et de contrôle d’accès

Les systèmes plus anciens peuvent ne pas prendre en charge les normes actuelles d’identité, d’authentification, de chiffrement ou de surveillance de l’organisation.

Par exemple, les comptes d’utilisateurs SAP legacy peuvent se trouver en dehors du fournisseur d’identité actuel, tandis que les rôles d’affichage larges créés des années auparavant peuvent ne plus être inclus dans les processus modernes d’examen des accès.

Les composants non pris en charge peuvent également rendre l’application de correctifs difficile. Les équipes de sécurité peuvent avoir à choisir entre modifier un système instable ou laisser une faiblesse connue non résolue.

Le déplacement des informations historiques vers un environnement d’accès pris en charge peut réduire cette exposition en appliquant les contrôles actuels d’authentification, de journalisation, d’autorisation et de protection des données.

L’objectif n’est pas simplement de copier la base de données. Il s’agit de placer les informations conservées sous un modèle de sécurité plus durable.

Défis de conformité dans les systèmes non pris en charge

La conformité devient plus difficile lorsque les informations historiques sont réparties sur plusieurs applications legacy.

Chaque système peut utiliser des règles de rétention, des processus de destruction, des modèles d’accès et des mécanismes d’audit différents. Certains enregistrements peuvent contenir des informations personnelles qui devraient éventuellement être bloquées ou supprimées, tandis que d’autres peuvent rester soumises à des suspensions légales.

Une application non prise en charge peut préserver l’enregistrement d’origine mais manquer des contrôles nécessaires pour le gérer tout au long de son cycle de vie. De nombreuses applications legacy ont été conçues avant l’existence des exigences modernes en matière de confidentialité des données, de sorte qu’elles peuvent ne pas inclure de mécanismes fiables pour l’examen de la confidentialité, la suppression contrôlée, la capture de preuves ou les flux de travail autorisés de suppression de données.

Par exemple, l’application peut ne pas prendre en charge la destruction contrôlée d’un enregistrement client expiré sans affecter les documents connexes ou les preuves comptables. Cela crée un écart de conformité : l’organisation peut être responsable de l’application des règles de confidentialité, mais l’ancien système peut ne pas fournir les fonctionnalités nécessaires pour les appliquer en toute sécurité.

Le décommissionnement offre l’opportunité de gérer les informations legacy selon un modèle d’accès plus contrôlé. Cela peut simplifier la récupération, les examens d’accès, les vérifications de confidentialité et le support d’audit. Cependant, les règles de confidentialité et de suppression doivent toujours être évaluées et appliquées en fonction du système source spécifique, du type de données et de l’exigence de rétention, plutôt que de supposer qu’une seule politique peut s’appliquer automatiquement à chaque système retiré.

Ce dont les données legacy ont besoin avant de pouvoir prendre en charge l’IA

Les données historiques ne sont pas automatiquement adaptées à l’analyse ou à l’IA, mais elles ne sont pas toujours directement utilisables sous leur forme brute de système legacy. Certaines données peuvent être difficiles à récupérer, stockées dans des structures qui n’ont pas été conçues pour une utilisation analytique moderne, ou conservées dans des formats tels que des tables clusterisées, chiffrées ou personnalisées. Avant de pouvoir prendre en charge l’IA, les données doivent être extraites avec leur contexte, vérifiées pour leur qualité et préparées pour le cas d’utilisation prévu.

Pour les cas d’utilisation en entreprise, elles doivent rester compréhensibles, cohérentes, traçables et disponibles sous des autorisations définies.

Ceci est particulièrement important pour les données SAP car la signification métier est souvent répartie entre les transactions, les données de base, la configuration, les champs personnalisés, les structures organisationnelles et les documents justificatifs.

Contexte métier et métadonnées

Une table de transactions historiques a une valeur limitée si les utilisateurs ne peuvent pas expliquer ce que représente chaque champ, quel code d’entreprise a créé l’enregistrement, quelle devise et quelle période fiscale s’appliquent, ou si les identifiants ont changé lors de fusions ou de migrations.

Ils peuvent également avoir besoin de comprendre si le résultat original a été influencé par la configuration du système source, les champs personnalisés, les rapports ou les règles métier, où les documents justificatifs sont stockés, et comment l’enregistrement se rapporte à d’autres objets métier. Cela ne signifie pas recréer la logique de l’application d’origine dans la plateforme de décommissionnement.

Les métadonnées préservent cette signification.

Elles peuvent inclure des définitions de table, des descriptions de champs, des relations de documents, un contexte organisationnel, une logique de rapport, des identifiants de système source, des dates d’extraction, des journaux d’extraction et une traçabilité vers le système d’origine.

La préservation de la logique des rapports mérite une attention particulière. Un rapport financier historique peut dépendre de tables de taux de change, de calendriers fiscaux, de valeurs de configuration, de calculs personnalisés ou de règles qui ont changé au fil du temps. Les pièces jointes peuvent également se trouver en dehors de la base de données SAP.

La conservation des seules tables de transactions peut donc être insuffisante pour reproduire le résultat original.

Considérons un modèle conçu pour prédire les retards de paiement.

• Il peut combiner les créances actuelles de S/4HANA, le comportement de paiement historique d’ECC, les informations de litige d’un système de service client retiré et les attributs client d’une ancienne application régionale.

• Ces sources ne peuvent pas être traitées comme interchangeables tant que les identifiants client, les devises, les conditions de paiement, les formats de date et les définitions métier n’ont pas été réconciliés.

• Les données historiques doivent rester connectées au contexte qui leur donne un sens.

Préparer les données historiques pour l’analyse et l’IA

Le décommissionnement préserve les informations historiques et le contexte nécessaire pour les utiliser après le retrait de l’application source.

Pour l’analyse ou l’IA, les informations sélectionnées peuvent encore devoir être mappées, standardisées ou préparées pour le cas d’utilisation spécifique, en particulier lorsque les structures ou définitions métier ont changé au fil du temps.

Cela ne réduit pas la valeur du décommissionnement. Cela sépare deux exigences différentes : préserver un accès fiable aux informations historiques et préparer des données sélectionnées pour un objectif analytique ou d’IA particulier.

Gouvernance et accès contrôlé

Les données historiques ne devraient pas devenir plus largement disponibles simplement parce qu’elles sont envisagées pour l’IA.

L’autorisation des utilisateurs, l’accès basé sur l’objectif, le masquage, la rétention, la suppression, les pistes d’audit, la résidence des données et les exigences de confidentialité continuent de s’appliquer.

Une plateforme peut préserver les enregistrements historiques pour une récupération conforme, tandis qu’un pipeline contrôlé distinct fournit des informations sélectionnées à SAP Business Data Cloud, à un lac de données, à un entrepôt ou à une autre plateforme analytique.

Ces modèles d’accès servent des objectifs différents :

Besoin d’accès	Exigence typique
Récupération historique	Données source, documents, rapports enregistrés, relations et traçabilité, sans recréer les transactions SAP dans la plateforme d’accès legacy
Réponse à un audit ou à une demande fiscale	Preuves reproductibles avec accès utilisateur contrôlé
Analyse ou IA	Données sélectionnées, transformées et dont la qualité a été évaluée, fournies via un pipeline approuvé

Le référentiel legacy et la plateforme d’IA n’ont pas besoin d’être le même système.

La préservation des informations historiques dans un environnement d’accès legacy permet aux organisations de maintenir l’ERP actuel axé sur les opérations actives tout en conservant l’accès aux données, documents et rapports qui devraient être nécessaires après le retrait. Cela ne signifie pas que la plateforme doit être traitée comme une simple couche de stockage à froid pour chaque cas d’utilisation futur possible.

Lorsqu’un cas d’utilisation ultérieur d’analyse ou d’IA est approuvé, l’organisation doit définir un processus d’accès ou d’extraction distinct à partir des données legacy conservées. L’objectif, les autorisations, la qualité des données et le statut de rétention doivent être vérifiés avant que ces informations ne soient utilisées en dehors de l’environnement d’accès legacy.

Comment préserver les informations historiques tout en décommissionnant le système source

Un projet de décommissionnement réussi ne commence pas par l’arrêt de l’application.

Il commence par l’identification des informations historiques dont les utilisateurs, les auditeurs, les équipes fiscales et les propriétaires d’entreprise auront encore besoin après le retrait du système source. Cela peut inclure des données métier, des documents, des pièces jointes, des rapports, des références de système source et suffisamment de contexte pour rendre les informations conservées compréhensibles.

L’objectif n’est pas de recréer l’application legacy dans une nouvelle plateforme. Il s’agit de préserver les informations qui ont encore un objectif commercial, légal, fiscal ou de reporting valide, tout en permettant le retrait du système d’origine.

Pour cette raison, la portée doit être convenue avant l’arrêt. L’organisation doit confirmer quelles données et quels documents doivent rester accessibles, qui aura besoin d’un accès, comment la récupération sera testée, et quelles exigences de confidentialité, de rétention et de suspension légale s’appliquent toujours.

Une fois cette portée claire, les étapes les plus importantes sont la validation et le retrait contrôlé.

1. Réconciliation et tests de récupération validés

Les utilisateurs métier, les auditeurs, les équipes fiscales et les propriétaires de données doivent confirmer que les informations conservées sont complètes et utilisables.

Les tests doivent couvrir la récupération des transactions, des rapports, des documents et des pièces jointes. Ils doivent également confirmer que les totaux correspondent à la source, que les rôles d’utilisateur fonctionnent comme prévu et que les contrôles de confidentialité ou de suspension légale applicables restent efficaces.

Lorsque des rapports historiques doivent être reproduits, les tests doivent confirmer que la logique, la configuration et les données de support nécessaires ont été préservées.

Le système source doit rester disponible jusqu’à ce que les propriétaires concernés aient approuvé les résultats.

2. Retrait de l’application et accès futur contrôlé

Une fois l’extraction, la réconciliation et les tests utilisateurs terminés, l’organisation peut retirer l’ancienne infrastructure, les licences, les interfaces, les comptes et les processus de support.

Les informations historiques peuvent rester disponibles via un modèle d’accès legacy durable.

Le plan de retrait doit définir comment la récupération historique de routine, le support d’audit, les enquêtes légales et les extractions analytiques approuvées seront gérés après l’arrêt.

Comment ELSA prend en charge le décommissionnement des systèmes legacy et l’accès aux données à long terme

L’Enterprise Legacy System Application, ou ELSA, est la solution de TJC Group pour le décommissionnement des systèmes SAP et non-SAP tout en préservant l’accès aux informations historiques.

ELSA sépare l’accès à long terme de l’application d’origine et peut conserver les données métier, les documents, les pièces jointes, les rapports, les relations, le contexte du système source et les informations d’audit.

Les utilisateurs autorisés peuvent rechercher, interroger, générer des rapports et récupérer ces informations après le retrait de l’ancienne application.

Un projet de décommissionnement avec ELSA peut inclure l’évaluation de la source, l’extraction des données et des documents, la réconciliation, la préparation et la préservation des rapports requis, la configuration de l’accès et de la confidentialité, les tests d’acceptation utilisateur, le retrait de l’application et le support à long terme. Lorsque des rapports historiques sont requis, ils doivent normalement être générés à partir du système source avant ou pendant le projet et stockés pour un accès futur, plutôt que recréés dans la plateforme d’accès legacy.

ELSA peut être déployé dans l’environnement SAP BTP du client ou dans l’environnement SAP BTP de TJC Group, tandis que le stockage des données reste la propriété du client. Selon l’architecture du client, ce stockage peut être basé sur le cloud ou sur site. TJC Group ne prend pas en charge le stockage des données client. ELSA est certifié comme étant construit sur SAP BTP et disponible sur SAP Store. Sa certification SAP BTP soutient son rôle au sein des paysages SAP modernes.

Résultat du projet	Effet commercial
Retirer les applications legacy	Réduire les exigences d’infrastructure, de licence et de support et l’exposition à la cybersécurité
Préserver l’accès historique	Maintenir la disponibilité des données, documents, rapports et relations
Centraliser les informations legacy	Accéder à plusieurs systèmes SAP et non-SAP retirés via une seule plateforme
Appliquer les contrôles de gouvernance actuels	Utiliser des contrôles modernes d’autorisation, de confidentialité, de rétention et d’audit
Soutenir l’analyse future et l’IA	Permettre aux applications ou pipelines d’analyse et d’IA approuvés d’accéder à des données legacy sélectionnées via l’API d’ELSA sous des autorisations définies
Maintenir la traçabilité	Préserver les informations source et la lignée après le retrait de l’application

ELSA permet à l’ERP actuel de rester axé sur les opérations actives tandis que les informations historiques restent accessibles via ELSA. Si nécessaire, les applications ou pipelines d’analyse et d’IA approuvés peuvent accéder à des données legacy sélectionnées via l’API d’ELSA sous des autorisations définies.

Conclusion

Le retrait d’un système SAP legacy ne signifie pas nécessairement la perte des informations qu’il contient. Les transactions historiques, les documents, les rapports et le contexte métier peuvent conserver une valeur réelle pour le reporting, les audits, les obligations fiscales et les futurs cas d’utilisation de l’IA, longtemps après l’arrêt de l’application d’origine.

Le risque réside dans le fait de laisser cette valeur piégée dans un système vieillissant, coûteux et de plus en plus vulnérable. Une approche de décommissionnement structurée, basée sur une extraction validée, une réconciliation et un accès gouverné, permet aux organisations de préserver ce qui compte encore tout en retirant ce qui n’a plus besoin de fonctionner.

Avec ELSA, TJC Group aide les organisations à opérer cette transition en toute confiance : en conservant un accès traçable et bien gouverné aux données legacy tout en réduisant les coûts d’infrastructure, l’exposition à la sécurité et les risques de conformité, afin que les informations historiques restent prêtes à soutenir l’entreprise, quand et comme elles seront nécessaires.