Bonnes pratiques DevSecOps : les 4 piliers à maîtriser

Parcours Implémentation, Partie 1 : Évaluer

Chapitre 1.2, Les 4 piliers d'un système de qualité DevSecOps.

Étape précédente : 1.1 Audit de maturité Prochaine étape : 2.1 Team Topologies

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

Cette page rassemble les bonnes pratiques DevSecOps éprouvées en 2026 : 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 via les Golden Paths. Elle s'adresse aux équipes qui ont déjà des outils en place mais cherchent une méthode pour les faire converger. Chaque recommandation est actionnable et issue de retours terrain, sans prétendre qu'il faut tout appliquer d'un coup.

Ce que vous allez apprendre

• Structurer vos pratiques autour des quatre piliers : sécurité, fiabilité, exploitabilité, maintenabilité
• Générer et vérifier un SBOM, puis situer votre chaîne de build sur l'échelle SLSA
• Définir des SLI, des SLO et un Error Budget pour arbitrer entre vélocité et stabilité
• Instrumenter vos systèmes avec OpenTelemetry pour diagnostiquer un incident en quelques minutes
• 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, backups non testés)

Prérequis

Avant d'appliquer ces bonnes pratiques, maîtrisez les fondamentaux :

Fondamentaux DevSecOps Principes de sécurité intégrée au cycle de développement

Fondamentaux DevOps Culture, collaboration, automatisation

Infrastructure as Code Provisionnement automatisé et reproductible

Les 4 piliers des bonnes pratiques DevSecOps

Les bonnes pratiques DevSecOps s'organisent autour de quatre piliers complémentaires. Chacun répond à une question fondamentale que tout système en production doit se poser. Négliger l'un de ces piliers crée tôt ou tard des problèmes : une application peut être sécurisée mais impossible à déboguer, ou fiable mais impossible à maintenir.

Pilier	Objectif	Question clé
Sécurité	Protéger les données et 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 identifier la cause d'un incident en 5 minutes ?
Maintenabilité	Faire évoluer et corriger facilement	Comment modifier ce système dans 6 mois ?

Glissez pour voir

Le problème terrain

Pourquoi formaliser des bonnes pratiques ? Parce que 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 largement les anti-patterns DevOps documentés plus largement : les reconnaître tôt évite d'y consacrer des mois de rattrapage.

Symptômes d'alerte

• Sécurité en afterthought : vulnérabilités découvertes en production, correctifs urgents
• Dette technique croissante : code non documenté, configurations dupliquées, scripts ad hoc
• Incidents récurrents : mêmes erreurs qui se répètent faute de capitalisation
• Environnements divergents : « ça marche sur ma machine » mais pas en production
• Restaurations non testées : sauvegardes inutilisables le jour J
• Monitoring inexistant ou inexploitable : alertes ignorées, dashboards abandonnés

Pilier 1 : Sécurité

La sécurité coûte moins cher quand elle est intégrée tôt. Une vulnérabilité détectée au moment du commit se corrige en quelques minutes. La même vulnérabilité découverte en production peut nécessiter des jours de travail, sans compter les impacts potentiels.

Le principe du shift-left sécurité consiste à déplacer les contrôles de sécurité le plus tôt possible dans le cycle de développement. Concrètement, cela signifie scanner les dépendances avant de merger une pull request, vérifier les secrets avant le commit, et bloquer les images vulnérables avant qu'elles n'atteignent la production. Avant même d'écrire le code, un exercice de threat modeling avec la méthode STRIDE aide à prioriser les scénarios d'attaque les plus probables sur une architecture donnée.

Pour prioriser vos contrôles, appuyez-vous sur une référence à jour : l'OWASP Top 10:2025, dont la version finale est parue en janvier 2026, place le contrôle d'accès défaillant en tête (A01), suivi de la mauvaise configuration (A02) puis, nouveauté marquante, des échecs de la chaîne d'approvisionnement logicielle (A03), qui remplace et élargit l'ancienne catégorie « composants vulnérables ». Notre page dédiée à l'OWASP Top 10 appliqué au DevSecOps traduit ces dix risques en contrôles CI/CD concrets.

Pratiques essentielles

