Aller au contenu
English
Cloud high

Cloud Computing : de la théorie à la pratique

10 min de lecture

Cette section enseigne le cloud comme un métier, pas comme le catalogue d'un fournisseur. Vous y apprenez d'abord les mécanismes communs à tous les clouds, ceux qui expliquent pourquoi une machine coûte ce qu'elle coûte, pourquoi un réseau mal découpé se paie deux ans plus tard, et pourquoi une permission trop large finit toujours par servir. Vous appliquez ensuite ces mécanismes sur le fournisseur de votre choix. Le public visé va du débutant qui n'a jamais créé de machine virtuelle à l'administrateur qui veut structurer ce qu'il pratique déjà.

  • Décider entre IaaS, PaaS et SaaS avec des critères de coût et de risque, pas par habitude.
  • Construire un réseau privé, du découpage d'adresses à la sortie vers Internet.
  • Exposer une application sans laisser le serveur d'origine joignable par son adresse publique.
  • Choisir un stockage et une base managée en sachant ce que chacun coûte à l'usage.
  • Contrôler qui accède à quoi, sans reproduire les erreurs classiques.
  • Gouverner et exploiter dans la durée : hiérarchie de comptes, garde-fous, quotas, sauvegardes restaurées.
  • Transposer le même savoir d'un fournisseur à l'autre, parce que le vocabulaire change plus que les concepts.
PublicDéveloppeurs, administrateurs, architectes qui découvrent ou structurent le cloud
PrérequisBases d'administration Linux, notions de réseau
ApprocheConcepts indépendants du fournisseur, puis mise en pratique au choix
Fournisseurs traitésAWS, Azure, GCP, OUTSCALE, OVHcloud, Scaleway selon les sujets
Coût pour suivreNul jusqu'aux travaux pratiques, qui peuvent se faire en local

Le cours sépare volontairement ce qui est universel de ce qui appartient à un fournisseur. C'est la distinction la plus utile que vous puissiez emporter : elle vous évite de confondre une compétence transférable avec un réflexe qui ne vaut que dans une console.

Le tronc commun explique les mécanismes. Un sous-réseau, une politique d'accès, une classe de stockage froid, un transfert sortant facturé : ces notions existent partout, sous des noms différents. Les pages du tronc commun ne dépendent d'aucun fournisseur pour expliquer un concept, et quand une implémentation aide à comprendre, elles en montrent plusieurs.

Les parcours fournisseurs appliquent ces mécanismes à un cloud précis, avec ses noms, ses limites et ses pièges. Vous n'en suivez qu'un, celui que vous utilisez. Les autres restent lisibles le jour où vous changez.

Les mécanismes du cloud, indépendamment de tout fournisseur : ce qu'on achète réellement, comment c'est facturé, et ce que l'on cède en contrepartie.

Le domaine à traiter en premier, parce qu'une permission trop large ne se voit pas tant qu'elle ne sert pas. On commence par les identités, on continue par ce qui est joignable sans authentification, et on journalise avant d'en avoir besoin.

Ce que vous achetez en créant une machine, comment la dimensionner sans payer pour rien, et ce qui continue d'être facturé après l'extinction.

Le parcours complet, de l'adressage aux architectures : neuf leçons qui s'enchaînent, avec des labs rejouables en local.

Où poser les données, et ce que chaque choix implique en performance comme en facture. Le stockage est le poste qui grossit tout seul, et celui qui se corrige le plus difficilement après coup.

Savoir qui dépense quoi, poser des garde-fous que personne ne contourne, et tenir l'environnement dans la durée : maintenance imposée par le fournisseur, quotas, sauvegardes qui survivent à une compromission.

Localisation, juridiction et dépendance technologique sont trois questions distinctes, et les confondre conduit à des décisions mal fondées dans un sens comme dans l'autre.

Le premier obstacle pour apprendre le cloud n'est pas la difficulté, c'est la carte bancaire. Une erreur de manipulation sur un compte réel se paie immédiatement, et la peur de la facture empêche d'expérimenter, donc d'apprendre.

L'émulateur feint répond à ce problème pour une partie du parcours : il sert en local les API de plusieurs clouds européens, ce qui permet de rejouer des manipulations, de les rater, et de recommencer sans qu'aucune ressource ne soit facturée. Ce qu'il émule et, tout aussi important, ce qu'il n'émule pas, est documenté page par page.

