Sur site ou cloud : guide des données d'entreprise (2026)

Le choix entre le sur site (on-prem) et le cloud est une décision de déploiement entre l’exécution de charges de travail sur du matériel que vous possédez et exploitez, ou la location d’une capacité gérée auprès d’un fournisseur, et cette décision s’étend désormais bien au-delà des serveurs. Les trois modèles dominants (cloud public, cloud privé et sur site) diffèrent par leur structure de coûts, leur contrôle, leur élasticité et leur conformité, et la plupart des entreprises en gèrent au moins deux simultanément.

• Sur site signifie que vous possédez et exploitez la pile physique ; le cloud signifie qu’un fournisseur possède le matériel et que vous le consommez en tant que service, facturé à l’utilisation ou par abonnement.
• La comparaison des coûts n’est pas une question de « bon marché ou cher » : il s’agit de dépenses d’investissement (CapEx) avec un long amortissement, face à des dépenses d’exploitation (OpEx) qui évoluent selon la consommation.
• L’hybride et le multi-cloud sont la réalité par défaut des entreprises, faisant d’un modèle de données agnostique des applications le véritable enjeu de l’intégration des données dans le cloud.
• Les charges de travail avec une demande stable et prévisible et des règles strictes de résidence des données favorisent souvent le sur site ; les charges de travail irrégulières (spiky), expérimentales ou distribuées mondialement privilégient généralement le cloud.
• Les plateformes SaaS telles que SharePoint et SAP sont désormais disponibles en éditions sur site et cloud, donc le choix « sur site vs cloud » est souvent une décision par application, et non à l’échelle de l’entreprise.
• Des normes d’interopérabilité open source existent spécifiquement pour empêcher la frontière sur site/cloud de devenir une frontière de silo de données, facilitant l’intégration sur site/cloud et l’interopérabilité d’entreprise open source pour le cloud.

Signification de sur site vs cloud

La question du sur site vs cloud revient à savoir qui possède la couche d’infrastructure. Le sur site (souvent écrit « on-prem ») désigne les logiciels et les données s’exécutant sur des serveurs, du stockage et des réseaux que l’organisation achète, héberge et entretient — généralement dans son propre centre de données ou dans un centre de colocation. Le cloud désigne les mêmes charges de travail s’exécutant sur une infrastructure appartenant à un fournisseur tel qu’Amazon Web Services, Microsoft Azure ou Google Cloud, livrées via un réseau et consommées en tant que service.

La distinction porte sur la limite de responsabilité, et non sur la technologie à l’intérieur de la boîte. Une machine virtuelle sur votre propre hyperviseur et une machine virtuelle dans un cloud public peuvent exécuter des systèmes d’exploitation et des bases de données identiques. Ce qui change, c’est qui applique les correctifs sur l’hôte, qui remplace les disques défectueux, qui provisionne la capacité et qui détient le contrat en cas de panne.

Un modèle mental utile est le modèle de responsabilité partagée. Dans le cloud, le fournisseur sécurise l’installation physique, l’hyperviseur et la couche de services gérés, tandis que le client sécurise les identités, les données et la configuration. Sur site, le client possède chaque couche. Ce changement explique à lui seul la plupart des différences opérationnelles, de personnel et de coûts qui en découlent.

Différence entre sur site et cloud

La différence entre les solutions sur site et cloud se manifeste selon six dimensions pratiques : modèle de coût, évolutivité, contrôle, posture de sécurité, résilience et rapidité du changement.

Modèle de coûts. L’infrastructure sur site est une dépense d’investissement : vous achetez l’équipement à l’avance et vous l’amortissez sur plusieurs années. Le cloud est une dépense d’exploitation : vous payez ce que vous consommez, ce qui rend les prévisions plus difficiles mais évite des engagements initiaux importants.

Connexes : Fivetran — Le pipeline ELT entièrement géré qui continue de fonctionner.

Évolutivité. La capacité cloud peut être provisionnée en quelques minutes et libérée lorsque la demande diminue. La capacité sur site nécessite des cycles d’approvisionnement se comptant en semaines ou en mois, et l’équipement inutilisé coûte toujours de l’argent.

Contrôle. La version sur site offre un contrôle complet sur le matériel, la topologie du réseau, les versions du micrologiciel et les fenêtres de maintenance. Le cloud permet un contrôle de la configuration dans les limites imposées par le fournisseur, et les services gérés suppriment complètement certains choix.

