Élaborer une stratégie SAP Clean Core pour les entreprises en France

Découvrez comment les entreprises SAP en France peuvent réduire leur dette technique, préserver leurs capacités métiers essentielles et bâtir une feuille de route Clean Core durable.

Avant de définir le périmètre d’une migration vers SAP S/4HANA, les responsables métiers et IT doivent disposer d’une vision claire des éléments du paysage existant à conserver. Les développements spécifiques, les intégrations et les variantes de processus doivent être examinés au regard des priorités de transformation afin de préserver les capacités essentielles sans reproduire systématiquement l’environnement actuel dans le système cible. Le séquencement est tout aussi important : certaines évolutions doivent intervenir avant la migration, d’autres pendant la mise en œuvre, et certaines seulement après la stabilisation du nouvel environnement.

Pour les entreprises opérant en France, cette trajectoire doit concilier les obligations réglementaires locales avec les priorités définies au niveau du groupe. Les équipes finance et IT, ainsi que les responsables de processus métiers, doivent distinguer les exigences qui justifient une adaptation locale des pratiques pouvant s’inscrire dans un standard commun au groupe. La continuité des opérations doit rester un critère central, au même titre qu’une évaluation réaliste des coûts et des efforts nécessaires.

Une stratégie SAP Clean Core fournit un cadre pour structurer ces décisions. Elle privilégie les fonctionnalités standard tout en définissant des principes clairs pour faire évoluer les processus métiers, les extensions, les données, les intégrations et les opérations. Cet article présente les principaux arbitrages à effectuer : déterminer ce qu’il convient de préserver ou de simplifier, organiser les évolutions en fonction des priorités métiers et maintenir cette discipline à mesure que de nouveaux besoins apparaissent.

Pourquoi le Clean Core est devenu une priorité stratégique en France

La transformation de l’ERP, les projets de conformité réglementaire et les investissements dans l’intelligence artificielle doivent être planifiés à partir d’une vision cohérente du paysage SAP. Chacune de ces initiatives mobilise des budgets, implique des responsabilités métiers et suppose de décider quelles applications et quelles données l’entreprise souhaite continuer à maintenir dans la durée.

La transformation SAP impose de réévaluer le paysage existant

La politique de maintenance de SAP fixe un horizon concret pour la planification des transformations. Pour les applications centrales concernées de SAP Business Suite 7, la maintenance standard est assurée jusqu’à fin 2027, avec la possibilité de souscrire une maintenance étendue jusqu’à fin 2030. Il s’agit d’échéances de maintenance, et non de dates auxquelles les systèmes cesseraient de fonctionner ni d’une obligation universelle de migrer.

Cette distinction doit être prise en compte au moment d’établir le budget d’une migration vers SAP S/4HANA. Les décideurs doivent examiner les conditions de maintenance applicables aux versions actuellement déployées, en parallèle du périmètre et du calendrier de transformation. Le recours à la maintenance étendue a également une incidence financière, puisqu’il entraîne un surcoût.

Le dossier d’investissement doit par ailleurs distinguer les travaux indispensables à la migration des évolutions destinées à simplifier le paysage. Les développements spécifiques, les intégrations et les variantes locales de processus doivent répondre à un besoin métier clairement identifié avant que l’entreprise décide de les maintenir dans le système cible. L’approche Clean Core fournit un cadre pour mener cette analyse en privilégiant les processus standard et les extensions qui répondent à de véritables besoins de différenciation métier.

Les projets réglementaires en France exigent des processus et des données fiables

La réforme française de la facturation électronique est entrée dans sa première phase obligatoire. Pour les entreprises concernées, le calendrier distingue l’obligation de pouvoir recevoir des factures électroniques de celles liées à leur émission ainsi qu’à la transmission des données de transaction et de paiement.

La réforme s’appuie sur des plateformes agréées pour l’échange des factures et la transmission des données requises à l’administration fiscale. Pour les entreprises utilisant SAP, le traitement des factures, le reporting et la connexion à ces plateformes font donc partie intégrante du périmètre de conformité.

