#Ressources — Projet de synthèseCopier le lien

Gabarits, checklists et repères pour mener le projet comme une démarche expérimentale: hypothèse, instrumentation, ligne de base, analyse, rapport reproductible. Les gabarits sont à adapter à votre sujet; l'ordre suit le cycle du module.

#Gabarit READMECopier le lien

Le README d'un projet expérimental documente l'usage et la façon de rejouer les mesures. C'est la première chose qu'un auditeur regarde.

1# Nom du projet2 3Une ligne: le problème traité et l'hypothèse testée.4 5## Objectif6 7Quel problème? Pour qui? Quelle hypothèse falsifiable? Quel critère de succès8mesurable, défini avant l'implémentation?9 10## Prérequis11 12- Python 3.12+ (ou Node 20+)13- Dépendances verrouillées dans `requirements.txt` (ou `package-lock.json`)14 

#Gabarit cahier de cadrageCopier le lien

#1. Question et hypothèseCopier le lien

Question: quel problème, pour qui, quelle valeur apportée?

Hypothèse falsifiable, à remplir avant de coder:

Si [changement], alors [métrique] s'améliore de [ordre de grandeur attendu], mesuré par [protocole], parce que [mécanisme].

Critère de succès: les mesures qui décideront, et le seuil à partir duquel on conclut « confirmé » ou « invalidé ». Écrit avant l'implémentation, pour ne pas choisir la métrique après coup.

#2. ObjectifsCopier le lien

Objectif principal: [Formulation SMART: Spécifique, Mesurable, Atteignable, Réaliste, Temporel]

Objectifs secondaires: [Liste numérotée]

#3. PérimètreCopier le lien

Inclus:

• Fonctionnalité A
• Fonctionnalité B

Explicitement exclus:

• Fonctionnalité C (hors périmètre, candidate pour une suite)

Le MVP est le plus petit sous-ensemble qui permet de mener l'expérience décisive.

#4. Parties prenantesCopier le lien

#5. RisquesCopier le lien

#6. PlanningCopier le lien

#Gabarit d'entrée de journal d'expérienceCopier le lien

Chaque expérience consignée dans docs/journal.md, une entrée par itération:

1## [AAAA-MM-JJ] Expérience 3: [variante testée]2 3- Question: ce que cette expérience doit décider4- Hypothèse: formulation « si... alors... parce que »5- Commit: hash exact du code mesuré6- Protocole: script de mesure, répétitions, échauffement, graine des données7- Environnement: CPU, RAM, OS, versions des dépendances8- Résultats bruts: lien vers results/experience-3.csv9- Verdict: confirmée / invalidée / non concluante, et pourquoi10- Suite: prochaine question, ou limite à documenter

#Gabarit de protocole de mesureCopier le lien

À écrire avant la première série, appliqué à l'identique à la ligne de base et à chaque variante:

1# Protocole de mesure: [métrique visée]2 3- Système mesuré: commit hash, branche4- Métrique: définition exacte (ex: temps de construction de l'index en secondes)5- Données: jeu de référence ou générateur avec graine (`random.seed(42)`), taille6- Échauffement: 3 exécutions non mesurées (caches, JIT, pages mémoire)7- Répétitions: 20 (augmenter si la dispersion dépasse l'effet attendu)8- Conditions: machine décrite (CPU, RAM, disque), au repos, aucune autre charge9- Redressement: aucun; les valeurs aberrantes restent dans les résultats bruts10- Sortie: results/[nom].csv, une ligne par exécution11- Rapport: médiane et quartiles par variante, jamais une mesure unique

#Gabarit de rapport finalCopier le lien

Le rapport suit la structure d'un article scientifique court, telle que décrite dans la phase 6 du module:

1# [Titre: le système et l'hypothèse]2 3## 1. Problème et hypothèse4Ce qu'on affirme, et pourquoi le mécanisme le prédit.5 6## 2. Méthode7Système, instrumentation, protocole, environnement. Assez précis pour être rejoué.8 9## 3. Résultats10Tableaux et graphiques avec médiane et dispersion; données et scripts disponibles.11 12## 4. Analyse13Les chiffres confirment-ils l'hypothèse? Quels cas la contredisent?14 

#ChecklistsCopier le lien

#Avant chaque mergeCopier le lien

• Les tests passent
• Le code a été revu
• La documentation est à jour
• Pas de secret committé
• Le journal d'expérience est à jour si la fusion change les mesures

#Avant de conclure sur une mesureCopier le lien

• La ligne de base a été mesurée avec le même protocole que la variante
• Au moins 5 répétitions par variante (20 si la variance est élevée)
• Médiane et dispersion rapportées, pas seulement la moyenne
• Environnement consigné: CPU, RAM, OS, versions, hash du commit
• Résultats bruts archivés dans results/, jamais retouchés à la main
• Les intervalles se recouvrent-ils? Si oui, verdict « non concluant », pas « amélioré »

#Avant la démoCopier le lien

• La démo tourne sur des données réalistes (générateur seedé)
• Les résultats affichés viennent de results/, pas d'une capture retouchée
• Plan B prêt (vidéo pré-enregistrée, résultats rejouables hors ligne)
• Le résultat négatif éventuel est assumé et expliqué
• Durée répétée (~10 minutes), questions anticipées

#Qualité techniqueCopier le lien

• Lint configuré et sans erreurs
• Tests unitaires et tests d'intégration sur les chemins critiques
• Journal structuré pour les événements importants
• Variables d'environnement documentées
• Environnement figé (requirements.txt, package-lock.json ou image Docker taggée)

#Conseils pratiquesCopier le lien

Découper en MVPs: le plus petit ensemble qui permet l'expérience décisive, pas le plus petit qui fait une jolie démo.

Instrumenter dès le début: les chronomètres, compteurs et journaux greffés après coup coûtent plus cher et mesurent moins bien.

Itérer sur mesures: chaque itération se termine par une entrée de journal et un verdict, sinon elle ne produit que du code.

Assumer l'incertitude: rapportez des médianes avec leur dispersion; un chiffre unique sans contexte n'est qu'une opinion chiffrée.

Préparer la démo: scénario écrit, données seedées, plan B hors ligne.

Rétrospective: ce qui a marché, ce qui a échoué, ce qu'on mesurerait autrement la prochaine fois.

#Outils recommandésCopier le lien

Gestion de projet: GitHub Projects, Trello, Notion

CI/CD: GitHub Actions, GitLab CI

Mesure: time.perf_counter() et module statistics en Python, performance.now() en JavaScript, hyperfine pour comparer des commandes

Analyse: pandas + matplotlib (tables et graphiques depuis results/, générés par script)

Journal d'expérience: un simple docs/journal.md versionné avec le code suffit

Diagrammes: Mermaid, draw.io, Excalidraw