Parcours OUTSCALE Well-Architected, cloud souverain SecNumCloud

Ce parcours couvre OUTSCALE de bout en bout, de la première connexion au Cockpit jusqu'au déploiement d'une application 3-tiers Well-Architected auditée par un outil dédié. Il compte 50 leçons pour environ 30 heures de travail, labs compris, et s'adresse aux sysadmins, développeurs, architectes et RSSI qui cherchent une progression pédagogique plutôt qu'une collection de tutoriels isolés. Le fil conducteur est le Well-Architected Framework, étendu d'un 7ᵉ pilier Souveraineté propre au cloud souverain. La compatibilité API avec AWS est exploitée comme vecteur de transférabilité : les compétences passent dans les deux sens.

Que contient le parcours OUTSCALE, et combien de temps demande-t-il ?

Le programme se découpe en huit blocs, du cadrage aux expérimentations avancées, qui totalisent 50 leçons et environ 30 heures de travail. Le tableau donne le volume réel de chaque bloc : il sert à planifier votre progression et à repérer les deux plus lourds, le cadre Well-Architected et le projet fil rouge.

Bloc	Ce que vous y faites	Leçons	Durée
Cadrage du parcours	Contexte d'écriture, grille de lecture Well-Architected retenue, arbre de décision par profil	3	~50 min
Volet 1, découvrir OUTSCALE	Positionnement, orchestrateur TINA OS, régions, qualification SecNumCloud, correspondance avec le vocabulaire AWS, Cockpit et `oapi-cli`	9	~3 h 20
Volet 2, les fondations	EIM, séparation des environnements, Net multi-AZ et subnets, Security Groups, bastion, instances TINA, volumes BSU, stockage objet OOS, sauvegardes	11	~5 h
Volet 3, Infrastructure as Code	Provider Terraform et état sur OOS, plugin Packer, inventaire dynamique Ansible, extension OSC Viewer	5	~3 h
Volet 4, services managés	Tour des services managés, puis déploiement d'un cluster OKS en ligne de commande	2	~1 h
Volet 5, les sept piliers Well-Architected	Les six piliers AWS revus sur OUTSCALE, puis le pilier Souveraineté : questions clés, checklists, ADR types, points d'audit	8	~5 h 30
Volet 6, projet fil rouge 3-tiers	Trois Nets en /22, peering full-mesh, bastion SSH durci, frontends Nginx en TLS de bout en bout, puis deux stratégies de haute disponibilité	7	~6 h 30
Expérimentations et patterns avancés	Cluster Talos multi-AZ, images OMI construites avec NixOS, EIP flottante pilotée par Corosync et Pacemaker	5	~4 h

S'ajoutent cette page de présentation et la page de suivi de progression, qui ne comptent pas comme des leçons. Les expérimentations se lisent une fois les fondations et le projet fil rouge bouclés : ce sont des montages de laboratoire hors du chemin principal, utiles mais pas nécessaires à la compréhension de l'ensemble.

Par où commencer selon votre profil ?

Trois pages d'orientation ouvrent le parcours, et elles répondent chacune à une question différente avant que vous n'écriviez la moindre ligne de Terraform. Les suivre dans l'ordre prend moins d'une heure et évite de découvrir au volet 5 que la moitié du chemin ne vous concernait pas.

Pourquoi ce parcours existe : le positionnement pédagogique et le public visé, pour savoir si ce parcours est fait pour vous.
Le Well-Architected adapté à OUTSCALE : les six piliers du cadre AWS et le septième, la souveraineté.
Choisir son parcours selon votre profil : l'arbre de décision par rôle, du sysadmin au FinOps, qui indique les volets à prioriser.

Comment suivre sa progression dans le parcours ?

Chaque leçon porte une case à cocher, et votre progression est enregistrée dans votre navigateur, sans compte ni inscription. Aucune donnée n'est envoyée au serveur.

La page Mon parcours affiche le programme complet, bloc par bloc, avec l'avancement. En haut de chaque leçon, un bandeau rappelle où vous en êtes ; en bas, un bouton marque la leçon comme lue et vous emmène à la suivante. Vous pouvez donc reprendre plusieurs semaines plus tard sans avoir à retrouver votre place.

Mon retour d'expérience, pour ceux qui veulent comprendre

Je travaille au quotidien sur OUTSCALE et ce parcours reflète ma vision pédagogique personnelle : un parcours structuré qui articule un cadre de qualité (le Well-Architected Framework) avec la pratique opérationnelle. C'est un angle complémentaire à la documentation de référence, orienté sur la question « est-ce que ce que je viens de déployer est correctement architecturé ? » plutôt que sur la mécanique d'un service donné. La doc officielle reste la source de vérité sur les détails techniques ; ce parcours y ajoute la grille de lecture transverse qui aide à juger une architecture dans son ensemble.

