Questions d'entretien ingénieur cloud OVHcloud : Public Cloud et vRack

Chez OVHcloud, un même projet mélange souvent instances Public Cloud sur OpenStack, serveurs dédiés reliés par le vRack, clusters Managed Kubernetes et parfois du VMware hébergé. L'ingénieur cloud qui tient ce périmètre connaît l'API OVHcloud aussi bien qu'OpenStack.

Recevoir la fiche complète

Mis à jour le Par l'équipe Delectus5 min de lecture

La fiche Ingénieur cloud OVHcloud : technologies, chaîne du poste, une question et la grille d'évaluation

Un ingénieur cloud OVHcloud crée et exploite les projets Public Cloud, leurs réseaux privés, les clusters Managed Kubernetes, les buckets Object Storage et les serveurs dédiés qui gravitent autour. Le tout s'automatise avec le provider Terraform ovh et le provider openstack. Le poste s'ouvre pour sortir d'un hyperscaler, pour consolider un parc de serveurs dédiés ou parce qu'une partie des données doit aller sur une offre qualifiée SecNumCloud.

Les CV mêlent deux mondes. Certains profils viennent de l'hébergement dédié et connaissent bien les serveurs, les IP additionnelles et le vRack, mais peu Kubernetes. D'autres arrivent d'AWS ou d'Azure et cherchent des services managés qui n'existent pas ici sous la même forme. Le premier signe d'une vraie pratique, c'est de savoir ce qu'OVHcloud gère et ce qu'il laisse au client, nœud Kubernetes compris.

Les offres réellement utilisées sont à préciser. Public Cloud, Hosted Private Cloud, bare metal et offres SecNumCloud ne demandent pas les mêmes réflexes, et le mot souverain sur un CV ne dit pas lequel. Le PDF propose un cas de 20 minutes sur une application à héberger en région Paris sur trois zones.

Le catalogue OVHcloud qu'un ingénieur cloud exploite

Public Cloud (OpenStack)

Les instances, les volumes Block Storage et les réseaux privés, construits sur OpenStack et regroupés en projets. On les pilote par l'espace client, par Horizon ou par l'API OpenStack. Les régions vont de Gravelines, Roubaix et Strasbourg à des régions à trois zones comme Paris et Milan. Un candidat à l'aise avec OpenStack s'y retrouve vite.

Managed Kubernetes Service

Le Kubernetes managé d'OVHcloud, en plan Free ou Standard. Le plan Standard ajoute le déploiement sur trois zones, un etcd dédié, jusqu'à 500 nœuds et un SLA de production. Les nœuds sont des instances du projet gérées par le service : y toucher par OpenStack crée des ennuis, et un profil expérimenté le sait.

vRack

Le réseau privé d'OVHcloud. Il relie entre eux des projets Public Cloud, des serveurs dédiés et du Hosted Private Cloud, y compris dans des datacenters différents, avec des VLAN. Beaucoup d'architectures hybrides chez OVHcloud passent par lui.

Gateway et Load Balancer

La Gateway donne une sortie internet aux instances d'un réseau privé sans leur attribuer d'IP publique. Le Load Balancer, basé sur Octavia, répartit le trafic HTTP ou TCP entre instances et sert aussi aux Services Kubernetes de type LoadBalancer.

Object Storage S3

Le stockage objet compatible S3, avec plusieurs classes, du stockage haute performance aux archives froides. On y range sauvegardes, exports et fichiers applicatifs. Les droits passent par des utilisateurs dédiés, des identifiants S3 et des politiques par bucket.

Bare metal et Hosted Private Cloud

Les serveurs dédiés, gérés par l'API ou l'espace client, avec IPMI, IP additionnelles et pare-feu réseau. Le Hosted Private Cloud fournit une plateforme VMware dédiée : OVHcloud tient le matériel, le client ses VM. Des offres Nutanix existent aussi sur bare metal.

API OVHcloud, IAM et Terraform

Tout passe par l'API OVHcloud, que le provider Terraform ovh utilise. L'authentification moderne repose sur des comptes de service OAuth2 associés à des politiques IAM. L'ancien trio application key, application secret et consumer key traîne encore dans beaucoup de dépôts.

Offres SecNumCloud

