Intention — poser le contrat d'évaluation avant le premier geste, et faire comprendre que la journée est une journée de preuve, pas de production. Le risque numéro un du PFR d'une filière DevSecOps est le réflexe de développeur : ouvrir l'éditeur et améliorer. L'encadré « ce que la journée ne vous demande pas » existe pour cela, et c'est le passage à faire relire s'il dérive.

Ce qui coince

• La confusion entre « la faille est corrigée » et « la fermeture est prouvée ». Elle structure toute la journée et se repère tôt : s'il vous dit à 9 h 30 que le jalon 2 sera rapide « parce que tout est déjà corrigé », il n'a pas lu la troisième ligne du tableau des livrables. Reprenez-le tout de suite, cela coûte deux minutes maintenant et une heure à 11 h 30.
• Le cluster kind, sous-estimé. Il l'a laissé tourner le 13 août et n'y a plus touché depuis huit jours ; entre-temps Docker a redémarré au moins une fois. C'est le composant le plus susceptible de manquer à l'appel, et c'est pour cela que le jalon 1 le prend en deuxième position et non en dernier.
• La grille lue en diagonale. Trois critères sur sept valent ●●● et deux d'entre eux se jouent avant midi. S'il commence par soigner le rapport, il inverse la journée.

Questions à anticiper

• « Est-ce que je peux corriger encore une faille ce matin ? » — non, et l'angle n'est pas l'interdiction : une correction non répétée est une régression potentielle poussée le jour de la soutenance, sur une branche protégée, sans temps pour la rattraper.
• « Le jury, c'est qui ? » — vous, à distance, plus un second évaluateur. Dites-le clairement : la soutenance passe par un partage d'écran, ce qui change la préparation matérielle. C'est traité au jalon 4, ne l'anticipez pas ici.
• « Je montre devsecops-lab ou Juice Shop ? » — les deux ont leur place, mais le fil rouge de la démonstration est devsecops-lab, parce que c'est la seule dont il possède le code et le pipeline. Juice Shop n'intervient qu'à travers le rapport de pentest.

Ce qu'il faut exiger — rien de matériel à la fin d'une leçon. Mais au premier échange de la journée, deux réponses en trente secondes : quelle ligne de la grille l'inquiète, et à quelle heure elle se joue. S'il cite un critère du soir alors que ses deux critères ●●● les plus lourds tombent avant midi, l'arbitrage de 11 h n'aura pas lieu et le rapport sera écrit à la va-vite après 15 h.