La question d’architecture est dès lors très concrète : les équipes Finance peuvent-elles faire évoluer ces processus sans ajouter une nouvelle couche de logique spécifique fortement couplée au cœur du système ? Les principes du Clean Core peuvent orienter ces choix, tandis que le projet de conformité conserve ses propres contrôles, échéances et exigences de validation.

Les obligations en matière de reporting de durabilité nécessitent une analyse plus ciblée. Avant d’engager des évolutions du système d’information, les entreprises doivent d’abord déterminer précisément les exigences qui leur sont applicables, puis identifier les processus et les contrôles nécessaires pour y répondre.

Les investissements dans l’IA renforcent également les exigences en matière d’architecture

Un projet d’intelligence artificielle ne se limite pas à l’application ou au cas d’usage envisagé. Avant de valider un investissement, les directions métier et IT doivent comprendre les dépendances de ce cas d’usage au sein du paysage SAP existant.

Trois dimensions méritent une attention particulière :

• Le processus métier : définir la tâche ou la décision que l’IA doit assister et préciser qui reste responsable du résultat.
• Les informations : identifier les données et les enregistrements utilisés par la solution, puis vérifier leur qualité, les responsabilités associées et les conditions d’accès.
• Les dépendances applicatives : déterminer quelles applications SAP et non-SAP doivent intervenir et intégrer les travaux d’intégration nécessaires dans le périmètre d’investissement.

L’analyse de rentabilité doit prendre en compte ces travaux préparatoires au même titre que la solution d’IA elle-même. Les décideurs disposent ainsi d’une vision plus complète de l’effort à engager avant d’autoriser un pilote ou un déploiement à plus grande échelle.

Comment des années de personnalisations peuvent freiner l’innovation

Au fil du temps, les développements spécifiques peuvent créer des dépendances qui rendent des évolutions pourtant limitées plus difficiles à cadrer, à tester et à coordonner à l’échelle du paysage SAP. Le problème ne réside pas dans la personnalisation en elle-même, mais dans la complexité qui s’accumule lorsque la logique métier, les interfaces et les extensions deviennent fortement interdépendantes.

Des développements autrefois nécessaires peuvent perdre leur raison d’être initiale

Un développement spécifique peut avoir constitué une réponse pertinente à un besoin réel au moment de sa mise en place, qu’il s’agisse de combler une lacune fonctionnelle, de prendre en charge un service spécialisé ou de répondre à un modèle opérationnel particulier. Sa valeur métier initiale doit donc être distinguée des choix techniques retenus pour sa mise en œuvre.

Avec le temps, le contexte peut toutefois évoluer. Les processus métiers changent, les responsabilités sont redistribuées entre équipes, les applications environnantes sont remplacées et certaines fonctionnalités peuvent être dupliquées ailleurs dans le système d’information. Une solution qui répondait autrefois parfaitement au besoin peut ainsi nécessiter une réévaluation, même si elle continue de fonctionner comme prévu.

La différenciation métier et les habitudes historiques ne doivent pas être évaluées selon les mêmes critères. Un développement qui répond à un engagement contractuel n’a pas la même justification qu’une solution conservée parce qu’une équipe est habituée à son circuit d’approbation. Ni l’ancienneté ni la familiarité ne suffisent à trancher. De la même manière, un rapport, un workflow ou une interface indispensable ne doit pas être considéré comme superflu au seul motif qu’il a été développé spécifiquement pour l’entreprise.

Les dépendances élargissent le périmètre de chaque évolution

Une extension qui repose sur des objets internes SAP est exposée aux évolutions de ces objets. Lorsque l’application sous-jacente change, les équipes peuvent devoir identifier les dépendances concernées, adapter le code spécifique et vérifier que les processus connectés continuent de fonctionner comme prévu. SAP privilégie donc les extensions découplées et les interfaces publiées, qui offrent des engagements de stabilité plus clairs et limitent les dépendances inutiles.

L’impact peut dépasser largement le composant modifié. Une évolution dans un domaine peut affecter des workflows, des interfaces, des rapports ou des applications en aval qui reposent sur la même logique ou les mêmes données. Plus ces dépendances sont nombreuses, plus le périmètre à analyser et à tester s’élargit.

