On-premise ou cloud : comment trancher workload par workload
On-premise ou cloud : critères de décision pour DSI, coûts réels, rapatriement, souveraineté et hybride. Une méthode pour arbitrer workload par workload.
On-premise ou cloud : comment trancher workload par workload
La bonne question n’est pas « on-premise ou cloud ? » pour tout le système d’information, mais « où chaque workload doit-il tourner, et pourquoi ? ». Un hébergement sur site garde le contrôle et un coût prévisible. Le cloud apporte l’élasticité et la vitesse de mise en service. Le choix se joue sur le profil de charge, les contraintes réglementaires, les compétences disponibles et le coût complet sur la durée.
Cet article donne les définitions utiles, les critères qui pèsent vraiment, le cas du rapatriement et une méthode pour présenter l’arbitrage à votre comité de direction.
Arbitevaarbiteva.comArbitrez chaque workload avec clartéARBITEVA relie données techniques, financières et opérationnelles pour éclairer vos décisions sur les coûts, les risques et les exigences.Découvrir la plateforme
Table des matières
Key takeaways
Les points clés
Ce que recouvrent vraiment les deux termes
Les critères qui font vraiment la décision
Le rapatriement : réviser, pas renier
L’hybride comme architecture durable
Une méthode en cinq étapes pour arbitrer
Notre point de vue
Passer de l’analyse à la décision avec ARBITEVA
FAQ
Sources
Key takeaways
Le cloud se définit par des caractéristiques précises, pas par « l’infrastructure de quelqu’un d’autre ». Le on-premise reste un modèle d’investissement et de contrôle.
Aucun des deux n’est systématiquement moins cher : cela dépend du profil de charge et de la phase de vie de l’application.
Le rapatriement n’est pas un retour en arrière. C’est une révision d’arbitrage, souvent déclenchée par des coûts imprévus, la latence ou la conformité.
Les compétences disponibles pèsent autant que le prix du matériel.
Un arbitrage défendable se documente : scénarios chiffrés, risques, effort, stratégie de sortie.
(Titre de section à adapter : voir ci-dessous « Les points clés ».)
Les points clés
Ces cinq points résument la décision. Le détail suit, avec un exemple fictif à la fin de la méthode.
Ce que recouvrent vraiment les deux termes
Le NIST définit le cloud par cinq caractéristiques essentielles : libre-service à la demande, accès réseau étendu, mutualisation des ressources, élasticité rapide et service mesuré. Un serveur loué à un hébergeur, sans ces propriétés, n’est donc pas du cloud au sens strict.
Le on-premise désigne l’inverse sur chacun de ces points : vous achetez, installez et administrez le matériel dans vos locaux ou votre datacenter. Le guide FinOps sur les datacenters reprend cette distinction du NIST pour comparer les deux mondes.
Côté finances, la différence se lit en CAPEX et OPEX. Le sur-site mobilise un investissement initial, puis des coûts d’exploitation. Le cloud facture à l’usage. Ce point compte pour votre direction financière : il change l’amortissement, la visibilité budgétaire et la façon dont une dérive se manifeste.
SaaS, IaaS, on-premise : ne pas tout mélanger
Une application en SaaS et une machine virtuelle en IaaS n’engagent pas les mêmes responsabilités. En SaaS, l’éditeur gère presque tout. En IaaS, vous gardez système, patchs et sécurité applicative. Comparer « cloud » et « on-premise » sans préciser le modèle de service fausse le chiffrage.
Les critères qui font vraiment la décision
Le profil de charge
Une charge variable, saisonnière ou en phase de test profite de l’élasticité. Une charge stable, dimensionnée de longue date, supporte mal une facturation à l’usage permanente. C’est le premier tri à faire, et il se fait application par application.
Le coût complet, pas le prix de l’instance
L’Uptime Institute indique que 45 % des charges IT restent dans des installations d’entreprise en 2025. Beaucoup d’opérateurs estiment que le sur-site peut coûter moins cher que le cloud public ou la colocation, selon la charge et le cycle de vie. Le « selon » est la partie importante.
Pour comparer, intégrez au minimum :
le matériel, son renouvellement, l’énergie et l’hébergement physique ;
les licences et le support ;
le temps des équipes, y compris l’astreinte ;
les frais de sortie de données et le réseau côté cloud ;
le coût d’une indisponibilité.
Les compétences
Le sur-site demande des équipes qui savent l’exploiter. Selon la même enquête Uptime, 46 % des opérateurs peinent à recruter des profils qualifiés. Si vous ne pouvez pas staffer l’exploitation, l’économie sur le matériel s’évapore.
Souveraineté, conformité, latence
Certaines données ou certains systèmes imposent un hébergement maîtrisé. En France, la qualification SecNumCloud de l’ANSSI, dans sa version 3.2 de 2022, intègre des critères d’immunité face aux législations extraterritoriales. Elle montre qu’un cloud peut aussi répondre à une exigence de souveraineté : la frontière n’est donc pas « sur site = sûr, cloud = risqué ». Pour une charge industrielle sensible à la latence, la proximité physique reste en revanche un argument technique réel.
La réversibilité
Posez la question avant de signer : comment sortez-vous, en combien de temps, avec quelles données et à quel coût ? Une stratégie de sortie pèse aussi sur le choix initial.
Le rapatriement : réviser, pas renier
Le rapatriement consiste à ramener des charges du cloud public vers du sur-site ou un cloud privé. TechTarget cite parmi les causes les coûts imprévus, les exigences de performance et de latence, la souveraineté et la conformité, et la volonté d’éviter l’enfermement chez un fournisseur. La presse française décrit le même mouvement, porté par les coûts et la complexité des environnements de cloud public.
Une cause revient souvent en amont : le « lift and shift ». Migrer une application telle quelle, sans la repenser, conduit à des coûts plus élevés que prévu, comme le décrit ce retour d’expérience publié par la CNCF. Le problème vient alors de la migration, pas du cloud.
Avant de rapatrier, vérifiez que vous avez essayé d’optimiser. Une démarche FinOps (visibilité, responsabilité partagée, rightsizing) corrige parfois l’écart sans déménager. Et si vous rapatriez, comptez le coût du retour : matériel, compétences, délais.
L’hybride comme architecture durable
Selon la CNCF, l’hybride et le multicloud sont devenus la norme pour les grandes organisations, non comme une étape de transition mais comme une approche de long terme. Le cloud absorbe la variabilité, le sur-site garde le contrôle et la prévisibilité là où ils comptent.
Le revers : deux mondes à piloter. Le groupe de travail FinOps Foundation souligne que la maturité vient de l’intégration de la vue FinOps, au rythme de la consommation, et de la gestion financière IT, sur les cycles longs, à la fois pour le cloud et les datacenters. La pratique FinOps s’applique d’ailleurs aussi au sur-site.
Une méthode en cinq étapes pour arbitrer
Cartographiez les applications : propriétaire, criticité, dépendances, données manipulées.
Classez chaque charge : variable ou stable, sensible ou non, latence critique ou non.
Chiffrez au moins deux scénarios par application, sur la même durée et avec les mêmes postes de coût.
Pesez gains, risques et efforts, y compris la réversibilité et les compétences.
Décidez et documentez l’arbitrage, avec les hypothèses, pour pouvoir le défendre puis le réviser.
Exemple fictif
Imaginons, à titre d’illustration, une ETI avec deux applications. La première, un portail client aux pics saisonniers, tourne sur des serveurs sous-utilisés l’essentiel de l’année. La seconde, un traitement de données stable et volumineux, est hébergée dans le cloud public depuis trois ans.
L’analyse conclut : le portail gagne à passer en cloud, pour l’élasticité. Pour le traitement stable, le scénario sur-site est chiffré, mais l’équipe n’a pas de capacité d’exploitation. L’arbitrage retenu est donc un cloud privé chez un prestataire, avec une revue dans douze mois. Les chiffres sont inventés ; la logique, elle, est celle à reproduire.
Notre point de vue
Nous voyons le même piège revenir : on débat d’un modèle d’hébergement en général, alors que la décision se prend sur des applications précises, avec des données dispersées entre le CMDB, les factures cloud, les tableaux financiers et l’avis des équipes. Chacun apporte alors son chiffre, et les chiffres ne se recoupent pas.
Selon nous, un arbitrage tient devant un comité de direction quand quatre éléments sont réunis : des données techniques, financières et opérationnelles reliées, des scénarios comparables, des risques et efforts explicites, et une trace des hypothèses. Le FinOps y contribue, mais seul, il voit la facture sans voir le contexte : propriétaire, architecture, risque. Ce contexte évite les optimisations qui dégradent la performance.
Nous ne défendons ni le cloud ni le sur-site par principe. Nous défendons une décision qu’on peut expliquer.
— lakraa
Passer de l’analyse à la décision avec ARBITEVA
Si vos données sont éparpillées, la plateforme de décision ARBITEVA relie données techniques, financières et opérationnelles pour comparer des scénarios chiffrés et construire un plan d’action. Pour la maîtrise des coûts cloud et hybrides, voir notre approche FinOps. Pour préparer un business case ou défendre un arbitrage devant la direction, notre accompagnement DSI et CTO est là pour cela.
FAQ
Quelle est la différence entre le SaaS et le on-premise ?
En SaaS, l’éditeur héberge, exploite et met à jour l’application, que vous payez par abonnement. En on-premise, vous installez le logiciel sur votre infrastructure et vous en assurez l’exploitation, les mises à jour et la sécurité. Le SaaS réduit la charge opérationnelle, le on-premise laisse plus de maîtrise.
Le cloud est-il toujours moins cher que le on-premise ?
Non. L’Uptime Institute relève que beaucoup d’opérateurs jugent le sur-site moins coûteux dans certains cas, selon la charge et le cycle de vie. Comparez le coût complet, équipes comprises, sur plusieurs années.
Quels sont les principaux inconvénients du cloud ?
Les coûts peuvent dériver faute de pilotage, la dépendance à un fournisseur complique la sortie, et la conformité ou la latence peuvent poser problème pour certaines charges. Ces risques se traitent par la gouvernance, la réversibilité et le choix du bon modèle par application.
Quand faut-il envisager un rapatriement ?
Quand des coûts imprévus persistent malgré l’optimisation, qu’une exigence de latence ou de souveraineté l’impose, ou que la dépendance fournisseur devient un risque. Chiffrez d’abord le coût du retour et vérifiez que vous avez les compétences pour exploiter.
Sources
TechTarget, What is cloud repatriation and what are the leading causes
Le Monde Informatique, Coûts et complexité alimentent les stratégies de rapatriement cloud