Ces pratiques forment le socle minimal à mettre en place avant d'aller plus loin. Elles sont classées par ordre de facilité de mise en œuvre : les trois premières lignes se déploient en général en quelques jours, les suivantes demandent un peu plus d'organisation et l'adhésion de plusieurs équipes.

Pratique	Action concrète
Shift-left security	Scanner les dépendances dans la CI (Trivy, Snyk, Grype)
Secrets management	Jamais de secrets en clair ; utiliser Vault, SOPS, ou Sealed Secrets
Moindre privilège	Comptes de service avec permissions minimales, révision trimestrielle
Scan d'images	Bloquer les images avec CVE critiques non corrigées
SAST/DAST	Analyse statique et dynamique intégrée au pipeline
Revue de code sécurité	Checklist sécurité dans les pull requests

Glissez pour voir

Supply Chain Security : SBOM et SLSA

La sécurité de la chaîne d'approvisionnement logicielle est devenue critique après les attaques SolarWinds et Log4Shell. Ces incidents ont révélé une vérité inconfortable : vous pouvez avoir le code le plus sécurisé du monde, si une de vos dépendances est compromise, votre application l'est aussi. Notre page consacrée à la sécurité de la supply chain logicielle détaille les attaques et contre-mesures ; voici l'essentiel à appliquer immédiatement.

Deux standards complémentaires émergent pour sécuriser la supply chain. Le SBOM répond à la question « de quoi est composé mon logiciel ? ». SLSA répond à « puis-je faire confiance à la manière dont il a été construit ? ».

SBOM

Le Software Bill of Materials (SBOM) est un inventaire complet des composants d'un logiciel :

• Quoi : Liste de toutes les dépendances (directes et transitives)
• Pourquoi : Traçabilité des CVE, conformité licences, audit sécurité
• Formats : SPDX (Linux Foundation), CycloneDX (OWASP)
• Outils : Syft, Trivy, Grype pour générer et scanner

# Générer un SBOM avec Syft
syft packages alpine:latest -o spdx-json > sbom.spdx.json

# Scanner le SBOM avec Grype
grype sbom:sbom.spdx.json

SLSA

SLSA (Supply-chain Levels for Software Artifacts) a abandonné en 2023 son ancien barème à quatre niveaux (v0.1) pour un modèle plus simple, cumulatif, allant du niveau 0 au niveau 3 (spécification v1.0, révisée en v1.2) :

Niveau	Exigences	Protège contre
Level 0	Aucune garantie : build local, sans provenance	Absence totale de traçabilité
Level 1	Provenance générée, même auto-attestée par le développeur	Erreurs de build non documentées
Level 2	Build sur un service hébergé qui génère et signe la provenance	Falsification a posteriori de la provenance
Level 3	Build isolé, provenance infalsifiable même par un script compromis	Compromission du pipeline de build lui-même

Glissez pour voir

# Exemple attestation SLSA dans GitHub Actions
- uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v2
  with:
    base64-subjects: "${{ needs.build.outputs.digest }}"

Outils

Ces outils se combinent en une chaîne de confiance : Syft documente ce qui compose l'image, Grype scanne les vulnérabilités connues, Cosign signe le résultat, et Sigstore fournit l'infrastructure de clés publiques qui rend cette signature vérifiable sans gérer soi-même des certificats.

Outil	Usage
Cosign	Signature et vérification d'images OCI
Syft	Génération de SBOM
Grype	Scan de vulnérabilités
in-toto	Attestations de provenance
Sigstore	PKI publique pour la signature

Glissez pour voir

# Signer une image avec Cosign
cosign sign --key cosign.key myregistry/myimage:v1.0.0

# Vérifier la signature
cosign verify --key cosign.pub myregistry/myimage:v1.0.0

Pilier 2 : Fiabilité

La question n'est pas si une panne arrivera, mais quand. Un serveur tombera, un disque se corrompra, un datacenter subira une coupure. Les systèmes fiables ne sont pas ceux qui ne tombent jamais, mais ceux qui résistent aux pannes et se rétablissent rapidement.

La fiabilité repose sur deux principes fondamentaux : l'immutabilité et la redondance. L'immutabilité signifie qu'on ne modifie jamais un système en production, on le remplace par une nouvelle version. La redondance garantit qu'une panne d'un composant n'impacte pas le service global.