Trois offres figurent au catalogue de l'ANSSI : Hosted Private Cloud VMware, Bare Metal Pod et, depuis le 31 juillet 2026, SNC Cloud Platform, le cloud de confiance d'OVHcloud bâti sur OpenStack. Selon OVHcloud, elles sont hébergées à Roubaix, Gravelines et Strasbourg. Le Public Cloud classique et Managed Kubernetes n'en font pas partie. Chaque qualification a une date de fin, à relire au catalogue de l'ANSSI.

Le poste existe chez des clients finaux qui hébergent leur production chez OVHcloud, chez des éditeurs qui en ont fait leur cloud principal et dans des ESN qui accompagnent des sorties d'hyperscaler ou des projets de cloud souverain. Il touche souvent au bare metal et au réseau autant qu'à Kubernetes. Les profils viennent de l'administration système Linux, d'OpenStack ou d'un cloud public. Sur une offre qualifiée SecNumCloud, le périmètre des services et les règles d'exploitation changent, et l'expérience correspondante se vérifie à part.

Les compétences OVHcloud à contrôler, de l'API au vRack

  • API OVHcloud, IAM et Terraform
  • Instances et stockage Public Cloud
  • Réseau privé : vRack, Gateway, Load Balancer
  • Exploitation de Managed Kubernetes
  • Object Storage, sauvegarde et reprise
  • Offres SecNumCloud et Hosted Private Cloud

