Défis de revue de code
Les développeurs examinent du code vulnérable réel, identifient la faille de sécurité et choisissent le correctif approprié parmi plusieurs options. Un parcours en deux phases qui développe à la fois la détection et la correction.
Deux phases. Un challenge.
Repérer le bloc vulnérable
Le développeur voit un extrait de code issu d'un cas réel comportant une ou plusieurs lignes vulnérables. Il clique sur le bloc qu'il pense contenir la faille de sécurité. Pas de QCM — il doit lire le code et raisonner sur ce qui ne va pas.
- ✓ Schémas de code réalistes en production
- ✓ Sélection par clic sur la ligne de code concernée
- ✓ Plusieurs tentatives autorisées
Choisir le correctif approprié
Une fois le bloc vulnérable identifié, le développeur choisit le correctif approprié parmi un ensemble d'alternatives plausibles. Les options leurres incluent des correctifs courants mais erronés — ceux qui passent en revue de code et laissent pourtant le bug en production.
- ✓ Sélection du correctif par QCM
- ✓ Leurres plausibles mais incorrects
- ✓ Explication révélée après la réponse
Un challenge, en cours.
Pensé pour l'apprentissage, pas pour la sélection.
Indices sans pénalité
Les développeurs peuvent demander un indice à tout moment. Les indices ne réduisent pas le score final — l'objectif est la compréhension, pas la sanction.
Notation basée sur les tentatives
Le score est calculé à partir du nombre de tentatives effectuées dans chaque phase. Moins de tentatives = meilleur score. Une réussite du premier coup dans les deux phases donne le score maximal.
Explication après chaque réponse
Une fois le correctif sélectionné — bon ou mauvais — la plateforme explique pourquoi chaque option est sûre ou non. Les leurres ne sont pas simplement étiquetés comme incorrects ; le mode de défaillance est expliqué.
Lire du code vulnérable, c'est le vrai métier.
La plupart des formations à la sécurité pour développeurs leur demandent de regarder une vidéo sur l'injection SQL et de répondre à un QCM. Les défis de revue de code inversent la logique : ils placent le développeur face au code en premier, et exigent le même type de raisonnement qu'une revue de code. Détection et correctif sont notés séparément parce qu'en revue réelle, savoir que quelque chose cloche et savoir comment le corriger sont deux compétences distinctes — et un ingénieur peut être fort dans l'une sans l'être dans l'autre.
Essayez vous-même un challenge.
La démo interactive propose trois défis de revue de code complets afin que vous puissiez voir le parcours en deux phases de bout en bout avant de parler à notre équipe.