Préférences technologiques
Définissez vos langages et frameworks de programmation préférés pour personnaliser votre expérience de formation. SecureCodingHub affiche automatiquement les challenges dans votre stack préférée.
Définition de vos préférences
Lors de votre première visite sur la plateforme, un assistant en 3 étapes vous guide à travers la sélection de vos langages et frameworks préférés :
| Étape | Sélection | Options |
|---|---|---|
| Étape 1 | Langage backend | JavaScript, TypeScript, Python, Java, C#, PHP, Go |
| Étape 2 | Framework frontend | React (TS/JS), Vue (TS/JS), Angular (TS/JS) |
| Étape 3 | Plateforme mobile | Swift (iOS), Kotlin (Android) |
Comment fonctionnent les préférences
Chaque sujet dans SecureCodingHub possède un stackType qui correspond à l'une de vos catégories de préférences. Lorsque vous ouvrez un challenge, la plateforme sélectionne automatiquement le langage correspondant à vos préférences.
| Type de stack | Préférence mappée | Exemples de sujets |
|---|---|---|
| Backend | Votre préférence de langage backend | SQL Injection, SSRF, Command Injection |
| Frontend | Votre préférence de framework frontend | XSS, DOM Clobbering, Prototype Pollution |
| Mobile | Votre préférence de plateforme mobile | Insecure Storage, WebView Injection, Certificate Pinning |
Le bon langage est affiché par défaut quand vous ouvrez un challenge. Vous pouvez toujours basculer vers un autre langage via le sélecteur de langage dans n'importe quel challenge.
Passer une étape
Chaque étape de l'assistant a un bouton Passer à côté de son action principale. Passer n'abandonne pas l'assistant — cela applique un défaut raisonnable pour cette étape et vous permet de continuer. Les défauts sont :
- Backend :
JavaScript - Frontend :
React (TypeScript) - Mobile :
Kotlin (Android)
Passer est le bon choix lorsqu'une étape ne s'applique pas à vous aujourd'hui — par exemple, un ingénieur frontend qui passe l'étape backend pour prendre le défaut. Vous pouvez revenir plus tard et écraser le défaut via le même assistant.
Modification des préférences
La puce d'indicateur de stack sur la barre supérieure (affichant les icônes de votre stack sélectionnée) rouvre l'assistant au clic — c'est la manière quotidienne de mettre à jour les préférences. Les changements prennent effet immédiatement sur tous les challenges et sujets. Les préférences vivent aussi sur votre profil sous Préférences technologiques, ce qui est utile lorsque vous voulez inspecter ce qui est défini sans relancer le sélecteur.
Quand un sujet n'existe pas dans votre langage
Tous les challenges ne sont pas encore livrés dans toutes les langues. Quand vous ouvrez un sujet dont l'auteur n'a pas encore fourni d'extrait pour votre langage préféré, la plateforme bascule sur une chaîne déterministe : votre préférence de stack pour la zone de ce sujet, puis le défaut défini par l'auteur du sujet, puis JavaScript, puis le premier langage disponible. Vous verrez le libellé de langue changer dans l'en-tête du challenge pour que le fallback ne soit jamais silencieux — mais vous ne verrez pas d'écran « sujet non disponible ».
Pour les administrateurs
Les préférences sont stockées par utilisateur. Les administrateurs ne peuvent pas définir les préférences pour les apprenants — chaque développeur choisit sa propre stack. Cela garantit que chaque membre de l'équipe s'entraîne dans le langage avec lequel il travaille réellement au quotidien.
Pourquoi la stack compte
Un développeur TypeScript qui lit un challenge PHP passe la majeure partie de son attention à analyser une syntaxe inconnue plutôt qu'à chercher la vulnérabilité. La charge cognitive est réelle et le coût en temps est réel. Les préférences technologiques existent pour que le langage utilisé pour enseigner un concept ne devienne pas une barrière à l'apprentissage du concept. Quand la syntaxe est fluide, votre œil va directement à la limite de confiance et à la primitive non sécurisée. C'est la mémoire musculaire que vous voulez bâtir. Un challenge dans un langage que vous ne lisez qu'à moitié vous entraîne dans la mauvaise direction : vous devenez un débogueur moyennement bon de code inconnu, et non un relecteur confiant de votre propre code.
C'est aussi pourquoi les préférences sont par utilisateur, non par organisation. Un administrateur d'équipe ne peut pas forcer un ingénieur Python à faire des challenges Java. Chaque développeur doit s'entraîner dans la stack qu'il relira, livrera et soutiendra en astreinte. Voir Mode pratique pour la façon dont le langage sélectionné pilote l'extrait par défaut affiché dans n'importe quel challenge.
Quand élargir vos paramètres de stack
Les préférences technologiques ne sont pas permanentes. Les ingénieurs full-stack qui passent réellement entre backend et frontend devraient choisir leur backend et frontend principaux, puis utiliser le sélecteur de langage dans le challenge pour basculer à la demande. Les ingénieurs qui apprennent un nouveau langage pour un projet à venir sont l'autre cas courant d'élargissement : passez quelques semaines à vous entraîner dans la nouvelle stack pour construire une aisance de revue avant que la première pull request n'arrive. Vous pouvez basculer à tout moment depuis les paramètres.
Un cas spécifique à signaler est l'ingénieur senior ou staff qui relit des pull requests à travers plusieurs stacks. Choisir un seul langage backend masque les schémas inter-langages qui apparaissent dans les vulnérabilités API et adjacentes à l'infrastructure. Faire tourner les préférences trimestriellement est une habitude raisonnable pour ce rôle.
Comment la stack interagit avec les affectations d'équipe
Quand un administrateur d'organisation crée une affectation dans Démarrage rapide, il choisit une catégorie, un sujet ou un scénario. Il ne choisit pas un langage. Chaque apprenant attribué voit le contenu attribué dans le langage correspondant à ses propres préférences technologiques. Une seule affectation « OWASP Web Top 10 » peut atterrir comme des challenges Python pour l'équipe backend, des challenges React pour l'équipe frontend et des challenges Swift pour l'équipe iOS. C'est la conception voulue : une affectation, plusieurs stacks, couverture cohérente. Les administrateurs ne devraient pas essayer de contourner cela en créant des affectations par langage en double.