Parcours DevOps : 59 jours du commit à la production
Cinquante-neuf séances d'une heure, une par jour, du 3 novembre au 31 décembre, en quatre modules. Vous partez de zéro, seul, avec des outils gratuits ; vous terminez avec une petite application qui va d'un commit à la production par une chaîne que vous avez construite, documentée et cassée exprès.
Pour qui, et vers quoi
Pour toute personne qui veut apprendre comment un logiciel est construit, livré et maintenu en marche, sans diplôme ni expérience : ni Linux, ni programmation, ni réseau ne sont supposés connus. Le DevOps est une culture et un ensemble de pratiques avant d'être un intitulé de poste ; les métiers auxquels il mène s'appellent le plus souvent ingénieur DevOps, ingénieur fiabilité (SRE, site reliability engineer), ingénieur plateforme ou ingénieur cloud / infrastructure. Beaucoup y arrivent après un premier poste en support, en administration système ou en développement : ce parcours vous donne les bases et les preuves pour candidater à ces premiers postes ou à des postes DevOps juniors.
Ce qu'un autodidacte montre à un recruteur le 31/12, ce n'est pas un certificat mais un dépôt public : quatre livrables (un par module) et un projet final avec sa chaîne, ses tests, son infrastructure en code, son tableau de bord, son runbook et le postmortem d'un incident que vous avez provoqué puis réparé. Un recruteur peut lire l'historique de vos commits : qu'il vaille la peine d'être lu.
La méthode, la même chaque jour
| Durée | Phase | Ce que vous faites |
|---|---|---|
| 20 min | Théorie | La leçon de la séance, sur la page du module, avec ses exercices : répondez avant de lire la suite. |
| 30 min | Pratique | La manipulation sur votre machine Linux, pas à pas, puis le prompt du jour pour votre IA. |
| 10 min | Synthèse | Trois lignes dans votre carnet, puis refaire l'exercice du jour sans notes. |
La synthèse est la phase qu'on saute, et c'est celle qui fait retenir : se rappeler de mémoire, c'est ce qui ancre une connaissance.
Les outils, installés une fois (jour 1)
- Une machine Linux : une machine virtuelle Debian ou Ubuntu dans VirtualBox, ou WSL 2 sous Windows, ou Linux directement. Tout le parcours s'y déroule.
- Git et un éditeur de code (VS Code ou sa version libre VSCodium).
- Un compte sur une forge avec CI : GitHub (GitHub Actions est gratuit sur les dépôts publics) ou une instance Forgejo (Codeberg en fait tourner une, ou vous hébergez la vôtre : voir Homelab 8).
- Docker Engine à partir du jour 20 ; Ansible, OpenTofu, kind et kubectl quand leur module arrive.
- Un carnet : un fichier Markdown par jour, dans un dépôt Git à lui (vous le versionnez à partir du jour 10).
8 Go de RAM suffisent jusqu'au module 3 ; Kubernetes avec kind et la pile de supervision sont plus à l'aise avec 16 Go. Tout est gratuit et tourne sur votre machine : ni compte cloud, ni carte bancaire.
Apprendre avec une IA, sans la laisser apprendre à votre place
Ce parcours s'apprend avec une IA comme tuteur, de préférence un modèle qui tourne sur votre machine (voir votre premier modèle local). C'est un tuteur, pas un prête-plume :
- demandez-lui de vous interroger, d'expliquer un message d'erreur, de relire un script ou une chaîne que vous avez écrits ;
- ne collez jamais sa réponse comme votre travail : retapez-la vous-même, ligne à ligne, et sachez expliquer chaque ligne ;
- vérifiez ce qu'elle dit dans la documentation officielle : elle peut se tromper avec aplomb, inventer une option ou un module qui n'existe pas, ou décrire une ancienne version.
Chaque séance termine sa pratique par une ligne « Avec votre IA : » qui donne le prompt du jour. Dès le module 1, une note « Le faire faire par un agent : » montre aussi ce qu'un agent de code (Claude Code, Kimi Code, OpenFox, un modèle local avec outils) peut reprendre d'une tâche que vous avez déjà faite une fois à la main, et ce que vous vérifiez encore vous-même.
Bien prompter pour le travail DevOps
Un prompt pour du travail d'exploitation est un ticket pour un collègue qui n'a jamais vu votre machine. Un bon prompt contient :
- Rôle et contexte : qui le modèle joue, sur quel système (Debian 13, Docker Engine, GitHub Actions…, avec les versions qu'affiche
--version). - Tâche : un verbe, un résultat.
- Contraintes : ce qui ne doit pas arriver (pas de
sudo, idempotent, aucun secret dans le fichier, versions épinglées). - Entrées : le vrai message d'erreur, le vrai fichier, la vraie sortie de commande, collés, pas résumés.
- Format de sortie : un fichier, un diff, une liste numérotée de commandes, un tableau.
- Exemples : une ligne de ce à quoi ressemble une bonne réponse, si le format compte.
- Comment vous vérifierez : « je lancerai
shellcheck,--check --diff,tofu plan» : dites-le, et faites-le.
Chaque module a une leçon sur le prompt propre à son travail (jour 8 : scripts, jour 26 : chaînes CI, jour 35 : infrastructure en code, jour 50 : incidents). La réponse d'un modèle reste une proposition tant qu'une commande, un test ou la documentation ne l'a pas confirmée.
La règle d'or
Une heure chaque jour vaut mieux que sept heures le dimanche. Si vous manquez un jour, ne rattrapez pas le lendemain : décalez tout d'un jour, et raccourcissez le module 4. Les dates affichées supposent un départ le 3 novembre ; seuls l'ordre et la régularité comptent.
Les quatre modules
Chaque module tient sur une page et se termine par un livrable digne d'un portfolio. Cochez un module quand toutes ses séances sont faites ; votre progression reste dans votre navigateur.
Ressources gratuites recommandées
- Pro Git, de Scott Chacon et Ben Straub, gratuit en ligne et traduit en français (module 1)
- The Missing Semester of Your CS Education (MIT, en anglais) : shell, scripts, Git (module 1)
- The Linux Command Line, de William Shotts, PDF gratuit en anglais (module 1)
- Learn Git Branching, un jeu interactif sur Git, en français (module 1)
- Linux Foundation — Introduction to DevOps and Site Reliability Engineering (LFS162), gratuit, à son rythme, en anglais
- Les bases de Kubernetes, le tutoriel officiel (module 3), et Killercoda pour des labos dans le navigateur
- Les livres SRE de Google, gratuits en ligne, en anglais (module 4)
- DORA : la recherche sur la performance de livraison logicielle (modules 1 et 4)
- roadmap.sh — DevOps, pour situer chaque sujet
La liste de fin de parcours, à cocher le 31/12
- J'explique ce qu'est le DevOps, d'où il vient et comment on mesure ses résultats.
- J'écris un script bash qui vérifie ses erreurs et passe ShellCheck.
- Je crée des branches, je fusionne, je rebase et je résous un conflit avec Git, et je relis une pull request.
- J'écris une chaîne CI qui analyse, teste, scanne et construit une image.
- Je construis une petite image de conteneur sans root et je lance une pile avec Compose.
- Je configure une machine avec un playbook Ansible idempotent et je décris une infrastructure avec OpenTofu.
- Je déploie, expose, mets à jour et ramène en arrière une application sur Kubernetes.
- Je garde les secrets hors de Git et hors des journaux.
- Je lis métriques, journaux et traces, je définis un SLO et une alerte.
- Je mène un incident et j'écris un postmortem sans reproche.
- J'ai un projet public et documenté qui va du commit à la production.
Une case qui ne se coche pas n'est pas un échec : c'est la liste de ce que vous travaillez ensuite.
- 1DevOps module 1 : la culture, Linux, le shell et GitJours 1 à 14 : d'où vient le DevOps et comment on le mesure, la ligne de commande Linux, les droits, les processus, les scripts bash, le réseau vu du terminal, Git en profondeur, les modèles de branches et la revue de code.
- 2DevOps module 2 : chaînes CI/CD et conteneursJours 15 à 28 : intégration et livraison continues, la syntaxe GitHub Actions et Forgejo Actions, les tests dans la chaîne, les runners, les conteneurs du Dockerfile au registre, Compose, et les stratégies de mise en production.
- 3DevOps module 3 : infrastructure en code, Kubernetes et secretsJours 29 à 42 : gestion de configuration avec Ansible, infrastructure en code avec OpenTofu, Kubernetes du premier Pod aux déploiements progressifs, Helm et GitOps, et des secrets qui restent hors de Git.
- 4DevOps module 4 : observabilité, incidents, sécurité, et le projet finalJours 43 à 59 : métriques, journaux et traces avec Prometheus, Grafana, Loki et OpenTelemetry, SLO et alertes, gestion d'incident et postmortems sans reproche, sécurité dans la chaîne, puis une petite appli menée du commit à la production.