Pourquoi les postes juniors cyber disparaissent

Éditorial

Enquête sur le discours de pénurie mondiale de talents en cybersécurité et sur l'absence de postes juniors permettant d'acquérir l'expérience exigée.

~11 min de lecture8 sections

Pourquoi les postes juniors cyber disparaissent

Le discours sur la pénurie mondiale de talents en cybersécurité décrit un manque de personnes compétentes. Le mécanisme réel est plus gênant : les organisations demandent une expérience opérationnelle, puis externalisent ou suppriment les conditions qui permettraient de l’acquérir. Ce n’est pas une pénurie de vocations, c’est une chaîne de formation cassée.

Explication de la marmotte

Le système ressemble à une entreprise qui chercherait des cuisiniers ayant déjà travaillé dans sa propre cuisine, tout en refusant d’embaucher des apprentis. À court terme, elle croit éviter les erreurs. À long terme, elle manque de personnel et prétend découvrir un mystère mondial.

→ Lire l’explication complète de la marmotte

La pénurie de talents masque une pénurie de capacité d’apprentissage

Un poste « junior » qui exige trois ans d’expérience en réponse à incident, administration de pare-feu, audit ou gestion des identités n’est pas un poste junior. C’est un poste intermédiaire payé avec un intitulé junior. La fraude sémantique est pratique : elle transforme un arbitrage budgétaire en crise abstraite de marché, donc en sujet pour slides de fournisseurs.

Le compromis central est brutal. Embaucher un débutant réduit la capacité de production immédiate d’une équipe, car un ingénieur expérimenté doit relire, expliquer, limiter les privilèges et absorber les erreurs initiales. En échange, l’organisation construit une capacité durable, documente ses opérations et réduit sa dépendance aux recrutements externes. Refuser ce coût donne un gain local, puis facture des taux de turnover, des prestations onéreuses et des postes vacants qui vieillissent très bien dans un outil de suivi. Les postes vacants ont cette qualité rare : ils ne demandent ni formation ni budget.

La recommandation est donc de financer explicitement des postes juniors avec une capacité d’encadrement associée. Pas de les accrocher à une équipe déjà saturée en espérant qu’un canal de discussion et un wiki feront office de transmission. Cette approche est valide si trois conditions sont réunies :

1. un périmètre de production peut être découpé en tâches à faible rayon d’explosion ;
2. un référent dispose d’un temps réservé, mesuré et protégé ;
3. les accès sont progressifs et réversibles.

Sans ces trois conditions, le poste junior devient un alibi RH, puis un compte à privilèges mal supervisé. Ce n’est pas une filière, c’est une attaque par fatigue contre l’équipe.

Le sujet touche directement l’architecture cyber : une architecture exploitable produit des tâches observables, répétables et réversibles. Une architecture où chaque changement exige la mémoire d’une seule personne ne forme personne, même avec les meilleurs intitulés de poste.

L’expérience exigée est souvent un proxy de risque mal conçu

L’expérience demandée dans une offre sert généralement de substitut à quatre propriétés distinctes : savoir exécuter une procédure, reconnaître un incident anormal, comprendre les dépendances d’un changement et assumer une décision sous contrainte. Les confondre produit des exigences absurdes, par exemple demander cinq ans d’expérience sur une technologie plus récente que l’offre elle-même.

Une expérience professionnelle ne garantit pas ces propriétés. Une personne peut avoir administré cent environnements sans avoir conçu de contrôle d’accès, lu un journal d’authentification ou testé une restauration. À l’inverse, une personne débutante peut démontrer une compétence précise avec un dépôt versionné, un environnement de laboratoire, une analyse de menace ou une procédure de reprise testée. Le recrutement doit donc évaluer des preuves de capacité, pas une durée passée à proximité d’un clavier.

Pour un rôle junior en sécurité infrastructure, une grille crédible distingue au minimum :

• les connaissances déclaratives : expliquer pourquoi un mot de passe ne doit pas être journalisé ;
• les gestes opératoires : déployer une règle de filtrage avec validation et retour arrière ;
• le raisonnement : identifier les actifs, les identités et les flux affectés ;
• la discipline : produire une trace exploitable, demander une revue, signaler une incertitude ;
• la limite d’autorité : savoir s’arrêter avant une action irréversible.

Cette dernière propriété est sous-estimée. Un débutant qui escalade une situation incertaine est moins dangereux qu’un profil expérimenté persuadé que désactiver les contrôles « juste cinq minutes » relève de l’agilité. Vingt ans de métier apprennent que les cinq minutes en question ont une étonnante longévité.

L’expérience reste nécessaire pour les rôles qui portent des clés de chiffrement, des accès d’administration globale ou la décision de contenir un incident majeur. Il ne faut pas vendre le contraire. Confier la rotation d’une clé maîtresse ou la suppression d’un environnement à une personne non accompagnée n’est pas un programme de formation. C’est une loterie avec journalisation centralisée, quand la journalisation existe.

