Les entreprises françaises ont développé du code spécifique dans SAP pour répondre aux exigences locales et préserver certains processus métiers. Avec le temps, l’accumulation de ces développements complique les montées de version, alourdit la maintenance et ralentit les évolutions. L’enjeu consiste à identifier les développements les plus contraignants et à moderniser les fonctions essentielles dans une démarche Clean Core.
Lors des premiers déploiements de SAP, notamment dans les années 1990 et 2000, adapter l’ERP permettait aux entreprises de préserver des processus qu’elles considéraient comme un avantage concurrentiel. Ces choix répondaient à des besoins concrets. Au fil des projets, l’accumulation de développements spécifiques a toutefois créé une dette technique importante.
La démarche Clean Core vise à limiter les dépendances au code standard SAP tout en conservant les fonctionnalités utiles à l’entreprise. Elle permet ainsi de mieux maîtriser la maintenance et les évolutions de l’ERP.
Pourquoi les développements spécifiques se sont accumulés dans les systèmes SAP des entreprises françaises
|
Des exigences réglementaires nécessitant des adaptations locales |
La volonté de préserver les pratiques de l’entreprise |
Des environnements sur site favorisant le développement spécifique |
Des acquisitions multipliant les besoins d’intégration |
Le développement sur mesure devenu une réponse habituelle |
|
Les premiers déploiements internationaux d’ERP ne couvraient pas toujours l’ensemble des besoins locaux. Les équipes ont donc ajouté des règles de calcul, des champs, des circuits de validation et des états spécifiques. Les évolutions réglementaires ont ensuite nécessité de nouvelles adaptations. |
Les entreprises adaptaient SAP pour conserver des processus qu’elles jugeaient essentiels à leur activité. Cette volonté de préserver « le spécifique » s’est traduite par la création de circuits de traitement, d’états et d’interfaces propres à chaque organisation. |
Les systèmes SAP sur site, ou on-premises, permettaient d’ajouter des programmes ABAP, des extensions et des tables spécifiques directement dans l’ERP. Au fil des demandes, le code lié à cet environnement s’est accumulé. |
Les acquisitions ont introduit de nouvelles applications devant échanger des données avec SAP. Des interfaces spécifiques, des transferts de fichiers et des traitements par lots ont permis de les connecter sans remplacer les systèmes des entités acquises. |
Les éditeurs et les intégrateurs pouvaient répondre aux nouvelles demandes par des développements sur mesure. À mesure que cette approche devenait courante, chaque projet ajoutait du code dont il fallait ensuite assurer la maintenance. |
Cinq signes d’un excès de développements spécifiques dans votre environnement SAP
L’accumulation de développements spécifiques se manifeste souvent dans le fonctionnement quotidien. Les cinq situations suivantes permettent d’en repérer les effets sur les processus métiers et sur la capacité de la DSI à faire évoluer le système.
1. Le code spécifique retarde les montées de version SAP
Avant de tester une nouvelle version, les développeurs doivent examiner les extensions qui dépendent d’objets standard modifiés par SAP. Ils adaptent les programmes concernés, puis relancent les tests de non-régression sur les processus associés.
Lorsque ces travaux ajoutent plusieurs semaines, voire plusieurs mois, à chaque montée de version, les dépendances entre le code spécifique et le standard SAP deviennent un frein majeur.
2. Les traitements spécifiques allongent la clôture comptable
Les états spécifiques, notamment les rapports Z, et les traitements par lots peuvent prendre sensiblement plus de temps à mesure que les volumes de transactions augmentent. Les équipes financières doivent attendre leur fin pour effectuer les rapprochements.
Pendant ces périodes de forte activité, les autres utilisateurs peuvent également constater un allongement des temps de réponse dans SAP.
3. Les utilisateurs finalisent leurs opérations dans des tableurs
Les contournements manuels commencent souvent par un décalage précis entre le système et les besoins. Un écran spécifique de gestion des commandes peut, par exemple, ne plus correspondre au circuit de validation en vigueur. Un utilisateur exporte alors les données, réalise les étapes manquantes dans un tableur, puis reporte les valeurs validées dans SAP.
L’ERP enregistre ainsi le résultat de la transaction sans conserver l’historique complet des modifications et des décisions qui y ont conduit. Lors d’un audit ou d’une analyse d’erreur, les équipes doivent reconstituer cet historique à partir de fichiers et de messages. La ressaisie augmente aussi le risque d’introduire des données erronées ou obsolètes.
4. La maintenance mobilise l’essentiel des ressources de la DSI
Les équipes informatiques consacrent la majeure partie de leur temps à réparer des interfaces défaillantes et à maintenir des objets spécifiques vieillissants. Lorsque ces tâches absorbent également l’essentiel du budget SAP, les projets d’amélioration sont reportés.
Chaque modification insuffisamment maîtrisée ajoute des dépendances qu’il faudra maintenir et tester lors des prochaines mises à jour, ce qui alourdit encore les coûts.
5. L’intégration de nouvelles entités exige toujours plus d’adaptations
Les nouveaux modèles économiques, les acquisitions et les déploiements dans plusieurs entités révèlent souvent les limites d’un environnement SAP fortement personnalisé.
Le code existant peut avoir été conçu uniquement pour l’organisation d’origine. Les équipes doivent alors créer de nouveaux contournements à chaque évolution. Les développements et les tests supplémentaires retardent les mises en production et augmentent le coût de l’expansion des activités.
Comment les entreprises françaises font évoluer leur approche des développements spécifiques SAP
Les choix de développement influencent la capacité d’une entreprise à adapter SAP à une évolution réglementaire ou à l’intégration d’une nouvelle société. Le tableau ci-dessous présente les pratiques qui permettent de mieux maîtriser ces changements.
|
Domaine |
Pratiques historiques |
Orientation actuelle |
Intérêt pour l’entreprise |
|
Conception des processus |
Adapter SAP aux pratiques internes, y compris à des habitudes sans justification réglementaire ni avantage concurrentiel identifié. |
Privilégier les processus standard SAP pour les activités courantes. Conserver les règles spécifiques lorsqu’une obligation réglementaire ou une justification économique documentée le nécessite. |
Réduire le nombre de variantes pour alléger la maintenance et simplifier les déploiements dans les différentes entités. |
|
Code spécifique existant |
Reconduire les objets spécifiques d’une version à l’autre, faute de visibilité sur leur usage et leurs responsables. Certains faisaient doublon avec des fonctions ajoutées au standard SAP. |
Analyser les données d’utilisation et confirmer l’utilité de chaque développement avec les métiers. Retirer les objets inutilisés et remplacer les doublons par les fonctionnalités SAP disponibles. |
Cesser de financer la maintenance et les tests de non-régression de code devenu inutile. |
|
Nouvelles demandes de développement |
Respecter les délais du projet, avec une prise en compte limitée des coûts de maintenance et des conséquences sur les montées de version. |
Faire examiner chaque demande conjointement par les métiers et la DSI. Exiger un responsable désigné, un objectif précis et une estimation des coûts de maintenance et de support. |
Écarter plus tôt les demandes à faible valeur ajoutée et définir les responsabilités pour les développements retenus. |
|
Innovation répondant à des besoins propres à l’entreprise |
Développer les nouvelles applications et intégrations directement dans le cœur ERP, selon les pratiques déjà établies. |
S’appuyer sur SAP Business Technology Platform (SAP BTP) ou sur d’autres modèles d’extension pris en charge par SAP. |
Limiter les adaptations lors des montées de version et faire évoluer les nouvelles fonctionnalités selon un calendrier distinct. |
|
Acquisitions et déploiements dans les entités |
Ajouter à chaque déploiement de nouveaux états, interfaces et règles de validation propres à l’entité. |
Partir d’un modèle de processus commun au groupe. Justifier les adaptations locales par une exigence réglementaire ou un besoin opérationnel. |
Réduire les développements nécessaires avant la mise en production d’une nouvelle entité. |
Où placer la logique métier spécifique dans l’architecture SAP ?
Dans une démarche Clean Core, les règles propres à l’entreprise conservent leur place dans le système d’information. Leur emplacement dépend de leur rôle dans les processus, de leurs besoins d’intégration et de leur rythme d’évolution. Plusieurs approches peuvent se compléter.
Les fonctionnalités standard au cœur de SAP
Les écritures comptables, les mouvements de stock, la gestion des données de référence et les contrôles réglementaires doivent s’appuyer sur le standard SAP dès lors que celui-ci couvre les besoins. Ces opérations restent ainsi soumises aux règles de validation, d’habilitation et de traçabilité définies dans l’ERP.
|
Avantages |
Points de vigilance |
|
SAP maintient ces fonctionnalités au fil des versions et fournit des mises à jour pour les exigences locales prises en charge. |
Lorsque le standard ne répond pas à une exigence réglementaire ou métier documentée, les utilisateurs risquent de recourir à des tableurs ou à des corrections manuelles. |
Les extensions on-stack compatibles avec le Clean Core
Certains besoins doivent être traités au sein d’une même transaction SAP, alors que le paramétrage standard ne suffit pas. Selon la version et l’édition utilisées, SAP propose des points d’extension officiellement publiés pour ajouter un champ, un contrôle ou un calcul à l’aide des outils destinés aux utilisateurs clés, ou d’ABAP Cloud. Le développement reste dans SAP S/4HANA, sans modification des objets standard.
|
Avantages |
Points de vigilance |
|
Les utilisateurs restent dans le même processus, avec les données et les habilitations de SAP. L’utilisation de points d’extension publiés limite les adaptations nécessaires après une montée de version. |
Une extension initialement limitée peut s’enrichir au fil des demandes. Des changements fréquents élargissent alors le périmètre des tests dans SAP. Les accès directs aux tables internes ou les dépendances à des objets SAP non publiés pour cet usage peuvent également créer des incompatibilités lors des mises à jour. |
Les extensions side-by-side sur SAP BTP
La logique utilisée par plusieurs applications, ou qui doit évoluer selon son propre calendrier, peut être déployée dans une extension side-by-side sur SAP BTP. Celle-ci communique avec SAP S/4HANA par des API officiellement publiées et prises en charge par SAP. L’ERP valide et enregistre la transaction, tandis que l’extension exécute les fonctions propres à l’entreprise.
|
Avantages |
Points de vigilance |
|
L’extension s’exécute hors du cœur SAP et peut évoluer indépendamment. Plusieurs applications peuvent utiliser les mêmes règles métier, ce qui limite les développements en doublon. SAP BTP permet de choisir entre des outils low-code et un développement classique selon la complexité du besoin. |
La réplication de volumes importants de données impose de gérer leur synchronisation et peut conduire l’extension à utiliser des données obsolètes. Une succession d’appels API en temps réel rend le processus sensible aux latences et aux indisponibilités. La responsabilité de chaque interface et la gestion de ses versions doivent être clairement définies pour éviter l’utilisation de versions d’interface incompatibles ou qui ne sont plus prises en charge. Lorsque des données personnelles sont traitées, la conception doit aussi intégrer les exigences du RGPD, notamment la minimisation des données et la limitation des accès aux personnes habilitées. |
Les extensions fondées sur les événements métier
Une fois une opération enregistrée dans SAP, le système peut publier un événement métier via SAP Event Mesh. Une application abonnée reçoit cet événement et déclenche son propre traitement, indépendamment de la transaction d’origine.
Ce modèle convient, par exemple, à une notification ou à une mise à jour de données après la modification d’une commande, d’une facture ou d’une fiche de données de référence.
|
Avantages |
Points de vigilance |
|
La transaction SAP n’attend pas l’exécution des traitements complémentaires par les autres applications. Une nouvelle application peut s’abonner au même événement sans modifier le processus SAP qui l’émet. |
Les événements peuvent arriver en retard, être reçus plusieurs fois ou dans un ordre différent de celui de leur émission. L’application destinataire doit gérer les doublons et permettre la reprise des traitements en échec. La supervision permet de vérifier que les actions attendues ont bien été exécutées. Ce modèle ne convient pas à une règle devant autoriser ou bloquer la transaction initiale, puisque l’événement intervient après son enregistrement. |
Les agents IA en complément de la couche transactionnelle
Les agents d’intelligence artificielle peuvent interpréter une demande non structurée, recueillir les informations nécessaires dans les applications connectées et proposer une action dans SAP. Après validation, l’action est transmise par une API publiée, dans les limites des droits de l’utilisateur. SAP applique alors ses contrôles standard avant d’enregistrer l’opération.
SAP propose Joule Studio pour développer ces agents et SAP AI Agent Hub pour accompagner leur gouvernance et la gestion de leur cycle de vie.
|
Avantages |
Points de vigilance |
|
En rassemblant les informations réparties entre plusieurs systèmes, les agents peuvent réduire le travail manuel nécessaire à la préparation des transactions. Les équipes peuvent ensuite améliorer l’interprétation des demandes et l’enchaînement des actions en faisant évoluer le modèle ou ses instructions, sans modifier le code de l’ERP. |
Un agent peut mal interpréter une demande ou fournir des informations erronées. Pour les actions ayant des conséquences financières ou juridiques, la conception doit prévoir une validation humaine, une traçabilité des opérations et des droits limités à la tâche. Les règles de comptabilisation et de conformité doivent continuer à être appliquées par les contrôles déterministes de SAP, sans possibilité de contournement par l’agent. |
Dans ces différentes architectures, SAP reste le système de référence pour l’enregistrement des transactions. Les extensions apportent des fonctionnalités spécifiques par des interfaces publiées et prises en charge, ce qui permet de les faire évoluer sans modifier le code standard de l’ERP.
Faut-il supprimer le code spécifique de votre système SAP ?
La suppression d’un développement n’a d’intérêt que si elle réduit la charge de maintenance et d’évolution tout en préservant les processus nécessaires à l’activité. Avant de modifier ou de retirer un développement, les experts LeverX recommandent de suivre les étapes suivantes.
Vérifier l’usage réel du code
Les données d’exécution indiquent à quand remonte la dernière utilisation d’un objet, mais elles ne suffisent pas à expliquer son utilité métier. Le responsable du processus doit confirmer quelles activités en dépendent.
Cette vérification évite de supprimer des objets rarement utilisés mais indispensables, comme des états réglementaires annuels ou des interfaces à faible volume d’échanges.
Conserver les développements dont la valeur reste démontrée
Un développement se justifie s’il répond à une obligation réglementaire française ou apporte un bénéfice financier ou opérationnel mesurable, à la hauteur de ses coûts de maintenance et d’adaptation aux nouvelles versions.
Chaque développement conservé doit avoir un responsable et une date de réexamen.
Moderniser la réalisation technique lorsque le besoin reste valable
Le code dépendant d’objets standard ou de structures internes SAP peut imposer des adaptations évitables lors des montées de version.
Une règle limitée au périmètre d’une transaction peut être réimplémentée à l’aide d’un point d’extension publié par SAP. Une logique partagée entre plusieurs applications peut être déplacée vers SAP BTP. La comparaison de la charge de test avant et après la modernisation permet d’évaluer la réduction des dépendances au cœur ERP.
Remplacer les fonctions spécifiques désormais couvertes par SAP
Des développements anciens peuvent faire doublon avec des fonctionnalités aujourd’hui disponibles dans SAP S/4HANA ou dans sa localisation française.
Testez les fonctions standard sur des transactions réelles, en couvrant les exceptions, les habilitations et les résultats attendus. Le remplacement du code spécifique doit intervenir une fois ces scénarios validés.
Retirer progressivement le code obsolète
Lorsqu’aucun processus actif ni aucun autre système ne dépendent d’un objet et que celui-ci n’est pas nécessaire au respect d’une obligation réglementaire, désactivez-le pendant une période d’observation convenue avec les équipes concernées.
Surveillez les traitements planifiés, les erreurs d’interface et les demandes des utilisateurs avant de supprimer définitivement le code.
Un environnement SAP plus facile à faire évoluer grâce au Clean Core
Les choix faits aujourd’hui en matière de développements spécifiques déterminent la capacité des entreprises françaises à faire évoluer leur environnement SAP dans les années à venir. Une démarche Clean Core vise à alléger la préparation des montées de version, à accélérer l’adoption de nouvelles fonctionnalités et à intégrer les services d’IA au moyen d’interfaces maîtrisées. Elle permet aussi de mieux encadrer les nouveaux investissements pour limiter la reconstitution de la dette technique.
Cette démarche exige une connaissance précise du code existant et des processus qu’il soutient. LeverX analyse les développements spécifiques dans ce contexte, identifie les dépendances qui compliquent les montées de version et détermine où placer les règles métier à conserver dans une architecture Clean Core. Nos équipes SAP BTP réalisent les extensions nécessaires et planifient leur déploiement en tenant compte des opérations critiques et du calendrier des mises en production.
Contactez LeverX pour une évaluation Clean Core adaptée à votre environnement SAP et à vos priorités d’investissement.