1. Introduction
SAP RE-FX figure parmi les modules les plus complexes de l'environnement SAP en raison de son intégration étroite avec les modules FI, CO, PM, PS, MM et FI-CA. Dans de nombreuses organisations, il se connecte également à des plateformes externes : systèmes CAFM ou SIG, ou extensions personnalisées. Chaque connexion représente une véritable dépendance opérationnelle. Les contrats de location, les structures d'actifs, l'utilisation de l'espace et la répartition des coûts ne sont pas de simples données ; ils reflètent la réalité de l'entreprise. Cette profondeur rend RE-FX puissant, mais elle amplifie également les risques. Ce qui semble être une procédure SAP simple pour l'archivage se transforme souvent en un enchevêtrement de configurations héritées et de connexions profondément enracinées via des programmes Z et des API. L'archivage dans RE-FX n'est jamais purement technique ; il est organisationnel, juridique et politique. Trop souvent, cependant, le sujet est traité comme une tâche secondaire — quelque chose qui peut attendre, être délégué ou « géré plus tard ». Cette hypothèse coûte cher. Ce document met en évidence quatre erreurs récurrentes dans l'archivage SAP, en mettant l'accent sur RE-FX et ILM. Les deux premières décrivent des défis communs à presque tous les modules principaux. Les troisième et quatrième abordent des problèmes spécifiques à RE-FX et ILM, des disciplines particulièrement pertinentes pour les organisations immobilières et à forte intensité d'actifs. Dans les quatre cas, le même schéma se répète : des idées fausses structurelles qui érodent discrètement la conformité, les budgets et la crédibilité bien avant qu'un seul octet ne soit supprimé. Chaque section expose la cause sous-jacente, le risque systémique qu'elle engendre et l'état d'esprit nécessaire pour y remédier.
2. Le risque d'attendre : pourquoi « plus tard » est l'option la plus coûteuse
L'archivage figure rarement à l'ordre du jour du conseil d'administration. Il ne génère aucun chiffre d'affaires, n'améliore aucun indicateur de performance clé (KPI) et ne vaut guère de reconnaissance. Ce qu'il garantit, c'est la stabilité : une conservation documentée, une croissance prévisible des données et des dépenses HANA maîtrisables. Rares sont ceux qui défendent des résultats invisibles, et le sujet semble à peu près aussi glamour que de ranger le grenier. Au sein de l'organisation, chaque service trouve une raison d'attendre. Le marketing conserve les données historiques « pour le contexte ». Le service client conserve les anciens contrats. Le service juridique hésite à supprimer des preuves potentielles, mais s'inquiète également de la conformité au DSG/RGPD. Des positions individuelles pourtant justifiées créent une impasse collective. Les mois passent, les données s'accumulent. La prétendue prudence de l'attente se traduit plus tard par des factures HANA plus élevées, des audits plus stricts et des demandes de conformité exigeant de la documentation. Un détour fréquent est le HANA Easy Fix lors de transformations Greenfield ou Bluefield : migrer de manière sélective et conserver un héritage en lecture seule. Cela semble bien sur les diapositives, mais cela maintient généralement l'exposition aux coûts et à la gouvernance au lieu de la résoudre. Une approche pratique est discrète et précoce. Formalisez l'archivage en tant qu'initiative définie — ajoutez des discussions préalables avec les parties prenantes et les décideurs compétents, ne le présentez pas comme une tâche secondaire. Commencez de manière informelle : recueillez les points de vue et suscitez l'intérêt. Passez ensuite à la clarté — introduisez progressivement les termes techniques de l'ILM (gestion du cycle de vie des informations) — définition des fenêtres de conservation, etc. Publiez-les en tant que règles de gouvernance, organisez de brèves réunions de décision avec les quelques parties prenantes qui doivent donner leur accord. Exécutez, mesurez, étendez. Répétez. Les itérations sont précieuses dans cette tâche. L'archivage ne suscitera peut-être jamais d'applaudissements. Mais il réduit les risques et apporte une prévisibilité des coûts — avant que des déclencheurs externes n'imposent une réponse précipitée et coûteuse.
3. Le dilemme décisionnel : itératif, ni en cascade ni en coupure nette
Une fois que la direction reconnaît que l'archivage ne peut plus être reporté, le véritable travail stratégique commence. Pour le plus grand soulagement de tous les dirigeants qui préfèrent l'éviter : l'archivage n'a atteint son niveau actuel d'urgence et d'importance « qu'au cours de la dernière décennie », motivé moins par la stratégie que par des circonstances techniques et juridiques. Ce qu'il convient de mentionner : cette décision ne peut pas suivre une simple séquence Décision → Exécution → Clôture. Elle nécessite une clarification itérative — mais avec un point d'arrivée défini. Prendre cette décision ou la rendre possible relève en partie d'un travail de pionnier. L'erreur par défaut survient dès que l'action est enfin reconnue : la responsabilité est transférée aux services juridiques et informatiques. Le raisonnement semble logique — le service juridique définit ce qui doit être supprimé, le service informatique met en œuvre la méthode. En pratique, les deux fonctionnent en vase clos. Le service juridique manque de visibilité sur les structures de données et l'utilisation du système ; le service informatique manque de maîtrise des termes, de la formulation ET de la réflexion propres aux différentes juridictions.
Chacun agit correctement dans son propre cadre, mais ensemble, ils créent une impasse. La délégation sous cette forme ne résout pas le problème ; elle le formalise.
Option 1 — Définissez vous-même l'objectif
La prise en charge par la direction commence par la définition de l'objectif principal :
- Conformité : conservation conforme au DSG/RGPD avec suppression automatisée.
- Maîtrise des coûts : réduction du volume HANA pour stabiliser les dépenses de stockage et de licence.
- Sortie du système : mise hors service avec maintien d'un accès légal à des fins d'audit.
Ces facteurs s'excluent mutuellement en termes de priorité. Les mélanger sans prise de responsabilité conduit à des règles contradictoires, à une duplication du travail et à des retards. L'archivage « neutre » échoue car la neutralité n'existe pas : chaque choix de conception privilégie une dimension. Si le service juridique domine, l'efficacité s'érode ; si l'informatique domine, le bouclier juridique s'affaiblit. Le problème de l'option 1 (explicite).
Il est difficile de prendre une décision exécutive éclairée sans contributions précises des services juridiques et informatiques — et en réalité :
- SAP ILM est rarement une priorité centrale pour l'équipe SAP, à moins que vous ne disposiez d'un expert ILM attitré.
- Le DSG/RGPD est souvent traité par le service juridique comme de l'hygiène « externalisable », déléguée vers des prestataires externes en tant que tâche peu prestigieuse.
Résultat : les dirigeants hésitent, les itérations tournent en boucle, aucune décision n'est prise. Ce qu'il faut. Une immersion personnelle délimitée en vaut généralement la peine. Consacrez-y une attention réelle (des jours, pas des heures), définissez l'objectif et concluez. Si cela est fait correctement, vous retirez le sujet de votre agenda pour environ 10 ans. Le paradoxe : les résultats à long terme sont peu applaudis ; mieux vous faites, moins le succès est visible. C'est là le véritable dilemme de l'option 1.
Option 2 — Déléguer, mais au bon niveau
Si la direction ne prend pas directement les rênes, elle doit tout de même définir les limites et la traduction : mettre en place une triade gouvernée : Juridique, Informatique, Finance/Opérations sous mandat exécutif explicite. Finance/Opérations assure le réalisme des coûts et la continuité des processus, Juridique et Informatique fournissent les contraintes. La direction supervise la compréhension, pas le contenu : Juridique doit comprendre la traçabilité des données ; Informatique doit comprendre les conséquences juridiques. Si les deux quittent la réunion en souriant, rien n'a été décidé. Problème résiduel (explicite). Le problème de l'Option 1 ne disparaît pas. Sans une personne de niveau C consacrant du temps à une compréhension approfondie (personnellement ou via un délégué véritablement habilité), les lacunes de traduction persistent et les décisions sont bloquées. Test de maturité pour la direction. Pas de consensus, mais de la clarté : qui décide, sur quelle base, avec quelle trace probatoire, à quelle date. L'archivage, s'il est effectué correctement, n'est pas un rituel de conformité ; il définit le coût, la crédibilité et la stabilité pour la prochaine décennie.
4. Budgétisation fondée sur l'espoir, et non sur la profondeur du système
Même si les décisions sont prises et que les personnes et les intérêts sont alignés, la plupart des budgets d'archivage RE-FX s'effondrent avant le premier cycle de test. Non pas à cause d'une technologie médiocre, mais à cause d'hypothèses erronées. Les responsables pourraient tomber dans le piège d'imaginer un bref nettoyage technique après tout ce long travail de décision : allouer quelques jours de consultation, et considérer que c'est terminé. C'est alors que la réalité commence à se dévoiler. Les budgets échouent pour des raisons prévisibles. Premièrement, les effectifs : les organisations prévoient un seul consultant et finissent par avoir besoin de cinq expertises — un spécialiste RE-FX, un architecte de règles ILM, un développeur et un chef de projet capable de faire le lien entre l'entreprise et la conformité. Même les petits systèmes nécessitent l'implication précoce des utilisateurs métier et des conseillers juridiques ; l'archivage est moins un exercice technique qu'une négociation de responsabilité. Deuxièmement, la complexité du système : RE-FX peut être étroitement imbriqué dans BW, PM, MM, PS et d'innombrables tables Z et sorties. Certains contrats ou actifs « inactifs » sont liés à quelque chose qui est toujours actif. La première simulation de suppression révèle souvent une décennie de logique non documentée. Troisièmement, l'absence de marge de manœuvre : les projets prévoient des résultats idéaux et ignorent les frictions de la réalité. Les conservations légales, les revues d'audit et les corrections d'interface prennent toutes du temps. Sans marge d'erreur, chaque découverte se transforme en retard — et chaque retard en spirale des coûts. Un projet durable suit une règle simple : connaissez votre système, connaissez vos équipes, établissez un budget réaliste, prévoyez une marge de manœuvre, puis faites appel à de l'aide. L'expertise externe n'est pas un coût — c'est une assurance contre la reprise de travaux. Chaque cycle ILM productif coûte moins cher que le nettoyage d'un test raté. Planifiez en conséquence ou regardez votre « optimisation » se transformer en centre de coûts permanent.
5. Ne pas aller jusqu'au bout : le piège du projet à moitié terminé
Il n'y a rien de plus préjudiciable qu'un projet ILM à moitié terminé. Une opération de suppression mise en pause, une règle de conservation non testée ou une exception non documentée devient une dette technique avec des implications juridiques. De nombreuses organisations démarrent avec énergie, se réorientent à mi-parcours et perdent discrètement leur élan. Deux ans plus tard, un rapport couramment utilisé peut poser des problèmes parce qu'une règle de conservation a été oubliée et continue de supprimer des données. La plupart des données restent là, non archivées. Certaines données sont supprimées mais pas effacées, et finissent par être oubliées. Ce n'est pas de la gestion des risques ; c'est de l'amnésie institutionnelle. L'archivage, une fois lancé, n'a que deux issues légitimes : achevé ou jamais commencé. Tout ce qui se trouve entre les deux sape à la fois la crédibilité en matière de conformité et la confiance interne. Les auditeurs se souviennent bien plus longtemps des projets inachevés que de ceux qui ont abouti.
La règle opérationnelle est claire : planifier – aligner – exécuter. Réajuster si nécessaire, mais ne jamais reculer. Une fois la première suppression effectuée, l'histoire ne peut être réécrite. La préparation et la documentation sont aussi importantes que la configuration. Définissez votre périmètre, fixez-le, communiquez la justification. Les équipes futures ne jugeront pas ce que vous avez supprimé, mais à quel point vos décisions étaient traçables. Un projet ILM inachevé maintient les risques en vie mais perd tous ses défenseurs. Menez-le à bien une bonne fois pour toutes. Documentez-le soigneusement. Puis ne menez jamais deux fois la même bataille.
6. Conclusion : l'archivage est une stratégie, pas de la maintenance
L'archivage est rarement urgent — jusqu'à ce qu'il le devienne soudainement. Pour ces quatre erreurs, le schéma est le même : retard, délégation, sous-estimation et lassitude. Aucune n'est un échec technique ; toutes sont des défaillances de gouvernance. Les C-levels qui s'occupent directement de l'archivage sont, en partie, des pionniers. Ils opèrent dans un domaine qui n'a gagné en visibilité que récemment, mais qui définit discrètement comment les données, les coûts et la crédibilité s'aligneront pour la prochaine décennie. Bien géré, l'archivage introduit un nouveau rythme de prise de décision — des boucles d'inspection courtes, une responsabilité claire et des progrès transparents — au sein d'organisations qui ne fonctionnent généralement qu'avec de longs cycles de planification. Il devient un exercice pratique d'adaptabilité contrôlée : apprendre rapidement sans perdre d'autorité. Une fois achevé, la récompense est structurelle : des coûts stables, des audits prévisibles et un paysage informatique qui ne cache plus son propre historique. L'archivage, par essence, est la manière la plus discrète de démontrer sa maîtrise. Et la maîtrise, en matière de données d'entreprise, reste la forme la plus rare de leadership.
Avis juridique (Disclaimer) :
Ce texte ne constitue pas un conseil juridique, fiscal ou technique. Il reflète une expérience de mission. Metaneering S.à r.l. décline toute responsabilité quant à l'exhaustivité ou l'actualité.
T.H. Scheer
L'auteur n'est pas employé par ou affilié à SAP SE. Les noms de produits sont des marques de leurs détenteurs.
© Metaneering S.à r.l., Luxembourg. Tous droits réservés.
Si vous le souhaitez, un petit don à CARE Luxembourg aide des personnes dans le besoin — et nous encourage à garder ces contenus accessibles sans paywall.