Roadmap DevOps : Linux, Docker, CI/CD et cloud dans le bon ordre

Le mot DevOps recouvre à peu près tout et son contraire selon qui l'emploie. Une offre d'emploi va demander Kubernetes, Terraform, Ansible, Prometheus, AWS et Bash dans la même annonce, pour un poste junior, avec deux ans d'expérience exigés.

Face à cette liste, il existe deux réactions courantes : ouvrir dix onglets et commencer par ce qui semble le plus impressionnant, ou refermer la page en se disant que le sujet viendra plus tard. Les deux mènent au même endroit.

Ce qui manque dans ces annonces, c'est l'ordre. Les outils DevOps ne sont pas une collection d'objets indépendants qu'on peut piocher au hasard : ils forment une chaîne où chaque maillon suppose le précédent. Docker manipule des processus, des systèmes de fichiers et des ports Linux. Un pipeline CI/CD exécute des commandes shell dans un conteneur. Le cloud déploie des images construites par ce pipeline. Prendre la chaîne par le milieu revient à lire un manuel dans une langue à moitié apprise.

La séquence qui suit tient en quatre étapes, dans cet ordre, avec un critère de sortie clair à chacune. Elle vise les personnes en reconversion, les développeurs juniors et les curieux non-informaticiens qui veulent comprendre comment une application arrive sur un serveur.

Ce que donne un apprentissage dans le désordre

Voici une situation que produit régulièrement l'ordre inversé. Quelqu'un suit un tutoriel Kubernetes de trois heures, obtient un cluster local qui tourne, applique un manifeste YAML copié depuis la documentation, et voit son pod passer en CrashLoopBackOff. À partir de là, plus rien n'avance. Diagnostiquer ce statut demande de lire les logs du conteneur, de comprendre pourquoi le processus principal s'arrête, de vérifier les variables d'environnement et les permissions sur un volume monté. Chacune de ces vérifications suppose des notions Linux et Docker qui n'ont jamais été posées.

Le même effet se produit un cran plus bas. Un pipeline GitHub Actions qui échoue affiche un message d'erreur brut sorti d'un shell : un code de retour 127, un fichier introuvable, un droit d'exécution manquant. Sans repères sur le terminal, ces messages ressemblent à du bruit.

Cette accumulation de blocages n'a rien à voir avec le niveau de la personne. Elle vient d'un ordre d'apprentissage qui empile des abstractions avant que les couches du dessous soient lisibles. Le sujet revient d'ailleurs souvent au moment de choisir une formation, tant l'offre est dense et peu hiérarchisée, un point développé dans l'article sur comment s'y retrouver dans la formation tech en France.

Le principe : chaque brique fait tourner la suivante

Une règle simple permet de trancher l'ordre d'apprentissage sans réfléchir à chaque nouvel outil : on apprend une couche quand on sait déboguer celle du dessous.

Appliquée aux quatre briques, cette règle donne une pile. Linux fournit le vocabulaire de base : processus, ports, permissions, variables d'environnement, chemins. Docker emballe une application avec ses dépendances dans une image qui utilise ce vocabulaire. Le pipeline CI/CD exécute des commandes dans des conteneurs pour tester puis construire cette image. Le cloud reçoit l'image et la fait tourner sur une machine que personne n'administre à la main.

Une remarque sur les durées affichées : elles supposent de la pratique quotidienne sur un projet réel, pas de la vidéo regardée en accéléré. Quelqu'un qui code déjà tous les jours ira plus vite sur Docker et plus lentement sur le cloud, où les concepts de facturation et de réseau sont neufs.

Étape 1 : Linux, le vocabulaire commun

Tout ce qui suit tourne sur Linux. Les runners GitHub Actions sont des machines Ubuntu, les images Docker officielles sont basées sur des distributions Linux, les serveurs de production le sont dans leur immense majorité. Au moment où ces lignes sont écrites, la version LTS de référence est Ubuntu 26.04, publiée le 23 avril 2026 et maintenue jusqu'en avril 2031.

L'objectif de cette étape tient en une phrase : pouvoir ouvrir un terminal sur une machine distante et comprendre ce qu'on regarde. Devenir administrateur système est un autre métier, qui demande bien davantage.

• Naviguer et manipuler des fichiers sans interface graphique
• Lire et modifier les permissions, comprendre à quel utilisateur appartient un processus
• Se connecter en SSH avec une paire de clés, sans mot de passe
• Voir quel processus écoute sur quel port
• Lire des logs, filtrer avec grep, suivre un fichier en temps réel
• Écrire un script bash de vingt lignes avec une condition et une boucle
• Comprendre les variables d'environnement et le PATH

Les commandes ci-dessous couvrent une bonne partie du quotidien. Elles ne sont pas là pour être mémorisées, mais pour donner une idée du niveau visé.

# Qui écoute sur le port 3000 ?
ss -tlnp | grep 3000
 
# Suivre les 50 dernières lignes d'un log en direct
tail -n 50 -f /var/log/nginx/error.log
 
