Bonnes pratiques DevSecOps : les 4 piliers à maîtriser

Adopter des outils sans méthode peut compromettre la sécurité, la fiabilité et la maintenabilité des systèmes. Installer Kubernetes ne rend pas une application plus sûre ; mettre en place un pipeline CI/CD ne garantit pas des déploiements fiables. C'est la manière d'utiliser ces outils qui fait la différence.

Cette leçon de synthèse rassemble les bonnes pratiques DevSecOps de 2026 en quatre piliers : sécurité de la chaîne d'approvisionnement (SBOM, SLSA), fiabilité pilotée par les SLO et l'error budget, observabilité avec OpenTelemetry, et standardisation par les Golden Paths. Elle s'adresse aux équipes qui ont déjà des outils en place et cherchent à les faire converger. Les commandes et configurations montrées ont été exécutées avec les versions citées.

Ce que vous allez apprendre

• Structurer vos pratiques autour des quatre piliers : sécurité, fiabilité, exploitabilité, maintenabilité
• Générer et analyser un SBOM, signer une image et situer votre build sur l'échelle SLSA
• Définir des SLI, des SLO et un error budget pour arbitrer entre vélocité et stabilité
• Instrumenter un service avec OpenTelemetry et router ses signaux par un collecteur
• Construire un Golden Path qui standardise sans imposer de bureaucratie
• Repérer les pièges les plus fréquents (sécurité en fin de cycle, alertes ignorées, sauvegardes non testées)

Cette leçon clôt la formation : elle relie des notions vues dans les modules précédents, des fondamentaux DevSecOps à la fiabilité, sans les redire. Chaque section renvoie vers la leçon qui approfondit le sujet.

Quels sont les 4 piliers des bonnes pratiques DevSecOps ?

Les bonnes pratiques DevSecOps s'organisent autour de quatre piliers complémentaires, chacun répondant à une question que tout système en production doit se poser. En négliger un crée tôt ou tard des problèmes : une application peut être sécurisée mais impossible à diagnostiquer, ou fiable mais impossible à faire évoluer. Les Golden Paths appliquent les quatre par défaut, et les indicateurs DORA mesurent l'effet.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Pilier	Objectif	Question clé
Sécurité	Protéger les données et les systèmes	Comment détecter une vulnérabilité avant la production ?
Fiabilité	Garantir disponibilité et performance	Comment résister à une panne sans impact utilisateur ?
Exploitabilité	Surveiller, diagnostiquer, réagir	Comment trouver la cause d'un incident en quelques minutes ?
Maintenabilité	Faire évoluer et corriger facilement	Comment modifier ce système dans six mois ?

Glissez pour voir

Pourquoi formaliser des bonnes pratiques ?

Sans cadre commun, chaque équipe invente ses propres solutions, souvent dans l'urgence. Les erreurs se répètent, la dette technique s'accumule, et les incidents deviennent la norme plutôt que l'exception. Ces symptômes recoupent les anti-patterns DevOps : les reconnaître tôt évite des mois de rattrapage.

Les signaux d'alerte les plus fréquents sont connus : vulnérabilités découvertes en production, configurations dupliquées et scripts ad hoc, incidents qui se répètent faute de capitalisation, environnements qui divergent, sauvegardes jamais restaurées, alertes ignorées et tableaux de bord abandonnés.

Pilier 1 : comment intégrer la sécurité ?

La sécurité coûte moins cher quand elle est intégrée tôt. Une vulnérabilité détectée au commit se corrige en quelques minutes ; la même découverte en production peut demander des jours de travail, sans compter l'impact.

Le shift-left déplace les contrôles au plus tôt : analyser les dépendances avant le merge, détecter les secrets avant le commit, bloquer les images vulnérables avant la production. En amont du code, le threat modeling STRIDE aide à prioriser les scénarios d'attaque les plus probables.

Pour prioriser vos contrôles, l'OWASP Top 10:2025, publié en version finale en janvier 2026, place le contrôle d'accès défaillant en tête (A01), la mauvaise configuration de sécurité en A02, puis les défaillances de la chaîne d'approvisionnement logicielle en A03, qui élargissent l'ancienne catégorie des composants vulnérables. La leçon OWASP Top 10 appliqué au DevSecOps traduit ces risques en contrôles CI/CD.

Les pratiques essentielles

Ces pratiques forment le socle minimal. Elles sont rangées par facilité de mise en œuvre : les trois premières se déploient en quelques jours, les suivantes demandent plus d'organisation et l'adhésion de plusieurs équipes.

