Aller au contenu

Formation DevOps

De zéro à prêt pour l'entretien. Pas de blabla, des analogies simples, des commandes copy-paste, et un projet fil rouge du début à la fin.

10 Modules

De Linux à Kubernetes, un parcours progressif et pratique. Commencer →

Projet fil rouge

Une app React + FastAPI que tu fais évoluer à chaque module. Voir le projet →

Préparation entretien

Questions techniques, mises en situation, system design. S’entraîner →

Cheatsheet

Toutes les commandes essentielles en un seul fichier. Consulter →

Dans le monde du logiciel, il y a généralement trois grands domaines :

  • Frontend — ce que l’utilisateur voit et touche : les boutons, les pages, le design. Le développeur frontend écrit le code qui tourne dans ton navigateur (ou ton appli mobile). Technologies : React, Vue, HTML/CSS, etc.
  • Backend — ce qui tourne sur le serveur, derrière l’écran. Le coeur du backend, c’est l’API : un programme qui tourne 24h/24 sur un serveur et qui reçoit des messages du frontend. Quand tu ouvres ton panier, le frontend envoie un message à l’API (“donne-moi le panier de cet utilisateur”), l’API va chercher les données dans la base de données et les renvoie au frontend qui les affiche. Quand tu cliques sur “Valider ma commande”, le frontend envoie un autre message à l’API, et c’est l’API qui traite la demande : elle vérifie le panier, débite la carte, enregistre la commande en base de données, et répond au frontend “c’est bon, commande validée”. Technologies : Python, Java, Go, Node.js, etc.
  • DevOps — tout ce qu’il y a entre le code et l’utilisateur final. Le code est écrit, ok — mais comment on le teste automatiquement ? Comment on le met en ligne ? Sur quel serveur ? Comment on sait que ça marche ? Comment on gère 10 000 utilisateurs en même temps ? C’est le DevOps.

Concrètement, le DevOps c’est le métier de construire et maintenir l’infrastructure qui permet au code de tourner en production. Tu ne codes pas l’application — tu fais en sorte qu’elle soit livrée, déployée, surveillée, et qu’elle tienne la charge.

En frontend, on te demandera souvent de comprendre le backend et d’avoir un bon sens du design/UX. En backend, on attendra de toi que tu saches aussi faire du frontend basique et parfois du DevOps. Ces deux domaines ont des frontières floues — tu finis vite par porter plusieurs casquettes.

Le DevOps, c’est un domaine à part. En entreprise, on ne va pas te demander de coder des features frontend ou de designer des pages. Ton périmètre est clair : l’infrastructure, le déploiement, l’automatisation, le monitoring. Tu peux te concentrer sur un seul domaine et devenir opérationnel rapidement.

C’est aussi un domaine où il y a beaucoup de demande, et les compétences de base (Linux, Docker, CI/CD, Cloud) s’apprennent en quelques semaines avec de la pratique. Ce cursus est fait pour ça.

Tu ne connais pas les termes ci-dessous (Docker, Terraform, Kubernetes…) ? C’est normal — c’est exactement ce que la formation va t’apprendre, un par un. Commence par le Module 0 et tout s’éclairera au fur et à mesure.

Module 0 (Git + WSL) ─▶ Module 1 (Linux) ─▶ Module 2 (Réseau) ─▶ Module 3 (Docker)
┌──────────────┬───────────┼──────────────┐
▼ ▼ ▼ ▼
Module 4 Module 8 Module 9 (tous les
(CI/CD) (Monitoring) (K8s) modules
│ optionnel sensibilisation suivants)
Module 5
(AWS)
Module 6
(Terraform)
Module 7
(Ansible)
optionnel

Une Task List toute simple : frontend React + backend FastAPI. L’app elle-même est triviale — c’est l’infrastructure autour qui compte.

On la fait évoluer à chaque module :

  • Module 0-1 : On la clone, on la lance en local
  • Module 3 : On la dockerize
  • Module 4 : On ajoute un pipeline CI/CD
  • Module 5 : On la déploie sur AWS à la main
  • Module 6 : On automatise l’infra avec Terraform
  • Module 7 : On configure le serveur avec Ansible
  • Module 8 : On la monitore avec Prometheus + Grafana
  • Module 9 : On l’orchestre avec Kubernetes

Si tu y consacres environ 1h tous les 2 jours, tu peux terminer le cursus en 6 à 8 semaines. Ce n’est pas une course — mieux vaut aller doucement et comprendre que tout survoler.

  1. Suis les modules dans l’ordre (chaque module dépend des précédents)
  2. Tape les commandes toi-même — ne fais pas copier-coller sans lire
  3. Quand tu es bloqué, regarde les indices avant de chercher sur Google
  4. Après chaque module, fais le Coin entretien pour vérifier que tu as compris
  5. Le cheatsheet est ta référence rapide pour les commandes
  6. Les questions d’entretien consolidées sont ta révision finale

Cette question revient souvent en entretien : “C’est quoi concrètement le métier ?”

Le matin :

  • Vérifier les dashboards (Grafana, Datadog) — est-ce que tout tourne bien ? Des errors cette nuit ?
  • Lire les alerts reçues pendant la nuit — trier entre le bruit et les vrais problèmes
  • Regarder les pull requests en attente — review de code, surtout les changements d’infra (Terraform, Dockerfiles, CI/CD)

En journée :

  • Améliorer l’infra — optimiser un pipeline CI/CD trop lent, upgrader une version de Kubernetes, migrer un service vers un nouveau provider
  • Aider les devs — “mon container crash”, “le deployment ne marche pas”, “comment je configure la variable d’env en staging ?”
  • Écrire du code d’infra — Terraform pour un nouveau service, un playbook Ansible, un nouveau workflow GitHub Actions
  • Automatiser — tout ce qui est fait à la main plus de 2 fois doit être scripté

Quand ça va mal (incident) :

  • Diagnostiquer : logs, metrics, traces
  • Corriger en urgence (rollback, restart, scale up)
  • Communiquer avec l’équipe (status page, Slack)
  • Écrire un post-mortem après l’incident (qu’est-ce qui s’est passé, comment éviter que ça se reproduise)

En entretien DevOps, il y a 3 types de questions. Pratique-les dans cet ordre :

ÉtapeType de questionRessource
1. Définitions”C’est quoi un container Docker ?”, “C’est quoi le state Terraform ?”Questions d’entretien
2. Expérience”Raconte-moi un incident en prod”, “Comment tu gères un rollback ?”Questions d’expérience
3. System design”Comment tu déploierais cette app pour 50 000 utilisateurs ?”Exercices system design