Livrez des logiciels comme les vraies équipes le font.

Le DevOps n’est pas un outil ni un titre qu’on achète avec un certificat. C’est une façon de travailler où ceux qui écrivent le logiciel et ceux qui le font tourner cessent de se renvoyer la balle et en deviennent responsables ensemble, de bout en bout.

L’ancienne façon : les développeurs écrivaient le code, l’empaquetaient et le passaient à une équipe d’exploitation qui tentait de le faire tourner en production. Quand ça cassait à 2 h du matin, chacun accusait l’autre. Le DevOps fait tomber ce mur. La même équipe construit, teste automatiquement, livre automatiquement et surveille en production.

Trois idées portent tout le domaine :

• Automatiser tout ce qui se répète — compiler, tester, déployer.
• Faire de petits changements souvent — dix petites livraisons sûres valent mieux qu’une énorme terrifiante.
• Mesurer ce qui se passe — on ne corrige pas ce qu’on ne voit pas.

Les serveurs n’ont pas de souris. Presque tous les serveurs du monde tournent sous Linux, et on leur parle en tapant. Le terminal intimide une semaine, puis devient l’outil le plus rapide que vous possédez.

Les commandes que vous utiliserez chaque jour :

• pwd — où suis-je ? (répertoire courant)
• ls -la — tout lister ici, y compris les fichiers cachés
• cd projets — entrer dans un dossier ; cd .. remonte
• cat fichier.txt — afficher un fichier ; less fichier.txt pour faire défiler
• mkdir, cp, mv, rm — créer, copier, déplacer, supprimer
• grep "erreur" app.log — chercher dans les fichiers

Deux choses bloquent tout débutant sous Linux : les permissions et l’installation de logiciels.

Permissions

Chaque fichier a un propriétaire et des permissions : lecture (r), écriture (w), exécution (x). Quand un script « ne s’exécute pas », il lui manque souvent juste la permission : chmod +x deploy.sh le rend exécutable. Quand vous voyez Permission denied, soit il faut sudo (exécuter en administrateur), soit vous touchez un fichier qui ne vous appartient pas.

Paquets

On ne télécharge pas d’installateurs sous Linux — on utilise un gestionnaire de paquets. Sous Ubuntu/Debian, c’est apt :

• sudo apt update — rafraîchir le catalogue
• sudo apt install git — installer un logiciel

Git est la machine à remonter le temps de votre code. Il enregistre chaque changement pour revenir en arrière, voir qui a changé quoi et quand, et laisser plusieurs personnes travailler sur le même projet sans s’écraser.

Travailler sans Git — final.js, final_v2.js, final_VRAI_final.js — est un cauchemar dont vous ne reviendrez jamais.

Le rythme quotidien, en trois temps :

• git add . — préparer vos changements (choisir ce qui entre)
• git commit -m "Ajout du formulaire de connexion" — enregistrer un instantané avec un message
• git push — l’envoyer au serveur partagé (GitHub)

Une branche est une copie parallèle de votre projet où tester sans toucher la version qui marche. C’est ce qui permet aux équipes d’avancer vite sans tout casser.

Le modèle : main est toujours le code stable, qui marche. Pour ajouter une fonctionnalité, on part d’une branche, on travaille, puis on fusionne quand c’est prêt.

• git checkout -b feature/paiements — créer et basculer sur une nouvelle branche
• travailler, add, commit normalement
• git checkout main puis git merge feature/paiements — la ramener

GitHub est l’endroit où votre historique Git vit en ligne pour qu’une équipe le partage. Il ajoute une idée très importante par-dessus Git : la pull request (PR).

Une pull request dit : « voici ma branche, relisez-la avant qu’elle n’entre dans main ». Un coéquipier lit les changements, commente, approuve. Cette relecture est là où naissent la qualité et le partage de connaissances — et, plus tard, où les tests automatiques tournent avant toute fusion.

« Ça marche sur ma machine » est la plus vieille excuse du logiciel. Docker l’a tuée.

Un conteneur empaquette votre application avec tout ce dont elle a besoin — le code, l’environnement d’exécution, les bibliothèques, les réglages — dans une boîte scellée qui tourne à l’identique sur votre portable, celui d’un collègue, et un serveur en centre de données.

On confond conteneurs et machines virtuelles. Une VM embarque tout un système d’exploitation (lourd, lent à démarrer, des gigaoctets). Un conteneur partage le noyau de l’hôte et n’embarque que votre appli (léger, démarre en une seconde, des mégaoctets). On fait tourner des dizaines de conteneurs là où l’on mettait deux ou trois VM.