Pratiques essentielles

Ces pratiques réduisent la probabilité et l'impact d'une panne. Elles se combinent entre elles : l'infrastructure as code garantit la reproductibilité, la redondance absorbe les défaillances locales, et le chaos engineering valide que ces filets de sécurité fonctionnent réellement avant qu'un incident réel ne le fasse à votre place.

Pratique	Action concrète
Infrastructure as Code	100 % de l'infra versionnée (Terraform, Pulumi, Ansible)
Immutabilité	Pas de modification manuelle en production ; redéployer
Redondance	Multi-AZ ou multi-région pour les services critiques
Circuit breakers	Isoler les défaillances pour éviter les cascades
Chaos engineering	Tests de résilience réguliers (Chaos Monkey, Litmus)
Capacity planning	Projections de charge et tests de performance

Glissez pour voir

Error Budgets : équilibrer vélocité et stabilité

L'Error Budget est un concept SRE qui transforme la fiabilité en décision business. Au lieu de viser 100 % de disponibilité (impossible et coûteux), on définit un budget d'erreur acceptable. La page dédiée aux SLO, SLI et Error Budgets détaille les formules de calcul et les politiques de burn rate ; voici le principe et l'essentiel pour démarrer.

L'idée est simple : si votre SLO est de 99,9 % de disponibilité, vous « autorisez » 0,1 % d'indisponibilité. Ce budget peut être « dépensé » pour livrer des features (qui comportent toujours un risque) ou « économisé » pour absorber les incidents imprévus. Quand le budget est épuisé, l'équipe se concentre exclusivement sur la stabilité.

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

   Métriques mesurables : latence p99, taux d'erreur, throughput.

   # Exemple SLI
   sli:
     latency_p99: "temps de réponse 99e percentile < 200ms"
     error_rate: "taux d'erreurs HTTP 5xx"
     availability: "succès des health checks"

2. Fixer les SLO (Service Level Objectives)

   Objectifs internes basés sur les SLI.

   # Exemple SLO
   slo:
     availability: 99.9%  # 8h45 de downtime autorisé par an
     latency_p99: 200ms
     error_rate: < 0.1%

3. Calculer l'Error Budget

   Error Budget = 100% - SLO
   
   Avec SLO = 99.9% → Error Budget = 0.1%
   Sur 30 jours = 43 minutes de downtime autorisées

4. Appliquer la politique Error Budget

   Budget restant	Action
   > 50%	Nouvelles features, expérimentations
   20-50%	Features + travail sur la fiabilité
   < 20%	Stop features, focus stabilité
   Épuisé	Gel complet, incident review

   Glissez pour voir

Pilier 3 : Exploitabilité

Vous ne pouvez pas réparer ce que vous ne voyez pas. L'observabilité consiste à instrumenter vos systèmes pour comprendre leur comportement en production. Sans elle, chaque incident devient une enquête à l'aveugle. Notre page sur l'observabilité : logs, métriques et traces approfondit ces trois signaux.

L'observabilité moderne repose sur trois piliers complémentaires : les métriques (que se passe-t-il en ce moment ?), les logs (qu'est-ce qui s'est passé ?), et les traces (comment les requêtes traversent-elles le système ?). La corrélation entre ces trois sources permet de diagnostiquer rapidement les problèmes les plus complexes.

Pratiques essentielles

Ces pratiques transforment une supposition en certitude au moment où un incident survient. Elles se construisent progressivement : commencez par les dashboards et les alertes, puis formalisez les runbooks et la culture post-mortem une fois les premiers incidents traités.

Pratique	Action concrète
Observabilité 3 piliers	Métriques + Logs + Traces corrélés
Dashboards actionnables	Indicateurs clés visibles, pas de « vanity metrics »
Alertes pertinentes	Seuils basés sur SLO, pas sur des valeurs arbitraires
Runbooks	Procédures documentées pour chaque alerte critique
Post-mortems	Analyse blameless après chaque incident majeur
On-call rotation	Équipes formées et outillées pour l'astreinte

Glissez pour voir