Exemple hypothétique : faire évoluer le processus d’approbation des commandes d’un industriel

Prenons le cas hypothétique d’un industriel français qui souhaite faire évoluer son processus d’approbation des commandes clients. Dans cet environnement, un workflow spécifique d’approbation partage une partie de sa logique avec une extension de contrôle du crédit. Une interface avec le système de gestion d’entrepôt et un portail client exploitent également le statut de commande qui en résulte.

Avant de mettre l’évolution en production, l’équipe doit donc examiner ces quatre composants. Les tests doivent couvrir les approbations, les exceptions liées au crédit, la libération des commandes pour l’entrepôt et le statut affiché aux clients. Lorsque des ajustements sont nécessaires, ils doivent être coordonnés entre les applications concernées.

Ce qui n’était au départ qu’un besoin des équipes commerciales mobilise alors des spécialistes de la finance, de la logistique et de l’intégration. Cet élargissement du périmètre résulte des dépendances autour du processus, alors même que l’évolution métier demandée reste relativement ciblée.

La dette technique devient un enjeu de pilotage

La question pour les décideurs n’est pas seulement de connaître le volume de code spécifique, mais d’évaluer l’effort nécessaire pour exploiter et faire évoluer le paysage existant. Cette analyse doit s’appuyer sur des données issues de l’environnement de l’entreprise.

Trois indicateurs sont particulièrement utiles :

• Capacité consacrée à la maintenance : suivre les efforts récurrents de support, la résolution des incidents et les travaux nécessaires pour maintenir les fonctionnalités existantes dans un état stable.
• Dépendance à des expertises clés : identifier les développements critiques dont la maîtrise repose sur un nombre limité de spécialistes et déterminer si cette dépendance affecte les délais de réalisation ou le support.
• Capacité de réalisation : comparer les délais prévus et réels pour les nouveaux travaux et mesurer la part d’effort absorbée par l’analyse, la coordination et les reprises liées aux dépendances existantes.

Le nombre d’objets spécifiques ne suffit pas, à lui seul, à évaluer la dette technique. Une modification limitée intervenant dans la libération de commandes clients peut nécessiter davantage d’attention qu’un ensemble beaucoup plus important de rapports indépendants. Ce sont avant tout l’exposition opérationnelle et l’effort de maintenance associé au code qui doivent guider l’analyse.

À quoi ressemble un paysage SAP Clean Core

SAP structure l’approche Clean Core autour de cinq dimensions : les processus métiers, l’extensibilité, les données, les intégrations et les opérations. Ensemble, elles définissent un environnement durablement maîtrisable, avec des principes clairs pour introduire et gérer les évolutions. Les capacités propres à l’entreprise peuvent continuer à faire partie de ce paysage, à condition que leur conception et leur exploitation respectent ces principes.

Des processus standard complétés par des extensions métier justifiées

Les fonctionnalités standard de SAP et les possibilités de configuration doivent être évaluées avant d’introduire une nouvelle extension. Lorsqu’un besoin métier avéré reste non couvert, il convient ensuite de choisir un mode d’extension adapté à la fois au besoin et à l’architecture cible.

Le choix dépend notamment du périmètre de l’évolution, du niveau d’interaction nécessaire avec les transactions ERP et du modèle de déploiement. SAP prend en charge l’extensibilité pour les utilisateurs clés, l’extensibilité pour les développeurs au sein de SAP S/4HANA et les applications side-by-side sur SAP Business Technology Platform (SAP BTP).

L’extensibilité pour les utilisateurs clés et l’extensibilité pour les développeurs sont toutes deux mises en œuvre au sein de l’environnement SAP S/4HANA. Déplacer systématiquement toutes les extensions vers SAP BTP ne constitue pas une exigence du Clean Core. Les possibilités disponibles varient selon le produit SAP, le modèle de déploiement, la version et le paysage applicatif. L’approche retenue doit donc être validée au regard de l’environnement cible.

