Cloud ou Hardware On-prem ?

L’illusion de la vitesse : pourquoi un démarrage rapide dans le cloud peut ralentir une entreprise

Dans l’industrie IT, il est largement admis que cloud rime avec rapidité. Du point de vue du time-to-market, c’est souvent vrai. Déployer un cluster Kubernetes via des services managés (EKS, GKE et plateformes similaires) prend de 5 à 15 minutes, tandis que l’acquisition de matériel physique, sa logistique et sa mise en production peuvent nécessiter plusieurs semaines, voire des mois.

Cependant, il existe une distinction fondamentale entre la vitesse de déploiement et la vitesse de traitement des données (exécution et latence).
Un scénario typique de « piège de scalabilité » se déroule ainsi : une entreprise lance son service dans le cloud. À l’étape MVP, les charges sont légères, les coûts modérés et la flexibilité maximale. Avec l’augmentation des volumes de données et des transactions, des problèmes cachés apparaissent :

• Écart financier : les coûts des ressources augmentent de façon non linéaire. Les architectures complexes engendrent des dépenses liées au trafic sortant (egress fees) et aux opérations d’entrée/sortie (IOPS), difficiles à prévoir dès le départ.

• Variabilité technique : les ingénieurs rencontrent l’effet dit « noisy neighbor ». Malgré l’isolation logique, les machines virtuelles partagent la cache L3 du CPU et la bande passante mémoire. Une requête de base de données qui prend normalement 2 ms peut ralentir ponctuellement de 20 à 100 %, atteignant 4–5 ms. Pour des systèmes à forte charge, ce type de jitter devient un goulot d’étranglement critique.

Point clé de l’expert : « Si le cloud permet un démarrage rapide, pourquoi finissons-nous par surpayer des vCPU moins performants que les cores physiques, tout en perdant le contrôle de la prévisibilité des temps de réponse sur des charges stables ? »

Les serveurs on-prem offrent un contrôle direct sur le matériel, permettant l’usage de technologies de kernel bypass pour minimiser la latence. Le cloud, en revanche, vend de l’abstraction, intégrant le risque d’indisponibilité et l’amortissement dans son modèle de prix.

Tableau comparatif

Lancement et montée en charge – l’avantage du cloud

Pour des projets à forte incertitude, saisonnalité ou demande fluctuante, le cloud reste le choix le plus rationnel, offrant une flexibilité critique.

Sur des marchés très concurrentiels, la rapidité de validation prime. L’accès à des solutions PaaS comme Kubernetes managé ou DBaaS permet aux équipes de se concentrer directement sur le code, contournant la longue phase de conception physique d’un data center. Les erreurs architecturales sont peu coûteuses dans le cloud : les ressources peuvent être supprimées instantanément, tandis qu’un serveur acheté pour un usage erroné devient un actif illiquide. Cet avantage clé de l’IaaS est renforcé par l’élasticité, difficile à reproduire on-prem.

Exemple : une campagne marketing multiplie par dix le trafic pendant 48 heures. Les groupes d’auto-scaling correctement configurés ajoutent automatiquement des instances à mesure que l’utilisation CPU augmente et les retirent lorsque la demande baisse, avec des temps de réaction de 30 secondes à deux minutes. La logique économique est simple : paiement uniquement pour les ressources effectivement consommées. En on-prem, le matériel dimensionné pour les pics resterait inactif environ 95 % de l’année.

Cet avantage s’estompe lorsque les charges deviennent constantes. L’analyse TCO montre qu’avec une utilisation 24/7, le coût de location d’une VM atteint celui de l’achat complet d’un serveur physique en 8–12 mois. Sur un cycle matériel typique de cinq ans, le cloud peut devenir 2 à 3 fois plus cher à long terme, incluant R&D, coût énergétique et capacité de réserve.

Hardware On-prem – contrôle, stabilité et efficacité des coûts

Migrer vers une infrastructure propriétaire ou des serveurs bare-metal hébergés chez des fournisseurs marque souvent une phase de maturité, appelée “cloud repatriation”, motivée par la performance et l’économie.

Les performances sont supérieures en environnement on-prem grâce à l’absence de couches de virtualisation et à la possibilité d’optimiser les systèmes. Les études montrent que les hyperviseurs consomment entre 5 et 15 % de la CPU, alors que sur du matériel dédié, la capacité complète est disponible pour les applications. De plus, l’optimisation du kernel et les technologies de kernel bypass (DPDK ou io_uring) peuvent réduire la latence I/O de 50 à 80 % en éliminant les context switches.

