Historiquement, dans les entreprises tech, deux équipes vivaient en opposition permanente.
D'un côté, les développeurs (Dev), qui veulent livrer des fonctionnalités le plus vite possible.
Chaque nouvelle version apporte de la valeur aux utilisateurs.
De l'autre, les opérationnels (Ops, aussi appelés administrateurs système ou "sysadmins"), qui veulent que le
système reste stable. Chaque changement est un risque de panne.
Ces deux objectifs sont en tension directe. Plus on change de choses, plus on risque de casser.
Moins on change, plus le produit stagne. On obtient alors des frictions permanentes,
des mises en production rares et douloureuses, et des incidents dont chaque camp
rejette la faute sur l'autre.
Le mouvement DevOps, né en 2009 autour du Belge Patrick Debois et des premières conférences DevOpsDays,
propose de casser ce mur.
Le principe
DevOps n'est pas un outil ni un poste. C'est une culture qui vise à rapprocher
les développeurs et les opérationnels pour qu'ils travaillent ensemble vers le même objectif :
livrer de la valeur aux utilisateurs, rapidement et de manière fiable.
Concrètement, ça se traduit par plusieurs pratiques :
- L'automatisation : tout ce qui peut être automatisé doit l'être. Les tests, les déploiements, la configuration des serveurs, la surveillance. On élimine les actions manuelles, sources d'erreurs et de lenteur.
- La responsabilité partagée : l'équipe qui développe une fonctionnalité est aussi celle qui la déploie et la surveille en production. "You build it, you run it" (tu le construis, tu le fais tourner), résume Werner Vogels, le CTO d'Amazon.
- Le feedback continu : grâce au monitoring et aux logs, l'équipe sait en temps réel comment se comportent les nouvelles fonctionnalités. Si quelque chose ne va pas, on corrige immédiatement.
- Les petits changements fréquents : au lieu de grosses versions trimestrielles, on déploie de petites modifications plusieurs fois par jour. Chaque changement est petit et facile à annuler.
Les outils du DevOps
La culture DevOps s'appuie sur des outils que nous avons déjà rencontrés dans les chapitres précédents :
- Git pour versionner le code et l'infrastructure.
- CI/CD (GitHub Actions, GitLab CI) pour automatiser les tests et les déploiements.
- Docker et Kubernetes pour empaqueter et orchestrer les applications.
- Monitoring (Grafana, Datadog) pour surveiller la production.
- Infrastructure as Code (Terraform, Ansible) pour décrire les serveurs et les réseaux dans des fichiers plutôt que les configurer à la main.
Ces outils ne font pas le DevOps à eux seuls. Une équipe peut utiliser tous ces outils tout en gardant un fonctionnement en silos. L'outil le plus important du DevOps, c'est le changement de mentalité.
Le rôle de "DevOps engineer"
Paradoxalement, alors que le DevOps prône la suppression des silos,
un nouveau poste a émergé, le DevOps engineer. On croise aussi le SRE (Site Reliability Engineer), un rôle
cousin né chez Google, davantage tourné vers la fiabilité mesurée du service que vers l'outillage.
Son rôle consiste à construire et maintenir les outils d'automatisation, les pipelines CI/CD,
l'infrastructure cloud, le monitoring. C'est un profil hybride qui comprend à la fois
le développement et les opérations.
C'est un métier très demandé et bien rémunéré, car il requiert des compétences
dans beaucoup de domaines : systèmes, réseaux, cloud, scripting, sécurité...
L'impact
Les études DORA, menées chaque année depuis une dizaine d'années sur plusieurs
dizaines de milliers d'équipes, mesurent un écart considérable entre les meilleures et les moins bonnes,
de l'ordre de plusieurs centaines de fois plus de déploiements en production, avec des taux d'échec plus
faibles. Netflix, Amazon, Google ou Spotify ont toutes construit leur succès technique sur ces principes.
Pour les équipes non techniques, l'impact est concret :
les fonctionnalités arrivent plus vite, les incidents sont résolus plus rapidement,
et les mises en production ne sont plus des événements stressants
mais des routines quotidiennes.