Comment Apprendre le Cloud Computing en Partant de Zéro en 2026
Il était 23h un mardi et je lisais mon quinzième article comparant AWS et Azure. Mes yeux commençaient à se fermer. J’avais trois onglets ouverts avec des calculateurs de pricing, deux avec des graphiques de parts de marché, et un avec un thread Reddit où des inconnus s’insultaient sur le serverless.
Ça faisait deux semaines que j‘“apprenais le cloud”. Je n’avais pas lancé une seule ressource.
Et puis mon collègue Dave — le genre de mec qui apprend les choses en les cassant — m’a dit de créer un compte AWS et de casser des trucs. Donc je l’ai fait. J’ai lancé une instance EC2 le soir même. J’arrivais pas à m’y connecter en SSH. J’ai passé une heure à fixer les règles du security group, à essayer de comprendre pourquoi le port 22 faisait comme si j’existais pas. Vers minuit, ça marchait. Et j’avais plus appris sur le réseau dans cette heure frustrante et caféinée que pendant mes deux semaines de comparatifs.
C’est à peu près tout l’article résumé en trois paragraphes. Tu apprends le cloud en faisant du cloud.
Le reste, c’est juste toi, à 23h, en train de lire des calculateurs de pricing.
Ce qu’il te faut avant de toucher une console
Pas grand-chose. Mais si tu sautes ça, chaque message d’erreur va ressembler à du chinois.
Un minimum de réseau. C’est quoi une adresse IP. C’est quoi un sous-réseau. Comment marche le DNS. Ce qu’est un port. Je parle pas de passer le CCNA — juste assez pour que quand un security group bloque ton trafic, t’aies une chance de comprendre pourquoi. Deux soirées sur les vidéos Network+ de Professor Messer. C’est gratuit, c’est en anglais, c’est suffisant.
Le réseau, c’est un peu les légumes qu’il faut manger avant le dessert. C’est pas très excitant. Mais c’est la différence entre “pourquoi ce truc marche pas ??” et “ah, le port 443 est fermé.” Ce déclic-là vaut l’ennui.
La ligne de commande Linux. La majorité de l’infra cloud tourne sur Linux. ls, cd, grep, ssh, chmod — ça doit être naturel. Pas expert. Juste pas paniqué. Sur Windows, installe WSL. Dix minutes.
Une vague idée des VMs et conteneurs. Une VM c’est un ordinateur simulé complet. Un conteneur c’est une boîte isolée légère. Docker emballe des applis dans des conteneurs. C’est tout. Creuse pas plus pour l’instant. Tu creuseras quand t’en auras besoin, et ça fera bien plus de sens à ce moment-là.
Trois trucs. C’est la liste. J’ai passé un mois à essayer de comprendre toute la théorie cloud avant de toucher une console, et tout ce que ça m’a donné c’est un dossier de favoris très bien rangé et zéro compétence pratique.
Choisis-en un et arrête de tourner en rond
AWS, Azure ou GCP. Le débat éternel. J’ai vu des gens passer plus de temps à choisir un provider qu’à en apprendre un.
Ce que j’aurais aimé qu’on me crie dessus : ils font tous la même chose au niveau fondamental. Compute, stockage, réseau, bases de données, gestion d’identité. Si t’apprends bien AWS, passer à Azure prend des semaines. Pas des mois. Des semaines.
Si t’as vraiment aucune préférence, pars sur AWS. Plus grosse part de marché, plus de tutos, plus d’offres d’emploi. Si ta boîte utilise Azure, ou si tu t’orientes data/ML, pars sur GCP. Mais choisis. Le pire c’est de passer un mois à alterner entre les trois.
Crée un compte free tier. Et avant de faire quoi que ce soit d’autre — quoi que ce soit — mets une alerte de facturation à 5€.
Faut que je te parle de la facturation parce que j’en ai marre de voir des gens se faire avoir. Mon pote a laissé tourner un NAT gateway un weekend. 47€ le lundi matin sur sa carte. Il a fixé le mail comme on fixe un PV. C’est pas la mort, mais pour un débutant qui essaie juste d’apprendre, c’est assez pour fermer l’onglet et plus jamais revenir. Le free tier est généreux mais il a des bords invisibles. Mets l’alerte.
Ensuite, dans cet ordre :
- Lance une instance EC2. SSH. Installe nginx. Vois une page web. Ressens un petit frisson de fierté.
- Mets un site statique sur S3.
- Crée une base RDS. Connecte-toi depuis ton EC2.
- Écris une fonction Lambda. Déclenche-la via API Gateway. Regarde-la répondre.
- Configure des utilisateurs IAM avec des permissions différentes. Essaie un truc interdit. Regarde le message d’erreur.
Suis pas les tutos bêtement. Change un paramètre. Retire une règle du security group. Regarde ce qui casse. C’est là que l’apprentissage vit vraiment.
Bon, les projets
Faut que je sois honnête sur un truc d’abord. Je dis à tout le monde de construire des projets. C’est le bon conseil. Mais quand j’ai commencé, moi, j’ai pas fait ça. J’ai regardé quarante heures de tutos Kubernetes sur YouTube. J’étais content de moi. Et quand j’ai essayé de vraiment déployer un truc, je comprenais rien. Toutes les connaissances du tuto se sont évaporées dès que j’ai dû prendre une vraie décision sans personne pour me tenir la main.
C’est comme regarder quelqu’un cuisiner un soufflé sur YouTube et se dire qu’on sait le faire. La confiance est là. Le soufflé, pas du tout.
Les projets te forcent à connecter les points d’une manière que les tutos ne font jamais. Un tuto t’apprend “voilà comment S3 marche.” Un projet t’apprend “voilà comment S3 marche quand CloudFront cache des fichiers périmés et ta policy IAM est légèrement fausse et le CORS rejette tout et t’es en train de débugger depuis deux heures et t’as juste envie de manger.”
Trois projets qui m’ont beaucoup appris :
Un site portfolio avec CI/CD. S3 pour l’hébergement, CloudFront devant, un domaine branché. Push sur GitHub, ça déploie automatiquement. Ça touche stockage, réseau, cache, automatisation. Ça m’a pris plus de temps que je voudrais l’admettre. Mais quand le premier auto-deploy a marché, j’ai levé le poing. À mon bureau. Tout seul. Aucun regret.
Une API serverless. Lambda derrière API Gateway, DynamoDB derrière. Traiter des données, retourner du JSON. C’est là que “architecture event-driven” est passé de buzzword à truc que je pouvais vraiment construire.
Du monitoring. Dashboards CloudWatch et alertes SNS sur une app en production. C’est le truc chiant qui sépare “j’ai déployé un truc” de “je pourrais maintenir un truc en prod sans que ça prenne feu à 3h du mat’.”
Mets-les sur GitHub. Écris des READMEs. Les recruteurs — je dis ça en tant que mec qui a reviewé des centaines de CV — préfèrent un vrai projet avec du code un peu sale qu’un badge de certification sans rien derrière. Y’a des gens qui sont pas d’accord. C’est pas grave.
Spécialise-toi plus tard (vraiment)
Quand t’as quelques projets, choisis une direction :
- DevOps — Terraform, CI/CD, Kubernetes si t’as du courage
- Data engineering — data lakes, ETL, Redshift ou BigQuery
- Sécurité cloud — IAM en profondeur, chiffrement, conformité
Moi j’étais persuadé que la data m’intéressait. Pendant des mois. J’avais lu des articles, planifié une trajectoire de carrière. Et puis j’ai passé un mois à en faire et j’ai découvert que le DevOps me passionnait bien plus. Toute cette planification, poubelle. C’est exactement pour ça qu’il faut explorer avant de s’engager. Le toi de dans trois mois aura des avis différents du toi d’aujourd’hui.
Toujours les mêmes erreurs
Le piège des tutos. Je t’ai déjà raconté ma saga Kubernetes. Quarante heures de visionnage, zéro de pratique. Si t’as pas ouvert une console cette semaine, t’es pas en train d’apprendre le cloud. T’es en train de regarder quelqu’un d’autre l’apprendre. Je sais que la différence est dure à sentir sur le moment. Elle est réelle quand même.
Oublier l’argent. L’alerte de facturation. Je l’ai mentionnée trois fois maintenant. Je vais probablement la mentionner encore avant la fin de l’article. Le free tier a des limites pas toujours évidentes. Une instance oubliée ici, un transfert de données qui déborde là.
Sauter le réseau. Je l’ai dit plus haut. Je le redis. J’ai vu trop de gens passer trois jours à se battre avec des security groups parce qu’ils avaient jamais appris ce qu’est un masque de sous-réseau. C’est pas glamour. C’est pas négociable.
Certifier avant de construire. Les certifs sont utiles — elles structurent ton apprentissage et donnent aux recruteurs un truc à scanner. Mais une certif sans pratique, c’est du QCM. Construis d’abord. Certifie vers le mois quatre ou cinq. L’examen sera plus facile avec du contexte, et un GitHub avec des vrais projets impressionne plus qu’un badge seul.
On me demande tout le temps si faut savoir coder. Pas pour commencer. Réseau, stockage, compute, IAM — zéro code. Mais dès que tu touches au Lambda ou à l’Infrastructure as Code, Python ou Bash devient nécessaire. Apprends au fil de l’eau. Ça colle mieux quand t’as une vraie raison.
Le free tier, c’est vraiment gratuit ? Oui, avec des limites. Douze mois d’accès à certains services. Mais tout est pas couvert. Mets l’alerte de facturation. Combien de fois je l’ai dit dans cet article ? J’ai perdu le compte.
Bon. Je crois que j’ai fait le tour.
Prêt à apprendre autrement ? Commencer maintenant →