Pour débuter en DevSecOps, cette page couvre le niveau 1 du parcours : les fondations techniques à maîtriser avant d'aborder la moindre exigence de sécurité. Elle s'adresse aux débutants qui savent utiliser un terminal mais n'ont jamais administré un serveur, versionné du code en équipe ou fait tourner un conteneur en production. Vous y trouverez 7 blocs de compétences (Linux, Git, culture DevOps, conteneurs, scripting, réseau, cloud), chacun avec ses guides de référence, plus un projet fil rouge pour valider vos acquis avant de passer au niveau suivant.
Un ingénieur qui maîtrise Linux, Git, les conteneurs et la culture DevOps peut apprendre n'importe quel nouvel outil en quelques jours, parce qu'il comprend déjà les mécanismes sous-jacents. Sans ces bases, chaque outil devient un obstacle qu'il faut réapprendre isolément.
Durée estimée : 60 à 80 heures selon votre point de départ.
Ces bases acquises, place aux exigences de sécurité concrètes : le référentiel Socle DevSecOps en détaille 412, du code au cloud, pour transformer ces fondations en preuves auditables. Pour situer le DevSecOps dans le paysage plus large du DevOps, la page DevSecOps : la sécurité intégrée au développement pose les définitions de base.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Administrer un serveur Debian/Ubuntu ou RHEL en production : utilisateurs, paquets, services systemd, stockage, réseau, SSH
- Travailler avec Git en équipe : branches, merge requests, rebase, hooks, workflows
- Expliquer les métriques DORA et pourquoi elles importent concrètement pour une équipe de livraison
- Faire tourner une application dans des conteneurs Docker et la composer avec Compose
- Écrire des scripts shell qui ne cassent pas en production
- Utiliser Python pour des tâches d'automatisation simples
Bloc 1, Linux
Section intitulée « Bloc 1, Linux »Linux est le substrat universel du DevSecOps : les conteneurs, les pipelines CI, les clusters Kubernetes et la quasi-totalité des serveurs de production tournent dessus. Ignorer Linux, c'est devoir deviner ce qui se passe sous chaque couche d'abstraction plutôt que le comprendre.
Objectif de ce bloc : être autonome sur un serveur Debian ou RHEL sans interface graphique, capable de diagnostiquer un problème sans redémarrer la machine par réflexe.
Éditeurs de texte, maîtrisez au moins l'un d'eux : c'est l'outil que vous utiliserez pour modifier une configuration en urgence sur un serveur sans interface graphique.
Commandes de traitement de données : elles servent quotidiennement à analyser des logs, des fichiers de configuration ou des sorties JSON sans quitter le terminal.
Bloc 2, Git
Section intitulée « Bloc 2, Git »Git est le point de départ de tout pipeline DevSecOps : chaque scan de sécurité, chaque build et chaque déploiement part d'un commit. La maîtrise des workflows d'équipe et de l'historique n'est pas négociable, même pour un profil qui vise l'infrastructure plutôt que le développement.
Objectif de ce bloc : contribuer en autonomie dans un dépôt en équipe, résoudre les conflits de fusion, comprendre l'historique et utiliser les hooks pour automatiser des vérifications.
Bloc 3, Culture DevOps
Section intitulée « Bloc 3, Culture DevOps »Comprendre pourquoi le DevOps existe évite de reproduire les mêmes erreurs avec des outils différents. Un ingénieur qui connaît les Three Ways et les anti-patterns classiques reconnaît un silo organisationnel avant qu'il ne bloque une livraison.
Objectif de ce bloc : savoir expliquer les Three Ways, les métriques DORA, et comprendre pourquoi la sécurité échoue quand elle est traitée en silo plutôt qu'intégrée au flux de travail.
Les métriques DORA (fréquence de déploiement, délai de livraison, taux d'échec des changements, temps de restauration) restent la référence pour mesurer la performance d'une équipe de livraison. Depuis le rapport 2024 de DORA, ces quatre indicateurs historiques ont été complétés par un cinquième, le taux de reprise des déploiements (deployment rework rate), qui mesure la part de changements qui doivent être repris après coup. Le rapport 2025 est allé plus loin en remplaçant le classement Elite/High/Medium/Low par sept profils d'équipe, preuve que le modèle continue d'évoluer. Le détail de chaque métrique est couvert dans le guide dédié Les métriques DORA.
Bloc 4, Conteneurs
Section intitulée « Bloc 4, Conteneurs »Les conteneurs sont le format standard de livraison applicative depuis une dizaine d'années. Sans la maîtrise de Docker et Compose, impossible d'avancer dans le parcours CI/CD : la quasi-totalité des pipelines modernes packagent et testent des images plutôt que des binaires nus.
Objectif de ce bloc : construire, lancer, déboguer et composer une application conteneurisée, en comprenant ce qui se passe réellement sous la commande docker run.
Bloc 5, Scripting
Section intitulée « Bloc 5, Scripting »Un ingénieur DevSecOps qui ne sait pas scripter passe son temps à refaire à la main ce qui devrait être automatisé, ce qui rend chaque intervention lente et source d'erreurs. Le scripting shell reste la compétence la plus rentable du socle : elle sert aussi bien dans un pipeline CI que dans un incident de production à 3 heures du matin.
Objectif de ce bloc : écrire des scripts shell robustes, déboguer des pipelines, et utiliser Python pour l'automatisation quand le shell atteint ses limites.
Bloc 6, Réseau de base
Section intitulée « Bloc 6, Réseau de base »Comprendre IP, ports, DNS, TLS et les pare-feux est indispensable pour diagnostiquer des problèmes de connectivité dans un pipeline ou un cluster. La majorité des incidents « ça ne marche pas » d'un débutant viennent d'une mauvaise résolution DNS, d'un port fermé ou d'un certificat expiré, pas d'un bug applicatif.
Objectif de ce bloc : lire une configuration réseau Linux, diagnostiquer une panne de connectivité avec les bons outils, et comprendre ce qui se passe entre une requête curl et la réponse du serveur.
Bloc 7, Cloud de base
Section intitulée « Bloc 7, Cloud de base »Même sans viser le poste de Cloud Engineer, comprendre les concepts fondamentaux du cloud est nécessaire : IAM (gestion des identités et des accès), régions, VPC (réseau virtuel privé), stockage objet et machines virtuelles. Ces notions reviennent dans quasiment tous les blocs suivants du parcours, notamment les blocs sécurité et CI/CD.
Objectif de ce bloc : situer les modèles IaaS/PaaS/SaaS, comprendre le principe de responsabilité partagée, et savoir ce que recouvre une gestion IAM avant de manipuler un vrai compte cloud.
Livrable pratique, Projet socle
Section intitulée « Livrable pratique, Projet socle »À la fin de ce niveau, vous devez être capable de réaliser ce projet fil rouge qui combine tous les blocs vus plus haut en une seule livraison concrète.
À retenir
Section intitulée « À retenir »- Le socle n'est pas optionnel : sauter ces fondations crée des lacunes qui reviennent en production, souvent au pire moment.
- Linux et Git sont les deux blocs les plus critiques : ce sont les compétences qui servent tous les jours, quel que soit le poste visé ensuite.
- La culture DevOps se lit vite (2 à 3 heures) mais apporte une cohérence de raisonnement qui change beaucoup la façon d'aborder un incident ou un projet.
- Les conteneurs (Docker) sont désormais le format de livraison par défaut : mieux vaut les maîtriser avant d'attaquer Kubernetes au niveau 2.
- Le scripting shell est la compétence la plus rentable à court terme : elle élimine le travail manuel répétitif dès la première semaine.
- Les métriques DORA sont passées à cinq indicateurs en 2024, puis à sept profils d'équipe en 2025 : le domaine continue de se structurer, autant apprendre les bonnes bases dès maintenant.
- Le projet fil rouge (Dockerfile, Compose, hook pre-commit, README) est le meilleur test pour savoir si vous êtes prêt à passer au niveau 2.
- N'avancez pas au niveau 2 tant que ce projet ne tourne pas de bout en bout sans intervention manuelle.