ERP Cloud vs On-Premise — Une matrice de décision
Le choix entre ERP cloud et ERP on-premise n'est plus une simple question de préférence — il façonne à la fois la souveraineté des données, le modèle d'exploitation informatique, la latitude de personnalisation et la structure de coûts sur cinq ans. Presque tous les grands éditeurs poussent désormais une feuille de route cloud-first (SAP RISE, Microsoft Dynamics 365, Sage X3, Oracle NetSuite, Infor CloudSuite), et pourtant les PME et ETI françaises ont encore de solides raisons d'évaluer trois modèles de déploiement plutôt que deux : SaaS en cloud public, cloud privé (hébergé en mono-tenant) et on-premise.
Cette matrice de décision recense les dix critères qui déterminent réellement le choix pour les entreprises de taille intermédiaire. Il ne s'agit volontairement pas d'un classement d'éditeurs — un même produit peut constituer un cloud pertinent ou un cloud mal avisé selon la sensibilité des données, la densité d'intégration, la profondeur de personnalisation et la capacité informatique interne de l'acheteur. La réponse honnête pour la plupart des PME et ETI françaises de 100 à 500 salariés est « cela dépend de six ou sept variables », et ce guide passe en revue chacune d'entre elles.
Les trois modèles de déploiement expliqués
Avant qu'une matrice ne devienne utile, les trois modèles de déploiement doivent être définis clairement — le marketing des éditeurs brouille régulièrement les frontières.
SaaS en cloud public (multi-tenant)
Une pile logicielle unique et partagée sert de nombreux clients sur une ligne de code commune ; l'éditeur détient l'exploitation, l'application des correctifs et le calendrier des versions. Exemples : SAP S/4HANA Cloud Public Edition, Microsoft Dynamics 365 Business Central Cloud, Oracle NetSuite, Sage Intacct, Cegid XRP Flex. Les clients reçoivent les fonctionnalités selon le calendrier de l'éditeur et ne peuvent pas reporter les montées de version. La personnalisation est limitée au modèle d'extension proposé par l'éditeur (AppSource, SuiteScript, extensions side-by-side).
Cloud privé (hébergé en mono-tenant)
Le même logiciel s'exécute sur une infrastructure dédiée à un seul client, exploitée soit par l'éditeur, soit par un partenaire d'hébergement, soit par une société de services managés. Exemples : SAP RISE Private Edition, Dynamics 365 hébergé par un partenaire, proAlpha Cloud, abas Cloud. Le calendrier des montées de version reste négociable, la profondeur de personnalisation est plus élevée et la résidence des données peut être étroitement contrôlée. Le coût se situe entre le SaaS et l'on-premise.
On-premise
Le client détient l'infrastructure, les licences et la responsabilité d'exploitation. L'éditeur vend du logiciel et du support, et non des niveaux de service. La personnalisation est illimitée, la cadence des montées de version est entièrement maîtrisée par l'acheteur, et les données ne quittent jamais le périmètre du client. La contrepartie est la compétence informatique interne requise pour exploiter une pile ERP moderne incluant base de données, serveur applicatif, couche d'intégration et reprise après sinistre.
Les modèles hybrides combinent ces éléments — un schéma typique de PME/ETI consiste en un cœur ERP en cloud privé avec des satellites en cloud public pour le CRM, les notes de frais ou les RH. Ces cas sont traités séparément plus loin dans ce guide.
Les dix critères de décision
Une matrice de décision utile note chaque option de déploiement au regard des critères qui font réellement la différence pour les acheteurs du segment intermédiaire. Les dix critères ci-dessous reviennent dans presque chaque sélection que nous observons sur le marché.
- Sensibilité des données et posture réglementaire : les préoccupations liées à l'arrêt Schrems II, les exigences de la CNIL, le RGPD ainsi que les obligations sectorielles (ACPR pour la finance, secteurs OIV/SAIV) déterminent le niveau de confort d'un acheteur vis-à-vis d'une infrastructure partagée située hors de France.
- Profondeur de personnalisation requise : si le modèle économique dépend véritablement de processus non standard, la contrainte d'une ligne de code multi-tenant devient réelle. La plupart des PME/ETI surestiment ce point et finissent malgré tout avec 80 % de standard.
- Densité d'intégration : combien d'interfaces temps réel existent vers le MES, la CAO/PLM, l'e-commerce, l'EDI et les systèmes de gestion d'entrepôt ? Un parc d'intégrations on-premise dense rend un passage en cloud pur plus douloureux qu'il n'y paraît sur une diapositive.
- Capacité informatique interne : une équipe d'infrastructure solide, disposant d'une expertise en base de données, réseau et sécurité, rend l'on-premise viable ; un service informatique réduit avec un seul généraliste rend le cloud presque incontournable.
- Préférence Capex vs Opex : les actionnaires de capital-investissement et les directeurs financiers orientés croissance préfèrent souvent le modèle d'abonnement prévisible ; les entreprises familiales disposant d'une bonne capacité bilancielle privilégient parfois le traitement Capex des licences perpétuelles.
- Géographie du déploiement et trajectoire de fusions-acquisitions : les entreprises qui prévoient une expansion internationale ou des acquisitions fréquentes tirent profit du provisionnement plus rapide de nouvelles entités offert par le cloud.
- Coût total de possession sur 5 à 7 ans : le point de croisement où le cloud devient plus coûteux que l'on-premise se situe généralement entre la cinquième et la septième année pour un nombre d'utilisateurs stable — voir notre calculateur de TCO ERP.
- Discipline de mise à jour : les montées de version obligatoires du cloud imposent d'être toujours à jour mais perturbent le calendrier ; l'on-premise tolère la dette technique au prix de migrations de rattrapage finalement douloureuses.
- Stratégie de sortie : à quel point est-il réaliste de quitter un éditeur dans cinq ans ? Les droits d'export des données, la portabilité du schéma et l'écosystème de partenaires entrent tous en ligne de compte.
- Adéquation culturelle et préoccupations du comité social et économique (CSE) : en France, les instances représentatives du personnel ont un rôle formel à jouer dès qu'un système touche aux données RH, et les déploiements cloud qui transfèrent des données salariés à l'étranger nécessitent un alignement explicite.
Quand le SaaS en cloud public est le bon choix
Le SaaS en cloud public est la recommandation par défaut pour les PME et ETI dont la situation correspond à un profil clair : processus standard, service informatique réduit, croissance ambitieuse ou expansion internationale, et une direction financière qui valorise un Opex prévisible. D'après nos observations, cela couvre environ 40 à 55 % de la population des PME/ETI de 50 à 500 salariés.
Les profils typiquement bien adaptés incluent :
- Les entreprises de services (cabinets de conseil, agences, éditeurs SaaS) dont le parc de processus est standard et dont les besoins d'intégration sont modestes.
- Les sociétés de négoce et de distribution sans production complexe, où Oracle NetSuite ou Dynamics 365 Business Central couvrent les flux essentiels en standard.
- Les groupes multi-entités qui prévoient de consolider leurs comptes entre plusieurs pays sur une ligne de code commune.
- Les entreprises issues d'une opération de capital-investissement, dont le nouvel actionnaire souhaite un reporting standardisé et une ligne de coût informatique prévisible.
Les contraintes à accepter : la feuille de route des fonctionnalités appartient à l'éditeur, la personnalisation doit vivre dans le cadre d'extension, et la résidence des données est celle que l'éditeur propose dans ses centres de données régionaux. Pour SAP S/4HANA Cloud Public Edition, cela signifie Francfort ; pour Microsoft et Oracle, l'empreinte européenne est large et des options à résidence française existent ; pour les éditeurs cloud-native plus petits, la résidence des données peut être rédhibitoire.
Un écueil à éviter : démarrer en SaaS cloud public pour économiser au départ, puis tenter d'ajouter ensuite une personnalisation profonde parce que le standard ne convient pas tout à fait. C'est la manière la plus coûteuse de découvrir que le modèle de déploiement était le mauvais.
Quand le cloud privé offre le meilleur compromis
Le cloud privé — hébergé en mono-tenant — est la bonne réponse pour les entreprises de taille intermédiaire qui ont besoin de plus de contrôle que ce que le SaaS autorise, mais qui n'ont pas la profondeur informatique interne (ni l'appétit) pour exploiter elles-mêmes l'infrastructure. Situations typiques :
- Systèmes fortement personnalisés migrés depuis l'on-premise : un parc Microsoft Dynamics NAV ou SAP ECC vieux de 15 ans ne peut pas réalistement être basculé tel quel vers un SaaS cloud public sans une refonte des processus s'étalant sur plusieurs années. Le cloud privé préserve la personnalisation tout en transférant la charge d'exploitation.
- ERP sectoriels à forte verticalisation : proAlpha pour l'industrie manufacturière, abas pour la fabrication à la commande, oxaion pour les activités projet, Divalto pour le négoce et l'industrie. Ces éditeurs proposent généralement une option d'hébergement en cloud privé qui conserve la profondeur verticale.
- Secteurs réglementés : pharmacie, dispositifs médicaux, production alimentaire, fournisseurs de la défense, où les pistes d'audit, les environnements validés et des fenêtres de changement étroitement contrôlées comptent davantage que des livraisons mensuelles de fonctionnalités.
- Entreprises exigeant une résidence des données en France avec des exploitants nommés : un partenaire d'hébergement à Paris ou à Lyon, capable de nommer le personnel ayant accès à la base de données, constitue parfois une exigence ferme.
Le profil financier se situe entre le SaaS et l'on-premise — en général 30 à 50 % plus cher que le SaaS cloud public par utilisateur, mais 20 à 40 % moins cher que l'exploitation de la même charge en on-premise avec une équipe interne compétente. L'avantage caché est la flexibilité des montées de version : le client peut différer les versions majeures d'un trimestre ou deux lorsque le calendrier de l'entreprise l'exige, ce qui est rarement possible en SaaS pur.
Quand l'on-premise garde du sens
L'ERP on-premise n'est pas mort dans le segment des PME/ETI — il n'est simplement plus le choix par défaut. Il subsiste quatre situations relativement étroites où il constitue la bonne réponse.
Intégration profonde de l'OT (technologies opérationnelles). Les entreprises de la machine-outil, de l'industrie de process, de la sous-traitance automobile et de la fabrication discrète exploitent souvent un ERP étroitement couplé au MES de l'atelier, aux systèmes SCADA, aux automates (PLC) et aux systèmes qualité. La sensibilité à la latence et les exigences de bascule sur site font de l'instance ERP locale le choix pragmatique. On peut citer les entreprises de construction de machines qui font tourner proAlpha ou abas en on-premise avec des exigences de temps de réponse inférieures à 50 ms vers leur MES.
Exigences de souveraineté des données au-delà du RGPD standard. Les sous-traitants de la défense, les détenteurs d'informations classifiées et certains fournisseurs proches du secteur public sont soumis à des obligations contractuelles qui rendent tout flux de données transfrontalier problématique. Les niveaux de qualification les plus élevés de l'ANSSI (SecNumCloud, par exemple) peuvent, dans certaines interprétations, exclure entièrement l'infrastructure des hyperscalers.
Personnalisation très profonde et critique pour l'activité. Un petit nombre d'entreprises ont bâti un véritable avantage concurrentiel sur un ERP personnalisé — non pas l'avantage concurrentiel imaginaire que supposent la plupart des projets, mais une différenciation réelle que le standard ne peut reproduire. Pour celles-ci, la liberté de personnalisation de l'on-premise l'emporte sur le coût d'exploitation.
Exploitation informatique interne déjà solide. Si l'entreprise dispose déjà d'un centre de données compétent ou d'une colocation avec sauvegarde, supervision et astreinte 24/7, le coût marginal d'exploitation de l'ERP sur la même pile reste modéré. La comparaison de TCO du cloud s'inverse pour ces organisations.
En dehors de ces quatre cas, l'on-premise est généralement hérité plutôt que choisi — un système vieux de 10 à 20 ans que personne n'a encore eu le budget ou le courage de migrer.
Stratégies hybrides et à deux niveaux
Un schéma courant chez les PME et ETI est une architecture hybride plutôt qu'un choix de déploiement pur. Les variantes les plus fréquentes :
- ERP à deux niveaux (two-tier) : un cœur ERP lourd (souvent SAP, proAlpha, abas) au siège, avec des ERP cloud plus légers (Business Central, NetSuite, Cegid) dans les filiales ou les entités récemment acquises. La consolidation s'opère via l'intégration financière et les interfaces intercompany. Ce schéma protège l'investissement du siège tout en laissant les filiales avancer à leur propre rythme.
- Cœur-plus-satellites : un ERP en cloud privé ou on-premise pour la finance, la production et la chaîne logistique ; des satellites SaaS pour le CRM (Salesforce, HubSpot), les RH (Personio, Workday), la gestion des notes de frais (SAP Concur), les déplacements et les achats.
- Edge-and-core : un cœur ERP cloud combiné à des composants on-premise en périphérie — typiquement un système de gestion d'entrepôt ou la collecte de données en atelier — nécessitant une résilience locale et des temps de réponse rapides.
Les architectures hybrides résolvent des contraintes réelles mais introduisent leur propre complexité : gouvernance des données de référence entre systèmes, gestion des identités et des accès, et désignation claire du système qui fait foi pour chaque entité (client, fournisseur, article, salarié). Beaucoup de configurations hybrides deviennent ingérables non pas à cause de l'architecture elle-même, mais parce que personne n'est financé pour exploiter la couche d'intégration. Des configurations hybrides réalistes budgètent l'équivalent de 0,5 à 1,5 personne à temps plein pour l'intégration et l'exploitation des données de référence.
Protection des données, RGPD et résidence des données
Le paysage juridique depuis l'arrêt Schrems II (2020) rend les transferts de données vers des pays tiers — en particulier les États-Unis — bien plus difficiles à justifier au regard du RGPD. Pour un ERP, qui traite par définition des données personnelles de clients, de fournisseurs et de salariés, cela compte davantage que pour bien d'autres catégories de logiciels.
Les hyperscalers (Microsoft, AWS, Google) ont répondu par des offres de données à résidence dans l'UE, des régions européennes dédiées et des engagements contractuels visant à limiter la sortie des données. Le cadre de protection des données UE-États-Unis (Data Privacy Framework, DPF), en vigueur depuis 2023, fournit un nouveau mécanisme de transfert mais devrait, de l'avis général, faire face aux mêmes contestations juridiques que ses prédécesseurs. Pour les acheteurs PME/ETI français, les réflexes pratiques sont les suivants :
- Pour les données salariés : exiger une résidence dans l'UE, documenter la base légale au titre de l'article 6 du RGPD, et associer tôt le CSE car les déploiements cloud touchant aux données RH requièrent une consultation formelle au titre du Code du travail.
- Pour les données clients : examiner les propres obligations contractuelles du client — certains clients B2B français (notamment dans la pharmacie, la finance et le secteur public) imposent par contrat des exigences de résidence des données qui se répercutent sur leurs fournisseurs.
- Pour les données fournisseurs : sensibilité généralement plus faible, mais les mêmes attentes de résidence s'appliquent lorsque la base fournisseurs contient des données personnelles de prestataires individuels.
La loi Informatique et Libertés et les recommandations de la CNIL ajoutent des exigences supplémentaires au RGPD, en particulier concernant le traitement des données salariés. Les éditeurs d'ERP cloud qui ont fait leurs devoirs offrent des engagements de résidence des données et des rapports d'audit (généralement SOC 2 Type II, ISO 27001, et la qualification SecNumCloud) qui s'alignent proprement sur les attentes de conformité françaises. Les acheteurs devraient demander ces rapports avant la signature du contrat, et non après.
Migration et stratégie de sortie — à ne pas oublier
Deux questions que les acheteurs sous-pondèrent au moment de la sélection et regrettent amèrement à la quatrième année : comment entre-t-on, et comment en sort-on ?
Migration entrante : passer d'un système on-premise existant à un ERP cloud est un projet à part entière, coûtant généralement 60 à 90 % d'une implémentation équivalente en greenfield. L'approche du lift-and-shift (emporter sa personnalisation avec soi) échoue le plus souvent — soit l'éditeur cloud refuse d'héberger le code sur mesure, soit le coût de sa réingénierie pour le modèle d'extension cloud est prohibitif. La plupart des migrations réussies sont essentiellement des réimplémentations greenfield avec reprise de données, ce qui signifie que la durée et le coût du projet approchent ceux d'un nouveau projet ERP. Voir notre guide de migration ERP pour l'approche structurée.
Sortie : les stratégies de sortie d'un ERP cloud restent souvent théoriques jusqu'à ce qu'elles ne le soient plus. Les engagements d'export de données dans les contrats cloud standard varient considérablement — certains éditeurs offrent un export complet de la base dans un format lisible par machine, d'autres fournissent des rapports et des extraits CSV dépourvus de la structure relationnelle nécessaire pour amorcer un nouveau système. Les acheteurs devraient demander et examiner la spécification d'export réelle au moment du contrat, et non au moment de la sortie. Parmi les clauses contractuelles utiles : une assistance à la transition limitée dans le temps, la documentation du schéma et un format de données de sortie préservant l'intégrité référentielle.
Pour le SaaS multi-tenant en particulier, la dépendance opérationnelle au calendrier de versions de l'éditeur signifie qu'il n'existe pas d'option réaliste de statu quo — si un éditeur traverse une opération de fusion-acquisition ou réoriente sa feuille de route, le client s'adapte ou s'en va. Budgéter 5 à 10 % de l'abonnement annuel comme « réserve de sortie » notionnelle constitue une couverture raisonnable pour les charges critiques.
Performance, disponibilité et montée en charge
Les ERP cloud s'engagent généralement sur des accords de niveau de service (SLA) de 99,5 à 99,9 % de disponibilité mensuelle, assortis d'avoirs financiers en cas de manquement. Sur le papier, cela surpasse la plupart des exploitations on-premise, qui mesurent rarement une disponibilité formelle. En pratique, la comparaison est plus nuancée :
- Périmètre du SLA : les SLA cloud couvrent généralement la disponibilité de l'application mais pas la connexion internet du client, son fournisseur d'identité ou ses intégrations tierces. Un SLA applicatif de 99,9 % combiné à une connexion internet à 99 % produit une disponibilité réelle de 98,9 % pour l'utilisateur final.
- Variabilité de la performance : la performance d'un SaaS multi-tenant peut varier en fonction des effets de « voisin bruyant », de la charge régionale et de la gestion de capacité de l'éditeur. La performance on-premise est plus déterministe mais dimensionnée par le client plutôt que par l'éditeur.
- Reprise après sinistre : la reprise après sinistre cloud est généralement intégrée (géo-réplication, bascule automatisée) ; en on-premise, c'est un projet distinct doté de son propre budget et de sa propre discipline. Beaucoup d'implémentations on-premise disposent d'une reprise après sinistre nominale qui n'a jamais été testée.
- Montée en charge pour les pics : les activités saisonnières (e-commerce, distribution de mode, approvisionnement agricole) tirent un bénéfice substantiel de l'élasticité du cloud. L'on-premise doit dimensionner pour le pic et le payer toute l'année.
Une recommandation pragmatique : inscrire les exigences de performance et de disponibilité dans l'appel d'offres et demander aux éditeurs présélectionnés de documenter comment ils les satisfont. Les prises de références auprès de clients existants dans des secteurs comparables sont plus révélatrices que les SLA des éditeurs eux-mêmes.
Un cadre de décision pratique
Pour réunir les dix critères, un cadre simple aide les acheteurs PME/ETI à parvenir à une recommandation défendable. La décision passe par trois filtres, dans l'ordre.
Filtre 1 : contraintes réglementaires et de souveraineté des données. Existe-t-il des exigences impératives (ACPR, SecNumCloud, obligations contractuelles des clients) qui éliminent certaines options de déploiement ? Si oui, la matrice est partiellement résolue — l'acheteur choisit parmi les options restantes.
Filtre 2 : profondeur de personnalisation. Quelle part de l'activité a véritablement besoin d'un support de processus non standard ? Une analyse d'écart franche par rapport au standard de deux ou trois systèmes candidats montre généralement que 80 à 90 % des processus s'inscrivent dans le standard. Si les besoins réels de personnalisation sont inférieurs à 15 % des processus, le SaaS cloud public devient viable ; entre 15 % et 30 %, le cloud privé est la bonne zone ; au-delà de 30 %, l'on-premise recommence à paraître raisonnable — ou les besoins de personnalisation eux-mêmes devraient être remis en question.
Filtre 3 : capacité informatique et préférence financière. Parmi les options restantes, laquelle correspond à la capacité d'exploitation interne et à la préférence du directeur financier entre Capex et Opex ? Il s'agit rarement d'une élimination stricte, mais cela devrait rendre le choix évident.
La matrice de décision en résumé :
- SaaS en cloud public : processus standard, informatique réduite, préférence Opex, déploiement international, intégration de fusions-acquisitions. Adéquation typique : 40 à 55 % des PME/ETI.
- Cloud privé : personnalisation modérée, secteur réglementé, résidence des données en France, volonté d'une exploitation hébergée mais sans les contraintes du multi-tenant. Adéquation typique : 25 à 35 % des PME/ETI.
- On-premise : intégration OT profonde, données classifiées, personnalisation critique pour l'activité, exploitation informatique interne déjà solide. Adéquation typique : 10 à 20 % des PME/ETI, et en recul.
La matrice est descriptive, et non prescriptive — chaque sélection comporte des facteurs propres au contexte qui supplantent les choix par défaut. L'enjeu est de rendre le choix explicite plutôt que d'hériter d'un modèle de déploiement par hasard.