AeroManager
Plateforme web institutionnelle
Vols, hôtels, transports, emploi et appels d’offres, réunis dans une seule plateforme pour l’Office National Des Aéroports.
- Organisation
- ONDA · Office National Des Aéroports
- Rôle
- Stagiaire développement logiciel · Seul développeur
- Période
- Juillet – août 2025 · 1 mois
Un projet de stage, et non le site public de l’ONDA. Les écrans et données internes ne sont pas présentés ici.
- Interfaces
- 11
- Écrans développés en tant que seul développeur, sur les cinq domaines de la plateforme.
- Cas d’utilisation
- 20
- Identifiés lors de l’analyse UML. Chacun est couvert par le contrôle d’accès par rôles.
- Niveaux d’accès
- 3
- Niveaux de permissions qui définissent ce que chaque type d’utilisateur peut voir et faire.
- Aéroports couverts
- 25
- Les aéroports couverts par la plateforme.
01 Contexte
Pendant un stage d’un mois en développement logiciel à l’ONDA, l’Office National Des Aéroports, j’ai été le seul développeur d’AeroManager, une plateforme web institutionnelle conçue pour l’Office.
02 Problème
Cinq domaines métier, plusieurs types d’utilisateurs et une seule plateforme partagée : chaque écran devait présenter des données claires, et chaque action les bonnes permissions.
03 Architecture
01Client
SPA React
Vite
02API
API REST Flask
Vols · Hôtels · Transports · Emploi · Appels d’offres
03Sécurité
JWT + accès par rôles
Sessions sans état
04ORM
SQLAlchemy
05Données
MySQL
04 Ma contribution
Seul développeur : l’analyse UML complète, l’architecture découplée, toutes les interfaces, l’API REST, l’authentification JWT sans état, le contrôle d’accès par rôles et le tableau de bord d’administration.
05 Choix techniques
- 01
Un front et un back découplés
Une application monopage React (Vite) consomme une API REST Flask : l’interface et la logique métier évoluent indépendamment.
- 02
Une authentification sans état
Les jetons JWT portent la session : l’API ne conserve aucun état de session côté serveur.
- 03
Un accès par rôles sur chaque cas d’utilisation
Les règles d’accès sont définies par rôle et appliquées à chaque cas d’utilisation identifié lors de l’analyse UML.
- 04
Un seul modèle relationnel
SQLAlchemy relie les cinq domaines métier à MySQL.
06 Résultats
- Cinq domaines métier servis par une seule API REST
- Chaque cas d’utilisation contrôlé selon le rôle de l’utilisateur
- Tableau de bord d’administration et analyse UML complète livrés
07 Stack
- React
- Vite
- Flask
- SQLAlchemy
- MySQL
- JWT
- UML
08 Code source
Le code source n’est pas public : il a été écrit pendant un stage et reste privé. D’autres projets sont sur GitHub.
Vous construisez quelque chose de similaire ?
Lancer un projet