📅 Année universitaire : 2026–2027
🏫 École : ESPRIT, École d’Ingénieurs
🎓 Public : 4e année, Cycle Ingénieur en Informatique, Génie Logiciel
🏷️ Code du module : MT-41
🏢 Unité pédagogique : UP WEB
Ce dépôt regroupe les ressources pédagogiques et techniques du module Applications Web Distribuées.
Le module accompagne progressivement les étudiants dans l’étude, la conception, la réalisation, la documentation, la sécurisation et le déploiement d’applications Web distribuées.
Le parcours commence par l’analyse d’une application monolithique, puis introduit les API REST, la décomposition en Microservices, la découverte de services, l’API Gateway, les communications synchrones et asynchrones, la sécurité et la conteneurisation.
La progression pédagogique suit le fil conducteur suivant :
Monolithe MVC
↓
API REST et documentation OpenAPI
↓
Décomposition en Microservices
↓
Service Discovery et observabilité
↓
API Gateway
↓
Communication synchrone et asynchrone
↓
Sécurité distribuée
↓
Conteneurisation et déploiement Cloud Native
Le module vise à former des ingénieurs capables de :
- comprendre l’évolution des architectures logicielles ;
- analyser les besoins métier et les contraintes techniques ;
- comparer plusieurs styles architecturaux ;
- concevoir des contrats d’API cohérents ;
- décomposer une application selon ses capacités métier ;
- mettre en œuvre les mécanismes nécessaires à une architecture distribuée ;
- documenter, tester, sécuriser et déployer une solution ;
- justifier les choix technologiques et architecturaux réalisés.
À l’issue du module, l’étudiant sera capable de :
- AA1 : Expliquer l’évolution des architectures logicielles jusqu’aux architectures distribuées modernes.
- AA2 : Comparer et analyser les architectures monolithique, SOA et Microservices selon les besoins métier et les contraintes techniques.
- AA3 : Analyser les besoins métier conduisant à l’adoption d’une architecture distribuée.
- AA4 : Expliquer les principes fondamentaux d’une architecture Microservices.
- AA5 : Évaluer les avantages, les limites et les défis des architectures Microservices.
- AA6 : Sélectionner les outils et technologies adaptés à la conception et au déploiement d’une architecture distribuée.
- AA7 : Appliquer les principes de l’architecture Microservices dans un environnement distribué.
- AA8 : Concevoir, implémenter, déployer et valider une application distribuée orientée Cloud Native.
Le module adopte une approche active, progressive et centrée sur la mise en situation de l’étudiant.
Le projet JobBoard constitue le fil rouge du module. Chaque chapitre introduit une nouvelle problématique architecturale et fait évoluer le même système.
Les étudiants suivent un cycle complet d’ingénierie :
Concevoir → Développer → Implémenter → Opérer
Les notions théoriques sont mobilisées dans des ateliers pratiques, des Prosits, des activités d’analyse et des livrables techniques.
Les étudiants participent à :
- des études de cas ;
- des diagnostics architecturaux ;
- des activités individuelles et collectives ;
- des discussions argumentées ;
- des recherches guidées ;
- des démonstrations ;
- des revues et validations intermédiaires.
L’utilisation d’outils d’intelligence artificielle peut être autorisée selon les consignes de chaque activité.
Les étudiants restent responsables :
- du code remis ;
- des choix techniques ;
- des tests réalisés ;
- des corrections apportées ;
- de la compréhension des éléments générés ;
- de la traçabilité des prompts lorsque celle-ci est demandée.
L’IA doit soutenir l’analyse et la production, sans remplacer la réflexion de l’étudiant.
Chaque séquence peut combiner les étapes suivantes :
- Cours : concepts, fondements et patterns ;
- Atelier : mise en œuvre sur le projet fil rouge ;
- Prosit : analyse d’une situation-problème ;
- Réflexion : recul critique, comparaison et justification ;
- Livrable : code, documentation, diagrammes, dépôt Git ou démonstration.
JobBoard est une plateforme pédagogique de recrutement utilisée pour illustrer la transformation progressive d’une application Web.
Le domaine couvre notamment :
- les candidats ;
- les entreprises et les recruteurs ;
- les offres d’emploi ;
- les candidatures ;
- les entretiens ;
- les notifications.
- analyse d’un monolithe MVC existant ;
- diagnostic architectural ;
- exposition d’API REST ;
- documentation OpenAPI et Swagger ;
- décomposition en services métier ;
- ajout du Service Discovery et de l’observabilité ;
- mise en place de l’API Gateway ;
- communication interservices ;
- sécurisation ;
- conteneurisation et déploiement reproductible.
Candidate Service
Company Service
Job Service
Application Service
Meeting Service
Notification Service
- évolution des architectures logicielles ;
- architecture monolithique ;
- architecture N-tiers ;
- SOA et services Web ;
- principes des systèmes distribués ;
- diagnostic architectural de JobBoard.
- principes REST ;
- ressources et URI ;
- méthodes HTTP ;
- codes de statut ;
- JSON ;
- OpenAPI et Swagger ;
- conception, documentation et test d’API.
- principes Microservices ;
- décomposition métier ;
- bounded contexts ;
- autonomie des services ;
- déploiement indépendant ;
- communication interservices.
- découverte de services ;
- enregistrement et heartbeat ;
- registre de services ;
- health, info et metrics ;
- observabilité d’une architecture distribuée.
- validation de la conception ;
- architecture proposée ;
- diagrammes ;
- organisation Git ;
- documentation ;
- démonstration du projet.
- point d’entrée unique ;
- routage ;
- load balancing ;
- centralisation des préoccupations transverses ;
- documentation des accès.
- appels interservices ;
- contrats ;
- gestion des erreurs ;
- délais d’attente ;
- résilience.
- événements métier ;
- broker de messages ;
- découplage temporel ;
- cas d’usage asynchrones ;
- cohérence éventuelle.
- identité ;
- authentification ;
- autorisation ;
- rôles ;
- tokens ;
- protection des endpoints.
- images et conteneurs ;
- configuration des services ;
- composition multi-conteneurs ;
- déploiement reproductible ;
- transition vers le Cloud Native.
Le module n’impose pas un stack backend unique pour tous les ateliers et projets.
Selon les consignes de l’activité, les étudiants peuvent choisir une technologie appropriée, par exemple :
- Symfony et PHP ;
- Node.js avec Express ou NestJS ;
- Django REST Framework ou FastAPI ;
- Spring Boot ;
- .NET Web API ;
- une technologie équivalente, pertinente et justifiée.
Quel que soit le stack retenu, les productions doivent respecter les exigences communes du module :
- contrat REST cohérent ;
- URI orientées ressources ;
- méthodes HTTP adaptées ;
- statuts HTTP explicites ;
- validation des entrées ;
- réponses JSON structurées ;
- gestion des erreurs ;
- documentation OpenAPI et Swagger ;
- scénarios de test reproductibles ;
- instructions d’installation et d’exécution ;
- justification des choix techniques.
- un environnement de développement adapté au stack choisi ;
- le runtime et le gestionnaire de dépendances associés ;
- Git ;
- un compte GitHub ou GitLab.
- Swagger UI et OpenAPI ;
- Postman ;
- Insomnia ;
- curl ;
- tests automatisés selon le framework choisi.
- diagrams.net ;
- Mermaid ;
- PlantUML ;
- un outil équivalent de modélisation.
- Docker ;
- Docker Compose ;
- une base de données adaptée au projet ;
- des outils de développement local propres au stack sélectionné.
La note finale du module est répartie comme suit :
| Composante | Pondération | Éléments évalués |
|---|---|---|
| Projet | 40 % | Architecture, réalisation, documentation, tests, Git, démonstration et justification des choix |
| Contrôle continu | 20 % | Cours notés, Prosits, ateliers, quiz et livrables intermédiaires |
| Examen théorique | 40 % | Compréhension des concepts, analyse architecturale et justification technique |
Note finale = 0,40 × Projet + 0,20 × Contrôle continu + 0,40 × Examen théorique
Les productions sont évaluées selon les critères pertinents pour l’activité :
- compréhension du problème ;
- cohérence de l’architecture ;
- qualité du contrat d’API ;
- exactitude technique ;
- fonctionnement de la solution ;
- gestion des erreurs ;
- qualité des tests ;
- qualité de la documentation ;
- reproductibilité ;
- lisibilité du code et des diagrammes ;
- justification des choix ;
- recul critique ;
- contribution au travail d’équipe ;
- usage responsable de l’intelligence artificielle.
Dr Badia Bouhdid
PhD en Informatique, IT Assistant Professor, UP WEB
📧 badiaa.bouhdid@esprit.tn
Le module Applications Web Distribuées est dispensé à l’École d’Ingénieurs ESPRIT.
- Site officiel ESPRIT
- Profil LinkedIn de l’enseignante
- Chaîne YouTube
- Publications Medium
- Profil ResearchGate
Ne commencez pas par choisir une technologie. Commencez par comprendre le besoin, identifier les contraintes, définir les qualités attendues et concevoir un contrat clair.
Une architecture distribuée ne constitue pas une solution universelle. Elle apporte de l’autonomie, de la flexibilité et des possibilités de déploiement indépendant, mais introduit aussi de nouvelles responsabilités liées au réseau, aux pannes partielles, à la cohérence des données, à la sécurité, à l’observabilité et à l’exploitation.
Bon apprentissage et bon développement du projet JobBoard !