Postes juniors et surface d’attaque organisationnelle

Une filière junior mal conçue crée une surface d’attaque. Le risque ne vient pas du statut junior, mais de l’écart entre les droits accordés, les contrôles disponibles et la maturité des procédures. Cet écart existe aussi chez les recrutements seniors, mais il est plus souvent maquillé par une certification ou un intitulé ronflant.

Les attaques connues contre ce type d’organisation sont prévisibles :

• Ingénierie sociale : un attaquant exploite l’autorité supposée d’un collègue pour obtenir un secret, contourner une validation ou faire modifier une règle.
• Escalade de privilèges : un compte attribué pour apprendre possède des droits plus larges que la tâche ne l’exige.
• Détournement de procédures : une demande urgente pousse à exécuter un script non revu ou à approuver sa propre modification.
• Exfiltration involontaire : des journaux, sauvegardes ou exports de configuration contiennent des identifiants, des jetons d’accès ou des données personnelles.
• Dépendance au mentor unique : l’absence du référent bloque les opérations ou force des contournements non documentés.

Les contre-mesures doivent être architecturales. Attribuer des droits temporaires par tâche, séparer les environnements de test et de production, imposer la revue à quatre yeux pour les changements sensibles, centraliser les journaux et tester la restauration. Un coffre de secrets ne remplace pas ces contrôles : il distribue des secrets, il ne décide pas si leur usage est légitime.

La gestion des identités mérite une attention particulière. Un compte nominatif doit être créé avant l’accès, associé à un rôle limité, désactivé à la sortie et revu périodiquement. Les comptes partagés rendent l’apprentissage confortable pendant deux jours et l’investigation impossible pendant deux ans. La page sur les identités et accès complète ce point : l’attribution doit suivre une responsabilité, pas une équipe entière ni un tableau Excel fossilisé.

Ce mécanisme ne garantit pas qu’un junior deviendra autonome, ni qu’un mentor sera compétent pédagogiquement, ni qu’une équipe conservera ses recrutements. Il garantit seulement que la prise de risque est visible, limitée et réversible. La rétention dépend ensuite du niveau de rémunération, de la qualité du management, de la mobilité interne et de la charge réelle. Aucun contrôle d’accès ne répare un budget construit sur l’idée que les gens travaillent par amour des alertes à 02:17.

Requis de plateforme pour une filière junior exploitable

Une filière ne doit pas dépendre d’une bonne volonté informelle. Avant toute ouverture de poste, il faut disposer d’un socle d’exploitation minimal :

• un système de suivi des candidatures, ou ATS (Applicant Tracking System), capable de versionner les critères et de conserver les décisions ;
• un gestionnaire de code avec revue obligatoire et droits séparés entre contribution et approbation ;
• un environnement de laboratoire isolé, sans secrets de production ni interconnexion implicite ;
• une gestion centralisée des identités avec authentification multifacteur ;
• une collecte de journaux horodatés et protégés contre la modification ;
• des sauvegardes testées pour les configurations, scripts, procédures et preuves de recrutement.

Les dépendances doivent être documentées comme pour un service technique. Une personne en apprentissage dépend d’un référent nommé, d’une file de tâches, d’un accès de laboratoire, de créneaux de revue et d’un mécanisme d’escalade. Si l’un de ces éléments disparaît, la progression s’arrête ou les contournements commencent. Les contournements ont une faculté de reproduction supérieure aux procédures officielles.

La rotation des secrets est également une condition d’exploitation. Un jeton attribué à un exercice doit expirer automatiquement. Un accès temporaire doit avoir une date de fin. Les mots de passe ou clés exposés dans un dépôt de formation doivent être révoqués, même si le dépôt était supposé privé. « Privé » décrit une intention d’interface, pas une propriété cryptographique.

Exemple reproductible : bloquer les offres junior incohérentes

Le contrôle suivant valide une offre en format JavaScript Object Notation (JSON). Il refuse une offre déclarée junior qui exige plus d’un an d’expérience ou qui accorde un accès de production sans mentor désigné. Le schéma utilise JSON Schema Draft 2020-12 et ajv-cli version 5.0.0.

# Installer un validateur localement dans un répertoire de travail.
npm install --save-dev ajv-cli@5.0.0 ajv-formats@3.0.1

# Écrire le schéma de contrôle des offres.
cat > offre.schema.json <<'EOF'
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["niveau", "experience_max_ans", "mentor", "acces_production"],
  "properties": {
    "niveau": { "const": "junior" },
    "experience_max_ans": { "type": "integer", "minimum": 0, "maximum": 1 },
    "mentor": { "type": "string", "minLength": 3 },
    "acces_production": { "const": false }
  },
  "additionalProperties": false
}
EOF

# Cette offre passe : le périmètre d'accès reste hors production.
printf '%s\n' \
'{"niveau":"junior","experience_max_ans":1,"mentor":"referent-securite","acces_production":false}' \
> offre.json

