Ce parcours couvre OUTSCALE comme cloud souverain de bout en bout : depuis la première connexion au Cockpit jusqu'au déploiement d'une application 3-tiers Well-Architected auditée par un outil dédié. Elle s'adresse aux sysadmins, développeurs, architectes et RSSI qui souhaitent un parcours pédagogique articulant un cadre de qualité avec la pratique opérationnelle, en complément de la documentation de référence. Le fil conducteur est le Well-Architected Framework étendu d'un 7ᵉ pilier Souveraineté spécifique au cloud souverain. La compatibilité API avec AWS est exploitée comme vecteur de transférabilité — vos compétences passent dans les deux sens.
Aller droit au but
Section intitulée « Aller droit au but »Au terme de ce parcours, vous saurez
Section intitulée « Au terme de ce parcours, vous saurez »- Choisir une région OUTSCALE selon vos contraintes (commercial vs SecNumCloud) et concevoir un Net multi-AZ robuste avec subnets public, privé et data.
- Industrialiser votre infrastructure en Terraform avec un backend d'état OOS, des modules réutilisables et une discipline de pipeline IaC sécurisé.
- Construire des OMI durcies ANSSI BP-028 avec Packer + Ansible, et les déployer dans un cluster OKS managé ou un cluster Talos self-managed selon le contexte.
- Évaluer votre posture sur les 7 piliers Well-Architected (Operational Excellence, Security, Reliability, Performance, Cost, Sustainability, Sovereignty) avec des checklists actionnables.
- Auditer un compte OUTSCALE selon les piliers Well-Architected et corriger les écarts détectés.
Mon retour d'expérience — pour ceux qui veulent comprendre
Section intitulée « 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 la pratique
Section intitulée « Pourquoi un cadre Well-Architected change la pratique »Sans cadre, vous apprenez comment faire. Avec cadre, vous apprenez comment bien faire — et surtout, comment savoir que c'est bien fait.
| 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 vendor-spécifiques bloquent la portabilité | Lecture transverse par pilier qui survit aux changements de fournisseur |
Ce que ce parcours défend
Section intitulée « Ce que ce parcours défend »- 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 review 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 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 OTel après-coup sur un parc existant prend des mois. Au démarrage, c'est quelques minutes par service.
Ce que je vous interdis
Section intitulée « Ce que je vous interdis »- 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/0sur SSH. C'est le grand classique des incidents Outscale comme 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 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 de l'autre. Le backend OOS + locking est non négociable dès le deuxième utilisateur.
- Le déploiement direct sans pipeline CI/CD. Pas de
terraform applydepuis le poste d'un développeur sur la production. Le pipeline est ce qui trace, valide et reverte si nécessaire.
Sécurité non négociable
Section intitulée « Sécurité non négociable »La sécurité OUTSCALE repose sur trois disciplines qui ne souffrent aucune exception :
- MFA obligatoire sur tout compte EIM humain — sans exception, y compris pour le root account.
- Chiffrement at-rest activé partout — BSU, OOS, snapshots. Outscale fournit le chiffrement 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
Section intitulée « Productivité au quotidien »Quelques outils et réflexes qui changent la vie sur OUTSCALE :
osc-cliouoapi-clidans le terminal pour les opérations rapides — Cockpit pour le diagnostic visuel, CLI pour l'action.- Extension VS Code OSC Viewer pour explorer ses ressources sans quitter l'éditeur.
- Tagging discipliné dès la première ressource —
env,project,owner,cost-center. Sans tags, pas de FinOps. - Pre-commit hook gitleaks sur tous les dépôts qui touchent à du Terraform Outscale — un AK/SK qui fuit en commit est un incident.
Ce parcours prépare à quoi
Section intitulée « Ce parcours prépare à quoi »Ce parcours n'est pas adossée à une certification officielle OUTSCALE (il n'y en a pas à ce jour), mais elle prépare à plusieurs profils opérationnels :
| 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.
Compatibilité versions et écosystème
Section intitulée « Compatibilité versions et écosystème »| 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 + plugin OUTSCALE | dernière version stable |
| Ansible | 2.16+ |
Les versions exactes sont rappelées dans chaque guide pratique au moment de l'écriture, parce qu'elles évoluent.
Validation et entraînement
Section intitulée « Validation et entraînement »- Lab fil rouge (capstone) — application 3-tiers déployée de bout en bout, audit Well-Architected final.
- Labs par volet — chaque page pratique pointe vers un lab reproductible dans
~/Projets/lab-outscale/. - Quiz par volet — à venir au fil de la production du parcours.