Comment j’ai découvert le DevSecOps, pour de vrai

Pendant longtemps, pour moi, le DevSecOps était surtout un mot. Je savais le définir : intégrer la sécurité dans toute la chaîne de livraison, plutôt que de la vérifier à la fin. Je connaissais les noms des outils. Mais je ne l’avais jamais vraiment vécu.

C’est l’année 2025–2026 à l’ENSIBS qui a changé ça, avec le projet Escolis.

#Le point de départ : une application qui ne tournait qu’en local

Escolis est un système d’information scolaire en micro-services : chaque fonctionnalité métier (gestion des alternances, calendriers, e-mails et support…) est un service indépendant, développé et versionné séparément, puis assemblé avec les autres. Notre promotion l’avait conçu lors d’un projet précédent. Il marchait, mais uniquement sur nos machines.

Notre mission n’était pas d’ajouter des fonctionnalités. C’était de l’industrialiser : construire une vraie chaîne CI/CD, avec la sécurité et la résilience intégrées, et livrer une version finale, ICE-2026-v1.0.0, en production, sans interruption de service.

Dit comme ça, ça paraît simple. En pratique, c’est là que j’ai compris que « ça marche sur ma machine » est le tout début du travail, pas la fin.

#Trente étudiants, dix groupes, une seule production

Ce n’était pas un exercice isolé par groupe. Une dizaine de groupes, environ trente étudiants, travaillaient en même temps sur le même cluster et le même GitLab. Chaque groupe industrialisait un micro-service différent, mais tous devaient converger vers les mêmes environnements pour reconstituer Escolis en entier.

Ça change tout. Il faut partager un dépôt d’infrastructure commun, respecter strictement les conventions (namespaces, nommage des images, ports) et accepter qu’une erreur dans ton service peut casser l’environnement de tout le monde. La stabilité du produit final était une responsabilité collective.

#Un vrai cluster, partagé par toute la promo

Pas de simulation : on travaillait sur un cluster Kubernetes (K3s) avec un master et six workers, mutualisé entre tous les groupes.

• Chaque groupe avait son propre namespace (ns-groupe-X), une sandbox privée.
• Trois namespaces globaux étaient partagés par tout le monde : staging, preprod et prod. C’est là que les micro-services de toute la promo étaient assemblés.
• Les runners GitLab tournaient directement dans le cluster. Les pipelines pouvaient donc parler aux pods via le DNS interne de Kubernetes, sans jamais passer par l’extérieur :

http://<service>.<namespace>.svc.cluster.local:<port>

Ce qui m’a le plus marqué, c’est le RBAC à deux niveaux. En tant qu’étudiant, j’avais les droits d’écriture sur le namespace de mon groupe, et seulement la lecture sur les environnements globaux. Le robot CI/CD, lui, pouvait écrire dans staging, preprod et prod… mais n’avait aucun droit sur les namespaces des groupes.

Autrement dit : personne ne déploie en production à la main. Tout passe par le pipeline. C’est une contrainte, et c’est exactement le but.

#Quatre environnements, quatre filets de sécurité

Le pipeline était pensé comme une progression. Chaque environnement ajoute une couche de vérification.

Sandbox : shift-left. Avant même de déployer, on analyse le code, le Dockerfile et les manifests YAML. L’objectif : un retour au développeur en moins de deux minutes. Une faille détectée ici coûte presque rien à corriger.

Staging : l’application tourne vraiment. On attaque les vraies URLs internes avec des tests DAST (OWASP ZAP, fuzzing) et on vérifie que les contrats d’API sont respectés.

Preprod : est-ce que ça tient ? Tests de charge pour valider les quotas CPU et mémoire, et chaos engineering : on supprime des pods au hasard pour prouver que l’architecture se répare seule, sans perte de données.

Prod : livrer sans que personne ne s’en rende compte. Stratégies zero-downtime, dashboards Grafana et protections à l’exécution.

#Deux façons de travailler avec Git

On utilisait deux workflows, chacun adapté à son rôle.

Sur les dépôts applicatifs, du trunk-based development : une branche courte, une merge request vers main qui déclenche les scans statiques, un merge qui construit une image temporaire et la déploie dans la sandbox, puis un tag de version (v2.1.0 par exemple) qui produit l’image Docker officielle.

