Mon premier jour dans le cloud AWS — Journal d'un dev Java qui veut devenir DevOps

mustafa fakhruddin — Sat, 11 Apr 2026 22:04:06 +0000

Pourquoi cet article ?

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.

C'est quoi le cloud, concrètement ?

Avant de plonger dans AWS, Terraform et Kubernetes, il faut répondre à une question toute bête : pourquoi le cloud existe ?

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

Au boulot, quand on a besoin d'un nouveau serveur, voilà ce qui se passe :

On fait une demande
On attend que quelqu'un le provisionne
On le configure à la main (ou presque)
S'il tombe en panne un vendredi soir, c'est la galère

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".

La solution cloud

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.

Les 3 géants du cloud

Provider	Entreprise	Part de marché	Ce qu'il faut retenir
AWS	Amazon	~31%	Le leader, le plus d'offres d'emploi en France
Azure	Microsoft	~25%	Très présent dans les grandes entreprises et ESN
GCP	Google	~11%	Fort en data et machine learning

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.

Les 5 services AWS que je vais utiliser

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à :

Service AWS	En une phrase	Mon équivalent actuel
EC2	Un serveur virtuel	Mon serveur de qualif au boulot, mais créé en 30 secondes
VPC	Un réseau privé dans le cloud	Le réseau interne de ma boîte, avec ses sous-réseaux
RDS	Une base de données managée	Ma base PostgreSQL, mais AWS gère les backups et mises à jour
S3	Du stockage de fichiers illimité	Un disque dur géant accessible de partout via une URL
IAM	La gestion des droits et accès	Les users Linux + sudo, mais en version cloud avancée

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.

Et pourquoi "Infrastructure as Code" ?

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 :

Tu crées un serveur en cliquant dans la console
3 mois plus tard, un collègue te demande : "c'est quoi la config exacte ?"
Tu fouilles dans l'interface... et tu ne retrouves plus tous les réglages
Tu dois recréer la même chose pour un autre client — tu recommences tout à la main

Maintenant imagine l'alternative :

# main.tf — mon serveur en 5 lignes
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  tags = {
    Name = "mon-premier-serveur"
  }
}

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.

Ce que j'ai fait aujourd'hui

✅ 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

Prochaine étape

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 !

Forem: mustafa fakhruddin