Thread by @EnDirectDuLabo

J'ai fini de rattraper le #ParJupiter d'aujourd'hui en mangeant. Du coup là j'ai du temps, je vous cause un peu d'enseignement ?

Ma première réelle expérience d'enseignement était le monitorat (enfin, ma "mission doctorale d'enseignement") pendant ma thèse. Avant ça j'avais informellement encadré quelques projets d'étudiants de L3 pendant mon M2 mais c'est tout.

Pour mon monitorat j'étais affecté à Polytech'UPMC (@ParisUpmc).
La première année j'ai donné des TPs de programmation en C au premier semestre aux étudiant·e·s de la filière EI2I (polytech.upmc.fr/fr/formation/e…). Ça m'a beaucoup plu !

Au second semestre je donnais des TP de développement web aux étudiant·e·s de la filière AGRAL (polytech.upmc.fr/fr/formation/a…), et c'était vraiment cool aussi.

La deuxième année, j'ai refait la même chose + un cours "TP Zéro" de prise en main des machines sous GNU/Linux (terminal, etc) au début de l'année pour les nouveaux et nouvelles arrivant·e·s.

L'été entre mes deuxième et troisième années de thèse j'ai décidé que :
– j'avais envie de changer de cours pour voir autre chose,
– je voulais voir ce que ça fait de gérer tout seul un cours complet,
– j'avais pas envie d'avoir cours au second semestre pour rédiger pépère.

Du coup j'ai contacté le prof responsable du département info de Polytech'UPMC pour lui dire tout ça, et il m'a dit que normalement c'était pas possible de me filer la responsabilité complète d'un cours, mais que je pouvais venir pour en discuter.

On s'est donc rencontré quelques jours plus tard, et il m'a dit que pour deux raisons ça allait être possible de faire une exception : 1- des bons retours sur mes encadrements de TP de la part des étudiant·e·s et des enseignants des cours, donc il voulait bien me faire confiance.

Mais aussi et surtout 2- ils avaient deux MdC qui partaient en sabbatique et du coup ils étaient en galère de profs :D.
Après discussion il a été établi que je serai en charge du cours de programmation orientée objet et C++ de la filière EISE (polytech.upmc.fr/fr/formation/e…). YAY!

C'était une expérience géniale ! J'ai pu concevoir complètement mon cours, mes TPs, les projets et les exams !
Bon, j'ai aussi découvert les joies des réservations de salles et de corrections de copies, et saisie de notes ^^'.

Pendant les deux mois et demis / trois mois qu'à durer le cours par contre, je n'ai fait *que ça*, vraiment rien d'autre, donc pas de recherche. Tout préparer de zéro, ça prend un temps dingue !

En gros préparer 1h de cours de manière à peu près satisfaisante, c'est en moyenne une bonne grosse journée de boulot. J'avais 2h de CM + 2×2h de TP par semaine. Faites le calcul :D.

Mais ça m'a vraiment permis de découvrir cet aspect là aussi du métier d'enseignant-chercheur et d'être sûr que c'est ce que je voulais faire :).

Et j'ai pu comme je le voulais ne pas faire cours au second semestre de ma troisième année de thèse parce que j'avais du temps de service en rab des deux années précédentes (fallait arriver à une moyenne de 64hTD / an, et je dépassais déjà un peu).

Le pompon, ça a été les retours des étudiant·e·s !
Je savais pas que Polytech'UPMC faisait ça parce que seul les respo de cours les reçoivent, pas les chargé·e·s de TP.
J'étais trop content :).

Première image, tous les retours "points de satisfaction". Deuxième image, tous les retours "points faible à améliorer". #NoFilter
C'était franchement encourageant !

