Tous les ERP Cloud Public imposent-ils le même niveau de standard ?

Parce que l’architecture technique (multi-tenant, mises à jour gérées par l’éditeur) n’impose pas un modèle unique d’extensibilité. Chaque éditeur arbitre différemment entre deux objectifs contradictoires : garder un cœur applicatif propre et facile à mettre à jour, ou laisser le client modifier profondément le comportement du système. Plus un éditeur autorise de développements spécifiques dans le cœur, moins il peut garantir des mises à jour automatiques sans risque de régression — c’est un compromis, pas un détail technique.

Ce compromis a un coût quand il est mal maîtrisé. Une étude Deloitte menée en 2025 auprès d’un panel de plus de 60 DSI et DAF français montre que la dette technique freine 63 % des initiatives de transformation — davantage que la résistance culturelle interne. Le code spécifique accumulé au fil des années sur les ERP historiques est l’une des sources les plus documentées de cette dette technique.

La question à se poser n’est donc pas si un ERP est « standard » ou pas, mais quel mécanisme chaque éditeur propose pour absorber les besoins spécifiques sans reconstituer cette dette dans un environnement neuf.

Du côté le plus cadrant du marché des ERP Cloud Public, mais pas par absence de personnalisation — plutôt parce que cette personnalisation est déjà faite en amont, dans le standard. SAP S/4HANA Cloud Public Edition repose sur une logique qu’on peut résumer par « adopter, pas créer » : le produit intègre plusieurs centaines de pratiques métier et sectorielles préconfigurées (appelées scope items), issues de plusieurs décennies d’implémentations SAP. L’entreprise ne part pas d’une feuille blanche : elle sélectionne et configure, parmi ces pratiques existantes, celles qui correspondent à son activité.

C’est ce que SAP appelle l’approche « Fit-to-Standard » : les ateliers de cadrage ne cherchent pas à définir des processus depuis zéro, mais à confronter les processus standards déjà disponibles aux besoins réels de l’entreprise, pour identifier les rares ajustements mineurs nécessaires.

Cette logique s’accompagne de deux règles structurantes. D’abord, le principe du « cœur propre » (« keep the core clean ») : toute logique métier qui sortirait de ce standard préconfiguré — donc un vrai développement spécifique, pas un simple ajustement — doit être construite en dehors du système central, sur la plateforme SAP Business Technology Platform (BTP), en extension « side-by-side ». Le code cœur de S/4HANA Cloud Public Edition lui-même n’est pas modifiable. Ensuite, un rythme de montée de version imposé : SAP publie deux mises à jour majeures par an (février et août), automatiques et obligatoires, complétées par des évolutions continues plus légères entre ces deux échéances.

Concrètement, une entreprise qui choisit SAP Cloud Public Edition bénéficie d’un très large socle de pratiques métier déjà pensées pour son secteur — mais accepte, pour tout ce qui sort de ce socle, de développer en dehors du système plutôt que dedans, et de recevoir les mises à jour qu’elle le souhaite ou non.

C’est le choix de confier la discipline de standardisation à l’outil plutôt que de la faire reposer sur l’organisation elle-même — un arbitrage qui compte particulièrement pour une entreprise en croissance ou en transformation.
Dans ce type d’entreprise, compter sur les équipes pour maintenir seules cette discipline est plus exigeant qu’ailleurs : les effectifs grossissent vite, le turnover est plus élevé, de nouvelles entités arrivent par acquisition — et la mémoire des raisons pour lesquelles telle exception a été accordée un jour se perd avec les départs. Une organisation plus stable peut choisir de faire reposer cette discipline sur quelques personnes clés qui connaissent l’historique ; une entreprise qui change vite doit se poser la question différemment.

Le rapport 2026 de Panorama Consulting Group, qui analyse chaque année les projets ERP dans le monde, documente ce risque sur les environnements SaaS mal gouvernés : sans propriétaire clair des rôles, des règles de reporting ou des demandes de changement, les utilisateurs finissent par créer eux-mêmes des accès ponctuels ou des rapports parallèles — et la standardisation que le cloud était censé apporter s’érode peu à peu.

Un ERP dont le cœur ne peut techniquement pas être modifié ferme cette possibilité dès le départ, quel que soit le niveau de gouvernance interne à un instant donné. C’est le même mécanisme qui, dans l’article sur la clôture mensuelle, explique pourquoi les clôtures s’allongent avec le temps : chaque exception ajoutée devient une étape manuelle de plus à vérifier, un contrôle qui finit par sauter parce qu’il n’est nulle part documenté. Empêcher ces exceptions à la source, c’est régler le problème avant qu’il n’apparaisse — un bénéfice qui compte d’autant plus quand l’entreprise change vite.