# Rendre un script exécutable, puis le lancer
chmod +x deploy.sh
./deploy.sh
 
# Générer une clé SSH dédiée au déploiement
ssh-keygen -t ed25519 -C "deploy@monprojet" -f ~/.ssh/deploy_monprojet
 
# Espace disque restant, par point de montage
df -h

Le critère de sortie de l'étape : louer un petit VPS, s'y connecter en SSH avec une clé, y installer un serveur web et faire répondre une page sur son adresse IP. Tant que cette manipulation demande de copier un tutoriel ligne par ligne sans comprendre, l'étape n'est pas finie. C'est exactement le périmètre de la formation Linux et ligne de commande pour développeurs, deux jours pour poser ces bases.

Un mot sur Git, qui n'apparaît pas dans les quatre briques et devrait pourtant être acquis avant de commencer. Un pipeline CI/CD se déclenche sur des événements Git : un push, une pull request, un tag. Sans branches et pull requests maîtrisées, l'étape 3 devient illisible. La formation Git et GitHub pour débutants couvre ce prérequis.

Étape 2 : Docker, l'application et ses dépendances

Docker répond à une question précise : comment faire tourner la même application, avec la même version de Node ou de PHP et les mêmes bibliothèques système, sur un poste de développement, sur un runner de CI et sur un serveur. La réponse tient dans une image, un modèle figé à partir duquel on démarre des conteneurs.

Six notions suffisent pour être autonome, et elles se travaillent dans cet ordre : image et conteneur, Dockerfile, volumes, réseau entre conteneurs, Docker Compose, build multi-étapes. Le détail de cette progression est développé dans l'article sur la séquence Docker minimale pour un développeur web, et le contexte général dans pourquoi Docker concerne aussi les développeurs.

Un Dockerfile en deux étapes, pour une application Node, ressemble à ceci. La première étape installe les dépendances et construit, la seconde ne garde que ce qui est nécessaire à l'exécution.

# Étape de build
FROM node:22-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
 
# Étape finale, image allégée
FROM node:22-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY package*.json ./
RUN npm ci --omit=dev
COPY --from=build /app/dist ./dist
USER node
EXPOSE 3000
CMD ["node", "dist/server.js"]

Deux lignes méritent une explication. COPY package*.json ./ avant COPY . . permet à Docker de réutiliser la couche d'installation des dépendances tant que le fichier de lock ne change pas, ce qui divise le temps de build par un facteur important sur les projets qui itèrent vite. USER node fait tourner le processus sans les droits root, une pratique attendue en production et facile à oublier.

Le critère de sortie : conteneuriser un projet personnel avec sa base de données, le lancer avec un seul docker compose up, et savoir expliquer ce que contient chaque ligne du Dockerfile. La formation Docker pour développeurs web tient sur trois jours et s'arrête volontairement avant l'orchestration.

Étape 3 : CI/CD, automatiser ce qu'on fait déjà à la main

Un pipeline d'intégration continue n'invente rien. Il rejoue automatiquement les commandes qu'on tape déjà : installer les dépendances, lancer les tests, vérifier le style du code, construire une image. C'est pour ça que cette étape arrive après les deux premières, et pas avant.

Trois distinctions structurent le vocabulaire du domaine. L'intégration continue vérifie chaque modification du code. La livraison continue maintient le code toujours déployable et automatise jusqu'à un environnement de préproduction. Le déploiement continu va jusqu'en production sans intervention humaine. La plupart des équipes s'arrêtent au deuxième niveau, avec une validation manuelle avant la production.

Un premier workflow GitHub Actions utile tient en quinze lignes.

name: CI
on:
  pull_request:
    branches: [main]
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v6
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test

Les numéros de version des actions officielles changent régulièrement : checkout@v7 et setup-node@v6 sont les majeures courantes en août 2026, à vérifier sur le dépôt de chaque action avant de copier. Sur un projet sensible, on épingle même à un SHA de commit plutôt qu'à un tag, parce qu'un tag peut être déplacé par le mainteneur.

Une fois ce workflow en place, l'étape suivante consiste à le brancher sur les règles de protection de la branche principale : interdire le push direct sur main, exiger que la CI soit verte avant de pouvoir fusionner une pull request. C'est le moment où le pipeline cesse d'être décoratif.

Viennent ensuite les secrets, les environnements séparés pour la préproduction et la production, le build et la publication de l'image Docker sur un registre, puis le déploiement automatique. La formation CI/CD avec GitHub Actions déroule cette progression sur trois jours et se termine par un pipeline complet, de la pull request au déploiement avec approbation manuelle.

Le critère de sortie : une pull request sur un projet personnel qui déclenche les tests, bloque la fusion en cas d'échec, et un merge sur la branche principale qui construit une image et la pousse sur un registre.

Étape 4 : le cloud, et pourquoi il arrive en dernier