Tout ce parcours converge vers un projet unique : déployer une application à trois étages, la sécuriser, la sauvegarder, puis vérifier chaque exigence par une commande plutôt que par une impression. Une bonne partie se monte en local, sans compte ni carte bancaire.

Ce cours est neutre sur les concepts, il ne l'est pas sur les choix. Les deux choses sont différentes, et les confondre produit des formations tièdes qui n'aident personne à décider.

Neutre sur les concepts : un sous-réseau, une politique d'accès ou une classe de stockage s'expliquent sans nommer de fournisseur, et rien ici n'exige d'avoir un compte quelque part pour être compris. Vous n'aurez jamais à choisir un cloud pour suivre une leçon du tronc commun.

Non neutre sur les choix : j'ai une préférence assumée pour les clouds européens et souverains, et vous la verrez dans les exemples, dans les comparatifs et dans les parcours les plus développés. Elle repose sur trois arguments que ce cours détaille plutôt qu'il ne les assène.

  • La juridiction se choisit à l'avance ou se subit. Un hébergement en Europe chez un fournisseur soumis à une législation extraterritoriale ne protège pas de cette législation. C'est un sujet de droit, pas de géographie, et il se tranche avant la migration.
  • La réversibilité est un critère technique. Le coût de sortie se construit le jour où l'on adopte un service managé propriétaire, pas le jour où l'on veut partir. Le trafic sortant facturé en est la version visible ; la dépendance à une API l'est moins.
  • La souveraineté n'est pas un label unique. « Cloud européen », « cloud souverain », « SecNumCloud » et « données hébergées en France » désignent quatre choses distinctes, et ce cours les sépare au lieu de les empiler.

Cela dit, rien ici ne vous pousse à quitter un cloud américain. Si vous travaillez sur AWS, Azure ou GCP, les mécanismes enseignés sont exactement les mêmes, les exemples les citent, et vous serez mieux armé pour discuter des contreparties avec votre direction. Un cours qui refuserait de parler des trois plus gros fournisseurs mondiaux vous rendrait un mauvais service.

Choisissez le cloud que vous utilisez, ou celui que vous devez évaluer. Les parcours n'ont pas la même maturité, et le tableau ci-dessous le dit franchement plutôt que de vous laisser le découvrir en cours de route.

ParcoursÉtatCe que vous y trouvez
OUTSCALECompletFondations, réseau, stockage, IaC, Well-Architected et projet final
ScalewayEn coursPrise en main, fondations, réseau, ligne de commande
AWSPartielIntroduction et ligne de commande
AzureÀ écrireLes concepts du tronc commun s'y appliquent
GCPÀ écrireLes concepts du tronc commun s'y appliquent

Commencez par les fondamentaux. Ils répondent à la question que personne n'ose poser une fois en poste : qu'achète-t-on exactement quand on « prend une machine dans le cloud », et à qui cède-t-on quoi.

  • Les concepts sont transférables, les consoles ne le sont pas. Apprenez le mécanisme, le vocabulaire du fournisseur s'apprend en une journée.
  • Trois sujets décident du coût réel d'une infrastructure : le dimensionnement, le stockage et le transfert sortant. Aucun des trois ne se rattrape après coup.
  • Une permission trop large finit toujours par être utilisée. Le moindre privilège n'est pas un principe théorique, c'est ce qui limite l'ampleur d'un incident.
  • Pratiquez avant de payer. Une bonne partie des manipulations de ce cours se rejoue en local, sans compte cloud.
  • Le cloud ne s'arrête pas à la mise en ligne. Maintenance imposée, quotas atteints, montées de version subies et restaurations jamais testées font l'essentiel des mauvaises surprises.
  • Un parcours fournisseur n'est pas une documentation officielle. Il reflète une expérience, et la documentation de l'éditeur reste la source de référence.

Ce site vous est utile ?

Sachez que moins de 1% des lecteurs soutiennent ce site.

Je maintiens +700 guides gratuits, sans pub ni tracking. Un soutien, même symbolique, m'aide à couvrir l'hébergement et à garder ces ressources gratuites. Merci pour votre appui.

Le formulaire ne s'affiche pas ? Ouvrir Ko-fi dans un onglet.

Abonnez-vous et suivez mon actualité DevSecOps sur LinkedIn