Le choix du Well-Architected Framework comme fil conducteur n'est pas un hasard. C'est le vocabulaire commun de la profession depuis 2015, popularisé par AWS puis adopté par Azure, Google et IBM. Sur OUTSCALE, ce vocabulaire est directement transférable parce que les primitives techniques sont alignées : on retrouve les mêmes piliers, sécurité, fiabilité, performance, coût, excellence opérationnelle, durabilité, avec en plus un pilier spécifique au cloud souverain, la souveraineté.

Pourquoi un cadre Well-Architected change-t-il la pratique ?

Sans cadre, vous apprenez comment faire. Avec cadre, vous apprenez comment bien faire, et surtout comment savoir que c'est bien fait. Le tableau ci-dessous oppose les deux situations sur cinq points qui se manifestent tous en exploitation, pas en conception.

Sans Well-Architected	Avec Well-Architected
Chaque équipe redéfinit ses propres standards	Vocabulaire commun entre équipes et auditeurs
Aucun moyen objectif d'évaluer une architecture	Checklists par pilier, ADR types, scoring
Les audits sont sporadiques et manuels	Audit automatisable par règles claires
La dette d'architecture s'accumule en silence	Score de posture suivi dans le temps
Les choix spécifiques à un fournisseur bloquent la portabilité	Lecture transverse par pilier qui survit aux changements de fournisseur

Ce que ce parcours défend

Un parcours qui ne prend aucune position ne sert à rien : il laisse le lecteur devant dix options équivalentes. Voici les cinq principes qui structurent chaque guide, pour que vous sachiez à quoi vous vous engagez en les suivant.

L'IaC dès le J1, jamais de ClickOps en production. Une infrastructure construite à la console ne se reproduit pas, ne se versionne pas, et ne se relit pas. Le coût d'écrire un module Terraform est largement amorti par l'élimination des dérives manuelles.
Le moindre privilège EIM est non négociable. Pas de root account, pas d'AK/SK partagés, pas de policies * sur *. La discipline EIM est ce qui transforme une compromission applicative en incident contenu, plutôt qu'en compromission de compte.
Le Well-Architected n'est pas un module en bout de course, c'est une grammaire. Chaque page de service est taguée par les piliers concernés. Le volet 5 agrège, mais la rigueur s'applique en continu, pas en audit de fin.
Les sauvegardes non testées n'existent pas. La règle 3-2-1 (3 copies, 2 supports, 1 hors-site) ne vaut que si vous avez restauré pour de vrai au moins une fois par an. Un snapshot jamais restauré est un placebo.
L'observabilité s'instrumente dès le premier service. Ajouter OpenTelemetry après coup sur un parc existant prend des mois. Au démarrage, c'est quelques minutes par service.

Ce que je vous interdis

Six pratiques reviennent assez souvent pour mériter d'être nommées avant que vous ne les rencontriez. Aucune n'est théorique : chacune se paie en incident, en perte de temps ou en travail à refaire.

Le root account utilisé au quotidien. C'est la première chose qu'un attaquant cherche. Un root account créé, sécurisé par MFA matériel, et rangé dans un coffre : toutes les opérations passent par des utilisateurs EIM dédiés.
Le ClickOps en console pour des changements répétitifs. Si vous créez deux fois la même ressource à la main, vous avez déjà perdu. Le Cockpit est utile pour explorer et diagnostiquer, pas pour construire.
Les Security Groups en 0.0.0.0/0 sur SSH. C'est le scénario d'incident le plus fréquent, sur OUTSCALE comme sur AWS. La discipline minimale : SSH depuis un bastion ou depuis le VPN de l'entreprise, jamais depuis Internet ouvert.
Les snapshots BSU comme seule stratégie de sauvegarde. Un snapshot est un blob lié à votre compte. Si le compte est compromis, les snapshots le sont aussi. La copie vers OOS dans un compte séparé, avec lifecycle, est le minimum vital.
Le state Terraform sur le poste local. Deux développeurs en parallèle écrasent le state l'un de l'autre. Le backend OOS avec verrouillage est non négociable dès le deuxième utilisateur.
Le déploiement direct sans pipeline CI/CD. Pas de terraform apply depuis le poste d'un développeur sur la production. Le pipeline est ce qui trace, valide et permet de revenir en arrière.

