EIA - Gabarit de rapport technique

Gabarit Document de reference Guide de redaction

---

Apercu du rapport

Votre rapport technique est un PDF de 5 a 8 pages qui documente l'ensemble de votre projet EIA. Il doit etre redige de sorte qu'un lecteur technique qui n'a jamais vu votre projet puisse comprendre votre approche, reproduire vos resultats et evaluer vos decisions.

Voir la structure du rapport

Directives de mise en forme

Aspect	Exigence
Longueur	5-8 pages (excluant les references et annexes)
Format	PDF
Police	11-12pt, police lisible (ex. : Calibri, Arial, Times New Roman)
Marges	2,5 cm (1 pouce) de chaque cote
Interligne	1,15 ou 1,5
Figures	Numerotees et avec legende (ex. : « Figure 1 : Comparaison des modeles »)
Tableaux	Numerotes et avec legende (ex. : « Tableau 1 : Metriques d'evaluation »)
Code	Utiliser une police a espacement fixe, code minimal (uniquement les extraits cles)
Langue	Francais ou anglais (coherent tout au long)

Limite de pages

Ne depassez pas 8 pages pour le corps principal. Le rapport doit etre concis et cible. Les annexes (graphiques supplementaires, code complet, captures d'ecran Postman) ne comptent pas dans la limite de pages.

---

Section 1 : Resume executif

Longueur : 0,5 page

Le resume executif est redige en dernier mais apparait en premier. Il fournit un apercu de haut niveau de l'ensemble du projet en un seul paragraphe ou une courte section.

Ce qu'il faut inclure

• Le probleme que vous avez resolu
• Le jeu de donnees utilise
• Le meilleur modele et sa metrique cle
• Le framework API utilise
• Un resultat cle d'explicabilite
• La conclusion principale

Gabarit

Ce rapport presente le developpement et le deploiement d'[un service predictif pour VOTRE PROBLeME] en utilisant le jeu de donnees [nom du jeu de donnees]. Apres avoir compare [Modele A] et [Modele B], le [meilleur modele] a ete selectionne avec un [metrique principale] de [valeur]. Le modele est servi via une API REST [FastAPI/Flask] avec [nombre] endpoints, validee par [nombre] tests automatises atteignant [X] % de couverture de code. L'analyse d'explicabilite utilisant [LIME/SHAP] a revele que [resultat cle, par ex. : « les frais mensuels et le type de contrat sont les predicteurs les plus forts de l'attrition client »]. Le systeme complet est documente, teste et pret pour le deploiement.

Exemple — Projet d'attrition client

Ce rapport presente le developpement et le deploiement d'un service predictif pour l'attrition client en utilisant le jeu de donnees Telco Customer Churn (7 043 echantillons, 20 caracteristiques). Apres avoir compare la regression logistique, Random Forest et XGBoost, le classificateur XGBoost a ete selectionne avec un AUC-ROC de 0,87 et un F1-score de 0,63. Le modele est servi via une API REST FastAPI avec 3 endpoints (/predict, /health, /model-info), validee par 14 tests automatises atteignant 82 % de couverture de code. L'analyse SHAP a revele que les contrats mensuels, les frais mensuels eleves et la faible anciennete sont les predicteurs les plus forts de l'attrition. Le systeme complet est documente, teste et pret pour le deploiement.

---

Section 2 : Definition du probleme

Longueur : 1 page

2.1 Contexte metier

Expliquez pourquoi ce probleme est important. Qui beneficierait de ce service de prediction ? Quelle decision metier soutient-il ?

Gabarit

Contexte metier : [Decrivez le probleme reel et son impact]

Utilisateur final : [Qui utiliserait ce service ? Comment ?]

Valeur metier : [Quelle decision ce modele aide-t-il a prendre ? Quel cout permet-il d'economiser ?]

2.2 Description du jeu de donnees

Fournissez une description factuelle du jeu de donnees.

Attribut	Valeur
Nom	[Nom du jeu de donnees]
Source	[URL ou reference]
echantillons	[Nombre de lignes]
Caracteristiques	[Nombre de caracteristiques]
Variable cible	[Nom et type]
Distribution des classes	[par ex. : 73 % Pas d'attrition, 27 % Attrition]
Valeurs manquantes	[Description]

Incluez 1-2 visualisations EDA cles :

• Distribution de la cible (diagramme a barres ou diagramme circulaire)
• Carte de chaleur des correlations ou distributions des principales caracteristiques

2.3 Objectifs du projet

enoncez vos objectifs sous forme de buts mesurables :

1. Entrainer et comparer au moins [N] modeles pour [type de probleme]
2. Atteindre un [metrique principale] > [seuil]
3. Construire une API REST avec [framework] servant des predictions avec < [N] ms de latence
4. Atteindre une couverture de tests > 70 %
5. Fournir une analyse d'explicabilite utilisant [LIME/SHAP]

---

Section 3 : Methodologie

Longueur : 1 a 1,5 pages

3.1 Pretraitement des donnees

Documentez chaque transformation appliquee aux donnees :

etape	Action	Justification
Valeurs manquantes	[par ex. : Imputees avec la mediane]	[par ex. : Seulement 11 lignes affectees, la mediane preserve la distribution]
Encodage	[par ex. : Encodage one-hot pour les categorielles]	[par ex. : Requis pour les modeles a base d'arbres]
Mise a l'echelle	[par ex. : StandardScaler sur les caracteristiques numeriques]	[par ex. : Requis pour la regression logistique]
Selection de caracteristiques	[par ex. : Suppression de customer_id]	[par ex. : Pas une caracteristique predictive]
Separation train/test	[par ex. : 80/20 avec stratification]	[par ex. : Preserve la distribution des classes]

3.2 Selection du modele

Expliquez pourquoi vous avez choisi ces modeles specifiques :

Modele	Pourquoi selectionne
[Modele A]	[par ex. : Reference de base simple, interpretable, rapide a entrainer]
[Modele B]	[par ex. : Gere les relations non lineaires, bon pour les donnees tabulaires]
[Modele C (si applicable)]	[par ex. : etat de l'art pour les donnees structurees, gradient boosting]

3.3 Ajustement des hyperparametres

Documentez votre strategie d'ajustement :

Modele	Methode	Parametres ajustes	Meilleures valeurs
[Modele A]	[GridSearch / RandomizedSearch]	[par ex. : C, penalty]	[par ex. : C=0.1, penalty=l2]
[Modele B]	[GridSearch / RandomizedSearch]	[par ex. : n_estimators, max_depth]	[par ex. : n_estimators=200, max_depth=10]

3.4 Strategie d'evaluation

• Methode de validation : [par ex. : Validation croisee a 5 plis]
• Metrique principale : [par ex. : AUC-ROC — parce que le jeu de donnees est desequilibre]
• Metriques secondaires : [par ex. : F1-Score, Precision, Recall]

---

Section 4 : Resultats

Longueur : 1 a 1,5 pages

4.1 Comparaison des modeles

Presentez un tableau comparatif clair :

Modele	Accuracy	Precision	Recall	F1-Score	AUC-ROC
[Modele A]	[valeur]	[valeur]	[valeur]	[valeur]	[valeur]
[Modele B]	[valeur]	[valeur]	[valeur]	[valeur]	[valeur]
[Meilleur modele]	[valeur]	[valeur]	[valeur]	[valeur]	[valeur]

4.2 Matrice de confusion

Incluez la matrice de confusion pour votre meilleur modele :

	Predit negatif	Predit positif
Reel negatif	[VN]	[FP]
Reel positif	[FN]	[VP]

Interpretez les resultats :

• Faux positifs : [Que signifie un faux positif dans votre contexte ?]
• Faux negatifs : [Que signifie un faux negatif ? Lequel est plus couteux ?]

4.3 Selection du meilleur modele

Le [meilleur modele] a ete selectionne parce que [justification basee sur les metriques ET le contexte metier]. Bien que [Modele A] ait obtenu [leger avantage sur une metrique], [meilleur modele] offre [meilleure performance sur la metrique principale / meilleur compromis / temps d'inference plus court].

4.4 Visualisations cles

Incluez :

• Courbe ROC comparant tous les modeles (pour la classification)
• Diagramme de dispersion reel vs. predit (pour la regression)
• Courbes d'apprentissage (optionnel mais precieux)

---

Section 5 : Conception de l'API

Longueur : 1 page

5.1 Architecture

Decrivez l'architecture globale de l'API :

5.2 Endpoints

Endpoint	Methode	Description	Codes de statut
/health	GET	Verification de la sante du service	200
/predict	POST	Prediction unique	200, 400, 422, 500
/model-info	GET	Metadonnees du modele	200

5.3 Exemples de requete/reponse

Pour chaque endpoint, fournissez un exemple de requete et de reponse (vous pouvez referencer votre documentation Swagger).

5.4 Gestion des erreurs

Type d'erreur	Code HTTP	Exemple
Erreur de validation	422	Champ requis manquant
Mauvaise requete	400	JSON malforme
Erreur serveur	500	echec de la prediction du modele

5.5 Decisions de conception

Expliquez les decisions cles :

• Pourquoi vous avez choisi [FastAPI/Flask]
• Comment le modele est charge (au demarrage vs. par requete)
• Comment fonctionne la validation des entrees

---

Section 6 : Strategie de tests

Longueur : 0,5 page

6.1 Plan de tests

Categorie de tests	Nombre	Outils
Tests unitaires	[N]	pytest
Tests d'integration	[N]	pytest + TestClient/httpx
Tests de cas limites	[N]	pytest
Tests API	[N]	Postman
Total	[N]

6.2 Couverture de code

Module	Instructions	Couvertes	Couverture
src/app.py	[N]	[N]	[X] %
src/model.py	[N]	[N]	[X] %
src/schemas.py	[N]	[N]	[X] %
Total	[N]	[N]	[X] %

6.3 Resultats de tests cles

Mentionnez tout cas limite notable que vous avez decouvert et comment vous l'avez gere.

6.4 Collection Postman

Referencez la collection Postman exportee (incluez une capture d'ecran d'une execution de test reussie dans l'annexe).

---

Section 7 : Explicabilite du modele

Longueur : 1 page

7.1 Methodologie

• Outil(s) utilise(s) : [LIME / SHAP / Les deux]
• Nombre d'explications generees : [N predictions individuelles expliquees]
• Visualisations produites : [Listez-les]

7.2 Importance globale des caracteristiques

Incluez votre graphique de synthese SHAP ou l'importance globale des caracteristiques LIME et interpretez-le :

Les 3 caracteristiques les plus importantes sont :

1. [Caracteristique A] — [interpretation]
2. [Caracteristique B] — [interpretation]
3. [Caracteristique C] — [interpretation]

7.3 Explications de predictions individuelles

Montrez 1-2 explications LIME ou SHAP pour des predictions specifiques :

Exemple 1 : Pour un client avec [caracteristiques], le modele a predit [prediction] avec [confiance] %. Les principaux facteurs contributifs etaient [facteurs].

7.4 Perspectives et biais potentiels

• Les caracteristiques importantes sont-elles attendues ? Ont-elles un sens dans le domaine ?
• Y a-t-il des caracteristiques qui ne devraient PAS influencer la prediction ? (par ex., attributs sensibles)
• Qu'est-ce qui vous a surpris dans le comportement du modele ?

Rediger des interpretations efficaces

Ne vous contentez pas de decrire les graphiques — expliquez ce qu'ils signifient pour le metier ou l'utilisateur final. Exemple : « Le modele s'appuie fortement sur l'anciennete (mois en tant que client), ce qui a du sens metier puisque les nouveaux clients ont eu moins de temps pour developper leur fidelite. »

---

Section 8 : Architecture de deploiement

Longueur : 0,5 page

8.1 Comment executer le service

Fournissez des instructions etape par etape (abregees — les instructions completes sont dans le README) :

# 1. Clone the repository
git clone https://github.com/username/lia-project.git

# 2. Create virtual environment
python -m venv venv
source venv/bin/activate  # or venv\Scripts\activate on Windows

# 3. Install dependencies
pip install -r requirements.txt

# 4. Start the API
uvicorn src.app:app --host 0.0.0.0 --port 8000

8.2 Docker (si applicable)

FROM python:3.10-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["uvicorn", "src.app:app", "--host", "0.0.0.0", "--port", "8000"]

8.3 Environnement

Composante	Version
Python	[version]
Framework	[version FastAPI/Flask]
scikit-learn	[version]
SE	[par ex. : Windows 11 / Ubuntu 22.04]

---

Section 9 : Conclusion et travaux futurs

Longueur : 0,5 page

9.1 Resume

Recapitulez les realisations cles :

Ce projet demontre avec succes [realisation principale]. Le [modele] atteint [metrique] sur [jeu de donnees], et est servi via une API [framework] avec [N] endpoints, [N] tests et [X] % de couverture de code. L'analyse d'explicabilite utilisant [outil] a fourni [perspective cle].

9.2 Lecons apprises

Listez 2-3 lecons importantes :

1. [par ex. : « Le pretraitement des donnees a pris plus de temps que prevu — 60 % du temps du projet a ete consacre au nettoyage des donnees »]
2. [par ex. : « ecrire les tests en premier (TDD) aurait economise du temps de debogage par la suite »]
3. [par ex. : « SHAP a revele que mon modele s'appuyait sur une caracteristique que je n'avais pas anticipee »]

9.3 Ameliorations futures

Suggerez 2-3 ameliorations realistes :

1. [par ex. : « Implementer un pipeline CI/CD avec GitHub Actions »]
2. [par ex. : « Ajouter la surveillance du modele pour detecter la derive des donnees en production »]
3. [par ex. : « Tester des modeles d'apprentissage profond pour comparaison »]

---

Section 10 : References

Utilisez un format de citation coherent (APA, IEEE ou numerote). Incluez :

• Source et documentation du jeu de donnees
• Documentation des frameworks (FastAPI, Flask, scikit-learn)
• Articles ou documentation LIME/SHAP
• Tout materiel de cours reference
• Tout outil IA utilise (avec une breve description de l'utilisation)

Exemples de references

[1] T. Chen and C. Guestrin, "XGBoost: A Scalable Tree Boosting System," in Proc. KDD, 2016.

[2] S. Lundberg and S.-I. Lee, "A Unified Approach to Interpreting Model Predictions," in NeurIPS, 2017.

[3] M. Ribeiro, S. Singh, and C. Guestrin, ""Why Should I Trust You?": Explaining the Predictions of Any Classifier," in Proc. KDD, 2016.

[4] FastAPI Documentation, https://fastapi.tiangolo.com/

[5] Telco Customer Churn Dataset, Kaggle, https://www.kaggle.com/datasets/blastchar/telco-customer-churn

---

Annexes (non comptees dans la limite de pages)

Incluez du materiel de soutien supplementaire :

Annexe	Contenu
A	Visualisations EDA supplementaires
B	Matrice de confusion complete et rapport de classification
C	Captures d'ecran d'execution de tests Postman
D	Visualisations LIME/SHAP supplementaires
E	Rapport complet de couverture de code (export HTML ou capture d'ecran)

---

Liste de verification de qualite pour votre rapport

Avant de soumettre, verifiez :

• Le resume executif couvre tous les points majeurs
• Le probleme est clairement defini avec des objectifs mesurables
• Toutes les etapes de pretraitement sont documentees et justifiees
• Le tableau de comparaison des modeles est complet avec ≥ 3 metriques
• La matrice de confusion est presente et interpretee
• Les endpoints API sont documentes avec des exemples
• La couverture de tests est rapportee avec des chiffres
• La section d'explicabilite contient ≥ 3 visualisations avec interpretations
• La conclusion inclut les lecons apprises et les travaux futurs
• Les references sont completes et formatees de maniere coherente
• Toutes les figures et tableaux sont numerotes et avec legende
• Le rapport fait 5-8 pages (ni plus, ni moins)
• Pas de fautes d'orthographe ou de grammaire
• Format PDF, correctement mis en forme

Declaration d'utilisation d'IA

Si vous avez utilise des outils IA (ChatGPT, Copilot, etc.) pendant votre projet, vous devez le declarer dans votre rapport. Ajoutez une breve section avant les references expliquant quels outils vous avez utilises et comment. Exemple : « GitHub Copilot a ete utilise pour la generation de code passe-partout. ChatGPT a ete consulte pour le debogage de messages d'erreur. Tout le code genere a ete revise, teste et adapte. »