Intention — quatre questions, quatre réponses de soutenance, prises une dans chaque module (M3 pour le gate d'image, M2 pour la preuve de fermeture, M3 pour Calico, M4 pour CVSS/DREAD). Placé à 9 h 20 pour révéler le trou avant qu'il ne coûte, pas pour noter.

Ce qui coince

• q1 ratée dans le sens « il échoue » : il croit que --exit-code 1 réagit à tout. Conséquence directe, il ne saura pas défendre son seuil de sévérité, qui est une question de jury quasi certaine.
• q2 est la plus importante des quatre et la plus ratée, dans le sens « Semgrep ne remonte plus rien ». C'est le cœur du jalon 2 : un échec ici annonce un tableau de preuves fait de sorties d'outils au lieu de rejeux d'exploits. À reprendre avant 11 h, pas après.
• q3 ratée signifie que la demi-journée du 12 août sur le remplacement de kindnet par Calico a été vécue comme une manipulation d'installation, sans en retenir le motif. La démonstration Kubernetes de l'après-midi sera alors une déclaration, pas une preuve.
• q4 ratée dans le sens « CVSS pour le code, DREAD pour l'infra » : partage faux mais confortable, et il tiendra devant le jury s'il n'est pas repris ici.

Questions à anticiper

• « Pourquoi un quiz le jour de la soutenance ? » — l'angle est utilitaire : ce sont quatre questions du jury, posées quatre heures plus tôt, quand il reste du temps pour y répondre.
• « Le score compte dans l'évaluation ? » — non. Ce qui compte est ce qu'il en fait d'ici 16 h ; renvoyez-le à la fiche de questions du jalon 4.

Ce qu'il faut exiger — le score seul ne dit rien, la répartition dit tout. Un 3/4 dont l'erreur est q1 ou q4 se rattrape dans la conversation de 11 h. Un 3/4 dont l'erreur est q2 impose de reprendre avec lui la première ligne de son tableau de preuves avant qu'il n'écrive les neuf autres sur le même modèle.

Intention — établir un état de départ opposable et, surtout, provoquer avant midi les pannes qui auraient sinon surgi à 16 h. C'est le seul créneau de la journée où une panne ne coûte rien. L'ordre des étapes encode ce raisonnement : le plus fragile d'abord.

Ce qui coince

• Le cluster kind. C'est la panne la plus probable de la journée, et le réflexe sera kind delete cluster suivi d'une reconstruction. Coupez court : reconstruire impose de réinstaller Calico, de réappliquer les quatre manifestes et d'attendre que tout se stabilise — huit à dix minutes dans le meilleur des cas, et il n'a pas répété cette séquence. docker start des deux nœuds puis kind export kubeconfig résout la grande majorité des cas en deux minutes.
• La règle de coupure de 10 h 15, ignorée. C'est le point où votre intervention à distance est justifiée, même si vous intervenez peu : envoyez un message à 10 h 15 s'il n'a pas signalé la fin du cluster. Sans ce rappel, il y passera la matinée — c'est le scénario d'échec le plus fréquent d'un PFR d'infrastructure.
• Le triage du job rouge. Il corrigera sans distinguer régression réelle et défaillance d'environnement, et perdra vingt minutes sur un dépassement de délai réseau. Le signe : il modifie ci.yml alors que le message d'erreur parle de connexion.
• act repoussé « si j'ai le temps ». Le repli n'existe que s'il a été essayé une fois dans la journée : la version d'act, l'image de runner qu'elle télécharge et le socket Docker sont trois choses qui se découvrent mal en urgence.

Questions à anticiper

• « Le job dast prend six minutes, je peux le désactiver pour la démonstration ? » — non, mais la vraie réponse est ailleurs : il n'attend pas la fin du run, il montre sast qui rougit en quatre-vingt-dix secondes. C'est ce qu'enseigne le déroulé de l'après-midi ; s'il pose la question dès le matin, renvoyez-l'y.
• « Trivy me sort une CVE HIGH nouvelle sur python:3.12-slim. » — cela arrive et c'est même une excellente nouvelle : l'image de base a été rafraîchie depuis le 11 août. Deux issues acceptables, épingler un digest ou documenter l'exception dans le rapport ; jamais lever le seuil du gate pour faire passer le build.
• « git log --show-signature me dit No signature sur un vieux commit. » — normal, la signature n'a été activée que le 4 août. Seul le dernier commit compte pour le critère.

Ce qu'il faut exiger — à 11 h, pas « tout est vert », mais trois choses montrées : la sortie de docker run --rm devsecops-lab:hardened id avec son uid=10001, la durée totale du run avec le nom du job qui en consomme la moitié, et la liste écrite de ce qui n'est pas remonté seul. Le premier sépare « image durcie » de « image durcie et vérifiée aujourd'hui ». Le troisième est ce qui fera la différence entre un plan de repli réel et un plan de repli déclaré.

Intention — produire la matière du rapport et celle de la démonstration en un seul geste, et faire vivre la différence entre « l'outil ne dit plus rien » et « l'exploit ne marche plus ». L'étape sur --no-git est le sommet pédagogique de la journée : elle transforme un exercice de vérification en un vrai travail d'audit, où l'on trouve un défaut dans son propre dispositif de contrôle.

Ce qui coince

• La tentation de corriger. Elle est presque irrésistible sur l'historique Git, et c'est le pire moment possible : filter-repo plus poussée forcée sur main protégée, à quatre heures de la soutenance, sur un dépôt dont dépend toute la démonstration. Si vous ne deviez intervenir qu'une fois dans la journée, c'est ici.
• Les preuves par sortie d'outil. Il écrira « Semgrep ne remonte plus VULN-03 » au lieu de rejouer le curl. Signe repérable en dix secondes : la colonne « Exploit rejoué » contient des noms d'outils au lieu de commandes. C'est la question q2 du quiz du matin, et c'est pour cela qu'elle y était.
• VULN-04 et VULN-08, fermées le 19 août et donc les plus fraîches — mais aussi les deux dont la correction est la plus susceptible d'être partielle. Un IDOR « corrigé » par une vérification côté client, ou une SSRF filtrée par une liste noire plutôt qu'une liste blanche, se rouvrent en une question de jury. Faites-lui montrer le code, pas seulement le code de retour.
• Le statut « Accepté » employé comme synonyme de « pas eu le temps ». Un risque accepté porte une raison écrite et un responsable ; sans cela, c'est un risque ouvert déguisé, et le jury le retourne immédiatement.

Questions à anticiper

• « Le secret dans l'historique, c'est grave ? » — ne tranchez pas à sa place. Faites-lui énumérer les facteurs : dépôt privé, clé qui est un exemple public de la documentation AWS, mais aussi un dépôt privé qui peut devenir public d'un clic. La réponse attendue n'est pas un score, c'est un raisonnement — et c'est la deuxième question de réflexion.
• « Je change --no-git dans ci.yml ? » — c'est une modification d'une ligne, tentante, et elle rendrait le job rouge sur-le-champ à cause de l'historique. Donc non aujourd'hui : cela va dans la feuille de route de la partie 5, après la purge, dans cet ordre.
• « sha256 au lieu de md5, VULN-06 est donc réglée ? » — la question mérite mieux qu'un oui. Le finding CWE-327 est effectivement fermé : l'algorithme cassé a disparu. Mais un hachage rapide reste un mauvais choix pour un mot de passe, quel qu'il soit — il faut une fonction lente et salée, bcrypt ou argon2. Faites-lui écrire cette nuance comme une ligne de la feuille de route plutôt que comme une correction : c'est une question de jury très probable, et savoir qu'un finding fermé peut laisser une faiblesse derrière lui est exactement ce qu'on attend d'un auditeur.

Ce qu'il faut exiger — à 12 h 15, dix lignes remplies dont aucune vide, et au moins un statut qui ne soit pas « Fermé ». Un tableau intégralement fermé après quinze jours de travail est statistiquement improbable et, s'il vous en présente un, l'unique question à poser est celle de l'historique Git : soit il l'a trouvé et l'a classé, soit il a coché sans regarder. Vérification en une minute : choisissez vous-même une ligne et faites rejouer l'exploit devant vous.

Intention — empêcher que le rapport d'audit soit un rapport de pentest avec un autre nom de cible. La différence tient en un mot, contrôle : un audit se prononce sur le dispositif qui empêche le retour de la faille, pas seulement sur la faille. Placée après le jalon 2 parce qu'à cet instant quatre parties sur six sont déjà écrites — c'est ce qui rend l'exercice faisable en soixante-quinze minutes.

Ce qui coince

• L'ordre de rédaction. Il commencera par la partie 1 et y passera trente minutes. Le résumé exécutif s'écrit en dernier, quand on sait ce qu'on résume : c'est écrit dans le tableau, il faudra probablement le redire à 14 h.
• La colonne « contrôle » traitée comme un ornement. C'est pourtant le seul apport propre de l'audit, et la question de jury la plus prévisible sur VULN-04 : quel job l'aurait vue ? Aucun. S'il ne l'a pas écrit, la réponse s'improvisera mal.
• Le copier-coller du rapport d'hier, structure comprise. Le format est effectivement le même — c'est voulu — mais un rapport d'audit qui n'emploie jamais le mot « contrôle » n'en est pas un.
• La partie 5 confondue avec des excuses. Une feuille de route ordonne par sévérité puis par effort et donne un geste concret par ligne. Sans effort estimé, ce n'est pas une feuille de route, c'est une liste de regrets.

Questions à anticiper

• « Combien de pages ? » — cinq à sept. La question cache presque toujours « je n'ai pas assez de matière », ce qui est faux : montrez-lui la troisième colonne du tableau des parties plutôt que de répondre au chiffre.
• « Je remets les vecteurs CVSS complets ou juste les scores ? » — complets, c'est la règle du format depuis le 7 août. Un score sans vecteur ne se rejoue pas.
• « Je mets du code dans le rapport ? » — les commandes de preuve, oui ; le code source corrigé, non. La formule qui reste en tête : le dépôt dit comment, le rapport dit pourquoi.

Ce qu'il faut exiger — leçon, donc rien à valider dans l'instant. Le signe à guetter dans l'heure qui suit : si son rapport ne comporte aucune ligne de contrôle et aucun finding ouvert, ce n'est pas un défaut de rédaction, c'est qu'il rend compte de son travail au lieu d'auditer son système. Cela ressortira intact à la première question de justification, et il sera trop tard pour le reprendre.

Intention — obtenir un livrable qu'un tiers peut rejouer, et faire pratiquer l'ordre de rédaction inverse : synthèse d'abord, résumé exécutif en dernier. C'est aussi le créneau où se révèle la qualité réelle du jalon 2 — un tableau de preuves bâclé le matin rend la partie 4 impossible à remplir.

Ce qui coince

• L'heure de bascule de 14 h 35, franchie sans y penser. C'est le seul endroit de la journée où une intervention d'autorité de votre part est justifiée : coupez, et faites lancer la première répétition. Un rapport parfait et une démonstration jamais répétée est le pire couple possible sur cette grille.
• Les dix blocs de la partie 4 écrits à longueur décroissante : trois pages pour VULN-01, deux lignes pour VULN-10. Signe que le gabarit n'est pas tenu ; le remède est de chronométrer le premier bloc.
• Les vecteurs CVSS recopiés du registre du 17 août sans vérification. Deux d'entre eux ont pu changer de contexte depuis — notamment VULN-09, dont l'exposition n'est plus la même une fois l'image durcie. Demandez-lui d'en justifier un au hasard.
• La partie 2 expédiée en trois lignes. C'est pourtant celle qui protège l'auteur : sans périmètre écrit, toute question du type « et sur un vrai cluster ? » devient un reproche au lieu d'un hors-sujet assumé.

Questions à anticiper

• « Je remets les dix blocs alors que neuf sont fermés ? » — oui. Un audit documente ce qui est fermé autant que ce qui est ouvert, sinon rien ne prouve que la fermeture a été vérifiée à cette date.
• « Le contrôle pour VULN-04, je mets quoi ? » — ne lui donnez pas « aucun » : faites-lui passer en revue ses cinq jobs et conclure lui-même. Le raisonnement vaut plus que le mot, et c'est celui qu'il redira au jury.
• « Je peux réutiliser le résumé exécutif d'hier ? » — non, les deux documents n'ont pas le même lecteur ni le même verdict. Le fond de la question est souvent le temps : renvoyez-le à l'heure de bascule.

Ce qu'il faut exiger — à 14 h 50, un fichier commité et poussé, avec ses six parties présentes, même inégales. Deux vérifications de trente secondes chacune : la partie 3 comporte une colonne « contrôle » avec au moins un « aucun », et la partie 5 porte la ligne de l'historique Git avec ses trois gestes dans le bon ordre. Si la purge y précède le retrait de --no-git, il a écrit la séquence sans la penser — et c'est une question de jury toute trouvée.

Intention — donner un déroulé qui absorbe la latence du pipeline, et convertir la liste des sept questions en travail de préparation plutôt qu'en trac. Quinze minutes juste avant le créneau de répétition : c'est un briefing, pas un cours.

Ce qui coince

• La démonstration qui attend au lieu de provoquer. C'est le défaut structurel des soutenances DevSecOps : le candidat pousse sa régression et se tait pendant six minutes. Le déroulé résout le problème, encore faut-il qu'il l'ait répété dans cet ordre — vérifiez-le au jalon 4, pas en soutenance.
• Le partage d'écran, découvert le jour même. Police minuscule, écran entier, notifications personnelles à l'écran. Dix minutes de préparation matérielle au jalon 4 évitent trois incidents.
• La question sur le pre-commit. Il répondra que le hook bloque le commit ; la réponse attendue est qu'un hook local se contourne avec --no-verify, et que c'est précisément pour cela que les mêmes outils tournent aussi en CI, où ils ne se contournent pas. Cette question sépare « j'ai installé pre-commit » de « je comprends où vit un contrôle ».
• Les réponses apprises par cœur. Signe en soutenance : la réponse est plus longue que la question et n'en traite pas le dernier tiers. Repérable dès la répétition — interrompez-le une fois pour le lui montrer.

Questions à anticiper

• « Et si le run n'est pas fini à la douzième minute ? » — le job sast l'est, et c'est celui qui bloque la fusion. Faites-lui dire cette phrase à voix haute, elle lui servira telle quelle.
• « J'ai le droit de dire que je ne sais pas ? » — oui, avec la suite : comment il s'y prendrait. C'est ce que la deuxième règle appelle assumer les manques.
• « Vous allez m'interrompre pendant la démonstration ? » — donnez le format : les questions viennent après, sauf s'il passe trop vite sur un point qui compte.

Ce qu'il faut exiger — leçon, rien à valider. En tant que jury, préparez deux questions dont vous connaissez déjà la réponse par son rapport : elles testent la cohérence entre ce qu'il a écrit à 14 h et ce qu'il affirme à 16 h 20. Et s'il décrit au lieu de justifier, ce n'est pas un défaut d'expression : c'est qu'il a repris un réglage d'un module sans se l'approprier, et la colonne « contrôle » de son rapport le confirmera en trente secondes.

Intention — obtenir un chronométrage réel et un plan de repli constitué avant d'en avoir besoin. Le créneau est volontairement court : l'arbitrage de ce qu'on coupe fait partie de l'exercice, et c'est même le seul moment où il pratique la compétence qu'on lui demandera le plus souvent en poste.

Ce qui coince

• La répétition mentale. Il annoncera vingt minutes sans avoir chronométré ; en réel, vingt-quatre. Demandez le relevé par segment, jamais le total : le total se devine, le relevé par segment ne s'invente pas.
• Le hook pre-commit qui refuse le commit de régression. Il va le découvrir et croire sa préparation cassée. C'est au contraire une excellente nouvelle et un moment de démonstration à part entière : --no-verify passe outre, et c'est justement l'illustration de pourquoi les mêmes outils tournent aussi en CI. S'il ne fait pas le lien tout seul, c'est la relance à lui donner.
• Le plan de repli repoussé « s'il reste du temps », donc jamais fait. C'est le poste le plus facile à sacrifier et le plus coûteux à ne pas avoir. Quinze minutes, pas négociables.
• La coupe faite dans le mauvais segment. Sous pression il rognera sur la justification des choix, qui est silencieuse et lui semble donc dispensable, et gardera la manipulation, qui est visible. C'est l'inverse du barème.

Questions à anticiper

• « Je peux préparer les terminaux à l'avance ? » — oui, le créneau de 16 h à 16 h 10 existe pour cela. Mais la séquence complète doit avoir été répétée, y compris le démarrage de Juice Shop.
• « Et si la régression est fusionnée par erreur ? » — elle ne peut pas l'être, la protection de branche l'interdit tant que sast est rouge. C'est même le point de la démonstration ; faites-le lui reformuler.
• « Combien de diapositives ? » — cinq au maximum, et le schéma de chaîne vaut mieux qu'une capture illisible en visioconférence.

Ce qu'il faut exiger — une répétition intégrale chronométrée avec les durées relevées segment par segment, et le répertoire artefacts/repli/ non vide. L'observable qui distingue « prêt » de « ça devrait passer » : il sait dire ce qu'il coupe s'il a cinq minutes de retard à la moitié. Sans ce plan de coupe, le débordement écrase mécaniquement le segment de justification, c'est-à-dire le seul critère ●●● que la démonstration ne couvre pas.

Intention — ce n'est pas une auto-évaluation, c'est la grille de départ de la soutenance. Les onze critères se vérifient en moins de deux minutes chacun et constituent, dans l'ordre, l'ordre du jour du retour de jury. Le créneau couvre 16 h – 17 h : préparation, vingt minutes de soutenance à 16 h 10, retour, clôture du parcours.

Ce qui coince

• Le quatrième critère est le cœur de la journée et le plus facile à cocher à tort. Prenez vous-même deux lignes au hasard dans son tableau et faites rejouer les deux exploits devant vous. C'est la vérification qui teste tout le rapport en trois minutes.
• Le cinquième critère, « au moins un finding ouvert ». S'il n'en a aucun, il n'a pas regardé l'historique Git — ou il l'a regardé et l'a corrigé, ce qui est pire. Une seule question à poser : que voit le job secrets avec --no-git ?
• Le critère git ls-files. Il l'a vu le 3 août et le croit acquis une fois pour toutes ; or .env, les artefacts et les manifestes ont bougé pendant quinze jours. Faites-le lancer devant vous : cinq secondes, et c'est le seul critère du parcours qui, raté, compromettrait un vrai dépôt.
• La branche demo/regression déjà poussée « pour être sûr ». Elle ruine l'effet de la démonstration et laisse une pull request ouverte avec une faille dedans. Faites-lui vérifier, c'est un git branch -r.
• Le relevé par segment absent. Sans lui, il n'a pas de plan de coupe, et il n'y a plus de temps pour en fabriquer un.

Questions à anticiper

• « Un job est rouge pour une raison réseau, je coche quand même ? » — non, mais ce n'est pas éliminatoire : il coche à côté ce qui est rouge et pourquoi, et il l'annonce dans les deux premières minutes de la soutenance. Un problème annoncé cesse d'être un problème.
• « On peut décaler si la plateforme ne remonte pas ? » — non. Un report abîme plus qu'il n'aide, et le plan de repli existe exactement pour ce cas.
• « Qu'est-ce que je fais de tout ça après ? » — la clôture est prévue jusqu'à 17 h. Le dépôt, les deux rapports et le journal lui appartiennent et constituent son dossier de prise de poste.

Ce qu'il faut exiger — avant 16 h 10 : la plateforme tourne, les onglets sont ouverts, la police est lisible en partage d'écran. S'il débogue encore à 16 h 05, la soutenance démarre quand même à l'heure et il bascule sur le repli. La vérification qui départage, après la démonstration : prenez une ligne de son tableau de preuves et faites-la constater en direct. Concordance, il a mesuré ; écart inexpliqué, tout le tableau redevient douteux — et c'est aussi ce que ferait un client.