Pratique	Action concrète
Analyse des dépendances	Scanner les dépendances dans la CI (Trivy, Grype, OSV-Scanner)
Gestion des secrets	Jamais de secret en clair ; Vault, SOPS ou Sealed Secrets
Moindre privilège	Comptes de service aux permissions minimales, revus chaque trimestre
Analyse d'images	Bloquer les images portant des CVE critiques corrigeables
SAST et DAST	Analyse statique et dynamique intégrées au pipeline
Revue de code sécurité	Checklist sécurité dans les merge requests

Glissez pour voir

SBOM et SLSA : sécuriser la chaîne d'approvisionnement

La chaîne d'approvisionnement logicielle est devenue critique après SolarWinds et Log4Shell : un code impeccable ne protège de rien si une dépendance ou le build est compromis. Deux standards se complètent : le SBOM répond à « de quoi est fait mon logiciel ? », SLSA à « puis-je faire confiance à la façon dont il a été construit ? ». La leçon sécurité de la supply chain détaille attaques et contre-mesures.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

SBOM

Le Software Bill of Materials (SBOM) est l'inventaire complet des composants d'un logiciel, dépendances directes et transitives, aux formats SPDX (Linux Foundation) ou CycloneDX (OWASP). Il sert à tracer les CVE, vérifier les licences et répondre en minutes à « sommes-nous touchés ? ». Avec Syft 1.51 et Grype 0.118, sur une image épinglée par digest :

# Générer le SBOM (la sous-commande « packages » est dépréciée au profit de « scan »)
syft scan alpine:3.22@sha256:5291449c3df73caf6ed85e649dec1b9e818b39a5d8c871e97afc13e9cd5e8fa8 \
  -o spdx-json=sbom.spdx.json

# Chercher les vulnérabilités connues dans le SBOM, sans réanalyser l'image
grype sbom:./sbom.spdx.json

