L'essentiel en une minute
DevOps c'est quoi ? C'est une façon de travailler qui réunit le développement (Dev) et l'exploitation (Ops) d'un logiciel autour d'un même objectif : livrer souvent, sans casser la production. Ce n'est ni un outil, ni une équipe, mais une culture et des pratiques, soutenues par des outils.
Ce guide s'adresse aux débutants, aux développeurs et aux managers. C'est une synthèse de sources publiques consultées le 6 novembre 2026, sans test de notre part.
Points clés
- Le DevOps vise à abattre le « mur » entre ceux qui écrivent le code et ceux qui le font tourner. La première conférence devopsdays a lieu à Gand, en Belgique, en 2009.
- Deux grilles de lecture structurent la démarche : CALMS (culture, automatisation, lean, mesure, partage) et les trois voies de Gene Kim (flux, rétroaction, apprentissage).
- DORA mesure aujourd'hui la livraison logicielle avec cinq métriques, et non plus quatre : délai de mise en production, fréquence de déploiement, temps de rétablissement après un déploiement raté, taux d'échec des changements et taux de reprise des déploiements.
- Le SRE, le platform engineering et le DevSecOps ne remplacent pas le DevOps : ce sont des façons de l'appliquer à la fiabilité, à l'outillage interne et à la sécurité.
- Côté salaire, le cabinet de recrutement Robert Half donne une médiane nationale de 73 000 € fixes pour 2027, et le cabinet Silkhom 50 à 60 k€ bruts fixes pour un confirmé à Paris.
DevOps c'est quoi : définition et origine
DevOps est un mot-valise formé de development et operations. Il désigne la collaboration de ces deux métiers sur tout le cycle de vie d'une application, de l'idée à la production. Le livre de Google sur le SRE en résume les principes : impliquer l'exploitation dans chaque phase de conception, préférer l'automatisation à l'effort humain et appliquer des pratiques d'ingénierie aux tâches d'exploitation (Site Reliability Engineering, Google, édition de 2016).
Le mur entre Dev et Ops
Le problème de départ est organisationnel. Les développeurs sont jugés sur la vitesse à laquelle ils livrent, l'exploitation sur la stabilité. Atlassian décrit des objectifs séparés et souvent concurrents, des directions et des indicateurs séparés, parfois des bâtiments séparés (Atlassian, histoire du DevOps, consulté le 6 novembre 2026).
Scénario fictif, pour illustrer. Une équipe livre une fois par mois, un vendredi soir : trois cents changements partent ensemble, la production tombe, et personne ne sait lequel est en cause. La même équipe en mode DevOps aurait livré ces changements en petits déploiements automatisés, chacun testé par un pipeline : celui qui casse est identifié en minutes et retiré seul. Ce scénario n'est pas un cas mesuré.
Patrick Debois et les devopsdays de 2009
Patrick Debois, consultant belge, présente en 2008 à la conférence Agile de Toronto un exposé sur l'infrastructure et l'exploitation agiles. Sur son blog (9 octobre 2008), il raconte avoir rencontré des membres de Puppet qui ont proposé une session ouverte sur le sujet, et que personne d'autre que lui n'y est venu.
En juin 2009, à la conférence Velocity, John Allspaw et Paul Hammond présentent « 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr », soit plus de dix déploiements par jour grâce à la coopération entre Dev et Ops chez Flickr (blog de John Allspaw, 23 juin 2009). Debois a vu l'exposé à distance et dit qu'il a décidé, après, d'organiser une conférence (interview sur InfoQ, décembre 2014).
La première devopsdays se tient à Gand, en Belgique, en 2009, avec Patrick Debois comme fondateur (devopsdays.org, consulté le 6 novembre 2026).
Les principes : CALMS et les trois voies
Deux cadres reviennent dans presque toutes les présentations sérieuses du DevOps. À notre sens, CALMS sert plutôt à évaluer une organisation, les trois voies à orienter les décisions.
CALMS
L'acronyme a deux étapes. John Willis écrit qu'il a forgé CAMS (culture, automatisation, mesure, partage) avec Damon Edwards après la première devopsdays américaine, à Mountain View en 2010, et que Jez Humble a ajouté plus tard le L de Lean (John Willis, IT Revolution, 1er mai 2012) :
| Lettre | Principe | En pratique |
|---|---|---|
| C | Culture | Responsabilité partagée de la production, pas de recherche de coupable |
| A | Automatisation | Tests, builds, déploiements et infrastructure scriptés |
| L | Lean | Petits lots, limitation du travail en cours, chasse au gaspillage |
| M | Mesure | Indicateurs de livraison et de fiabilité suivis dans le temps |
| S | Partage (Sharing) | Connaissances, outils et retours d'incident accessibles à tous |
Le guide CALMS d'Atlassian insiste : toute l'automatisation du monde est inutile si développeurs et exploitants ne travaillent pas ensemble.
Les trois voies
Gene Kim a décrit en 2012 trois principes dont, selon lui, découlent toutes les pratiques DevOps, et qui structurent The DevOps Handbook (IT Revolution, Gene Kim, 22 août 2012) :
- Le flux. Optimiser le système entier plutôt qu'un service isolé, ne jamais transmettre un défaut connu à l'étape suivante.
- La rétroaction. Raccourcir et amplifier les boucles de retour, de la production vers le développement.
- L'expérimentation et l'apprentissage continus. Prendre des risques mesurés, apprendre des échecs, et répéter pour maîtriser.
La boucle DevOps en huit étapes
Le cycle de vie DevOps se représente souvent comme une boucle en forme de huit couché, parcourue en continu. Les noms d'étapes varient selon les éditeurs, mais la version la plus courante en compte huit :
| Étape | Ce qu'on y fait | Outils typiques |
|---|---|---|
| Planifier | Découper le travail en petites tâches | Tableau Kanban, tickets |
| Coder | Écrire le code et le versionner | Git, revue de code |
| Construire | Compiler, empaqueter, créer l'image | Docker, outils de build |
| Tester | Lancer les tests automatiques à chaque changement | Frameworks de tests, CI |
| Publier | Produire un artefact (le paquet ou l'image livrable) versionné | Registre d'images, tags |
| Déployer | Mettre en production, souvent progressivement | CD, Kubernetes, GitOps |
| Exploiter | Faire tourner, dimensionner, corriger | Infrastructure as code |
| Surveiller | Observer et réinjecter les retours dans la planification | Logs, métriques, traces |
La dernière flèche fait du DevOps une boucle : ce qu'on observe en production alimente la planification suivante. C'est la deuxième voie de Gene Kim appliquée au quotidien.
Les pratiques et les outils
Les outils changent, les pratiques restent. Voici les six blocs qu'on retrouve dans presque toutes les équipes.
Le contrôle de version. Tout part de Git : le code, mais aussi la configuration et l'infrastructure. Notre guide Git et GitHub pour débutant va de la première commande à la pull request.
L'intégration et la livraison continues (CI/CD). À chaque changement, un pipeline construit, teste et, si tout passe, déploie. Le principe est détaillé dans notre guide pour automatiser ses déploiements, la pratique dans le tutoriel GitHub Actions.
L'infrastructure as code. Serveurs, réseaux et bases se décrivent dans des fichiers versionnés. Terraform reste l'outil le plus connu. Le 10 août 2023, HashiCorp l'a fait passer de la licence MPL 2.0 à la Business Source License 1.1, une licence « source disponible » qui n'est pas open source au sens de l'OSI, créée par MariaDB, qui interdit les offres concurrentes de HashiCorp mais laisse les utilisateurs copier et modifier le code (annonce de HashiCorp). En réponse, plusieurs éditeurs ont créé OpenTofu, un fork (une copie indépendante du code), sous l'égide de la Linux Foundation et toujours sous MPL 2.0 (FAQ d'OpenTofu). Ansible, lui, sert surtout à configurer des machines existantes.
Les conteneurs et l'orchestration. Un conteneur emporte l'application et ses dépendances. Commencez par Docker pour débutants, puis Kubernetes pour débutants. Notre comparatif Kubernetes vs Docker aide à savoir quand un cluster se justifie.
L'observabilité. Le projet OpenTelemetry la définit comme la capacité à comprendre l'état interne d'un système par ses sorties : traces, métriques et logs (OpenTelemetry, consulté le 6 novembre 2026). Il fournit des API open source, indépendantes du fournisseur, et envoie les données vers des outils comme Jaeger ou Prometheus.
Le GitOps. Les principes OpenGitOps 1.0.0 en posent quatre : un état souhaité déclaratif, versionné et immuable, tiré automatiquement par des agents logiciels et réconcilié en continu avec l'état réel (OpenGitOps). Exemple concret : Argo CD tourne dans le cluster Kubernetes, compare en continu l'état réel à celui décrit dans un dépôt Git et applique lui-même les écarts (documentation d'Argo CD). Le pipeline de CI ne pousse plus rien en production : il modifie le dépôt, et l'agent tire le changement.
Mesurer les résultats : les métriques DORA
Pour savoir si une démarche DevOps fonctionne, la référence est DORA (DevOps Research and Assessment). D'abord une société indépendante fondée notamment par Nicole Forsgren, Jez Humble et Gene Kim, auteurs du livre Accelerate, DORA a été rachetée par Google en décembre 2018 et est aujourd'hui un programme de recherche de Google Cloud (annonce de DORA, 20 décembre 2018). Son guide, mis à jour le 5 janvier 2026, liste cinq métriques de livraison logicielle (guide des métriques DORA, consulté le 6 novembre 2026) :
| Famille | Métrique DORA | Ce qu'elle mesure |
|---|---|---|
| Débit | Délai de mise en production des changements | Temps entre le commit et le déploiement en production |
| Débit | Fréquence de déploiement | Nombre de déploiements sur une période |
| Débit | Temps de rétablissement après un déploiement raté | Temps pour se remettre d'un déploiement qui exige une intervention immédiate |
| Instabilité | Taux d'échec des changements | Part des déploiements suivis d'un retour arrière ou d'un correctif urgent |
| Instabilité | Taux de reprise des déploiements | Part des déploiements non planifiés, causés par un incident en production |
Quatre clés devenues cinq
Beaucoup d'articles parlent encore des « quatre métriques DORA ». C'est daté. L'historique de DORA retrace l'évolution : quatre variables en 2014, le remplacement du temps moyen de rétablissement (MTTR) par le temps de rétablissement après un déploiement raté en 2023, puis une cinquième métrique, le taux de reprise des déploiements, en 2024 (historique des métriques DORA, consulté le 6 novembre 2026).
La fiabilité est à part. Ajoutée en 2018 sous le nom de disponibilité, élargie à la fiabilité en 2021, elle relève selon DORA de la performance opérationnelle, pas de la livraison : la même page reconnaît que le rapport 2021 l'a à tort appelée « cinquième métrique ». Le changement de 2023 compte aussi : la nouvelle métrique ne retient que les échecs causés par un changement logiciel, pas les pannes externes.
Ce que dit le rapport le plus récent
Le dernier rapport listé sur dora.dev au 6 novembre 2026 est celui de 2025, consacré au développement assisté par l'IA. Google indique avoir interrogé près de 5 000 professionnels de la technologie dans le monde (blog de Google, 23 septembre 2025). L'usage de l'IA y atteint 90 %, « en hausse de 14 % » sur un an selon les termes de Google, qui ne précise pas s'il s'agit de points.
Sa conclusion, telle que la résume DORA : l'IA agit comme un amplificateur, et les meilleurs résultats viennent du système sociotechnique, c'est-à-dire de l'organisation des équipes autant que des outils.
Attention à l'homonyme. En France, « DORA » désigne aussi le règlement européen sur la résilience opérationnelle numérique du secteur financier, sans lien avec les métriques DevOps.
DevOps, SRE, platform engineering et DevSecOps
Ces quatre termes se recouvrent : les trois derniers sont des façons d'appliquer le DevOps à un problème précis.
Le SRE (Site Reliability Engineering) est né chez Google, où Benjamin Treynor Sloss a pris en 2003 la tête de l'équipe qui en est l'origine. Il le définit comme ce qui arrive quand on demande à un ingénieur logiciel de concevoir une équipe d'exploitation. Google plafonne à 50 % la part de travail d'exploitation de ses SRE pour garder du temps pour l'automatisation (livre SRE de Google). Le second livre résume la relation en une ligne : « class SRE implements interface DevOps » (The Site Reliability Workbook).
Le platform engineering construit une plateforme interne en libre-service, pour que chaque équipe produit n'ait pas à réinventer son pipeline. Le livre blanc du TAG App Delivery de la CNCF explique que l'équipe plateforme réduit le travail commun et intègre la gouvernance dans ses modèles (CNCF, livre blanc sur les plateformes, consulté le 6 novembre 2026). Le bilan de DORA est nuancé : selon le rapport 2024, une plateforme interne améliore la productivité individuelle, la performance des équipes et celle de l'organisation, mais peut aussi réduire le débit et la stabilité des changements.
Le DevSecOps intègre la sécurité à chaque étape du pipeline. Le guide DevSecOps de l'OWASP vise à introduire des contrôles de sécurité sans ralentir la livraison, avec une culture « shift-left », la sécurité traitée dès le début du cycle (OWASP DevSecOps Guideline, consulté le 6 novembre 2026). Silkhom y associe des missions concrètes : scans de vulnérabilités automatisés dans la CI/CD, audit du cloud, réponse aux incidents.
| Approche | Question centrale | Indicateur typique | Livrable |
|---|---|---|---|
| DevOps | Comment livrer souvent et sans casse ? | Métriques DORA | Culture et pipeline partagés |
| SRE | Quel niveau de fiabilité viser ? | Objectifs de niveau de service et budget d'erreur | Service fiable, tâches manuelles réduites |
| Platform engineering | Comment éviter que chaque équipe refasse tout ? | Adoption de la plateforme | Plateforme interne en libre-service |
| DevSecOps | Comment sécuriser sans ralentir ? | Vulnérabilités détectées avant la production | Contrôles de sécurité automatisés |
Pour la sécurité au sens large, notre guide des métiers de la cybersécurité détaille neuf postes.
Le métier d'ingénieur DevOps
Paradoxe : le DevOps n'est pas un poste, mais le marché recrute des ingénieurs DevOps. Ce sont des profils qui construisent les pipelines, l'infrastructure et l'observabilité, et aident les développeurs à s'en servir.
Missions et compétences
Silkhom liste comme missions la réduction des interventions humaines pour accélérer les livraisons, l'automatisation complète de la mise en production et la qualité à chaque étape. Compétences citées : Linux et Windows, Shell, Python, Bash, PowerShell, Jenkins, Ansible, Kubernetes, AWS et Azure (Silkhom). Ajoutez-y Git, Docker et un outil d'infrastructure as code.
Salaire : deux cabinets, deux méthodes
Les chiffres viennent de cabinets de recrutement et ne mesurent pas la même chose. Robert Half donne une fourchette nationale pour l'ingénieur DevOps en 2027, en percentiles (le 25e percentile est le montant sous lequel se situe un quart des salaires) : 61 000 € au 25e, 73 000 € à la médiane, 81 000 € au 75e (Robert Half, consulté le 6 novembre 2026). Son guide des salaires précise qu'il s'agit de salaires fixes, hors primes et avantages ; il ne dit pas s'ils sont bruts.
Silkhom donne des fourchettes en brut annuel fixe, tirées selon le cabinet des données de plus de 25 000 candidats entre 2019 et 2026. À Paris : 45 à 50 k€ en junior (0 à 2 ans), 50 à 60 k€ en confirmé (2 à 5 ans), 60 à 80 k€ en senior. Dans les grandes villes et en région : 38 à 45, 45 à 55 et 55 à 65 k€ (Silkhom, Salaires informatique 2026, consulté le 6 novembre 2026).
La médiane nationale de Robert Half dépasse le haut de la fourchette confirmée de Silkhom à Paris : les méthodes diffèrent trop pour trancher. Notre comparatif des salaires des développeurs confronte six sources, dont l'Apec.
Comment y arriver
Deux portes d'entrée mènent au poste d'ingénieur DevOps. Un développeur back-end qui maîtrise Git et les tests ajoute la CI/CD, Docker, puis le cloud. Un administrateur système qui maîtrise Linux et le réseau ajoute le code, l'infrastructure as code et les pipelines. Dans les deux cas, un projet personnel déployé de bout en bout pèse plus qu'une liste d'outils. Notre guide des certifications cloud aide à structurer l'apprentissage.
Cinq idées reçues sur le DevOps
- « Le DevOps, c'est une équipe. » Placer une « équipe DevOps » entre Dev et Ops recrée un silo : c'est l'anti-modèle « DevOps Team Silo » décrit par Matthew Skelton et Manuel Pais (DevOps Topologies).
- « Le DevOps, c'est un outil. » Jenkins, GitHub Actions ou Kubernetes servent la démarche, ils ne la remplacent pas.
- « Le DevOps, c'est pour les géants du web. » Une petite équipe avec un pipeline, des tests et un déploiement automatisé applique déjà l'essentiel. Au fond, le DevOps, ce sont des boucles courtes, à n'importe quelle échelle.
- « Plus vite, c'est moins stable. » Les métriques DORA mesurent débit et instabilité ensemble pour ne pas sacrifier l'un à l'autre.
- « DevOps et agile, c'est pareil. » L'agile a rapproché le métier et le développement ; le DevOps prolonge ce rapprochement jusqu'à l'exploitation.
Par où commencer : une feuille de route
Plutôt que de répéter nos tutoriels, voici l'ordre dans lequel les suivre :
| Étape | À apprendre | Notre tutoriel | Objectif |
|---|---|---|---|
| 1 | Le terminal Linux | Commandes Linux de base | Se connecter à un serveur et lire des logs |
| 2 | Git et GitHub | Git et GitHub pour débutant | Travailler par branches et pull requests |
| 3 | Docker | Docker pour débutants | Conteneuriser une petite API |
| 4 | CI/CD | GitHub Actions | Tester et publier à chaque push |
| 5 | Mise en production | Nginx et Docker Compose | Servir l'API en HTTPS |
| 6 | Cloud | Hébergement cloud pour développeurs | Choisir où héberger |
| 7 | Orchestration | Kubernetes pour débutants | Comprendre pods, services et déploiements |
Ajoutez ensuite Terraform ou OpenTofu, et OpenTelemetry sur votre projet. Puis mesurez votre fréquence de déploiement : c'est la plus simple des métriques DORA à mesurer pour commencer.
Glossaire DevOps
| Terme | Définition courte |
|---|---|
| CI (intégration continue) | Fusionner et tester automatiquement chaque changement |
| CD (livraison ou déploiement continu) | Rendre chaque version prête à partir en production, ou l'y envoyer automatiquement |
| Pipeline | Suite d'étapes automatisées entre le commit et la production |
| Artefact | Paquet ou image produit par le build, celui qu'on déploie |
| Infrastructure as code (IaC) | Infrastructure décrite dans des fichiers versionnés |
| Fork | Copie indépendante d'un projet open source, qui évolue de son côté |
| Orchestrateur | Outil qui place, redémarre et dimensionne les conteneurs, comme Kubernetes |
| Observabilité | Comprendre un système par ses logs, métriques et traces |
| GitOps | Déploiement piloté par l'état décrit dans Git |
| SLO | Objectif de niveau de service, par exemple un taux de disponibilité |
| Budget d'erreur | Marge d'indisponibilité tolérée par le SLO |
| Toil | Travail d'exploitation manuel et répétitif, à automatiser |
| Percentile | Seuil sous lequel se situe une part donnée des valeurs |
| Post-mortem | Analyse d'incident sans recherche de coupable |
Ce que nous n'avons pas pu vérifier
- Qui a inventé le mot. Des sources secondaires l'attribuent à Patrick Debois, parfois avec Andrew Clay Shafer. Le billet de Debois que nous citons ne nomme pas Shafer, et nous n'avons pas trouvé de source primaire qui tranche.
- La date exacte de la première devopsdays. Le site officiel donne l'année et la ville, pas le jour. Le lieu exact de Velocity 2009 n'est pas indiqué dans les sources lues.
- Le détail des rapports DORA 2024 et 2025. Nous avons lu les pages de DORA et la présentation de Google, pas les rapports complets. Aucun rapport DORA 2026 n'était publié au 6 novembre 2026.
- La méthode des cabinets. Robert Half ne dit pas si ses montants sont bruts ni combien de profils il observe. Leurs chiffres sont des repères.
Questions fréquentes
Un ingénieur DevOps, c'est quoi exactement ?
C'est un ingénieur qui automatise la construction, les tests, le déploiement et la surveillance des applications, et qui gère l'infrastructure sous forme de code. Selon Silkhom, sa mission est de réduire les interventions humaines pour accélérer les livraisons. Ingénieur plateforme, ingénieur cloud ou SRE : ces postes recouvrent des missions proches.
DevOps et SRE, c'est quoi la différence ?
Le DevOps est une démarche générale, le SRE une façon précise de l'appliquer, née chez Google, centrée sur la fiabilité mesurée par des objectifs de niveau de service et des budgets d'erreur. Le livre de Google le résume par « class SRE implements interface DevOps ».
Le DevOps cloud, c'est quoi ?
C'est l'application des pratiques DevOps à une infrastructure louée chez un fournisseur cloud : ressources créées par code, déploiements automatisés, facturation à l'usage. Le cloud facilite le DevOps sans être obligatoire. Notre comparatif AWS, Azure et Google Cloud aide à choisir.
Faut-il savoir coder pour faire du DevOps ?
Oui, au moins des scripts : pipelines CI/CD, infrastructure as code et automatisation sont du code. Silkhom cite Shell, Python, Bash et PowerShell parmi les compétences attendues. Pas besoin d'être développeur senior, mais il faut lire, écrire et versionner du code chaque jour.
À propos de l'auteur
Abdelilah Ourti est ingénieur IA et architecte logiciel. Il conçoit et déploie des applications web et des systèmes d'IA, et publie sur NeurauTech des guides et des comparatifs destinés aux développeurs francophones. Ses autres articles sont réunis sur sa page auteur.
Méthode. Synthèse fondée exclusivement sur des sources publiques consultées le 6 novembre 2026 : pages de DORA et de Google, livres SRE de Google, textes de Patrick Debois, John Allspaw, John Willis et Gene Kim, documentation d'OWASP, de la CNCF, d'OpenTelemetry, d'OpenGitOps, d'Argo CD, d'OpenTofu et de HashiCorp, grilles de salaires de Robert Half et de Silkhom. Les chiffres des cabinets de recrutement sont signalés comme tels. Les citations en anglais sont traduites par nos soins. Aucun test n'a été mené, aucun lien n'est affilié et aucune relation commerciale ne lie l'auteur aux éditeurs mentionnés.
Une erreur ou un chiffre périmé ? Écrivez à contact@neurautech.com : l'article sera corrigé et la date de mise à jour modifiée.
Dernière mise à jour : 6 novembre 2026.
Images : airfocus et Eden Constantino (Unsplash License).
Top comments (0)