Avant le pilote automatique, apprendre à conduire : le Bare Metal OVHcloud pour comprendre le cloud

Le cloud nous a appris à aller vite. Quelques clics ou quelques lignes de Terraform suffisent aujourd'hui pour obtenir une machine virtuelle, un réseau privé, un load balancer, une base de données, un cluster Kubernetes ou une chaîne complète de services managés.

C'est une réussite technique considérable. Mais il existe un paradoxe : plus la plateforme devient facile à consommer, plus il devient possible de l'utiliser sans comprendre ce qu'elle remplace.

C'est précisément là que j'apprécie l'approche Bare Metal d'OVHcloud. Elle ne supprime pas le cloud ; elle permet d'en retrouver les couches fondamentales et de les manipuler réellement.

Le cloud managé cache de la complexité — et c'est son travail

Dire qu'un service cloud « cache » des couches n'est pas une critique en soi. C'est souvent sa proposition de valeur. Une équipe applicative n'a pas forcément intérêt à administrer des disques, un hyperviseur, un control plane Kubernetes ou la réplication d'une base de données si un service fiable peut le faire à sa place.

Mais selon le niveau de service choisi, plusieurs éléments peuvent devenir partiellement ou totalement abstraits :

• le matériel physique, les contrôleurs de stockage et la topologie des disques ;
• l'hyperviseur et le cycle de vie des hôtes ;
• une partie du réseau de niveau 2, du tagging VLAN et parfois du routage ;
• les passerelles, mécanismes de NAT et load balancers implémentés derrière des objets de plateforme ;
• le control plane et les nœuds système dans Kubernetes managé ;
• le mécanisme exact de réplication, de sauvegarde ou de bascule dans certaines bases managées ;
• une partie du patching, du failover et des domaines de panne ;
• les couches d'identité, d'observabilité et d'automatisation propres au fournisseur.

Cette abstraction est excellente lorsqu'on sait ce qu'elle abstrait. Elle devient plus problématique lorsqu'on apprend directement le produit sans construire d'abord le modèle mental sous-jacent.

Un exemple très concret : le VLAN

La documentation OVHcloud illustre elle-même parfaitement cette différence.

Sur un serveur dédié connecté au vRack, on travaille avec un accès administrateur, une plage d'adresses privées choisie et la configuration réelle des interfaces réseau. Pour construire plusieurs réseaux privés, on doit comprendre où et comment appliquer le marquage VLAN.

Dans le Public Cloud, une partie de cette mécanique est prise en charge au niveau de l'infrastructure OpenStack. La documentation précise notamment qu'il n'est pas nécessaire de tagguer directement le VLAN sur l'instance Public Cloud comme on le ferait sur un serveur dédié.

Dans les deux cas, le service fonctionne. Mais l'expérience d'apprentissage n'est pas la même. Dans le premier cas, une mauvaise configuration de VLAN, de bridge, de route ou de passerelle devient visible. Elle produit une panne qu'il faut observer, comprendre et corriger.

Avec un Bare Metal, on reconstruit le cloud au lieu de seulement le consommer

Sur une machine dédiée, le point de départ est simple : un serveur physique, un accès administrateur et la responsabilité de ce que l'on va construire dessus.

Installer Proxmox transforme alors cette machine en plateforme de virtualisation. Créer des bridges oblige à comprendre la circulation des trames. Ajouter OPNsense oblige à distinguer WAN, LAN, DMZ, routage et filtrage. Déployer plusieurs VMs oblige à réfléchir aux adresses, aux DNS, aux routes et aux dépendances.

Ensuite arrivent les mêmes problèmes que dans le cloud moderne :

• comment segmenter les workloads ;
• comment exposer un service sans exposer tout le réseau ;
• comment déplacer une IP ou reconstruire une VM ;
• comment assurer la persistance ;
• comment sauvegarder et restaurer ;
• comment superviser l'infrastructure ;
• comment automatiser ce qui a d'abord été compris manuellement ;
• comment concevoir la haute disponibilité et accepter qu'elle n'apparaisse pas magiquement.

Autrement dit, le Bare Metal ne nous éloigne pas du cloud. Il permet de construire une partie des mécanismes qui donnent ensuite du sens aux services cloud.

La différence entre apprendre un concept et apprendre un catalogue

Le risque pédagogique de certaines plateformes très intégrées n'est pas leur qualité. Il est de confondre un concept universel avec l'objet commercial qui l'implémente.

Un réseau privé n'est pas une option dans une console. Une identité n'est pas seulement une policy écrite dans le dialecte IAM d'un fournisseur. Un load balancer n'est pas un bouton. Une base hautement disponible n'est pas uniquement une case « multi-zone ». Un cluster Kubernetes ne se résume pas à une API disponible quelques minutes après une commande.

