EIA - Guide de presentation orale
Apercu de la presentation
Votre presentation orale vaut 15 % de votre note d'EIA. Vous disposez de 15 minutes pour presenter votre projet, suivies de 5 minutes de questions de l'enseignant. C'est votre opportunite de demontrer non seulement que votre systeme fonctionne, mais que vous comprenez chaque decision que vous avez prise.
Voir le deroulement de la presentation
Allocation du temps
Respectez cette repartition du temps. S'exercer avec un chronometre est essentiel.
| # | Section | Duree | Diapositives | Contenu cle |
|---|---|---|---|---|
| 1 | Titre et introduction | 1 min | 1-2 | Nom du projet, enonce du probleme, votre nom |
| 2 | Probleme et jeu de donnees | 1 min | 1 | Contexte metier, statistiques du jeu de donnees, objectifs |
| 3 | Entrainement du modele et resultats | 3 min | 2-3 | Points saillants de l'EDA, modeles compares, tableau de metriques, justification du meilleur modele |
| 4 | Architecture de l'API | 2 min | 1-2 | Endpoints, validation, gestion des erreurs, choix du framework |
| 5 | Demo en direct | 3 min | 0 (en direct) | Verification de sante, prediction valide, entree invalide, model-info |
| 6 | Tests | 1,5 min | 1 | Resume des tests, couverture %, points saillants Postman |
| 7 | Explicabilite | 1,5 min | 1-2 | Visualisations SHAP/LIME, perspectives cles |
| 8 | Conclusion et lecons | 2 min | 1-2 | Resume, lecons apprises, ce que vous amelioreriez |
| Total presentation | 15 min | 10-14 | ||
| 9 | Questions | 5 min | 0 | Repondre aux questions de l'enseignant |
Depasser 18 minutes ou rester en dessous de 12 minutes vous coutera des points. Exercez-vous avec un chronometre. Si vous etes en retard, reduisez les details de l'entrainement du modele — la demo et l'explicabilite sont plus impressionnantes.
Guide diapositive par diapositive
Diapositive 1 : Diapositive de titre
| element | Contenu |
|---|---|
| Titre | Le nom de votre projet (par ex. : « API de prediction d'attrition client ») |
| Sous-titre | EIA — Deploiement de modeles IA |
| Votre nom | Prenom et nom de famille |
| Date | Date de la presentation |
| Cours | Code et nom du cours |
Commencez fort. Votre diapositive de titre doit etre propre, sans encombrement. enoncez le nom de votre projet et passez directement au probleme. Ne perdez pas de temps avec « Merci d'etre ici » ou « Aujourd'hui, je vais presenter... » — l'auditoire sait pourquoi vous etes la.
Diapositive 2 : Probleme et contexte (1 min)
Contenu a inclure :
- Quel probleme votre modele resout-il ?
- Qui beneficie de cette prediction ?
- Pourquoi est-ce important ? (valeur metier)
- Jeu de donnees : nom, taille, source (1-2 points)
Exemple :
« Les entreprises de telecommunications perdent des millions annuellement a cause de l'attrition client. Ce projet predit quels clients sont susceptibles de partir, permettant des campagnes de retention proactives. J'ai utilise le jeu de donnees Telco Customer Churn — 7 043 clients avec 20 caracteristiques. »
Diapositives 3-4 : Entrainement du modele (3 min)
Contenu a inclure :
- 1-2 perspectives cles de l'EDA (montrez un graphique, pas un mur de texte)
- Modeles compares (tableau avec metriques)
- Meilleur modele et pourquoi vous l'avez choisi
- Un resultat interessant de l'entrainement
| Modele | Accuracy | F1-Score | AUC-ROC |
|---|---|---|---|
| Regression logistique | 0,80 | 0,56 | 0,84 |
| Random Forest | 0,79 | 0,54 | 0,83 |
| XGBoost | 0,81 | 0,63 | 0,87 |
« J'ai selectionne XGBoost parce qu'il a le meilleur AUC-ROC (0,87) et F1-Score (0,63), ce qui compte plus que l'accuracy pour ce jeu de donnees desequilibre. »
Diapositive 5 : Architecture de l'API (2 min)
Contenu a inclure :
- Choix du framework et justification
- Tableau des endpoints (restez simple)
- Un exemple de requete/reponse
- Comment fonctionnent la validation et la gestion des erreurs
Voir l'architecture de l'API
Diapositives 6-7 : Demo en direct (3 min)
C'est la partie la plus percutante de votre presentation. Montrez votre API fonctionnant en temps reel.
Sequence de demonstration (ordre recommande) :
| # | Action | Ce qu'il faut montrer | Resultat attendu |
|---|---|---|---|
| 1 | GET /health | L'API fonctionne | [ "status": "healthy" ] |
| 2 | GET /model-info | Metadonnees du modele | Nom du modele, version, metriques |
| 3 | POST /predict (valide) | Prediction reelle | Prediction + confiance |
| 4 | POST /predict (invalide) | Gestion des erreurs | 422 avec message d'erreur de validation |
| 5 | GET /docs | Interface Swagger | Documentation API interactive |
- Pre-demarrez votre API avant le debut de la presentation. Ne perdez pas 30 secondes a executer
uvicorn. - Utilisez l'interface Swagger (
/docs) pour la demo — c'est visuel et impressionnant. - Preparez vos requetes a l'avance (onglets de navigateur en favoris ou formulaires Swagger pre-remplis).
- Ayez un plan de secours : Si la demo echoue, montrez des captures d'ecran ou une video pre-enregistree.
Testez votre demo sur l'ordinateur de presentation avant de presenter. echecs courants :
- Port deja utilise (changez de port)
- Dependances manquantes (utilisez
requirements.txt) - Fichier de modele introuvable (verifiez les chemins relatifs)
- Pare-feu bloquant les connexions
Diapositive 8 : Tests (1,5 min)
Contenu a inclure :
- Nombre de tests et types de tests
- Pourcentage de couverture
- Une capture d'ecran Postman (optionnel)
- Un cas limite interessant que vous avez decouvert
Exemple :
« J'ai ecrit 14 tests automatises — 5 tests unitaires, 6 tests d'integration et 3 tests de cas limites. La couverture de code est de 82 %. J'ai decouvert que l'envoi de valeurs negatives pour
tenurecausait une erreur non geree, ce qui m'a amene a ajouter une validation de plage d'entree. »
Diapositives 9-10 : Explicabilite (1,5 min)
Contenu a inclure :
- Methode utilisee (LIME, SHAP ou les deux)
- Un graphique d'importance globale des caracteristiques (le graphique de synthese SHAP est ideal)
- Une explication de prediction individuelle
- Perspective cle en langage simple
Exemple de narration :
« En utilisant SHAP, j'ai constate que les trois caracteristiques les plus importantes sont : le type de contrat, les frais mensuels et l'anciennete. Les clients avec un contrat mensuel ont 3x plus de chances de partir. Voici un graphique en cascade pour un client a haut risque specifique — vous pouvez voir que sa courte anciennete et ses frais mensuels eleves poussent fortement la prediction vers l'attrition. »
Diapositives 11-12 : Conclusion (2 min)
Contenu a inclure :
- Resume des realisations (3-4 points)
- 2-3 lecons apprises (soyez honnete et reflechi(e))
- 2-3 ameliorations futures
- Mot de la fin
Exemple de conclusion :
« En resume, j'ai construit un service de prediction IA complet — de l'exploration des donnees a une API deployee, testee et explicable. Lecons cles : la qualite des donnees compte plus que la complexite du modele, et ecrire les tests tot fait gagner du temps. Si j'avais plus de temps, j'ajouterais un deploiement Docker et une surveillance avec Prometheus. »
Gerer la periode de questions (5 minutes)
La periode de questions teste si vous comprenez veritablement votre projet. L'enseignant posera 3-5 questions.
Questions courantes a preparer
Banque de questions detaillee
Questions sur l'entrainement du modele
| Question | Ce qu'on evalue |
|---|---|
| Pourquoi avez-vous choisi [modele] plutot que [autre modele] ? | Pouvez-vous justifier vos decisions avec des metriques et un raisonnement ? |
| Comment avez-vous gere le desequilibre des classes ? | Connaissez-vous des techniques comme SMOTE, les poids de classe ? |
| Que se passerait-il si vous utilisiez plus/moins de caracteristiques ? | Comprenez-vous la selection de caracteristiques ? |
| Votre modele est-il en surapprentissage ? Comment le savez-vous ? | Pouvez-vous interpreter la performance train vs test ? |
| Pourquoi avez-vous utilise [metrique] comme metrique principale ? | Comprenez-vous les compromis entre metriques ? |
| Qu'est-ce que la validation croisee et l'avez-vous utilisee ? | Comprenez-vous la methodologie d'evaluation ? |
| Comment re-entraineriez-vous le modele avec de nouvelles donnees ? | Pensez-vous au cycle de vie en production ? |
Questions sur la conception de l'API
| Question | Ce qu'on evalue |
|---|---|
| Pourquoi FastAPI plutot que Flask (ou vice versa) ? | Pouvez-vous comparer les frameworks ? |
| Comment et quand le modele est-il charge ? | Comprenez-vous le chargement au demarrage vs. par requete ? |
| Que se passe-t-il si le fichier du modele est manquant ? | Gerez-vous les cas limites ? |
| Comment fonctionne la validation Pydantic ? | Comprenez-vous votre couche de validation ? |
| Quel code de statut HTTP pour [scenario] ? | Connaissez-vous les conventions REST ? |
| Comment gereriez-vous les requetes concurrentes ? | Comprenez-vous la concurrence ? |
| Comment ajouteriez-vous l'authentification ? | Pensez-vous a la securite ? |
Questions sur les tests
| Question | Ce qu'on evalue |
|---|---|
| Quelle est la difference entre tests unitaires et tests d'integration ? | Comprenez-vous les types de tests ? |
| Que signifie 70 % de couverture de code ? | Comprenez-vous les metriques de couverture ? |
| 100 % de couverture est-il toujours l'objectif ? | Comprenez-vous les limites des tests ? |
| Qu'est-ce qu'un fixture de test dans pytest ? | Comprenez-vous votre framework de test ? |
| Comment avez-vous teste la gestion des erreurs ? | Avez-vous teste les scenarios d'echec ? |
| Qu'est-ce que les tests Postman verifient que pytest ne fait pas ? | Comprenez-vous les tests complementaires ? |
Questions sur l'explicabilite
| Question | Ce qu'on evalue |
|---|---|
| Quelle est la difference entre LIME et SHAP ? | Comprenez-vous les deux methodes ? |
| Que represente une valeur SHAP ? | Pouvez-vous expliquer les mathematiques simplement ? |
| Avez-vous trouve une importance de caracteristique inattendue ? | Avez-vous reflechi de maniere critique aux resultats ? |
| Pourrait-il y avoir une fuite de donnees dans vos caracteristiques ? | Comprenez-vous ce concept critique ? |
| Votre modele est-il equitable ? Comment le verifieriez-vous ? | Pensez-vous aux biais et a l'ethique ? |
| Quelles sont les limites de votre analyse d'explicabilite ? | Comprenez-vous les limites des methodes ? |
Strategie pour les questions
| a faire | a ne pas faire |
|---|---|
| ecouter la question en entier avant de repondre | Interrompre le questionneur |
| Dire « C'est une excellente question » pour gagner du temps de reflexion | Dire « Je ne sais pas » et s'arreter la |
| Admettre si vous ne savez pas, puis emettre une hypothese | Inventer une reponse dont vous n'etes pas sur(e) |
| Relier les reponses a votre projet specifique | Donner des reponses generiques de manuel |
| etre concis(e) — 30-60 secondes par reponse | Divaguer pendant 3 minutes |
C'est normal de ne pas tout savoir. Une reponse solide est : « Je n'ai pas explore cela specifiquement, mais en me basant sur ce que je sais de [concept connexe], j'aborderais cela en [hypothese]. » Cela montre une pensee critique meme lorsque vous manquez de connaissances specifiques.
Conseils de design pour la presentation
Regles de design des diapositives
| Regle | Bon | Mauvais |
|---|---|---|
| Texte par diapositive | 4-6 points, mots cles | Paragraphes entiers copies du rapport |
| Taille de police | ≥ 24pt pour le corps, ≥ 32pt pour les titres | Texte en 12pt que personne ne peut lire |
| Visualisations | Graphiques, diagrammes, captures d'ecran | Murs de texte |
| Couleurs | Palette coherente, contraste lisible | Couleurs arc-en-ciel, texte clair sur fond clair |
| Code dans les diapositives | Extraits courts (5-10 lignes max) | Fichiers sources complets |
| Animations | Aucune ou minimale | Texte volant et transitions tournoyantes |
Strategie de contenu
Pensez a votre presentation comme une histoire, pas un rapport :
- Accroche — Pourquoi l'auditoire devrait-il s'interesser ? (Introduction)
- Defi — Qu'est-ce qui etait difficile ? (Entrainement, problemes de donnees)
- Solution — Comment l'avez-vous resolu ? (API, tests)
- Preuve — Est-ce que ca fonctionne ? (Demo, explicabilite)
- Reflexion — Qu'avez-vous appris ? (Conclusion)
Ce qu'il ne faut PAS faire
Anti-modeles de presentation
| Anti-modele | Pourquoi c'est mauvais | Que faire a la place |
|---|---|---|
| Lire ses diapositives | Montre que vous ne maitrisez pas le sujet | Utilisez les diapositives comme aide-memoire, parlez naturellement |
| Montrer tout votre code | Ennuyeux, impossible a lire | Montrez 1-2 extraits cles, demontrez le reste |
| Sauter la demo | La demo represente 20 % de l'impression | Faites toujours une demo, meme brievement |
| Pas de contact visuel | Semble peu confiant(e) | Regardez l'auditoire, pas l'ecran |
| S'excuser (« Desole, je sais que ce n'est pas parfait ») | Devalorise votre travail | Presentez avec confiance, mentionnez les ameliorations dans les travaux futurs |
| Depasser le temps | Irrespectueux, perte de points | Exercez-vous avec un chronometre |
| Coder en direct pendant la demo | Trop risque, perte de temps | Ayez tout en marche avant de commencer |
| Jargon inexplique | Perd l'auditoire | Definissez brievement les termes si necessaire |
| Pas de plan de secours | Les echecs de demo sont devastateurs | Ayez des captures d'ecran ou une video pretes |
| Remercier tout le monde au debut | Perd 30 secondes | Commencez par l'enonce du probleme |
Liste de verification de preparation
Une semaine avant
- Le diaporama est complet (10-14 diapositives)
- Toutes les visualisations et graphiques sont inclus
- Le script de demo est redige (ce que vous montrerez, dans quel ordre)
- Premiere repetition effectuee (verifier le minutage)
Trois jours avant
- Repetition #2 avec chronometre (visez 14-15 minutes)
- Questions de la periode de questions revisees et reponses preparees
- Demo testee sur l'ordinateur de presentation (ou configuration similaire)
- Captures d'ecran de secours sauvegardees dans les diapositives (en cas d'echec de la demo)
La veille
- Repetition finale (idealement devant quelqu'un)
- API testee et fonctionnelle
- Diaporama exporte en PDF (format de secours)
- Tous les fichiers sur cle USB ou stockage cloud accessible
Le jour meme
- Arriver tot, installer l'equipement
- Demarrer votre API avant le debut de la presentation
- Ouvrir l'interface Swagger dans un onglet de navigateur
- Ouvrir votre diaporama
- Prendre une grande respiration — vous vous etes bien prepare(e)
Grille d'evaluation — Presentation orale
| Critere | Ponderation | Excellent (14-15) | Bon (12-13) | Satisfaisant (11) | Insuffisant (< 11) |
|---|---|---|---|---|---|
| Completude du contenu | 25 % | Toutes les composantes couvertes : modele, API, tests, explicabilite | La plupart des composantes couvertes | Certaines composantes manquantes | Composantes majeures manquantes |
| Profondeur technique | 20 % | Comprehension approfondie, justifie toutes les decisions | Bonne comprehension, la plupart des decisions expliquees | Comprehension superficielle | Ne peut pas expliquer les decisions |
| Demo en direct | 20 % | Demo impeccable, plusieurs scenarios montres | La demo fonctionne avec des problemes mineurs | La demo fonctionne partiellement | La demo echoue ou n'est pas tentee |
| Communication | 15 % | Confiant(e), clair(e), bon rythme, engage l'auditoire | Bonne livraison, nervosite mineure | Adequat(e) mais monotone ou precipite(e) | Peu clair, lecture des diapositives |
| Qualite des diapositives | 10 % | Propres, visuelles, informatives, professionnelles | Bon design, problemes mineurs | Acceptables mais trop de texte | Mauvais design, difficiles a lire |
| Performance aux questions | 10 % | Repond a toutes les questions avec confiance | Repond bien a la plupart des questions | Repond a certaines questions | Ne peut pas repondre aux questions de base |
Exemple de plan de presentation
Voici un exemple concret pour un projet de prediction d'attrition client :
| Diapositive | Titre | Contenu |
|---|---|---|
| 1 | API de prediction d'attrition client | Titre, nom, date, cours |
| 2 | Le probleme | « 26 % des clients partent chaque trimestre — perte annuelle de 2 M$ » |
| 3 | Jeu de donnees et EDA | Jeu de donnees Telco, 7 043 echantillons, graphique de distribution des classes |
| 4 | Comparaison des modeles | Tableau : LogReg vs RF vs XGBoost, metriques mises en evidence |
| 5 | Meilleur modele : XGBoost | AUC-ROC=0,87, matrice de confusion, pourquoi XGBoost a gagne |
| 6 | Architecture de l'API | Diagramme : Client → FastAPI → Modele → Reponse |
| 7 | Endpoints et validation | Tableau des endpoints, exemple Pydantic |
| 8-9 | DeMO EN DIRECT | Interface Swagger : /health → /predict → /model-info → cas d'erreur |
| 10 | Resultats des tests | 14 tests, 82 % de couverture, cas limite cle trouve |
| 11 | Analyse SHAP | Graphique de synthese : top 3 des caracteristiques expliquees |
| 12 | Explication individuelle | Graphique en cascade pour un client a haut risque |
| 13 | Conclusion et lecons | Resume, 3 lecons apprises, 2 ameliorations futures |
| 14 | Merci / Questions | Coordonnees, lien vers le depot |