Des intégrations fondées sur des interfaces prises en charge

Une architecture Clean Core privilégie des interfaces documentées et prises en charge, assorties de responsabilités clairement définies, de contrôles de sécurité et de dispositifs de supervision. Le modèle opérationnel doit également préciser les responsabilités en cas d’incident ou d’évolution tout au long du cycle de vie de chaque intégration. Les recommandations SAP en matière d’intégration associent des scénarios d’intégration standard, de la gouvernance et de la supervision de bout en bout.

Le simple fait qu’une API soit techniquement accessible ne signifie pas qu’elle soit appropriée pour une extension. SAP distingue notamment les API publiées assorties d’engagements de stabilité, certaines API classiques reconnues pour les scénarios concernés en cloud privé ou on-premise, ainsi que les dépendances à des objets internes, qui présentent un risque plus élevé en cas d’évolution. Ces différentes catégories nécessitent donc des niveaux d’analyse distincts.

Le mode d’utilisation de l’interface compte également. Une interface conçue pour traiter des transactions individuelles peut, par exemple, ne pas convenir à une réplication de données à grande échelle. Les connexions existantes doivent donc être évaluées en fonction de leur usage, de leur niveau de support, de leurs exigences de sécurité et de leurs contraintes opérationnelles. Leur ancienneté ne justifie pas, à elle seule, leur remplacement : SAP continue de reconnaître des mécanismes établis, tels que les IDoc, lorsqu’ils sont adaptés au scénario concerné.

Une gouvernance des données et des opérations au-delà du périmètre ERP

Les responsabilités liées aux données doivent rester clairement définies, quel que soit l’endroit où celles-ci sont stockées ou utilisées. Les responsables métiers doivent être clairement responsables de la signification et de la qualité des données, avec des règles définies en matière de conservation, d’archivage et de suppression dans l’ERP comme dans les applications connectées.

Les responsabilités opérationnelles doivent être précisées avec le même niveau de rigueur. Chaque application, intégration et extension doit disposer d’un responsable identifié pour la supervision, la gestion des incidents, la coordination du support et le suivi de son cycle de vie. Lorsqu’une évolution concerne plusieurs systèmes, le modèle opérationnel doit également définir la manière dont les tests et les mises en production sont coordonnés entre les différentes équipes applicatives.

Pour les entreprises opérant en France, les décisions liées au cloud doivent aussi prendre en compte la localisation des données et la répartition des responsabilités en matière de sécurité entre le client et le fournisseur. Les droits d’accès, le chiffrement, les sauvegardes, les dispositifs de reprise ainsi que les transferts internationaux de données doivent faire l’objet d’une évaluation distincte de l’architecture Clean Core elle-même.

Vous envisagez de migrer votre environnement SAP on-premise vers le cloud ?

Comparez les environnements gérés par SAP et les options proposées par les hyperscalers, explorez les principales approches de transformation SAP et découvrez les étapes à prévoir pour élaborer une feuille de route de migration.

En savoir plus

Construire une feuille de route Clean Core pragmatique

Une feuille de route Clean Core doit relier les constats issus de l’évaluation aux travaux effectivement financés, aux responsables désignés et à des échéances réalistes. Le périmètre doit être défini à partir des priorités métiers, en distinguant les évolutions indispensables à la transformation de celles qui peuvent être engagées dans un second temps.

Définir les priorités métiers et les responsabilités de décision

Commencez par les objectifs de transformation de l’entreprise, ses engagements réglementaires, ses contraintes opérationnelles et les capacités disponibles. Identifiez également les échéances que le programme devra prendre en compte, notamment les clôtures financières, les pics de production et les autres évolutions majeures du système d’information.

Désignez un sponsor exécutif et définissez une structure de décision pour le programme de transformation. Les responsables de processus métiers doivent valider les besoins et les priorités, les architectes d’entreprise approuver les choix relatifs à l’architecture cible, et la fonction Finance participer aux décisions de financement et d’investissement. Les équipes en charge de la sécurité et de la protection des données doivent être associées lorsque le périmètre concerne les droits d’accès, les données à caractère personnel ou les modalités d’hébergement.

