PCI-DSS v4.0 est entré en vigueur le 31 mars 2024, avec une date butoir d'application des nouvelles exigences fixée au 31 mars 2025. Pour les fintech et tout acteur traitant des données de cartes, c'est un changement de paradigme : le standard quitte le modèle de l'audit annuel ponctuel pour exiger une démonstration continue de conformité, intégrée au cycle de développement. Cela ne signifie pas que les audits annuels disparaissent ; cela signifie que l'auditeur QSA ne se contente plus d'un état figé au jour de l'audit et demande désormais des preuves d'exécution permanente — logs de scans, rapports de rotation de credentials, journaux de signatures d'artefacts. Cinq exigences en particulier façonnent le travail DevSecOps post-v4. L'exigence 6.4.3 demande un test de sécurité applicative (SAST minimum) à chaque changement de code applicatif, pas seulement avant une mise en production majeure. L'exigence 8.4.2 impose une rotation effective des credentials et le bannissement de toute clé long-lived, avec preuve technique de la rotation. L'exigence 11.6.1 introduit la sécurisation explicite de l'infrastructure as code. L'annexe A3.2.5 régit la sécurité de la chaîne d'approvisionnement logicielle. L'exigence 12.10 exige des runbooks d'incident testés. Notre approche structurelle : répondre à chacune par un mécanisme automatisé observable, plutôt que par une procédure documentée rétroactivement. Le premier pilier est le SAST continu. Un workflow GitHub Actions exécute Semgrep à chaque push, avec un ruleset combinant les règles communautaires fintech, les règles OWASP Top 10, et des règles custom internes (interdiction de logger un PAN, détection d'usage de `random.random` pour générer des tokens, vérification des chemins de masquage côté sortie). Les findings critiques bloquent le merge ; les findings élevés exigent une justification du tech lead signée et conservée comme artefact PR pour l'audit. SonarQube peut remplacer Semgrep pour les équipes habituées à Sonar, à condition d'activer les profils de sécurité PCI-DSS. Le deuxième pilier est la gestion des dépendances et des secrets. Snyk (ou Trivy + Grype en équivalents open-source) scanne les dépendances Node.js, Java ou Python à chaque commit, et un Renovate ou Dependabot crée automatiquement des PR de mise à jour. Côté secrets, HashiCorp Vault gère la rotation tous les 90 jours minimum, exposée aux applications via External Secrets Operator côté Kubernetes — les secrets matérialisent en mémoire dans le pod, jamais sur disque, et la rotation déclenche un rolling restart contrôlé. Pour démontrer la rotation en audit, un dashboard Grafana branché sur les métriques Vault montre l'âge maximum de chaque secret, mis à jour en temps réel. Le troisième pilier est la signature et l'immutabilité des artefacts. Chaque image Docker produite par le pipeline est signée avec cosign en utilisant une clé hardware-backed (idéalement AWS CloudHSM ou GCP Cloud HSM). À l'admission Kubernetes, une admission policy Kyverno ou OPA Gatekeeper vérifie la signature et refuse silencieusement les artefacts non signés. Le registry conserve un mode strictement append-only — pas de suppression possible, audit log conservé deux ans. Cela rend la chaîne d'approvisionnement traçable de bout en bout : du commit Git au pod en production, chaque maillon a sa preuve cryptographique présentable à l'auditeur. Le quatrième pilier est l'infrastructure as code sécurisée. Terraform est devenu le standard, mais nu il ne répond pas à PCI-DSS v4. Trois compléments sont nécessaires. Premièrement, authentification OIDC vers le cloud (AWS, GCP, Azure) plutôt que des access keys long-lived — GitHub Actions a un support natif. Deuxièmement, scan statique des plans avec `checkov` et `tfsec` avant chaque apply, avec règles ciblant explicitement les contrôles PCI-DSS (chiffrement S3 obligatoire, logs CloudTrail activés, pas de Security Group `0.0.0.0/0` en entrée sur les ports sensibles). Troisièmement, un job quotidien de drift detection qui compare l'état Terraform au cloud réel et ouvre un ticket en cas de divergence non justifiée. Le cinquième pilier est le déploiement progressif avec rollback automatique. Argo Rollouts (ou Flagger) sur EKS / GKE applique une stratégie canary : 5% du trafic pendant 10 minutes, puis 25%, puis 50%, puis 100%. À chaque palier, une analyse SLI automatique compare la latence p95, l'error rate et la saturation CPU du nouveau ReplicaSet contre le baseline. Une dérive au-delà des seuils (par exemple +20% sur la latence ou +0,5% sur l'error rate) déclenche un rollback immédiat sans intervention humaine, en général en moins de 90 secondes. Ce mécanisme répond directement aux exigences de continuité de service tout en réduisant le MTTR de manière objectivable. La pièce qui lie tout, et qui manque souvent dans les projets qui échouent, est l'observabilité. OpenTelemetry sur tous les services, traces et métriques envoyées vers Grafana Tempo + Prometheus, dashboards Grafana exposant par environnement les indicateurs PCI-DSS critiques : âge des secrets, taux de signature d'artefacts, dérives Terraform ouvertes, MTTR moyen sur 30 jours, couverture SAST. Quand l'auditeur QSA arrive, il ne consulte plus des PDF figés — il regarde le dashboard et constate l'exécution. C'est exactement le changement culturel que PCI-DSS v4 cherchait à provoquer, et c'est aussi ce qui rend la conformité durable plutôt que cosmétique. Un ordre de grandeur réaliste sur la durée de mise en conformité : 5 à 7 mois pour une fintech de 15 à 50 développeurs partant d'une pipeline manuelle Jenkins, à condition de structurer le programme par les cinq piliers ci-dessus plutôt que par une lecture article-par-article du standard. Les projets qui suivent le standard de manière linéaire mettent typiquement le double et terminent avec une dette technique structurelle.