Grype liste chaque paquet vulnérable avec sa CVE, sa sévérité et son score EPSS (probabilité d'exploitation).

SLSA

SLSA (Supply-chain Levels for Software Artifacts) a abandonné en 2023 son ancien barème à quatre niveaux pour une piste Build cumulative de L0 à L3 ; la version 1.2, approuvée, y ajoute une piste Source.

Niveau Build	Exigences	Protège contre
L0	Aucune garantie : build local, sans provenance	Rien
L1	Provenance générée, même produite par le développeur	Erreurs de build non documentées
L2	Build sur un service hébergé qui génère et signe la provenance	Falsification a posteriori de la provenance
L3	Build isolé, provenance infalsifiable même par le script de build	Compromission du pipeline lui-même

Glissez pour voir

Sur GitHub Actions, le générateur officiel est un workflow réutilisable, appelé au niveau du job et non comme une étape. Exception documentée à la règle d'épinglage par SHA : son README exige une référence par tag complet @vX.Y.Z, sans quoi slsa-verifier ne peut pas vérifier le builder.

  provenance:
    needs: [build]
    permissions:
      actions: read       # lire le workflow appelant
      id-token: write     # signer la provenance par OIDC
      contents: write     # publier la provenance dans la release
    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v2.1.0
    with:
      base64-subjects: "${{ needs.build.outputs.digests }}"

Signature

Cosign signe une image et vérifie la signature ; Sigstore fournit l'infrastructure publique (journal de transparence Rekor) qui rend la vérification possible sans gérer soi-même des certificats. On signe toujours une image par son digest, jamais par un tag, qui peut être déplacé :

cosign generate-key-pair
cosign sign --key cosign.key registry.example.org/app@sha256:<digest>
cosign verify --key cosign.pub registry.example.org/app@sha256:<digest>

Testé avec Cosign 3.1.1 sur un registre local : la vérification réussit avec la clé publique et échoue sur une image non signée (« no signatures found »). La leçon Signer et vérifier avec Cosign va plus loin, signature sans clé comprise.

Pilier 2 : comment rendre un système fiable ?

La question n'est pas si une panne arrivera, mais quand. Les systèmes fiables ne sont pas ceux qui ne tombent jamais, mais ceux qui résistent aux pannes et se rétablissent vite. Deux principes les fondent : l'immutabilité (on remplace un système plutôt que de le modifier en production) et la redondance (une panne locale n'atteint pas le service).

Les pratiques essentielles

Ces pratiques réduisent la probabilité et l'impact d'une panne. L'infrastructure as code garantit la reproductibilité, la redondance absorbe les défaillances locales, et le chaos engineering vérifie que ces filets fonctionnent avant qu'un incident réel ne le fasse à votre place.

Pratique	Action concrète
Infrastructure as Code	Toute l'infrastructure versionnée (Terraform, OpenTofu, Ansible)
Immutabilité	Aucune modification manuelle en production : on redéploie
Redondance	Plusieurs zones de disponibilité pour les services critiques
Disjoncteurs	Isoler les défaillances pour éviter les cascades
Chaos engineering	Tests de résilience réguliers (Chaos Mesh, LitmusChaos)
Capacité	Projections de charge et tests de performance

Glissez pour voir

L'error budget : arbitrer entre vélocité et stabilité

L'error budget est un concept SRE qui transforme la fiabilité en décision. Plutôt que de viser 100 % de disponibilité, impossible et coûteux, on fixe un SLO et on accepte l'écart restant comme budget. La leçon SLO, SLI et error budgets détaille les calculs et les alertes par burn rate.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

1. Définir les SLI (Service Level Indicators)

   Ce que l'on mesure, du point de vue de l'utilisateur : part des requêtes réussies, part des requêtes servies sous 200 ms.

2. Fixer les SLO (Service Level Objectives)

   L'objectif interne sur une fenêtre glissante : par exemple 99,9 % de requêtes réussies sur 30 jours.

3. Calculer l'error budget

   Error budget = 100 % - SLO. Avec un SLO de 99,9 %, le budget vaut 0,1 %, soit environ 43 minutes d'indisponibilité sur 30 jours, ou 8 h 45 sur un an.

4. Appliquer une politique

   Un exemple de politique, à négocier avec le produit : au-delà de 50 % de budget restant, on livre et on expérimente ; entre 20 et 50 %, on livre en renforçant la fiabilité ; sous 20 %, on suspend les nouvelles fonctionnalités ; budget épuisé, gel et revue d'incident.

Pilier 3 : comment rendre un système exploitable ?

On ne répare pas ce que l'on ne voit pas. L'observabilité instrumente le système pour comprendre son comportement en production, à partir de trois signaux : les métriques (que se passe-t-il ?), les journaux (qu'est-ce qui s'est passé ?) et les traces (par où passe une requête ?). La leçon observabilité approfondit ces signaux.

Les pratiques essentielles

Ces pratiques transforment une supposition en certitude au moment de l'incident. Commencez par les tableaux de bord et les alertes, puis formalisez runbooks et post-mortems une fois les premiers incidents traités.

Pratique	Action concrète
Trois signaux corrélés	Métriques, journaux et traces reliés par un identifiant de trace
Tableaux de bord utiles	Indicateurs qui servent une décision, pas de « vanity metrics »
Alertes sur les SLO	Seuils dérivés des SLO, pas de valeurs arbitraires
Runbooks	Une procédure documentée pour chaque alerte critique
Post-mortems	Analyse blameless après chaque incident majeur
Astreinte	Rotation soutenable, équipes formées et outillées

Glissez pour voir

L'astreinte doit rester soutenable pour ne pas épuiser les équipes, et le post-mortem transforme un incident en apprentissage collectif plutôt qu'en recherche de coupable.

OpenTelemetry : instrumenter une fois, router partout

OpenTelemetry (OTel) est le standard d'instrumentation : la CNCF l'a fait graduer le 21 mai 2026, son plus haut niveau de maturité. Traces, métriques et journaux sont stables ; un quatrième signal, le profiling, est en alpha publique depuis mars 2026 et n'est pas encore destiné à la production. On instrumente une fois, et le collecteur reçoit, transforme et route les données vers le backend de son choix.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Instrumentation Python

Côté application, le SDK crée les spans et les exporte en OTLP vers le collecteur. Le nom du service, porté par la ressource, identifie les traces dans le backend. Testé avec le SDK Python 1.45 contre un collecteur 0.161 : la trace arrive avec son attribut.

from opentelemetry import trace
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

# Le nom du service identifie les traces dans le backend.
provider = TracerProvider(resource=Resource.create({"service.name": "commandes"}))
# Schéma http:// : connexion gRPC sans TLS, acceptable sur un réseau interne.
provider.add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter(endpoint="http://otel-collector:4317"))
)
trace.set_tracer_provider(provider)

tracer = trace.get_tracer(__name__)


def traiter_commande(commande_id: str) -> None:
    with tracer.start_as_current_span("traiter_commande") as span:
        span.set_attribute("commande.id", commande_id)
        # ... traitement métier

Configuration du collecteur

