Chapitre 5.9Le DevOps

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.

Ce dernier point a une conséquence que le chapitre sur le déploiement continu a introduite et qui te concerne directement. Quand le code part en production plusieurs fois par jour, la mise en ligne technique et l'ouverture aux utilisateurs deviennent deux décisions distinctes. La fonctionnalité est déjà là, cachée derrière un interrupteur, et c'est toi qui choisis le moment de l'activer, pour tout le monde ou pour un pour cent des visiteurs d'abord. La date de lancement n'est plus une contrainte technique, c'est un choix marketing.

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, avec des branches courtes, fusionnées plusieurs fois par jour.
• 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.

Tu entendras aussi le mot observabilité, qui a largement remplacé monitoring dans le vocabulaire des équipes. L'idée est la même, avec une nuance, on ne se contente plus de surveiller des indicateurs prévus à l'avance, on instrumente le système pour pouvoir répondre à des questions qu'on ne s'était pas encore posées.

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, à situer parmi les autres métiers de la tech.

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é...

Le revers

Le tableau serait incomplet sans sa face sombre. "You build it, you run it" veut aussi dire que les développeurs portent l'astreinte, et qu'une équipe produit doit désormais comprendre le réseau, le cloud, la sécurité et la supervision en plus de son métier. La charge mentale est réelle, et elle explique une partie du turnover dans les équipes techniques.

Beaucoup d'entreprises ont par ailleurs compris "DevOps" comme "on supprime les ops et les développeurs se débrouilleront". Ça donne des équipes qui passent la moitié de leur temps sur l'infrastructure et l'autre moitié à s'excuser du retard sur les fonctionnalités. La suite du mouvement corrige justement ce travers, avec des équipes plateforme qui construisent un socle interne, déploiement, supervision, environnements, pour que chaque équipe produit n'ait pas à devenir experte de tout.

Deux prolongements complètent aujourd'hui le tableau. Intégrer les contrôles de sécurité dans la chaîne automatisée plutôt qu'en audit annuel, et surveiller la facture cloud comme on surveille la performance, puisqu'une équipe qui crée des serveurs en une commande en oublie aussi très facilement.

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.

Ces études reposent sur quatre indicateurs, et ils méritent d'être connus parce que ce sont à peu près les seuls de tout ce guide qu'un lecteur non technique peut demander à son équipe, et comprendre sans aide.

• La fréquence de mise en production : plusieurs fois par jour, une fois par semaine, une fois par trimestre.
• Le délai de livraison : le temps entre le moment où une ligne de code est écrite et celui où elle tourne en production.
• Le taux d'échec : la part des mises en production qui provoquent un incident ou un retour arrière.
• Le temps de rétablissement : combien de temps il faut pour remettre le service debout après une panne, celui que le chapitre sur le monitoring évoquait.

Ces quatre chiffres se suivent dans le temps, et leur évolution en dit plus sur la santé d'une équipe technique que n'importe quel compte rendu.

Pour les équipes non techniques, le changement le plus profond n'est pas la vitesse. C'est qu'on ne raisonne plus en dates de livraison trimestrielles mais en flux continu. Une campagne ne se cale plus sur "la version de mars", elle se cale sur l'activation d'une fonctionnalité déjà en ligne, le jour que tu choisis.