L’objectif est que les décisions relatives aux métiers, à l’architecture, aux risques et aux investissements aient un responsable clairement identifié avant le début de la mise en œuvre.

Livrable : un périmètre validé, des critères de décision définis, des responsables identifiés et de premiers indicateurs de réussite.

Évaluer le paysage existant et confirmer ce qui reste nécessaire

Établissez un inventaire du code spécifique, des modifications, des add-ons tiers, des interfaces, des variantes de processus et des principales dépendances de données. Reliez chaque élément au processus qu’il prend en charge et aux responsables concernés. Pour les composants gérés par des éditeurs ou prestataires externes, documentez également leurs engagements de support et leurs responsabilités en matière d’adaptation.

SAP ABAP Test Cockpit (ATC) peut contribuer à l’évaluation technique en analysant le code ABAP afin d’identifier notamment les problèmes liés à l’utilisation des API, aux approches d’extension et à certaines instructions potentiellement problématiques. Les contrôles retenus doivent être adaptés aux systèmes et aux environnements de développement concernés.

Ces résultats techniques doivent être complétés par une validation métier et par des données d’usage issues de la production. Une courte période sans utilisation enregistrée ne suffit pas pour conclure qu’un développement peut être retiré. L’analyse doit couvrir les cycles métiers pertinents, y compris les activités peu fréquentes telles que la clôture annuelle. Lorsque les éléments disponibles ne permettent pas de conclure, cette incertitude doit être documentée plutôt que de classer le développement comme inutile.

Livrable : un inventaire reliant finalité métier, responsabilité, dépendances, données d’usage et constats techniques.

Décider quoi retirer, remplacer, conserver ou repenser

Traduisez les résultats de l’évaluation en une décision explicite pour chaque développement ou interface. Les catégories ci-dessous constituent un cadre pratique de planification ; elles ne correspondent pas aux niveaux de classification technique définis par SAP.

Pour chaque exception temporaire, documentez la justification, les mesures compensatoires, le responsable, ainsi que la date de réexamen. Précisez également les conditions qui doivent déclencher un remplacement ou une nouvelle évaluation. Une exception ne doit pas permettre de contourner des exigences obligatoires de compatibilité ou de conformité.

Livrable : un registre de décisions regroupant les éléments justificatifs, les actions approuvées et les exceptions documentées.

Séquencer les évolutions selon les jalons critiques pour l’activité

Priorisez les travaux en fonction de leur importance métier, du risque technique, des échéances réglementaires, de la réduction des dépendances et de l’effort de mise en œuvre. Ces critères permettent de distinguer ce qui est indispensable de ce qui peut raisonnablement être reporté.

Dans le cadre d’une migration SAP S/4HANA, la feuille de route peut être structurée autour de trois périodes :

• Avant la migration : traiter les prérequis confirmés, valider les éléments candidats au retrait et préparer les décisions de processus et d’architecture nécessaires pour définir le périmètre de mise en œuvre.
• Pendant la migration : réaliser les adaptations, les intégrations, les tests et les évolutions de processus nécessaires pour que l’environnement cible puisse être exploité de manière maîtrisée dès la mise en production.
• Après stabilisation : mettre en œuvre les améliorations approuvées qui ne conditionnent pas le démarrage du nouvel environnement, notamment certaines refontes différées, des travaux complémentaires de standardisation ou des optimisations de performance.

Le positionnement de chaque tâche dépend de l’approche de migration retenue et des prérequis techniques. Les recommandations SAP en matière de conversion prévoient également des phases de revue et d’optimisation après la conversion technique, ce qui permet d’inscrire l’amélioration dans une démarche progressive.

Pour les entités françaises, les travaux de conformité obligatoires doivent apparaître comme un chantier clairement identifié, avec leurs propres échéances et dépendances. Leur réalisation ne doit pas dépendre de l’achèvement de l’ensemble du programme de modernisation. La disponibilité des utilisateurs métiers, les capacités de test et les hypothèses budgétaires doivent également être intégrées à la planification.