Les exporteurs dédiés jaeger et loki ont disparu de la distribution contrib : Jaeger et Loki acceptent désormais OTLP nativement. Une ancienne configuration qui les nomme est refusée par otelcol-contrib validate (« unknown type: "jaeger" ») ; celle-ci est acceptée par le collecteur 0.161.0. Le processeur memory_limiter vient en premier pour protéger le collecteur sous charge.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 1000
  batch:
    timeout: 1s
    send_batch_size: 1024

exporters:
  otlp/jaeger:
    endpoint: jaeger:4317
    tls:
      insecure: true
  prometheus:
    endpoint: 0.0.0.0:8889
  otlphttp/loki:
    endpoint: http://loki:3100/otlp

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp/jaeger]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [prometheus]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlphttp/loki]

Pilier 4 : comment garder un système maintenable ?

Un système est modifié bien plus souvent qu'il n'est écrit. La maintenabilité facilite ces modifications : un README qui explique comment lancer le projet, des ADR (Architecture Decision Records) qui gardent la trace des choix, des tests qui servent de spécification vivante. C'est la différence entre un projet qu'on fait évoluer sereinement et un projet qu'on a peur de toucher.

Les pratiques essentielles

Ces pratiques évitent qu'un système devienne une boîte noire que plus personne n'ose modifier. Elles demandent une discipline continue : documentation et tests se dégradent vite si personne n'y consacre de temps régulier.

Pratique	Action concrète
Documentation à jour	README, ADR, schémas, dans le dépôt
Sauvegardes testées	Restauration réellement exécutée chaque mois
Plan de reprise	Exercé au moins une fois par an avec les équipes
Versionnage sémantique	Contrats d'API clairs, ruptures documentées
Refactoring continu	Temps réservé à la réduction de la dette
Tests automatisés	Couverture suffisante pour refactorer sans crainte

Glissez pour voir

Les tests automatisés méritent un investissement particulier : sans ce filet, un système se fige par peur de la régression. La leçon stratégies de tests aide à prioriser entre tests unitaires, d'intégration et de bout en bout.

Comment standardiser sans contraindre avec les Golden Paths ?

Les Golden Paths sont des chemins balisés qui appliquent les quatre piliers par défaut : un développeur qui les suit livre vite tout en respectant les pratiques de l'organisation. C'est le cœur du Platform Engineering, qui construit une plateforme interne en libre-service.

Selon le rapport DORA 2025, 90 % des organisations utilisent déjà une plateforme interne et 76 % ont une équipe plateforme dédiée. Un Golden Path reste une recommandation, pas une obligation : les équipes peuvent dévier pour une bonne raison, mais le chemin par défaut doit être le plus facile à suivre. Il se construit en quatre briques, de la moins coûteuse à la plus exigeante.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

1. Un modèle de projet

   Structure de dépôt, Dockerfile, pipeline CI/CD et configuration de base prêts à l'emploi. Dans Backstage, c'est un Software Template que le développeur instancie depuis le portail ; il crée par exemple src/, Dockerfile, .gitlab-ci.yml, les manifestes Kubernetes, un dossier docs/adr/ et le README.

2. Un portail en libre-service

   Une interface pour créer des ressources sans ticket : Backstage en open source, Port ou Humanitec en produits gérés.

3. Une documentation intégrée

   Les guides vivent dans le flux de travail et dans le dépôt, pas sur un wiki séparé : c'est l'approche Docs-as-Code.

4. Des garde-fous automatiques

   Des politiques d'admission qui préviennent les erreurs au moment du déploiement, comme cette ValidatingPolicy Kyverno qui exige un label team.

La politique ci-dessous a été testée avec la CLI Kyverno 1.19.1 : un Deployment qui porte le label team est admis, un Deployment sans ce label est refusé avec le message prévu.

apiVersion: policies.kyverno.io/v1
kind: ValidatingPolicy
metadata:
  name: require-labels
spec:
  validationActions: [Deny]
  matchConstraints:
    resourceRules:
      - apiGroups: ["apps"]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["deployments"]
  validations:
    - expression: >-
        has(object.metadata.labels) &&
        'team' in object.metadata.labels &&
        size(object.metadata.labels['team']) > 0
      message: "Le label 'team' est obligatoire sur tous les Deployments."

Deux scénarios concrets

Ces deux scénarios comparent, sur des cas fréquents, ce qui se passe avec et sans les pratiques décrites. Ils montrent l'écart entre une équipe qui a formalisé ses réflexes et une équipe qui découvre le problème au moment où il survient.

Scénario 1 : une clé d'API commitée par erreur

Un développeur commite par erreur une clé d'API dans le code source. Sans bonnes pratiques, la clé reste dans l'historique Git et un audit la découvre six mois plus tard : rotation de tous les accès, analyse forensique, communication de crise. Avec, le hook pre-commit (Gitleaks, detect-secrets) bloque le commit ; s'il passe malgré tout, le scan CI échoue, la clé est révoquée et remplacée depuis le gestionnaire de secrets, et l'incident est documenté.

