Je vous propose un retour d’expérience sur un dispositif d'évaluation que nous avons eu l'occasion de mettre en place dans le cadre d'une formation auprès de l'école d'ingénieur ESIPE de l'Université Gustave Eiffel. La formation était donnée à des étudiants en 3e année de cycle ingénieur sur le thème des bases de données pour le big data, que j'ai orienté pour évoquer différentes technologies NoSQL, l'utilisation des techniques NoSQL pour mettre en place une plateforme de stream processing (hello Kafka) et surtout un cas d'usage en introduction pour montrer un exemple où le métier de data engineer est nécessaire et ce qu'il implique.
Nous sommes alors autour d'octobre-novembre 2020. Si les premiers cours ont eu lieu sur place mais masqué (sur un slide de présentation, j'avais alors montré une photo de moi-même en disant : "voilà, c'est moi sans le masque."), les cours suivants se sont faits à distance. Il n'y avait ni TD ni TP par manque de temps de préparation. Il restait alors la question de la validation du module de formation pour les étudiants.
Que doit retenir un étudiant d'un module de formation ?
Bien souvent, la validation d'un module passe par la validation des connaissances acquises lors d'un examen donné sur un temps limité. Nous avons tous vécu ça. Et si ce format permet de vérifier que les leçons sont (partiellement) bien apprises et de faciliter les corrections, son intérêt s'arrête là ! La place pour la créativité est très limitée. C'est pourtant un point essentiel pour un domaine — le domaine de l'informatique tout entier — qui se renouvelle régulièrement.
Lors de mon cours, j'ai cherché à montrer qu'avec de bonnes bases (principalement le livre de Martin Kleppmann d'un côté et du code source de l'autre), le fonctionnement de systèmes NoSQL devient plus limpide, incluant d'ailleurs quelques live coding pour recréer des commits logs ou des protocoles pour gérer des requêtes... Le point étant que les technologies présentées dans le cours sont beaucoup plus accessibles qu'elles n'y paraissent. Si lors du cours, il n'est pas possible de tout voir, il doit fournir un minimum de pointeurs pour permettre d'en apprendre plus par la suite (et même avec ça, ce n'est pas suffisant *frustration personnelle*).
Comme je sentais que le cours ne suffisait pas, j'avais envie que la partie validation du module soit un complément où l'étudiant aurait l'occasion de voir et apprendre par lui-même. Et donc, l'examen en mode devoir sur table ne me convenait pas.
J'ai dans ma carrière participé à des missions d'audit et de conseil. En peu de temps, il faut fournir une solution à un client suite à un problème rencontré. Dans ce laps de temps, il faut à la fois se baser sur ses connaissances et son expérience pour imaginer des solutions adaptées, et dans la mesure cela ne suffit pas, éventuellement effectuer des recherches sur l'existant pour trouver de nouvelles façons de faire ou valider des idées.
J'ai trouvé cette approche beaucoup plus adaptée par rapport à ce que je cherchais à mettre en place pour la validation du module de formation. Pour un étudiant sans expérience, elle implique en effet :
- De voir un exemple de problématique rencontré chez des clients (j'avais alors choisi un sujet proche d'une de mes expériences).
- D'avoir un complément par rapport au cours et tout en ayant la possibilité d'y apporter un regard critique.
- D'effectuer des recherches et explorer des solutions existantes pour répondre au besoin.
- Éventuellement de confronter ses ébauches de solutions face à des personnes ayant plus d'expériences.
Pour faciliter le travail, surtout en période de confinement, les étudiants étaient regroupés, sur fond de pizza team !
Sujet
Une entreprise gère indépendamment un ensemble de sources de données concernant des utilisateurs de son offre numérique (site web, applis mobiles, réseau social...). Elles sont mises à disposition pour différents usages métiers. Ces sources ont un certains débits : certaines sont "continues" ou aléatoires, d'autres fournissent des données à intervalle fixe. Elle ne dépasse pas le gigaoctet a par une seule qui fournit 400 Go par jour. Ces sources sont localisées dans des bases de données ou des fichiers localisés dans l’entreprise ou dans des stockages de type cloud.
L'entreprise souhaite concentrer sur une seule plateforme ces données concernant ses utilisateurs pour des usages marketing.
Il est demandé de proposer une recommandation architecturale sur laquelle reposerait une telle plateforme.
Le sujet précise :
- L'usage actuel des sources avec plus ou moins de précisions.
- Le temps de rétention pour certaines sources de données (90 jours).
- La fréquence de mise à jour attendue des données de la plateforme (1 fois par jour).
Il est précisé aussi que le client a une équipe technique, mais que ses connaissances en termes de base de données se limitent à MySQL et Elasticsearch.
Le sujet tient sur deux pages et est volontairement incomplet. Le fait que les étudiants demandent des précisions par la suite fait partie de l'exercice.
Des questions sont ajoutées au sujet, demandant par exemple de calculer l'espace de stockage à prévoir (cachée dans une question qui demande le volume des données, ce qui implique de penser au facteur de réplication) et d’imaginer en conclusion des points qui auraient pu être abordés dans l'étude.
Mise en situation et déroulement
Dans le cadre de ce sujet, le groupe d'étudiants est vu comme un groupe d'experts ayant acquis des connaissances dans le domaine de la data ingénierie et capable de recommander une entreprise sur la mise en place d'une "plateforme data".
Certains ont même baptisé leur équipe. Je vous laisse juge...
Les étudiants ont eu un mois pour proposer une solution. Un mois c'est court, d'autant plus pour des étudiants sachant qu'avec les autres modules, ils ne sont pas à 100% de la journée dessus.
Dans cet exercice, je joue tour à tour le rôle d'enseignant, coach et client. En tant que coach, j'oriente leur façon d'aborder le sujet et leurs recherches. Je les mets plus en situation sur la relation qu'ils devront entretenir avec le client. En tant qu'enseignant, j'émets des avis techniques sur leurs ébauches, je les oriente sur des solutions correspondant à leur souhait. En tant que client, j'apporte un jugement sur les ébauches de solution qui me sont présentés. Dans tout ça, j'évite d'imposer un point de vue purement personnel et de les enfermer dans certaines solutions. Il vaut indiquer un ensemble des technologies ou d'approches pouvant répondre au problème sans entrer dans les détails plutôt que de ne parler que d'une seule techno. C'est aux étudiants de faire l'effort de découvrir les technologies et d'en vérifier l'adéquation avec le sujet.
Dans tout ça, il est nécessaire pour l'enseignant de suivre l'avancée. Ce suivi a surtout été à l'initiative de certains étudiants. En y voyant l'intérêt, j'ai fini par imposer des points de suivi à d'autres groupes.
Un aspect, qui est probablement venu un peu tard, fût de les pousser à rencontrer des professionnels pour confronter leurs solutions. L'avantage est évidemment certain, et ce n'est pas faute de les avoir encouragés :
Ces sociétés sont suffisamment ouvertes pour comprendre qu’elles ont tout intérêt à aider des étudiants (qui pourraient être de futurs recrues ou des futures « évangélistes » de leurs solutions). Le cas échéant, faites en part dans votre rapport, ça rassurera le client. Et si certaines vous disent non, vous saurez celles qui ne méritent pas votre CV 😉
Il est venu un peu tard dans le déroulement. Finalement, un seul groupe a utilisé cette possibilité.
La phase mise en place et déroulement se sont particulièrement bien passés et a été enrichissant pour tout le monde, moi y compris, comme je l'explique dans ces tweets :
Soutenance & rapport
La partie soutenance s'est faite groupe par groupe... à distance. Chaque groupe ayant 20mn de présentation et 10mn de questions. Les étudiants devaient ensuite rendre un rapport de quelques pages. J'étais alors accompagné par un collègue expérimenté.
L’un des problèmes posés par cette approche est de pousser les groupes à la limite du bluff. Un mois de préparation pour des personnes qui ne peuvent pas consacrer 100% de leur temps à cet exercice, du fait des cours et d’autres préparations diverses à mettre en place, laisse peu de temps pour l’expérimentation. Comme le sujet implique d’imaginer l’usage de systèmes complets de stockage et de manipulation de données utilisées sur des problématiques techniquement avancés en entreprise, le défi représenté est passionnant pour les étudiants, mais nécessite en réalité une bonne expérience avec ces outils. Ils ne peuvent que se baser sur de la documentation accessible pour imaginer ce qui pourrait être mis en place.
Il y aurait différents moyens de pallier ce problème :
- Un cours insistant sur les usages attendus des différents types de systèmes de stockage et traitement de la donnée.
- Un suivi des travaux en cours par l’enseignant avec de l’accompagnement ponctuel.
- Forcer un peu plus les groupes à demander l’avis d’un expert technique.
Le point 1. est à mon sens pas très simple à mettre en place. Les possibilités d’une base de données sont relativement vastes. Il y a moyen de passer une bonne partie du cours sur les cas d'usage de chaque type de base.
Le point 3. a été très partiellement suivi. Son avantage est en apparence majeur, mais comporte une potentielle difficulté. L'expert peut voir le sujet à sa façon (sachant que le sujet comporte des imprécisions) qui ne correspond pas à ce qui doit être compris et insister sur des technologies qui ne sont pas nécessaires (ça arrive même aux meilleurs 😄). Dans ce cadre, c'est au groupe de cadrer et challenger les recommandations de l'expert.
Le point 2. est un point qui a été mis en place et qui a mon sens est celui qui est le plus intéressant. Il est intéressant, car il permet à la fois d’insister sur les détails du cours dans un cadre pratique et d’éviter que le groupe ne se disperse.
Notation
C'est la partie la plus compliquée. Dans un cas comme celui-là, il faut être capable de diviser le travail réalisé par les groupes en items à valider. Pour imaginer ces items, on peut commencer par imaginer les cas extrêmes et même des cas extrêmes du point de vue du potentiel client de l'étude.
Le pire des cas apparaît lorsqu'un groupe ne montre aucun intérêt et remet des livrables excessivement bâclés ou ne remet pas de travail du tout sans justification compréhensible. C'est un manque de respect notoire et va créer auprès du client de la frustration, qui n'aura aucun souci à aller voir ailleurs. (Ce cas n'est pas arrivé dans les groupes que j'ai fréquentés) ⇒ 0-5
Il y a un autre cas extrême : problème administratif ⇒ pas de note (ce n'est pas un 0, hein !)
Le meilleur des cas : l'architecture répond au besoin du client, les livrables sont corrects. En se basant sur ces livrables, le client peut avec un effort moindre mettre en place sa plateforme data ⇒ 20
L'architecture et les livrables dépassent les attentes du client : c'est potentiellement une bonne idée de réaliser une proposition qui va au-delà des attentes, mais elle va se faire généralement au détriment d'autres aspects d'ordre professionnels et/ou privés, qui risquent de se traduire par une diminution à moyen terme de la qualité de service rendu par l'équipe. Dans la vie professionnelle cela se traduit par le fait d'avoir trop travaillé sur un sujet au détriment d'autres sujets potentiellement plus importants, ce qui peut mettre à mal une carrière. De plus, ce surplus n'est généralement pas payé (du moins à court terme) ⇒ 20
Les cas vont être notés ensuite en fonction des éléments d'architecture en place (eg. toutes les sources sont-elles bien présentes ? Comment sont-elles ingérées par le système ? Comment est effectué le traitement ?...) et de l'effort que devra fournir le client pour mettre en place une plateforme data convenable selon son besoin.
Le système de notation ici n'est pas parfait, mais il permet d'être relativement objectif par rapport à l'ensemble des travaux rendus.
Amélioration possible
Ce fût ma première expérience avec ce type d'exercice. Je l'ai trouvé vraiment intéressant et j'ai très envie de recommencer. De plus, elle s'adapte assez bien vis-à-vis des contraintes sanitaires rencontrées durant cette période.
Je pense que quelques améliorations peuvent être apportées néanmoins.
- C'est un détail, mais je pense que je devrais insister sur le fait que la soutenance et le rapport soient à destination du client. Dans les rapports, j'ai en effet trouvé des phrases du style "C'est un exercice demandé dans le cadre du cours de M. François Sarradin" ou "Nous avons beaucoup appris avec ce sujet...". Ces phrases n'ont pas à être dans un rapport.
- Fixer des rendez-vous de suivi de 30mn pour chaque groupe durant les sessions de TP, avec au moins.
- Un rendez-vous où le groupe aura préparé une série de questions à poser au client (questions fonctionnelles et techniques), ainsi que les critères de satisfaction.
- Un rendez-vous pré-soutenance de présentation de l'architecture au client pour avoir les premiers retours.
- Dans le cours, parler un peu plus des usages attendus de certains types de base de données.
- Laisser du temps (quelques jours) pour rendre le rapport, afin que les étudiants y apportent des corrections par rapport à ce qui a été vu lors de la soutenance.
Le point 1. est à mon sens pas très simple à mettre en place. Les possibilités d’une base de données sont relativement vastes. Il y a moyen de passer une bonne partie du cours sur les cas d'usage de chaque type de base.
Le point 1. est à mon sens pas très simple à mettre en place. Les possibilités d’une base de données sont relativement vastes. Il y a moyen de passer une bonne partie du cours sur les cas d'usage de chaque type de base.