Pipeline DevSecOps — Fintech réglementée

Une fintech européenne soumise à PCI DSS avait construit son pipeline CI/CD à coup de scripts shell et de déploiements manuels. Le lead time moyen de mise en production s'élevait à 12 jours ; chaque release mobilisait l'équipe entière pendant une nuit. Les incidents post-déploiement représentaient 40 % des escalades client. L'objectif : industrialiser le pipeline, intégrer les contrôles de sécurité en continu et obtenir la conformité PCI DSS sans ralentir la vélocité produit. Nous avons restructuré l'ensemble du pipeline autour de GitHub Actions avec des workflows séparés par type de livrable (API, front, infrastructure). Chaque commit déclenche : Semgrep (SAST) avec un ruleset PCI spécifique, Trivy sur les images Docker, Gitleaks sur l'historique, et un DAST OWASP ZAP en mode actif sur l'environnement de staging. Les secrets sont gérés dans HashiCorp Vault avec rotation automatique toutes les 72 heures — exigence directe du chapitre 3 de PCI DSS. Le déploiement est orchestré par Argo CD en mode GitOps strict : la branche main est l'unique source de vérité pour l'état production. Chaque déploiement applique un blue/green sur EKS avec analyse automatique (error rate, latence p95, saturation CPU) via Argo Rollouts. Le rollback s'active en moins de 90 secondes si l'un des SLI franchit son seuil. Cette mécanique a permis de passer de 3 déploiements par mois à 18 par semaine sans augmenter l'astreinte. La partie la plus chronophage a été la cartographie des contrôles PCI DSS (v4.0) sur nos pratiques CI/CD. Nous avons produit une matrice de contrôles qui génère automatiquement les rapports d'audit depuis les logs CI, ce qui a réduit le temps de préparation du rapport annuel de 6 semaines à 4 jours. En production, le lead time moyen est passé de 12 jours à 3,5 jours (−70 %), les incidents post-déploiement ont baissé de 85 %, et l'équipe déploie désormais 18 fois par semaine contre 3 fois par mois. La conformité PCI DSS v4.0 a été obtenue dès le premier audit externe.