Le mot cloud désigne deux choses très différentes selon le contexte. D'un côté, des plateformes qui prennent une image ou un dépôt et le font tourner sans qu'on touche à un serveur : Render, Railway, Fly.io, Scaleway Serverless Containers. De l'autre, les fournisseurs d'infrastructure complets, AWS, Google Cloud, Azure, OVHcloud, avec leurs centaines de services et leur logique de facturation propre.

La première catégorie s'apprend en quelques heures quand les trois étapes précédentes sont acquises. On pousse une image, on renseigne des variables d'environnement, on obtient une URL en HTTPS. C'est suffisant pour la quasi-totalité des projets personnels et pour beaucoup de projets professionnels.

La seconde demande un investissement d'un autre ordre. Avant d'ouvrir la documentation d'AWS, il vaut mieux avoir déjà déployé à la main sur un VPS, parce que les services managés ne sont compréhensibles qu'en tant qu'automatisation de gestes qu'on a faits soi-même. Un groupe de sécurité est une règle de pare-feu. Un load balancer répartit le trafic entre plusieurs machines. Sans référentiel concret, ces objets restent des cases dans une interface.

Sur l'infrastructure as code, un point mérite d'être connu avant de choisir un outil. En août 2023, HashiCorp a changé la licence de Terraform, passant de la Mozilla Public License à la Business Source License, qui n'est pas une licence open source au sens de l'Open Source Initiative. Une partie de l'écosystème a forké la dernière version libre pour créer OpenTofu, projet hébergé par la Linux Foundation et accepté au CNCF en avril 2025. Le langage de configuration est le même des deux côtés et la migration se résume le plus souvent à changer de binaire. Apprendre l'un revient donc à apprendre l'autre, et ce choix se pose après la roadmap décrite ici, pas pendant.

Quant à Kubernetes, mon avis est tranché : il n'a pas sa place dans une roadmap de départ. Kubernetes résout des problèmes d'échelle et de résilience que les projets d'apprentissage n'ont pas, et le temps investi dessus avant d'avoir déployé quelque chose de simple est du temps perdu. Il s'apprend quand un besoin réel le justifie, en général dans le cadre d'un poste où l'infrastructure existe déjà.

Les pièges qui font perdre le plus de temps

Regarder au lieu de taper

Une vidéo de six heures sur Docker donne la sensation d'avoir avancé et ne laisse presque rien. Ces briques s'ancrent par la répétition sur un projet à soi, avec ses propres erreurs à réparer. Un projet médiocre déployé pour de vrai apprend plus que trois tutoriels suivis jusqu'au bout.

Écrire des secrets dans un fichier versionné

Une clé d'API dans un docker-compose.yml poussé sur GitHub, un mot de passe de base de données dans un Dockerfile : ces erreurs sont fréquentes et coûteuses, parce qu'un secret publié dans l'historique Git y reste même après suppression du fichier. Les secrets vivent dans des variables d'environnement, dans les secrets du dépôt GitHub, ou dans un gestionnaire dédié.

Confondre l'outil et la pratique

GitHub Actions, GitLab CI, Jenkins et CircleCI font la même chose avec des syntaxes différentes. Ce qui se transfère d'un outil à l'autre, ce sont les notions : un déclencheur, un job, une étape, un artefact, un environnement. Quelqu'un qui maîtrise ces notions sur GitHub Actions apprend GitLab CI en une journée.

Négliger les tests avant de monter le pipeline

Un pipeline d'intégration continue sur un projet sans tests automatisés ne vérifie rien. Il installe des dépendances et affiche une coche verte. Écrire trois ou quatre tests sur les fonctions critiques avant de construire le pipeline change entièrement sa valeur.

Laisser tourner une facture cloud oubliée

Les offres gratuites des grands fournisseurs demandent une carte bancaire et basculent en facturation à l'usage au-delà d'un certain seuil. Une instance oubliée, un volume de stockage jamais supprimé, un transfert de données sortant mal évalué : les factures surprises sur des comptes d'apprentissage sont assez répandues pour que la précaution vaille la peine. Une alerte de budget se configure en cinq minutes sur AWS comme sur GCP, et il faut le faire avant de créer la première ressource.

Attendre d'avoir tout appris pour montrer quelque chose

Un dépôt GitHub avec un Dockerfile propre, un workflow de CI qui tourne et une application déployée quelque part vaut plus, dans un entretien, qu'une liste de certifications sur un CV. Ce dépôt est atteignable à la fin de l'étape 3, sans avoir touché au cloud.

Par où commencer cette semaine

Prendre un projet existant, même petit, même laid. Le faire tourner sur une machine autre que celle de développement. Noter chaque endroit où ça coince, parce que cette liste est le programme d'apprentissage le plus juste qu'on puisse obtenir.

La roadmap ci-dessus n'est pas la seule possible. Une personne qui vise un poste d'administrateur système passera plus de temps sur Linux et le réseau, une autre qui vise le développement s'arrêtera peut-être à la fin de l'étape 3. L'ordre, lui, tient dans tous les cas.

Questions fréquentes