SOPRA STERIA
Analyste Cybersécurité et Gouvernance | Alternance | Sept 2025 – Avril 2026
Le contexte : Gouvernance de la sécurité à l’échelle entreprise
Chez Sopra Steria, j’ai intégré une équipe de consultants en cybersécurité et gouvernance. Mon rôle ? Analyser les risques informatiques d’un client stratégique et proposer une stratégie de sécurité cohérente et pérenne.
Contrairement à du support IT classique, ce n’était pas « corriger des bugs », c’était « identifier les failles critiques, quantifier les menaces, et tracer la route pour les éliminer » en tenant compte des contraintes budgétaires et opérationnelles du client.
Les missions : Une approche méthodique et technique
Ma base de travail : EBIOS RM (Expressions of Needs and Identification of Security Objectives – Risk Management), la méthodologie française de référence pour les analyses de risques, couplée à EGERIE, l’outil de pilotage et de reportage qui centralise tous les risques, les plans d’action et le suivi.
Concrètement, j’ai animé 5 ateliers EBIOS RM auprès de 2 à 3 clients différents pour identifier les risques informatiques de façon systématique. J’ai loggé chaque risque dans EGERIE avec son contexte, son impact (critique/fort/moyen/faible), et son propriétaire responsable. J’ai créé des plans de préconisations détaillés pour éliminer ou réduire chaque risque identifié. J’ai piloté des points réguliers avec les clients pour valider les choix techniques et négocier les priorités en fonction du budget. Et j’ai participé à la redéfinition du PASG (Plan d’Assurance Sécurité Gouvernance) – le document qui définit les normes de sécurité de toute l’entreprise.
Le mix de risques : 70% classique, 30% technique complexe
Les risques qu’on a identifiés, ce n’était pas que du « HTTP non chiffré » (même si ça existait en zone interne). On a croisé des configurations faibles (protocoles non chiffrés, absence de MFA), une gestion insuffisante des accès (droits trop larges, absence d’audit), des chaînes d’approvisionnement fragiles (dépendance à des vendors sans contrats de sécurité), et même de la fraude cyber potentielle liée à des failles d’authentification ou de logs mal configurés.
Mais surtout, on a trouvé des trucs vraiment techniques.
L’anecdote qui m’a marqué : Une vulnérabilité de concurrence sur la base de données
Durant une analyse de risque, on travaillait sur une base de données critique utilisée par plusieurs services simultanément. En creusant la documentation technique de la BDD, j’ai découvert une vulnérabilité de concurrence : si deux processus appelaient la même base de données en même temps et faisaient des modifications simultanées, on pouvait soutirer des informations sensibles (data exfiltration via condition de race), crasher complètement la BDD ou seulement certaines valeurs, ou créer des états incohérents des données (corruption).
Le truc intéressant ? La solution existait déjà dans la doc du vendor, mais le client ne la connaissait pas. On a recommandé l’implémentation d’un système de versioning des données – essentiellement, chaque modification crée une version de la donnée avec un timestamp et un hash, ce qui permet de détecter les modifications simultanées et les rejeter/retry, d’avoir un audit complet (qui a modifié quoi et quand), et de rollback en cas de souci.
C’est typique du job de consultant : pas inventer la roue, mais avoir l’esprit critique suffisant pour creuser la doc, trouver ce qui existe, et l’adapter au contexte du client.
Les projets du client : Où les risques se matérialisent vraiment
J’avais un client principal pour lequel j’animais les analyses et je pilotais les plans d’action. Ce client avait deux gros projets en cours qui soulevaient des enjeux de sécurité majeurs.
Le premier était une migration de datacenter. Le client quittait son infrastructure physique actuelle pour migrer vers une nouvelle. Les risques étaient évidents : downtime non planifié qui paralyse le service critique, perte de données lors de la migration (corruption, oubli de fichiers), incohérence entre l’ancien et le nouveau (données qui ne synchro pas), et surtout des attaques qui profiteraient de la fenêtre de migration quand les défenses sont baissées et l’organisation chaotique. On a proposé une stratégie de migration par vagues avec points de synchronisation entre ancien et nouveau, des tests de restauration pour valider qu’on ne perd rien, et des équipes de sécurité dédiées pendant la fenêtre sensible.
Le second projet était encore plus sensible : mise en place d’une API externe. Le client voulait exposer une API aux partenaires externes. Ça veut dire authentification robuste (OAuth2, JWT bien signé, pas de secrets en dur), chiffrement en transit (TLS 1.3 minimum, zéro HTTP), gestion des clés API (rotation régulière, audit complet, traçabilité), rate limiting et DDoS protection (l’API ne doit pas crasher sous charge), et logging exhaustif des appels (qui appelle quoi, quand, d’où).
L’une de mes premières recommandations : chiffrer les échanges entre clients et API avec des algorithmes modernes (AES-256 en plus du TLS), et surtout logger chaque changement de clé API dans un système d’audit immuable (blockchain/ledger distribué ou simplement des logs centralisés non modifiables).
L’enjeu majeur que j’ai amené : Le chiffrement post-quantique
Là où j’ai vraiment déployé mon esprit critique, c’est quand j’ai réalisé quelque chose de fondamental : la majorité des algorithmes de chiffrement actuels (RSA, ECDSA, etc.) seront cassés dans 10 à 15 ans si les ordinateurs quantiques arrivent à maturité.
Le client n’en parlait pas. Personne n’en parlait vraiment. Mais avec une infrastructure aussi critique, la continuité de service dans 20 ans, c’est maintenant qu’on la prépare.
J’ai donc amené le sujet de façon proactive : « On chiffre vos données avec RSA-2048 aujourd’hui, mais dans un futur proche, c’est du papier mâché pour un quantum computer. On fait quoi ? »
Le client (qui est une grosse entreprise) a compris immédiatement l’enjeu. Du coup, je suis en train de construire une roadmap vers le chiffrement post-quantique : Phase 1 en 2026, audit complet des algorithmes crypto utilisés actuellement. Phase 2 de 2026 à 2027, commencer par les données les plus sensibles (cryptage de secrets, clés maîtres) et migrer vers NIST-standardized post-quantum algos (Kyber pour l’échange de clés, Dilithium pour la signature). Phase 3 de 2027 à 2028, étendre à toute l’infrastructure critique. Phase 4 à partir de 2028, évaluer l’évolution des standards et adapter.
Ce n’est pas du « on va le faire demain », c’est une stratégie à long terme adaptée à la maturité des technologies et aux contraintes du client.
Le pilotage et les résultats
On a livré une quarantaine de risques identifiés et loggés dans EGERIE avec des plans d’action détaillés pour chacun (technique, budgétaire, RH). La majorité ont été appliqués (les clients ont vraiment implémenté nos recommandations). Les plans non appliqués sont marqués en rouge (car budgétairement bloqués), mais au moins le client sait ce qu’il risque.
On a mesuré une réduction significative du score de risque global (avant/après notre intervention), une compliance améliorée vis-à-vis des standards (ISO 27001, ISO 27005), et une sensibilisation du client sur des menaces qu’il ne voyait pas (post-quantique, fraude cyber).
Les changements appliqués par le client incluaient l’implémentation du versioning de BDD (fix immédiat), un chiffrement renforcé de l’API (TLS 1.3, logging exhaustif, key rotation), MFA obligatoire sur tous les accès critiques, une politique de segmentation réseau (zones de confiance clairement définies), et un plan de migration sécurisée du datacenter (avec freeze windows, validation points, rollback plan).
Les risques budgétairement bloqués ? Ils sont documentés en rouge pour que le client sache : « Si on ne traite pas ça, on s’expose à X et Y. »
Ce que j’ai vraiment appris
Cybersécurité et Gouvernance : Ce n’est pas juste de la techno, c’est du leadership. Je dois convaincre des décideurs (CTO, CISO, CFO) que la sécurité ce n’est pas un coût, c’est de la prévention. Montrer l’impact en termes business (perte de données = millions d’euros, downtime = réputation en jeu).
Face à l’incertitude : EBIOS, c’est une méthodologie, mais chaque client est différent. Il faut adapter : certains veulent du détail technique, d’autres veulent juste les gros risques. Il faut naviguer entre l’exhaustivité et le pragmatisme, entre « il faudrait tout chiffrer » et « on a 50k€ de budget ». Ce n’est pas appliquer une recette, c’est créer une stratégie.
Esprit critique poussé loin : Le post-quantique, c’est l’exemple parfait. Pas beaucoup de consultants soulèvent ça en 2025-2026. Mais une vraie expertise, c’est de voir les menaces de demain et de préparer le client maintenant. C’est de demander « et dans 10 ans ? » quand tout le monde parle d’aujourd’hui.
Gérer les points clients : Animer 10 à 15 points par mois, présenter les risques, défendre les choix techniques face à des objections budgétaires, c’est une compétence. Pas évident de dire « non, on ne peut pas faire que du HTTP interne » sans passer pour un puriste.
Les lendemains : Ce qui continue
Je quitte Sopra Steria en avril, mais les analyses de risque continuent (l’équipe prend le relais), le client applique progressivement les plans d’action, la roadmap post-quantique est validée et elle va être implémentée sur 3 à 4 ans, et les normes du PASG évoluent (elles vont être revisitées chaque année).
C’est cool de voir qu’on a structuré quelque chose qui dépasse mon départ. Les risques sont documentés, les décisions sont tracées, le client sait ce qu’il doit faire.
Compétences rattachées à cette réalisation
- Cybersécurité et Gouvernance (EBIOS RM, EGERIE, PASG, stratégie long terme)
- Face à l’incertitude (adaptation méthodologique, navigation budgétaire, vision future)
- Esprit critique (versioning de BDD, post-quantique, anticipation des menaces)
- Résolution de problème (identification de vulnérabilités cachées, roadmaps d’implémentation)