Qu'est-ce que le DevOps ?
Résumé : le DevOps est un ensemble de pratiques culturelles et techniques visant à réduire le délai entre l'écriture d'une modification et sa mise à disposition, tout en améliorant la fiabilité. Cette leçon donne une définition solide, dresse la liste de ce que le DevOps n'est pas, retrace son histoire depuis 2007, et le distingue clairement de l'agilité, du SRE et de l'ingénierie de plateforme.
1. La définition
La partie de la définition qu'on oublie systématiquement : « sans dégrader la fiabilité ». Le DevOps n'est pas « déployer plus vite ». C'est « déployer plus vite et plus sûrement ». Une équipe qui déploie vingt fois par jour en cassant la production une fois sur trois ne fait pas du DevOps — elle fait du désordre accéléré.
2. Ce que le DevOps n'est pas
Le point 2 mérite d'être insisté, car c'est l'erreur la plus commune. Créer une « équipe DevOps » placée entre le développement et l'exploitation produit trois murs au lieu d'un. Le développement transmet à l'équipe DevOps, qui transmet à l'exploitation. Vous avez ajouté une transmission tout en croyant les supprimer. Ce sujet est développé en leçon 5.
Le point 6 corrige un préjugé fréquent chez les personnes venant d'environnements réglementés. On imagine parfois que le DevOps consiste à contourner les contrôles pour aller vite. C'est l'inverse : une équipe DevOps mature exécute plus de vérifications qu'une équipe classique — tests, analyses de sécurité, contrôles de conformité — mais elles s'exécutent en quelques minutes au lieu de trois semaines.
3. DevOps et agilité — la distinction
La formule qui clarifie définitivement : l'agilité rend l'équipe capable de produire du code toutes les deux semaines. Le DevOps rend l'organisation capable de le mettre entre les mains des utilisateurs dans la journée. Sans le second, le premier produit surtout du stock.
4. Petite histoire du DevOps
Deux noms à retenir pour un entretien : Patrick Debois, qui a organisé le premier DevOpsDays en 2009 et à qui l'on attribue le terme, et Gene Kim, auteur du Phoenix Project et coauteur des travaux de recherche qui ont fourni les preuves chiffrées.
L'étape H10 explique une évolution importante du marché de l'emploi. L'idéal du DevOps — chaque équipe autonome de bout en bout — a rencontré une limite pratique : la charge cognitive. Maîtriser Kubernetes, Terraform, l'observabilité et la sécurité en plus de son métier est irréaliste pour une équipe produit. D'où l'apparition des équipes de plateforme, qui construisent des services internes en libre-service. C'est aujourd'hui l'un des profils les plus recherchés.
5. DevOps, SRE, plateforme — le tableau clair
| Critère | DevOps | SRE | Ingénierie de plateforme |
|---|---|---|---|
| Nature | Culture et pratiques | Discipline d'ingénierie | Fonction produit |
| Origine | Communauté, 2009 | Google, 2003 | Industrie, vers 2020 |
| Question centrale | Comment livrer vite et sûrement ? | Comment garantir la fiabilité ? | Comment rendre les équipes autonomes ? |
| Outils propres | Aucun en particulier | SLO, budget d'erreur, règle des 50 % | Portail interne, modèles, libre-service |
| Mesure du succès | Délai et fiabilité | Respect des SLO | Adoption par les équipes |
| Client | L'utilisateur final | L'utilisateur final | Les équipes de développement |
La distinction la plus utile : le SRE et l'ingénierie de plateforme sont deux réponses concrètes à la question posée par le DevOps. Le SRE apporte des outils de mesure et une méthode de fiabilité. La plateforme apporte des services prêts à l'emploi qui réduisent la charge des équipes.
Le point le plus important sur l'ingénierie de plateforme : son client interne, ce sont les développeurs. Une plateforme que les équipes contournent est un échec, même si elle est techniquement excellente. Cela change tout dans la façon de la concevoir — c'est un produit, avec des utilisateurs à convaincre.
6. Comment reconnaître une vraie démarche DevOps
La question 5 est la plus révélatrice de toutes, et elle est rarement posée. Le délai pour qu'un nouvel arrivant déploie sa première modification en production mesure d'un seul coup la qualité de la documentation, le degré d'automatisation, la simplicité de l'architecture et le niveau de confiance de l'organisation. Une réponse en jours indique une maturité réelle ; une réponse en mois indique une accumulation de connaissances non partagées.
La question 6 est excellente en entretien, du côté du candidat comme du recruteur. Une organisation qui n'a jamais testé son retour arrière n'en a pas — elle a une procédure théorique.
Retenir en 30 secondes
- DevOps = réduire le délai entre l'écriture d'une modification et sa mise à disposition, sans dégrader la fiabilité.
- La moitié oubliée de la définition : « sans dégrader la fiabilité ». Vite et sûrement.
- Ce n'est pas un outil, ni une équipe, ni (à l'origine) un poste, ni de l'agilité, ni l'absence de contrôles.
- Créer une « équipe DevOps » ajoute un troisième silo — c'est l'anti-modèle le plus répandu.
- Le DevOps augmente le nombre de contrôles, mais les rend automatiques et rapides.
- Agilité = décider quoi construire. DevOps = livrer et exploiter. L'agilité sans DevOps produit du stock.
- Histoire : Amazon 2006 (you build it, you run it) → Flickr 2009 (dix déploiements par jour) → Patrick Debois et le premier DevOpsDays → Docker 2013 → Kubernetes et SRE → ingénierie de plateforme.
- Deux noms : Patrick Debois (le terme) et Gene Kim (Phoenix Project et les preuves chiffrées).
- SRE et plateforme sont deux réponses concrètes à la question du DevOps. Le client d'une plateforme, ce sont les développeurs.
- La question la plus révélatrice : combien de temps un nouvel arrivant met-il à déployer sa première modification ?
Suivant : Les trois voies et le modèle CALMS →