Cours OVHcloud — Public Cloud (instances, stockage objet, réseaux privés), projets, accès, facturation, souveraineté déclarée et CLI/API en lecture

Objectifs d'apprentissage

À la fin de ce cours, l'apprenant peut :

1. décrire un projet Public Cloud et ses principales ressources (instances, stockage objet, réseau privé) ;
2. expliquer ce qu'est le vRack et comment un réseau privé s'y rattache ;
3. distinguer facturation horaire et mensuelle et savoir quand la facturation d'une instance s'arrête ;
4. organiser les accès par utilisateurs, groupes et politiques IAM ;
5. protéger les clés d'API (application, secret, consommateur) ;
6. présenter les arguments de souveraineté comme des déclarations du fournisseur, avec leur périmètre ;
7. lire l'état d'un projet avec la CLI ou l'API sans rien modifier.

Prérequis

• Notions de machine virtuelle, de stockage objet (compatible S3) et de réseau IP (VLAN, sous-réseau, DHCP).
• Lire une commande dans Terminal (cours Terminal macOS).
• Aucun compte OVHcloud n'est requis pour lire ce cours. Pour pratiquer : un projet de test, des ressources supprimées en fin d'exercice, jamais de production.

Parcours et chapitres

1. Le projet Public Cloud

La documentation sur la structure des projets (mise à jour le 17 avril 2025) indique que les projets Public Cloud permettent de séparer les ressources des droits d'accès associés, et recommande un nom en trois parties : domaine, identifiant d'application, environnement (par exemple un projet « qa » et un projet « prod » distincts). Un projet est aussi le niveau auquel se regroupent les ressources du cours : instances, stockage objet, réseaux privés.

2. Instances

Les pages lues sur la facturation (31 juillet 2026) traitent des instances Public Cloud sous l'angle du coût : deux modèles (horaire, mensuel) et l'état « arrêté » ou « mis en pause » (voir chapitre 5). Les catalogues de types d'instance, d'images et de régions ne sont pas lus ici : non vérifié. Les instances sont créées par la console, l'API, l'interface OpenStack ou la CLI.

3. Réseau privé et vRack

D'après « vRack pour Public Cloud » (18 septembre 2026) : le vRack est une solution de réseau privé qui permet d'acheminer le trafic entre serveurs dédiés OVHcloud et d'autres services OVHcloud, dont des instances Public Cloud. Procédure décrite : activer un vRack, y ajouter le projet Public Cloud, puis créer un réseau privé (VLAN). Un vRack accepte jusqu'à 4 000 VLAN ; la plage DHCP par défaut est 10.1.0.0/16, modifiable ou désactivable. Des instances peuvent être créées dans le vRack ou y être rattachées ensuite ; certaines régions ne prennent pas en charge les instances uniquement privées avec passerelle. Ces opérations passent par la console, l'API, la CLI, Terraform ou OpenStack.

4. Stockage objet

D'après la recherche web (résumé, pages docs.ovhcloud.com « Choosing the right storage class » et « Endpoints and geoavailability » non relues en entier : non vérifié) : le stockage objet est accessible par une API compatible S3, avec plusieurs classes (Standard, High Performance, Infrequent Access), un point d'accès de la forme https://s3.<REGION>.io.cloud.ovh.net, et des régions variables selon la classe. La page de facturation indique une facturation selon le volume moyen stocké par heure et par classe ; le trafic et les appels d'API y sont mentionnés comme inclus, et les classes d'archive ont des durées minimales et des frais de récupération.

5. Facturation

La page « Information on Public Cloud billing options » (31 juillet 2026) :

• horaire : paiement à l'usage, facturé à la seconde après une minute minimale, prélevé le premier jour du mois suivant ;
• mensuel : réduction d'environ 50 % par rapport à l'horaire d'après la page (chiffre à reconfronter, ne pas promettre) ; « chaque mois commencé est facturé, même si l'instance est supprimée avant la fin du mois » ;
• la facturation d'une instance s'arrête seulement à sa suppression définitive ; une instance « arrêtée » ou « en pause » reste facturée ;
• la mise en suspension (shelve) d'une instance horaire libère les ressources et conserve l'IP, seul un instantané reste facturé ;
• la consommation se consulte dans la console, rubrique de facturation « consommation actuelle », avec une estimation de la prochaine facture.

Les budgets, alertes de dépense et plafonds éventuels côté OVHcloud ne sont pas établis par les pages lues : non vérifié. Se rabattre sur une discipline manuelle : liste de contrôle de fin d'exercice et revue de la consommation.

6. Comptes, utilisateurs et gestion d'accès

