diff --git a/internal-reflections/idees-2024-2025.md b/internal-reflections/idees-2024-2025.md
new file mode 100644
index 000000000..7652217fa
--- /dev/null
+++ b/internal-reflections/idees-2024-2025.md
@@ -0,0 +1,11 @@
+A chaque début de cours un petit tricks, où je commence par un mini exemple et je leur demande quel est le problème dans le code, si iels voient comment l'améliorer :
+- 1. Les outils
+- 2. Keep things small and simple, séparez en petites fonctions, single responsibility
+- 3. Early return et Early continue
+- 4. Move constructor: très important pour leurs classes OpenGL!
+- 5. Tests unitaires & documentation & nommage: comment bien les écrire, comment s'en servir comme outils pour bien comprendre ce qu'on veut que le code fasse. Si vous n'êtes pas capables de me faire une phrase pour me dire ce que votre classe est / fait, c'est qu'il y a un problème. Pareil pour chaque fonction. Et si le nom de la fonction n'a rien à voir avec la description que vous m'en avez fait, il y a aussi un problème.
+- 6. const !! Faire un quiz sur tous les différents const, voir si iels les connaissent tous (notamment les méthodes const). Les + importants sont les const sur les & et sur les méthodes. Et montrer aussi les const qu'on ne veut pas (sur les types de retour de fonction, et sur les variables membres)
+- 7. Les Structs c'est cool ! Et pitié ne faites pas de classes avec des setters pour tous les membres
+- 8. Pointer vs Reference (et aussi, bug classique quand on objet ne change pas, c'est probablement que vous l'avez passé par copie au lieu de référence)
+- 9. Gardez un max de choses en privé, et faites des fonctions libres pour ce qui n'a pas besoin d'être dans la classe (e.g. une fonction distance entre glm::vec2 faite en méthode de la classe Boid) => On veut minimiser la taille de nos classes, les rendre le + simple possible
+- 10. Polymorphisme ? Montrer les différentes approches et leurs avantages et inconvénients. Pb: ce cours ci est un peu long et compliqué
\ No newline at end of file