Le mouvement DevOps — comprendre avant d'outiller

1. Ce que DevOps cherche à réparer

Historiquement, deux équipes se partagent le cycle de vie d’un logiciel avec des objectifs contradictoires :

Équipe	Objectif	Conséquence
Dev (développement)	Livrer des nouveautés, vite	Le changement est son métier
Ops (exploitation)	Garder la production stable	Le changement est son risque

Chacune optimise son objectif, et le conflit se règle au pire endroit : la mise en production. On appelle ça le mur de la confusion — les développeurs jettent une version par-dessus le mur, les exploitants la reçoivent sans en connaître le contenu, et chaque incident devient un procès en responsabilité (« ça marche sur ma machine » contre « votre code a cassé la prod »).

DevOps est la réponse à ce mur : une culture — pas un outil, pas un poste — où les mêmes personnes, ou des équipes qui coopèrent vraiment, portent le logiciel du commit jusqu’à la production, et pendant sa vie en production. La phrase qui résume le mouvement : you build it, you run it (celui qui construit exploite).

2. La boucle infinie

Le cycle DevOps se dessine en boucle, parce qu’il ne s’arrête jamais : ce qu’on observe en production nourrit ce qu’on planifie ensuite.

flowchart LR
    subgraph Dev
        P[Plan] --> C[Code] --> B[Build] --> T[Test]
    end
    subgraph Ops
        R[Release] --> D[Deploy] --> O[Operate] --> M[Monitor]
    end
    T --> R
    M --> P

Chaque étape de la boucle a ses outils dans ce wiki :

Étape	Ce qu’on y fait	Où creuser
Plan	Décrire et prioriser le travail	Plane, issues GitLab — cf. CI/CD
Code	Versionner, relire	Git, merge requests
Build / Test	Compiler, tester à chaque push	CI/CD
Release / Deploy	Livrer sans clic manuel	GitOps, Dokploy
Operate	Faire tourner	Docker, Dockhand
Monitor	Observer, alerter	Observabilité

3. Les 12 facteurs — rendre l’application déployable

Le manifeste The Twelve-Factor App (Heroku, 2011) répond à une question précise : qu’est-ce qui rend une application facile à déployer, à répliquer et à exploiter ? Douze règles, nées des mêmes douleurs que DevOps, et qui expliquent la forme des applications conteneurisées d’aujourd’hui.

#	Facteur	La règle en une phrase
I	Base de code	Une application = un dépôt Git, déployé en plusieurs environnements
II	Dépendances	Déclarées explicitement (lockfile), jamais supposées présentes sur la machine
III	Configuration	Dans l’environnement (variables), jamais dans le code — c’est elle qui change entre staging et prod
IV	Services externes	Base de données, file, cache : des ressources attachées, remplaçables par leur URL
V	Build, release, run	Trois étapes strictement séparées — on ne modifie jamais le code au moment du run
VI	Processus	L’application est sans état : tout ce qui doit survivre vit dans un service externe
VII	Liaison de port	L’application expose elle-même son port, elle ne dépend pas d’un serveur web injecté
VIII	Concurrence	Monter en charge = lancer plus de processus, pas un processus plus gros
IX	Jetabilité	Démarrage rapide, arrêt propre : un processus peut mourir à tout instant sans drame
X	Parité dev/prod	Les environnements se ressemblent au point que « ça marche chez moi » veuille dire quelque chose
XI	Logs	Un flux d’événements écrit sur la sortie standard — la plateforme le collecte, pas l’application
XII	Processus d’administration	Les tâches ponctuelles (migration, script) tournent dans le même environnement que l’application

Pourquoi ces douze règles vous concernent : ce sont exactement les hypothèses que font Docker, la CI et les plateformes de déploiement. Une application 12-factor se conteneurise en dix lignes de Dockerfile et se déploie sans documentation d’exploitation ; une application qui viole le facteur III (config dans le code) ou VI (état local) se paie à chaque déploiement.

Pour aller plus loin

The Twelve-Factor App, en français
Xavki — chaîne YouTube : le mouvement DevOps expliqué en pratique, du réseau à la CI
Stéphane Robert — blog : la référence francophone IaC / conteneurs / sécurité
La suite du wiki : Docker puis CI/CD