Livrable : un backlog structuré par phases, avec les dépendances, les jalons, les besoins en ressources et les hypothèses de financement.

Quelle approche choisir pour votre transformation SAP S/4HANA ?

Comparez la conversion de système, la nouvelle implémentation et la transition sélective des données, ainsi que leurs implications sur les processus existants, les données historiques et les développements spécifiques.

Lire l’article

Valider l’approche à travers un pilote représentatif

Avant de généraliser une architecture, testez-la sur un pilote de développement ou d’intégration au périmètre maîtrisé. Le scénario retenu doit être suffisamment représentatif du backlog global et présenter un enjeu métier réel pour permettre une validation pertinente de l’approche.

Définissez les critères d’acceptation avant le démarrage. Évaluez la couverture fonctionnelle, les performances dans les conditions de charge attendues, la sécurité, la gestion des incidents, la supportabilité et les coûts récurrents. Associez également l’équipe qui assurera le support futur afin de valider les responsabilités opérationnelles en même temps que la solution.

Utilisez les résultats pour ajuster les standards d’architecture et les estimations de mise en œuvre. Un pilote concluant doit fournir des éléments utiles pour les travaux du même type ; des besoins sensiblement différents peuvent nécessiter une validation spécifique.

Livrable : un modèle de conception éprouvé, ses limites documentées et des éléments permettant d’éclairer les décisions d’investissement ultérieures.

Mettre en place une gouvernance qui se poursuit au-delà du projet

Une fois l’architecture cible validée, la gouvernance doit encadrer la manière dont les évolutions futures sont introduites. Définissez qui peut approuver de nouvelles extensions, qui peut autoriser des écarts par rapport aux standards d’architecture et combien de temps une exception peut rester ouverte avant d’être réexaminée.

Chaque exception approuvée doit comporter une justification documentée, un responsable, une date de révision et un plan de résolution. Les constats techniques doivent être intégrés au backlog avec une décision explicite : corriger, accepter temporairement ou faire remonter pour arbitrage.

Intégrez les contrôles techniques au cycle de développement et de mise en œuvre. SAP documente l’utilisation de contrôles ATC automatisés, de baselines pour les constats existants et d’exemptions permettant d’appliquer les standards de développement tout en traitant progressivement le code historique. Une baseline décrit la situation de départ ; elle ne signifie pas que les problèmes identifiés ont été résolus.

Le tableau de bord destiné au pilotage doit rester centré sur les dépendances à risque élevé, les exceptions non résolues, l’effort de remédiation nécessaire lors des montées de version et la maintenabilité des nouveaux développements.

Livrable : un processus de gouvernance pérenne intégrant les règles d’approbation, un registre des exceptions et une revue régulière au niveau du pilotage.

Comment le Clean Core soutient les futures initiatives SAP

Les bénéfices d’une stratégie Clean Core doivent se mesurer dans les projets qui suivent : effort nécessaire pour adopter une nouvelle version, déployer une application ou répondre à une évolution réglementaire. Ces résultats doivent être évalués en parallèle des coûts liés au maintien de la nouvelle architecture.

Des montées de version plus prévisibles et une adoption plus fluide des nouvelles fonctionnalités

Après la modernisation, l’objectif est de déterminer si les nouvelles versions sont réellement plus simples à préparer et à adopter.

Cette évolution peut être mesurée à partir de l’effort de remédiation, du temps de préparation des montées de version et du volume de tests de régression nécessaires pour des périmètres comparables. Ces indicateurs doivent être suivis dans le temps, en distinguant les travaux nécessaires pour préserver la compatibilité de ceux consacrés à l’introduction de nouvelles fonctionnalités.

La comparaison doit également tenir compte du périmètre de chaque version. Un projet plus court ne traduit pas nécessairement une amélioration s’il concerne moins de processus, d’intégrations ou d’unités opérationnelles. L’indicateur le plus pertinent consiste à déterminer si des évolutions comparables nécessitent moins de remédiation et de coordination qu’auparavant.

Une base plus claire pour l’IA et l’automatisation