Sécurité. La sécurité sur site est limitée par l’expertise et le budget de votre propre équipe. La sécurité du cloud bénéficie de l’échelle du fournisseur et des certifications de conformité, mais la mauvaise configuration reste la cause principale des incidents cloud. Aucun des deux modèles n’est intrinsèquement plus sûr ; la surface d’attaque se déplace simplement.

Notre sélection : Workato — iPaaS piloté par l'automatisation sur lequel les équipes commerciales peuvent réellement s'appuyer.

Résilience. Les régions cloud et les zones de disponibilité font de la redondance géographique un simple exercice de configuration. La redondance sur site nécessite un second site, un stockage répliqué et un basculement testé : un véritable travail d’ingénierie à un coût réel.

Rapidité du changement. Le cloud raccourcit le chemin entre l’idée et la production, c’est pourquoi les équipes l’utilisent pour l’expérimentation. La gestion du changement sur site est plus lente, mais souvent plus prévisible et auditable.

Coûts sur site vs cloud

Les coûts sur site et cloud sont souvent comparés comme une simple facture mensuelle face à une facture de matériel, et cette comparaison est presque toujours erronée. Un modèle de coût total de possession (TCO) défendable doit inclure les coûts qui n’apparaissent jamais sur une facture cloud et ceux qui n’apparaissent jamais sur un bon de commande.

Les postes de coûts sur site comprennent le matériel serveur et stockage, l’équipement réseau, les frais d’espace de centre de données ou de colocation, l’énergie et le refroidissement, le renouvellement du matériel tous les quelques années, les licences de système d’exploitation et de base de données, l’infrastructure de sauvegarde, le site de reprise après sinistre et les salaires des ingénieurs qui gèrent l’ensemble. Les éléments de coût du cloud comprennent la consommation de calcul et de stockage, les frais de sortie de données (egress), les services de base de données et de files d’attente gérés, les plans de support, les engagements de capacité réservée et le temps d’ingénierie consacré à la gouvernance des coûts et au redimensionnement (rightsizing).

Deux comportements de coûts méritent d’être soulignés. Premièrement, les dépenses cloud sont élastiques dans les deux sens : elles peuvent diminuer lorsque la demande baisse, ce que les actifs sur site ne peuvent pas faire.

Deuxièmement, le système sur site a un problème d’utilisation : le matériel dimensionné pour les pics de charge reste inactif la plupart du temps, et cette capacité inutilisée est déjà payée. Le cloud convertit cette capacité inutilisée en un coût variable, ce qui est un réel avantage pour les charges de travail irrégulières et un réel inconvénient pour les charges de travail stables.

Connexes : Matillion — ELT push-down conçu pour les entrepôts de données cloud.

Un troisième facteur est le coût de sortie. Migrer hors d’un fournisseur cloud implique des frais de sortie, un effort de replatforming et une refonte des compétences. La migration sur site implique l’élimination du matériel et, souvent, un projet de migration vers le cloud. Les deux directions entraînent des coûts de transfert inhérents au modèle.

Comparaison des coûts sur site vs cloud

Le tableau ci-dessous présente la comparaison par facteur de décision plutôt que par prix absolu, car les prix absolus varient selon la région, le contrat et la forme de la charge de travail.

Facteur de décision	Sur site	Cloud
Dépense initiale	Élevée (matériel, licences, installations)	Faible ou nulle
Dépenses continues	Amortissement fixe, énergie, personnel	Consommation variable, sortie, support
Coût de mise à l’échelle	Fonction en escalier (achat d’un rack)	Continu (ajout d’une instance)
Capacité inutilisée	Payée quoi qu’il arrive	Libérée lorsqu’elle n’est pas utilisée
Prévisibilité des coûts	Élevée	Plus faible sans engagements
Coût de sortie	Élimination du matériel, projet de migration	Frais de sortie, replatforming
Meilleur ajustement	Stable, forte utilisation, réglementé	Irrégulier, expérimental, distribué

Sur site vs basé sur le cloud

« Sur site vs basé sur le cloud » est la formulation utilisée par les acheteurs lorsqu’ils comparent des produits livrés dans les deux éditions. Une application « basée sur le cloud » est fournie en tant que service : le fournisseur l’héberge, la corrige et la fait évoluer, et le client y accède via un navigateur ou une API. Une édition sur site du même produit est installée au sein du réseau du client et gérée par l’équipe du client.