Ce qu'on demande à un ingénieur OVHcloud, et ce qu'il doit répondre

Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.

  1. Question 1 · confirmé

    Des instances Public Cloud doivent joindre une base installée sur un serveur dédié, dans un autre datacenter, sans passer par internet. Que mettez-vous en place ?

    Une bonne réponseLe projet Public Cloud et le serveur dédié dans le même vRack. Un réseau privé côté Public Cloud avec un identifiant de VLAN, le même VLAN configuré sur l'interface privée du serveur dédié, un plan d'adressage sans chevauchement et des adresses fixes ou un DHCP maîtrisé. Le vRack relie des datacenters différents, donc la personne vérifie la latence entre les deux sites avant d'y faire passer une base.

    Signal d'alerteOuvrir le port de la base sur l'IP publique du serveur et filtrer par adresse source, ou croire que le vRack ne fonctionne qu'à l'intérieur d'un datacenter.

  2. Question 2 · confirmé

    Un collègue a supprimé dans Horizon une instance qui portait un nœud du cluster Managed Kubernetes. Que se passe-t-il, et que lui expliquez-vous ?

    Une bonne réponseLes nœuds, leurs volumes et les load balancers apparaissent comme des ressources du projet, mais c'est Managed Kubernetes qui les gère. L'autoréparation recrée le nœud manquant, et toute modification faite par OpenStack peut créer ou dupliquer des ressources. Les pods sans réplique ont été coupés le temps de la recréation. Les nœuds se gèrent par les pools du cluster (API, Terraform, kubectl), jamais par Horizon.

    Signal d'alerte« Je recrée l'instance à la main avec le même nom », alors que des noms d'instance en double posent justement problème au kubelet.

  3. Question 3 · confirmé

    Votre pipeline Terraform s'authentifie encore avec une application key, un application secret et un consumer key créés par un ancien collègue. Que changez-vous ?

    Une bonne réponseLe consumer key est lié au compte qui l'a généré, souvent avec des droits sur toute l'API (GET, POST, PUT, DELETE sur /*). La personne le remplace par un compte de service OAuth2 (client_id et client_secret), que le provider ovh accepte, et lui attache une politique IAM OVHcloud limitée aux ressources et aux actions utiles. Les secrets passent dans le coffre de la CI ou dans les variables OVH_CLIENT_ID et OVH_CLIENT_SECRET, jamais dans le dépôt, et l'ancien jeton est révoqué.

    Signal d'alerteGarder les trois clés dans un fichier tfvars versionné, ou régénérer un consumer key avec les mêmes droits sur /* au nom d'un autre collègue.

  4. Question 4 · senior

    Une application doit tourner sur une offre qualifiée SecNumCloud chez OVHcloud. Que vérifiez-vous avant de proposer une architecture ?

    Une bonne réponseLa qualification porte sur des offres précises, pas sur tout le catalogue. Il cite Hosted Private Cloud VMware, Bare Metal Pod et SNC Cloud Platform, inscrite au catalogue de l'ANSSI depuis le 31 juillet 2026. Il sait que Managed Kubernetes et le Public Cloud classique sont hors périmètre. Il vérifie au catalogue de l'ANSSI l'offre, son périmètre et sa date de fin de validité, les datacenters concernés (Roubaix, Gravelines, Strasbourg selon OVHcloud) et les services qu'il faudra opérer soi-même.

    Signal d'alerte« OVHcloud est français, donc tout son cloud est SecNumCloud. »

  5. Question 5 · junior à confirmé

    Une instance Public Cloud ne démarre plus après une mise à jour du noyau. Comment reprenez-vous la main ?

    Une bonne réponseLa console VNC de l'espace client pour lire l'erreur, puis un redémarrage en mode rescue : l'instance démarre sur un système de secours et son disque se monte pour corriger GRUB, le fstab ou revenir à l'ancien noyau. Si rien ne marche, restauration de la dernière sauvegarde ou du dernier snapshot de l'instance. Les données placées sur un volume Block Storage séparé se rattachent à une nouvelle instance.

    Signal d'alerteSupprimer l'instance et la recréer, sans savoir si des données vivaient sur son disque local.

Recevez la fiche d'entretien complète en PDF

La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.

  • 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
  • Le niveau visé pour chaque question
  • Une mise en situation de 20 minutes et ce qu'on attend du candidat
  • La grille d'évaluation de 1 à 4, axe par axe

Ingénieur OVHcloud : les doutes fréquents

Que perd un ingénieur AWS ou Azure en arrivant sur OVHcloud ?

Une partie des services managés qu'il consommait tout faits : certaines files de messages, du serverless, des outils de gouvernance multi-comptes. Il retrouve des briques plus proches de l'infrastructure, avec OpenStack, le vRack et des serveurs dédiés, et doit opérer lui-même ce qui manque. Les bons profils s'adaptent vite s'ils ont une base Linux et réseau solide. Le service qu'il a dû remplacer lors d'une migration, et la façon de le faire, le montrent.

OpenStack doit-il figurer sur le CV d'un ingénieur OVHcloud ?

C'est un plus réel, sans être obligatoire. Le Public Cloud d'OVHcloud repose sur OpenStack : un candidat qui connaît Nova, Neutron et Cinder comprend vite les instances, les réseaux et les volumes, et sait utiliser l'API OpenStack directement. Un profil qui n'a connu que l'espace client et Terraform peut convenir pour un poste centré sur Kubernetes. Pour un poste d'exploitation large, mieux vaut quelqu'un qui a déjà dépanné une instance par l'API.

Le test technique peut-il se faire sur un vrai projet Public Cloud ?

Oui, un petit projet de test coûte peu et rend l'exercice concret. L'exercice consiste à créer en Terraform un réseau privé, une Gateway et deux instances derrière un load balancer, en une heure, en commentant à voix haute. Sans projet de test, un schéma à compléter et un code Terraform à relire suffisent. Dans les deux cas, compte la façon dont la personne gère les identifiants et ce qu'elle confie au service managé.

Pourquoi distinguer un ingénieur OVHcloud d'un ingénieur OpenStack ?

L'ingénieur OpenStack fait tourner la plateforme elle-même : il installe, met à jour et dépanne Nova, Neutron ou Ceph, souvent dans un cloud privé. L'ingénieur OVHcloud utilise une plateforme qu'OVHcloud opère pour lui. Son travail porte sur l'architecture du projet, le réseau entre Public Cloud et bare metal, Kubernetes, l'automatisation et la reprise. Les deux profils se croisent, mais l'annonce doit dire lequel est recherché.

Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.

Les fiches voisines

Toutes les fiches →

Voyez Delectus sur vos propres offres.

Commencez gratuitement. Passez à l'échelle quand vous êtes prêt.

Demander une démo

Votre ATS, connecté à Delectus

  • Workable
  • Teamtailor
  • iCIMS
  • Lever
  • SmartRecruiters
  • Jobvite
  • Greenhouse
  • Pinpoint