Ensuite pendant mon année de post-doc (que je vous raconterai demain), je n'ai pas eu l'occasion de donner de cours :(. Mais bon j'aurais pas trop eu le temps, avec la campagne de concours (que je vous raconterai aussi dans la semaine).

Et après ça, depuis l'an dernier je suis maître de conf à Paris 8. Les gens ici sont super cools, dès mon arriver j'ai pu complètement choisir mes cours !

Du coup l'an dernier j'avais comme cours :
– Méthodologie de la programmation (L1 s1),
– Réseaux : modèles, protocoles, programmation (L2 s2),
– Histoire de l'informatique (L3 s1),
– Développement de logiciels libres (L3 s2),
– Sécurité et systèmes embarqués (M1 s1).

Et depuis cette année j'ai en plus :
– Langages : interprétation et compilation (L3 s1).

Remarquez comment je me suis arrangé avec les noms pour qu'ils aient tous des acronymes en 4 lettres : mdlp, rmpp, hdli, liec, ddll, sese. #PasManiaqueNonNonÇaVa

À côté de ça, j'encadre quelques TP, comme celui de programmation fonctionnelle (L1) aujourd'hui, l'an dernier j'encadrais du Prolog (L1) au second semestre.

Faut savoir un truc c'est qu'à Paris 8 en informatique, on ne veut pas d'amphi. Les étudiant·e·s de chaque années sont répartis en groupes qui sont en fait des classes. Chaque groupe à son cours, avec son prof, qui gère tout (CM/TD/TP) en toute indépendance.

C'est vraiment bien parce que ça nous permet de vraiment connaître nos étudiant·e·s et de faire le cours comme on veut. Et comme les groupes sont mélangés chaque semestre, ça mets ensemble des étudiant·e·s qui ont vus des choses différentes, souvent complémentaires.

Ça fait parti des choses qui m'ont vraiment méga motivé pour le poste à Paris 8, mais je vous raconterai ça plus tard. Maintenant, je vais détailler un peu chacun de mes cours !

— Méthodologie de la programmation (L1 s1) :
Le but c'est de leur apprendre à apprendre à programmer, et d'avoir les bons outils pour faire leur études. On voit plein de choses : Python, Git, LaTeX, du C, et un peu de théorie (logique, calculabilité, machines de Turing).

Ça recoupe avec d'autres cours simultanés ou de la suite, mais ça leur permet de voir déjà les notions, y compris avec les mains (TP coriaces) pour mieux les appréhender par ailleurs. Illes se plaignent un peu de l'intensité au début mais sont vraiment content·e·s à la fin.

Notamment parce que le projet du cours consiste en le développement d'un jeu graphique (2D) en Python avec la bibliothèque Pygame, et que la plupart sont bluffé·e·s par ce qu'illes arrivent à produire à la fin du cours !

L'an dernier j'étais avec mes petits frères à noël pendant que je corrigeais les projets, ils ont joué aux jeux de mes étudiant·e·s et attribué des points bonus, c'était extrêmement drôle de les voir prendre ça super au sérieux avec des critiques constructives et tout :D.

— Réseaux : modèles, protocoles, programmation (L2 s2) :
Rien de bien surprenant, on étudie les modèles OSI et TCP/IP, quelques protocoles et on fait de la programmation réseaux en C et (un peu en Racket et Python).

Les points rigolo du cours c'est que je leur parle un peu de sécurité, et puis que c'est amusant de reprogrammer soi même ping, traceroute, etc.

En projet l'an dernier je les ai mis par groupe, illes devaient se mettre d'accord sur un protocole client-serveur pour un petit jeu multijoueurs (au minimum un chat), puis chaque membre du groupe devait implémenter client et serveur, mais chacun·e dans un langage différent !

Je ne sais pas si je vais refaire ça cette année parce que la partie conception de protocole était pas évidente, beaucoup de groupe se sont au départ lancés dans des choses trop compliquées à gérer (par manque d'expérience), faudra que je cadre un peu mieux le sujet.

— Langages : interprétation et compilation (L3 s1) :
Là aussi c'est assez classique : on apprend l'analyse lexicale, l'analyse syntaxique, l'analyse sémantique, à écrire un interpréteur, puis on apprend l'assembleur, puis à écrire un compilateur.

Je profite quand même de ce cours pour leur filer des notions théoriques qu'illes ne voient pas trop par ailleurs (notre licence à Paris 8 est quand même très orientée pratique, c'est possible de ne faire plus que de l'info (sans math quoi) dès le second semestre de la L1).

Donc on voit des trucs directement en rapport avec la compilation, tout ce qui est grammaires, langages, expressions rationnelles, et tout. Mais je leur fait aussi manger un peu de λ-calcul.

Et sinon le projet cette année c'est d'écrire en Racket un compilateur d'un sous-ensemble de Python vers l'assembleur MIPS.

— Histoire de l'informatique (L3 s1) :
Ça, c'est un cours vraiment, vraiment cool. Je trouve que ça manque dans la plupart des formations, je suis vraiment content qu'on ait ça a Paris 8. J'ai tout de suite voulu en prendre la charge.

C'est beaucoup de boulot de préparer les cours (et j'imagine que mes cours feraient sauter les historien·ne·s au plafond), mais c'est vraiment important. J'ai choisi de traiter ce cours sujet par sujet. Donc chaque séance est "Histoire de truc" avec un truc différent.

Dans l'ordre on fait :
– chronologie de l'informatique, de la pré-histoire à nous jours,
– histoire du calcul,
– histoire des machines,
– histoires des systèmes,
– histoires des langages de programmation,
– histoire de la logique,
– histoire de la cryptologie, >>

>> – histoire du logiciel libre,
– histoire des internets.

Puis la dernière séance est utilisée pour faire passer les exposés de tou·te·s celleux qui ne sont pas encore passé·e·s.

Le choix des sujets d'exposés des étudiant·e·s est très libre, du moment qu'on apprend des trucs ! J'ai eu des exposés très variés allant de "La vie de George Boole" à "L'histoire des jeux point-and-click", en passant par "L'évolution de l'industrie du porno à l'ère d'Internet".

De mon côté, je profite de ce cours pour essayer de faire prendre un maximum de recul aux étudiant·e·s sur leur discipline et la société dans laquelle on vit et dans laquelle illes devront travailler. Je mets aussi en perspective les effets de mode.

Oui, très bon exemple :

External Tweet loading...
If nothing shows, it may have been deleted
by @MonniauxD view original on Twitter

L'avantage à la fac (par rapport au secondaire), c'est qu'on s'adresse à des adultes. Je préviens les étudiant·e·s que je leur propose une vision subjective et non-neutre de l'histoire, et je fais dès que possible des parallèles avec l'actualité.

Par exemple cette année la séance sur l'histoire des machines était la semaine qui suivait le reportage de Cash Investigation sur le travail (avec Free et LIDL). Pas mal d'étudiant·e·s avaient vu le reportage donc on a pu le raconter aux autres et en débattre : >>

>> le casque qui commande/escalvagise les employé·e·s des entrepôts de LIDL, il a été conçu autres autres par des informaticien·ne·s. Quelle est notre part responsabilité là dedans ? Est-ce qu'il n'y aurait pas besoin de comités d'éthique en informatique aussi ?

On fait se pose la question du rôle de la technologie, de si et comment il faut décider de le limiter. Et on a eu ce débat après un parallèle fait avec un ancêtre des ordinateurs : la première machine programmable !

La première machine programmable, c'est le métier Jacquard, un métier à tisser du nom de son inventeur qui permet d'automatiser une part considérable du boulot et d'actionner une machine seul ou à deux là où il fallait être 3 ou 4 avant.

Le but de son inventeur, selon ses dires, c'était de libérer les enfants du travail, pour qu'ils puissent aller à l'école, par exemple… Mais ça n'a pas du tout eu ce résultat. En fait, comme les enfants n'avaient plus besoin de travailler >>

>> ils ne percevaient plus de salaire, et le manque à gagner à forcer les parents à les envoyer travailler ailleurs dans des conditions parfois bien pire que dans les ateliers de tissages.

Résultat : le technologie censée libérer n'a fait qu'empirer les choses. Alors il faut se poser la question de pourquoi ? Pourquoi on paye moins les familles si le même travail est accompli et donc la même richesse produite ?

Je me permets alors de leur parler de la différence entre propriété d'usage et propriété lucrative, et aussi de la dépossession de ses outils de travail (et du parallèle avec le logiciel libre). Je leur parle de la révolte des Canuts. Et on revient à nos soucis actuels.

Par exemple, est-ce qu'on doit se battre contre les machines qui automatise le travail pénible parce que ça "vol" du travail à des gens ? Ou est-ce que c'est un combat mal placé ?

Dans ce cours, j'insiste aussi beaucoup sur les contributions de femmes pionnières à l'informatique (Grace Hopper, Ada Lovelace, mais aussi les programmeuses de l'ENIAC, etc.), et j'en profite pour parler des soucis de sexismes qui sont courant dans cette industrie de nos jours.

Bref, vous voyez pourquoi je préviens les étudiant·e·s que je leur parle d'adulte à adultes d'un point de vu subjectif, et qu'illes doivent réfléchir à tout ça par elleux-même :). Je les laisse aussi toujours dire ce qu'ils ont à dire lors des discussions.

En tout cas, c'est vraiment un cours intéressants, les étudiant·e·s aiment beaucoup (et moi aussi ^^). Je l'utilise aussi pour aborder plein de sujets scientifiques qu'on ne voit pas forcément en licence ou qu'on survole juste. Et pour raconter plein d'anecdotes !

— Développement de logiciels libres (L3 s2) :
À ce moment de leur cursus, les étudiant·e·s ont tou·te·s pas mal programmé de projet seul·e ou en groupe, mais toujours sur leur propre code. Le but de ce cours c'est de les faire contribuer à un vrai projet "in the wild".

On commence par des rappels des outils de base : IRC, mailing lists, Git, issue tracker. Puis on les fait choisir un projet libre et le décrire : quel langage ? organisation du code ? où est-il héberger ? avec quels outils ? où est la doc ? comment la communauté discute ? etc.

Ensuite, le but est qu'illes choisissent un bug ou une feature request simple, et qu'illes essayent de le corriger. Illes doivent aussi prendre contact avec la communauté (donc écrire à une mailing list ou sur IRC en anglais, y en a qui flippent ! :D).

Si illes arrivent carrément à aller jusqu'à une vraie contribution (du moins une soumission de patch ou une pull-request, les délais du cours étant contraignants pour l'intégration de leur code au projet), c'est génial, et on a eu quelques cas de belles réussites l'an dernier :).