Si vous faites du shopping : Boomi AtomSphere — Enterprise iPaaS pour l'intégration hybride cloud-on-premise.

Le compromis se situe entre le contrôle et la charge opérationnelle. Les éditions basées sur le cloud offrent des mises à jour plus rapides et des frais de maintenance réduits, mais lient le client au rythme de publication et aux conditions de traitement des données du fournisseur.

Les éditions sur site permettent une personnalisation approfondie, un déploiement isolé (air-gapped) et une pleine garde des données, au prix de projets de mise à niveau et d’une expertise interne. De nombreux fournisseurs proposent désormais une édition cloud privé ou « bring-your-own-cloud » comme solution intermédiaire, ce qui mérite d’être demandé explicitement lors de l’achat.

Serveur sur site vs serveur cloud

Les comparaisons entre serveurs sur site et cloud se résument généralement à trois questions : qui possède l’hôte physique, comment la capacité est allouée et que se passe-t-il en cas de panne. Un serveur sur site est une machine physique appartenant à l’organisation, avec un CPU, une mémoire et un stockage fixes qui ne peuvent s’étendre au-delà de son châssis. Un serveur cloud est une instance virtuelle extraite de la flotte d’un fournisseur, redimensionnable en quelques minutes et remplaçable automatiquement en cas de panne de l’hôte sous-jacent.

Les serveurs cloud introduisent également des familles d’instances optimisées pour le calcul, la mémoire, le stockage ou les charges GPU, permettant aux équipes d’adapter le matériel à la charge de travail sans achat physique. Les serveurs sur site offrent des performances prévisibles sans effets de « voisin bruyant » (noisy-neighbor) et sans dépendance réseau vis-à-vis d’un fournisseur externe. Pour les charges de travail sensibles à la latence et colocalisées avec d’autres systèmes sur site, cette prévisibilité est un réel avantage architectural.

SharePoint sur site vs cloud

Le cas de SharePoint sur site vs cloud est un exemple concret d’une plateforme existant dans les deux mondes. SharePoint Server est le produit sur site, installé sur Windows Server avec SQL Server, corrigé par l’équipe informatique du client et généralement mis à niveau selon un cycle pluriannuel. SharePoint dans Microsoft 365 est le service cloud, mis à jour en permanence par Microsoft sans intervention du client.

Les organisations ayant des exigences strictes de résidence des données, des solutions de fermes (farm) fortement personnalisées ou des investissements SharePoint sur site existants restent parfois sur SharePoint Server. Les organisations souhaitant des fonctionnalités de collaboration modernes, des intégrations de type Copilot et aucune maintenance de ferme se tournent généralement vers le service cloud. La migration elle-même est rarement un simple « lift-and-shift » : les personnalisations, les flux de travail et les modèles d’authentification doivent généralement être retravaillés, et c’est là qu’un modèle de données partagé entre les deux environnements devient payant.

SAP sur site vs cloud

Le cas de SAP sur site vs cloud suit le même modèle à plus grande échelle. SAP ERP sur site (SAP ECC classique et édition sur site de SAP S/4HANA) permet aux clients de contrôler la base de données, le calendrier des mises à jour et la couche de personnalisation, ce qui est courant dans les secteurs réglementés. SAP S/4HANA Cloud et RISE with SAP déplacent ces mêmes processus métier vers un modèle d’abonnement hébergé par SAP ou un hyperscaler.

La décision dépend de la profondeur de la personnalisation, de la tolérance aux mises à niveau et de la surface d’intégration. Les paysages SAP sur site fortement personnalisés sont coûteux à replatformer, tandis que les éditions cloud poussent les clients vers des principes de « clean core » et des extensions standardisées. Quoi qu’il en soit, les données SAP doivent atteindre des systèmes CRM, de chaîne d’approvisionnement et d’analyse qui peuvent résider dans un modèle de déploiement différent — ce qui est précisément le problème d’intégration qu’un modèle de données agnostique des applications est conçu pour résoudre.

Pourquoi la vraie question est l’intégration, pas le déploiement