Deux mots à ne pas confondre : une image est la recette (un plan enregistré) ; un conteneur est une instance en cours d’exécution de cette image. On construit une image une fois et on lance plusieurs conteneurs à partir d’elle.

On décrit l’image dans un Dockerfile — une simple liste d’étapes :

• FROM node:20 — partir d’une image officielle Node.js
• COPY . /app — copier votre code
• RUN npm install — installer les dépendances
• CMD ["node","server.js"] — comment la démarrer

Les vraies applications ne sont pas un seul conteneur. Une appli web typique, c’est un frontend, une API backend et une base de données — trois conteneurs qui doivent se parler. Les démarrer et les relier à la main est pénible.

Docker Compose permet de décrire toute la pile dans un fichier docker-compose.yml et de tout lancer d’une commande : docker compose up.

Deux sigles que vous entendrez sans cesse. CI (intégration continue) : à chaque envoi de code, il est automatiquement construit et testé, donc le code cassé est attrapé en minutes, pas en semaines. CD (livraison/déploiement continu) : une fois les tests passés, le code est automatiquement envoyé sur un serveur.

Ensemble, ils forment une chaîne (pipeline) : push → build → test → déploiement, sans intervention manuelle. Les humains se trompent en déployant à la main à minuit ; une chaîne refait les mêmes étapes sûres chaque fois.

Mettons quelque chose sur internet. Le déploiement réel le plus simple : un serveur Linux bon marché (un VPS) exécutant votre conteneur.

Les étapes, que vous automatiserez ensuite :

• Louer un VPS (DigitalOcean, Hetzner, Contabo — à partir de quelques dollars par mois)
• Se connecter avec ssh user@ip-du-serveur
• Installer Docker, copier votre image, la lancer avec docker run
• Faire pointer un nom de domaine vers l’IP du serveur

Votre appli a besoin de réglages qui diffèrent entre votre portable et la production : mots de passe de base, clés d’API, quelle URL appeler. Deux règles vous gardent en sécurité.

Ne codez jamais de secrets en dur dans le code. Un mot de passe commité dans Git est un mot de passe fuité pour toujours — des gens scrutent GitHub pour exactement ça. Gardez les secrets dans des variables d’environnement, chargées à l’exécution.

Séparez les environnements. Vous voulez un développement, peut-être une copie staging pour tester, et production pour les vrais utilisateurs — chacun avec sa config, pour qu’un test ne touche jamais de vraies données client.

GitHub Actions exécute votre chaîne gratuitement, là où votre code vit déjà. Vous la décrivez dans un fichier YAML sous .github/workflows/ et elle se déclenche sur des événements — le plus souvent « à chaque push ».

Un workflow est fait de jobs, et chaque job est une liste d’étapes. Une étape exécute une commande ou utilise une action prête à l’emploi.

Une vraie chaîne a des étapes qui s’exécutent dans l’ordre, et une étape ultérieure ne tourne que si la précédente a réussi. C’est votre filet de sécurité.

• Build — compiler le code, construire l’image Docker
• Test — lancer les tests automatiques ; si l’un échoue, on s’arrête et on alerte
• Déploiement — atteint seulement sur la branche main, seulement si les tests passent

On fait attendre les jobs les uns les autres avec needs:, donc deploy a needs: [build, test]. Le code cassé ne peut physiquement pas atteindre la production, car l’étape de déploiement ne s’exécute jamais.

Trois choses rendent les chaînes rapides et sûres.

Le cache : télécharger les dépendances à chaque exécution gaspille des minutes. Mettez-les en cache pour que les exécutions répétées soient rapides — une vraie économie sur des minutes gratuites limitées.

Les artefacts : le résultat d’un build (une appli compilée, une image) peut être sauvegardé et passé au job suivant au lieu d’être reconstruit.

Les secrets : votre déploiement a besoin d’une clé de serveur ou d’un mot de passe de registre. Stockez-les dans les Secrets chiffrés de GitHub, jamais dans le YAML. Référencez-les via ${{ secrets.SSH_KEY }} — ils sont masqués dans les journaux pour ne jamais fuiter.

Un conteneur sur un serveur, c’est facile. Mais que se passe-t-il quand ce serveur meurt à 3 h du matin ? Ou quand le trafic triple pendant une campagne et qu’un conteneur ne suffit plus ? Ou qu’il faut mettre à jour sans coupure ?