Deux de ces pratiques méritent une attention particulière. La rotation d'astreinte doit rester soutenable pour ne pas épuiser les équipes : notre guide sur l'on-call et les astreintes détaille comment l'organiser. Le post-mortem transforme un incident en apprentissage collectif plutôt qu'en recherche de coupable : la page incidents et post-mortems explique comment le conduire.

OpenTelemetry : observabilité standardisée

OpenTelemetry (OTel) est le standard de facto pour l'instrumentation. En mai 2026, la CNCF (Cloud Native Computing Foundation) a officiellement fait graduer le projet, consacrant son adoption massive : les trois signaux historiques, métriques, logs et traces, sont désormais stables sur tous les SDK majeurs (Python, Java, Go, JavaScript...). Un quatrième signal, le profiling continu, est en release candidate et vise la disponibilité générale d'ici la fin 2026.

L'avantage principal d'OpenTelemetry est sa portabilité : vous instrumentez une fois votre code, et vous pouvez envoyer les données vers n'importe quel backend (Jaeger, Zipkin, Datadog, New Relic...). Le Collector agit comme un point central qui reçoit, transforme et route les données vers les destinations appropriées.

Architecture

Implémentation

# Python avec OpenTelemetry
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

# Configuration
provider = TracerProvider()
processor = BatchSpanProcessor(OTLPSpanExporter(endpoint="otel-collector:4317"))
provider.add_span_processor(processor)
trace.set_tracer_provider(provider)

# Utilisation
tracer = trace.get_tracer(__name__)
with tracer.start_as_current_span("process_request") as span:
    span.set_attribute("user.id", user_id)
    # ... traitement

Collector config

otel-collector-config.yaml

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

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

exporters:
  prometheus:
    endpoint: "0.0.0.0:8889"
  jaeger:
    endpoint: jaeger:14250
    tls:
      insecure: true
  loki:
    endpoint: http://loki:3100/loki/api/v1/push

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

Pilier 4 : Maintenabilité

Un système sera modifié bien plus souvent qu'il ne sera écrit. La maintenabilité consiste à faciliter ces modifications futures : documentation à jour, tests qui permettent de refactorer sereinement, sauvegardes qui fonctionnent vraiment.

La maintenabilité se joue souvent dans les détails : un README clair qui explique comment lancer le projet, des ADR (Architecture Decision Records) qui documentent les choix techniques, des tests qui servent de spécification vivante. C'est ce qui fait la différence entre un projet qu'on peut faire évoluer sereinement et un projet qu'on a peur de toucher.

Pratiques essentielles

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

Pratique	Action concrète
Documentation à jour	README, ADR, diagrammes
Sauvegardes testées	Restauration validée mensuellement
Plan de reprise (PRA/PCA)	Testé annuellement avec les équipes
Versioning sémantique	Contrats d'API clairs, breaking changes documentés
Refactoring continu	Budget temps dédié à la réduction de dette
Tests automatisés	Couverture suffisante pour refactorer sereinement

Glissez pour voir

Les tests automatisés méritent un investissement spécifique : ils sont ce qui permet de refactorer sans crainte, alors qu'un système sans filet de sécurité se fige progressivement par peur de la régression. Notre page sur les stratégies de tests détaille comment prioriser entre tests unitaires, d'intégration et de bout en bout.

Golden Paths : standardiser sans contraindre

Les Golden Paths sont des chemins balisés qui permettent aux développeurs de livrer rapidement tout en respectant les bonnes pratiques de l'organisation. C'est le concept central du Platform Engineering, la discipline qui consiste à construire une plateforme interne en libre-service pour les équipes produit.

L'idée est de réduire la charge cognitive des développeurs : au lieu de devoir choisir parmi des dizaines d'options pour chaque aspect technique (framework, CI/CD, monitoring...), ils suivent un chemin pré-validé. Ce n'est pas une contrainte rigide, c'est un raccourci vers les bonnes pratiques. Les équipes expérimentées peuvent toujours dévier si nécessaire.

Cette approche s'est banalisée en quelques années : d'après le rapport DORA 2025, 90 % des organisations utilisent déjà une plateforme interne en libre-service (Internal Developer Platform) et 76 % ont constitué une équipe plateforme dédiée. Le cabinet Gartner anticipe que 80 % des grandes organisations disposeront de leur propre équipe de Platform Engineering d'ici la fin de l'année 2026.