Sur le dépôt d’infrastructure global, du GitFlow, où chaque branche correspond à un environnement :

feature/*  →  develop (staging)  →  release/ICE-2026-vX (preprod)  →  main (prod)

La règle que j’ai trouvée la plus intéressante : un merge vers main devait être validé par quelqu’un d’un autre groupe. Une revue croisée obligatoire, tracée dans l’historique. Ça oblige à écrire des changements compréhensibles par quelqu’un qui ne connaît pas ton service. Et ça, c’est une vraie compétence.

#Le trajet d’un changement, de bout en bout

Pour rendre tout ça concret, voici le chemin d’une modification :

1. Un développeur pousse son code et ouvre une merge request. La CI lance un scanner statique (Bandit, par exemple). Après le merge sur main, l’image est construite et déployée automatiquement dans la sandbox du groupe. Si les tests passent, un tag de version produit l’image Docker officielle.
2. Le manifest Kubernetes du service est mis à jour dans le dépôt d’infrastructure (feature/* → develop). Déploiement automatique en staging, puis attaque DAST automatisée avec OWASP ZAP contre l’environnement global.
3. Quand tous les groupes ont fusionné sur develop, une merge request vers release/… déclenche la preprod : tests de charge et chaos engineering sur tout le système.
4. Dernière merge request vers main, revue par un autre groupe, déploiement en production et supervision en temps réel dans Grafana.

#Ma partie : le service Calendriers

J’étais dans le groupe 8, à trois, responsable du service Calendriers en Node.js. Comme notre effectif était réduit, la preprod n’était pas exigée pour nous ; on a concentré l’effort sur le reste de la chaîne.

#Bloquer une image vulnérable dès la CI

Dans la sandbox, on scannait l’image Docker avec Trivy. Si une vulnérabilité CRITICAL apparaissait, le pipeline s’arrêtait, point :

trivy image --exit-code 1 --severity CRITICAL "$IMAGE"

Une ligne. Mais c’est la première fois que j’ai vu la sécurité passer de « recommandation » à « condition pour avancer ».

#Vérifier le contrat de l’API en staging

En staging, des tests Newman/Postman vérifiaient automatiquement que l’API de création d’événements répondait bien 201 Created et respectait le contrat de données attendu. Si un autre groupe dépendait de notre format, il était protégé.

#Basculer en production sans coupure

Pour la prod, on a mis en place un déploiement Blue/Green : deux Deployments Kubernetes, calendrier-blue et calendrier-green. La nouvelle version démarre à côté de l’ancienne, et quand elle est prête, on bascule 100 % du trafic d’un coup avec un kubectl patch, déclenché manuellement depuis un job GitLab CI.

En simplifié, l’idée ressemble à ça :

kubectl patch service calendrier -n prod \
  -p '{"spec":{"selector":{"version":"green"}}}'

Si quelque chose se passe mal, revenir en arrière, c’est la même commande dans l’autre sens.

#Ce que j’en retiens

La sécurité, c’est une série de petites portes, pas un audit final. Un scan qui bloque en deux minutes vaut mieux qu’un rapport de cinquante pages trois semaines plus tard.

Les contraintes font l’architecture. Le RBAC, les namespaces isolés et le DNS interne ne sont pas des obstacles : ce sont eux qui rendent un cluster partagé par des dizaines de personnes vivable.

Le déploiement fait partie du produit. Avant, je voyais la mise en production comme une étape après le « vrai » travail. Maintenant, je pense à la façon dont un service sera livré, supervisé et restauré dès que je commence à l’écrire.

La revue croisée apprend l’empathie technique. Écrire pour quelqu’un qui n’a pas ton contexte, c’est écrire mieux.

À trente sur une même infrastructure, les conventions sont de la sécurité. Un nom d’image ou un port qui ne respecte pas la règle commune, et c’est l’environnement des autres groupes qui tombe.

C’est ce projet qui m’a fait passer de « je connais le DevSecOps » à « j’ai envie d’en faire mon métier ». Et c’est pour ça que Cloud et DevSecOps sont aujourd’hui au cœur de ce que je cherche.