Pour une PME/ETI qui recrute vite, ouvre des filiales ou absorbe une acquisition, cet effet se voit particulièrement : toute nouvelle entité utilise le même standard dès le premier jour, sans repartir d’une feuille blanche processus par processus.

Quand un processus est une source réelle de différenciation concurrentielle, pas seulement une habitude. La logique de SAP Cloud Public Edition n’est pas « aucune personnalisation » : le standard intègre déjà des centaines de pratiques sectorielles et métier, issues de plusieurs décennies d’implémentations, que l’entreprise sélectionne et configure selon son activité plutôt que de les construire elle-même. C’est une logique d’adoption, pas de création. Mais cette logique a une limite : si un processus ne correspond à aucune de ces pratiques préconfigurées parce qu’il constitue justement l’avantage concurrentiel de l’entreprise, l’écart doit être traité comme un développement spécifique — pas comme un simple ajustement de configuration. C’est précisément dans les organisations avec des processus très individualisés — en finance et contrôle de gestion notamment, où les reportings sur-mesure sont fréquents — que ces écarts sont les plus fréquents.

Dans ces situations, deux alternatives honnêtes existent, toutes deux légitimes : une plateforme Cloud Public plus permissive du marché sur l’extensibilité du cœur, ou SAP Cloud Private Edition, qui conserve la logique cloud mais autorise des développements spécifiques dans le système lui-même et laisse l’entreprise choisir son propre calendrier de mise à jour plutôt que de le subir. Un scénario hybride est également possible : les processus cœur sur une brique standardisée, et les processus réellement différenciants sur un environnement plus souple.

En le testant concrètement sur vos propres processus. C’est précisément la fonction des ateliers Fit-to-Standard menés en phase de cadrage : les processus standards de SAP S/4HANA Cloud Public Edition sont démontrés face aux équipes métier, qui identifient elles-mêmes les écarts avec leurs pratiques actuelles. L’exercice répond à une seule question par processus : cet écart est-il un ajustement mineur acceptable, ou un point de blocage réel ?

Trois signaux orientent la réponse avant même d’entrer en atelier :

• vos processus les plus spécifiques concernent-ils votre cœur de métier (donc un vrai avantage concurrentiel), ou sont-ils hérités d’un ancien système qu’on n’a jamais remis à plat ?
• votre organisation a-t-elle la capacité de faire évoluer ses habitudes de travail en même temps que l’outil, ou le changement doit-il rester invisible pour les équipes ?
• combien d’entités, de filiales ou de futures acquisitions devront un jour utiliser le même système — plus ce nombre est élevé, plus un standard commun devient un atout plutôt qu’une contrainte ?

Aucune de ces questions ne se tranche sur une plaquette commerciale. C’est un diagnostic, pas une conviction.

Oui, à condition que le développement passe par une extension « side-by-side » sur SAP BTP plutôt que par une modification du cœur applicatif. Les extensions construites de cette façon restent indépendantes du cycle de mise à jour de S/4HANA Cloud Public Edition, donc elles survivent aux montées de version.

Oui, et c’est souvent le vrai enjeu derrière la question de personnalisation. Chaque développement spécifique dans le cœur d’un ERP doit être retesté et parfois réécrit à chaque montée de version — c’est une charge récurrente qui s’accumule d’année en année. En reportant ces développements hors du cœur (sur BTP pour SAP Cloud Public Edition), l’entreprise limite cette charge répétée : l’extension continue de fonctionner indépendamment des mises à jour du système central. Le niveau de standardisation choisi au départ influence donc directement le coût de maintenance sur toute la durée de vie du projet, pas seulement le coût initial d’implémentation.

Non, mais cela signifie accepter de faire évoluer certaines habitudes de travail sur les processus où l’écart avec le standard est mineur. L’atelier Fit-to-Standard sert précisément à distinguer, processus par processus, ce qui relève d’un ajustement d’organisation de ce qui constituerait un vrai point de blocage.

Généralement quelques semaines, selon le nombre de processus couverts par le périmètre du projet. C’est un point de passage obligé avant tout engagement sur le délai et le budget du projet — l’objectif est justement d’éviter de s’engager sur un périmètre avant d’avoir confronté le standard à la réalité de l’entreprise.

PREREQUIS, ESN spécialisée dans la transformation des SI depuis 2001, accompagne les PME et ETI en croissance dans le choix des solutions ERP les mieux adaptées à leurs enjeux de structuration.

SAP Learning — Providing an Overview of the Fit-to-Standard Analysis Process

SAP Learning — Navigating Release Upgrades (SAP S/4HANA Cloud Public Edition)

ERPVisors — SAP Best Practices: Definition and usage (scope items, adopt not create)

Deloitte France — Faire de la technologie un véritable levier de performance économique (étude DSI/DAF 2025)

Panorama Consulting Group — The 2026 ERP Report