Principe clé

Un Golden Path est une recommandation, pas une obligation. Les équipes peuvent dévier si elles ont une bonne raison, mais le chemin par défaut doit être le plus facile à suivre.

Composants d'un Golden Path

Un Golden Path se construit à partir de quatre briques concrètes, à introduire progressivement plutôt que toutes en même temps. L'ordre ci-dessous correspond à une charge de mise en œuvre croissante : commencez par le template de projet, qui apporte l'essentiel de la valeur pour un coût minimal.

1. Template de projet

   Structure de repo, Dockerfile, CI/CD, configs de base pré-configurés.

   # Exemple avec Backstage
   backstage-cli create --template=microservice-template
   
   # Génère automatiquement :
   # ├── src/
   # ├── Dockerfile
   # ├── .gitlab-ci.yml
   # ├── kubernetes/
   # │   ├── deployment.yaml
   # │   └── service.yaml
   # ├── docs/
   # │   └── ADR/
   # └── README.md

2. Self-service portal

   Interface pour créer des ressources sans tickets.

   Outil	Type	Points forts
   Backstage	IDP open-source	Templates, catalog, plugins
   Port	SaaS	Rapide à déployer, scorecards
   Humanitec	SaaS	Focus déploiement

   Glissez pour voir

3. Documentation intégrée

   Guides dans le flux de travail, pas sur un wiki séparé. Voir Docs-as-Code.

4. Guardrails automatiques

   Policies qui préviennent les erreurs sans bloquer.

   # Kyverno ValidatingPolicy : politique de guardrails
   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."

Scénarios concrets

Les deux scénarios suivants comparent, sur des cas fréquents, ce qui se passe avec et sans les pratiques décrites plus haut. Ils rendent concret 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 : Fuite de secrets dans un commit

Contexte : Un développeur commit accidentellement une clé API dans le code source.

Sans bonnes pratiques

La clé reste dans l'historique Git. Elle est découverte 6 mois plus tard par un audit externe. Coût : rotation de tous les accès, analyse forensique, communication de crise.

Avec bonnes pratiques

1. Le hook pre-commit (git-secrets, detect-secrets) bloque le commit
2. Si le commit passe, le scan CI (Gitleaks, TruffleHog) échoue
3. La clé est révoquée immédiatement via Vault
4. Nouvelle clé générée et injectée automatiquement
5. L'incident est documenté, le processus amélioré

Scénario 2 : Incident production un vendredi soir

Contexte : L'application principale renvoie des erreurs 500. L'ingénieur d'astreinte est alerté.

Sans bonnes pratiques

4 heures de diagnostic dans les logs non structurés. Pas de runbook. Rollback manuel hasardeux. Weekend ruiné.

Avec bonnes pratiques

1. L'alerte contient un lien vers le runbook correspondant
2. Le dashboard montre la corrélation entre le déploiement de 17h et les erreurs
3. Le rollback automatique est déclenché en 2 clics
4. Le service est restauré en 15 minutes
5. Post-mortem planifié pour lundi

Pièges courants

Ce tableau récapitule les erreurs les plus fréquentes observées sur le terrain, souvent héritées d'une culture où la vélocité prime sur tout le reste. Beaucoup recoupent les anti-patterns DevOps documentés plus largement : les repérer tôt évite d'y consacrer ensuite des mois de rattrapage.

Piège	Pourquoi c'est un problème	Correction
Sécurité en fin de cycle	Correctifs coûteux, retards de livraison	Shift-left : scanner dès le commit
Trop d'alertes	Alert fatigue, alertes ignorées	Seuils basés sur SLO, suppression du bruit
Backups non testés	Restauration impossible le jour J	Test de restauration mensuel
Documentation obsolète	Confiance perdue, erreurs de procédure	Docs dans le repo, revue à chaque PR
Environnements manuels	Divergences, « works on my machine »	Tout en IaC, environnements éphémères
Moindre privilège ignoré	Surface d'attaque étendue	Audit trimestriel des permissions
Post-mortems punitifs	Dissimulation des erreurs	Culture blameless, focus sur le système
Dette technique accumulée	Vélocité en chute libre	Budget dédié (20 % du sprint)

Glissez pour voir

Critères de réussite

