Projet 1
Projet 1 : Messagerie temps réel (B2B)
Pondération : 25 % de la note annuelle · Remise : 02/11/2026 à 23h59 (lien GitHub + rapport PDF dans le devoir Teams) · Présentation orale au premier cours après les congés d'automne
1. Objectif & périmètre
Vous allez construire une application de chat temps réel pour équipes (B2B) — pensez Slack, Teams ou Discord, version professionnelle. Ce n'est pas un exercice jetable : vous allez le concevoir, le déployer en production dès les premières semaines, et le faire vivre comme un vrai produit, landing page et pricing compris.
MVP obligatoire
- Conversations privées (1:1) et de groupe
- Temps réel : envoi/réception sans rechargement de page
- Notifications en temps réel (in-app au minimum : badge, toast, compteur de non-lus)
- Authentification + permissions basiques (qui a accès à quelle conversation)
- Interface responsive
En plus de ce socle, des fonctionnalités optionnelles au choix sont fortement valorisées : co-édition de documents, base de connaissances, stockage de fichiers, chatbots, recherche plein texte… ou votre propre idée. Une optionnelle bien intégrée vaut mieux que trois optionnelles bâclées.
2. Livrables
À la remise, vous fournissez une URL de production publique fonctionnelle, votre repo GitHub (public de préférence) et deux documents : le rapport de projet au format PDF et un carnet métacognitif IA par membre (templates fournis pour les deux). La présentation orale devant la classe a lieu au cours suivant la remise.
Le rapport couvre notamment : les acteurs du système (rôles, permissions, interactions), le MVP et les exigences non fonctionnelles, le choix de la stack technique et sa justification, le schéma d'architecture, le diagramme de classes UML, la présentation de l'application avec captures d'écran, et l'explication du CI/CD et du déploiement.
⚠️ Éliminatoire
- Noms de tous les membres du groupe sur le rapport, sinon 0.
- Rapport au format PDF, sinon 0.
3. Organisation d'équipe & Git
Vous travaillez en groupes de 2 (fortement recommandé — les groupes de 3 restent à la discrétion du professeur), idéalement avec des rôles tournants : lead technique, référent QA, référent déploiement.
Côté Git, on applique le GitHub Flow : une branche feature/<nom> par fonctionnalité, une Pull Request revue par un pair, puis merge. main = production : chaque merge déclenche un déploiement. Un chapitre GitHub Flow est fourni si vous voulez apprendre à collaborer sans vous marcher sur les pieds.
Une exigence chiffrée : au moins 1 PR significative par personne et par semaine — substantielle (pas une micro-PR), avec des étapes de test claires.
4. Contraintes techniques
- Backend : langage interprété uniquement (PHP, Python, JavaScript/TypeScript, Ruby…)
- Un framework backend et un framework frontend
- Stack validée par le professeur avant la première ligne de code
- Secrets via variables d'environnement — jamais dans le repo
Le choix de l'hébergement guide le choix de la stack, pas l'inverse. Gardez vos exigences fonctionnelles en tête au moment de choisir : il vous faut de la persistance des données et du temps réel (WebSockets ou équivalent) — tous les hébergeurs ne s'y prêtent pas.
5. CI/CD (mis en place dès le cours 2)
Votre pipeline vérifie chaque PR (lint + build, tests s'ils existent) et déploie automatiquement à chaque merge sur main, avec un statut de build et des logs accessibles. On démarre avec cette base au deuxième cours, puis on enrichira le pipeline au fil de l'année.
6. Page marketing & pricing
Votre produit est un SaaS B2B : il lui faut une vitrine. Prévoyez une landing page publique qui vend les bénéfices du produit (captures animées recommandées), un pricing d'au moins 2 paliers (ex. Free / Pro) avec des quotas — messages, pièces jointes, membres, rétention… — et un CTA clair : « Essayer maintenant ».
7. Qualité & sécurité (socle)
Le lint est systématique et le formatage homogène. Des tests sur le cœur du système (envoi/lecture de message, droits d'accès) sont attendus si possible. Les entrées utilisateur sont validées et échappées, les origines CORS strictes.
Soignez particulièrement l'expérience d'erreur : messages d'erreur clairs dans tous les formulaires, gestion propre des exceptions, et messages compréhensibles pour prévenir l'utilisateur quand quelque chose se passe mal — jamais de stack trace à l'écran.
8. Déroulé du premier cours
- Présentation du cours
- Présentation du Projet 1
- Formation des groupes
- Activité : recherche de solutions d'hébergement — par groupe, puis mise en commun en classe ; le choix de la stack découle de vos trouvailles
- Début du cahier des charges fonctionnel et non fonctionnel
9. Planning indicatif (7 semaines de cours)
| Sem. | Séance | En parallèle, votre projet |
|---|---|---|
| S1 | Présentation, groupes, activité hébergement, CDC v0 | Choix stack + hébergeur à faire valider |
| S2 | Théorie : CI/CD | Squelette du projet, auth basique, premier déploiement |
| S3 | Revue d'avancement n°1 (rapport + démo) | DB conversations/messages, chat 1:1 temps réel |
| S4 | Théorie | Chat de groupe, memberships, permissions |
| S5 | Revue d'avancement n°2 (rapport + démo) | Notifications temps réel, stabilisation |
| S6 | Théorie | Landing + pricing, fonctionnalités optionnelles |
| S7 | Revue d'avancement n°3 + derniers conseils | Finitions, rapport PDF, démo fluide en prod |
| Congés | 2 semaines pour finaliser → remise le 02/11 à 23h59 | + préparation de la présentation orale |
| Rentrée | Présentations orales devant la classe |
10. Revue d'avancement — mode d'emploi
Toutes les deux semaines, votre groupe dépose un rapport d'avancement (fonctionnalités implémentées + captures d'écran) dans le devoir Teams avant la séance, puis le présente en live : démo en production, un point fort, un point faible, et l'objectif pour la quinzaine suivante. Vous repartez avec le feedback et les conseils du professeur.
11. Présentation orale — un pitch business
Vous ne présentez pas un exercice scolaire, vous présentez votre produit. Le jour J, devant la classe :
- description des fonctionnalités — et surtout pourquoi elles existent (quel besoin utilisateur ?)
- démo en live, en production
- justification des choix techniques : stack, hébergement, architecture, temps réel
- support visuel soigné, propos structuré, gestion du temps
La qualité de la présentation (support et expression orale) fait partie de l'évaluation. C'est votre entraînement pour la défense du TFE.