Les besoins en latence varient selon les cas d’usage. Pour les applications web, la différence entre 20 et 25 ms est négligeable. Dans les systèmes RTB, la latence acceptable peut atteindre 80–100 ms, permettant des approches hybrides. Dans le HFT, les temps de réponse inférieurs à 100 microsecondes sont impératifs, rendant les clouds publics techniquement inadaptés à cause du jitter réseau ; seul le matériel on-prem optimisé est viable. Même situation dans l’automatisation industrielle et les systèmes temps réel stricts, où garantir les délais de livraison des paquets est difficile dans le cloud public.

Au-delà des aspects techniques, le déploiement on-prem redéfinit la structure des coûts. Les frais de colocation – rack, connectivité et énergie – sont fixes et prévisibles, éliminant la “trappe des egress fees”. Les fournisseurs cloud facturent souvent lourdement le trafic sortant. Pour les applications web classiques, cela représente 5–10 % de la facture, mais pour des systèmes intensifs en données (streaming, IA, analytics), jusqu’à 30 %. Dans les datacenters privés, la connectivité internet est souvent à tarif fixe par unité de bande passante, sécurisant économiquement la croissance du trafic.

L’infrastructure on-prem nécessite une équipe qualifiée pour maintenir serveurs, réseau et stockage. Bien que cela augmente les coûts de personnel, cela offre un contrôle total sur les SLA : l’entreprise n’est plus dépendante des pannes globales du cloud ou des priorités de support du fournisseur.

Point clé de l’expert : le matériel on-prem n’est plus une approche “legacy”, mais un outil stratégique pour les organisations matures. Sur trois ans et plus, les économies d’OPEX peuvent atteindre 60–70 % par rapport au cloud, surtout pour les workloads stateful. Le contrôle du niveau physique permet un comportement système prévisible, inaccessible sur des plateformes multi-tenant. La flexibilité — inutile avec des charges stables — se traduit par des marges business plus élevées.

Stratégie hybride comme standard de l’industrie

La pratique moderne privilégie les modèles cloud hybrides, combinant les forces des deux approches pour équilibrer vitesse, coût et sécurité.
Les services core et bases de données principales sont de plus en plus déployés sur des infrastructures privées ou bare-metal pour minimiser le coût par transaction et garantir la protection des données. Lorsque la capacité locale est saturée, le cloud bursting redirige une partie du trafic ou de la charge de calcul vers le cloud public, évitant la surprovision pour des pics rares.

Cette approche s’aligne avec la tendance croissante au rapatriement des workloads lourds. Des cas publics comme 37signals (Basecamp), qui a économisé des millions en quittant le cloud, et des enquêtes montrant que 83 % des CIO sont intéressés par le rapatriement partiel, confirment que stocker des données froides ou réaliser des opérations intensives sur disque est souvent moins cher sur des NVMe propriétaires que dans des services cloud managés. Simultanément, les couches front-end, CDN et protections DDoS restent typiquement dans le cloud pour assurer la portée globale.

La couche unificatrice de cette architecture est la gestion standardisée via Kubernetes et les outils IaC comme Terraform et Ansible. Ces abstractions dissocient les applications de l’infrastructure physique, rendant le placement des workloads transparent, qu’ils soient sur serveur privé ou VM cloud, réduisant le risque de lock-in et simplifiant les migrations.

Point clé de l’expert : « L’ère du “cloud first” indiscriminé est terminée. Nous évoluons vers une stratégie “workload smart”. Les CTO reconnaissent maintenant que le cloud est un service de location à marge élevée, pas un service public. L’insight infrastructurel réel de 2025 est que les entreprises construisent leurs propres plateformes sur des serveurs bare-metal utilisant le même stack Kubernetes que le cloud, atteignant des performances hardware au coût de l’électricité et de l’amortissement. Le cloud demeure, mais comme extension pour les invités et expérimentations, pas comme fondation de l’infrastructure. »

Conclusion

Le choix de l’infrastructure est à la fois financier et technique, nécessitant calcul et non choix lié à une mode.
Il doit être guidé par les caractéristiques des workloads et l’horizon temporel. Le cloud est adapté aux phases initiales, lorsque la demande est imprévisible, le déploiement rapide essentiel, ou en absence de compétence hardware interne. L’hardware on-prem est préférable lorsque les workloads sont stables et lourds, que la latence sub-100 microsecondes est critique (HFT), le trafic sortant élevé, ou l’horizon supérieur à trois ans.

Une stratégie efficace requiert un modèle TCO détaillé, incluant egress fees et coûts de support, car le trafic peut devenir la dépense dominante pour médias et workloads IA. Les workloads doivent être segmentés : services stateless comme microservices et front-end web dans le cloud, composants stateful comme bases de données et stockage sur hardware dédié.

Les exigences de latence doivent être claires : courir après les microsecondes pour un CRM standard n’est pas rentable, tandis que l’isolation physique est non négociable pour le trading. Enfin, maintenir une flexibilité stratégique via des standards ouverts permet de migrer entre cloud et hardware sans réécrire les applications.