TCHAMKO CHABRELL — Architecte SI

Formations & Expériences

[ formation académique ]

[ mastère · architecte réseaux & cybersécurité ]

01 ↗

Télécom Paris · MS ARC

Mastère Spécialisé® · Alternance / Stage recherchée

514h, 75 ECTS. Architecture SI, gouvernance, PSSI, EBIOS Risk Manager, SOC, gestion de projet.

Architecture SIPSSIISO 27001EBIOSSDN/SASE

Sept 2026 · En recherche d'alternance

[ cycle ingénieur · sécurité réseaux · Dijon ]

Polytech Dijon

Cycle Ingénieur · Sécurité et Qualité des Réseaux informatiques

Cryptographie, administration systèmes Linux/Windows, développement logiciel, CI/CD, virtualisation réseau, architecture SI sécurisée.

Sécurité réseauxCybersécuritéLinuxCI/CDVirtualisation

En cours · Sept 2024 — Juil 2026 · Dijon

[ ingénieur · télécommunications & réseaux · Yaoundé ]

Polytech Yaoundé (ENSPY)

Ingénieur en Télécommunication & Réseaux · Double diplôme ENSPY / Polytech Dijon

Réseaux avancés, Systèmes, Cybersécurité, Architectures distribuées. Conception d'infrastructures réseaux, sécurisation des systèmes, simulation d'architectures réseau.

TélécommunicationsRéseaux avancésArchitectures distribuéesCybersécurité

Sept 2022 — Juil 2026 · Yaoundé

[ expérience ]

[ R&D informatique · C++ ]

Pryntec

Stage R&D · Ingénieure Logicielle Réseau C++

Mission : développer une bibliothèque C++ de communication réseau chiffrée.

Stage · Fév — Juil 2026 · 6 mois

[ administration systèmes & réseaux ]

ICTA P.M · Dijon

Stage · Ingénieure Réseau & Sécurité

Mission : sécuriser l'accès au réseau de l'entreprise et migrer son outil GLPI.

Stage · Avr — Juil 2025 · 4 mois

Projets sélectionnés

[ 03 études de cas · 2025 → 2026 ]

Trois projets, dans l'ordre où je les ai vécus. À chaque étape je suis descendue d'un niveau : d'abord qui a le droit d'entrer sur le réseau, puis comment protéger l'infrastructure qui héberge les services, enfin ce qui se passe à l'intérieur d'un paquet chiffré. Chacun a répondu à une question que le précédent m'avait laissée.

