Évaluation & Travaux : M2 DevOps - CI/CD DO (3 jours)¶

Établissement : Sup de Vinci
Public : Mastère DevOps — M2 (Session 2026-2027)
Épreuve : E54 — CI/CD DO (RNCP 40165, Bloc 5 : B5C1, B5C2, B5C3)
Volume horaire : 21 heures (3 journées de 7 heures)
Dépôts du projet fil rouge : securepay-api et securepay-platform

Modalités d'Évaluation¶

Le livrable réalisé pendant le module alimente le volet « Orchestration et Sécurité Applicative » du Dossier écrit individuel du Bloc 5 (MSPR 4.1), évalué par le jury de la certification.

1. Guide de l'Évaluation QCM (100%)¶

Philosophie de l'Épreuve¶

Les questions vont des fondamentaux du déploiement continu aux notions plus avancées, et portent toutes sur ce qui a été présenté et pratiqué pendant les trois jours.

L'objectif est de vérifier que vous savez :

1. Concevoir une chaîne de déploiement continu fondée sur Git, avec une stratégie de release progressive.
2. Garantir l'intégrité de chaque changement, de la Merge Request à l'admission dans le cluster, et en garder la trace.
3. Placer les tests de sécurité automatisés (SAST, DAST, IAST) au bon endroit de la chaîne.
4. Vérifier automatiquement chaque release, revenir en arrière sans intervention humaine et identifier la cause d'une défaillance.
5. Mesurer et optimiser la performance et les ressources de la chaîne.

Référentiel des 8 Domaines de Révision¶

Les questions portent sur 8 domaines, directement issus des présentations et des TP :

1. Déploiement continu, GitOps & réconciliation

• Livraison et déploiement continus : ce qui change quand la mise en production n'est plus une décision humaine.
• Modèles push et pull : droits de la pipeline sur la production, surface d'attaque.
• Argo CD : synchronisation, selfHeal, prune, détection du drift.
• Promotion : un dossier par environnement, AppProject, Merge Request, build once, deploy many.

2. Stratégies de release : Canary & Blue-Green

• Rayon d'impact : pourquoi exposer progressivement une nouvelle version.
• Limites du RollingUpdate : pas d'étapes pilotées, pas d'analyse, pas de retour arrière automatique.
• Argo Rollouts : étapes setWeight et pause, services actif et de prévisualisation.
• Choisir : coût en ressources, compatibilité des schémas de données (expand / contract).

3. Contrôle des changements & intégrité

• Digest ou tag : pourquoi une référence immuable.
• Cosign : signature sans clé longue durée, vérification de l'identité du signataire.
• Provenance et SLSA : relier un artefact à son build.
• Admission : ce qui se passe quand une image non signée arrive dans le cluster.

4. Security Policy as Code & traçabilité

• Policy as Code : traduire la PSSI en règles versionnées, testées et appliquées.
• Kyverno : tests des politiques en CI, modes Enforce et Audit, exceptions limitées dans le temps.
• Journal de déploiement : ce qu'il doit contenir, ce qu'il ne doit jamais contenir.
• resource_group : un seul déploiement à la fois par environnement.

5. Tests de sécurité automatisés : DAST & IAST

• IAST : principe, prérequis, couverture, limites.
• DAST authentifié : pourquoi un scan anonyme ne suffit pas pour une API.
• Ressources : analyses ciblées en Merge Request, analyses complètes planifiées, placement avant la promotion.
• Non-régression : chaque faille corrigée devient un test.

6. Robustness testing & analyse automatique

• Robustness testing post-déploiement : vérifier chaque version avant de l'exposer pleinement.
• SLO et thresholds k6 : percentiles plutôt que moyennes.
• AnalysisTemplate et AnalysisRun : métriques, condition de succès, failureLimit.
• Critères : erreurs, latence, métriques métier.

7. Auto-remédiation & causes racines

• Abandon automatique : ce que fait Argo Rollouts quand l'analyse échoue.
• Git après un rollback : pourquoi un revert par Merge Request reste nécessaire.
• Cause principale : quelle preuve désigne le composant défaillant.
• Temps de rétablissement : comment le mesurer, pourquoi l'automatisation le réduit.

8. Performance & ressources de la chaîne

• Mesurer d'abord : durée, attente, durée par job, chemin critique.
• Leviers GitLab CI : needs, rules:changes, interruptible, clés de cache, parallélisation.
• Runners : requêtes et limites, mise à l'échelle selon la file d'attente.
• Indicateurs DORA : vitesse et stabilité de la livraison.

2. Travaux Pratiques & Livrable (non notés)¶

Contexte : SecurePay Solutions¶

SecurePay Solutions fournit une API de paiement aux sites de commerce en ligne. Sa pipeline d'intégration continue est en place, sa plateforme Kubernetes aussi. Pourtant, une release défectueuse est restée 40 minutes en production : personne ne l'a vue passer, et le retour arrière a été fait à la main.

Le comité de direction demande une chaîne de livraison qui :

• déploie sans intervention manuelle, à partir de Git ;
• expose chaque nouvelle version progressivement ;
• vérifie automatiquement son intégrité, sa sécurité et sa tenue sous charge ;
• revient seule à la version stable en cas de dégradation, en désignant la cause ;
• reste rapide et sobre en ressources.

git clone https://github.com/Momotoculteur/securepay-api.git
git clone https://github.com/Momotoculteur/securepay-platform.git

Les travaux pratiques¶

Livrable : volet « Orchestration et Sécurité Applicative » (B5C1, B5C2, B5C3)¶

Volet « Orchestration et Sécurité Applicative » du Dossier écrit individuel du Bloc 5 (MSPR 4.1), de 8 à 12 pages hors annexes :

1. La chaîne de livraison : un schéma de bout en bout, de la Merge Request à la production, et le rôle de chaque étape.
2. La stratégie de release : Canary ou Blue-Green selon l'environnement, paramètres retenus, justification au regard du risque métier et du coût en ressources.
3. Le contrôle des changements : promotion par digest, signature vérifiée à l'admission, politiques, journal de déploiement, matrice exigence PSSI → contrôle automatisé → preuve.
4. Les tests de sécurité automatisés : place du SAST, du DAST et de l'IAST dans la chaîne, seuils bloquants, faux positifs, analyses différentielles et complètes.
5. La robustesse et l'auto-remédiation : critères d'analyse issus des SLO, démonstration d'un retour arrière automatique, composant défaillant et cause principale identifiés, temps de rétablissement mesuré.
6. La performance et les ressources : mesures avant/après, leviers appliqués, objectif de durée de pipeline, dimensionnement des runners.
7. Les limites et la suite : ce que la chaîne ne détecte pas encore, et comment l'améliorer.

Annexes : preuves horodatées et reproductibles (sorties de commandes, captures, extraits de journaux, liens vers les pipelines et les Merge Requests).

Conseil certifiant de la fiche : le candidat doit démontrer que son système d'automatisation identifie les composants défaillants et établit la cause principale de la défaillance.

Grille de retours (non notée)¶

Utilisée par l'intervenant pour les retours en séance, et par les étudiants pour s'auto-évaluer.