Johan Heurtebise

Contexte & Enjeux

Dans le cadre de ma formation, j'ai réalisé un audit et une campagne de sensibilisation fictive. L'objectif : transformer l'utilisateur, souvent maillon faible, en première ligne de défense.

Objectifs Pédagogiques

Analyser les vecteurs d'attaques (Social Engineering, Malware).
Vulgariser des concepts techniques (Chiffrement, 2FA).
Concevoir des supports visuels impactants.

Cadre SAE 1.01 - IUT Blois

Rôle Responsable Sensibilisation

Outils Canva, PowerPoint, Veille ANSSI

Scénarios d'Attaque Étudiés

Nous avons déconstruit 3 attaques majeures pour expliquer leur fonctionnement aux utilisateurs :

1. L'attaque au Président (Fraude au virement)

Vecteur : Ingénierie Sociale (Email urgent du PDG).
Technique : Spoofing d'adresse mail & Pression psychologique.
Parade : Procédure de validation financière stricte et contre-appel.

2. Ransomware via USB (Rubber Ducky)

Vecteur : Clé USB "perdue" sur le parking.
Action : La clé se comporte comme un clavier et tape un script malveillant.
Parade : Désactivation des ports USB & interdiction de brancher des périphériques inconnus.

3. Phishing ciblé (Spear Phishing)

Vecteur : Faux mail Microsoft 365.
Indicateur : Typosquatting (ex: micosoft.com) et sentiment d'urgence.
Parade : MFA (Double facteur) obligatoire.

Bonnes Pratiques : Nos Recommandations

Pour contrer ces menaces, nous avons établi 4 règles d'or (Cliquez sur les cartes pour voir les détails techniques) :

Robustesse

Mots de passe > 12 caractères + Utilisation d'un gestionnaire (Keepass) pour éviter la réutilisation.

Double Facteur

Activation systématique du 2FA (TOTP ou Clé FIDO) sur tous les comptes critiques (Email, VPN, Admin).

Mobilité

Interdiction des Wi-Fi publics sans VPN. Chiffrement du disque dur (BitLocker) en cas de vol.

Résilience

Stratégie de sauvegarde 3-2-1 : 3 copies, 2 supports différents, 1 copie hors ligne (Air-gapped).

Supports de Communication

La technique ne suffit pas : il faut savoir communiquer. J'ai conçu des visuels accrocheurs pour les salles de pause.

Stratégie de Com' :

Utilisation de l'humour et de messages courts pour capter l'attention.

Message clé : "Le pirate ne hacke pas l'ordinateur, il hacke la personne devant."

Apprentissages Critiques BUT R&T validés

Compétences transversales du diplôme travaillées lors de ce projet (2ème année, Niveau 1 → 2).

COMPÉTENCE 3 — Programmer

AC11.02 — Comprendre les fondements des systèmes numériques et des communications
AC13.01 — Utiliser un système informatique et ses outils (Canva, PowerPoint, ANSSI)
AC13.02 — Lire, corriger et modifier un programme / support

COMPÉTENCE 1 — Administrer

