Rapport de stages
Les indications ci-dessous sont tirés intégralement des conseils pour faire un bon mémoire de stage de Pierre David qui est enseignant de le Master CSMI et qui dirige le Master en Informatique SIRIS. |
1. Introduction
Le mémoire est un élément essentiel de votre stage : il a pour but de de présenter, aussi fidèlement que possible, à la fois la portée du stage (organisationnelle et/ou (organisationnel et/ou technique) et votre contribution.
Votre mémoire sera lu par un rapporteur, c’est-à-dire un enseignant de l’équipe pédagogique (donc une personne ayant des compétences dans votre discipline), dont la mission est d’évaluer votre thèse pour comprendre : - le contexte dans lequel vous avez évolué, - votre apport (réalisation technique, travail scientifique) sa pertinence par rapport aux cours du Master.
Il vous est rappelé que le plagiat est puni par la loi, par l’université par l’université et par vos examinateurs : si de courtes citations sont autorisées, vous devez en indiquer la source. |
2. Plan
La section Vérification est obligatoire. Les sections Validation et Quantification d’incertitude sont recommandées si pertinentes pour votre projet — avec justification brève si omises. |
2.1. Missions & Objectifs
Décrivez les missions confiées, les objectifs mesurables, les livrables attendus et les contraintes (techniques, calendrier, données, sécurité). Indiquez votre rôle précis et les parties du travail dont vous êtes responsable.
2.2. Contexte
Présentez brièvement l’organisme et le contexte métier/technique utile à la compréhension du projet (sans recopier le site web). Précisez l’existant (outils, modèles, jeux de données, pipeline) et les choix imposés.
2.3. Contributions
Résumez vos contributions (méthodologie, modélisation, implémentation, expérimentation). Mentionnez les technologies, frameworks et ressources (HPC, conteneurs, CI/CD) effectivement utilisés.
2.4. Jeux de données (datasets)
Cette section est requise pour tout projet manipulant des données. |
-
Origine & droits : source(s), licences, RGPD/éthique si applicable.
-
Description : taille, formats, variables cibles/caractéristiques, statistiques de base.
-
Découpage : train/val/test (ou CV), éviter les fuites de données; logique temporelle/spatiale si nécessaire.
-
Prétraitements : nettoyage, filtrage, normalisation, enrichissement, gestion des valeurs manquantes.
-
Pertinence/limitations : adéquation avec les objectifs, biais connus, représentativité.
2.5. Vérification — « Ai-je bien résolu le problème ? » (OBLIGATOIRE)
La vérification démontre la justesse technique (maths/numérique/logiciel) : implémentation correcte, expériences reproductibles, métriques calculées correctement. |
-
Stratégie : tests unitaires/intégration, oracles simples, cas jouets, conservation d’invariants.
-
Numérique : études de convergence, sensibilité aux pas/maillages, stabilité, tolérances.
-
Reproductibilité : graine aléatoire, environnement (versions, conteneur), scripts d’expérience.
-
Mesures : métriques adaptées (p.ex. RMSE, MAE, F1, AUC, énergie, temps, mémoire).
-
Comparatifs : baseline(s) simples, ablations, profils HPC (si pertinent : temps noyau, scaling, IO).
-
Traçabilité : tableau récapitulatif des expériences (id, données, paramètres, métriques).
2.5.1. Tests de convergence numérique
Les tests de convergence sont essentiels pour valider l’implémentation d’algorithmes numériques. Ils démontrent que la méthode implémentée converge théoriquement. |
A. Convergence de maillage (méthodes à base d’éléments finis, différences finies)
Utiliser une solution manufacturée (Method of Manufactured Solutions - MMS) : partir d’une solution analytique connue \(u_{exact}(x,y)\), calculer le terme source correspondant, puis vérifier que l’erreur numérique décroît selon l’ordre théorique.
h (taille maille) | DOF | \(‖u_h - u_{exact}‖_{L²}\) | Ordre L² | \(‖u_h - u_{exact}‖_{H¹}\) | Ordre H¹ |
---|---|---|---|---|---|
0.1 |
1024 |
2.34e-3 |
— |
1.87e-2 |
— |
0.05 |
4096 |
5.92e-4 |
1.98 |
9.45e-3 |
0.98 |
0.025 |
16384 |
1.49e-4 |
1.99 |
4.73e-3 |
1.00 |
0.0125 |
65536 |
3.74e-5 |
1.99 |
2.37e-3 |
1.00 |
Ordre = \(log(e_i/e_{i+1}) / log(h_i/h_{i+1})\). Éléments P1 ⇒ ordre théorique \(L²=2, H¹=1\).
B. Convergence d’algorithmes itératifs
Pour les solveurs, optimiseurs, méthodes de point fixe : montrer la décroissance du résidu/erreur.
Itération | Résidu \(‖r‖\) | Erreur \(‖e‖\) | Taux |
---|---|---|---|
0 |
1.0e+0 |
— |
— |
5 |
3.2e-2 |
8.1e-3 |
— |
10 |
1.0e-4 |
2.6e-5 |
0.031 |
15 |
3.2e-7 |
8.2e-8 |
0.032 |
20 |
1.0e-9 |
2.6e-10 |
0.031 |
Taux = \(‖r_{k+1}‖/‖r_k‖\) (convergence linéaire si constant < 1).
C. Convergence de loss (apprentissage automatique)
Montrer la décroissance des fonctions de coût (entraînement + validation) et la stabilisation des métriques.
Époque | Loss train | Loss val | Acc train | Acc val |
---|---|---|---|---|
1 |
2.31 |
2.28 |
0.12 |
0.15 |
10 |
1.85 |
1.92 |
0.34 |
0.31 |
50 |
0.97 |
1.18 |
0.67 |
0.59 |
100 |
0.52 |
0.94 |
0.83 |
0.71 |
200 |
0.31 |
0.87 |
0.91 |
0.74 |
# Exemple : vérification convergence loss
import matplotlib.pyplot as plt
import numpy as np
# Charger logs d'entraînement
epochs = [1, 10, 50, 100, 200]
train_loss = [2.31, 1.85, 0.97, 0.52, 0.31]
val_loss = [2.28, 1.92, 1.18, 0.94, 0.87]
plt.figure(figsize=(10, 4))
plt.subplot(1, 2, 1)
plt.semilogy(epochs, train_loss, 'b-o', label='Train')
plt.semilogy(epochs, val_loss, 'r-s', label='Val')
plt.xlabel('Époque'); plt.ylabel('Loss'); plt.legend()
plt.title('Convergence de la fonction de coût')
# Vérifier absence d'overfitting
plt.subplot(1, 2, 2)
gap = np.array(train_loss) - np.array(val_loss)
plt.plot(epochs, gap, 'g-^')
plt.xlabel('Époque'); plt.ylabel('Gap train-val')
plt.title('Écart train/validation')
plt.tight_layout()
D. Ordres de convergence théoriques (référence)
Méthode | Ordre spatial | Ordre temporel | Notes |
---|---|---|---|
Diff. finies centrées |
p (schéma ordre p) |
— |
Stable si CFL < C |
Éléments finis Pk |
\(k+1\) (L²), \(k\) (H¹) |
— |
k = degré polynomial |
Runge-Kutta ordre s |
— |
s |
RK4 ⇒ ordre 4 |
Euler explicite |
— |
1 |
Ordre minimal |
Newton-Raphson |
— |
2 (quadratique) |
Si \(x₀\) assez proche |
Gradient à pas fixe |
— |
Linéaire |
Taux = \(1 - μ/L\) |
E. Script type pour test de convergence
#!/usr/bin/env python3
# test_convergence.py
import numpy as np
import matplotlib.pyplot as plt
def manufactured_solution(x, y):
"""Solution exacte u = sin(πx)*sin(πy)"""
return np.sin(np.pi * x) * np.sin(np.pi * y)
def source_term(x, y):
"""Terme source f = -Δu = 2π²sin(πx)sin(πy)"""
return 2 * np.pi**2 * np.sin(np.pi * x) * np.sin(np.pi * y)
def solve_poisson(h):
"""Résout -Δu = f avec maillage de pas h"""
# Implémentation du solveur (DF, EF, etc.)
# Retourne u_h, erreur_L2, erreur_H1
pass
# Test de convergence
h_values = [0.1, 0.05, 0.025, 0.0125]
errors_L2 = []
errors_H1 = []
for h in h_values:
u_h, err_L2, err_H1 = solve_poisson(h)
errors_L2.append(err_L2)
errors_H1.append(err_H1)
print(f"h={h:6.3f}, L2={err_L2:.2e}, H1={err_H1:.2e}")
# Calcul des ordres
orders_L2 = []
orders_H1 = []
for i in range(1, len(h_values)):
order_L2 = np.log(errors_L2[i-1]/errors_L2[i]) / np.log(h_values[i-1]/h_values[i])
order_H1 = np.log(errors_H1[i-1]/errors_H1[i]) / np.log(h_values[i-1]/h_values[i])
orders_L2.append(order_L2)
orders_H1.append(order_H1)
print(f"Ordre L2: {order_L2:.2f}, Ordre H1: {order_H1:.2f}")
# Graphique
plt.loglog(h_values, errors_L2, 'bo-', label='L² error')
plt.loglog(h_values, errors_H1, 'rs-', label='H¹ error')
plt.loglog(h_values, [h**2 for h in h_values], 'k--', label='h²')
plt.loglog(h_values, h_values, 'k:', label='h')
plt.xlabel('h'); plt.ylabel('Erreur'); plt.legend()
plt.title('Test de convergence'); plt.grid(True)
Formules utiles :
\[S(N) = T(1) / T(N), \quad E(N) = S(N)/N\]
|
2.5.2. Exemples de tableaux de performance (valeurs fictives)
A. Forte scalabilité (strong scaling) — taille de problème fixe
Le travail est identique, on augmente les ressources.
Exp ID | Ressources (nœuds × CPU/GPU) | \(T_{total}\) (s) | Speedup S | Eff. E | Débit (it/s) | Mémoire (GB) |
---|---|---|---|---|---|---|
SS-01 |
1×(32/0) |
1200 |
1.00 |
1.00 |
85 |
56 |
SS-02 |
2×(32/0) |
640 |
1.88 |
0.94 |
160 |
60 |
SS-03 |
4×(32/0) |
340 |
3.53 |
0.88 |
300 |
68 |
SS-04 |
8×(32/0) |
190 |
6.32 |
0.79 |
520 |
76 |
\(S = T(1)/T(N), E = S/N\). Indiquez aussi la version du code, le hash Git et l’image du conteneur.
B. Faible scalabilité (weak scaling) — charge par ressource constante
On double ressources et taille du problème pour conserver la charge par unité.
Exp ID | Ressources | \(T_{total}\) (s) | Eff. faible \(E_w\) | Débit (unités/s) | Note |
---|---|---|---|---|---|
WS-01 |
1×(32/0) |
300 |
1.00 |
3.2 |
Baseline |
WS-02 |
2×(32/0) |
310 |
0.97 |
6.3 |
I/O commence à dominer |
WS-03 |
4×(32/0) |
325 |
0.92 |
12.3 |
Synchro MPI plus coûteuse |
WS-04 |
8×(32/0) |
360 |
0.83 |
24.8 |
Bande passante réseau limite |
\(E_w\) peut s’estimer via \(T(1)/T(N)\) (problème proportionnel).
C. Scalabilité par taille de données
Impact du volume de données sur temps, débit et métriques du modèle.
Taille données | \(T_{total}\) (min) | Débit (échant./s) | Acc./RMSE | Mémoire (GB) | Commentaire |
---|---|---|---|---|---|
10k |
12 |
830 |
Acc=0.89 |
12 |
Sous-apprentissage |
100k |
95 |
1050 |
Acc=0.92 |
22 |
Bon compromis |
1M |
980 |
1010 |
Acc=0.925 |
76 |
I/O + mémoire limitent |
10M |
— |
— |
— |
>256 |
Non tenable sans sharding |
D. Sensibilité aux paramètres d’exécution (ex. batch size)
Montrer le compromis débit ↔ qualité ↔ mémoire.
Batch | Précision (float16/32) | \(T_{total}\) (min) | Débit (it/s) | Acc./F1 | Mémoire (GB) |
---|---|---|---|---|---|
32 |
fp32 |
120 |
12.5 |
F1=0.88 |
24 |
64 |
fp32 |
95 |
17.6 |
F1=0.88 |
38 |
128 |
fp16 |
70 |
31.0 |
F1=0.87 |
26 |
256 |
fp16 |
62 |
35.2 |
F1=0.86 |
28 |
2.5.3. Modèles de tableaux vierges (à remplir)
Champ | Valeur |
---|---|
ID exp. |
EXP-YYYYMMDD-XX |
Objectif |
(baseline / strong / weak / data scaling / sensibilité) |
Version code |
<hash git court> |
Conteneur |
<registry/image:tag + digest> |
Données |
<source + checksum + split> |
Ressources |
<nœuds × CPU/GPU, RAM, stockage> |
Script |
<chemin/job Slurm + options clés> |
Paramètres |
<batch, lr, tolérance, partitions, etc.> |
Métriques |
<\(T_{total}\), débit, S, E, pic RAM, précision> |
Notes |
<observations, goulets d’étranglement> |
Exp ID | Ressources | \(T_{total}\) (s) | Speedup S | Eff. E | Débit | Mémoire (GB) |
---|---|---|---|---|---|---|
Exp ID | Ressources | \(T_{total}\) (s) | Eff. faible \(E_w\) | Débit | Note |
---|---|---|---|---|---|
Taille données | \(T_{total}\) | Débit | Qualité | Mémoire | Commentaire |
---|---|---|---|---|---|
|
2.6. Validation — « Ai-je résolu le bon problème ? » (SI PERTINENT)
La validation évalue la pertinence scientifique/métier via confrontation au réel (physique/biologie/usage). Si non applicable, l’indiquer en 1–2 phrases et justifier. |
-
Données externes/terrain : protocole de comparaison, incertitudes de mesure.
-
Critères métier/physiques : unités, seuils d’acceptation, cohérences dimensionnelles.
-
Résultats : écarts modèle–réalité, cas limites, domaine de validité.
-
Discussion : explications, limites, pistes d’amélioration.
2.7. Quantification d’incertitude (UQ) (SI PERTINENT)
-
Méthode : MC, ensembles, intervalles/bootstraps, sensibilité (Sobol, LHS), GPs, etc.
-
Résultats : intervalles de confiance, variances, propagation d’incertitude.
-
Impact : robustesse des conclusions, recommandations (données/paramètres critiques).
Si UQ non réalisée, indiquez pourquoi (périmètre/temps/données) et ce qui serait fait en suite.
2.8. Annexe — Mode opératoire benchmark (HPC + local)
Cette annexe décrit un protocole minimal, reproductible et traçable pour vérifier les performances et la scalabilité (strong/weak) d’un projet. Elle s’utilise avec Slurm sur HPC (Apptainer/Singularity ou Docker selon la politique du site) et en local pour l’inférence.
2.8.1. Principes
-
Reproductibilité: figer code (hash Git), environnement (image conteneur + digest), données (checksum), config (YAML), seeds.
-
Mesure: collecter \(T_{total}\), débit, mémoire max, utilisation CPU/GPU, et ressources allouées.
-
Scalabilité:
-
Strong scaling: problème fixe, ressources ↑ ⇒ \(S(N)=T(1)/T(N),\;E(N)=S(N)/N\)
-
Weak scaling: charge par ressource ~constante ⇒ stabilité de \(T(N)\) et du débit.
2.8.2. Organisation minimale du dépôt
project/ ├─ configs/exp.yaml ├─ data/ # (ou DVC si utilisé) ├─ images/ml.sif # image Apptainer locale (optionnel) ├─ scripts/ │ ├─ train.sh # lance entraînement (local/HPC) │ ├─ strong_scaling.sh │ └─ weak_scaling.sh ├─ slurm/ │ ├─ train_cpu.sbatch │ └─ train_gpu.sbatch ├─ tools/ │ ├─ log_metrics.py # append CSV │ └─ parse_sacct.sh # récupère métriques Slurm └─ results/ ├─ runs.csv └─ logs/
2.8.3. Conteneur & environnement
|
2.8.4. Script Slurm — CPU
#!/usr/bin/env bash
#SBATCH -J train_cpu
#SBATCH -A <account> # compte projet
#SBATCH -p <partition> # ex: cpu, long, normal
#SBATCH --nodes=1
#SBATCH --ntasks-per-node=32
#SBATCH --time=02:00:00
#SBATCH -o results/logs/%x-%j.out
#SBATCH -e results/logs/%x-%j.err
set -euo pipefail
# Paramètres expérience
EXP_ID=${EXP_ID:-"EXP-$(date +%Y%m%d-%H%M%S)"}
CONFIG=${CONFIG:-"configs/exp.yaml"}
DATA_DIR=${DATA_DIR:-"$PWD/data"}
RESULTS=${RESULTS:-"$PWD/results"}
CSV=${CSV:-"$RESULTS/runs.csv"}
CONTAINER=${CONTAINER:-"$PWD/images/ml.sif"} # ou "docker://ghcr.io/<org>/<img>:<tag>"
mkdir -p "$RESULTS/logs"
START_TS=$(date +%s)
# Exemple Apptainer (CPU)
srun apptainer exec \
--bind "$DATA_DIR:/workspace/data","$RESULTS:/workspace/results" \
"$CONTAINER" \
bash -lc "python -m project.train --config $CONFIG --device cpu"
END_TS=$(date +%s)
T_TOTAL=$(( END_TS - START_TS ))
# Récupère métriques Slurm
tools/parse_sacct.sh "$SLURM_JOB_ID" > "$RESULTS/logs/${EXP_ID}-${SLURM_JOB_ID}.sacct"
# Journalise
python tools/log_metrics.py \
--csv "$CSV" \
--exp-id "$EXP_ID" \
--resources "nodes=${SLURM_NNODES};ntasks_per_node=${SLURM_NTASKS_PER_NODE}" \
--t-total "$T_TOTAL" \
--container "$CONTAINER" \
--config "$CONFIG" \
--notes "cpu-run"
2.8.5. Script Slurm — GPU
#!/usr/bin/env bash
#SBATCH -J train_gpu
#SBATCH -A <account>
#SBATCH -p <partition> # ex: gpu
#SBATCH --nodes=1
#SBATCH --gres=gpu:1
#SBATCH --cpus-per-task=16
#SBATCH --time=02:00:00
#SBATCH -o results/logs/%x-%j.out
#SBATCH -e results/logs/%x-%j.err
set -euo pipefail
EXP_ID=${EXP_ID:-"EXP-$(date +%Y%m%d-%H%M%S)"}
CONFIG=${CONFIG:-"configs/exp.yaml"}
DATA_DIR=${DATA_DIR:-"$PWD/data"}
RESULTS=${RESULTS:-"$PWD/results"}
CSV=${CSV:-"$RESULTS/runs.csv"}
CONTAINER=${CONTAINER:-"$PWD/images/ml.sif"}
mkdir -p "$RESULTS/logs"
START_TS=$(date +%s)
# Exemple Apptainer (GPU)
srun apptainer exec --nv \
--bind "$DATA_DIR:/workspace/data","$RESULTS:/workspace/results" \
"$CONTAINER" \
bash -lc "python -m project.train --config $CONFIG --device cuda"
END_TS=$(date +%s)
T_TOTAL=$(( END_TS - START_TS ))
tools/parse_sacct.sh "$SLURM_JOB_ID" > "$RESULTS/logs/${EXP_ID}-${SLURM_JOB_ID}.sacct"
python tools/log_metrics.py \
--csv "$CSV" \
--exp-id "$EXP_ID" \
--resources "nodes=${SLURM_NNODES};gpu=1;cpus_per_task=${SLURM_CPUS_PER_TASK}" \
--t-total "$T_TOTAL" \
--container "$CONTAINER" \
--config "$CONFIG" \
--notes "gpu-run"
2.8.6. Lancements "scaling"
#!/usr/bin/env bash
set -euo pipefail
for N in 1 2 4 8; do
EXP_ID="SS-N${N}-$(date +%Y%m%d-%H%M%S)"
sbatch --nodes=$N --export=ALL,EXP_ID=$EXP_ID,CONFIG=configs/exp.yaml slurm/train_cpu.sbatch
done
#!/usr/bin/env bash
set -euo pipefail
# Associer (N, taille_données) pour garder charge par ressource ~constante
declare -a NS=(1 2 4 8)
declare -a DS=("10k" "20k" "40k" "80k")
for i in "${!NS[@]}"; do
N=${NS[$i]}; D=${DS[$i]}
EXP_ID="WS-N${N}-D${D}-$(date +%Y%m%d-%H%M%S)"
sbatch --nodes=$N --export=ALL,EXP_ID=$EXP_ID,CONFIG=configs/exp_${D}.yaml slurm/train_cpu.sbatch
done
2.8.7. Extraction métriques Slurm & logs
#!/usr/bin/env bash
# Usage: tools/parse_sacct.sh <jobid>
JOB=$1
sacct -j "$JOB" --format=JobID,Elapsed,MaxRSS,MaxVMSize,TotalCPU,AllocTRES%30,State -P
2.8.8. Journalisation CSV
#!/usr/bin/env python3
import argparse, csv, os, subprocess, hashlib, json, time
p = argparse.ArgumentParser()
p.add_argument("--csv", required=True)
p.add_argument("--exp-id", required=True)
p.add_argument("--resources", default="")
p.add_argument("--t-total", type=float, required=True)
p.add_argument("--container", required=True)
p.add_argument("--config", required=True)
p.add_argument("--notes", default="")
args = p.parse_args()
def git_commit():
try:
return subprocess.check_output(["git","rev-parse","--short","HEAD"]).decode().strip()
except Exception:
return "NA"
def file_sha256(path):
if not os.path.exists(path): return "NA"
h=hashlib.sha256()
with open(path,"rb") as f:
for chunk in iter(lambda: f.read(1<<20), b""): h.update(chunk)
return h.hexdigest()
row = {
"timestamp": time.strftime("%Y-%m-%d %H:%M:%S"),
"exp_id": args.exp_id,
"git_commit": git_commit(),
"container": args.container,
"container_sha256": file_sha256(args.container) if args.container.endswith(".sif") else "NA",
"config": args.config,
"config_sha256": file_sha256(args.config),
"resources": args.resources,
"t_total_s": args.t_total,
"notes": args.notes
}
file_exists = os.path.exists(args.csv)
os.makedirs(os.path.dirname(args.csv), exist_ok=True)
with open(args.csv, "a", newline="") as f:
w = csv.DictWriter(f, fieldnames=list(row.keys()))
if not file_exists: w.writeheader()
w.writerow(row)
print(json.dumps(row, indent=2))
2.8.9. Exemple CSV (results/runs.csv)
timestamp,exp_id,git_commit,container,container_sha256,config,config_sha256,resources,t_total_s,notes
2025-09-09 09:15:02,SS-N1-20250909-091502,abc1234,images/ml.sif,sha256:...,configs/exp.yaml,sha256:...,nodes=1;ntasks_per_node=32,1200,cpu-run
2025-09-09 09:48:31,SS-N2-20250909-094831,abc1234,images/ml.sif,sha256:...,configs/exp.yaml,sha256:...,nodes=2;ntasks_per_node=32,640,cpu-run
2.8.10. Post-traitement — calcul S(N), E(N)
Ces calculs servent à remplir les tableaux de Vérification (strong/weak scaling). |
# tools/compute_scaling.py (exemple)
import pandas as pd, sys
df = pd.read_csv("results/runs.csv")
# Filtrer la campagne strong scaling:
ss = df[df["exp_id"].str.contains("SS-N")]
# Extraire N depuis "resources" (ex: nodes=4;ntasks_per_node=32)
def get_nodes(s):
for kv in s.split(";"):
if kv.startswith("nodes="): return int(kv.split("=")[1])
return 1
ss["N"] = ss["resources"].apply(get_nodes)
T1 = ss.loc[ss["N"]==1, "t_total_s"].min()
ss["S"] = T1 / ss["t_total_s"]
ss["E"] = ss["S"] / ss["N"]
print(ss[["exp_id","N","t_total_s","S","E"]].sort_values("N"))
2.8.11. Bonnes pratiques (rappel)
|
3. La Forme
3.1. Typographie
La rédaction de textes obéit à des règles précises en Français : cela s’appelle la typographie, voir <les petites leçons de typographie de Jacques André>.
Il est intéressant de s’en imprégner pour donner à votre document un aspect de qualité et éviter des erreurs grossières. |
3.2. Orthographe et Grammaire
L’orthographe et la grammaire sont des prérequis indispensables pour la rédaction du mémoire. Si vous n’êtes pas sûr de vous, faites-vous relire par un tiers. C’est dommage de perdre des points sur ce critère.
3.3. Numérotation
Numérotez tout ce qui peut l’être.
-
pages,
-
chapitres,
-
sections,
-
figures,
-
tables,
-
équations,
-
bibliographie.
Laissez à Latex le soin de numéroter automatiquement, il le fera mieux que vous manuellement. |
Pour les utilisateurs d’Antora, voici un template pour les équations qui utilisent un compteur:
[stem#eq-<some label>,reftext=Equation ({counter:eqs})]
++++
<Equation here>
++++
= My Report
:sectnums:
:stem: latexmath
:eqnums: all
== Theory
[stem#eq-ode,reftext=Equation ({counter:eqs})]
++++
\mathbf{M}(t)\mathbf{\ddot{q}}(t) + \mathbf{C}(t)\mathbf{\dot{q}}(t) + \mathbf{K}(t)\mathbf{q}(t)
= \mathbf{F}(\mathbf{q}, \mathbf{\dot{q}}, t)
++++
See <<eq-ode>> for definition.
[stem#eq-emc,reftext=Equation ({counter:eqs})]
++++
E = mc^2
++++
<<eq-emc>> is another equation.
=== = My Report :sectnums: :stem: latexmath :eqnums: all
4. Theory
See Equation (1) for definition.
Equation (2) is another equation. ===
Utilisez des références si vous devez mettre en relation plusieurs éléments de votre discours en Latex (\ref , \pageref et \label ).
|
4.1. Bibliographie
La bibliographie constitue une partie importante de votre mémoire. Elle constitue un critère de qualité du travail (avez-vous trouvé les bonnes sources ? les documents sur lesquels vous vous appuyez sont-ils sérieux ?). Vous devez indiquer les documents :
-
de référence que vous avez consultés dans votre recherche, pour vous familiariser avec votre sujet ou pour apprendre des techniques particulières ;
-
que vous avez consultés pour effectuer vos choix ou mettre en œuvre un dispositif logiciel ou autre ;
-
qui permettent au lecteur d’en savoir plus sur tel ou tel point de votre mémoire que vous ne pouvez davantage développer.
La bibliographie, voir <le document sur citer ses sources et présenter une bibliographie par Savoirs CDI> vient en annexe, elle doit donner tous les renseignements nécessaires pour permettre au lecteur de retrouver les documents concernés : auteur, titre du document ou de l’ouvrage, éditeur, année de publication, URL si nécessaire, date de consultation pour un site Web, etc.
Chaque document dans la bibliographie comporte une référence (un numéro, une abréviation ou autre), que vous devez citer dans le texte : un document non cité ne devrait pas apparaître dans la bibliographie.
5. Soutenance
Les soutenances ont lieu fin août, elles permettent à l’étudiant de présenter son travail de manière concise devant un jury de 3 personnes qui assistent à l’ensemble des présentations.
Les présentations durent 30 minutes dont 20 minutes de présentations et 10 minutes de questions.
-
Ne reproduisez pas le mémoire dans votre présentation : vous n’avez ni la place, ni le temps. Détachez-vous du mémoire et repartez de zéro pour construire un nouveau discours tenant compte de la contrainte de temps.
-
Travaillez sur les idées et les messages que vous voulez faire passer. Comptez une idée par diapo. Explicitez les idées, ne vous contentez pas de les suggérer.
-
Ne surchargez pas le texte de votre présentation : ne faites pas de phrases, insistez plutôt sur quelques mots pour exposer vos idées.
-
Si vous pouvez prendre des libertés avec la grammaire et ne pas mettre de phrases, vous n’êtes pas dispensé de respecter l’orthographe.
-
Adoptez un fond sobre pour ne pas perturber votre message. Numérotez vos diapos.
-
Faites des illustrations (schémas, figures, courbes) qui puissent être lues à plusieurs mètres de distance. N’hésitez pas à prendre des libertés avec votre style de présentation pour faire une figure en pleine page.
-
Attention aux contrastes : votre présentation projetée dans une salle éclairée aura un contraste beaucoup moins bon que l’écran de votre portable. Évitez donc les couleurs pâles sur fond clair, ou les couleurs peu foncées sur fond sombre.
-
Une de vos missions est de maintenir l’attention de votre auditoire. Pensez que les membres du jury ont déjà peut-être une dizaine de présentations à leur actif, ainsi qu’un bon repas… Vous devez les motiver pour vous écouter.
-
Ne lisez surtout pas les diapos que vous présentez ou, pire encore, un texte que vous auriez préparé. Regardez l’assistance et non vos diapos.
-
Respectez la durée de votre présentation. Ne terminez pas trop en avance (vous n’avez donc rien à dire ?), ne terminez pas trop en retard (vous ne savez pas synthétiser et tenir compte d’une contrainte ?).
-
Répétez. Répétez. Répétez. Répétez. Répétez. Répétez. Répétez. Répétez. Répétez. Répétez. Répétez. Répétez.
-
Lors de la séance des questions, laissez les membres du jury aller jusqu’au bout de leurs questions, sans les interrompre. N’hésitez pas à prendre quelques secondes pour vous permettre de réfléchir à chaque question, voire de la reformuler pour vérifier que vous l’avez bien comprise.
Références
-
[JAndre] J. André. Petites leçons de typographie. Technical report, IRISA, 1990. btn:[> Site Web].
-
[SavoirsCDI] Savoirs CDI. Citer ses sources et présenter une bibliographie, 2016. btn:[> Site Web] .