La préparation de l’architecture se mesure plus concrètement lorsqu’elle est confrontée à un cas d’usage métier précis.

Exemple hypothétique : aider la Finance à traiter les factures fournisseurs bloquées

Prenons le cas d’un groupe français qui évalue un assistant d’intelligence artificielle capable de recommander des actions pour des factures bloquées en raison d’écarts de prix ou de quantité. Les équipes Finance conservent la responsabilité de l’approbation, tandis que l’IA les aide à analyser les cas d’exception.

Avant le déploiement, l’évaluation doit porter sur trois dimensions :

• Données et règles métier : rapprocher les lignes de facture des commandes d’achat, des réceptions de marchandises et des conditions fournisseurs applicables. Tester les recommandations au regard des tolérances documentées, y compris lorsque certaines informations sont manquantes ou que les devises et unités présentent des incohérences.
• Droits d’accès et responsabilités de décision : vérifier que l’assistant accède uniquement aux données autorisées pour l’utilisateur concerné. Ses recommandations doivent respecter les seuils d’approbation et ne doivent ni autoriser un paiement ni modifier des écritures comptables au-delà des droits qui lui ont été attribués.
• Interactions entre systèmes : tester les échanges entre l’assistant, l’ERP et le workflow de traitement des exceptions. Les scénarios doivent couvrir les échecs de requêtes, les mises à jour de statut et l’escalade vers un collaborateur habilité.

Les résultats opérationnels peuvent être évalués à partir du délai de résolution des exceptions, de la précision des recommandations et du volume de corrections nécessaires. La comparaison avec le processus existant permet d’intégrer dans le dossier d’investissement la valeur réelle de cette assistance dans les opérations quotidiennes.

Des évolutions réglementaires avec moins de dépendances non maîtrisées

La valeur à long terme d’un paysage correctement gouverné devient particulièrement visible lorsqu’une réglementation évolue après la mise en œuvre initiale.

L’objectif est de pouvoir retracer plus facilement les conséquences de cette évolution. Les équipes doivent être en mesure d’identifier le processus métier concerné, l’origine des données pertinentes, les règles de transformation ou la logique applicative qui les utilisent, les systèmes en aval qui les reçoivent, ainsi que les contrôles et tests à mettre à jour.

Dans le contexte de la facturation électronique en France, une modification d’un champ de reporting ou d’une exigence liée à une plateforme devrait ainsi conduire à une chaîne d’impact clairement identifiée, plutôt qu’à une analyse étendue de l’ensemble du paysage. Des responsabilités explicites et une documentation tenue à jour permettent de mieux délimiter le périmètre de l’évolution avant le début de sa mise en œuvre.

Certaines évolutions réglementaires nécessiteront malgré tout des adaptations de l’ERP, des intégrations et des applications externes. Le progrès réside dans la capacité à rendre ces dépendances visibles et testables, et non dans l’hypothèse que le changement sera techniquement simple.

Un dossier d’investissement fondé sur le coût total du cycle de vie

Évaluez le paysage cible sur une période pluriannuelle définie à l’avance. Prenez en compte la remédiation initiale, les développements d’intégration, les tests et la formation, ainsi que les coûts récurrents liés aux plateformes, à la supervision et au support applicatif. SAP BTP propose notamment des modèles de tarification basés sur la consommation, ce qui implique d’intégrer les volumes d’usage prévisionnels dans l’estimation des coûts d’exploitation.

Le déplacement de fonctionnalités hors de l’ERP doit donc être évalué comme un choix d’architecture assorti de ses propres coûts opérationnels. Comparez le coût complet de l’environnement existant avec celui de l’architecture cible, en tenant compte, le cas échéant, de la période pendant laquelle les deux doivent fonctionner en parallèle.

Ces dépenses doivent être mises en regard des évolutions réellement constatées en matière d’effort de maintenance, de gestion des incidents et de capacité à réaliser de nouvelles évolutions. Il convient de distinguer les économies budgétaires du temps ou de la capacité libérés pour d’autres travaux. Une diminution du nombre d’heures consacrées au support peut permettre à une équipe de réaliser davantage d’améliorations sans pour autant réduire son budget. Le dossier d’investissement doit refléter cette différence avec précision.