D'après le guide de sécurité et de structure (17 avril 2025) : OVHcloud IAM repose sur des identités, des groupes et des politiques. Identités citées : utilisateurs locaux, comptes de service, identités fédérées (AD FS, Google Workspace, Entra ID, Okta). Recommandations : grouper les utilisateurs par fonction (développeurs, administrateurs, auditeurs) plutôt que d'attribuer des politiques une à une ; définir des politiques par projet avec des droits de lecture ou d'écriture globaux ; activer l'authentification à deux facteurs, un mot de passe robuste et une adresse de secours.

7. API et clés : protéger les secrets

D'après « First steps with the OVHcloud APIs » (13 mai 2025) : l'accès à l'API repose sur trois valeurs, la clé d'application (AK), le secret d'application (AS) et la clé de consommateur (CK) ; la page précise que l'AS et la CK ne doivent pas être divulgués. À la création, on peut limiter les droits à certaines API et méthodes HTTP, et fixer une durée de validité ; les clés se listent et se révoquent via le portail d'API ou la console. Des bibliothèques (Go, Python, Node.js, PHP, etc.) évitent de signer les requêtes à la main.

8. CLI et API en lecture

La documentation de la CLI (13 octobre 2025) décrit ovhcloud, outil unique pour les produits OVHcloud ; l'authentification interactive se fait par ovhcloud login, ou par un fichier .ovh.conf dans le dossier personnel (sections par point d'accès, avec clés, secrets et projet par défaut éventuel) ou des variables d'environnement. La page cite une installation par un script téléchargé et exécuté (curl ... | sh) ou par Homebrew : ne jamais exécuter un script distant sans l'avoir lu ; ce cours n'installe rien.

ovhcloud versionovhcloud cloud project listovhcloud cloud instance list --cloud-project <ID-PROJET>

• Contexte : CLI ovhcloud déjà installée et connectée à un projet de test (syntaxe issue de la page du 13 octobre 2025 : à confirmer pour la version installée).
• Droits : lecture sur le projet.
• Effet : affiche la version, les projets et les instances.
• Vérification : les instances listées sont celles attendues ; toute instance inconnue est à investiguer (coût).
• Retour arrière : sans objet (lecture). La sortie contient des identifiants : ne pas la copier dans un dépôt ni un prompt.

La page indique aussi une commande de création d'instance (ovhcloud cloud instance create <REGION> --cloud-project <ID-PROJET>, avec des paramètres complémentaires non lus) : non reproduite comme exemple complet.

L'API console (portail d'API) permet aussi de lire l'état des services avec des clés restreintes en lecture ; routes précises non lues : non vérifié.

9. Souveraineté et hébergement européen : ce que déclare OVHcloud

Les pages commerciales consultées (SecNumCloud, zones de confiance) sont des déclarations du fournisseur, à rapporter comme telles. OVHcloud y affirme notamment : des offres qualifiées SecNumCloud (référentiel de l'ANSSI) pour un périmètre limité (VMware sur OVHcloud, SAP HANA sur Private Cloud, Bare Metal Pod, une plate-forme cloud dédiée) ; des « zones de confiance » hébergées dans des centres de données en France, avec exploitation par du personnel situé dans l'Union européenne et une « immunité totale face aux réglementations non européennes » ; des certifications citées (ISO 27001, 27017, 27018, HDS, SOC 2, PCI DSS). Ces offres sont commandées via l'équipe commerciale et demandent des comptes dédiés.

Exercices et vérifications de fin de cours

Tous sont sur papier ou en lecture seule.

1. Projets. Concevoir la liste de projets et de groupes IAM d'une petite équipe fictive (trois environnements, deux groupes).
2. Coût. Pour une instance fictive laissée « arrêtée » dix jours, dire ce qui est facturé selon la page de facturation, et ce qui est non vérifié.
3. Clés. Écrire la liste des précautions pour créer une clé d'API de diagnostic (droits, durée, stockage, révocation).
4. Réseau. Dessiner deux instances et leur réseau privé ; indiquer ce qui reste exposé sur internet.
5. Souveraineté. Reformuler trois affirmations commerciales sous la forme « OVHcloud déclare que… » et noter ce qu'il faudrait vérifier.
6. Nettoyage. Lister ce qu'il faut supprimer à la fin d'un exercice (instances, réseaux, conteneurs d'objets, clés révoquées).

Critères de réussite

• Savoir qu'une instance arrêtée est encore facturée jusqu'à sa suppression.
• Protéger les clés d'API et d'accès S3 en toutes circonstances.
• Présenter souveraineté et conformité comme des déclarations, avec leur périmètre.
• Dire ce qui n'est pas vérifié.