AC11.05 — Identifier des dysfonctionnements et savoir les signaler (vecteurs d'attaque)
AC11.06 — Expliquer une procédure mise en place (sensibilisation, bonnes pratiques)
AC21.02 — Expliquer une politique simple de sécurité d'un réseau (2FA, ACL, MFA)

Soft Skills développés

Vulgarisation technique, prise de parole en public, conception de supports visuels — compétences transverses valorisées dans les UE Communication du BUT.

Rétrospective du Projet

Ce que j'ai appris (Hard Skills)

Fonctionnement technique des ransomwares, cryptographie asymétrique (PGP), normes de l'ANSSI.

Soft Skills

Vulgarisation technique, prise de parole en public, design graphique.

Difficulté rencontrée

Le premier jet des affiches et supports était trop dense en texte technique : en le testant sur des camarades non-initiés, le message clé se perdait. J'ai dû accepter de sacrifier de la précision technique au profit de la clarté du message, ce qui n'était pas mon réflexe naturel.

Ce que je referais différemment

Je testerais mes supports auprès d'un public non-technique dès la première version plutôt qu'à la fin, pour itérer plus tôt sur la vulgarisation au lieu de tout refaire en dernière minute.

Vous pouvez télécharger le support complet de la présentation ci-dessous.

Télécharger la Présentation (PDF)

Contexte : CisCorporation

Conception de l'architecture réseau complète pour l'entreprise CisCorporation. Le projet simule un environnement de production incluant le LAN, une DMZ publique, et l'interconnexion via un Backbone OSPF à deux FAI (Orange & SFR).

Objectifs Critiques

Architecture Dual Stack (IPv4 & IPv6) intégrale.
Services : DNS Split-Horizon, Web Intranet/Extranet, Mail.
Administration sécurisée des équipements (SSHv2).
Redondance des liens FAI (Backbone maillé).

Matériel Routeurs Cisco 2911, Switchs 2960

Routage OSPFv3 Multi-Area

Sécurité ACL Étendues, PAT, Port-Security

Topologie Packet Tracer

Segmentation & Adressage

Optimisation de l'espace d'adressage via VLSM pour les sous-réseaux LAN (10.1.0.0/16) et DMZ.

Plan des VLANs (Métiers)

VLAN 10 : Bureau 1 (10.1.0.0/28)
VLAN 30 : Ingénieurs (10.1.0.32/28)
VLAN 100 : Serveurs Internes (10.1.0.72/29)
VLAN 210-230 : RH, SAV, Cadres
VLAN 240 : Wi-Fi Invité (DHCP dédié)

Architecture DMZ

Zone isolée (192.168.1.0/24) hébergeant les services accessibles depuis l'extérieur :

Serveur Web Public (192.168.1.100)
Serveur DNS Public (192.168.1.53)

Architecture Backbone & FAI

Le cœur du réseau repose sur un routage dynamique OSPFv3 Multi-Aires pour simuler un véritable Internet.

Topologie OSPF

Area 0 (Backbone) : Assure le transit haute vitesse entre les routeurs de cœur.
Area 5 (FAI Orange) : Simule le réseau 150.0.0.0/16.
Area 15 (FAI SFR) : Simule le réseau 160.0.0.0/16.
Area 10 (CisCorporation) : Réseau interne de l'entreprise.

Interconnexion

Les routeurs de bordure utilisent une route par défaut redistribuée dans OSPF pour permettre aux employés d'accéder à Internet, tandis que le NAT assure la translation d'adresses privées/publiques.

Configurations Techniques (IOS)

Extraits clés des configurations de routage et de commutation.

! Configuration OSPFv3 sur l'interface WAN
interface GigabitEthernet0/0
 ip address 203.0.113.2 255.255.255.252
 ipv6 address 2001:DB8:ACAD:A::2/64
 ipv6 ospf 1 area 0
 no shutdown

! Processus de routage Global
router ospf 1
 router-id 1.1.1.1
 passive-interface GigabitEthernet0/1 ! Pas de Hello vers le LAN
 default-information originate ! Propager la route par défaut

! Configuration Switch d'Accès
vlan 10
 name BUREAU_1
vlan 100
 name SERVEURS

interface GigabitEthernet0/1
 description UPLINK_VERS_ROUTER
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30,100,210,240

interface FastEthernet0/1
 description PC_EMPLOYE
 switchport mode access
 switchport access vlan 10
 spanning-tree portfast

! NAT Statique (Serveur Web DMZ)
ip nat inside source static tcp 192.168.1.100 80 205.0.113.1 80

! NAT Dynamique (PAT) pour les employés
ip nat pool INTERNET 205.0.113.10 205.0.113.20 netmask 255.255.255.0
ip nat inside source list NAT_LIST pool INTERNET overload

Architecture DNS Split-Horizon

Pour garantir la sécurité et la résolution correcte des noms, nous avons déployé une architecture DNS scindée (Split-Horizon) avec des fichiers de zones distincts.

Serveur : SRV-INT (10.1.0.75) - Accessible uniquement depuis le LAN.

Type	Nom (FQDN)	Valeur (IP Privée)
A	intranet.ciscorp.local	10.1.0.100
A	mail.ciscorp.local	10.1.0.78
A	dns-int.ciscorp.local	10.1.0.75
CNAME	smtp.ciscorp.local	mail.ciscorp.local

Serveur : SRV-PUB (192.168.1.53) - Visible depuis Internet.

Type	Nom (FQDN)	Valeur (IP Publique/NAT)
SOA	ciscorp.com	ns1.ciscorp.com
A	www.ciscorp.com	205.0.113.1 (NAT Static)
MX	ciscorp.com	mail.ciscorp.com (Priorité 10)
AAAA	www.ciscorp.com	2001:DB8:ACAD:B::100

Serveur : ROOT-DNS (.com) - Simule la délégation Internet.

Type	Domaine	Serveur de Noms (NS)
NS	ciscorp.com	ns1.ciscorp.com (205.0.113.1)
NS	orange.com	ns.orange.com (150.0.0.5)
NS	sfr.com	ns.sfr.com (160.0.0.5)

Administration & Sécurité

La sécurité du réseau repose sur le contrôle d'accès strict (ACL) et la gestion chiffrée des équipements.

Accès Distant SSHv2

Abandon de Telnet pour SSH version 2. Génération de clés RSA 1024 bits pour chiffrer les sessions d'administration.

crypto key generate rsa
ip ssh version 2
line vty 0 4
 transport input ssh

Filtrage ACL (Pare-feu)

ACL Étendue "PROTECT_DMZ" :
- Autorise le trafic Web (80/443) et DNS (53) entrant.
- Bloque tout le reste (ICMP, Telnet) provenant de l'extérieur.

Apprentissages Critiques BUT R&T validés

Compétences transversales du diplôme couvertes par ce projet (Niveau 2 — Administrer un réseau).

COMPÉTENCE 1 — Administrer

AC11.03 — Configurer les fonctions de base du réseau local (VLANs, DHCP, trunking)
AC21.01 — Configurer et dépanner le routage dynamique (OSPFv3 Multi-Area)
AC21.02 — Configurer une politique de sécurité : ACL étendues, SSHv2, Port-Security
AC21.04 — Déployer des services réseaux avancés (DNS Split-Horizon, NAT/PAT, Web, Mail)
AC21.05 — Identifier les réseaux opérateurs et l'architecture d'Internet (Backbone FAI, BGP)

COMPÉTENCE 2 — Connecter

AC12.03 — Déployer des supports de transmission (câblage, interfaces WAN/LAN)
AC22.03 — Mettre en place une connexion multi-site via réseau opérateur (FAI Orange & SFR)
AC22.05 — Capacité à questionner un cahier des charges R&T (analyse des besoins CisCorporation)

Point fort académique

Projet noté 18/20 — architecture dual-stack (IPv4 & IPv6) complète avec services opérationnels, démontrant une maîtrise du niveau 2 de la compétence Administrer.

Bilan Technique

Objectifs Atteints

Le LAN accède à Internet (Orange/SFR), le site public est visible mondialement, et l'intranet reste sécurisé et invisible de l'extérieur.

Compétences Clés

Adressage VLSM, OSPF Multi-Area, DNS Split, Sécurisation SSH/ACL, Troubleshooting.

Résultats Académiques

18/20 Livrable Cisco (.pkt)

18/20 Rapport de Projet

Prise de Recul

Ce projet reste noté 18/20, mais avec le recul certains choix auraient pu être affinés.

Difficulté rencontrée

Le premier découpage VLSM était trop rigide : en ajoutant les VLANs RH/SAV/Cadres en cours de projet, j'ai dû retoucher plusieurs plages d'adressage déjà configurées, ce qui a cassé temporairement le routage OSPF sur l'Area 10. J'avais sous-dimensionné la marge de croissance des sous-réseaux dès le départ.

Ce que je referais différemment

Je partirais d'un plan d'adressage avec plus de marge par VLAN dès la conception, et je documenterais le plan IP dans un tableau avant de toucher aux configurations, plutôt que d'ajuster au fur et à mesure. Je testerais aussi mes ACL étendues sur un flux légitime avant de les valider, après avoir bloqué par erreur du trafic DNS interne avec une ACL trop restrictive.

Ressources complètes du projet :

Télécharger le Lab Packet Tracer (.pkt) Consulter le Rapport (PDF)

Contexte : Transmission Numérique Terrestre

Étude complète du réseau TNT de Blois (BUT R&T — SAÉ 3.01), alliant théorie des télécommunications, mesures terrain sur trois types d'antennes et réalisation d'un bilan de liaison complet. Projet réalisé en équipe de 4, noté 16/20 au rapport et 16/20 à la soutenance.

Objectifs du Projet

Comprendre l'architecture et le fonctionnement du réseau TNT (tête de réseau → diffusion → réception).
Maîtriser les normes DVB-T / DVB-S2 et la modulation COFDM / 64-QAM.
Effectuer des mesures terrain (puissance, SNR, constellation) avec un analyseur RANGER HD+.
Réaliser un bilan de liaison complet à 490 MHz et 550 MHz.

Matériel RANGER HD+ (PROMAX), antennes Panneau / Râteau / Yagi

Logiciel MMANA-GAL (simulation antenne)

Site étudié Émetteur TDF Blois — Rue Auguste Poulain (pylône 46 m, 10 W PAR)

Équipe 4 étudiants BUT R&T · S3

Architecture du Réseau TNT

Le réseau TNT se décompose en 4 parties distinctes, chacune utilisant des technologies spécifiques :

1. Tête de Réseau — Encodage & Multiplexage

Les signaux audiovisuels de chaque chaîne sont compressés (MPEG-4 AVC / H.264), puis assemblés dans un multiplexeur DVB pour former le Multiplex TNT. Le codeur canal ajoute de la redondance via le mécanisme FEC (Forward Error Correction) pour corriger les erreurs à la réception.

2. Transmission TNT — Transport vers les sites d'émission

Le Multiplex TNT est acheminé via satellite (norme DVB-S2, bande Ku 10-15 GHz), fibre optique ou faisceaux hertziens. DVB-S2 utilise des modulations APSK / QPSK permettant une haute efficacité spectrale (jusqu'à 5 bits/symbole).

3. Diffusion TNT — Modulation COFDM & bande UHF

Le Multiplex est modulé en COFDM (Coded OFDM) : le canal 8 MHz est divisé en 6 817 sous-porteuses de 1 116 Hz, chacune modulée en 64-QAM (6 bits/symbole). Le signal est transposé en bande UHF (470–694 MHz, canaux 21–48) puis amplifié avant diffusion.

4. Réception TNT — Démodulation & tuner

L'antenne (Yagi/Râteau) convertit l'onde UHF en signal électrique. Une démodulation COFDM reconstruit le Multiplex, et le tuner TNT isole la fréquence de la chaîne souhaitée. Le câble coaxial 75 Ω relie l'antenne au démodulateur.

DVB-TDVB-S2COFDM64-QAMFECMPEG-4 AVC

Étude du Réseau TNT de Blois

Analyse du principal site de diffusion TNT couvrant la ville de Blois :

Caractéristiques de l'émetteur TDF

Opérateur : TDF — Rue Auguste Poulain, 41000 Blois
Pylône : 46 m (auto-stable), mutualisé 2G/3G/4G/5G
Norme : DVB-T (Multiplex) — Système 64-QAM 3/4, mode 8k
Hauteur antennes : 44,5 m à 45 m (6 panneaux, 1 par multiplex)
Fréquences : 470–694 MHz (canaux R1, R2, R4, R6, R7, R9)
Puissance PAR : 10 dBW (10 W) — identique pour tous les multiplex
Intervalle de garde : 1/8 à 1/4 selon le canal

Procédure de mesure

Mesures réalisées sur le toit de l'IUT de Blois avec l'analyseur RANGER HD+ (PROMAX) sur trois antennes :

Antenne Panneau (4 dipôles + réflecteur plan, large ouverture)
Antenne Râteau (Yagi progressif, haute directivité)
Antenne Yagi (gain élevé, lobe principal étroit)

Pour chaque antenne : mesures en bonne direction (vers l'émetteur) et en mauvaise direction (sens opposé) — fréquence 490 MHz, canal 23.

Résultats des Mesures Terrain

Comparatif des 3 antennes — Canal 23 (490 MHz) — Modulation : 64-QAM — Largeur canal : 8 MHz

Antenne	Puissance (dBµV)	SNR (dB)	Direction
Yagi	58,0	34	Bonne
Yagi	45,8	22	Mauvaise
Râteau	52,1	23,3	Bonne
Râteau	43,5	15	Mauvaise
Panneau	48,2	16,1	Bonne
Panneau	39,7	6	Mauvaise

Seuil ANFR (NF EN 60728-1-1)

La tension minimale au démodulateur doit être ≥ 48 dBµV (max 70 dBµV). La Yagi en bonne direction (58 dBµV) offre la meilleure marge. L'antenne Panneau (48,2 dBµV) est à la limite — risque de coupures par mauvais temps. Les diagrammes de constellation observés sur le RANGER confirment ces performances : symboles 64-QAM nets et bien séparés pour la Yagi, chevauchements visibles pour la Panneau en mauvaise direction (ISI).

Bilan de Liaison — Antenne Yagi & Émetteur Blois

Modélisation de l'antenne Yagi sur MMANA-GAL (30 conducteurs) puis calcul du bilan de liaison en espace libre sur 5 km :

Bilan à 490 MHz

Pr : 58 dBµV → −50,75 dBm
Gr : 8,55 dBi · Ge : 13,6 dBi
FSPL : 100,22 dB
Pe calculée : 0,53 W

Bilan à 550 MHz

Pr : 58 dBµV → −50,75 dBm
Gr : 9,5 dBi · Ge : 13,6 dBi
FSPL : 101,22 dB
Pe calculée : 0,55 W

Cohérence avec l'émetteur réel (10 W TDF)

Nos calculs donnent ~0,53 W pour 5 km en espace libre. L'émetteur réel émet 10 W pour compenser obstacles, réflexions et couvrir bien au-delà de 5 km — cohérence validée.

Rétrospective du Projet

Hard Skills acquis

Architecture réseau TNT bout-en-bout, normes DVB-T/DVB-S2, modulation COFDM/64-QAM, FEC, utilisation du RANGER HD+, diagramme de constellation, bilan de liaison FSPL, simulation antenne MMANA-GAL.

Soft Skills

Travail en équipe de 4, rédaction technique (rapport 51 pages), présentation orale (soutenance), rigueur expérimentale, lien théorie/pratique.

Résultats Académiques

16/20 Rapport écrit

16/20 Soutenance orale

Compétences BUT R&T validées

AC31.01 — Maîtriser les technologies de transmissions hertziennes (TNT, DVB-T, COFDM)
AC31.02 — Utiliser des instruments de mesure professionnels (RANGER HD+)
AC31.03 — Réaliser un bilan de liaison et interpréter les résultats
AC31.04 — Modéliser et simuler un système d'antenne (MMANA-GAL)

Prise de Recul

Un projet en équipe de 4, avec ses ajustements en cours de route.

Difficulté rencontrée

Nos premières mesures avec l'antenne Panneau en mauvaise direction donnaient un SNR incohérent avec la théorie : nous avions mal orienté l'analyseur RANGER HD+ lors du calibrage initial, ce qui a faussé une partie de la première série de relevés et nous a obligés à refaire une session de mesures sur le toit de l'IUT.

Ce que je referais différemment

Je vérifierais systématiquement un point de mesure de référence connu avant de lancer une campagne complète, plutôt que de découvrir l'erreur de calibrage après coup. Côté équipe, je répartirais aussi plus tôt les rôles entre mesures terrain, simulation MMANA-GAL et rédaction, pour éviter le goulot d'étranglement qu'on a eu en fin de rapport.

Consulter le Rapport (PDF)

Genèse du Projet

À l'IUT, les étudiants perdent du temps à chercher une salle libre pour travailler en groupe. J'ai développé une application Python qui centralise les emplois du temps (.ICS) et affiche en temps réel les salles disponibles.

Stack Technique V1

Backend : Python 3.11 + Flask
Parsing : Bibliothèque icalendar
Frontend : HTML/CSS/JS (Responsive)

Durée V1 2 semaines (temps perso)

Statut actuel V1 archivée → refonte SaaS (V2) en développement

GitHub Voir le repo V1

V1 — Architecture Technique Initiale

Le cœur du système reposait sur un pipeline simple : lire le planning officiel de l'ENT (.ICS), le transformer en statut de salle exploitable, puis le servir au front en temps réel.

Source ICS (ADE) Planning officiel de l'ENT, exposé en URL .ics par salle

Parsing Python Bibliothèque icalendar : extraction DTSTART / DTEND / LOCATION

Traitement & Cache Calcul du statut de salle + cache mémoire (TTL 60s)

API Flask Routes REST qui exposent l'état des salles au front

Frontend Templates Jinja2 + Bootstrap, affichage en temps réel

Pourquoi Flask ?

Un micro-framework volontairement léger : pas de couches inutiles, un contrôle total sur le routage et la logique métier, idéal pour une application interne à faible charge.

Pourquoi icalendar ?

La bibliothèque de référence pour parser le format iCalendar (.ics) en Python : lecture fiable des événements ADE sans réinventer le parseur.

Un choix d'architecture assumé (V1)

Le cache était volontairement gardé en mémoire (dict Python) plutôt que sur un système externe type Redis : plus simple à maintenir pour un seul serveur à faible trafic, au prix d'une contrainte — un seul worker Gunicorn pour éviter les incohérences de cache entre processus.

Le Pivot : Pourquoi une Architecture SaaS B2B

Une fois la V1 concrétisée, j'ai réalisé que le problème résolu pour l'IUT existait aussi, sous une forme différente, dans n'importe quelle entreprise gérant des salles de réunion.

La limite de la V1

Un outil mono-établissement, pensé pour parser des fichiers .ICS publics de l'ENT — une architecture qui ne tenait pas la route pour plusieurs entreprises clientes : pas d'isolation des données, pas de facturation, pas de connexion aux outils qu'utilisent réellement les entreprises (Outlook, Teams).

L'ambition V2

Transformer un outil interne en véritable produit SaaS B2B multi-tenant : chaque entreprise cliente avec ses données isolées, son abonnement, sa synchronisation Microsoft 365 et son authentification d'entreprise (SSO).

Pourquoi ce choix

Au-delà de l'aspect technique, c'est un projet que je voulais mener comme un vrai produit, de bout en bout — architecture, sécurité, facturation, intégrations entreprise — pour me confronter aux problématiques d'un SaaS professionnel, dans la continuité de mon projet d'école d'ingénieur en réseaux et cybersécurité.

V2 — Nouvelle Architecture SaaS

Refonte complète pour supporter plusieurs entreprises clientes (tenants) de façon isolée, sécurisée et déployable en conteneurs.

Multi-tenant PostgreSQL

Un schéma PostgreSQL dédié par entreprise cliente (schema-per-tenant) : isolation forte des données entre clients, avec un routage par sous-domaine pour identifier le tenant à chaque requête.

Conteneurisation Docker Compose

Déploiement en plusieurs conteneurs : Flask/Gunicorn pour l'application, PostgreSQL pour les données, Nginx en reverse proxy, et un conteneur dédié aux sauvegardes automatisées.

Outillage d'industrialisation

Scripts CLI dédiés (onboard_tenant.py, seed_demo.py) pour provisionner un nouveau client en quelques commandes, plus un assistant d'inscription (onboarding wizard) multi-étapes côté interface.

Authentification & sessions

Gestion des comptes et des sessions via Flask-Login, avec une isolation stricte des droits par tenant.

V2 — Intégrations Entreprise

Le produit se connecte directement aux outils déjà utilisés par les entreprises clientes, au lieu de leur imposer un nouveau silo.

Facturation Stripe

Gestion des abonnements par entreprise cliente, avec traitement des webhooks Stripe (paiement réussi, échec, annulation) pour synchroniser automatiquement l'accès au service avec l'état de l'abonnement.

Microsoft 365 / Outlook / Teams

Synchronisation des réservations de salles avec les calendriers Outlook et Teams des entreprises clientes. Passage en cours d'un polling toutes les 15 minutes à des webhooks Microsoft Graph API, pour des mises à jour quasi temps réel.

SSO Azure AD (SAML 2.0)

Authentification unique par entreprise via Azure AD, en SAML 2.0, réservée aux clients du plan Entreprise. Les secrets de connexion Microsoft 365 sont chiffrés en base (Fernet) plutôt que stockés en clair.

V2 — Aperçu de la Nouvelle Interface

Captures de la version actuelle, en développement actif.

Interface principale Salle Dispo V2 - liste des salles

Liste des salles disponibles

Page détaillée d'une salle Salle Dispo V2

Détail d'une salle

Fonctionnalités Clés

Multi-Entreprise

Chaque client dispose de son espace isolé, avec ses propres salles et utilisateurs

Sync Outlook / Teams

Réservations reflétées automatiquement dans les calendriers Microsoft 365

Facturation en Self-Service

Abonnement, changement de plan et paiement gérés via Stripe

SSO Entreprise

Connexion via Azure AD (SAML 2.0) pour les comptes du plan Entreprise

Mode Affichage

Interface dédiée pour écrans TV à l'entrée des salles

Onboarding Automatisé

Un nouveau client est provisionné en quelques minutes via l'assistant d'inscription

Détection de disponibilité

Le statut d'une salle combine désormais les réservations internes à l'application et les événements synchronisés depuis Outlook/Teams via Microsoft Graph, pour refléter la disponibilité réelle côté entreprise — et non plus uniquement un fichier .ICS externe comme en V1.

Défis Techniques Rencontrés

Trois problèmes concrets posés par le passage à une architecture SaaS multi-tenant.

Isolation des données entre entreprises

Avec un schéma PostgreSQL par tenant, il faut garantir qu'aucune requête ne puisse accidentellement traverser les frontières entre deux entreprises clientes. Chaque connexion à la base est explicitement liée au schéma du tenant identifié via le sous-domaine, avant toute exécution de requête.

Fiabilité de la synchronisation Microsoft 365

Les webhooks Microsoft Graph ont une durée de vie limitée et doivent être renouvelés régulièrement, sans quoi la synchronisation s'arrête silencieusement. L'application doit détecter un abonnement expiré et le renouveler automatiquement, avec un repli sur un polling ponctuel en cas d'échec.

Sécurité des paiements et des secrets

Chaque webhook Stripe est vérifié par signature pour éviter les appels falsifiés, et les secrets de connexion Microsoft 365 (tokens, identifiants d'application) sont chiffrés en base avec Fernet plutôt que stockés en clair — en plus du hashage bcrypt des mots de passe et du rate limiting anti-brute-force hérités de la V1.

Ce que ce projet dit de moi

Un projet né d'un vrai problème, poussé jusqu'à une refonte SaaS complète — hors cadre scolaire, sur temps personnel.

Vision Produit & Ambition

Capacité à faire évoluer un outil interne en produit SaaS B2B complet : multi-tenant, facturation, intégrations entreprise — pas juste un exercice technique, une vraie démarche produit.

Initiative & Autonomie

J'ai identifié seul un problème quotidien à l'IUT, défini le périmètre, choisi la stack et livré une solution fonctionnelle — sans cahier des charges, sans encadrement.

Développement Full-Stack & Cloud

Backend Python/Flask, PostgreSQL multi-tenant, conteneurisation Docker, intégrations tierces (Stripe, Microsoft Graph, Azure AD) — maîtrise de bout en bout d'une architecture SaaS.

Culture Open-Source

Code V1 publié sur GitHub avec documentation — démarche de partage, de lisibilité et de versioning dès le début du projet.

Apprentissages Critiques BUT R&T mobilisés

Bien que réalisé hors cadre scolaire, ce projet personnel mobilise directement plusieurs compétences du référentiel BUT R&T.

COMPÉTENCE 3 — Programmer

AC13.01 — Utiliser un environnement de développement (VS Code, Git, environnement virtuel Python)
AC23.01 — Développer des applications communicantes (API Flask, routes REST, Stripe, Microsoft Graph)
AC23.02 — Structurer les données et les bases de données (modélisation multi-tenant PostgreSQL)

COMPÉTENCE 1 — Administrer

AC21.03 — Sécuriser une application (chiffrement Fernet, hashage bcrypt, SSO SAML, rate limiting)
AC21.04 — Déployer des services réseaux avancés (conteneurs Docker, reverse proxy Nginx)

Extrait de Code (Parsing ICS — V1)

from icalendar import Calendar
from datetime import datetime

def get_available_rooms(ics_url):
    cal = Calendar.from_ical(requests.get(ics_url).text)
    now = datetime.now()
    
    busy_rooms = []
    for event in cal.walk('vevent'):
        if event['dtstart'].dt <= now <= event['dtend'].dt:
            busy_rooms.append(event['location'])
    
    return [room for room in ALL_ROOMS if room not in busy_rooms]

1. Récupération des fichiers .ICS (URL ADE)
2. Parsing des événements (VEVENT)
3. Extraction : DTSTART, DTEND, LOCATION
4. Comparaison avec l'heure actuelle
5. Filtrage : Salles libres = Toutes - Occupées
6. Affichage avec tri par capacité

Finaliser les webhooks Microsoft Graph

Remplacer complètement le polling 15 minutes par des notifications temps réel pour la synchronisation Outlook/Teams.

Finaliser le parcours d'abonnement Stripe

Gestion complète des plans, essais gratuits et changements d'abonnement en self-service pour les entreprises clientes.

Premier client pilote

Recruter une première entreprise pour tester le produit en conditions réelles et itérer sur les retours.

Prise de Recul

Le pivot vers une architecture SaaS n'a pas été une simple évolution technique.

Difficulté rencontrée

J'ai sous-estimé la complexité de migrer d'un modèle single-tenant vers un modèle multi-tenant : sur des tenants déjà provisionnés, l'ajout de nouvelles fonctionnalités provoquait des dérives de schéma (schema drift) entre bases, et j'ai dû gérer l'ordre des contraintes de clés étrangères pour éviter que les migrations échouent. J'ai aussi buté sur un nom de colonne (promotion) qui entrait en conflit avec un mot-clé réservé selon le contexte SQL, ce qui m'a obligé à renommer le concept en entite dans tout le code.

Ce que je referais différemment

Je mettrais en place un système de migrations de schéma versionnées dès le début de la V2, plutôt que d'appliquer des changements manuels tenant par tenant. Et je choisirais mes noms de colonnes/tables en anticipant les mots réservés SQL avant de coder, pas après avoir buté dessus.

Voir sur GitHub

Contexte & Objectif

Gus&Co est une marque de vêtements indépendante qui avait besoin d'une présence en ligne professionnelle, avec un lancement rapide exigé par le client. L'objectif n'était pas de construire une plateforme complexe, mais de donner à la marque une visibilité simple, crédible et rapide. J'ai pris en charge l'intégralité du projet : développement du site, hébergement et configuration DNS.

Ce que j'ai géré

Développement web — HTML / CSS / JavaScript
Hébergement — Configuration serveur & déploiement
DNS — Enregistrements A, CNAME, MX, TTL
SSL — Certificat HTTPS (Let's Encrypt)

Type Site vitrine & boutique

Objectif Visibilité rapide de la marque

URL gus-and-co.com

Statut ● En ligne

Du Besoin Client au Cahier des Charges

Avant même de parler technique, il a fallu traduire une demande client simple — « être visible en ligne, vite » — en choix concrets. C'est cette contrainte de délai qui a piloté toutes les décisions techniques du projet.

Contrainte principale : le délai

Le client voulait un lancement rapide, sans temps de développement long ni cycle de validation complexe. Chaque choix technique devait servir cet objectif de rapidité, sans sacrifier la fiabilité du site final.

Le choix d'une stack légère

Plutôt qu'un CMS lourd (type WordPress) — installation, thèmes, plugins, maintenance, failles de sécurité potentielles — j'ai opté pour du HTML / CSS / JS codé sur mesure : plus rapide à livrer, plus léger à héberger, sans dépendance externe à maintenir.

Le compromis assumé

Une stack sur mesure demande plus de code à écrire au départ qu'un CMS pré-configuré, mais élimine tout le temps perdu en configuration, mises à jour et compatibilité de plugins — un choix cohérent avec l'objectif de rapidité du client, quitte à sacrifier certaines fonctionnalités « clé en main » d'un CMS.

Stack Technique & Infrastructure

Un projet de A à Z : du code jusqu'à la mise en production, tout a été géré de façon autonome.

Développement Web

HTML / CSS / JS — site responsive, optimisé mobile & desktop

Hébergement

Configuration du serveur, déploiement des fichiers, gestion des accès

Serveur DNS

Zone DNS complète : enregistrements A, CNAME, MX, propagation & TTL

SSL / HTTPS

Certificat Let's Encrypt — connexion sécurisée en production

Ce que ce projet m'a apporté

Première expérience complète avec un vrai client
Maîtrise de la chaîne complète : code → serveur → DNS → production
Gestion de projet en conditions réelles (délais, communication)

Zoom Technique : La Configuration DNS

Ce n'est pas un « défi » à proprement parler, mais une étape technique déterminante : c'est le DNS qui relie le nom de domaine gus-and-co.com au serveur qui héberge réellement le site.

Enregistrement	Rôle	Exemple
A	Pointe le domaine vers l'adresse IP du serveur	gus-and-co.com → IP serveur
CNAME	Fait pointer un sous-domaine vers un autre nom de domaine	www → gus-and-co.com
MX	Route les e-mails du domaine vers le bon serveur mail	[email protected]
TTL	Durée de mise en cache d'un enregistrement par les résolveurs DNS	3600s (1h)

La propagation, un délai à anticiper

Une modification DNS n'est pas instantanée : elle se propage progressivement sur les résolveurs du monde entier, en fonction du TTL défini. Il faut donc planifier ce délai en amont d'un lancement, et non le découvrir le jour J.

Une étape souvent sous-estimée

Un enregistrement mal configuré peut rendre le site inaccessible pendant plusieurs heures, ou casser la réception des e-mails du domaine (MX) sans lien apparent avec le site lui-même — d'où l'importance de la rigueur sur ce point, invisible pour le client mais critique pour lui.

Ce que ce projet dit de moi

Un projet livré à un vrai client, en production, avec de vraies contraintes — pas un exercice, une mission.

Relation client

Comprendre le besoin d'un client non-technique, reformuler, proposer, ajuster — toute la réalité d'une prestation en conditions professionnelles.

Mise en production réelle

Code, hébergement, DNS, SSL, déploiement — une chaîne complète maîtrisée de bout en bout, avec un site actuellement en ligne et utilisé.

Gestion de projet autonome

Délais, priorisation, communication — gestion solo d'un projet de A à Z, du brief initial à la livraison finale, sans encadrement pédagogique.

Polyvalence technique

Développement front-end, infrastructure serveur, configuration réseau (DNS/SSL) — capacité à couvrir plusieurs domaines sur un même projet.

Apprentissages Critiques BUT R&T mobilisés

Un projet client réel qui recoupe directement plusieurs compétences du référentiel BUT R&T.

COMPÉTENCE 2 — Connecter

AC12.01 — Mettre en œuvre les protocoles applicatifs (DNS, HTTP/HTTPS, SSL/TLS)

COMPÉTENCE 3 — Programmer

AC13.01 — Développer une application web (HTML/CSS/JS responsive codé sur mesure)

Compétence transverse

Questionner un cahier des charges client, reformuler un besoin non-technique en solution concrète et respecter des délais de livraison courts.

Résultats & Aperçu Visuel

Un site livré vite, et qui a rempli son objectif : donner de la visibilité à la marque dès son lancement.

~30 Ventes au premier lancement

1,5k Visiteurs uniques sur un mois

100% Retour client positif

Le site est toujours en ligne aujourd'hui. Quelques captures du site livré, actuellement en production sur gus-and-co.com.

Menu de navigation

Menu

Zone d'achat

Visiter le site

Prise de Recul

Une première mission client réelle, avec ses vrais ajustements.

Difficulté rencontrée

J'ai sous-estimé le délai de propagation DNS au moment du lancement : le site était en ligne côté serveur mais restait inaccessible pour une partie des visiteurs pendant plusieurs heures le jour du lancement, faute d'avoir anticipé et communiqué ce délai au client en amont.

Ce que je referais différemment

Je planifierais la bascule DNS plusieurs jours avant la date de lancement officielle plutôt que le jour même, et j'expliquerais ce délai de propagation au client dès le début du projet pour éviter toute incompréhension le jour J.

À propos

Mon Profil

Projets Pro & Perso

Découvrir l'Hygiène Informatique

Concevoir un Réseau d'Entreprise

Étude d'une Transmission TNT

Site Marque Indépendante

Salle Dispo - Projet Personnel

DartVoice - Projet Personnel

Parcours

Alternant Ingénieur Avant-Vente

BUT Réseaux & Télécommunications parcours Cybersécurité

Baccalauréat Général

Certifications

CCNA1 : Intro to Networks

Bases du réseautage

Network Technician Career Path

Introduction to Cybersecurity

Digital Safety & Security

SecNum Académie (ANSSI)

MOOC CNIL — RGPD

Certification PIX

Compétences

Réseaux

Télécoms

Fibre Optique

Python

HTML / CSS

Linux / Bash

Bases de Données

Cybersécurité

Contact