Cloud, on-premise et hybride, choisir son architecture d'hébergement
Cloud public, cloud privé, on-premise ou architecture hybride, le choix d'hébergement structure tout le reste du système d'information. Le guide d'arbitrage pour DSI de PME et ETI, avec les critères qui comptent vraiment en 2026.
Hériter d’un parc on-premise vieillissant pendant qu’un éditeur SaaS pousse au cloud public et qu’un intégrateur souffle « hybride », c’est le quotidien de beaucoup de DSI en PME et ETI françaises en 2026. La question n’est plus de savoir si le cloud a gagné, parce que le cloud public est partout dans la bureautique et la collaboration, mais de décider ce qui doit rester en interne, ce qui doit basculer, et selon quelle architecture. Le mauvais arbitrage ne se paye pas sur la facture du mois suivant, il se paye trois ans plus tard sur la performance, la conformité et la dépendance contractuelle. Cet article structure les six critères qui comptent vraiment et donne une grille de lecture pour bâtir une infrastructure IT alignée sur le métier, pas sur les modes du marché.
Ce que recouvrent vraiment cloud public, cloud privé et on-premise
Les trois modèles sont devenus des mots-valises, et c’est précisément ce flou qui rend l’arbitrage difficile. Avant de comparer, il faut nommer précisément ce que chaque option recouvre côté responsabilité, côté économique et côté contraintes.
L’on-premise, contrôle total et facture en capex
L’on-premise consiste à exploiter son propre datacenter, qu’il occupe une salle serveur dédiée dans les locaux ou une baie en colocation. L’entreprise possède le matériel, gère les licences hyperviseurs, opère les sauvegardes, supervise les sondes de température et porte la responsabilité de continuité de service. Le modèle économique est en capex avec un amortissement sur quatre à six ans, et il suppose une équipe interne ou un infogéreur capable de tenir la production. Le rachat de VMware par Broadcom en 2023 et la refonte tarifaire qui a suivi a rebattu les cartes pour beaucoup de DSI qui découvrent que leur socle de virtualisation coûte deux à trois fois plus cher au renouvellement. Cette inflation a poussé une partie du marché à reconsidérer le sujet, sans pour autant signer la fin de l’on-premise.
Le cloud privé, dédié et opéré dans un datacenter tiers
Le cloud privé est une infrastructure dédiée hébergée chez un prestataire spécialisé, accessible via un lien privé ou un VPN d’entreprise. Contrairement au cloud public, les ressources ne sont pas mutualisées, ce qui supprime les effets de voisinage et autorise des engagements de performance fermes. Le datacenter porte les obligations de disponibilité, généralement matérialisées par une certification Tier III ou Tier IV, et le prestataire opère la couche d’infrastructure jusqu’à l’OS ou jusqu’à la plateforme selon le périmètre contractualisé. Le modèle est en opex récurrent, avec une visibilité budgétaire bien supérieure à celle d’un cloud public à l’usage. C’est l’option qui se rapproche le plus d’une externalisation pure et simple du datacenter.
Le cloud public, mutualisation et facturation à l’usage
Le cloud public désigne les ressources opérées par les grands acteurs mondiaux (AWS, Azure, Google Cloud) ou par les hébergeurs souverains européens, et facturées à la consommation. L’élasticité est l’argument fort, parce que la capacité s’ajuste en quelques minutes au volume réel d’usage. Le revers est connu, qu’il s’agisse de la facture qui dérive vite si la consommation n’est pas pilotée, des coûts de sortie de données (egress) qui rendent les bascules inter-fournisseurs douloureuses, ou de la complexité des catalogues qui demande une expertise dédiée. Le cloud public excelle pour les applications SaaS de bureautique, pour les pics de charge ponctuels et pour les environnements de développement. Il est moins évident à manier quand l’application est ancienne, latence-sensible ou attachée à des volumes de données massifs.