Ces services sont utiles, souvent excellents, et parfois le meilleur choix en production. Mais lorsqu'on ne connaît que leur interface propriétaire, on risque d'apprendre surtout comment utiliser ce fournisseur, plutôt que comment raisonner sur une infrastructure.

Le vendor lock-in commence parfois dans le modèle mental

On parle généralement de dépendance fournisseur à propos des API propriétaires, des services serverless, des bases de données managées, des mécanismes IAM, des outils d'observabilité ou des formats de déploiement.

Il existe pourtant une dépendance plus discrète : celle du raisonnement. Si toute notre compréhension de la haute disponibilité, du réseau, de l'identité ou du stockage passe par les noms de produits d'un seul fournisseur, changer de plateforme devient difficile avant même d'avoir commencé la migration technique.

À l'inverse, quelqu'un qui comprend VLAN, routage, NAT, DNS, hyperviseur, volumes, réplication, reverse proxy, certificats, métriques et restauration peut ensuite apprendre plus vite la manière dont AWS, Azure, Google Cloud, OVHcloud ou une plateforme privée exposent ces concepts.

Le concept devient la référence. Le fournisseur devient une implémentation.

Apprendre à conduire avant de choisir la marque

C'est ici que l'analogie automobile me paraît la plus juste.

Un cloud très managé ressemble à une voiture moderne : boîte automatique, aide au stationnement, maintien dans la voie, régulateur adaptatif, navigation intégrée et bientôt davantage de conduite assistée. Pour aller d'un point A à un point B, c'est souvent objectivement meilleur.

Mais si l'objectif est d'apprendre ce que signifie conduire, il est utile de comprendre aussi l'adhérence, le freinage, la transmission, la trajectoire et ce que fait la voiture lorsque l'assistance ne peut plus décider à notre place.

Apprendre uniquement une console cloud propriétaire, c'est un peu comme apprendre à « conduire » uniquement en mémorisant les menus d'un modèle précis. On devient efficace avec cette voiture. On ne devient pas nécessairement meilleur conducteur.

Le Bare Metal nous apprend d'abord la conduite. Les services managés nous apprennent ensuite à utiliser intelligemment les assistances.

Pourquoi OVHcloud est particulièrement intéressant dans ce rôle

OVHcloud fournit avec ses serveurs dédiés un accès administrateur complet à la machine, tout en offrant autour de cette machine les briques nécessaires pour construire une infrastructure moderne. Le vRack permet notamment de relier des serveurs et d'autres services OVHcloud dans un réseau privé de niveau 2, avec des VLANs que l'on peut réellement concevoir et exploiter.

Cette position intermédiaire est pédagogiquement intéressante : on n'est pas dans un serveur posé sous un bureau, mais on ne reçoit pas non plus une plateforme où chaque couche critique a déjà été transformée en service opaque.

On bénéficie du datacenter, de la connectivité et des services de l'opérateur, tout en gardant suffisamment de contrôle pour construire soi-même l'hyperviseur, la segmentation, les firewalls, les VMs, les clusters, les sauvegardes et l'observabilité.

Pour quelqu'un qui veut devenir administrateur systèmes et réseaux, ingénieur infrastructure, DevOps, SRE ou cloud engineer, cet espace de responsabilité est extrêmement formateur.

Cette liberté a un prix : la responsabilité

Il ne faut pas transformer cette idée en dogme. Un serveur dédié n'est pas « meilleur » qu'un service managé dans l'absolu.

Sur Bare Metal, ce que le fournisseur ne gère pas devient votre responsabilité : sécurité du système, patching, sauvegardes, supervision, architecture de reprise, configuration réseau, disponibilité des services et documentation. Une mauvaise décision reste votre mauvaise décision.

En production, cette responsabilité peut coûter du temps et exiger des compétences qu'une organisation préfère acheter sous forme de service managé. C'est parfaitement rationnel.

La leçon n'est donc pas « abandonner le cloud managé ». Elle est plutôt : comprendre au moins une fois ce que l'on délègue, puis déléguer consciemment.

De l'infrastructure visible vers le Cloud Native

C'est aussi la logique suivie par SORIA Académie. Le parcours Systèmes, Réseaux & Infrastructure commence par la construction et l'administration d'une vraie infrastructure avant d'aller vers les couches d'automatisation.

Dans le projet fil rouge, la phase 0 démarre explicitement par un serveur bare-metal OVH + Proxmox. Les phases suivantes ajoutent Linux, OPNsense, réseau, conteneurs, Kubernetes, Infrastructure as Code puis observabilité. L'objectif est que chaque abstraction arrive après la question technique qui lui donne du sens.