Pourquoi DevOps ?

Avant le DevOps

Au début des années 2000, le monde du développement adopte progressivement les méthodes agiles (Scrum, XP, Kanban…). Résultat : le code est écrit plus vite, les équipes livrent plus souvent… du moins en théorie.

Toutefois, côté production (Ops), rien ne change :

• Des processus ITIL rigides
• Des validations manuelles en cascade
• Une culture centrée sur la stabilité et la prévention du changement

Ce décalage entre Dev et Ops devient une source de tension.

• Les devs veulent livrer vite.
• Les ops veulent la stabilité.
• Les QA veulent tout tester manuellement.
• La sécu arrive à la fin, trop tard.

-> Résultat : un décalage de culture entre Dev et Ops.

Naissance du DevOps

En 2008, Patrick Debois, frustré de la séparation Dev/Ops, organise le premier DevOpsDays à Gand (Belgique). Son but est rapprocher les mondes Dev et Ops autour de l’idée de livrer mieux et ensemble.

"DevOps is not a goal, but a never-ending process of continual improvement." — Jez Humble

Sans DevOps

Le silotage

Chaque métier reste cloisonné :

• Dev fait le code.
• Ops gère l'infra.
• QA teste à la fin.
• La sécu arrive trop tard.

Exemple :
Un Développeur : "J’ai besoin d’une base de données pour développer."
Réponse Ops : "Fais un ticket. On te répond sous 5 jours."
Résultat : les devs bricolent localement, les problèmes arrivent plus tard.

Des déploiements risqués

• Déploiements manuels de nuit ("on ne prend pas de risque en journée").
• Scripts non testés, procédures orales.
• Une personne clé indispensable ("demandez à Paul, c’est lui qui sait comment faire").

Exemple :
Le build est fait à la main, en zip, copié via FTP en prod. L’admin oublie un fichier de config → downtime.

Feedback tardif

• Les bugs ne sont détectés qu’en production.
• Pas de tests automatisés.
• Peu ou pas de monitoring.

Exemple :
Une nouvelle version d’API est déployée. Aucun test d’intégration. Le frontend casse. Les utilisateurs remontent l’erreur avant l’équipe tech.

Culture du blâme

• Les incidents mènent à des reproches, pas à de l’apprentissage.
• Chacun se déresponsabilise.
• Le stress est permanent.

Exemple :
Suite à un crash de prod, on pointe un dev : "Tu n’avais qu’à mieux tester." L'ambiance est délétère, il n'y a pas d’amélioration du processus.

Objectifs de DevOps

Aligner les équipes

DevOps promeut une collaboration transversale :

• Partage des responsabilités.
• Vision produit commune.
• Implication Ops/Sécu dès la conception.

Exemple :
Mise en place d’une équipe "feature team" composée de Dev, QA, Ops → les échanges sont directs, les décisions rapides, les incidents divisés par 3.

Livrer plus vite, plus souvent, avec moins de risque

DevOps favorise la livraison continue (CI/CD), le test automatisé, et le déploiement sécurisé.

Exemple :
Une équipe passe de 1 déploiement mensuel à 1. déploiements par semaine après adoption de GitLab CI + Docker + tests automatisés. Lead time divisé par 6.

Réduire le coût des erreurs

En détectant tôt les problèmes (tests, alerting, monitoring), on évite les grosses crises.

Exemple :
Grâce au monitoring Prometheus + alerting Grafana, une app plante. L’équipe corrige avant que les utilisateurs s’en aperçoivent. MTTR : 15 min.

Tableau comparatif – Avant vs Après DevOps

Aspect	Avant DevOps (Organisation en silos)	Après DevOps (Collaboration & automatisation)
Communication	Cloisonnée, formelle, tickets	Transversale, directe, async (Slack, stand-up)
Structure d’équipe	Équipes séparées : Dev, QA, Ops, Sécu	Équipes pluridisciplinaires orientées produit
Déploiement	Manuel, rare, risqué, de nuit	Fréquent, automatisé, sécurisé
Feedback	Lent, après mise en prod	Rapide, continu dès le code ou le build
Responsabilité	Fragmentée : "pas moi", "c’est les Ops"	Partagée de bout en bout
Temps de cycle	Long (semaines ou mois)	Court (quelques heures ou jours)
Réaction aux incidents	Blâme, panique, goulots d’étranglement	Post-mortem sans blâme, amélioration continue
Outillage	Scripts locaux, Excel, FTP	CI/CD, Git, Ansible, Docker, monitoring centralisé
Valeur métier livrée	Retardée, incertaine	Continue, pilotée par les besoins utilisateurs