Kubernetes (K8s) est le système qui gère pour vous les conteneurs sur plusieurs serveurs. Vous lui dites l’état désiré — « je veux 3 copies de mon appli en permanence » — et il le rend vrai et le maintient. Un conteneur plante ? Il en démarre un neuf. Un serveur meurt ? Il déplace le travail ailleurs. On appelle ça l’auto-réparation.

Trois objets de base font tourner presque tout dans Kubernetes.

• Un Pod est la plus petite unité — généralement un conteneur en cours d’exécution.
• Un Deployment gère les Pods : il maintient le nombre demandé et gère les mises à jour progressives.
• Un Service donne à vos Pods une adresse stable, car les Pods vont et viennent. Il répartit aussi le trafic entre eux.

Pour tourner en production en sécurité, Kubernetes a besoin de trois choses de plus.

Les ConfigMaps contiennent les réglages non secrets (quelle API appeler, drapeaux de fonctionnalité). Les Secrets contiennent les valeurs sensibles (mots de passe, clés), séparées de vos images.

Les sondes de santé (probes) indiquent à Kubernetes si un Pod est réellement sain. Une sonde de vivacité demande « es-tu en vie ? » — sinon, redémarre-le. Une sonde de disponibilité demande « es-tu prêt à recevoir du trafic ? » — sinon, retiens le trafic jusqu’à ce qu’il le soit. Sans elles, Kubernetes enverrait des utilisateurs vers un Pod encore en démarrage ou silencieusement bloqué.

Cliquer dans une console cloud pour créer serveurs, réseaux et bases marche une fois — et devient un désastre à reproduire, documenter ou restaurer. L’infrastructure en code (IaC) consiste à écrire votre infrastructure dans des fichiers texte, à la versionner dans Git et à laisser un outil la construire.

Terraform est l’outil IaC le plus populaire. Vous décrivez ce que vous voulez (des ressources) ; Terraform trouve comment les créer, les modifier ou les détruire pour correspondre.

Trois concepts font tourner Terraform.

• Un fournisseur (provider) est le plugin d’une plateforme donnée (AWS, GCP, Azure, DigitalOcean).
• Une ressource est une chose que vous voulez voir exister — un serveur, une base, un enregistrement DNS.
• Le fichier d’état (state) est la mémoire de Terraform de ce qu’il a déjà construit, pour distinguer « créer » de « modifier l’existant ».

Le flux Terraform est volontairement sûr.

• terraform plan — montre exactement ce qui va changer avant que rien n’arrive. Lisez toujours ceci.
• terraform apply — applique les changements.
• terraform destroy — démonte tout proprement (idéal pour les environnements de test temporaires, et pour ne pas payer des serveurs inactifs).

Les modules permettent d’empaqueter un morceau d’infrastructure réutilisable (par exemple « un serveur web standard + pare-feu ») et de l’utiliser plusieurs fois avec des entrées différentes — le même principe « ne pas se répéter » que les fonctions en programmation.

Une fois votre appli en ligne, vous volez à l’aveugle sans la surveiller. Deux types de données comptent : les métriques (des nombres dans le temps — CPU, mémoire, débit de requêtes) et les journaux (le relevé texte détaillé de ce qui s’est passé).

Prometheus collecte les métriques ; Grafana les transforme en tableaux de bord lisibles. Les quatre signaux d’or à surveiller sur tout service :

• Latence — les réponses sont-elles lentes ?
• Trafic — quelle demande ?
• Erreurs — combien de requêtes échouent ?
• Saturation — vos ressources sont-elles pleines ?

Un tableau de bord que personne ne regarde ne sert à rien à 3 h du matin. L’alerte envoie un message (e-mail, SMS, Slack) quand quelque chose franchit un seuil — « erreurs au-dessus de 5 % pendant 5 minutes ».

L’art est d’alerter sur les symptômes ressentis par les utilisateurs, pas sur chaque soubresaut. Alertez sur « le site renvoie des erreurs », pas sur « le CPU a atteint 80 % pendant 10 secondes ». Trop de fausses alertes et l’équipe apprend à les ignorer — l’échec le plus dangereux, appelé fatigue d’alerte.

C’est ici que tout se relie. Votre projet final réunit tout le cours en un vrai système :

• Le code vit dans Git, relu via des pull requests
• Une chaîne GitHub Actions construit, teste et livre à chaque fusion sur main
• L’appli tourne en conteneur Docker, orchestrée par Kubernetes
• L’infrastructure est définie en Terraform
• Prometheus et Grafana la surveillent, avec une vraie alerte branchée

Quand vous pouvez montrer cela à un employeur — « j’ai construit ça, voici le dépôt, voici le tableau de bord en direct » — vous n’apprenez plus le DevOps. Vous le faites.