Pourquoi cet article ?

C'est quoi le cloud, concrètement ?

Le problème (que je vis tous les jours)

La solution cloud

Les 3 géants du cloud

Les 5 services AWS que je vais utiliser

Et pourquoi "Infrastructure as Code" ?

Ce que j'ai fait aujourd'hui

Prochaine étape Je m'appelle Mustafa. Je suis développeur sur une application Java legacy — Tomcat, Apache, Jenkins, Gradle. Le genre de stack où tu passes tes journées à débugger des problèmes de cookies, des certificats SSL, et des pipelines Jenkins capricieux. J'aime ce que je fais. Mais j'ai réalisé un truc : les parties de mon boulot que je préfère, ce n'est pas le code Java. C'est le déploiement, l'automatisation, le debugging d'infrastructure. Quand je passe une journée à écrire un Dockerfile, à configurer un pipeline CI/CD, ou à diagnostiquer pourquoi le serveur refuse de démarrer — c'est là que je suis dans mon élément. Alors j'ai décidé de devenir ingénieur DevOps. Et de documenter chaque étape du parcours ici, sur Dev.to. Aujourd'hui, c'est le Jour 0 : pas de code, pas d'outil. Juste comprendre le terrain de jeu. Avant de plonger dans AWS, Terraform et Kubernetes, il faut répondre à une question toute bête : pourquoi le cloud existe ? Au boulot, quand on a besoin d'un nouveau serveur, voilà ce qui se passe : Et si on a besoin de 3 environnements identiques (dev, staging, prod) ? On recommence 3 fois. Et si la config diverge entre les environnements ? Bon courage pour débugger le fameux "ça marche sur mon poste". Le cloud, c'est simple : tu loues des ressources informatiques à la demande, et tu paies ce que tu consommes. L'analogie qui m'a aidé à comprendre : Tu ne construis pas ta propre centrale électrique pour alimenter ta maison. Tu branches ta prise et tu paies EDF. Le cloud, c'est pareil — mais pour les serveurs, le réseau et le stockage. Tu veux un serveur ? Tu cliques (ou tu tapes une commande), et en 30 secondes il existe. Tu n'en as plus besoin ? Tu le supprimes et tu arrêtes de payer. Pas de matériel à gérer, pas de datacenter à refroidir. J'ai choisi de commencer par AWS pour une raison pragmatique : c'est celui qui revient le plus souvent dans les offres DevOps en Île-de-France. Mais les concepts sont les mêmes partout — et les outils comme Terraform fonctionnent avec les trois. AWS a des centaines de services. C'est terrifiant au début. Mais la réalité, c'est que 90% des DevOps en utilisent moins de 20. Et pour mon premier projet, j'en ai besoin de seulement 5. Voici comment je les ai compris en les comparant à ce que je connais déjà : Le truc rassurant : ce ne sont pas des concepts nouveaux. Ce sont les mêmes briques que je manipule déjà — serveurs, réseau, stockage, droits — mais dans un autre emballage. Dernière pièce du puzzle. AWS a une interface web (la "console") où tu peux tout créer en cliquant. Alors pourquoi s'embêter à écrire du code ? Imagine ce scénario : Maintenant imagine l'alternative : Ce fichier texte est ta documentation. Il est dans Git, versionné, relu en code review. Tu veux le même serveur pour un autre client ? terraform apply. Tu veux 10 serveurs ? Tu changes un chiffre. Tu veux revenir en arrière ? git revert. C'est exactement le même principe que Docker : au lieu de configurer un serveur à la main, tu écris un Dockerfile. L'Infrastructure as Code, c'est pareil mais pour tout le reste — le réseau, les bases de données, les droits d'accès, le load balancer... Si tu viens du monde Java/Jenkins comme moi, pense-y comme ça : le Jenkinsfile a remplacé la configuration manuelle des jobs Jenkins. Terraform, c'est le Jenkinsfile de ton infrastructure cloud. ✅ Créé mon compte AWS Free Tier (gratuit pendant 12 mois sur plein de services)

✅ Choisi la région eu-west-3 (Paris) — le datacenter le plus proche✅ Activé le MFA sur mon compte root (première règle de sécurité cloud)

✅ Fait un tour dans la console AWS — c'est impressionnant le nombre de services, mais je ne me laisse pas intimider Dans le prochain article, j'installe Terraform sur ma machine et je crée mon tout premier serveur EC2 — en code. Mon premier terraform apply. J'ai hâte de voir ce que ça donne. Si tu es dans la même situation que moi — dev qui veut évoluer vers le DevOps — suis cette série. On apprend ensemble, étape par étape. Cet article fait partie de la série *"De Dev à DevOps — Mon parcours"*. Chaque article correspond à une leçon pratique avec du vrai code et un vrai projet portfolio à la clé. Tu as des questions ou des conseils ? Je suis preneur en commentaires ! Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse