Article · 30 mars 2026 · 5 min de lecture

Du bricolage à la confiance : notre labo DevSecOps, reconstruit

La version un, c'était une semaine de travail, un pipeline, et beaucoup de bricolage. Elle prouvait le concept : du code entre, une image scannée sort, Argo CD la pose sur un cluster. La version deux, c'est la même petite app avec presque chaque couche en dessous remplacée, restructurée ou durcie. Voici ce qui a changé, et pourquoi.

L'app est un prétexte

Anchor est un planificateur de révisions espacées construit pour nous-mêmes : donnez-lui un sujet et une date de départ, il rend les dates exactes de révision (jour 0, puis 3, 7, 14, 30) avec un fichier calendrier. Quelques centaines de lignes de Streamlit. Elle compte ici pour une seule raison : c'est l'application que nous faisons passer dans le pipeline DevSecOps complet, de bout en bout, comme le serait le service d'un client.

Ce qu'est le labo

Un pipeline GitLab qui construit, scanne, teste, déploie, surveille et annule une app conteneurisée sur trois environnements Kubernetes (dev, staging, production), sur un cluster k3s provisionné en Terraform. Rien ne vit dans un fichier monolithique : le repo applicatif porte son code et ses manifests, la logique de pipeline vit dans la même bibliothèque de composants publique qui déploie ce site, et la production est en GitOps : le pipeline commite un changement de version dans un repo de manifests, et Argo CD réconcilie le cluster. Git est la source de vérité de ce qui tourne.

Le pipeline, étape par étape

• Avant la moindre couche Docker : tests unitaires, détection de secrets, SAST, lint et lint du Dockerfile, en parallèle.
• Construire une fois : l'artefact d'image descend la chaîne, chaque job travaille sur les mêmes octets.
• Scanner : Grype fait échouer le pipeline sur les vulnérabilités critiques ; le rapport est un artefact.
• Du vrai bout en bout : Playwright ouvre l'app dans un vrai navigateur, en Docker-in-Docker. Pas d'approximation curl : ce que voit l'utilisateur est ce que nous testons.
• Des portes : pousser l'image, staging et production sont des décisions manuelles ; dev se déploie tout seul.
• Les health checks décident : chaque déploiement est vérifié en interrogeant les pods Ready sur le tag d'image attendu. La production patiente jusqu'à quinze minutes, car la synchronisation Argo CD se fait hors bande.
• Rollback sans héroïsme : si le health check échoue, le job de rollback part tout seul ; s'il a réussi, le job lit le résultat et s'ignore. Aucune décision manuelle sous pression.
• Puis on reteste : Playwright tourne contre l'URL de production après la synchro, et une sauvegarde S3 à la demande est à un clic.

Ce qui a changé entre v1 et v2

L'instructif, c'est le pourquoi de chaque couche. GitHub Actions a cédé la place à GitLab pour le mécanisme d'include, le registre intégré et les portes manuelles natives. Le fichier de pipeline unique a été éclaté en composants réutilisables, parce qu'un correctif doit atterrir partout à la fois. Trivy a cédé la place à Grype après la découverte de vulnérabilités sérieuses dans le scanner lui-même : un rappel que suivre l'actualité et s'adapter fait partie du métier. Un registre Harbor auto-hébergé sur sa propre machine est devenu le registre GitLab fourni avec le projet : une machine de moins, une surface d'attaque de moins. Un environnement est devenu trois, chacun avec son health check et son rollback. L'absence de vérification post-déploiement est devenue des checks par sondage avec rollback automatique. Et un cluster aveugle a reçu l'opérateur Datadog : traces APM, santé des pods, et un dashboard.

Honnêtement, ce qui reste devant

Moteurs de politiques, gestion des secrets, métriques DORA, déploiements canary et un retour d'état Argo CD plus serré dans le pipeline sont encore sur la liste. L'objectif n'a pas bougé : une plateforme qu'on peut présenter, défendre et transmettre. La v2 s'en approche. Elle n'est pas finie, et le dire fait partie de la méthode.

Le code est public : gitlab.com/project-ds1/project-ds-v2. Et si vous hésitez entre un gros repo unique et une séparation précoce : séparez tôt. Le coût de l'extraction plus tard est toujours supérieur au coût d'un second repo maintenant.