# La commande retourne 0 seulement si l'offre respecte le contrat.
npx ajv validate -s offre.schema.json -d offre.json --spec=draft2020

Ce contrôle ne remplace pas une revue humaine. Il force cependant l’organisation à rendre ses contradictions détectables avant publication. Le même principe peut s’appliquer aux droits demandés, à la présence d’un budget de formation et à l’existence d’une procédure d’intégration.

Versionner cette politique dans le dépôt qui contient les modèles d’offres évite les modifications discrètes faites sous pression. Toute exception doit être approuvée, datée, limitée et réexaminée. Une exception non expirante n’est pas une exception, c’est une règle qui a honte d’elle-même.

Supervision, sauvegarde et reprise de la filière

La supervision doit mesurer le système, pas seulement le nombre de recrutements. Les indicateurs utiles sont le délai avant première tâche revue, le nombre de tâches réalisées sous revue, le délai de retrait des accès temporaires, la couverture des procédures documentées et le ratio de tâches bloquées faute de référent. Mesurer uniquement les embauches récompense la création de comptes, pas la construction de compétence.

Les données de candidatures, évaluations et décisions doivent avoir une durée de conservation définie, des accès minimaux et des sauvegardes chiffrées. Les sauvegardes doivent inclure les référentiels de compétences, les schémas de validation et les procédures de mentorat. Sans cela, le départ d’un responsable efface la méthode et l’organisation redécouvre le recrutement « senior only », grand classique des civilisations qui refusent les archives.

La reprise doit être prévue pour l’indisponibilité d’un mentor : référent secondaire, documentation de tâches, file de travaux non bloquants et procédure d’arrêt des accès sensibles. Il ne faut pas compenser l’absence par l’élargissement automatique des privilèges. Cette réponse résout une indisponibilité en créant un incident potentiel, ce qui est une forme de créativité dont l’infrastructure se passe très bien.

Les enjeux humains ne sont pas séparables des contrôles techniques. La section humain et les ressources de gouvernance permettent d’élargir l’analyse, notamment sur la responsabilité, l’évaluation et la traçabilité des décisions.

🐝 Ce qui arrive si on s’en passe

Sans filière junior encadrée, l’équipe de sécurité se réduit à quelques profils seniors et à des prestataires externes. La séparation des tâches devient alors arithmétiquement impossible : quand deux personnes couvrent tout le périmètre, la revue à quatre yeux se transforme en approbation croisée de complaisance, puis en auto-approbation pendant les absences. Les comptes d’administration détenus par des tiers échappent en partie à la gestion centralisée des identités, et leur révocation dépend d’un contrat plutôt que d’un processus interne. Personne en interne ne peut vérifier les alertes traitées par le prestataire ni contester ses conclusions. Les astreintes tournent sur un effectif trop faible, et chaque incident nocturne mobilise les mêmes personnes, sans relève capable de prendre le quart suivant.

🦫 Explication de la marmotte 🍫

Le problème commence quand une entreprise cherche des personnes déjà capables de travailler seules sur des sujets de sécurité informatique. Elle demande plusieurs années d’expérience, parce qu’elle veut éviter les erreurs, gagner du temps et limiter les risques. Mais si presque aucune entreprise ne propose un premier poste encadré, les débutants ne peuvent pas acquérir cette expérience. Le manque de candidats expérimentés apparaît alors plus tard.

Pour corriger cela, il faut créer des postes où l’apprentissage fait partie du travail prévu. La personne débutante commence avec des tâches limitées, documentées et vérifiées par une personne plus expérimentée. Elle ne reçoit pas immédiatement les accès permettant de modifier les systèmes les plus sensibles. Les droits sont accordés pour une durée définie, puis retirés si nécessaire.

L’organisation doit aussi surveiller ce fonctionnement. Elle vérifie que les accès sont retirés, que les actions sont enregistrées, que les documents existent et qu’un remplaçant peut aider si le référent habituel est absent. Les informations de recrutement et les documents de formation doivent être sauvegardés et protégés.

Si l’encadrement manque, le débutant est soit bloqué, soit poussé à contourner les règles pour avancer. Si les accès sont trop larges, une erreur ou une manipulation peut toucher des systèmes critiques. Le but n’est donc pas de prétendre que tout débutant est prêt immédiatement, mais de construire un parcours où les compétences et les responsabilités augmentent ensemble.

À lire aussi

• Pourquoi la dernière heure de garde échoueLa fatigue de vigilance rend la dernière heure de garde dangereuse et impose des contrôles d’exploitation qui ne reposent pas sur la mémoire humaine.

Pages voisines

La citent

• Pourquoi les CTF créent des compétences offensives réutilisables
• Pourquoi les primes de bug bounty stagnent-elles

Pourquoi les postes juniors cyber disparaissent

Elle cite

• Comment structurer un mentorat technique sans dogme
• Laisser une équipe se tromper sans casser la production
• Onboarding sécurité : règles à retenir dès l’arrivée