Sécurité non négociable

La sécurité d'un compte OUTSCALE repose sur trois disciplines qui ne souffrent aucune exception, et qui sont vérifiées à chaque volet du parcours plutôt qu'une fois pour toutes.

MFA obligatoire sur tout compte EIM humain, sans exception, y compris pour le root account.
Chiffrement at-rest activé partout : BSU, OOS, snapshots. Le chiffrement est fourni par défaut, encore faut-il le vérifier explicitement sur chaque ressource.
Logs OAPI activés et exportés vers un stockage en lecture seule. Sans logs, pas d'audit possible, pas de réponse à incident, pas de conformité tenable.

Productivité au quotidien

Le confort de travail n'est pas un détail sur une plateforme cloud : c'est ce qui décide si vous vérifiez une ressource ou si vous supposez qu'elle est correcte. Quatre outils et réflexes reviennent en permanence dans les guides de ce parcours.

osc-cli ou oapi-cli dans le terminal pour les opérations rapides : le Cockpit pour le diagnostic visuel, la ligne de commande pour l'action.
Extension VS Code OSC Viewer pour explorer ses ressources sans quitter l'éditeur.
Tagging discipliné dès la première ressource, avec env, project, owner et cost-center. Sans tags, pas de FinOps possible.
Pre-commit hook gitleaks sur tous les dépôts qui contiennent du Terraform OUTSCALE : un AK/SK qui fuit dans un commit est un incident.

À quels profils ce parcours prépare-t-il ?

Ce parcours n'est pas adossé à une certification officielle OUTSCALE, mais il prépare à cinq profils opérationnels identifiés. Le tableau indique les compétences acquises pour chacun, ce qui aide aussi à choisir les volets à suivre en priorité.

Profil	Compétences acquises
Sysadmin / Opérateur cloud	Cockpit, CLI, OMI, sauvegardes, observabilité
DevOps / SRE	IaC complet, OKS, observabilité, FinOps
Architecte cloud	Well-Architected sur 7 piliers, ADR types, audit de posture
RSSI / Sécurité	EIM, chiffrement, conformité SecNumCloud, audit de posture
FinOps	Right-sizing TINA, lifecycle OOS, ReadConsumptionAccount, tagging

Les compétences sont transférables à AWS à 90 % grâce à la compatibilité API : un architecte qui maîtrise OUTSCALE peut intervenir sur un environnement AWS avec une courbe d'adaptation courte.

Sur quelles versions le parcours est-il écrit ?

Les guides pratiques rappellent la version exacte de chaque outil au moment de leur écriture, parce qu'elles évoluent plus vite que le parcours. Le tableau ci-dessous donne la cible générale retenue pour 2026.

Composant	Version cible 2026
Provider Terraform OUTSCALE	dernière version stable du registre HashiCorp
`osc-cli`	dernière release officielle
`oapi-cli`	dernière release officielle
OKS	versions Kubernetes supportées par OUTSCALE
Packer et plugin OUTSCALE	dernière version stable
Ansible	2.16 ou supérieur

Comment valider ses acquis ?

La validation passe par la pratique, pas par la lecture. Trois dispositifs se complètent, du lab isolé au projet complet, et le dernier sert de preuve que l'ensemble tient debout.

Projet fil rouge : le capstone déploie une application 3-tiers en haute disponibilité de bout en bout, avec trois Nets en peering full-mesh, un bastion, des frontends Nginx, puis la haute disponibilité par LBU et DNS round-robin ou par cluster HAProxy et Pacemaker. Il se termine par un audit Well-Architected.
Labs par volet : chaque page pratique pointe vers un lab reproductible, à rejouer sur votre propre compte.
Quiz par volet, à venir au fil de la production du parcours.

Ressources externes

Ce parcours ne remplace pas les sources officielles, il les complète par une grille de lecture. Gardez les quatre liens ci-dessous à portée de main : la documentation technique reste la référence sur le détail d'un service, et la page de statut est le premier réflexe devant un comportement inattendu.

Pour aller plus loin

Pourquoi ce parcours existe : Le positionnement pédagogique et le public visé, utile pour savoir si ce parcours vous concerne.
Le Well-Architected adapté à OUTSCALE : Les six piliers du cadre AWS et le septième, la souveraineté, propre au contexte français.
Choisir son parcours selon votre profil : L'arbre de décision par rôle, sysadmin, développeur, architecte, RSSI ou FinOps.
Volet 5, Well-Architected appliqué : La pièce maîtresse du parcours, sept piliers avec checklists et décisions d'architecture types.