[ couche 1 · contrôle d'accès ]

01 ↗

802.1X NAC & GLPI

Stage · ICTA P.M · Avr — Juil 2025

N'importe quel équipement branché sur une prise accédait au réseau. Comment savoir qui entre, et l'envoyer au bon endroit ?

J'ai déployé l'authentification 802.1X par certificat (RADIUS/NPS, PKI interne, EAP-TLS), des VLAN attribués selon le profil avec quarantaine des inconnus, le SSO Kerberos, puis migré GLPI de Windows IIS vers Ubuntu en suivant les recommandations ANSSI.

→ La sécurité réseau commence par l'identité, et une PKI se conçoit avant de se déployer.

802.1XEAP-TLSPKIKerberosGLPI

[ couche 2 · infrastructure ]

02 ↗

Sécurité d'un cloud IaaS

PFE · Laboratoire Informatique de Bourgogne · Oct 2025 — Jan 2026

En IaaS, le client gère presque tout et les machines partagent le même hôte. Comment empêcher qu'une seule VM compromise menace toutes les autres ?

Mon premier déploiement OpenStack a échoué faute de ressources. J'ai alors comparé 10 plateformes, choisi OpenNebula, puis empilé les protections : accès uniquement par VPN, chiffrement LUKS contrôlé par le client, reverse proxy anti-DDoS, durcissement de KVM (AppArmor, Seccomp) et détection avec Falco.

→ Une seule couche de sécurité ne suffit jamais, et savoir changer d'outil à temps fait partie du travail.

OpenNebulaKVMOpenVPNLUKSFalco

[ couche 3 · protocole & chiffrement ]

03 ↗

SecureComm C++

Stage R&D · Pryntec · Fév — Juil 2026

Jusqu'ici j'avais configuré des outils de chiffrement. Ici, il fallait l'écrire : protéger les échanges temps réel entre composants embarqués, sans ajouter de latence.

J'ai développé en C++17 une bibliothèque de communication TCP/UDP sécurisée : chiffrement authentifié AES-256-GCM ou ChaCha20-Poly1305 selon le matériel (x86 ou ARM), contrôle d'intégrité HMAC-SHA256 et protection anti-rejeu par numéro de séquence. Je suis partie de zéro en C++ pour arriver jusqu'à l'API SecureSocket.

→ Comprendre le chiffrement au niveau de l'octet m'apprend ce que coûte et ce que garantit chaque brique d'une architecture.

C++17TCP/UDPAES-256-GCMChaCha20HMAC

[ fil rouge ]

01AccèsQui entre ?

02InfrastructureQue protège-t-on derrière ?

03ProtocoleQue garantit le chiffrement ?

→ArchitectureConcevoir l'ensemble · MS ARC

Le certificat et la clé reviennent dans les trois projets : EAP-TLS chez ICTA, certificats OpenVPN et LUKS pendant le PFE, AES-GCM et HMAC chez Pryntec. Je les ai d'abord configurés, puis assemblés, puis codés. C'est ce qui m'oriente vers le métier d'architecte réseaux & cybersécurité : concevoir un SI dans son ensemble en sachant ce qui se passe dans chaque couche. Il me manque encore la gouvernance (ISO 27001, EBIOS RM, PSSI) et le pilotage de projet ; c'est exactement ce que je vais chercher au MS ARC de Télécom Paris.

Certifications

[ 07 certifications ]

[ Cisco · CCNA Associate · Routing & Switching ]

Cisco Networking Academy · ESIREM Dijon

CCNA : Associate Routing & Switching ↗

Module 1

Présentation des réseaux

28 Mar 2025

Module 2

Switching, Routing & Wireless Essentials

28 Mar 2025

Module 3

Enterprise Networking, Security & Automation

04 Mar 2026

[ Cisco · GL04 · Network Security ]

Cisco Networking Academy

Network Security ↗

Sécurité des réseaux TCP/IP, pare-feux, VPN, contrôle d'accès, détection d'intrusions — CyberTech Academy.

09 Mai 2025

[ Fortinet · FCF · Threat Landscape ]

Fortinet Training Institute

FCF — Introduction to the Threat Landscape 2.0 ↗

Fondamentaux cybersécurité : paysage des menaces, vecteurs d'attaque, bonnes pratiques défensives.

26 Juillet 2024

[ TryHackMe · Pre Security ]

TryHackMe · THM-YTK6NANIGY

Pre Security Learning Path ↗

Fondamentaux sécurité offensifs et défensifs. 19h 10min. Réseaux, Linux, cryptographie, Web.

6 Avril 2026

[ TryHackMe · Cyber Security 101 ]

TryHackMe · THM-ERW5PDF4KE

Cyber Security 101 Learning Path ↗

Parcours avancé cybersécurité. 45h 23min. Pentest, forensics, réseaux, reverse engineering, SIEM.

3 Juin 2026

Stage · Pryntec · R&D Informatique

SecureComm C++

Pryntec — Bourgogne · Février – Juillet 2026

Contexte

Pryntec est une PME spécialisée dans la vidéo industrielle et embarquée pour le marché de la sécurité. Le besoin : sécuriser les échanges entre composants logiciels internes via un module C++ transmettant des données chiffrées sur TCP/UDP.

Objectif

Développer un mécanisme de chiffrement léger, performant et portable — intégré dans une bibliothèque C++ interne — garantissant la confidentialité et l'intégrité des communications réseau en temps réel.

Durée

Février — Juillet 2026 · 6 mois · 35h/semaine

Les 5 phases du stage

Bases C++ & Environnement

Semaines 1–2 · En cours

VS Code, g++, CMake, Git. Variables, types, conditions, boucles, fonctions.

Mémoire, Pointeurs & Paquets

Semaines 3–4

Pointeurs, références, buffers. Modélisation d'un paquet réseau avec struct.

Sockets TCP & UDP

Semaines 5–7

Client/serveur TCP et UDP. Envoi/réception de messages, gestion des erreurs.

POO & Architecture Bibliothèque

Semaines 8–10

Classes TcpSocket, SecureSocket. API : send(), receive(), connect(), close().

Chiffrement & HMAC

Semaines 11–24 · Livrable final

AES/ChaCha20 via OpenSSL. HMAC pour l'intégrité. Tests unitaires + Doxygen.

Architecture sécurité — Pipeline de chiffrement

ÉMISSION :
  Données brutes
  → [1] Chiffrement  : AES-256-GCM  ou  ChaCha20-Poly1305
  → [2] Intégrité    : HMAC-SHA256 (clé partagée + hash du payload)
  → [3] Anti-rejeu   : numéro de séquence monotone (uint64)
  → [4] En-tête UDP/TCP + envoi socket

RÉCEPTION :
  [4] Lecture socket → [3] Vérif. séquence (fenêtre glissante)
  → [2] Validation HMAC → [1] Déchiffrement → Données originales

Structure d'un paquet SecureComm

struct SecurePacket {
    uint8_t   version;       // version protocole
    uint8_t   cipher_id;     // 0 = AES-GCM | 1 = ChaCha20
    uint64_t  seq_num;       // anti-rejeu (monotone)
    uint16_t  payload_len;   // taille données chiffrées
    uint8_t   payload[MAX];  // données chiffrées (nonce inclus)
    uint8_t   hmac[32];      // HMAC-SHA256 du paquet complet
};

Choix techniques & justifications

AES

Pourquoi AES-256-GCM ?

Standard NIST pour le chiffrement authentifié (AEAD). Le mode GCM apporte confidentialité + intégrité en un seul passage. Accélération matérielle native via AES-NI → latence <0.1ms par paquet.

CC20

Pourquoi ChaCha20-Poly1305 aussi ?

Pryntec fabrique des systèmes embarqués (ARM, pas d'AES-NI). ChaCha20 est conçu pour être rapide en logiciel pur. La bibliothèque s'adapte au matériel détecté au runtime.

HMAC

Pourquoi HMAC-SHA256 ?

Garantit authenticité + intégrité. Contrairement à un checksum, un HMAC sans la clé secrète est impossible à forger. Protection contre le tampering en transit.

SEQ

Anti-rejeu par numéro de séquence

Le récepteur maintient une fenêtre glissante (64 paquets). Tout paquet dont le numéro est déjà vu ou hors fenêtre est rejeté. Protection contre les attaques replay.

Objectifs & livrables attendus

✓ Bibliothèque C++ portable : Linux / Windows / ARM
✓ API simple : SecureSocket::send() / receive() / connect()
✓ Latence ajoutée par chiffrement < 1ms par paquet
✓ Tests unitaires > 80% couverture (Google Test)
✓ Documentation Doxygen · Aucune fuite mémoire (valgrind clean)

Compétences acquises

Apprendre le C++ en partant de zéro

Types à taille fixe, pointeurs, gestion mémoire, puis programmation orientée objet, jusqu'à concevoir une API de bibliothèque. Une progression planifiée en cinq phases.

Penser le réseau au niveau de l'octet

Structurer un paquet, gérer les tailles et l'ordre des octets, distinguer ce que TCP garantit de ce qu'UDP laisse à la charge de l'application.

Choisir une primitive cryptographique

AES-GCM ou ChaCha20 selon la présence d'AES-NI, HMAC pour l'intégrité, numéro de séquence contre le rejeu. Chaque choix se justifie par une menace et une contrainte matérielle.

Livrer comme en industrie

CMake, Git, tests unitaires Google Test, documentation Doxygen, contrôle des fuites avec valgrind.

Ce que j'en retiens

Pendant le PFE, j'écrivais « chiffré en AES-256 » comme une garantie. Ici, j'ai découvert tout ce que cette phrase cache : la gestion du nonce, l'authentification, le rejeu, la latence sur un processeur ARM. Une erreur d'un octet suffit à tout casser. Je lis désormais une architecture de sécurité en me demandant ce que chaque brique coûte et ce qu'elle garantit vraiment.

Et ensuite

Je ne cherche pas à devenir développeuse, mais ce stage a confirmé mon projet : être architecte réseaux & cybersécurité, quelqu'un qui conçoit l'ensemble d'un SI sans prescrire de mesures irréalistes, parce qu'il sait comment elles fonctionnent de l'intérieur. Le MS ARC de Télécom Paris m'apportera ce qui me manque : la gouvernance (ISO 27001, EBIOS RM) et le pilotage de projet.

Technologies

C++17CMakeTCP/UDPAES-256-GCMChaCha20HMAC-SHA256OpenSSLlibpcapGoogle TestDoxygenGit

Stage · ICTA P.M · Avr – Juil 2025

802.1X NAC & Migration GLPI

Administration Systèmes & Réseaux · 4 mois · Bourgogne

Contexte

ICTA P.M est une PME avec une infrastructure réseau hétérogène (postes Windows et Linux, équipements Cisco). Problème : tout équipement branché accédait au réseau sans aucun contrôle. L'outil ITSM GLPI tournait sur un vieux serveur Windows IIS sans durcissement.

Réalisation 1 — Contrôle d'accès réseau IEEE 802.1X

Poste client (Supplicant)
    ↕  EAP-TLS (certificat machine)
Switch Cisco (Authenticator) — port bloqué jusqu'à auth réussie
    ↕  RADIUS (UDP 1812)
Windows NPS / RADIUS (Authentication Server)
    ↕  LDAP
Active Directory (base utilisateurs + certificats)

EAP-TLS — Authentification par certificat

Le protocole EAP-TLS impose l'usage de certificats mutuels. Aucun mot de passe ne circule sur le réseau — seuls des tokens cryptographiques signés.

PKI interne + déploiement GPO

Création d'une Autorité de Certification (CA) interne. Les certificats machine sont émis automatiquement via GPO sur tous les postes du domaine.

VLAN dynamiques par politique RADIUS

NPS retourne des attributs RADIUS-VLAN selon le profil. Postes certifiés → VLAN 10 (production). Équipements inconnus → VLAN 99 (quarantaine).

Réalisation 2 — SSO Kerberos + Active Directory

Tickets Kerberos — zéro mot de passe sur le réseau

Au login, un ticket TGT est émis par le KDC. Pour chaque service, un ticket de service est obtenu sans ressaisir le mot de passe.

Apache GSSAPI — SSO web transparent

Configuration de mod_auth_gssapi sur Apache. Les utilisateurs connectés à l'AD s'authentifient sur les apps web sans saisir quoi que ce soit.

Jointure Linux à l'Active Directory (realmd + SSSD)

Les serveurs Ubuntu sont joints au domaine AD via realmd + sssd. Authentification Windows/Linux unifiée via un seul annuaire.

Réalisation 3 — Migration GLPI (Windows IIS → Ubuntu LAMP)

Migration sans perte de données

Export de la base GLPI depuis MySQL/Windows Server. Import sur MariaDB / Ubuntu 22.04 LTS avec PHP 8.1 + Apache2. 0 enregistrement perdu.

Durcissement ANSSI

Headers HTTP de sécurité (CSP, HSTS, X-Frame-Options), accès GLPI restreint par IP + auth Kerberos, sauvegardes chiffrées automatisées.

# Headers sécurité Apache appliqués
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
Header always set X-Frame-Options "DENY"
Header always set X-Content-Type-Options "nosniff"
Header always set Content-Security-Policy "default-src 'self'; script-src 'self'"

Résultats

✓ 100% des accès réseau contrôlés et tracés par RADIUS/NPS
✓ VLAN dynamiques : quarantaine automatique des équipements inconnus
✓ SSO Kerberos transparent pour 30+ utilisateurs AD
✓ GLPI migré avec 0 perte de données, conforme ANSSI
✓ Durée d'authentification réseau : <2 secondes (EAP-TLS)

Compétences acquises

Concevoir une PKI, pas seulement l'installer

Choisir qui émet quoi, comment les certificats arrivent sur les postes (auto-enrôlement GPO) et ce qui se passe quand l'un d'eux expire : le poste perd le réseau.

Faire dialoguer des systèmes hétérogènes

Switch Cisco, NPS, Active Directory, serveurs Ubuntu : un seul annuaire et une seule identité, que ce soit pour le port réseau, la session ou l'application web.

Migrer un service en production

Sauvegarder, restaurer sur la nouvelle plateforme, vérifier, puis basculer, sans perdre un seul ticket GLPI.

Durcir à partir d'un référentiel

Appliquer les recommandations ANSSI ligne par ligne plutôt que des réglages trouvés au hasard.

Ce que j'en retiens

Un 802.1X mal préparé, ce sont des utilisateurs bloqués le lundi matin. J'ai compris qu'une mesure de sécurité doit prévoir son mode dégradé : un VLAN de quarantaine plutôt qu'un refus sec, une méthode d'authentification qui reste transparente (moins de 2 secondes). Une sécurité qui gêne trop finit contournée.

Et ensuite

Ce stage m'a fait choisir la sécurité réseau plutôt que l'administration système pure. Il m'a aussi laissé une question : une fois l'accès contrôlé, comment protège-t-on les serveurs et les machines virtuelles qui se trouvent derrière ? C'est le sujet que j'ai choisi pour mon PFE.

Technologies

802.1XEAP-TLSRADIUS/NPSPKI / CAGPOKerberosActive DirectoryApache GSSAPISSSD / realmdGLPIUbuntu 22.04MariaDBPHP 8.1Cisco Switch

Projet de fin d'études · Polytech Dijon · Laboratoire Informatique de Bourgogne

Sécurité d'un cloud IaaS

Garantie d'un service de sécurité dans un environnement de cloud computing · 16/10/2025 – 30/01/2026 · Tuteur : Nader Mbarek

D'où je partais

Chez ICTA, j'avais sécurisé l'entrée d'un réseau d'entreprise. Mais je n'avais jamais eu la main sur ce qu'il y a derrière : les serveurs, l'hyperviseur, le stockage. Le PFE m'a donné l'occasion de construire et sécuriser une infrastructure complète.

Problématique

J'ai choisi le modèle IaaS parce que c'est celui où le client porte le plus de responsabilité : système, réseau, accès. Les menaces y sont propres à la mutualisation : échappement de VM (VM escape), failles de l'hyperviseur, mouvements latéraux entre VM, DDoS, mauvaises configurations. La question : quels mécanismes, combinés, réduisent réellement la surface d'attaque d'un cloud IaaS ?

Démarche

État de l'art

Modèles SaaS / PaaS / IaaS / NaaS, menaces par modèle, mécanismes de défense, en m'appuyant sur le NIST, la CSA et le rapport ANSSI 2025 sur la menace cloud.

Première tentative : OpenStack, et échec

Le VPS ne suffisait pas pour faire tourner les services OpenStack de façon stable. S'y ajoutaient la virtualisation imbriquée KVM, les permissions libvirt et la configuration de Neutron et Keystone. J'ai traité ça comme un risque projet plutôt que de m'acharner.

Benchmark : 10 outils, 11 critères

5 plateformes (OpenStack, CloudStack, Eucalyptus, Nimbus, OpenNebula) et 5 simulateurs (CloudSim, MR-CloudSim, DCSim, GreenCloud, iCanCloud). OpenStack obtenait 9/11 et OpenNebula 7,5/11. J'ai retenu OpenNebula : plus léger, et réellement déployable dans le temps et avec les ressources disponibles.

Déploiement, puis sécurisation

OpenNebula 6.10 en all-in-one sur un VPS OVH. L'environnement part d'un état volontairement permissif (SSH redirigé publiquement), que je sécurise ensuite couche par couche.

Architecture déployée

                    Internet
                        │
              [ OpenVPN · UDP 1194 ]   ← seul point d'entrée vers les VM
                        │
       ┌────────────────┴─────────────────┐
       │  VPS OVH · Ubuntu                │
       │  OpenNebula 6.10 (Sunstone, API) │  front-end + nœud de calcul
       │  KVM / QEMU via libvirt          │  AppArmor · Seccomp · Falco
       │  3 datastores (system, image,    │
       │    files) · driver SSH           │
       │  Réseau NAT virbr0               │
       │    192.168.122.0/24              │
       │   ├─ VM nginx-proxy  (anti-DDoS) │
       │   └─ VM clientes     (LUKS /data)│
       └──────────────────────────────────┘

5 mécanismes, chacun face à une menace

OpenVPN : plus aucune VM exposée

Menace : scans, force brute SSH, usurpation d'IP. J'ai supprimé la redirection NAT du SSH public : on ne joint le réseau des VM qu'à travers le tunnel, avec un certificat client valide. Les profils .ovpn sont distribués via un petit portail web authentifié.

LUKS : une clé que l'opérateur n'a jamais

Menace : accès au stockage ou compromission de l'hyperviseur. Chaque VM cliente a un disque de données secondaire que le client chiffre lui-même (script setup-luks.sh, AES-256-XTS), avec une passphrase qu'il est seul à connaître. Même l'administrateur du cloud ne peut pas lire /data.

Nginx reverse proxy : tenir sous la charge

Menace : HTTP flood, Slowloris. Une VM Nginx frontale limite à 10 requêtes/s par IP (rafale de 20), 10 connexions simultanées, impose des timeouts courts, masque sa version et n'accepte que le trafic venant du VPN.

Durcissement de l'hyperviseur KVM/QEMU

Menace : VM escape. Mises à jour de sécurité automatiques, vérification des mitigations Spectre/Meltdown, profil AppArmor qui interdit à QEMU /root, l'écriture dans /boot et /sys/kernel ainsi que les capacités sys_admin et sys_rawio. Filtre Seccomp qui tue le processus sur ptrace, bpf, perf_event_open ou userfaultfd.

Falco : détecter ce qui passe malgré tout

Menace : zero-day. Règles personnalisées qui alertent sur les appels système dangereux, les accès à /dev/mem ou /proc/*/mem et les tentatives d'escalade de privilèges (setuid, setgid).

Ce que j'ai vérifié

✓ Test de charge ApacheBench (10 000 requêtes, 100 en parallèle) : 0 rejet sans protection, 1 327 requêtes rejetées par Nginx avec protection
✓ SSH public fermé : la connexion directe échoue, l'accès à la VM ne passe que par le VPN
✓ Disque LUKS illisible sans passphrase (hexdump : seul l'en-tête LUKS est visible)
✓ VM toujours fonctionnelles une fois AppArmor et Seccomp appliqués

Compétences acquises

Raisonner par modèle de menace

Partir de la menace pour choisir le mécanisme, et non de l'outil à la mode. Chaque brique du projet répond à un risque identifié dans l'état de l'art.

Virtualisation et isolation

Comprendre ce qui isole réellement deux VM (processus QEMU, libvirt, bridges, profils MAC) et où se situent les points de rupture.

Comparer et décider

Construire une grille d'évaluation et défendre un choix qui n'est pas le mieux noté, parce qu'il correspond aux contraintes réelles.

Mesurer et documenter

Prouver l'effet d'une protection par un test avant/après, et rédiger des annexes qu'un autre administrateur peut rejouer.

Ce que j'en retiens

L'échec d'OpenStack a été la partie la plus formatrice : j'ai appris à reconnaître le moment où persister devient un risque pour le projet, et à replanifier sans perdre l'objectif. J'ai aussi appris à rester honnête sur les limites : un seul nœud, et aucune simulation d'attaque multi-locataires ou zero-day. Enfin, le modèle de responsabilité partagée m'a marquée : bien sécuriser, c'est aussi décider qui détient quelle clé.

Et ensuite

J'avais assemblé OpenVPN, LUKS et TLS sans jamais voir comment un chiffrement s'écrit. C'est ce qui m'a donné envie du stage chez Pryntec : passer de l'intégration de briques cryptographiques à leur implémentation.

Technologies

OpenNebula 6.10KVM / QEMUlibvirtOpenVPNLUKS / dm-cryptNginxAppArmorSeccompFalcoiptablesApacheBenchOVH VPS

Télécom Paris · IP Paris · Mastère Spécialisé® · RNCP n°38140

MS ARC — Architecte Réseaux & Cybersécurité

Admissible · Promotion 2026/2027 · En recherche d'alternance

Présentation

Le MS ARC de Télécom Paris forme des architectes au croisement des réseaux télécoms et de la cybersécurité. Label Mastère Spécialisé® CGE renouvelé le 01/09/2023 pour 6 ans. Enregistré RNCP n°38140. Formation intensive d'un an (514h d'enseignements + mission d'application 4–6 mois) — 75 ECTS.

4 blocs de compétences

BC1

Architecture cybersécurisée d'un réseau télécom ou d'un SI — 234,5h

Réseaux d'entreprise (BGP, IPv6, QoS, SDN/SASE), couches basses (5G, FTTH, IoT), architecture SI, cloud computing (Docker, K8s, SASE, SSE), services client et cybersécurité.

BC2

Piloter un projet de développement de la cybersécurité — 77h

Management de projet télécom, Security by Design, aspects juridiques (GDPR, droit cyber), économie du secteur télécom.

BC3

Gouvernance de la sécurité des réseaux et des SI — 63h

ISO 27001/27005, EBIOS Risk Manager, PSSI, indicateurs de sécurité, audit de sécurité, SMSI, GDPR.

BC4

Sécuriser, protéger et défendre un réseau ou un SI — 129,5h

PKI, chiffrement, protocoles sécurité, tests d'intrusion, APT, gestion des identités, SOC, gestion de crise, PCA/PRA, IA & cybersécurité.

Organisation

✓ 514h d'enseignements · 75 ECTS (45 enseignements + 30 thèse professionnelle)
✓ 1 à 2 semaines intensives par mois (lun–ven/sam) · 10 mois
✓ Cours dispensés en présentiel à Télécom Paris
✓ 2 périodes entreprise : acclimatation (4 mois min.) + mission d'application (4–6 mois)
✓ Soutenance de thèse professionnelle devant jury

Débouchés visés

Architecte réseaux & cybersécuritéRSSIConsultant cybersécuritéChef de projet sécuritéExpert technique SIAnalyste réseaux & SI

Sécuriser
ce qui compte.

Parcours

Formations & Expériences

Télécom Paris · MS ARC

Polytech Dijon

Polytech Yaoundé (ENSPY)

Pryntec

ICTA P.M · Dijon

Projets sélectionnés

802.1X NAC & GLPI

Sécurité d'un cloud IaaS

SecureComm C++

Expertise

Certifications

Construisons
un SI solide
ensemble.

Sécuriserce qui compte.

Parcours

Formations & Expériences

Télécom Paris · MS ARC

Polytech Dijon

Polytech Yaoundé (ENSPY)

Pryntec

ICTA P.M · Dijon

Projets sélectionnés

802.1X NAC & GLPI

Sécurité d'un cloud IaaS

SecureComm C++

Expertise

Certifications

Construisonsun SI solideensemble.

Sécuriser
ce qui compte.

Construisons
un SI solide
ensemble.