DevOps : bien plus qu’un outillage
“Vous pouvez avoir Jenkins, Docker, GitLab CI... et ne pas faire du tout de DevOps.”
La démarche DevOps est souvent réduite, à tort, à un ensemble d’outils techniques. Or, elle repose avant tout sur un changement profond de culture, de collaboration et de responsabilité collective.
Trois croyances fréquentes à déconstruire
| Croyance | Pourquoi c’est faux |
|---|---|
| "On a mis Jenkins, on est DevOps." | Jenkins peut être utilisé dans un processus très cloisonné. |
| "On fait du DevOps, on a Docker." | Conteneuriser une app ne transforme pas l’organisation. |
| "DevOps, c’est automatiser les builds." | Ce n’est qu’une facette du pilier “Automation” de CALMS. |
Ce que DevOps implique réellement
- Priorité aux humains et à la culture avant l’outillage.
- Partage des responsabilités : tout le monde est responsable de la qualité de bout en bout.
- Processus revus collectivement, pas juste "outillés".
Une organisation qui n’a pas changé ses pratiques mais adopte Docker, Ansible ou GitLab CI n’est pas DevOps, c’est une illusion d’efficacité.
Silos vs collaboration : deux logiques opposées
Le modèle en silos : cloisonnement et responsabilités floues
Dans les organisations traditionnelles, les équipes sont séparées par fonction :
- Développeurs : écrivent le code, mais s’arrêtent au merge.
- Ops : assurent le déploiement, mais sans toujours comprendre l’application.
- QA : testent, souvent trop tard.
- Sécurité : intervient après coup.
Exemple typique
Une fonctionnalité est développée, testée, puis transmise à Ops. Le déploiement plante.
Réactions en chaîne :
- QA : "C’était validé"
- Dev : "Ça marchait chez moi"
- Ops : "Personne ne m’avait prévenu"
Résultat : incident, perte de temps, reproches.
Le modèle collaboratif DevOps : transversalité et co-responsabilité
L’approche DevOps propose une structure d’équipe pluridisciplinaire orientée produit ou service.
Chacun est impliqué dès la conception jusqu’à la mise en production et à la supervision.
Exemple de "feature team"
Une équipe DevOps-type peut inclure :
- 3 développeurs
- 1 ingénieur QA
- 1 expert infrastructure
- 1 product owner
- 1 référent sécurité
L’équipe travaille ensemble du design jusqu’au monitoring, avec une vision produit commune.
Symptômes d’un fonctionnement en silos
- Les équipes s’ignorent ou ne se connaissent pas.
- Les responsabilités sont confuses ("Ce n’est pas à moi de gérer ça").
- La communication se fait par tickets, sans échange direct.
- Les incidents sont gérés en mode panique ou recherche de coupables.
Indicateurs d’une organisation DevOps saine
- Feedback rapide entre les rôles (Dev ↔ Ops ↔ QA ↔ Métier)
- Prise de décision collective et rapide
- Documentation à jour, co-produite
- Déploiements automatisés maîtrisés par l’équipe
- Post-mortems partagés, sans blâme
Tableau comparatif : silos vs collaboration DevOps
| Aspect | Organisation en silos | Organisation DevOps (collaborative) |
|---|---|---|
| Communication | Fragmentée, hiérarchique, tickets | Fluide, directe, outils partagés |
| Objectifs | Localisés par service | Partagés autour du produit/service |
| Gestion des incidents | Réaction en cascade, culture blâme | Diagnostic collectif, culture d’apprentissage |
| Prise de décision | En escalade | Équipe autonome |
| Documentation | Dispersée, obsolète | Vivante, intégrée au projet |
D’une logique projet à une logique produit
“DevOps ne vise pas à livrer du code plus vite, mais à livrer de la valeur plus régulièrement et durablement.”
Avant : logique projet
- Budget unique, début/fin définis
- Objectif : "livrer la version X"
- Peu de place pour l’évolution ou l’amélioration continue
Aujourd’hui : logique produit
- Équipe pérenne et pluridisciplinaire
- Objectif : "faire vivre, améliorer et maintenir le service"
- L’équipe s’aligne sur les besoins des utilisateurs et les indicateurs de valeur
Exemple de contraste
| Projet | Produit |
|---|---|
| "Portail client v1 livré après 6 mois" | "Portail client" évolutif, monitoré, amélioré en continu |
| Plus de support après livraison | Équipe responsable du bon fonctionnement long terme |
| Travail en phases (analyse → dev → test → déploiement) | Travail en flux (petites livraisons continues) |