Le cloud hybride, modèle dominant pour la PME et l’ETI en 2026
Une fois les trois briques posées, la réalité du terrain saute aux yeux. Très peu d’entreprises basculent à 100% dans un seul modèle, et la quasi-totalité des SI de PME et ETI fonctionnent déjà en architecture mixte sans toujours l’assumer comme telle.
Pourquoi l’architecture hybride s’impose dans les SI réels
Le cloud hybride n’est pas une mode marketing, c’est la conséquence mécanique de deux dynamiques opposées. D’un côté, l’inertie applicative qui maintient en interne les ERP métier, les outils industriels ou les bases de données historiques qui ne supportent ni la latence ni le coût d’une bascule. De l’autre, l’adoption massive du SaaS sur la bureautique, la messagerie, le CRM et la collaboration, qui place mécaniquement une partie du SI dans le cloud public. Entre les deux, beaucoup d’entreprises maintiennent un cloud privé pour héberger les briques critiques qu’elles veulent contrôler sans assumer le poids d’un datacenter interne. L’architecture hybride n’est pas un choix de design, c’est la photographie de ce qui s’est construit application après application.
Les patterns d’hybridation les plus fréquents en PME
Trois patterns reviennent dans la majorité des audits d’infrastructure. Le premier consiste à garder la production en on-premise et à externaliser la sauvegarde et le PRA dans un cloud privé géographiquement distant, ce qui permet de bâtir un PRA en architecture hybride sans dupliquer toute la production. Le deuxième conserve un ERP ou un logiciel métier en interne pendant que toute la périphérie (bureautique, CRM, marketing automation) bascule en SaaS, le défi étant alors la cohérence des données entre les deux mondes. Le troisième met la production sur cloud privé et garde du cloud public pour l’élasticité, typiquement pour absorber des pics saisonniers ou exécuter des traitements analytiques ponctuels. Dans tous les cas, la qualité de l’interconnexion VPN entre on-premise et cloud privé conditionne la performance ressentie par les utilisateurs.
Les vrais critères d’arbitrage entre cloud et on-premise
Le débat cloud contre on-premise est rarement tranché par un seul facteur. Sept critères concentrent l’essentiel de la décision, et leur pondération dépend du profil de l’entreprise. La grille qui suit n’est pas un classement absolu, c’est un outil de lecture qui doit être croisé avec la réalité métier.
Comparatif cloud public, cloud privé, on-premise et hybride sur 7 critères
| Critère | Cloud public | Cloud privé | On-premise | Hybride |
|---|---|---|---|---|
| Coût initial (capex) | Quasi nul | Faible | Élevé | Moyen |
| Coût récurrent (opex) | Variable, peut déraper | Stable et prévisible | Faible une fois amorti | Mixte |
| Maîtrise et conformité | Limitée | Forte | Maximale | Forte |
| Performance d’accès | Dépend du lien Internet | Excellente via lien dédié | Excellente en local | Excellente côté privé |
| Scalabilité | Maximale | Bonne mais bornée | Limitée | Bonne, ciblée |
| Souveraineté des données | Faible à moyenne | Forte si hébergeur FR | Maximale | Modulable par brique |
| Expertise interne requise | Cloud engineering | Modérée | Forte sur l’infra | Pluridisciplinaire |
Cette grille appelle plusieurs lectures. Sur le coût total de possession, le cloud public n’est pas systématiquement le moins cher, parce que sa facturation à l’usage devient pénalisante dès que la charge se stabilise à un niveau élevé et prévisible. Sur la conformité réglementaire, le cloud public hyperscaler pose des questions structurelles d’extraterritorialité du droit américain qu’aucune clause contractuelle ne résout complètement, ce qui pousse certaines fonctions vers le cloud privé européen ou vers l’on-premise. Sur la performance d’accès, le cloud public ne tient ses promesses que si la connectivité du site est dimensionnée en conséquence, ce qui réintroduit la question du raccordement fibre dans la décision. Et sur l’expertise interne, beaucoup de DSI sous-estiment qu’opérer du cloud public à l’échelle demande une équipe de cloud engineering qui coûte cher et qui se recrute mal.
Cloud souverain français, ce que la souveraineté change concrètement
Le mot souveraineté est galvaudé, et c’est dommage parce que la question est réelle et opérationnelle. La distinction entre ce qui relève du marketing et ce qui relève d’engagements vérifiables est devenue un sujet d’arbitrage à part entière depuis 2024.
Cloud souverain et cloud de confiance, deux niveaux à ne pas confondre
L’hébergement cloud souverain entreprise désigne une infrastructure opérée par une entité de droit européen, hébergée dans l’Union européenne, et immunisée contre l’application extraterritoriale du droit américain, en particulier le Cloud Act et FISA 702. La qualification SecNumCloud délivrée par l’ANSSI matérialise ce niveau d’exigence, avec un cahier des charges très lourd sur la sécurité, la gouvernance, la maintenance et la chaîne d’approvisionnement matérielle et logicielle. À côté, le « cloud de confiance » désigne des offres labellisées par des opérateurs européens en partenariat avec des hyperscalers américains, dont le statut juridique réel fait débat dans la communauté cyber. La nuance compte parce que la qualification SecNumCloud est aujourd’hui la référence pour les fonctions les plus sensibles.
Quand la souveraineté devient un critère contractuel
Le sujet n’est plus réservé aux opérateurs d’importance vitale. Depuis l’entrée en application de NIS2 en octobre 2024 et sa transposition en droit français, des milliers d’entités essentielles et importantes voient leurs obligations renforcées, et beaucoup d’ETI ainsi que de PME du tissu industriel sont désormais concernées. Les sous-traitants de grands comptes santé, défense ou énergie reçoivent par ailleurs des clauses contractuelles qui exigent un hébergement en France ou un cloud privé qualifié.
NIS2 et souveraineté, le périmètre s’est élargi en silence. La directive NIS2, transposée en France fin 2024 et début 2025, multiplie par dix environ le nombre d’entités couvertes par rapport à NIS1. La pression réglementaire NIS2 sur les PME pousse à clarifier l’arbitrage d’hébergement bien avant le premier contrôle.
La migration cloud, étapes, durée et pièges à éviter
Quand l’arbitrage débouche sur un mouvement vers le cloud, la qualité de l’exécution pèse davantage que la qualité du choix initial. Une migration cloud mal préparée annule en six mois les bénéfices attendus, et les exemples de retour arrière coûteux existent dans tous les secteurs.
Les 5 étapes d’une migration cloud bien menée
- L’audit du parc applicatif cartographie chaque application, ses dépendances, sa criticité métier, son éligibilité technique au cloud et son modèle de consommation. C’est l’étape qui prend le plus de temps et qui détermine la qualité du plan.
- La classification par stratégie de migration retient pour chaque application une cible entre le rehosting (lift-and-shift), le replatforming (adaptation légère), le refactoring (refonte) ou le retirement (mise au rebut). Toutes les applications ne méritent pas le même traitement.
- Le choix de la cible d’hébergement affecte à chaque application son environnement de destination, qu’il s’agisse du cloud public, du cloud privé, du maintien en on-premise ou d’un SaaS de remplacement. Cette étape arbitre aussi la question souveraineté brique par brique.
- Le plan de bascule séquence les migrations dans le temps en commençant par les applications à faible risque et à fort levier d’apprentissage, avant d’attaquer les briques critiques. Le plan intègre les fenêtres métier et les dépendances entre applications.
- Le run post-migration met en place la supervision, le FinOps, la gouvernance et l’optimisation continue, parce qu’un cloud non piloté est un cloud qui dérive en coût et en sécurité.
Les pièges classiques que paient les PME mal accompagnées
Quatre erreurs reviennent systématiquement dans les retours d’expérience. La bande passante sous-dimensionnée transforme une application performante en local en application lente une fois dans le cloud, et la correction passe par un upgrade du raccordement fibre rarement budgété au départ. Les coûts de sortie de données des hyperscalers ne sont visibles qu’au moment où on cherche à quitter le fournisseur, et ils peuvent atteindre plusieurs dizaines de milliers d’euros pour un volume significatif. Les applications legacy qui chattent intensivement avec la base de données s’effondrent dès qu’un trajet réseau s’ajoute entre les deux couches, ce qui interdit le lift-and-shift simple. Et la dette technique masquée, sous-jacente à des applications restées trop longtemps sans évolution, apparaît au pire moment, c’est-à-dire pendant la bascule. Mieux vaut cadrer une migration cloud étape par étape plutôt que de subir ces écueils en production.
Quand l’on-premise reste la bonne réponse en 2026
Le discours dominant pousse au tout cloud, et pourtant l’on-premise garde du sens dans plusieurs configurations qu’il faut nommer sans complexe. La position « cloud par défaut » est une simplification qui ignore la diversité réelle des SI.
Le premier cas concerne les applications à très forte volumétrie de données locales, qu’il s’agisse d’industrie manufacturière avec capteurs en pagaille, d’imagerie médicale, d’archivage audiovisuel ou de calcul scientifique. Le coût de stockage et surtout le coût d’egress dans le cloud public rendent l’équation économique défavorable, et la latence d’accès en local reste imbattable. Le second cas couvre les contraintes de souveraineté maximale quand aucun cloud souverain qualifié n’offre la stack technique requise, ce qui reste fréquent dans la défense, le renseignement et certaines fonctions santé. L’on-premise est alors la seule réponse pleinement crédible. Le troisième cas est plus prosaïque mais très répandu, celui d’un parc on-premise récent et non amorti, typiquement après un investissement lourd il y a deux ou trois ans. Casser un amortissement en cours pour basculer vers le cloud relève de l’erreur de gestion, sauf à pouvoir démontrer un ROI cloud court qui rembourse la valeur résiduelle de l’existant.
Il faut ajouter un cas plus discret. Les PME industrielles avec un site unique, un SI stable et une équipe IT modeste mais compétente n’ont parfois aucun intérêt à migrer. Leur infrastructure tourne, leurs coûts sont sous contrôle, et le cloud leur apporterait surtout de la complexité et une dépendance contractuelle nouvelle. Le tout-cloud n’est pas un horizon obligatoire, et un DSI qui résiste à la pression marketing pour conserver une infrastructure on-premise pertinente fait correctement son métier.
Choisir un hébergeur cloud sur mesure plutôt qu’un cloud public mondial
Quand le choix se porte sur l’externalisation, reste la question du type d’opérateur. Le marché propose deux logiques très différentes, et la confusion entre les deux conduit régulièrement à des erreurs d’arbitrage.
Hyperscaler ou hébergeur de proximité, la question n’est pas la taille
L’hyperscaler propose un catalogue de services managés très large, une présence mondiale, une élasticité quasi infinie et un écosystème d’outils et de partenaires gigantesque. L’hébergeur français de taille humaine joue sur un autre registre, fait de proximité commerciale, d’interlocuteur unique, d’accompagnement projet et de capacité à dimensionner une architecture sur-mesure. La question n’est pas de savoir lequel est « meilleur », parce que les deux répondent à des besoins différents. Une grande ETI internationale aura sans doute besoin des deux dans son SI, l’hyperscaler pour les fonctions à très forte élasticité et l’hébergeur français pour les fonctions à enjeu de proximité ou de souveraineté.
Ce qu’apporte un hébergeur cloud français à une PME ou une ETI
Pour une PME ou une ETI française, un hébergeur cloud sur mesure français apporte trois choses concrètes que les hyperscalers ne savent pas faire au même niveau. La première est l’accompagnement humain, avec des interlocuteurs identifiés qui connaissent l’historique du compte, ce qui réduit drastiquement le coût d’opération pour une DSI à effectif limité. La deuxième est la conformité européenne native, sans clause à négocier ni risque d’extraterritorialité résiduel. La troisième est la capacité d’intégration, parce que l’hébergeur qui maîtrise aussi les briques réseau peut bâtir une architecture cohérente où l’hébergement cloud opéré en France dialogue proprement avec l’on-premise via des liens privés, et où la performance d’accès au cloud privé via fibre dédiée est garantie contractuellement. C’est cette continuité réseau-hébergement qui fait la différence sur le ressenti utilisateur, davantage que la sophistication du portail self-service.
Questions fréquentes sur le cloud, l’on-premise et l’hybride
Quelle est la différence entre cloud public, cloud privé et on-premise ?
L’on-premise désigne une infrastructure IT hébergée dans les locaux de l’entreprise et gérée par elle, le cloud privé est un environnement dédié opéré dans le datacenter d’un prestataire, et le cloud public repose sur des ressources mutualisées facturées à l’usage. La différence porte autant sur le modèle économique (capex contre opex) que sur le degré de contrôle et la nature des engagements de sécurité. L’on-premise maximise le contrôle au prix d’une responsabilité opérationnelle complète, le cloud privé externalise l’infrastructure tout en gardant la dédicacité, et le cloud public optimise l’élasticité et le coût d’entrée au prix d’une mutualisation des ressources sous-jacentes.
Qu’est-ce qu’une architecture cloud hybride ?
Une architecture cloud hybride combine au moins deux environnements distincts, typiquement de l’on-premise et du cloud privé ou public, reliés par un réseau privé. Elle permet de garder en interne les applications les plus sensibles ou les plus volumineuses tout en exploitant l’élasticité du cloud pour le reste, et c’est le modèle qui domine aujourd’hui dans les PME et ETI françaises. La qualité d’une architecture hybride dépend largement de la solidité de l’interconnexion entre les environnements et de la cohérence de la gestion des identités et des sauvegardes.
Combien coûte une migration cloud pour une PME ?
Une migration cloud pour une PME se chiffre généralement entre 20 000 et 150 000 euros selon le périmètre, sans compter le coût récurrent du cloud lui-même qui dépend du volume et de l’usage. La fourchette dépend du nombre d’applications, du niveau de refonte demandé et du choix entre lift-and-shift et vraie modernisation. Une migration mal cadrée peut doubler cette enveloppe en run, parce que les coûts cloud non pilotés dérivent vite et que les corrections post-migration coûtent plus cher que la prévention.
Le cloud est-il moins cher que l’on-premise sur cinq ans ?
Le cloud n’est pas systématiquement moins cher que l’on-premise sur cinq ans, et la réponse dépend du profil de charge. Pour une charge stable et prévisible, l’on-premise amorti reste souvent compétitif et même favorable une fois passée la quatrième année. Pour une charge variable ou en forte croissance, le cloud public devient plus économique grâce à l’élasticité. Les comparaisons réalistes intègrent les coûts cachés, notamment la sortie de cloud, la bande passante et l’expertise interne requise pour piloter l’environnement.
Qu’est-ce qu’un cloud souverain et qui doit s’en préoccuper ?
Un cloud souverain est un environnement hébergé en France ou dans l’Union européenne, opéré par une entité de droit européen, et qualifié SecNumCloud par l’ANSSI quand le niveau d’exigence est maximal. Les opérateurs d’importance vitale, les opérateurs de services essentiels, les acteurs santé et désormais une grande partie des ETI couvertes par NIS2 ont intérêt à intégrer ce critère dans leur arbitrage cloud. Au-delà de l’obligation réglementaire, le cloud souverain protège contre les risques d’extraterritorialité du droit américain qui restent une zone grise pour les hyperscalers de droit américain.
Le cloud public est-il conforme RGPD pour une entreprise française ?
Un cloud public peut être conforme RGPD à condition de contractualiser les bonnes garanties, notamment sur la localisation des données dans l’Union européenne et sur les transferts internationaux. Le sujet épineux reste l’extraterritorialité du droit américain (Cloud Act, FISA 702) pour les hyperscalers de droit américain, même quand les données sont physiquement stockées en Europe. Le DPO et le juridique doivent statuer au cas par cas selon la nature des données, et un cloud souverain européen reste l’option la plus défensive quand des données sensibles sont en jeu.
NIS2 oblige-t-elle à passer en cloud souverain ?
NIS2 n’impose pas formellement le cloud souverain mais durcit les exigences de sécurité et de continuité pour des milliers d’entités essentielles et importantes, dont des ETI et PME qui n’étaient pas concernées avant. Dans la pratique, le cloud souverain qualifié SecNumCloud devient le moyen le plus simple de démontrer la conformité pour les fonctions les plus critiques, sans pour autant s’imposer pour tout le SI. Beaucoup d’entités vont donc opter pour une architecture hybride avec les fonctions sensibles en cloud souverain et le reste sur un cloud plus standard.
Comment choisir entre un hyperscaler et un hébergeur cloud français ?
Un hyperscaler convient quand la priorité est l’étendue du catalogue de services managés, l’élasticité massive et l’écosystème mondial. Un hébergeur cloud sur mesure français a l’avantage quand l’enjeu est la conformité européenne, la qualité de l’accompagnement, l’interlocuteur unique et la capacité à dimensionner une architecture hybride au plus près des besoins métier. Les deux logiques peuvent cohabiter dans un même SI, et beaucoup d’ETI françaises construisent aujourd’hui un modèle où les fonctions critiques sont chez un hébergeur français et les fonctions à élasticité forte chez un hyperscaler.
Peut-on faire cohabiter Microsoft 365 avec un cloud privé français ?
Microsoft 365 cohabite très bien avec un cloud privé français dédié aux applications métier et aux données sensibles, et cette configuration est courante dans les PME et ETI. Le périmètre Microsoft 365 reste sur Azure pour la bureautique et la collaboration, pendant que l’ERP, le CRM critique ou les serveurs de fichiers sensibles sont hébergés dans un cloud privé en France. La cohérence se joue sur l’identité fédérée via Entra ID et sur la sécurisation des flux entre les deux environnements.
Quelle bande passante prévoir pour migrer vers le cloud ?
Une migration vers le cloud demande de revoir la bande passante du site principal et souvent de basculer vers une fibre optique dédiée de type FTTO avec une garantie de temps de rétablissement. Le seuil de bascule se situe en pratique autour de 100 Mb/s symétriques pour une PME, davantage si les usages incluent de la sauvegarde lourde ou du transfert de médias. Une bande passante sous-dimensionnée annule les bénéfices attendus du cloud et transforme une application performante en local en application lente une fois externalisée.