Comment savoir si vos pratiques sont matures ? Cette grille d'évaluation objective est à passer en revue tous les trimestres plutôt qu'une seule fois. Elle s'appuie notamment sur les métriques DORA, qui ont évolué en 2025 : aux quatre indicateurs historiques (fréquence de déploiement, délai de mise en production, temps de restauration) s'ajoute désormais le taux de rework, la part des déploiements non planifiés liés à un correctif d'urgence. Pour aller plus loin, notre guide d'implémentation des métriques DORA et le suivi des KPIs sécurité détaillent comment les instrumenter.

• Aucun secret en clair dans les repos ou les pipelines
• Les images Docker sont scannées et la gestion des vulnérabilités CVE bloque les failles critiques avant déploiement
• SBOM généré automatiquement pour chaque release
• 100 % de l'infrastructure est versionnée et reproductible
• Les SLO sont définis et l'Error Budget est suivi
• Les alertes déclenchent des actions documentées (runbooks)
• Les restaurations de backup sont testées au moins une fois par trimestre
• Un post-mortem blameless est rédigé après chaque incident majeur
• Les équipes peuvent déployer de manière autonome sans intervention manuelle
• Les métriques DORA (déploiement, lead time, restauration, échec, rework) sont mesurées et suivies dans le temps

À retenir

• La sécurité s'intègre dès le premier commit avec SBOM et une chaîne de build évaluée sur l'échelle SLSA (niveaux 0 à 3)
• L'OWASP Top 10:2025 consacre les échecs de supply chain comme troisième risque applicatif mondial
• La fiabilité se pilote avec des SLO et Error Budgets, pas avec une promesse de disponibilité à 100 %
• L'exploitabilité repose sur OpenTelemetry, désormais gradué CNCF, et des runbooks actionnables
• La maintenabilité nécessite documentation, tests et sauvegardes validées
• Les Golden Paths standardisent sans contraindre : 90 % des organisations utilisent déjà une plateforme interne en libre-service
• Ces pratiques se renforcent mutuellement : commencez par celles qui traitent vos incidents récurrents

FAQ : questions fréquentes

Quelles sont les bonnes pratiques DevSecOps ?

Les bonnes pratiques DevSecOps s'organisent autour de quatre piliers : sécurité (SBOM, SLSA, shift-left), fiabilité (SLO, Error Budget), exploitabilité (observabilité avec OpenTelemetry) et maintenabilité (documentation, tests, sauvegardes testées).

Quelle est la différence entre SBOM et SLSA ?

Le SBOM est un inventaire des composants d'un logiciel : il répond à « de quoi est-il composé ? ». SLSA évalue la fiabilité de la chaîne de build sur une échelle de niveaux 0 à 3 : il répond à « peut-on faire confiance à sa construction ? ».

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

Un Error Budget est un concept SRE qui transforme la fiabilité en décision business : au lieu de viser 100 % de disponibilité, on définit un budget d'erreur acceptable à partir du SLO. Un SLO de 99,9 % autorise 43 minutes de downtime sur 30 jours.

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

Un Golden Path est un chemin balisé et pré-validé (template de projet, self-service portal, documentation intégrée, guardrails automatiques) qui permet aux développeurs de livrer rapidement tout en respectant les bonnes pratiques de l'organisation. C'est une recommandation, pas une obligation.

Pourquoi utiliser OpenTelemetry pour l'observabilité ?

OpenTelemetry est le standard de facto pour instrumenter un système une seule fois et envoyer les données vers n'importe quel backend (Jaeger, Prometheus, Loki). Il unifie métriques, logs et traces, stables depuis la graduation CNCF de mai 2026.

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

En appliquant le shift-left sécurité : scanner les dépendances avant chaque pull request, vérifier les secrets avant le commit et bloquer les images vulnérables avant la production. Une vulnérabilité corrigée au commit prend quelques minutes.

Liens utiles

Indicateurs DORA Mesurer l'efficacité de vos pratiques

Observabilité Métriques, logs, traces avec OpenTelemetry

Gestion de configuration Ansible et outils associés

Pipelines CI/CD Automatiser les déploiements sécurisés

Documentation technique Runbooks, ADR, Service Overviews et bonnes pratiques

×

📖 Voir la documentation →