La revue de pilotage doit finalement revenir à une question centrale : quels coûts récurrents et quelles contraintes la stratégie a-t-elle réellement permis de réduire, et quelles nouvelles responsabilités a-t-elle introduites ?

Définir les données à migrer, archiver ou conserver

Toutes les données historiques n’ont pas nécessairement vocation à être migrées vers SAP S/4HANA, mais chaque catégorie doit disposer d’une destination et de modalités d’accès clairement définies.

Lire l’article

Comment LeverX accompagne les entreprises françaises dans leur stratégie Clean Core

LeverX accompagne les initiatives Clean Core à travers le conseil en architecture SAP, la mise en œuvre et les services de gestion applicative. L’intervention peut porter sur un périmètre ciblé de développements ou s’inscrire dans une transformation plus large vers SAP S/4HANA.

Évaluation et architecture

Nos consultants analysent le paysage SAP, examinent le code spécifique et passent en revue les besoins métiers avec les responsables des processus concernés. Cette démarche couvre notamment la classification des objets, les possibilités de recours aux fonctionnalités standard, la stratégie d’extension et la conception des intégrations.

Des ateliers de cadrage stratégique permettent aux parties prenantes métier et IT de s’accorder sur les priorités de modernisation ainsi que sur les principes d’architecture qui encadreront la mise en œuvre.

Transformation et mise en œuvre

Les services de mise en œuvre de LeverX couvrent la transformation vers SAP S/4HANA, le développement d’extensions et la modernisation des intégrations. Selon les besoins, les travaux peuvent inclure la refonte de développements spécifiques existants, la création d’applications sur SAP BTP ou le recours à des approches d’extension prises en charge au sein de SAP S/4HANA.

Le développement et le déploiement s’appuient sur l’architecture retenue pour le projet, sans partir du principe que chaque capacité doit être déplacée hors de l’ERP.

Optimisation continue

Après la mise en production, les services de gestion applicative de LeverX couvrent le support technique et fonctionnel, la résolution des incidents, l’optimisation des performances ainsi que la gestion des intégrations SAP et non-SAP. La planification des montées de version et la gestion des releases peuvent également être intégrées au périmètre de services convenu.

Nous aidons également à définir des règles de développement et des mécanismes de contrôle des changements, puis à les appliquer aux évolutions ultérieures. L’objectif est de maintenir un lien cohérent entre les changements apportés aux applications et la stratégie Clean Core définie dans le cadre de la transformation.

Pour un industriel disposant d’un environnement SAP ECC fortement personnalisé, LeverX a évalué les extensions existantes et redéveloppé certains objets spécifiques dans SAP BTP, ABAP environment. Les nouvelles applications sont connectées à SAP S/4HANA via des API. L’étude de cas publiée fait état d’une réduction des coûts de possession et de développement après cette refonte. Elle illustre la manière dont l’évaluation de l’existant et un redéveloppement ciblé peuvent être combinés dans le cadre d’un projet de modernisation.

Conclusion

Une stratégie Clean Core aide les entreprises à mieux hiérarchiser les domaines dans lesquels poursuivre les investissements SAP. Les capacités essentielles à l’activité peuvent justifier de nouveaux développements, tandis que les personnalisations et les dépendances qui génèrent des coûts sans apporter une valeur métier suffisante doivent être considérées comme des candidates à la simplification, à la refonte ou au retrait. L’objectif est d’orienter les budgets vers les capacités qui soutiennent les priorités actuelles, plutôt que de continuer à financer par défaut une complexité devenue difficile à justifier.

Pour les entreprises en France, un point de départ pragmatique consiste à partager une évaluation commune de la valeur métier, des risques techniques, des engagements réglementaires et des priorités de transformation. À partir de cette base, les équipes peuvent construire une trajectoire par étapes et concentrer les investissements sur les domaines où la modernisation est la plus pertinente sur les plans opérationnels et stratégiques.

Questions fréquentes