Des centaines de portables,
et aucun n'appartient à l'école.
Des centaines de portables,
et aucun n'appartient à l'école.
Karel de Grote Hogeschool cherchait un moyen de suivre les ordinateurs des étudiants pendant les examens. Les enseignants ne voyaient pas si quelqu'un se connectait à un réseau externe, faisait tourner une machine virtuelle ou lançait une application interdite.
Jusque-là, tout reposait sur la surveillance en salle, ce qui ne tient pas dans des salles de plusieurs centaines de postes, dont la plupart sont les portables des étudiants eux-mêmes. KDG avait besoin de quelque chose qui vérifie chaque machine avant le début de l'épreuve, enregistre ce qui compte pendant qu'elle se déroule, et se remet en même temps que la copie. L'étudiant voit tout : il se connecte, l'application lui dit quoi changer, et c'est lui qui remet le journal à la fin. La surveillance relève de la convention sur les données d'études qu'il signe à l'inscription.
- 3
- systèmes d'exploitation, une seule base de code
- 6
- signaux surveillés pendant l'examen
- 1
- journal chiffré, remis avec la copie
- 0
- personnes capables de le lire sans la clé de l'enseignant
Un outil de bureau qui capte l'activité système sur Windows, macOS et Linux dépasse ce que Dart fait seul. Capturer des paquets réseau, reconnaître une machine virtuelle et lire le matériel demandent chaque fois du code natif.
Avec notre méthode en six étapes, nous avons construit une application Flutter en néerlandais et en anglais, qui appelle des bibliothèques C et C++ via dart:ffi, chiffre ce qu'elle enregistre sur la machine même, et donne aux enseignants un outil en ligne de commande pour ouvrir ces journaux ensuite.
1. IDENTIFIER & VALIDER
Avec l'équipe IT de KDG, nous avons défini ce que l'intégrité d'un examen veut dire concrètement. Six dimensions en sont sorties : connexions réseau, état du Bluetooth, adaptateurs connectés, applications en cours, présence d'une machine virtuelle et un battement qui indique que l'application tourne toujours. Chacune a été confrontée à des situations d'examen réelles.
1. IDENTIFIER & VALIDER
Avec l'équipe IT de KDG, nous avons défini ce que l'intégrité d'un examen veut dire concrètement. Six dimensions en sont sorties : connexions réseau, état du Bluetooth, adaptateurs connectés, applications en cours, présence d'une machine virtuelle et un battement qui indique que l'application tourne toujours. Chacune a été confrontée à des situations d'examen réelles.
2. CARTOGRAPHIE D'IMPACT
Chaque capacité a été reliée à un résultat pour l'intégrité de l'examen. La surveillance réseau attrape les accès internet non autorisés. La détection de machines virtuelles écarte les environnements en bac à sable. Le suivi des applications signale les outils interdits. L'ordre a été fixé par la fréquence réelle de chaque infraction.
3. AUDIT TECHNIQUE
Nous avons vérifié si Flutter desktop encaissait de la surveillance système en temps réel. L'audit a montré que la capture de paquets et la détection de machines virtuelles exigent toutes deux du code natif. Nous avons choisi dart:ffi avec des bindings générés plutôt que des platform channels, parce que FFI évite le coût de sérialisation qu'une surveillance au niveau du paquet ne peut pas se permettre.
4. PROTOTYPE INTERACTIF
Nous avons construit des paquets d'enrobage FFI autour des bibliothèques C et C++, chacun avec sa suite de tests, validés séparément sur Linux, macOS et Windows avant d'entrer dans l'application Flutter. Les problèmes de compilation propres à chaque plateforme sont ainsi apparus tôt.
5. DÉVELOPPEMENT & LANCEMENT
L'application est un monorepo : l'interface Flutter, deux paquets d'enrobage FFI et un outil Dart en ligne de commande pour déchiffrer. Toutes les données de surveillance sont chiffrées en AES-GCM avant d'être écrites sur le disque, et seul un enseignant disposant de la clé correspondante peut les relire. L'étudiant se connecte avec son code d'examen, parcourt la liste que l'application lui présente, et démarre l'épreuve une fois la machine en ordre.
6. ITÉRER & OPTIMISER
Après le premier déploiement, nous avons ajouté une détection d'adaptateurs propre à chaque plateforme, affiné le battement pour rendre visibles les tentatives de fermeture, et rendu le format de journal chiffré plus rapide à parcourir pour les enseignants.
Le résultat tourne sur chaque machine d'examen, quel que soit son système et à qui qu'elle appartienne. Il fait passer une vérification préalable à l'étudiant, enregistre six types d'activité système pendant l'épreuve, et produit un seul journal chiffré que seul un enseignant peut ouvrir.
Un défi similaire ?
D'abord une vérification, puis six choses suivies
Avant le début de l'épreuve, l'outil montre ce qui ne va pas encore et ne laisse pas commencer tant que ce n'est pas réglé. Pendant l'examen, il observe le système sous six angles, en horodatant et en chiffrant chaque événement là où il se produit.
Inspection en temps réel via une bibliothèque native : TCP, UDP et ICMP, avec adresses source et destination, ports et drapeaux de protocole. Tourne dans un isolate Dart séparé pour ne pas bloquer l'interface.
Reconnaît VMware, VirtualBox, Hyper-V et d'autres hyperviseurs via une bibliothèque C++ derrière un enrobage FFI, et indique le niveau de certitude ainsi que l'hyperviseur trouvé.
Énumère les adaptateurs réseau physiques et virtuels avec leurs détails matériels, et repère l'ajout ou le retrait d'un adaptateur pendant l'examen. Chaque plateforme est traitée comme elle le permet.
Suit les processus en cours et signale les applications interdites. Voit aussi ce qui est lancé ou fermé pendant la session d'examen.
Indique si le Bluetooth est actif avant le début de l'épreuve et s'il se rallume pendant. C'est ce que les étudiants oublient le plus souvent, la liste de vérification le nomme donc explicitement.
Un signal régulier qui dit que l'application tourne encore. Un trou dedans est aussi parlant que le reste du journal : c'est à cela que ressemble une fermeture de l'outil en pleine épreuve.
Flutter desktop avec des enrobages C et C++, un stockage chiffré et un outil de déchiffrement en ligne de commande
L'application est organisée en monorepo. L'interface Flutter pilote six services de surveillance, tous bâtis sur la même classe de base MonitoringService. Deux d'entre eux, la capture de paquets et la détection de machines virtuelles, passent par des paquets d'enrobage FFI aux bindings générés. Chaque événement traverse la couche de chiffrement avant d'atteindre le disque.
Nous avons détaillé le travail FFI derrière cette application. Lire l'article →
Construit avec Flutter pour Windows, macOS et Linux depuis une seule base de code, en néerlandais et en anglais. Le code C et C++ est compilé par plateforme avec CMake et CocoaPods.
L'étudiant se connecte avec son nom, son numéro d'étudiant et son code d'examen. l'outil vérifie la machine et dit en clair ce qui doit changer : désactiver cet adaptateur Wi-Fi, couper le Bluetooth. Une fois tout en ordre, l'épreuve démarre. À la fin, l'application désigne un seul journal compressé que l'étudiant remet avec sa copie. Les enseignants les ouvrent avec un outil Dart en ligne de commande, qui en tire une chronologie par machine.
Organiser les mêmes examens dans votre établissement ?
Karel de Grote Hogeschool a construit cet outil pour ses propres salles d'examen et est ouvert à l'idée de le concéder sous licence à d'autres établissements. La même application, votre identité visuelle, vos règles sur ce qui est vérifié, adaptée et intégrée par l'équipe qui l'a construite. Dites-nous comment vous organisez vos examens aujourd'hui.
