SAP GRC fin de vie: playbook de migration 2026-2031
Les dates qui comptent, ce qui change apres 2030 et le playbook de migration de 90 jours issu de 15 references enterprise signees.
La discussion sur la fin de vie de SAP GRC Access Control a changé de ton depuis 2024. Pendant des années c'était une note de bas de page — GRC 12 tient jusqu'en 2030, on s'en occupera plus tard. En 2026, c'est de plus en plus la question centrale. Les DSI, les comités d'audit interne et les centres d'excellence SAP posent la même question : que se passe-t-il concrètement après 2030, quand faut-il agir et quelles sont les options réalistes.
Ce guide est la vision d'un praticien sur la décision de fin de vie SAP GRC : les dates qui comptent, les différences pratiques entre 10.x, 11.x et 12.x, les implications pour les environnements S/4HANA, les quatre voies à suivre et le playbook de migration de 90 jours validé sur 15 références enterprise signées.
Les dates: chronologie SAP GRC fin de vie
Survolez chaque version pour voir les implications pratiques. Le repère GRC 12.0 est celui sur lequel la plupart des entreprises doivent se concentrer — la fin du support mainstream est le 31 décembre 2027 (unified GRC 12.0) et le 31 décembre 2030 pour GRC AC 12.0 sur bases de données historiques (Oracle, DB2, MSSQL).
👆 Cliquez sur n'importe quel point de la chronologie - voyez la description complète, les actions requises et l'impact sur les coûts. 2026 (votre position actuelle) est ouvert par défaut.
Deux observations pratiques à partir de ces dates. Premièrement, les organisations sur GRC 10.x ou 11.x en 2026 sont déjà au-delà du mainstream — elles paient un support étendu ou acceptent le risque. Deuxièmement, les clients GRC 12.0 sur Oracle/DB2/MSSQL disposent de 3 ans supplémentaires par rapport aux clients HANA — mais ce temps est souvent consacré à la migration S/4HANA (qui nécessite HANA), il n'est donc pas gratuit.
Ce qui change réellement après 2027 pour GRC 12.0
La nomenclature de fin de vie SAP est précise mais pas dramatique. Après la fin de la maintenance mainstream, plusieurs choses se dégradent simultanément : pas de nouvelles fonctionnalités, pas de patches de sécurité sauf critiques, support technique limité, pas de certification pour les nouvelles versions de navigateurs/OS. La plateforme continue de fonctionner, mais chaque année augmente les coûts de maintenance et le risque d'audit.
- Aucune nouvelle fonctionnalité. Le produit est figé dans son état de 2030. Aucun nouveau support de module SAP, aucun ajout d'agent IA, aucune amélioration de l'UI ou de l'analytique.
- Aucun patch pour les bugs non critiques. Les défauts fonctionnels qui apparaissent après 2030 ne sont pas corrigés. Les contournements deviennent la norme opérationnelle.
- Patches de sécurité progressivement réduits. SAP s'engage aux mises à jour de sécurité pendant la maintenance étendue (jusqu'en 2033 avec Enterprise Support), mais la priorité se déplace vers les successeurs cloud-native. Les patches pour les CVE moins critiques peuvent prendre plus de temps.
- Aucun support pour les nouvelles intégrations. Lorsque SAP lance de nouvelles fonctionnalités S/4HANA Cloud, des services BTP ou des capacités d'IA métier, la charge d'intégration retombe sur les clients. GRC 12 a été conçu pour l'ensemble de fonctionnalités S/4HANA de 2020-2023, pas pour le paysage 2030+.
- L'examen des auditeurs externes s'intensifie. Les auditeurs Big 4 (EY, KPMG, Deloitte, PwC) signalent les organisations fonctionnant sur des plateformes post-mainstream dans leurs constats ITGC. La formule « nous sommes sur un logiciel supporté » devient plus difficile à écrire chaque année.
La plateforme ne "s'arrete pas de fonctionner" le 31 decembre 2030 - elle devient progressivement plus couteuse et risquee a exploiter. La plupart des entreprises qui ont vecu des cycles de fin de vie similaires de produits SAP (ECC 6.0 a la meme date mainstream 2030) traitent l'annee EOL comme annee de decision, pas comme annee de migration. La migration se deroule dans les 18-24 mois precedant la date EOL.
L'implication S/4HANA
Le signal le plus fort dans la discussion sur la fin de vie SAP GRC est la feuille de route de modernisation. La direction stratégique de SAP pour la gouvernance, les risques et la conformité est Cloud Identity Access Governance (Cloud IAG) — pas GRC 12.0. C'est un signal d'investissement : le développement produit, les intégrations Joule (IA), l'UX Fiori et la fondation S/4HANA vont vers Cloud IAG. GRC 2026 reçoit de la maintenance, pas d'investissements.
Pour les organisations sur S/4HANA — ou celles qui envisagent la transition — cela crée une question de planification indépendante de la date de fin de vie. La feuille de route S/4HANA (public et private cloud) suppose de plus en plus Cloud IAG comme couche native de gouvernance des accès. Continuer avec GRC 12.0 sur S/4HANA est techniquement possible, mais stratégiquement à contre-courant de la direction SAP.
That decision typically narrows to three options.
GRC 2026: ce qu'est réellement le successeur
La confusion autour de la fin de vie SAP GRC vient principalement du langage. La position officielle de SAP, articulée dans la déclaration No Customers Left Behind (début 2026), est que les solutions SAP GRC ne sont PAS en fin de vie — la version 2026 est une nouvelle version du produit existant, livrée par la maintenance standard. En pratique cependant, la version 2026 change suffisamment sur le plan architectural pour que la plupart des clients décrivent la transition comme une migration, pas comme une mise à niveau. Survolez chaque section ci-dessous pour voir ce qui change réellement.
Ce qui change : Access Control, Process Control, Risk Management, Audit Management, Business Integrity Screening, Tax Compliance, UIDP Masking et UIDP Logging se consolident dans SAPGRC — un produit, un modèle de licence, une plateforme d'administration.
Impact : Analyse de risque cross-module en temps réel (fin des délais de sync DB). Une seule SKU vendor au lieu de 8.
Ce qui change : NetWeaver Business Client (NWBC) et les écrans WebDynpro sont retirés. Tous les workflows, approbations, tableaux de bord et revues firefighter fonctionnent via SAP Fiori 2.0 (responsive, tuiles basées sur les rôles, mobile).
Impact : Les approbateurs obtiennent un accès mobile. Fin du risque de compatibilité navigateur (WebDynpro se casse avec les mises à jour Chrome).
Ce qui change : Les utilisateurs demandent l'accès en langage naturel (Donne-moi un accès en lecture au vendor master pour l'Allemagne). Joule vérifie automatiquement les conflits SoD, suggère les approbations et rédige les justifications pour firefighter.
Impact : Supprime 40% de la charge de travail de revue manuelle — mais nécessite une licence SAP HANA Cloud AI.
Ce qui change : L'analyse SoD s'exécute en mémoire HANA — millisecondes au lieu de batches nocturnes. L'analytique d'utilisation des rôles utilise HANA Predictive Analytics Library (PAL) pour des recommandations de cleanup basées sur le ML.
Impact : Le taux de faux positifs baisse d'environ 40%. Mais : nécessite la migration HANA DB (Oracle/MSSQL/DB2 doivent d'abord migrer, souvent 48-72h de downtime).
What changes: GRC 2026 runs on S/4HANA Foundation 2025 (technical shell of S/4HANA without full ERP functional scope). Two deployment options: Embedded (inside your S/4 ERP) or Hub (standalone governing multiple ERPs).
Impact : Nouveaux plug-ins requis (GRCPIBAS, GRCPIS4, UISAPGRC). Tous les systèmes satellites ont besoin de mises à jour. Aucune nouvelle SKU de licence sous la maintenance standard.
Ce qui change : La maintenance mainstream s'aligne sur le cycle de vie SAP HANA et S/4HANA — jusqu'en 2040. Extended maintenance probablement jusqu'en 2043-2045.
Impact : Aucune migration forcée avant le début des années 2040. Comparez avec rester sur GRC 12.0 avec extended maintenance jusqu'en 2033 — vous faites face à la même décision à nouveau mais avec un logiciel plus ancien et une complexité accrue.
No Customers Left Behind — la déclaration stratégique SAPinsider, textuellement :
- →SAP Access Control and GRC solutions for SAP are NOT end-of-life.
- →SAP GRC 2026 is a new version, not a new product for any GRC-on-HANA customer.
- →Existing GRC-on-HANA customers upgrade as part of standard maintenance - no new SKU required.
- →Les clients sur GRC « classique » (Oracle/MSSQL/DB2) doivent migrer vers la nouvelle version on-premise ou private cloud 2026.
- →End-of-maintenance dates align with HANA EOM: support extended through 2040.
Ce que cela signifie en pratique:
Si vous êtes sur GRC-on-HANA, la mise à niveau 2026 est administrativement simple mais architecturalement significative (Fiori uniquement, nouveaux plug-ins, licence AI Joule). Si vous êtes sur GRC 12.0 avec une base de données ancienne, vous faites face à deux migrations empilées : d'abord la migration HANA DB, ensuite la mise à niveau GRC 2026. Les données du secteur suggèrent que la plupart des entreprises commencent à évaluer les plateformes alternatives précisément à ce point de décision — il est souvent moins cher et plus rapide de remplacer que de migrer deux fois.
La question suivante — quelles sont les quatre voies pratiques a suivre — est ce a quoi la plupart des DSI veulent reellement consacrer la reunion.
Les quatre voies à suivre
Voie 1: SAP Cloud IAG (le successeur natif SAP)
Le successeur prévu par SAP à GRC AC. Tarification par abonnement, cloud-native, intégré au reste de la pile SAP cloud. Prix ~30-80 k EUR/an selon le nombre d'utilisateurs et de modules. Les clients rapportent 3-6 mois de déploiement dans les environnements SAP-first. Bon ajustement pour les organisations déjà sur SAP BTP.
La bonne réponse pour : les organisations entièrement engagées dans la pile SAP cloud, les environnements de taille moyenne sans exigences SoD complexes, les clients SAP BTP ayant accès à Joule AI.
Voie 2: Plateforme GRC alternative (smartGRC, Pathlock, Saviynt, SailPoint)
Les plateformes de remplacement qui gèrent la gouvernance des accès pour SAP — et de plus en plus pour non-SAP — à une fraction du prix de SAP GRC AC. smartGRC, Pathlock, Saviynt, SailPoint dans cette catégorie. Elles diffèrent par leur architecture, leur focus (SAP-first vs identity-first), leur région d'hébergement et leur modèle tarifaire. Le TCO 3 ans est généralement 60-85% inférieur à SAP GRC AC.
La bonne réponse pour : les organisations dont les besoins en gouvernance des accès dépassent ce que couvre Cloud IAG, les clients qui valorisent un TCO 70-85% inférieur, les organisations avec des systèmes non-SAP significatifs dans le périmètre (30-70% du risque d'accès), les entreprises privilégiant la résidence des données en UE.
En 2026, la plateforme smartGRC a ajouté smartSecurity — un module de surveillance de la sécurité SAP par agents IA qui évalue en continu la configuration SAP par rapport aux référentiels (SBT, SAP Default, personnalisés), suit le statut des patchs Security Notes, détecte les autorisations critiques (SAP_ALL, S_A.SYSTEM) et mappe automatiquement chaque écart aux contrôles NIS2, ISO 27001, RGPD et DORA — comblant la lacune que SAP GRC AC n'a jamais couverte.
Voie 3: Support étendu / Custom Support
Achetez 1 à 3 ans de support SAP supplémentaire au-delà de la date mainstream tout en planifiant correctement la migration. SAP propose Extended Support et Custom Support. Les coûts augmentent de manière exponentielle : première année ~2x le prix normal de maintenance, deuxième ~4x, troisième ~6x. C'est une assurance temporelle payante, pas une stratégie à long terme.
La bonne réponse pour : les organisations qui ont réellement besoin d'1 à 2 ans supplémentaires avant de pouvoir exécuter une migration (par ex. pendant une transformation S/4HANA, après une M&A récente, projet IPO en cours). Pas une stratégie — un billet de temps pour faire autre chose.
Voie 4: "Ne rien faire et accepter le risque"
Techniquement possible, de moins en moins attrayant. Après la fin de vie mainstream, la plateforme continue de fonctionner, mais chaque année augmente : coûts de maintenance (spécialistes qui connaissent l'ancienne plateforme), risque de conformité (patches de sécurité, incompatibilité navigateur/OS), risque d'audit (comment expliquer à l'auditeur l'utilisation d'un logiciel en fin de vie). Le support étendu coûte plus cher que la migration — c'est pourquoi les migrations se déroulent généralement dans les temps.
Le playbook de migration en 90 jours
Le calendrier suivant est ce que nous avons vu fonctionner dans 15 references enterprise migrant de SAP GRC AC vers smartGRC. Les memes phases s'appliquent si vous migrez vers Cloud IAG ou une autre alternative — la difference reside dans les outils utilises entre les jours 15-60, pas dans la structure.
Semaines 1-3: Extraction des données
Extraction depuis SAP GRC AC : règles de risque d'accès SOD et catalogue d'accès critiques (GRAC SOD), contrôles d'atténuation (GRAC_MC), matrice des rôles (GRAC BRM), demandes d'accès historiques (GRAC ARM), sessions FF (GRAC EAM 6 derniers mois). Format de sortie : CSV + XML. Timing : 2-3 semaines.
Semaines 3-5: Ingestion du catalogue de risques
Chargez les règles de risque extraites dans la plateforme cible. Sur smartGRC, cela est automatisé (l'agent de mappage IA gère ~85% des mappages règles SOD vers transactions SAP), le reste est vérifié par un consultant. Résultat : un rulebook de 100-150 règles SoD prêt à être exécuté.
Semaines 5-7: Cycle pilote de revue SoD
Exécutez une seule unité commerciale à travers une revue SoD complète sur la nouvelle plateforme en parallèle de la revue existante SAP GRC AC. Objectif : résultats identiques quant au nombre de conflits SoD ; les différences = lacunes dans le rulebook à corriger. Timing : 2 semaines calendaires. Pour une description complète de la méthodologie de revue SoD, consultez notre guide complet de la Séparation des Tâches SAP.
Semaines 7-9: Exécution parallèle
Étendez au périmètre de production complet mais gardez SAP GRC AC comme système de référence. Chaque demande d'accès passe par les deux. Comparaison des résultats = validation finale du rulebook + confirmation que la nouvelle plateforme couvre tous les cas d'usage. Timing : 4-6 semaines.
Semaines 9-12: Basculement et déclassement
Basculez le système de référence vers la nouvelle plateforme. Gardez SAP GRC AC en lecture seule pendant 6 mois comme référence d'audit. Mise hors service de SAP GRC AC après le premier cycle d'audit réussi sur la nouvelle plateforme. Timing de bascule : 1 semaine + 6 mois de lecture seule.
Le cadre de décision zéro risque
L'industrie de la migration vend engagement d'abord, validation ensuite — signer un contrat, démarrer un projet, découvrir à mi-parcours que la plateforme ne convient pas à votre environnement. GRC Advisory vend l'inverse : une exécution parallèle de 90 jours avec périmètre limité + plateforme smartGRC. Le client voit des résultats identiques sur les deux systèmes avant de décider de la migration complète.
- • 150-200 jours-consultant à 700-800 EUR/jour
- • Migration HANA DB (48-72h de downtime pour 500 Go+)
- • S/4HANA Foundation 2025 en prérequis
- • Nouveaux plug-ins sur tous les satellites (GRCPIBAS, GRCPIS4, UISAPGRC)
- • Déploiement Fiori launchpad + reformation des utilisateurs
- • Cycle complet de tests de régression (3 rondes)
Plus: ongoing SAP GRC maintenance fees continue during and after upgrade.
- ✓ Les consultants GRC Advisory migrent les données (15 ans d'expérience SAP GRC)
- ✓ Les deux systèmes fonctionnent en parallèle pendant 90 jours
- ✓ Rapprochement hebdomadaire des sorties SoD
- ✓ Aucune perturbation de la production SAP GRC
- ✓ Point de décision après rapprochement — migrer ou rester
- ✓ Abonnement smartGRC à partir de 15 k EUR/an (après décision)
Plus: once you commit, SAP GRC maintenance fee stops.
Pourquoi les 15 ans d'expérience de GRC Advisory comptent
La raison pour laquelle le calendrier de 90 jours fonctionne n'est pas le logiciel — c'est l'expertise en migration. GRC Advisory implémente SAP GRC depuis 15 ans et est partenaire officiel SAP Service. Nous connaissons par cœur la structure interne de GRAC SOD et les pièges typiques de migration. Cela raccourcit la phase de découverte qui domine les projets avec les intégrateurs génériques.
Tous les modules et jeux de données n'ont pas besoin de migrer. La plupart des clients n'ont pas besoin d'une réimplémentation complète 1:1 de chaque objet historique — beaucoup de données SAP GRC sont dormantes (campagnes UAR clôturées de 2019, tickets de provisioning archivés, sessions firefighter expirées) et n'ont aucune importance opérationnelle pour le travail quotidien.
Cela transforme ce qui serait un projet de découverte + migration de 6-12 mois avec un partenaire d'implémentation générique en une exécution parallèle de 90 jours avec GRC Advisory. La différence réside dans les outils aux jours 15-60 (pas dans l'effort), plus dans les mappages pilotés par IA et la bibliothèque d'expérience de 15 migrations SAP GRC AC précédentes.
Le point de décision à la semaine 12
À la fin de l'exécution parallèle de 90 jours, le comité exécutif voit trois artefacts :
- Reconciliation report — every SoD conflict flagged by SAP GRC AC in the last 90 days, mapped against smartGRC's output on the same access base. Match rate is typically 96-98% at this point; the remaining discrepancies are documented rule interpretation differences, not bugs.
- Firefighter log review comparison — the same production sessions reviewed by both platforms. smartGRC's AI agent flags anomalies that the standard SAP GRC session-by-session review does not catch (this is the "Firefighter AI vs Human 6:0" case study in operation).
- 5-year TCO comparison — Mise à niveau SAP GRC 2026 + ongoing maintenance vs smartGRC subscription. For mid-market estates (400-600 SAP users), the delta is typically €400-600k over 5 years in favour of smartGRC.
Trois résultats sont possibles : (a) le client migre — SAP GRC AC passe en read-only, puis décommissionnement, le contrat de maintenance SAP se termine au renouvellement, (b) le client reste sur SAP GRC — pas de vendor lock-in, pas de pénalité, nous avons parcouru le processus avec lui, ou (c) hybride — smartGRC gouverne le nouveau périmètre S/4HANA tandis que SAP GRC gouverne l'estate ECC legacy. L'option (c) est inhabituelle mais s'est produite deux fois dans notre base de références.
Ce que le comité d'audit veut vraiment entendre
La discussion au comite d'audit sur la fin de vie de SAP GRC porte rarement sur la technologie. Elle porte sur trois questions. Premierement, existe-t-il un plan signe avec une date? — une decision "nous evaluons les options" est inacceptable apres 2027. Deuxiemement, qui porte le risque de migration? — le directeur financier, le DSI, le RSSI ou le responsable de l'audit interne. Troisiemement, quel est le plan de repli si la migration prend du retard? L'extended support est le plan de repli standard; le fait qu'il coute plus cher que la migration elle-meme est precisement pourquoi la migration se deroule generalement dans les delais.
La position la plus forte pour aborder cette réunion : une décision signée sur la plateforme cible, un sponsor exécutif nommé, un proof-of-concept de 90 jours planifié et un fallback Extended Support documenté au cas où le POC trouverait un bloqueur. Tout le reste, ce sont des détails de processus.
Questions fréquemment posées
Quand SAP GRC atteint-il la fin de vie ? expand_more
Le mainstream maintenance de SAP GRC 12.0 a été prolongé jusqu'au 31 décembre 2030 (aligné sur SAP ECC 6.0). L'Extended Maintenance continue jusqu'au 31 décembre 2033 pour les organisations sous contrat Enterprise Support. Après 2030/2033 — aucune nouvelle fonctionnalité, aucune correction pour les bugs non critiques et des patches de sécurité progressivement réduits. La fin de vie pratique pour un usage critique en production est décembre 2030 — au-delà, les risques réglementaires et d'audit augmentent fortement.
Quelle est la différence entre la fin de vie de SAP GRC 10.x et 12.x ? expand_more
Le mainstream maintenance de SAP GRC 10.0/10.1 a pris fin le 31 décembre 2020. L'Extended Maintenance a pris fin le 31 décembre 2024. SAP GRC 11.0 a atteint sa fin de vie mainstream en 2024. Seul GRC 12.0 bénéficie d'un support jusqu'en 2030/2033. Les clients sur 10.x ou 11.0 fonctionnent déjà sans support — les auditeurs externes peuvent le signaler comme material weakness lors du prochain cycle de contrôle.
SAP GRC fonctionnera-t-il sur S/4HANA après 2030 ? expand_more
SAP GRC 12.0 est pris en charge sur S/4HANA jusqu'aux mêmes échéances 2030/2033. Cependant, la roadmap de modernisation SAP se déplace vers Identity Authentication Service (IAS), Identity Provisioning Service (IPS) et Cloud Identity Access Governance (Cloud IAG). À long terme, GRC 2026 (le successeur on-premise) ne fonctionnera que sur S/4HANA Foundation 2025 avec HANA DB. Les clients sur bases de données legacy (Oracle, MSSQL, DB2) devront migrer vers HANA avant de passer à GRC 2026.
Quelles sont les options après la fin de vie de SAP GRC ? expand_more
Trois voies réalistes. (1) Migration vers SAP Cloud IAG — le successeur SAP-native, tarification par abonnement, portée fonctionnelle plus étroite que GRC AC on-prem, recommandé pour les organisations entièrement engagées sur le cloud SAP. (2) Upgrade vers SAP GRC 2026 sur HANA — suite unifiée complète, nécessite une migration DB HANA, coût 155-240k EUR. (3) Migration vers une plateforme alternative : smartGRC (produit polonais, ISO 27001), Pathlock, Saviynt, SailPoint — portée SAP-native plus étroite mais TCO inférieur et mise en œuvre plus rapide.
Combien de temps dure une migration EOL SAP GRC ? expand_more
Migration standard mid-market : 90 jours entre la signature du contrat et le cutover en production. Migrations enterprise (10K+ utilisateurs, paysages multi-systèmes) : 4-6 mois. Chemins critiques : extraction du catalogue de risques et des matrices de rôles (semaines 1-3), configuration de la plateforme cible et mapping des rôles (semaines 4-8), parallel run avec GRC legacy (semaines 9-11), cutover et décommissionnement (semaine 12). Expérience GRC Advisory : 15 références enterprise signées, toutes dans la fenêtre de 90 jours.
Que deviennent les données historiques SAP GRC ? expand_more
Trois options. (1) Archive : accès en lecture seule à la base GRC pour la période de rétention réglementaire (typiquement 7-10 ans pour SOX, 6 ans pour les enregistrements financiers RGPD). (2) Migration : import du catalogue de risques, des matrices de rôles, des logs d'approbation des mitigations et de l'historique des access reviews vers la plateforme cible — ~2-4 semaines avec le toolkit ETL GRC Advisory. (3) Hybride : données transactionnelles archivées, données de référence (contrôles, risques, rôles) migrées vers la nouvelle plateforme. Recommandation : migrer toujours le catalogue de contrôles/risques, archiver les exécutions de tests et les logs d'audit.
Quel est le coût d'une migration EOL SAP GRC ? expand_more
Pour un paysage SAP mid-market de 1000 utilisateurs : coût de migration typiquement 30-80K EUR (consulting + parallel run + formation), selon la complexité des données. Nouvelle plateforme : SAP Cloud IAG coûte ~100-200K EUR/an d'abonnement, upgrade SAP GRC 2026 — 155-240k EUR une fois. smartGRC — 35-60K EUR licence une fois + 25K EUR/an maintenance. Surcoût Extended Maintenance après 2027 : +20% de la maintenance annuelle — exemple concret : 200k EUR maintenance → +40k EUR/an. Ce que vous ne planifiez pas, vous le payez.
Prêt pour 90 jours d'exécution parallèle?
Les consultants GRC Advisory gèrent la migration des données. Vous gardez SAP GRC en fonctionnement pendant le cycle de réconciliation. Décision en semaine 12 — pas de vendor lock-in tant que vous n'avez pas validé le résultat.