Scénario 2 : un incident un vendredi soir

L'application renvoie des erreurs 500 et l'ingénieur d'astreinte est alerté. Sans bonnes pratiques, il passe des heures dans des journaux non structurés, sans runbook, avant un retour arrière manuel hasardeux. Avec, l'alerte pointe vers le runbook, le tableau de bord montre la corrélation avec le déploiement de 17 h, le retour arrière se déclenche en un geste et le service revient en quelques minutes ; le post-mortem est planifié pour lundi.

Quels pièges éviter ?

Ce tableau récapitule les erreurs les plus fréquentes, souvent héritées d'une culture où la vélocité prime sur tout. Les repérer tôt évite des mois de rattrapage ; la colonne de droite donne la correction de chacune.

Piège	Pourquoi c'est un problème	Correction
Sécurité en fin de cycle	Correctifs coûteux, retards de livraison	Analyser dès le commit
Trop d'alertes	Fatigue d'alerte, alertes ignorées	Seuils dérivés des SLO, suppression du bruit
Sauvegardes non testées	Restauration impossible le jour J	Restauration mensuelle réelle
Documentation obsolète	Confiance perdue, erreurs de procédure	Docs dans le dépôt, revue à chaque merge request
Environnements manuels	Divergences, « ça marche sur ma machine »	Tout en IaC, environnements éphémères
Moindre privilège ignoré	Surface d'attaque étendue	Revue trimestrielle des permissions
Post-mortems punitifs	Dissimulation des erreurs	Culture blameless, attention portée au système
Dette technique accumulée	Vélocité en chute libre	Temps réservé à chaque itération

Glissez pour voir

Comment savoir si vos pratiques sont matures ?

Cette grille se repasse chaque trimestre plutôt qu'une seule fois. Elle s'appuie notamment sur les indicateurs DORA, qui comptent cinq métriques depuis 2024 : délai des changements, fréquence de déploiement, temps de restauration après un déploiement raté, taux d'échec et taux de reprise (rework). Le suivi des KPI de sécurité complète la mesure.

• Aucun secret en clair dans les dépôts ni dans les pipelines
• Les images sont analysées et la gestion des vulnérabilités bloque les failles critiques avant déploiement
• Un SBOM est généré automatiquement pour chaque release
• Toute l'infrastructure est versionnée et reproductible
• Les SLO sont définis et l'error budget est suivi
• Chaque alerte critique renvoie à un runbook
• Les restaurations de sauvegarde sont testées au moins chaque trimestre
• Un post-mortem blameless suit chaque incident majeur
• Les équipes déploient de façon autonome, sans intervention manuelle
• Les cinq indicateurs DORA sont mesurés et suivis dans le temps

À retenir

• La sécurité s'intègre dès le premier commit : SBOM, signature par digest et build évalué sur l'échelle SLSA (L0 à L3).
• L'OWASP Top 10:2025 place les défaillances de la chaîne d'approvisionnement au troisième rang des risques applicatifs.
• La fiabilité se pilote avec des SLO et un error budget, pas avec une promesse de 100 % de disponibilité.
• L'exploitabilité repose sur OpenTelemetry, gradué CNCF en mai 2026, et sur des runbooks actionnables.
• La maintenabilité exige documentation dans le dépôt, tests et sauvegardes réellement restaurées.
• Les Golden Paths appliquent ces pratiques par défaut, sans les imposer.
• Un exemple qui a marché il y a deux ans peut ne plus marcher : exporteurs OpenTelemetry retirés, sous-commandes dépréciées, épinglage par SHA incompatible avec le générateur SLSA. Rejouez vos exemples avec les versions actuelles.

Contrôle de connaissances

Vérifiez que vous avez retenu l'essentiel de ce guide. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

FAQ : questions fréquentes

Les questions ci-dessous reprennent les doutes les plus fréquents sur les bonnes pratiques DevSecOps : SBOM et SLSA, l'error budget, les Golden Paths et OpenTelemetry.

Quelles sont les bonnes pratiques DevSecOps ?

Quelle est la différence entre SBOM et SLSA ?

Qu'est-ce qu'un Error Budget en DevSecOps ?

Qu'est-ce qu'un Golden Path en Platform Engineering ?

Pourquoi utiliser OpenTelemetry pour l'observabilité ?

Comment éviter les incidents de sécurité en production ?

×

📖 Voir la documentation →