Les solutions sur site et cloud existent rarement comme une alternative exclusive dans une entreprise mature. Un paysage typique fait tourner SAP sur site, Salesforce dans le cloud, un entrepôt de données chez un hyperscaler et une plateforme de machine learning chez un autre. La question du déploiement est tranchée par charge de travail ; la question de l’intégration n’est jamais résolue. Cette tension entre sur site et cloud est une constante des infrastructures modernes.

Les outils d’intégration de données cloud (Fivetran, Airbyte, dbt, Matillion, Informatica et les services natifs de chaque hyperscaler) résolvent le problème du mouvement. Ils extraient des sources, transforment et chargent dans des cibles.

Ce qu’ils ne résolvent pas seuls, c’est l’accord sémantique : si « client » dans le CRM désigne la même entité que « client » dans l’ERP, et si un champ nommé status porte le même domaine de valeurs dans les deux. C’est le défi central de l’intégration cloud/sur site.

C’est là que la modélisation des données cloud et les normes d’interopérabilité d’entreprise open source pour le cloud interviennent. Un modèle partagé définit les entités, les relations et les attributs une seule fois, de manière agnostique vis-à-vis des applications, afin que les systèmes sur site et cloud correspondent à un vocabulaire commun plutôt qu’aux particularités des uns et des autres.

Le Cloud Information Model est l’un de ces efforts : un schéma ouvert et neutre vis-à-vis des fournisseurs pour les entités commerciales courantes, destiné à être étendu plutôt que remplacé. Les travaux de normalisation associés incluent schema.org pour les données web, l’Open Data Protocol (OData) pour l’accès aux données RESTful, et les spécifications RDF et OWL du W3C pour la modélisation de données basée sur les graphes.

Pour les architectes consultant des revues d’outils d’intégration de données cloud, le filtre pratique est de savoir si un outil peut mapper vers un modèle canonique ou seulement vers des schémas point à point. Les mappages point à point se multiplient : cinq systèmes nécessitent dix mappages, dix systèmes en nécessitent quarante-cinq. Un modèle canonique réduit cela à un seul mappage par système, ce qui fait la différence entre une architecture d’intégration et un backlog d’intégration pour les environnements sur site et cloud.

Comment décider : une liste de critères

Un processus décisionnel défendable utilise des critères au niveau de la charge de travail plutôt qu’une préférence au niveau de l’entreprise pour peser le sur site face au cloud.

1. Forme de la demande. Des charges de travail constantes et à forte utilisation stimulent l’économie sur site ; une demande de pointe ou imprévisible favorise l’élasticité du cloud.
2. Résidence et souveraineté des données. Les juridictions appliquant des règles de localisation strictes peuvent exiger des régions cloud sur site ou dans le pays.
3. Exigences en matière de latence. Une interaction inférieure à la milliseconde avec les systèmes sur site existants plaide en faveur de la colocation, nécessitant souvent une intégration cloud robuste sur site.
4. Profondeur de personnalisation. Les plates-formes profondément personnalisées coûtent cher à refactoriser ; les solutions standardisées sont plus faciles à migrer, prenant en charge l’interopérabilité des entreprises open source pour le cloud.
5. Capacité de l’équipe. Le cloud déplace les efforts des opérations matérielles vers la gouvernance des coûts et la configuration de la sécurité ; adaptez vos effectifs en conséquence.
6. Risque de sortie et de verrouillage. Modélisez les frais de sortie, les dépendances de services propriétaires et les efforts de refonte de la plateforme avant de vous engager dans des stratégies sur site et cloud.
7. Zone d’intégration. Comptez les systèmes avec lesquels chaque charge de travail doit échanger des données et décidez si un modèle canonique est justifié, peut-être en consultant les évaluations des outils d’intégration de données cloud pour trouver la bonne approche d’intégration de données cloud.

Sources et lectures complémentaires

• Open source — Wikipédia : L’open source est la pratique consistant à publier publiquement des ressources numériques avec leur code source ou leurs fichiers sources, permettant leur utilisation, leur étude, leur modification et leur redistribution…
• Interopérabilité d’entreprise — Wikipédia : L’interopérabilité d’entreprise est la capacité d’une entreprise (une entreprise ou une autre grande organisation) à relier fonctionnellement des activités, telles que la conception de produits, la fourniture… -Intégration de données — Wikipédia : L’intégration de données est le processus de combinaison, de partage ou de synchronisation de données provenant de plusieurs sources pour fournir aux utilisateurs une vue unifiée. Il existe une large gamme de…
• Modélisation des données — Wikipédia : La modélisation des données en génie logiciel est le processus de création d’un modèle de données pour un système d’information en appliquant certaines techniques formelles. Il peut être appliqué…