Pour trouver des bugs "faciles", pas mal de projet ont des tags "newcomers" ou "easy-fix" par exemple. Sinon il y a des sites comme up-for-grabs.net et openhatch.org par exemple.

Après, il arrive d'avoir quelques ratés. L'an dernier des étudiants se sont lancés dans un bug de LibreOffice et c'était finalement indémerdable. Mais bon ils avaient fait un vrai effort, bien documenté leur démarche, et pris contact avec la communauté donc c'est allé :).

— Sécurité et systèmes embarqués (M1 s1) :
Ce cours là n'existait pas avant que j'arrive (enfin, c'en été un autre) il a été créé pour moi quand je suis arrivés (quand je vous dis que mes collègues sont cools !).

Dans ce cours je commence par faire un peu l'histoire de la crypto puis je passe rapidement à la crypto moderne : on voit de la cryptographie symétrique, de la cryptographie asymétrique, et de la cryptanalyse. Après ça, on fait une cryptanalyse linéaire sur un algo jouet en TP.

Ensuite on passe à la partie qui concerne les systèmes embarqués, c'est à dire ce dont je vous parlais cet après-midi à propos de ma thèse. Une séance sur les attaques par canaux auxiliaires, puis on fait un TP où les étudiant·e·s code un (vrai) algo en assembleur puis >>

>> l'attaque par analyse simple de consommation de courant. C'est ce TP qu'on corrige demain. À la fin du TP les étudiant·e·s obtiennent des courbes de consommations qui ressemble à ça par exemple :

On a pas de matos et je serais de toutes façons incapable de gérer 70 étudiant·e·s avec des cartes à puces, des sondes, des oscillos, et compagnie (et puis j'ai même plus mon Zak !). Du coup ça a été beaucoup de boulot de préparer ces TPs.

En gros j'ai tout recodé :D. J'ai écrit Python un simulateur de CPU qui exécute des instructions dans un assembleur simple (genre de MIPS ou ARM réduit pour celleux à qui ça parle).

Au passage il simule aussi sa consommation en fonction des données qui circulent (selon des modèles idéalisés). Et y a un module qui simule une sonde et peut récupérer des traces de consommation pendant l'exécution. Ensuite y a plus qu'à gnuplotter pour obtenir les courbes.

Comme ils doivent implémenter un algo de crypto (un RSA, celui dont jours vous parlais plus tôt dans la journée), j'ai aussi recodé une bibliothèque de grands nombres dans mon assembleur simplifié… Je vous raconte pas les nuits de debugging l'an dernier :D.

Mais au final ça marche bien ! Faudra que je proprifie un peu ça et que j'essaye de le publier. Je tenterai probablement de le soumettre à RESSI cette année ressi.fr :).

Après ce TP, on fait le cours sur les injections de fautes, puis le TP correspondant, sur l'attaque BellCoRe. Pareil, mon bazar est équipé pour pouvoir simuler des injections de fautes donc les étudiant·e·s peuvent mettre l'attaque en pratique sur leur code.

La dernière séance sert d'ouverture et je parle un peu de ce que veulent les étudiant·e·s. L'an dernier je leur ai parlé du fonctionnement du réseau Tor.

Et voilà pour mes cours :). Pfiou ! C'est largement l'heure de dormir demain, je commence à 9h !