Détails du sujet
Conception et développement d'un écosystème de surveillance d'événements d'évaluation(examen,test,intérrogation...) en ligne : SaaS multi-tenant, SDK framework-agnostic, extension navigateur et IA locale.
Résumé
Auteur : MUTUTE LWANZO
Niveau:
Département: Genie Electronique
Année Ac: 2025-2026 , | 2026-02-20 17:17:11
Mots clés
Proctoring,SaaS,SDK,Extension navigateur,IA,TensorFlow.js,HMAC,Multi-tenant,Framework-agnostic,RGPD,Manifest V3
Intérêt
Ce sujet couvre plusieur domaines du génie logiciel moderne
Architecture logicielle:Système distribué multi-composants (backend, SDK, extension)
Sécurité: Modèle Zero-Trust, signature HMAC, protection contre falsification.
Intelligence artificielle: Modèles TensorFlow.js (vision, audio) exécutés localement.
Développement web:SDK framework-agnostic, TypeScript.
Base de données:Modélisation multi-tenant.
Éthique & RGPD Traitement local, absence de données sensibles
Intérêt par rapport aux solutions existantes:
*Solutions classiques (Proctorio, Respondus)
Transmission données Images/audio envoyés aux serveurs.
Stockage Données sensibles stockées.
RGPD Complexe.
*solution proposée:
Aucune transmission (analyse locale) des données Images/audio au serveur.
Rien stocké (métadonnées seules).
RGPD faible.
Intérêt social:
La démocratisation de l'enseignement à distance en Afrique post-COVID a créé un besoin urgent d'outils d'évaluation fiables. Ce projet propose une approche légère, éthique et accessible, permettant aux établissements d'organiser des examens en ligne crédibles.
Problématique
Comment concevoir une solution de surveillance d'examens en ligne qui soit à la fois efficace contre la fraude, respectueuse de la vie privée (aucune transmission d'images/audio), accessible sur du matériel modeste , réutilisable par d'autres développeurs (sous forme de SDK universel), et facilement intégrable dans les plateformes existantes ?
Plan provisoire
Épigraphe
Dédicace
Remerciements
Résumé
Abstract
Table des matières
Liste des abréviations
Liste des tableaux
Liste des figures
INTRODUCTION GÉNÉRALE
1.1. Contexte/Généralités sur le thème
L'essor de l'enseignement à distance et les défis de l'évaluation en ligne
1.2. Identification et formulation du problème
1.3. Justification du choix du sujet et motivations
1.3.1 Motivation et intérêt pour le sujet
1.3.2 Pertinence scientifique du sujet
1.3.3 Pertinence sociale du sujet
1.4. Questions de recherche
Question principale et questions spécifiques
1.5. Énoncé des objectifs de recherche
1.5.1 Objectif général
1.5.2 Objectifs opérationnels/spécifiques
1.6. Formulation des hypothèses
Hypothèse principale et hypothèses secondaires
1.7. Méthodologie et délimitation du travail
Approche itérative, outils utilisés,
1.8. Structure du mémoire/Subdivision du travail
CHAPITRE 1 : REVUE DE LA LITTÉRATURE OU EXPOSITION DES TRAVAUX ANTÉRIEURS
1.1 La surveillance d'examens en ligne (proctoring)
1.1.1 Définition et enjeux
1.1.2 Évolution des techniques de fraude
1.1.3 Taxonomie des comportements suspects
1.2 Solutions existantes de proctoring
1.2.1 Solutions propriétaires (Proctorio, Respondus, Honorlock)
1.2.2 Solutions open source
1.2.3 Analyse comparative et limites identifiées
1.2.3.1 Problèmes de vie privée (RGPD)
1.2.3.2 Exigences matérielles et bande passante
1.2.3.3 Modèles économiques inadaptés
1.3 Intelligence artificielle pour l'analyse comportementale
1.3.1 Détection d'objets (YOLO, COCO-SSD)
1.3.2 Détection de visages et analyse du regard (FaceMesh, BlazeFace)
1.3.3 Analyse audio (YAMNet, Speech Commands)
1.3.4 TensorFlow.js pour l'exécution locale dans le navigateur
1.3.5 Adaptation dynamique pour matériel contraint(encore en question)
1.4 Sécurité et protection des données
1.4.1 Modèle Zero-Trust
1.4.2 Signature HMAC et tokens d'authentification
1.4.3 RGPD : principes et implications pour le proctoring
1.4.4 Edge computing et traitement local des données
1.5 Architectures logicielles pour SaaS multi-tenant
1.5.1 Principes du multi-tenant
1.5.2 Django et Django REST Framework
1.5.3 Conception d'APIs sécurisées
1.6 Développement de SDK framework-agnostic
1.6.1 TypeScript et compilation universelle
1.6.2 Compatibilité avec React, Angular, Vue, vanilla JS
1.6.3 Bonnes pratiques d'API publique
1.7 Synthèse et positionnement de SecureExam
CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS
2.1 Acteurs du système
2.1.1 Fournisseur SaaS (notre plateforme)
2.1.2 Développeur intégrateur (client)
2.1.3 Étudiant (utilisateur final)
2.1.4 Professeur (superviseur)
2.2 Cas d'utilisation
2.2.1 Diagramme des cas d'utilisation
2.2.2 Description textuelle détaillée
2.2.2.1 Gestion des développeurs
2.2.2.2 Intégration du SDK
2.2.2.3 Déroulement d'un examen
2.2.2.4 Surveillance et détection
2.2.2.5 Consultation des résultats
2.3 Exigences fonctionnelles
2.3.1 Backend (SaaS)
2.3.2 SDK
2.3.3 Extension Chrome
2.3.4 IA locale (vision et audio)
2.3.5 Dashboard professeur
2.3.6 Plateforme de test
2.4 Exigences non fonctionnelles
2.4.1 Sécurité (Zero-Trust, HMAC)
2.4.2 Confidentialité (RGPD, traitement local)
2.4.3 Accessibilité (matériel modeste, bande passante)
2.4.4 Performance et scalabilité
2.4.5 Maintenabilité et évolutivité
2.4.6 Réutilisabilité (framework-agnostic)
2.5 Contraintes techniques
2.5.1 Environnement d'exécution (navigateur)
2.5.2 Compatibilité matérielle
2.5.3 Limitations des extensions Chrome (Manifest V3)
2.6 Hypothèses de recherche
2.6.1 Hypothèse principale
2.6.2 Hypothèses secondaires
CHAPITRE 3 : CONCEPTION ARCHITECTURALE
3.1 Architecture globale du système
3.1.1 Vue d'ensemble des composants
3.1.2 Flux de données et interactions
3.1.3 Principes de séparation des responsabilités
3.2 Architecture backend (SaaS)
3.2.1 Modèle conceptuel de données (MCD)
3.2.2 Modèle logique de données (MLD)
3.2.3 Description détaillée des entités
3.2.3.1 Developer
3.2.3.2 Project
3.2.3.3 Exam
3.2.3.4 Student
3.2.3.5 ExamSession
3.2.3.6 Event
3.2.4 API REST : endpoints et spécifications
3.2.4.1 POST /api/events
3.2.4.2 GET /api/exams/{id}/sessions
3.2.4.3 GET /api/sessions/{id}/events
3.2.4.4 GET /api/projects/{id}/exams
3.2.4.5 GET /api/exams/{id}/students-with-scores
3.2.5 Mécanismes de sécurité
3.2.5.1 Génération et validation des tokens HMAC
3.2.5.2 Gestion des clés secrètes
3.2.5.3 Rate limiting et protection
3.3 Architecture du SDK
3.3.1 Structure modulaire
3.3.2 API publique exposée
3.3.3 Détecteurs d'événements DOM
3.3.3.1 FocusDetector
3.3.3.2 TabDetector
3.3.3.3 ClipboardDetector
3.3.4 Communication avec l'extension
3.3.5 Gestion des erreurs et logging
3.4 Architecture de l'extension Chrome
3.4.1 Manifest V3 et permissions
3.4.2 Service worker (background)
3.4.3 Content scripts
3.4.4 Détecteurs avancés
3.4.4.1 DevToolsDetector
3.4.4.2 NavigationDetector
3.4.4.3 AIDetector (sites suspects)
3.4.5 Communication avec le SDK et le backend
3.4.6 Gestion du heartbeat
3.5 Architecture de l'IA locale (TensorFlow.js)
3.5.1 Principes de traitement local
3.5.2 Module de détection d'objets (COCO-SSD)
3.5.2.1 Sélection du modèle
3.5.2.2 Configuration (seuils, résolution)
3.5.3 Module de détection de visages (FaceMesh)
3.5.3.1 Comptage de visages
3.5.3.2 Analyse du regard
3.5.4 Module d'analyse audio (Speech Commands)
3.5.4.1 Détection de chuchotements
3.5.4.2 Classification des sons
3.5.5 Fusion d'événements et anti-spam
3.5.6 Adaptation dynamique aux capacités matérielles
3.5.6.1 Ajustement de résolution
3.5.6.2 Ajustement de fréquence
3.5.6.3 Sélection du backend (WebGL/CPU)
3.6 Architecture du dashboard professeur
3.6.1 Pages et navigation
3.6.2 Composants principaux
3.6.2.1 ExamList
3.6.2.2 ExamDetail (tableau étudiants)
3.6.2.3 StudentDetail (timeline événements)
3.6.3 Calcul et affichage des scores de risque
3.6.4 Filtres et recherche
3.7 Modèle de sécurité Zero-Trust
3.7.1 Principe : jamais confiance au client
3.7.2 Format du sessionToken (payload + signature)
3.7.3 Algorithme de validation côté backend
3.7.4 Protection contre les attaques courantes
3.7.4.1 Falsification de token
3.7.4.2 Rejeu d'événements
3.7.4.3 Injection de données
3.8 Conformité RGPD
3.8.1 Privacy by Design
3.8.2 Minimisation des données
3.8.3 Transparence et information
3.8.4 Sécurité des traitements
CHAPITRE 4 : IMPLÉMENTATION
4.1 Organisation du développement
4.1.1 Méthodologie itérative
4.1.2 Environnement et outils
4.1.3 Standards de code et conventions
4.2 Itération 0 : Mise en place des fondations
4.2.1 Structure de dossiers
4.2.2 Configuration des environnements
4.2.3 Mise en place des outils de qualité
4.2.4 Scripts d'automatisation
4.3 Itération 1 : Backend core
4.3.1 Implémentation des modèles Django
4.3.2 Création des migrations
4.3.3 Interface admin
4.3.4 Endpoint POST /events (version basique)
4.3.5 Tests unitaires
4.4 Itération 2 : SDK V1 (surveillance DOM)
4.4.1 Structure TypeScript
4.4.2 Implémentation des détecteurs
4.4.3 ApiClient et communication backend
4.4.4 Build et packaging (npm + CDN)
4.4.5 Tests sur différents frameworks
4.5 Itération 3 : Extension V1
4.5.1 Manifest V3 et configuration
4.5.2 Service worker et content scripts
4.5.3 Communication SDK ↔ extension
4.5.4 Détection avancée (DevTools, navigation)
4.5.5 Envoi direct des événements au backend
4.5.6 Détection d'absence d'extension
4.6 Itération 4 : Sécurité Zero-Trust
4.6.1 Génération des SECRET_KEY
4.6.2 Implémentation des fonctions crypto
4.6.3 Modification de l'API pour validation HMAC
4.6.4 Création du modèle ExamSession
4.6.5 Adaptation du SDK et de l'extension
4.6.6 Tests de sécurité
4.7 Itération 5 : Dashboard professeur
4.7.1 Création des endpoints dashboard
4.7.2 Développement des composants React
4.7.3 Implémentation du calcul de score
4.7.4 Intégration avec l'API
4.7.5 Tests utilisateur
4.8 Itération 6 : IA locale
4.8.1 Intégration de TensorFlow.js
4.8.2 Module de détection d'objets
4.8.3 Module de détection de visages
4.8.4 Module d'analyse audio
4.8.5 Fusion d'événements et anti-spam
4.8.6 Adaptation dynamique
4.8.7 Tests de performance et précision
4.9 Itération 7 : Améliorations finales
4.9.1 Idempotence (eventUuid)
4.9.2 Heartbeat et détection de désactivation
4.9.3 Gestion offline basique
4.9.4 Packaging final (npm, extension)
4.9.5 Documentation complète
4.10 Défis techniques et solutions apportées
4.10.1 Performance de l'IA sur matériel modeste
4.10.2 Précision des modèles et faux positifs
4.10.3 Gestion des permissions navigateur
4.10.4 Sécurité des tokens en environnement hostile
CHAPITRE 5 : TESTS ET VALIDATION
5.1 Stratégie de test
5.1.1 Tests unitaires
5.1.2 Tests d'intégration
5.1.3 Tests de sécurité
5.1.4 Tests de performance
5.1.5 Tests d'accessibilité (matériel modeste)
5.1.6 Tests utilisateur
5.2 Environnements de test
5.2.1 Configuration haute performance
5.2.2 Configuration modeste (simulation PC ancien)
5.2.3 Connexions réseau variables
5.3 Résultats des tests
5.3.1 Couverture de code
5.3.2 Performance de l'IA (fps, latence, précision)
5.3.3 Consommation bande passante
5.3.4 Robustesse des mécanismes de sécurité
5.3.5 Adaptabilité dynamique
5.4 Validation des hypothèses
5.4.1 H0 : faisabilité d'un écosystème complet
5.4.2 H1 : efficacité du modèle Zero-Trust
5.4.3 H2 : supériorité de l'approche multi-niveaux
5.4.4 H3 : faisabilité de l'IA locale
5.4.5 H4 : efficacité de l'adaptation dynamique
5.4.6 H5 : respect de la vie privée
5.4.7 H6 : réduction de bande passante
5.4.8 H7 : scalabilité multi-tenant
5.4.9 H8 : réutilisabilité du SDK
5.5 Limites identifiées
5.5.1 Précision variable selon conditions
5.5.2 Dépendance aux API navigateur
5.5.3 Contournements possibles
CHAPITRE 6 : DISCUSSION ET PERSPECTIVES
6.1 Apports du projet
6.1.1 Contributions techniques
6.1.1.1 Architecture Zero-Trust adaptée au proctoring
6.1.1.2 SDK framework-agnostic réutilisable
6.1.1.3 Intégration d'IA locale avec TensorFlow.js
6.1.1.4 Mécanisme d'adaptation dynamique
6.1.2 Contributions méthodologiques
6.1.2.1 Approche itérative pour systèmes complexes
6.1.2.2 Méthodologie de validation multi-critères
6.1.3 Contributions éthiques et sociales
6.1.3.1 Conformité RGPD par conception
6.1.3.2 Accessibilité pour matériel modeste
6.1.3.3 Réduction de la fracture numérique
6.2 Comparaison avec les solutions existantes
6.2.1 Tableau comparatif détaillé
6.2.2 Avantages concurrentiels
6.2.3 Limitations relatives
6.3 Améliorations possibles
6.3.1 Modèles d'IA plus performants et légers
6.3.2 Support d'autres navigateurs (Firefox, Edge)
6.3.3 Mode entièrement hors ligne
6.3.4 Dashboard temps réel (WebSockets)
6.3.5 Intégration native avec LMS (Moodle, Canvas)
6.4 Perspectives
6.4.1 Commercialisation (SaaS pour établissements)
6.4.2 Recherche (nouveaux modèles d'IA frugale)
6.4.3 Impact social (éducation inclusive)
CONCLUSION GÉNÉRALE
7.1 Synthèse des travaux
7.2 Atteinte des objectifs
7.3 Réponse à la problématique
7.4 Contributions résumées
7.5 Ouverture et travaux futurs
BIBLIOGRAPHIE
ANNEXES
Annexe A : Spécifications détaillées des API
Annexe B : Guide d'installation complet
Annexe C : Manuel utilisateur (professeur)
Annexe D : Manuel utilisateur (étudiant)
Annexe E : Documentation technique du SDK
Annexe F : Documentation de l'extension
Annexe G : Configuration de l'adaptation dynamique
Annexe H : Résultats détaillés des tests de performance
Annexe I : Scripts de démonstration
Annexe J : Code source (structure commentée)
Hypothèses
Il est possible de concevoir un système de surveillance d'examens en ligne basé sur un modèle Zero-Trust et une analyse IA locale (TensorFlow.js) qui garantit l'intégrité des données, respecte la vie privée (aucune transmission d'images/audio).
La combinaison d'un SDK côté page, d'une extension navigateur, et d'une analyse IA locale offre un meilleur taux de détection des comportements suspects qu'une approche purement DOM.
Il est possible d'exécuter des modèles d'analyse comportementale (détection d'objets avec COCO-SSD, détection de visages avec FaceMesh, classification audio avec Speech Commands) directement dans le navigateur/extension sans dégrader l'expérience utilisateur sur des ordinateurs modestes.
Une architecture où toute l'analyse est locale et seules des métadonnées non identifiantes sont transmises permet de respecter pleinement le RGPD et d'obtenir la confiance des utilisateurs.
Une architecture multi-tenant avec isolation par projet permet de scaler le système pour des milliers d'examens simultanés sans compromettre la sécurité.
Méthodes
Utilisation des méthodes du génie logiciel .
Ex:Le projet suivra une méthodologie itérative incrémentale en 8 itérations, chacune produisant un livrable fonctionnel et testable....
Modélisation UML.
Gestion du projet avec git,github et gitlab si important Bibliographie
Building microservices designing fine-grained systems (Newman, Samuel, author).
Patterns of Enterprise Application Architecture (Martin Fowler).
Design Patterns Elements of Reusable Object-Oriented Software (Erich Gamma, Richard Helm, Ralph Johnson etc.)
Domain-Driven Design Tackling Complexity in the Heart of Software (Eric Evans)
The EU General Data Protection Regulation (GDPR).
MATHEMATIQUE DES RESEAUX DE NEURONES;
Learning Tensorflows.js
Modern Full-Stack Development Using TypeScript, React, Node.js, Webpack, Python, Django, and Docker - Second Edition (Frank Zammetti).
Formation tutoré en JavaScript Dom sur freeCodeCamp.
Formation tutoré pour Django .
Formation tutoré pour Django restframework.
Directeur & Encadreur
Status
Décision ou observation:
Feu vert:
Déposé : NON
Défendu: NON
Finalisé: NON
Conception et développement d'un écosystème de surveillance d'événements d'évaluation(examen,test,intérrogation...) en ligne : SaaS multi-tenant, SDK framework-agnostic, extension navigateur et IA locale.
Résumé
Auteur : MUTUTE LWANZO
Niveau:
Département: Genie Electronique
Année Ac: 2025-2026 , | 2026-02-20 17:17:11
Mots clés
Proctoring,SaaS,SDK,Extension navigateur,IA,TensorFlow.js,HMAC,Multi-tenant,Framework-agnostic,RGPD,Manifest V3Intérêt
Ce sujet couvre plusieur domaines du génie logiciel moderneArchitecture logicielle:Système distribué multi-composants (backend, SDK, extension)
Sécurité: Modèle Zero-Trust, signature HMAC, protection contre falsification.
Intelligence artificielle: Modèles TensorFlow.js (vision, audio) exécutés localement.
Développement web:SDK framework-agnostic, TypeScript.
Base de données:Modélisation multi-tenant.
Éthique & RGPD Traitement local, absence de données sensibles
Intérêt par rapport aux solutions existantes:
*Solutions classiques (Proctorio, Respondus)
Transmission données Images/audio envoyés aux serveurs.
Stockage Données sensibles stockées.
RGPD Complexe.
*solution proposée:
Aucune transmission (analyse locale) des données Images/audio au serveur.
Rien stocké (métadonnées seules).
RGPD faible.
Intérêt social:
La démocratisation de l'enseignement à distance en Afrique post-COVID a créé un besoin urgent d'outils d'évaluation fiables. Ce projet propose une approche légère, éthique et accessible, permettant aux établissements d'organiser des examens en ligne crédibles.
Problématique
Comment concevoir une solution de surveillance d'examens en ligne qui soit à la fois efficace contre la fraude, respectueuse de la vie privée (aucune transmission d'images/audio), accessible sur du matériel modeste , réutilisable par d'autres développeurs (sous forme de SDK universel), et facilement intégrable dans les plateformes existantes ?Plan provisoire
ÉpigrapheDédicace
Remerciements
Résumé
Abstract
Table des matières
Liste des abréviations
Liste des tableaux
Liste des figures
INTRODUCTION GÉNÉRALE
1.1. Contexte/Généralités sur le thème
L'essor de l'enseignement à distance et les défis de l'évaluation en ligne
1.2. Identification et formulation du problème
1.3. Justification du choix du sujet et motivations
1.3.1 Motivation et intérêt pour le sujet
1.3.2 Pertinence scientifique du sujet
1.3.3 Pertinence sociale du sujet
1.4. Questions de recherche
Question principale et questions spécifiques
1.5. Énoncé des objectifs de recherche
1.5.1 Objectif général
1.5.2 Objectifs opérationnels/spécifiques
1.6. Formulation des hypothèses
Hypothèse principale et hypothèses secondaires
1.7. Méthodologie et délimitation du travail
Approche itérative, outils utilisés,
1.8. Structure du mémoire/Subdivision du travail
CHAPITRE 1 : REVUE DE LA LITTÉRATURE OU EXPOSITION DES TRAVAUX ANTÉRIEURS
1.1 La surveillance d'examens en ligne (proctoring)
1.1.1 Définition et enjeux
1.1.2 Évolution des techniques de fraude
1.1.3 Taxonomie des comportements suspects
1.2 Solutions existantes de proctoring
1.2.1 Solutions propriétaires (Proctorio, Respondus, Honorlock)
1.2.2 Solutions open source
1.2.3 Analyse comparative et limites identifiées
1.2.3.1 Problèmes de vie privée (RGPD)
1.2.3.2 Exigences matérielles et bande passante
1.2.3.3 Modèles économiques inadaptés
1.3 Intelligence artificielle pour l'analyse comportementale
1.3.1 Détection d'objets (YOLO, COCO-SSD)
1.3.2 Détection de visages et analyse du regard (FaceMesh, BlazeFace)
1.3.3 Analyse audio (YAMNet, Speech Commands)
1.3.4 TensorFlow.js pour l'exécution locale dans le navigateur
1.3.5 Adaptation dynamique pour matériel contraint(encore en question)
1.4 Sécurité et protection des données
1.4.1 Modèle Zero-Trust
1.4.2 Signature HMAC et tokens d'authentification
1.4.3 RGPD : principes et implications pour le proctoring
1.4.4 Edge computing et traitement local des données
1.5 Architectures logicielles pour SaaS multi-tenant
1.5.1 Principes du multi-tenant
1.5.2 Django et Django REST Framework
1.5.3 Conception d'APIs sécurisées
1.6 Développement de SDK framework-agnostic
1.6.1 TypeScript et compilation universelle
1.6.2 Compatibilité avec React, Angular, Vue, vanilla JS
1.6.3 Bonnes pratiques d'API publique
1.7 Synthèse et positionnement de SecureExam
CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS
2.1 Acteurs du système
2.1.1 Fournisseur SaaS (notre plateforme)
2.1.2 Développeur intégrateur (client)
2.1.3 Étudiant (utilisateur final)
2.1.4 Professeur (superviseur)
2.2 Cas d'utilisation
2.2.1 Diagramme des cas d'utilisation
2.2.2 Description textuelle détaillée
2.2.2.1 Gestion des développeurs
2.2.2.2 Intégration du SDK
2.2.2.3 Déroulement d'un examen
2.2.2.4 Surveillance et détection
2.2.2.5 Consultation des résultats
2.3 Exigences fonctionnelles
2.3.1 Backend (SaaS)
2.3.2 SDK
2.3.3 Extension Chrome
2.3.4 IA locale (vision et audio)
2.3.5 Dashboard professeur
2.3.6 Plateforme de test
2.4 Exigences non fonctionnelles
2.4.1 Sécurité (Zero-Trust, HMAC)
2.4.2 Confidentialité (RGPD, traitement local)
2.4.3 Accessibilité (matériel modeste, bande passante)
2.4.4 Performance et scalabilité
2.4.5 Maintenabilité et évolutivité
2.4.6 Réutilisabilité (framework-agnostic)
2.5 Contraintes techniques
2.5.1 Environnement d'exécution (navigateur)
2.5.2 Compatibilité matérielle
2.5.3 Limitations des extensions Chrome (Manifest V3)
2.6 Hypothèses de recherche
2.6.1 Hypothèse principale
2.6.2 Hypothèses secondaires
CHAPITRE 3 : CONCEPTION ARCHITECTURALE
3.1 Architecture globale du système
3.1.1 Vue d'ensemble des composants
3.1.2 Flux de données et interactions
3.1.3 Principes de séparation des responsabilités
3.2 Architecture backend (SaaS)
3.2.1 Modèle conceptuel de données (MCD)
3.2.2 Modèle logique de données (MLD)
3.2.3 Description détaillée des entités
3.2.3.1 Developer
3.2.3.2 Project
3.2.3.3 Exam
3.2.3.4 Student
3.2.3.5 ExamSession
3.2.3.6 Event
3.2.4 API REST : endpoints et spécifications
3.2.4.1 POST /api/events
3.2.4.2 GET /api/exams/{id}/sessions
3.2.4.3 GET /api/sessions/{id}/events
3.2.4.4 GET /api/projects/{id}/exams
3.2.4.5 GET /api/exams/{id}/students-with-scores
3.2.5 Mécanismes de sécurité
3.2.5.1 Génération et validation des tokens HMAC
3.2.5.2 Gestion des clés secrètes
3.2.5.3 Rate limiting et protection
3.3 Architecture du SDK
3.3.1 Structure modulaire
3.3.2 API publique exposée
3.3.3 Détecteurs d'événements DOM
3.3.3.1 FocusDetector
3.3.3.2 TabDetector
3.3.3.3 ClipboardDetector
3.3.4 Communication avec l'extension
3.3.5 Gestion des erreurs et logging
3.4 Architecture de l'extension Chrome
3.4.1 Manifest V3 et permissions
3.4.2 Service worker (background)
3.4.3 Content scripts
3.4.4 Détecteurs avancés
3.4.4.1 DevToolsDetector
3.4.4.2 NavigationDetector
3.4.4.3 AIDetector (sites suspects)
3.4.5 Communication avec le SDK et le backend
3.4.6 Gestion du heartbeat
3.5 Architecture de l'IA locale (TensorFlow.js)
3.5.1 Principes de traitement local
3.5.2 Module de détection d'objets (COCO-SSD)
3.5.2.1 Sélection du modèle
3.5.2.2 Configuration (seuils, résolution)
3.5.3 Module de détection de visages (FaceMesh)
3.5.3.1 Comptage de visages
3.5.3.2 Analyse du regard
3.5.4 Module d'analyse audio (Speech Commands)
3.5.4.1 Détection de chuchotements
3.5.4.2 Classification des sons
3.5.5 Fusion d'événements et anti-spam
3.5.6 Adaptation dynamique aux capacités matérielles
3.5.6.1 Ajustement de résolution
3.5.6.2 Ajustement de fréquence
3.5.6.3 Sélection du backend (WebGL/CPU)
3.6 Architecture du dashboard professeur
3.6.1 Pages et navigation
3.6.2 Composants principaux
3.6.2.1 ExamList
3.6.2.2 ExamDetail (tableau étudiants)
3.6.2.3 StudentDetail (timeline événements)
3.6.3 Calcul et affichage des scores de risque
3.6.4 Filtres et recherche
3.7 Modèle de sécurité Zero-Trust
3.7.1 Principe : jamais confiance au client
3.7.2 Format du sessionToken (payload + signature)
3.7.3 Algorithme de validation côté backend
3.7.4 Protection contre les attaques courantes
3.7.4.1 Falsification de token
3.7.4.2 Rejeu d'événements
3.7.4.3 Injection de données
3.8 Conformité RGPD
3.8.1 Privacy by Design
3.8.2 Minimisation des données
3.8.3 Transparence et information
3.8.4 Sécurité des traitements
CHAPITRE 4 : IMPLÉMENTATION
4.1 Organisation du développement
4.1.1 Méthodologie itérative
4.1.2 Environnement et outils
4.1.3 Standards de code et conventions
4.2 Itération 0 : Mise en place des fondations
4.2.1 Structure de dossiers
4.2.2 Configuration des environnements
4.2.3 Mise en place des outils de qualité
4.2.4 Scripts d'automatisation
4.3 Itération 1 : Backend core
4.3.1 Implémentation des modèles Django
4.3.2 Création des migrations
4.3.3 Interface admin
4.3.4 Endpoint POST /events (version basique)
4.3.5 Tests unitaires
4.4 Itération 2 : SDK V1 (surveillance DOM)
4.4.1 Structure TypeScript
4.4.2 Implémentation des détecteurs
4.4.3 ApiClient et communication backend
4.4.4 Build et packaging (npm + CDN)
4.4.5 Tests sur différents frameworks
4.5 Itération 3 : Extension V1
4.5.1 Manifest V3 et configuration
4.5.2 Service worker et content scripts
4.5.3 Communication SDK ↔ extension
4.5.4 Détection avancée (DevTools, navigation)
4.5.5 Envoi direct des événements au backend
4.5.6 Détection d'absence d'extension
4.6 Itération 4 : Sécurité Zero-Trust
4.6.1 Génération des SECRET_KEY
4.6.2 Implémentation des fonctions crypto
4.6.3 Modification de l'API pour validation HMAC
4.6.4 Création du modèle ExamSession
4.6.5 Adaptation du SDK et de l'extension
4.6.6 Tests de sécurité
4.7 Itération 5 : Dashboard professeur
4.7.1 Création des endpoints dashboard
4.7.2 Développement des composants React
4.7.3 Implémentation du calcul de score
4.7.4 Intégration avec l'API
4.7.5 Tests utilisateur
4.8 Itération 6 : IA locale
4.8.1 Intégration de TensorFlow.js
4.8.2 Module de détection d'objets
4.8.3 Module de détection de visages
4.8.4 Module d'analyse audio
4.8.5 Fusion d'événements et anti-spam
4.8.6 Adaptation dynamique
4.8.7 Tests de performance et précision
4.9 Itération 7 : Améliorations finales
4.9.1 Idempotence (eventUuid)
4.9.2 Heartbeat et détection de désactivation
4.9.3 Gestion offline basique
4.9.4 Packaging final (npm, extension)
4.9.5 Documentation complète
4.10 Défis techniques et solutions apportées
4.10.1 Performance de l'IA sur matériel modeste
4.10.2 Précision des modèles et faux positifs
4.10.3 Gestion des permissions navigateur
4.10.4 Sécurité des tokens en environnement hostile
CHAPITRE 5 : TESTS ET VALIDATION
5.1 Stratégie de test
5.1.1 Tests unitaires
5.1.2 Tests d'intégration
5.1.3 Tests de sécurité
5.1.4 Tests de performance
5.1.5 Tests d'accessibilité (matériel modeste)
5.1.6 Tests utilisateur
5.2 Environnements de test
5.2.1 Configuration haute performance
5.2.2 Configuration modeste (simulation PC ancien)
5.2.3 Connexions réseau variables
5.3 Résultats des tests
5.3.1 Couverture de code
5.3.2 Performance de l'IA (fps, latence, précision)
5.3.3 Consommation bande passante
5.3.4 Robustesse des mécanismes de sécurité
5.3.5 Adaptabilité dynamique
5.4 Validation des hypothèses
5.4.1 H0 : faisabilité d'un écosystème complet
5.4.2 H1 : efficacité du modèle Zero-Trust
5.4.3 H2 : supériorité de l'approche multi-niveaux
5.4.4 H3 : faisabilité de l'IA locale
5.4.5 H4 : efficacité de l'adaptation dynamique
5.4.6 H5 : respect de la vie privée
5.4.7 H6 : réduction de bande passante
5.4.8 H7 : scalabilité multi-tenant
5.4.9 H8 : réutilisabilité du SDK
5.5 Limites identifiées
5.5.1 Précision variable selon conditions
5.5.2 Dépendance aux API navigateur
5.5.3 Contournements possibles
CHAPITRE 6 : DISCUSSION ET PERSPECTIVES
6.1 Apports du projet
6.1.1 Contributions techniques
6.1.1.1 Architecture Zero-Trust adaptée au proctoring
6.1.1.2 SDK framework-agnostic réutilisable
6.1.1.3 Intégration d'IA locale avec TensorFlow.js
6.1.1.4 Mécanisme d'adaptation dynamique
6.1.2 Contributions méthodologiques
6.1.2.1 Approche itérative pour systèmes complexes
6.1.2.2 Méthodologie de validation multi-critères
6.1.3 Contributions éthiques et sociales
6.1.3.1 Conformité RGPD par conception
6.1.3.2 Accessibilité pour matériel modeste
6.1.3.3 Réduction de la fracture numérique
6.2 Comparaison avec les solutions existantes
6.2.1 Tableau comparatif détaillé
6.2.2 Avantages concurrentiels
6.2.3 Limitations relatives
6.3 Améliorations possibles
6.3.1 Modèles d'IA plus performants et légers
6.3.2 Support d'autres navigateurs (Firefox, Edge)
6.3.3 Mode entièrement hors ligne
6.3.4 Dashboard temps réel (WebSockets)
6.3.5 Intégration native avec LMS (Moodle, Canvas)
6.4 Perspectives
6.4.1 Commercialisation (SaaS pour établissements)
6.4.2 Recherche (nouveaux modèles d'IA frugale)
6.4.3 Impact social (éducation inclusive)
CONCLUSION GÉNÉRALE
7.1 Synthèse des travaux
7.2 Atteinte des objectifs
7.3 Réponse à la problématique
7.4 Contributions résumées
7.5 Ouverture et travaux futurs
BIBLIOGRAPHIE
ANNEXES
Annexe A : Spécifications détaillées des API
Annexe B : Guide d'installation complet
Annexe C : Manuel utilisateur (professeur)
Annexe D : Manuel utilisateur (étudiant)
Annexe E : Documentation technique du SDK
Annexe F : Documentation de l'extension
Annexe G : Configuration de l'adaptation dynamique
Annexe H : Résultats détaillés des tests de performance
Annexe I : Scripts de démonstration
Annexe J : Code source (structure commentée)
Hypothèses
Il est possible de concevoir un système de surveillance d'examens en ligne basé sur un modèle Zero-Trust et une analyse IA locale (TensorFlow.js) qui garantit l'intégrité des données, respecte la vie privée (aucune transmission d'images/audio).La combinaison d'un SDK côté page, d'une extension navigateur, et d'une analyse IA locale offre un meilleur taux de détection des comportements suspects qu'une approche purement DOM.
Il est possible d'exécuter des modèles d'analyse comportementale (détection d'objets avec COCO-SSD, détection de visages avec FaceMesh, classification audio avec Speech Commands) directement dans le navigateur/extension sans dégrader l'expérience utilisateur sur des ordinateurs modestes.
Une architecture où toute l'analyse est locale et seules des métadonnées non identifiantes sont transmises permet de respecter pleinement le RGPD et d'obtenir la confiance des utilisateurs.
Une architecture multi-tenant avec isolation par projet permet de scaler le système pour des milliers d'examens simultanés sans compromettre la sécurité.
Méthodes
Utilisation des méthodes du génie logiciel .Ex:Le projet suivra une méthodologie itérative incrémentale en 8 itérations, chacune produisant un livrable fonctionnel et testable....
Modélisation UML.
Gestion du projet avec git,github et gitlab si important
Bibliographie
Building microservices designing fine-grained systems (Newman, Samuel, author).Patterns of Enterprise Application Architecture (Martin Fowler).
Design Patterns Elements of Reusable Object-Oriented Software (Erich Gamma, Richard Helm, Ralph Johnson etc.)
Domain-Driven Design Tackling Complexity in the Heart of Software (Eric Evans)
The EU General Data Protection Regulation (GDPR).
MATHEMATIQUE DES RESEAUX DE NEURONES;
Learning Tensorflows.js
Modern Full-Stack Development Using TypeScript, React, Node.js, Webpack, Python, Django, and Docker - Second Edition (Frank Zammetti).
Formation tutoré en JavaScript Dom sur freeCodeCamp.
Formation tutoré pour Django .
Formation tutoré pour Django restframework.
Directeur & Encadreur
Status
Décision ou observation:Feu vert:
Déposé : NON
Défendu: NON
Finalisé: NON