Questions fréquemment posées

Quelle est la différence entre sur site et dans le cloud ?

Sur site signifie que l’organisation possède et exploite les serveurs, le stockage et le réseau, et qu’elle supporte l’intégralité de la charge opérationnelle. Le cloud signifie qu’un fournisseur possède cette infrastructure et la fournit sous forme de service facturé au compteur ou souscrit. Lorsque l’on compare les versions sur site et dans le cloud, les charges de travail elles-mêmes peuvent être techniquement identiques ; ce qui diffère, c’est la propriété, la structure des coûts, le comportement de mise à l’échelle et qui est responsable en cas de panne.

Le sur site est-il moins cher que le cloud ?

Ni l’un ni l’autre n’est universellement moins cher. Le système sur site a tendance à gagner en termes de coût total pour les charges de travail stables et à forte utilisation, où le matériel est pleinement utilisé et amorti au fil des années.

Le cloud a tendance à gagner en cas de demande variable ou de pointe, de projets de courte durée et de charges de travail qui nécessiteraient autrement un deuxième centre de données pour la redondance. Une comparaison crédible doit inclure le personnel, l’alimentation, les cycles de rafraîchissement, les frais de sortie et les plans de support des deux côtés.

Que signifie « basé sur le cloud » par rapport aux logiciels sur site ?

Les logiciels basés sur le cloud sont hébergés et entretenus par le fournisseur et accessibles via un réseau, généralement par abonnement. Le logiciel sur site est installé dans l’environnement du client et corrigé par l’équipe du client. Les éditions basées sur le cloud sont continuellement mises à jour ; Les éditions sur site sont mises à jour selon le calendrier du client, ce qui constitue un avantage pour le contrôle des modifications et un inconvénient pour la rapidité des fonctionnalités.

SharePoint doit-il être sur site ou dans le cloud ?

SharePoint Server reste approprié pour les organisations ayant des mandats stricts de résidence des données, de lourdes personnalisations des solutions de batterie de serveurs ou des investissements sur site existants dont la refonte serait coûteuse. SharePoint dans Microsoft 365 convient aux organisations qui souhaitent des mises à jour continues des fonctionnalités, une collaboration moderne et aucune maintenance de batterie de serveurs. La migration nécessite généralement de retravailler les personnalisations et l’authentification, alors planifiez cet effort plutôt que de vous lancer dans une migration simple (lift-and-shift).

SAP doit-il fonctionner sur site ou dans le cloud ?

SAP S/4HANA sur site convient aux organisations ayant des personnalisations approfondies, un contrôle strict sur le calendrier de publication et des contraintes réglementaires sur l’emplacement des données. SAP S/4HANA Cloud et RISE avec SAP conviennent aux organisations désireuses d’adopter des principes de « clean core » et des extensions standardisées en échange de coûts d’infrastructure réduits. L’intégration avec des systèmes non SAP est le facteur décisif dans la plupart des cas, car les données SAP doivent presque toujours atteindre les plateformes cloud CRM, d’analyse et de chaîne d’approvisionnement.

Comment connecter l’intégration de données sur site et dans le cloud ?

L’intégration cloud sur site utilise généralement un tunnel sécurisé ou une interconnexion privée entre le réseau d’entreprise et le fournisseur cloud, avec un outil d’intégration de données cloud qui extrait les données de sources sur site et chargé dans des cibles cloud. Le problème le plus difficile est sémantique : mapper le schéma de chaque système sur un modèle partagé et indépendant des applications afin que les entités telles que le client, la commande et le produit signifient partout la même chose.

Des normes ouvertes telles que Cloud Information Model, OData et RDF/OWL existent pour prendre en charge l’interopérabilité des entreprises open source pour le cloud et rendre ce mappage réutilisable plutôt que sur mesure. Pour ceux qui effectuent des recherches sur la connectivité sur site et dans le cloud, les évaluations des outils d’intégration de données dans le cloud peuvent aider à identifier la meilleure plate-forme pour ces besoins.