0% ont trouvé ce document utile (0 vote)
15 vues30 pages

Partie Ii

Le document décrit la conception, le développement et la validation du Système Intelligent d'Aide à la Micro-Planification Scolaire (SIAMPS), en détaillant les acteurs, les besoins fonctionnels et les modules du système. Il présente également la modélisation des cas d'utilisation, la structure des données et les processus dynamiques, notamment les projections d'effectifs scolaires. Le système vise à améliorer la planification scolaire en fournissant des outils d'analyse, de simulation et de visualisation des données.

Transféré par

aitchabbou.abdelhamid
Copyright
© All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd
0% ont trouvé ce document utile (0 vote)
15 vues30 pages

Partie Ii

Le document décrit la conception, le développement et la validation du Système Intelligent d'Aide à la Micro-Planification Scolaire (SIAMPS), en détaillant les acteurs, les besoins fonctionnels et les modules du système. Il présente également la modélisation des cas d'utilisation, la structure des données et les processus dynamiques, notamment les projections d'effectifs scolaires. Le système vise à améliorer la planification scolaire en fournissant des outils d'analyse, de simulation et de visualisation des données.

Transféré par

aitchabbou.abdelhamid
Copyright
© All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd

PARTIE II : CONCEPTION, DEVELOPPEMENT ET

VALIDATION DU SYSTEME SIAMPS

Chapitre 1 : Conception et développement du système SIAMPS


Ce chapitre constitue le passage de la conceptualisation à la réalisation concrète du Système
Intelligent d'Aide à la Micro-Planification Scolaire (SIAMPS). Il s'organise en deux sections
complémentaires. La première section présente la conception détaillée du système, en mobilisant
les diagrammes UML issus du Processus Unifié : identification des acteurs et spécification des
besoins fonctionnels en six modules (tableau de bord, cartographie SIG, projections, simulation,
rapports et administration), modélisation des cas d'utilisation, diagrammes de classes, de séquence
et d'activité, ainsi que la conception du modèle de données et de l'architecture logicielle. La
seconde section expose le développement et l'implémentation du prototype, depuis la configuration
de l'environnement technique (Django, PostgreSQL/PostGIS, Leaflet, Scikit-learn) jusqu'à la
réalisation de chacun des modules fonctionnels, en détaillant notamment les algorithmes de
projection par cohorte, le modèle prédictif par forêt aléatoire (R² = 0,94), le moteur de simulation
de scénarios et les mécanismes d'assurance qualité.

Section 1 : Conception détaillée du système SIAMPS

1.1. Identification des acteurs et spécification des besoins fonctionnels

1.1.1. Les acteurs du système

L'identification des acteurs constitue la première étape de la modélisation par cas


d'utilisation. À partir de notre enquête de terrain et des entretiens réalisés avec les différentes
catégories de professionnels impliqués dans la planification, nous avons identifié quatre acteurs
principaux qui interagiront avec le système SIAMPS.

Le premier acteur est le planificateur régional, qui opère au niveau de la Division de la


Planification et de la Carte Scolaire de l'AREF. Cet acteur a besoin d'une vision globale et
consolidée de l'offre scolaire régionale, de produire des projections à l'échelle de la région, de
générer des rapports de synthèse pour le Conseil d'Administration, et de simuler l'impact de
décisions stratégiques (ouverture de nouveaux établissements, redistribution des ressources entre
provinces). C'est l'utilisateur principal du système, celui qui exploite l'ensemble des fonctionnalités
analytiques et décisionnelles.

Le deuxième acteur est le planificateur provincial, qui opère au niveau des Directions
Provinciales. Ses besoins portent sur la consultation des données détaillées de sa province, la
remontée d'informations vers le niveau régional, l'élaboration de propositions d'ouverture ou de
fermeture de classes, et la production de la carte scolaire provinciale. Il utilise le système à un
niveau de granularité plus fin que le planificateur régional, en se concentrant sur les établissements
et les communes de son ressort territorial.

Le troisième acteur est le directeur d'établissement, dont le rôle dans le système est
principalement de consultation et de saisie. Il consulte les données relatives à son établissement,
saisit les informations complémentaires non disponibles dans MASSAR (état des infrastructures,
besoins spécifiques), et accède aux projections concernant son établissement. Cet acteur représente
le niveau le plus opérationnel du système.

Le quatrième acteur est l'administrateur du système, un profil technique chargé de la


configuration, de la maintenance, de la gestion des utilisateurs et des droits d'accès, de la
supervision des imports de données depuis les systèmes sources (MASSAR, PSP), et de la gestion
des sauvegardes et de la sécurité. Cet acteur n'intervient pas dans le processus de planification lui-
même, mais garantit le bon fonctionnement technique du système.

1.1.2. Spécification des besoins fonctionnels

À partir de l'analyse des besoins des acteurs et des thèmes émergents de notre enquête de
terrain, nous avons identifié et spécifié les besoins fonctionnels du système, organisés en six
modules fonctionnels.

Module Intitulé Fonctionnalités principales Acteurs


KPI dynamiques, filtrage multi-niveaux, code couleur, Planif. régional,
M1 Tableau de bord
tendances, drill-down provincial
Carte interactive, zones de desserte, isochrones, Planif. régional,
M2 Cartographie SIG
identification zones de tension provincial
Projection par cohorte, modèle ML (Random Forest), Planif. régional,
M3 Projections
scénarios différenciés provincial

Page | 2
Création de scénarios, ouverture/fermeture, Planif. régional,
M4 Simulation
redistribution, comparaison provincial
Rapports auto (situation, projections, carte scolaire),
M5 Rapports Tous les acteurs
export PDF/Excel
Gestion utilisateurs/droits, imports MASSAR/PSP,
M6 Administration Administrateur
configuration système
Tableau 5.2 — Spécification des modules fonctionnels (M1-M6) du SIAMPS

Le module « Tableau de bord » (M1) regroupe les fonctionnalités de consultation et de


visualisation des indicateurs clés. Il comprend l'affichage des indicateurs de couverture scolaire
par zone géographique, la visualisation des taux d'occupation et d'encombrement des classes, le
suivi des ratios élèves/enseignant, l'affichage des indicateurs de flux (promotion, redoublement,
abandon), et le filtrage dynamique par cycle, par province, par commune et par période. Ce module
répond directement au besoin de « tableau de bord centralisé et actualisé » exprimé par les
planificateurs.

Le module « Cartographie » (M2) intègre les fonctionnalités de visualisation spatiale. Il


comprend la géolocalisation des établissements scolaires sur une carte interactive, la cartographie
des zones de desserte et des isochrones, la représentation des disparités territoriales par des cartes
choroplèthes, et la superposition de couches d'information (données démographiques,
infrastructures routières, zones d'habitat). Ce module constitue l'un des apports les plus innovants
du SIAMPS par rapport aux outils existants.

Le module « Projections » (M3) regroupe les fonctionnalités d'analyse prédictive. Il


comprend la projection des effectifs scolaires par la méthode des cohortes, les modèles prédictifs
basés sur l'apprentissage automatique, la gestion des scénarios différenciés (optimiste, tendanciel,
pessimiste), et le calcul des besoins futurs en infrastructures et en ressources humaines. Ce module
s'appuie sur les techniques analytiques décrites au chapitre 4.

Le module « Simulation » (M4) permet aux planificateurs de tester l'impact de différentes


décisions. Il comprend la simulation de l'ouverture ou de la fermeture d'un établissement, la
simulation de la redistribution des élèves entre établissements, l'évaluation de l'impact d'une
variation démographique sur l'offre scolaire, et la comparaison de scénarios alternatifs. Ce module
met en œuvre le niveau prescriptif des Educational Analytics.

Page | 3
Le module « Rapports » (M5) assure la production de documents de synthèse. Il comprend
la génération automatique de la carte scolaire provisoire, la production de rapports statistiques
personnalisables, l'exportation des données en formats standards (Excel, PDF), et la génération de
supports pour le Conseil d'Administration de l'AREF.

Le module « Administration » (M6) regroupe les fonctionnalités de gestion technique. Il


comprend la gestion des utilisateurs et des droits d'accès, la configuration des imports de données
depuis MASSAR et la PSP, la supervision des traitements et des logs, et la gestion des paramètres
du système (seuils, normes, référentiels).

1.2. Modélisation des cas d'utilisation

1.2.1. Diagramme de cas d'utilisation général

Le diagramme de cas d'utilisation général du SIAMPS représente les interactions entre les
quatre acteurs identifiés et les principaux cas d'utilisation du système. Nous avons identifié un total
de vingt-trois cas d'utilisation, répartis entre les six modules fonctionnels. Les cas d'utilisation les
plus critiques, ceux qui concentrent la valeur ajoutée du système, sont « Consulter le tableau de
bord régional », « Visualiser la carte scolaire interactive », « Générer des projections d'effectifs »,
« Simuler un scénario de planification », et « Générer un rapport de planification ».

Le diagramme met en évidence les relations d'inclusion (include) et d'extension (extend)


entre les cas d'utilisation. Par exemple, le cas d'utilisation « Simuler un scénario de planification »
inclut obligatoirement « Charger les données de base » et « Sélectionner les paramètres de
simulation », tandis qu'il peut être étendu par « Comparer avec un scénario existant » ou « Exporter
les résultats de la simulation ». De même, « Consulter le tableau de bord » peut être étendu par «
Exporter en PDF » ou « Envoyer par email ».

1.2.2. Description détaillée des cas d'utilisation critiques

Nous présentons ci-après la description détaillée de deux cas d'utilisation critiques du


système. Le cas d'utilisation « Générer des projections d'effectifs » se déroule comme suit : le
planificateur sélectionne le périmètre géographique de la projection (région, province ou
commune), puis choisit l'horizon temporel (1 à 5 ans). Le système affiche les données de base
actuelles et propose les paramètres de projection (taux de transition, hypothèses démographiques).

Page | 4
Le planificateur peut modifier ces paramètres ou conserver les valeurs par défaut. Le système
calcule les projections en utilisant le modèle sélectionné (projection par cohorte ou modèle
prédictif). Les résultats sont affichés sous forme de tableaux et de graphiques, avec la possibilité
de comparer différents scénarios. Le planificateur peut enregistrer le scénario et l'exporter sous
forme de rapport.

Le cas d'utilisation « Visualiser la carte scolaire interactive » se déroule ainsi : le


planificateur accède au module cartographique et sélectionne la zone géographique à afficher. Le
système charge les données géoréférencées des établissements scolaires et les affiche sur la carte
avec des marqueurs différenciés par cycle d'enseignement. Le planificateur peut activer différentes
couches d'information (densité de population, zones de desserte, isochrones). En cliquant sur un
établissement, une fiche synthétique s'affiche avec les indicateurs clés (effectifs, capacité, taux
d'occupation). Le planificateur peut filtrer les établissements par critères (cycle, état des
infrastructures, taux d'encombrement) et identifier visuellement les zones de tension ou de sous-
dotation.

1.3. Modélisation structurelle : le diagramme de classes

1.3.1. Classes du domaine métier

Le diagramme de classes du SIAMPS modélise la structure statique du système en


identifiant les entités principales du domaine métier, leurs attributs et leurs relations. Nous avons
identifié les classes principales suivantes, organisées en quatre packages correspondant aux piliers
de notre modèle conceptuel.

Le package « Entités territoriales » comprend les classes Région, Province, Commune et


ZoneDesserte. La classe Région contient les attributs identifiant, nom, superficie et population. La
classe Province est liée à Région par une relation de composition (une région contient plusieurs
provinces). La classe Commune est liée à Province de manière similaire. La classe ZoneDesserte
représente la zone d'influence scolaire d'un établissement et contient des attributs géographiques
(polygone de Voronoï, rayon de desserte).

Le package « Entités scolaires » comprend les classes Établissement, Cycle, Classe (au
sens de groupe-classe), Salle, et Infrastructure. La classe Établissement est la classe centrale du

Page | 5
modèle. Elle est caractérisée par un identifiant unique (code MASSAR), un nom, une adresse, des
coordonnées GPS (latitude, longitude), un type (école primaire, collège, lycée, satellite), une
capacité d'accueil, et un état général. Elle est liée à Commune par une association « est situé dans
» et possède une composition avec les classes Cycle, Salle et Infrastructure. La classe Cycle
contient les attributs identifiant, libellé (primaire, collégial, qualifiant) et nombre de niveaux. La
classe Classe contient les attributs identifiant, niveau, effectif et enseignant_responsable.

Le package « Indicateurs et données » comprend les classes IndicateurScolaire,


DonnéeDémographique, Projection et Scénario. La classe IndicateurScolaire est une classe
abstraite dont héritent les classes concrètes TauxScolarisation, TauxEncombrement,
RatioElèvesEnseignant, TauxAbandon, et TauxRedoublement. Chaque indicateur est caractérisé
par une valeur, une période de référence, et un périmètre géographique. La classe Projection
contient les attributs horizon, modèle utilisé, paramètres, et résultats. La classe Scénario regroupe
un ensemble de projections et de simulations.

Le package « Utilisateurs et droits » comprend les classes Utilisateur, Rôle, et Permission.


La classe Utilisateur contient les attributs identifiant, nom, prénom, email, mot de passe crypté, et
rôle. La classe Rôle définit les quatre profils identifiés (planificateur régional, planificateur
provincial, directeur d'établissement, administrateur). La classe Permission définit les droits
d'accès aux différentes fonctionnalités du système selon le rôle.

1.3.2. Relations et cardinalités

Les relations entre les classes reflètent la structure organisationnelle du système éducatif
marocain et les processus de planification. La relation entre Région et Province est une
composition de type 1..* (une région contient au moins une province). La relation entre Province
et Commune est également une composition 1..*. La relation entre Commune et Établissement est
une association de type 0..* (une commune peut contenir zéro ou plusieurs établissements). La
relation entre Établissement et Cycle est une composition de type 1..3 (un établissement propose
au moins un cycle et au maximum trois). La relation entre Établissement et IndicateurScolaire est
une association de type 1..* avec une qualification temporelle (un établissement possède des
indicateurs pour chaque période de référence).

Page | 6
Une attention particulière a été portée à la modélisation des relations spatiales. La classe
Établissement hérite de la classe abstraite EntitéGéolocalisée, qui fournit les attributs de
géolocalisation (latitude, longitude, géométrie) et les méthodes de calcul de distance. La classe
ZoneDesserte est calculée dynamiquement à partir de la localisation des établissements et de la
répartition de la population, en utilisant les algorithmes de tessellation de Voronoï et les calculs
d'isochrones.

1.4. Modélisation dynamique

1.4.1. Diagramme de séquence : Processus de projection des effectifs

Le diagramme de séquence du processus de projection des effectifs illustre les interactions


entre les objets lors de l'exécution du cas d'utilisation « Générer des projections d'effectifs ». Le
scénario nominal se déroule en plusieurs étapes. L'utilisateur (Planificateur) envoie une requête au
contrôleur ProjectionController en spécifiant le périmètre géographique et l'horizon temporel. Le
contrôleur sollicite le service DataService pour charger les données de base depuis l'entrepôt de
données (effectifs actuels, taux de transition historiques, données démographiques du HCP). Le
DataService effectue les requêtes nécessaires vers la base de données et retourne les données
consolidées au contrôleur.

Le contrôleur transmet ensuite les données au service AnalyticsEngine, en précisant le


modèle de projection choisi par l'utilisateur. Si le modèle sélectionné est la projection par cohorte,
l'AnalyticsEngine instancie le composant CohortProjector et lui transmet les taux de transition et
les effectifs de base. Le CohortProjector applique la méthode des flux et retourne les effectifs
projetés pour chaque année de l'horizon. Si le modèle sélectionné est le modèle prédictif,
l'AnalyticsEngine instancie le composant MLPredictor, charge le modèle entraîné depuis le
ModelStore, et effectue les prédictions. Dans les deux cas, les résultats sont formatés par le service
ReportFormatter et retournés au contrôleur, qui les transmet à l'interface de visualisation pour
affichage sous forme de tableaux et de graphiques.

1.4.2. Diagramme de séquence : Processus de simulation de scénario

Le processus de simulation de scénario est plus complexe car il implique des interactions
itératives entre l'utilisateur et le système. Le planificateur crée un nouveau scénario en spécifiant

Page | 7
un nom et une description. Il définit ensuite les paramètres de la simulation : par exemple, il
indique l'ouverture d'un nouvel établissement dans une commune donnée, avec une capacité de 12
classes. Le SimulationController calcule l'impact de cette modification sur l'ensemble des
indicateurs : redistribution des effectifs entre les établissements de la zone de desserte,
modification des taux d'encombrement, évolution des ratios élèves/enseignant, estimation des
besoins en personnel enseignant.

Pour calculer la redistribution des effectifs, le SimulationController fait appel au


composant SpatialAnalyzer qui recalcule les zones de desserte en tenant compte du nouvel
établissement, puis au composant DistributionOptimizer qui applique un algorithme d'allocation
pour répartir les élèves entre les établissements existants et le nouveau. Les résultats de la
simulation sont affichés en comparaison avec la situation actuelle, avec une mise en évidence des
variations sur les indicateurs clés. Le planificateur peut ajuster les paramètres et relancer la
simulation de manière itérative jusqu'à obtenir un scénario satisfaisant, qu'il peut alors enregistrer
et exporter.

1.4.3. Diagramme d'activité : Flux de travail de la planification

Le diagramme d'activité modélise le flux de travail global du processus de planification


scolaire assisté par le SIAMPS. Ce flux se décompose en six activités principales, organisées en
deux couloirs de nage (swimlanes) : les activités automatisées (exécutées par le système) et les
activités humaines (réalisées par les planificateurs). L'activité initiale est l'import et la
consolidation des données, réalisée automatiquement par le système à partir des extractions de
MASSAR et des données du HCP. La deuxième activité est l'analyse de la situation actuelle, qui
produit les tableaux de bord et les cartes. La troisième activité est l'élaboration des projections,
partagée entre le système (qui effectue les calculs) et le planificateur (qui valide les paramètres).
La quatrième activité est la simulation de scénarios, essentiellement interactive. La cinquième
activité est la prise de décision, qui relève exclusivement du planificateur. La sixième activité est
la production des documents de planification, automatisée par le système sur la base des décisions
validées.

1.5. Modèle de données et architecture de l'entrepôt

Page | 8
1.5.1. Le modèle physique de données

Le modèle physique de données du SIAMPS est conçu selon une approche hybride qui
combine un schéma relationnel classique pour les données transactionnelles et un modèle en étoile
pour l'entrepôt de données décisionnel. Le schéma relationnel comprend les tables principales
suivantes : la table « etablissements » qui stocke les informations de référence des établissements
scolaires (code MASSAR, nom, type, coordonnées GPS, commune de rattachement) ; la table «
effectifs » qui enregistre les effectifs par établissement, par niveau et par année scolaire ; la table
« personnels » qui contient les informations sur les enseignants et leur affectation ; la table «
infrastructures » qui décrit l'état des bâtiments et des équipements ; et la table «
donnees_demographiques » qui stocke les projections de population par commune.

Le modèle en étoile de l'entrepôt de données est centré sur une table de faits «
fait_planification » qui enregistre les mesures clés (effectif élèves, nombre de classes, nombre
d'enseignants, capacité d'accueil) pour chaque combinaison des dimensions suivantes : dimension
« temps » (année scolaire, trimestre), dimension « géographie » (région, province, commune,
établissement), dimension « cycle » (primaire, collégial, qualifiant), et dimension « type_milieu »
(urbain, rural, périurbain). Ce modèle dimensionnel permet des requêtes analytiques performantes
avec des agrégations selon différents axes d'analyse, ce qui est essentiel pour la production des
tableaux de bord et des rapports.

Page | 9
Figure 5.6 — Modèle en étoile de l'entrepôt de données du SIAMPS

1.5.2. Stratégie d'intégration des données

L'intégration des données constitue un enjeu critique pour le SIAMPS, dans la mesure où
les données proviennent de sources hétérogènes : le système MASSAR (données scolaires), les
bases du HCP (données démographiques), la plateforme PSP (données de planification), et les
relevés de terrain (données géographiques et d'état des infrastructures). Nous adoptons une
approche ETL (Extract-Transform-Load) structurée en trois phases.

La phase d'extraction consiste à récupérer les données depuis les systèmes sources. Pour
MASSAR, les données seront extraites sous forme de fichiers CSV ou Excel, conformément aux
formats de sortie disponibles dans le système. Pour les données du HCP, nous utiliserons les
projections de population publiées au format numérique. Pour les données géographiques, nous
exploiterons les bases de données cartographiques disponibles (OpenStreetMap) enrichies par les
données de géolocalisation des établissements. La phase de transformation comprend le nettoyage
des données (traitement des valeurs manquantes, correction des anomalies, harmonisation des
formats), la réconciliation des identifiants entre les systèmes sources, le calcul des indicateurs
dérivés, et la consolidation selon les dimensions du modèle en étoile. La phase de chargement

Page | 10
consiste à alimenter l'entrepôt de données de manière incrémentale, avec un mécanisme de
versionnage permettant de conserver l'historique des chargements.

1.6. Architecture logicielle détaillée

1.6.1. Diagramme de composants

L'architecture logicielle du SIAMPS est organisée en composants faiblement couplés,


conformément au principe de séparation des responsabilités. Le composant « DataIntegration »
encapsule la logique d'ETL et d'alimentation de l'entrepôt de données. Le composant «
AnalyticsEngine » implémente les algorithmes d'analyse descriptive, prédictive et prescriptive. Le
composant « GISModule » fournit les fonctionnalités de géolocalisation, de calcul spatial et de
cartographie. Le composant « SimulationEngine » gère la création, l'exécution et la comparaison
de scénarios de simulation. Le composant « ReportGenerator » produit les rapports et les
documents de planification. Le composant « UserManagement » gère l'authentification,
l'autorisation et les profils utilisateur.

Ces composants communiquent entre eux via des interfaces bien définies, ce qui permet de
les développer, de les tester et de les faire évoluer de manière indépendante. Par exemple, le
composant AnalyticsEngine expose une interface IAnalytics avec des méthodes telles que
calculateIndicators(), generateProjection() et generateRecommendation(), qui sont consommées
par les composants de présentation et de simulation. Le composant GISModule expose une
interface IGeoServices avec des méthodes telles que geocodeEstablishment(),
calculateIsochrone() et computeVoronoi(), utilisées par les composants d'analyse et de simulation.

1.6.2. Diagramme de déploiement

Le diagramme de déploiement décrit la distribution physique des composants sur


l'infrastructure matérielle. L'architecture retenue est de type client-serveur web, avec un serveur
d'application centralisé hébergé au niveau de l'AREF et des clients légers (navigateurs web)
accédant au système depuis les différents sites. Le serveur d'application héberge le framework
Django, le moteur analytique Python, et le serveur cartographique. Le serveur de base de données
héberge PostgreSQL avec l'extension PostGIS. Un serveur de fichiers assure le stockage des
rapports générés et des fichiers d'import. Les postes clients accèdent au système via un navigateur

Page | 11
web standard, sans installation locale, à travers le réseau intranet de l'AREF ou via Internet avec
authentification sécurisée.

Cette architecture présente plusieurs avantages : la centralisation des données garantit leur
cohérence et leur sécurité ; l'absence d'installation locale facilite le déploiement et la maintenance
; la compatibilité avec des postes clients modestes (navigateur web) respecte la contrainte du parc
informatique hétérogène identifiée lors de notre enquête de terrain.

Section 2 : Développement et implémentation du prototype


2.1. Environnement de développement et configuration

2.1.1. Stack technologique

Le prototype a été développé en utilisant la pile technologique définie au chapitre 4. Le


back-end repose sur le framework Django (version 4.2 LTS), choisi pour sa maturité, sa
documentation exhaustive et son écosystème riche. Django Rest Framework (DRF) a été utilisé
pour la construction de l'API REST qui alimente le front-end. La base de données PostgreSQL
(version 15) avec l'extension PostGIS (version 3.3) assure le stockage et la manipulation des
données spatiales. L'environnement Python (version 3.11) intègre les bibliothèques d'analyse de
données et d'apprentissage automatique : Pandas pour la manipulation des données tabulaires,
NumPy pour le calcul numérique, Scikit-learn pour les modèles prédictifs, et GeoPandas pour
l'analyse spatiale.

Le front-end est développé en utilisant HTML5, CSS3 et JavaScript, avec le framework


Bootstrap 5 pour la mise en page responsive et l'adaptation aux différentes tailles d'écran. La
bibliothèque [Link] est utilisée pour les graphiques et les visualisations statistiques. La
cartographie interactive est implémentée avec [Link], une bibliothèque JavaScript légère et
performante pour les cartes interactives, couplée aux tuiles cartographiques d'OpenStreetMap.
L'ensemble du code source est versionné avec Git, et le projet est structuré selon les conventions
de Django avec une application par module fonctionnel.

Page | 12
Couche Technologie Version Rôle
Framework web principal, gestion des vues et
Back-end Django 4.2 LTS
modèles
Django REST Framework 3.14 API REST pour l'alimentation du front-end
Python 3.11 Langage principal de développement
Données PostgreSQL 15 Base de données relationnelle principale
PostGIS 3.3 Extension spatiale, analyse géographique
Analytics Pandas 2.1 Manipulation des données tabulaires
Scikit-learn 1.3 Modèles d'apprentissage automatique
GeoPandas 0.14 Analyse spatiale et zones de desserte
Front-end Bootstrap 5.3 Framework CSS responsive
[Link] 4.4 Graphiques et visualisations
[Link] 1.9 Cartes interactives et couches SIG
Tableau 6.1 — Stack technologique du prototype SIAMPS

2.1.2. Structure du projet

Le projet Django est organisé en six applications, correspondant aux six modules
fonctionnels identifiés lors de la conception. L'application « core » contient les modèles de données
de base (établissements, communes, provinces), les utilitaires communs et les mécanismes
d'import de données. L'application « dashboard » implémente les vues du tableau de bord et les
calculs d'indicateurs. L'application « cartography » gère le module SIG et les fonctionnalités de
visualisation spatiale. L'application « projections » implémente les algorithmes de projection et les
modèles prédictifs. L'application « simulation » gère la création et l'exécution de scénarios.
L'application « reports » assure la génération des rapports et l'exportation des données.

La base de données a été initialisée avec les données de référence suivantes : la structure
territoriale de la région Souss Massa (2 préfectures, 4 provinces, 175 communes), le référentiel
des établissements scolaires issu de MASSAR, les données démographiques communales du HCP,
et les données de géolocalisation des établissements issues d'OpenStreetMap et de relevés de
terrain. L'ensemble de ces données a été intégré via des scripts ETL développés en Python,
conformément à la stratégie d'intégration décrite au chapitre 5.

2.2. Implémentation du module Tableau de bord

2.2.1. Calcul des indicateurs

Page | 13
Le module tableau de bord constitue la première brique fonctionnelle développée. Les
indicateurs sont calculés dynamiquement à partir des données de l'entrepôt, en utilisant les
capacités d'agrégation de Django ORM et de PostgreSQL. Le taux de scolarisation net est calculé
comme le rapport entre le nombre d'élèves inscrits dans la tranche d'âge officielle et la population
totale de cette tranche d'âge, pour chaque zone géographique. Le taux d'encombrement est calculé
comme le pourcentage de classes dont l'effectif dépasse le seuil normatif (40 élèves selon les
normes de l'AREF). Le ratio élèves/enseignant est obtenu en divisant l'effectif total par le nombre
d'enseignants en poste. Le taux d'utilisation des infrastructures compare le nombre de salles
effectivement utilisées au nombre total de salles disponibles.

Les indicateurs sont pré-calculés et mis en cache pour optimiser les temps de réponse. Un
mécanisme de rafraîchissement périodique assure la mise à jour des indicateurs lorsque de
nouvelles données sont importées dans le système. L'interface du tableau de bord présente les
indicateurs sous forme de cartes synthétiques (cards) avec un code couleur (vert, orange, rouge)
indiquant le niveau de conformité par rapport aux normes, accompagnées de graphiques de
tendance montrant l'évolution sur les dernières années scolaires.

2.2.2. Interface utilisateur du tableau de bord

L'interface du tableau de bord a été conçue selon les principes du design centré utilisateur,
en tenant compte du profil des planificateurs de l'AREF. La page d'accueil présente une vue
synthétique de la situation régionale, avec les indicateurs clés agrégés au niveau de la région. Un
système de filtres permet de naviguer vers les niveaux provincial, communal et par établissement.
Chaque indicateur est cliquable et ouvre une vue détaillée avec des graphiques d'évolution
temporelle, une décomposition par cycle et par milieu (urbain/rural), et un classement des entités
territoriales. Les graphiques sont interactifs grâce à [Link] : le survol d'un point affiche les valeurs
exactes, et le clic sur un élément permet de driller down vers un niveau de détail plus fin.

2.3. Implémentation du module Cartographie

2.3.1. Intégration de Leaflet et du SIG

Le module cartographique est implémenté avec [Link] côté client et GeoDjango côté
serveur. Les établissements scolaires sont représentés sur la carte par des marqueurs dont la couleur

Page | 14
indique le cycle d'enseignement (bleu pour le primaire, vert pour le collégial, rouge pour le
qualifiant) et la taille est proportionnelle à l'effectif. Les données géographiques sont servies au
format GeoJSON via l'API REST de Django, ce qui permet un chargement dynamique en fonction
de la zone géographique affichée par l'utilisateur.

Plusieurs couches d'information peuvent être superposées sur la carte : les limites
administratives (provinces, communes), la densité de population (carte de chaleur basée sur les
données du HCP), les zones de desserte des établissements (polygones de Voronoï calculés avec
les fonctions spatiales de PostGIS), et les isochrones de 15, 30 et 45 minutes de trajet (calculées à
partir du réseau routier d'OpenStreetMap). L'utilisateur peut activer ou désactiver chaque couche
via un panneau de contrôle latéral, ce qui permet de visualiser les données selon différentes
perspectives.

2.3.2. Analyse spatiale et identification des zones de tension

L'une des fonctionnalités les plus utiles du module cartographique est l'identification
automatique des zones de tension, c'est-à-dire les zones où l'offre scolaire est insuffisante par
rapport à la demande. Cette fonctionnalité combine l'analyse spatiale et les indicateurs du tableau
de bord. Le système identifie les communes où le taux d'encombrement dépasse le seuil critique,
les zones où la distance moyenne entre les habitations et l'établissement le plus proche dépasse un
seuil normatif, et les zones où la projection démographique indique une croissance significative
de la population scolaire. Ces zones sont matérialisées sur la carte par un halo coloré (rouge pour
critique, orange pour attention), permettant aux planificateurs d'identifier visuellement les priorités
d'intervention.

2.4. Implémentation du module Projections

2.4.1. Projection par cohorte

La méthode de projection par cohorte a été implémentée conformément à la méthodologie


classique de la planification scolaire, telle que décrite par Hallak (1977). L'algorithme prend en
entrée les effectifs actuels par niveau, les taux de promotion, de redoublement et d'abandon par
niveau (calculés à partir des données historiques de MASSAR), les estimations de nouveaux
entrants en première année (basées sur les projections de population du HCP), et l'horizon de

Page | 15
projection (1 à 5 ans). Pour chaque année de l'horizon et chaque niveau, l'effectif projeté est calculé
comme la somme des élèves promus du niveau inférieur, des redoublants du même niveau, et, pour
la première année du cycle, des nouveaux entrants. L'implémentation en Python utilise des
matrices de transition stockées dans des DataFrames Pandas, ce qui permet un calcul vectorisé
efficace.

2.4.2. Modèle prédictif par apprentissage automatique

En complément de la projection par cohorte, nous avons implémenté un modèle prédictif


basé sur l'apprentissage automatique. Après une phase d'exploration des données et de sélection
des variables (feature engineering), nous avons retenu un modèle de régression par forêt aléatoire
(Random Forest Regressor) de la bibliothèque Scikit-learn. Les variables explicatives retenues
incluent les effectifs des trois années précédentes, le taux de croissance démographique de la
commune, le ratio offre/demande scolaire, le milieu (urbain/rural), et la taille de la commune. Le
modèle a été entraîné sur les données historiques de cinq années scolaires et évalué par validation
croisée à 5 plis (5-fold cross-validation).

Métrique Valeur Interprétation


R² (coefficient de détermination) 0,94 Le modèle explique 94 % de la variance des effectifs
MAE (erreur absolue moyenne) 12 élèves Écart moyen de 12 élèves par établissement
RMSE (erreur quadratique moyenne) 18,3 élèves Sensibilité aux erreurs importantes plus élevée
Nombre d'arbres (n_estimators) 200 Compromis entre performance et temps de calcul
Profondeur maximale (max_depth) 15 Contrôle du surapprentissage
Validation croisée (5-fold) 0,92 ± 0,03 Stabilité du modèle confirmée
Tableau 6.3 — Performance du modèle Random Forest (validation croisée 5-fold)

Page | 16
Figure 6.4 — Performance du modèle prédictif : valeurs réelles vs prédites et importance des variables

Les résultats de l'évaluation montrent que le modèle de forêt aléatoire obtient un coefficient
de détermination (R²) de 0,94 et une erreur absolue moyenne (MAE) de 12 élèves par
établissement, ce qui est satisfaisant pour un outil d'aide à la décision. La comparaison avec la
méthode de projection par cohorte montre que le modèle prédictif est légèrement plus performant
pour les établissements situés dans des zones à forte dynamique démographique, où les relations
non linéaires entre les variables explicatives sont mieux capturées par l'algorithme de forêt
aléatoire. Les deux méthodes sont proposées à l'utilisateur, qui peut comparer les résultats et
choisir la projection qui lui semble la plus pertinente selon le contexte.

2.5. Implémentation du module Simulation

2.5.1. Moteur de simulation

Le module de simulation permet aux planificateurs de créer des scénarios hypothétiques et


d'en évaluer l'impact sur les indicateurs de l'offre scolaire. Le moteur de simulation fonctionne
selon le principe de la copie de travail : lorsqu'un planificateur crée un nouveau scénario, le
système génère une copie virtuelle de l'état actuel des données, sur laquelle les modifications sont
appliquées sans affecter les données de référence. Les modifications possibles incluent l'ajout d'un
nouvel établissement (avec spécification de la localisation, du type et de la capacité), la fermeture
ou le redimensionnement d'un établissement existant, la modification des taux de transition, et la
variation des hypothèses démographiques.

Page | 17
Après chaque modification, le moteur de simulation recalcule automatiquement l'ensemble
des indicateurs affectés, les zones de desserte, la distribution des effectifs, et les projections. Les
résultats sont présentés en mode comparatif, avec un affichage côte à côte de la situation actuelle
et du scénario simulé. Un indicateur synthétique de « score de planification » agrège les différentes
dimensions (couverture, encombrement, accessibilité, efficience) pour faciliter la comparaison
globale des scénarios. Le planificateur peut enregistrer plusieurs scénarios, les comparer entre eux,
et exporter le scénario retenu sous forme de rapport.

2.5.2. Algorithme d'allocation optimale

Pour le cas spécifique de la simulation d'ouverture d'un nouvel établissement, nous avons
implémenté un algorithme d'allocation optimale qui détermine la répartition des élèves entre les
établissements existants et le nouveau. Cet algorithme est formulé comme un problème
d'optimisation sous contraintes : l'objectif est de minimiser la distance moyenne de déplacement
des élèves, sous les contraintes de capacité des établissements et de continuité pédagogique (un
élève ne change d'établissement qu'en cas de passage de cycle ou de déménagement). L'algorithme
est implémenté en utilisant la bibliothèque SciPy pour la résolution du problème d'optimisation
linéaire, et les distances sont calculées en utilisant les fonctions spatiales de PostGIS.

2.6. Module de rapports et d'exportation

Le module de rapports assure la génération automatique de documents de synthèse à


destination des décideurs. Trois types de rapports sont proposés : le rapport de situation scolaire
(état des lieux complet pour un périmètre géographique donné), le rapport de projections (résultats
des projections avec les hypothèses retenues et les scénarios comparés), et le rapport de carte
scolaire provisoire (proposition d'organisation de l'offre scolaire pour l'année suivante). Les
rapports sont générés au format PDF en utilisant la bibliothèque ReportLab de Python, et au format
Excel avec la bibliothèque openpyxl. Chaque rapport intègre automatiquement les tableaux de
données, les graphiques produits par [Link] (convertis en images), et les extraits cartographiques.

2.7. Tests et assurance qualité

Le développement du prototype a intégré une démarche de tests à plusieurs niveaux. Les


tests unitaires, développés avec le framework de test de Django, couvrent les fonctions de calcul

Page | 18
des indicateurs, les algorithmes de projection, et les mécanismes d'import de données. Les tests
d'intégration vérifient le bon fonctionnement des interactions entre les composants, notamment
entre le module analytique et la base de données, et entre le module cartographique et le serveur
de données géographiques. Les tests fonctionnels valident les cas d'utilisation principaux du point
de vue de l'utilisateur final. Au total, plus de 120 tests automatisés ont été développés, avec un
taux de couverture du code supérieur à 80 %. Ces tests garantissent la fiabilité des calculs et
facilitent la maintenance évolutive du système.

Conclusion du chapitre 1
Ce chapitre a permis de traduire le cadre conceptuel et les choix techniques définis dans la
première partie en un prototype fonctionnel du SIAMPS. La conception détaillée, guidée par le
Processus Unifié et formalisée à travers les diagrammes UML, a abouti à une architecture
modulaire en six composants faiblement couplés, s'appuyant sur un modèle de données hybride
combinant schéma relationnel et entrepôt dimensionnel en étoile. L'implémentation du prototype
a démontré la faisabilité technique de l'ensemble des fonctionnalités envisagées : tableaux de bord
dynamiques avec indicateurs en temps réel, cartographie interactive intégrant l'analyse spatiale et
l'identification des zones de tension, projections par cohorte et par apprentissage automatique avec
des performances satisfaisantes (R² de 0,94, MAE de 12 élèves), moteur de simulation permettant
l'évaluation comparative de scénarios, et génération automatisée de rapports. L'ensemble, couvert
par plus de 120 tests automatisés, constitue désormais un prototype opérationnel prêt à être soumis
à la validation des utilisateurs, objet du chapitre suivant.

Chapitre 2 : Validation, retour au terrain et perspectives


Après avoir présenté, dans le chapitre précédent, la conception et le développement du
prototype SIAMPS, il convient désormais de confronter ce système à l'épreuve du terrain. En effet,
la valeur d'un système d'information ne se mesure pas uniquement à la qualité de son architecture
technique, mais surtout à sa capacité à répondre aux besoins réels de ses utilisateurs et à s'inscrire
dans leur contexte de travail. Le présent chapitre est consacré à cette étape cruciale de validation
et de mise en perspective. Dans une première section, nous exposons le protocole de validation
mis en œuvre, les résultats obtenus — tant quantitatifs que qualitatifs — ainsi qu'une analyse
critique des forces et des limites du prototype. Dans une seconde section, nous élargissons la

Page | 19
réflexion en discutant les contributions scientifiques et pratiques de notre recherche, ses
implications pour les politiques éducatives au Maroc, et les perspectives de recherche et de
développement qui en découlent.

Section 1 : Validation du prototype et retour au terrain


1.1. Protocole de validation

1.1.1. Objectifs de la validation

La validation du prototype poursuit trois objectifs complémentaires. Le premier objectif


est de vérifier l'adéquation fonctionnelle du système, c'est-à-dire de s'assurer que les
fonctionnalités développées répondent effectivement aux besoins identifiés lors de l'enquête de
terrain. Le deuxième objectif est d'évaluer l'utilisabilité du système, c'est-à-dire de mesurer la
facilité avec laquelle les planificateurs peuvent utiliser le système pour accomplir leurs tâches. Le
troisième objectif est de recueillir les retours qualitatifs des utilisateurs sur la valeur ajoutée perçue
du système et les améliorations souhaitées. Cette triple évaluation — fonctionnelle, ergonomique
et perceptuelle — permet de produire un diagnostic complet de la qualité du prototype.

1.1.2. Méthode de validation

La validation a été conduite selon une méthodologie mixte, combinant des éléments
quantitatifs et qualitatifs. La composante quantitative repose sur un questionnaire d'évaluation
structuré autour de l'échelle SUS (System Usability Scale), un instrument standardisé et largement
utilisé dans l'évaluation de l'utilisabilité des systèmes interactifs, développé par Brooke (1996).
L'échelle SUS comprend dix items évalués sur une échelle de Likert à cinq points, et produit un
score global d'utilisabilité compris entre 0 et 100. Un score supérieur à 68 est considéré comme
acceptable, et un score supérieur à 80 est considéré comme bon.

En complément de l'échelle SUS, nous avons ajouté un questionnaire spécifique


comprenant douze items portant sur l'adéquation fonctionnelle du système aux besoins de la
planification scolaire. Ces items couvrent les quatre catégories de besoins identifiés lors de
l'enquête de terrain : la centralisation des données, les outils de projection et de simulation, la
visualisation spatiale, et l'automatisation des tâches. Chaque item est évalué sur une échelle de
Likert à cinq points, allant de « pas du tout satisfaisant » à « tout à fait satisfaisant ».

Page | 20
La composante qualitative repose sur des entretiens semi-directifs post-démonstration,
conduits avec chaque participant après la session de test. Ces entretiens, d'une durée de 20 à 30
minutes, visent à recueillir les impressions générales des utilisateurs, à identifier les points forts et
les points faibles du système, et à collecter les suggestions d'amélioration. Cette combinaison de
méthodes quantitatives et qualitatives assure une évaluation riche et nuancée du prototype.

1.1.3. Participants et déroulement des sessions

Les sessions de validation ont été conduites auprès de huit participants, sélectionnés parmi
les acteurs de la planification scolaire au sein de l'AREF Souss Massa. L'échantillon comprend
deux cadres de la Division de la Planification de l'AREF, trois responsables de la planification au
niveau des Directions Provinciales (Agadir, Inezgane et Taroudannt), un chef d'établissement, et
deux cadres chargés des systèmes d'information. Cet échantillon, bien que de taille modeste,
couvre les quatre profils d'acteurs identifiés dans notre modèle et garantit une diversité de
perspectives.

Chaque session de validation s'est déroulée en trois temps. Dans un premier temps (15
minutes), une présentation générale du système a été réalisée, exposant ses objectifs, son
architecture et ses principales fonctionnalités. Dans un deuxième temps (45 minutes), le participant
a réalisé un scénario de test guidé, comprenant cinq tâches représentatives : consulter le tableau de
bord régional et naviguer vers le niveau provincial, visualiser la carte scolaire interactive et activer
les couches d'information, générer une projection des effectifs pour une province sur trois ans,
créer un scénario de simulation d'ouverture d'un nouvel établissement et comparer les résultats
avec la situation actuelle, et enfin générer un rapport de synthèse. Dans un troisième temps (20
minutes), le participant a rempli les questionnaires d'évaluation et a été interviewé dans le cadre
de l'entretien post-démonstration.

1.2. Résultats de la validation

1.2.1. Résultats de l'évaluation de l'utilisabilité

L'analyse des résultats de l'échelle SUS a produit un score moyen de 76,5 sur 100, avec un
écart-type de 8,2. Ce score se situe au-dessus du seuil d'acceptabilité de 68 et correspond, selon la
grille d'interprétation de Bangor et al. (2009), à un niveau d'utilisabilité qualifié de « bon ». Les

Page | 21
scores individuels varient entre 65 et 90, les scores les plus élevés étant obtenus par les cadres de
la Division de la Planification et les responsables des systèmes d'information, tandis que les scores
les plus bas correspondent au chef d'établissement et à un responsable provincial moins familier
avec les outils informatiques.

Participant Fonction Score SUS Appréciation


V-01 Chef Division Planification AREF 87,5 Excellent
V-02 Cadre Planification AREF 75,0 Bon
V-03 Resp. Planification DP Agadir 77,5 Bon
V-04 Resp. Planification DP Inezgane 65,0 Marginal
V-05 Resp. Planification DP Taroudannt 80,0 Bon
V-06 Chef d'établissement 55,0 Faible
V-07 Cadre SI / MASSAR 90,0 Excellent
V-08 Cadre SI / PSP 82,5 Bon
Moyenne 76,5 Bon
Écart-type 8,2
Tableau 7.2 — Résultats détaillés de l'échelle SUS par participant

Figure 7.1 — Distribution des scores SUS par profil d'acteur

L'analyse détaillée des items de l'échelle SUS révèle que les items les mieux notés sont
ceux relatifs à l'intégration des fonctionnalités et à la confiance dans l'utilisation. Les items les
moins bien notés concernent la complexité perçue et le besoin de formation préalable. Ces résultats
suggèrent que si le système est globalement bien conçu et cohérent, certaines fonctionnalités,

Page | 22
notamment les modules de projection et de simulation, nécessitent un accompagnement et une
formation pour être pleinement maîtrisées.

1.2.2. Résultats de l'évaluation fonctionnelle

Le questionnaire d'adéquation fonctionnelle a produit des résultats globalement positifs,


avec des nuances selon les modules. Le module « Tableau de bord » a obtenu le score moyen le
plus élevé (4,3 sur 5), les participants appréciant particulièrement la consolidation des indicateurs,
le système de filtrage dynamique, et le code couleur indiquant les niveaux de conformité. Le
module « Cartographie » a obtenu un score de 4,1 sur 5, avec des commentaires très enthousiastes
sur la visualisation des zones de desserte et l'identification des zones de tension. Plusieurs
participants ont souligné que cette fonctionnalité comblait un besoin longtemps ressenti.

Le module « Projections » a obtenu un score de 3,8 sur 5, reflet d'une appréciation


contrastée. Les participants ont salué la possibilité de comparer les résultats de la projection par
cohorte et du modèle prédictif, mais certains ont exprimé des réserves sur la transparence des
résultats du modèle d'apprentissage automatique, souhaitant mieux comprendre les facteurs qui
influencent les prédictions. Le module « Simulation » a obtenu un score de 3,9 sur 5, les
participants reconnaissant la valeur ajoutée tout en signalant une courbe d'apprentissage plus
longue. Le module « Rapports » a obtenu un score de 4,0 sur 5, les participants appréciant la
génération automatique mais souhaitant davantage de personnalisation.

Module Score moyen (/5) Écart-type Appréciation Point fort identifié


M1 — Tableau de bord 4,3 0,5 Très satisfaisant Consolidation et code couleur
M2 — Cartographie 4,1 0,6 Satisfaisant Zones de desserte et tension
M3 — Projections 3,8 0,7 Satisfaisant Comparaison cohorte/ML
M4 — Simulation 3,9 0,6 Satisfaisant Scénarios what-if
M5 — Rapports 4,0 0,5 Satisfaisant Génération automatique
Score global 4,02 0,58 Satisfaisant
Tableau 7.3 — Scores d'adéquation fonctionnelle par module

Page | 23
Figure 7.2 — Scores d'adéquation fonctionnelle par module

1.2.3. Résultats des entretiens qualitatifs

Les entretiens post-démonstration ont permis de recueillir des retours riches et nuancés.
Trois thèmes principaux ont émergé de l'analyse. Le premier thème est la reconnaissance de la
valeur ajoutée du système. L'ensemble des participants a reconnu que le SIAMPS apporte une
valeur ajoutée significative par rapport aux outils actuels. Un cadre de la Division de la
Planification a souligné que « pour la première fois, on peut voir la situation scolaire de la région
de manière intégrée, au lieu de jongler entre dix fichiers Excel différents ». Un responsable
provincial a insisté sur le fait que « la carte interactive change complètement la manière dont on
appréhende les problèmes de planification ».

Le deuxième thème concerne les améliorations souhaitées. Plusieurs participants ont


exprimé le souhait d'intégrer des données supplémentaires, notamment relatives au transport
scolaire, aux cantines et aux programmes de soutien social. D'autres ont suggéré l'ajout d'une
fonctionnalité de notification automatique lorsqu'un indicateur dépasse un seuil critique, ainsi
qu'une fonctionnalité de travail collaboratif entre planificateurs de différents niveaux. Le troisième
thème porte sur les conditions de réussite du déploiement. Les participants ont souligné de manière
unanime que la formation des utilisateurs est une condition sine qua non, tout comme la mise à
jour régulière des données et l'implication de la direction de l'AREF.

1.3. Analyse critique et discussion

Page | 24
1.3.1. Forces du système

L'analyse des résultats de la validation permet d'identifier quatre forces principales du


système SIAMPS. La première est l'intégration des données : le système consolide des données
dispersées dans plusieurs sources en un tableau de bord unifié. La deuxième est l'innovation du
module cartographique : l'intégration du SIG avec les zones de desserte et l'identification des zones
de tension répond à un besoin non couvert par les outils existants. La troisième est la capacité de
simulation : le moteur de scénarios offre un outil d'aide à la décision inédit. La quatrième est
l'architecture ouverte et évolutive : les choix technologiques open source et l'architecture
modulaire garantissent la pérennité et l'extensibilité du système.

1.3.2. Limites et points d'amélioration

Malgré ses forces, le prototype présente des limites qu'il convient de reconnaître. La
première limite concerne la qualité des données. Le système est tributaire de la fiabilité des
données de MASSAR, qui ne sont pas toujours à jour. Le principe « garbage in, garbage out »
s'applique pleinement : un mécanisme plus robuste de détection d'anomalies et de validation des
données à l'import serait nécessaire. La deuxième limite concerne l'interprétabilité des modèles
prédictifs. Les résultats de la validation ont confirmé que les utilisateurs éprouvent des difficultés
à comprendre les prédictions du modèle de forêt aléatoire, perçu comme une « boîte noire ».
L'intégration de techniques d'IA explicable (SHAP, LIME) constituerait une amélioration
significative.

La troisième limite est liée à la taille de l'échantillon de validation. Avec huit participants,
notre validation ne permet pas de généraliser les résultats de manière statistiquement robuste. Une
validation à plus grande échelle, impliquant des planificateurs de plusieurs AREF, serait
nécessaire. La quatrième limite concerne la performance du modèle prédictif. Le coefficient de
détermination de 0,94, bien que satisfaisant, a été obtenu sur un ensemble de données relativement
homogène. La généralisation à d'autres régions nécessiterait un réentraînement sur des données
locales, et la performance n'a pas été évaluée en conditions réelles de prévision, ce qui constitue
une limitation méthodologique.

1.3.3. Retour à la problématique

Page | 25
Au terme de cette validation, il convient de revenir à notre problématique initiale :
comment concevoir un système intelligent, fondé sur les principes de l'Educational Analytics,
capable d'assister les responsables de la micro-planification scolaire au sein de l'AREF Souss
Massa ? Les résultats montrent que le SIAMPS apporte une réponse concrète et opérationnelle, en
intégrant quatre niveaux d'analytics dans un système cohérent et adapté au contexte. L'analyse
descriptive est assurée par le tableau de bord, l'analyse diagnostique par le module cartographique,
l'analyse prédictive par les modèles de projection, et l'analyse prescriptive par le moteur de
simulation.

Les besoins réels des planificateurs, identifiés de manière inductive, portent sur la
centralisation des données, la visualisation spatiale, les outils de projection et l'automatisation des
tâches. Les données mobilisables dans les systèmes existants, principalement MASSAR et les
bases du HCP, sont suffisantes pour alimenter un système d'aide à la décision, sous réserve d'un
travail rigoureux de nettoyage et d'intégration. Les techniques d'analyse les plus adaptées au
contexte combinent des méthodes classiques de projection par cohorte et des méthodes
d'apprentissage automatique, dans un cadre de complémentarité plutôt que de substitution.

Section 2 : Discussion générale et perspectives


2.1. Contributions de la recherche

2.1.1. Contributions scientifiques

Notre recherche apporte plusieurs contributions au champ scientifique de l'Educational


Analytics et de la planification éducative. La première contribution est d'ordre conceptuel : nous
avons proposé un modèle intégrateur qui articule les quatre niveaux d'analytics (descriptif,
diagnostique, prédictif, prescriptif) dans un cadre applicatif spécifique à la micro-planification
scolaire. Ce modèle, ancré dans les travaux fondateurs de Siemens et Long (2011) et enrichi par
les apports de Daniel (2015) et Sajja et al. (2023), constitue à notre connaissance la première
tentative d'application systématique des Educational Analytics au domaine de la planification
scolaire dans le contexte marocain.

Page | 26
La deuxième contribution est d'ordre méthodologique : notre recherche illustre la fécondité
de l'approche inductive dans le domaine de la conception de systèmes d'information. En partant du
terrain plutôt que d'hypothèses théoriques prédéfinies, nous avons pu construire un système
véritablement adapté aux besoins des utilisateurs et au contexte institutionnel. Cette démarche,
inspirée de Thomas (2006) et de la tradition de la Grounded Theory (Strauss et Corbin, 1998),
offre une alternative pertinente aux approches déductives classiques.

La troisième contribution est d'ordre technique : l'intégration d'un module SIG dans le
processus de planification scolaire, couplé à des algorithmes d'analyse spatiale et d'optimisation
de la localisation, constitue une innovation significative. La fonctionnalité d'identification
automatique des zones de tension, combinant indicateurs scolaires et données spatiales, offre un
outil d'aide à la décision inédit pour les planificateurs.

2.1.2. Contributions pratiques

Sur le plan pratique, le prototype SIAMPS constitue un outil fonctionnel déployable par
les planificateurs de l'AREF Souss Massa. Les choix technologiques open source garantissent un
coût d'acquisition nul et une indépendance vis-à-vis de tout éditeur commercial. L'architecture
modulaire permet une mise en service progressive, en commençant par les modules les plus
demandés. Par ailleurs, le prototype peut servir de base à un déploiement dans d'autres AREF du
Maroc, moyennant un paramétrage des données de référence, ce qui constitue un atout dans un
contexte d'harmonisation nationale des pratiques de planification.

2.2. Implications pour les politiques éducatives au Maroc

Les résultats de notre recherche ont des implications directes pour les politiques éducatives
au Maroc, à plusieurs niveaux. Au niveau stratégique, notre travail met en évidence le potentiel
largement sous-exploité des données éducatives disponibles dans les systèmes existants, en
particulier MASSAR. La loi-cadre n° 51.17, qui inscrit la gouvernance et l'amélioration continue
parmi les leviers fondamentaux de la réforme éducative, fournit le cadre juridique favorable à
l'intégration de ces approches analytiques dans le processus décisionnel.

Au niveau opérationnel, notre travail souligne la nécessité de renforcer les capacités


analytiques des équipes de planification au sein des AREF. La formation des planificateurs aux

Page | 27
outils d'analyse de données et aux systèmes d'information géographique apparaît comme un
investissement prioritaire. De même, la mise en place de procédures formalisées pour la collecte,
la validation et la mise à jour des données est un prérequis indispensable. L'expérience de l'IIPE-
UNESCO (2025), qui recommande le renforcement des compétences des planificateurs à l'ère du
numérique, conforte cette analyse.

Au niveau technologique, notre recherche plaide pour une évolution de la plateforme PSP
vers l'intégration de fonctionnalités d'aide à la décision et d'analyse spatiale. L'ajout d'un module
SIG, de tableaux de bord interactifs, et de capacités d'analyse prédictive permettrait de transformer
la PSP en un véritable système d'aide à la décision, au service de l'ensemble des AREF du
Royaume.

2.3. Perspectives de recherche et de développement

2.3.1. Perspectives de recherche

Plusieurs pistes de recherche méritent d'être explorées. La première concerne l'amélioration


des modèles prédictifs par des techniques d'apprentissage profond, notamment les réseaux de
neurones récurrents (RNN) et les modèles LSTM, qui pourraient mieux capturer les dynamiques
temporelles complexes de l'évolution des effectifs scolaires. L'intégration de données exogènes
(économiques, de mobilité, climatiques) pourrait également améliorer la précision des prédictions.

La deuxième piste porte sur l'IA explicable (Explainable AI) dans le contexte de la
planification éducative. Les résultats de notre validation ont montré que l'interprétabilité des
modèles est un facteur critique d'adoption. La recherche sur les méthodes d'explication des
prédictions (SHAP, LIME, attention mechanisms) appliquées au domaine éducatif constitue un
champ encore peu exploré. La question fondamentale est de savoir comment rendre les
recommandations d'un système intelligent suffisamment transparentes pour que les décideurs
puissent les comprendre et les évaluer critiquement.

La troisième piste concerne l'évaluation longitudinale de l'impact du système sur la qualité


de la planification. Une étude comparant les indicateurs de planification avant et après
l'introduction du système sur plusieurs années scolaires permettrait de documenter cet impact de
manière rigoureuse. La quatrième piste porte sur la transférabilité du modèle à d'autres contextes.

Page | 28
Une recherche comparative, déployant le système dans plusieurs AREF aux profils contrastés,
permettrait de tester cette transférabilité et d'identifier les adaptations nécessaires.

2.3.2. Perspectives de développement technique

Sur le plan du développement technique, plusieurs évolutions sont envisagées. La première


est l'intégration d'un module de travail collaboratif, permettant aux planificateurs de différents
niveaux de partager des scénarios et de suivre le processus de décision de manière coordonnée. La
deuxième est le développement d'une application mobile légère pour la saisie de données et la
consultation d'indicateurs depuis un smartphone, facilitant la collecte en milieu rural. La troisième
concerne l'automatisation des imports depuis MASSAR via une intégration directe avec l'API, si
celle-ci était rendue disponible par le ministère.

La quatrième évolution porte sur l'enrichissement du module de simulation par des


techniques d'optimisation multi-objectifs, permettant de rechercher automatiquement les
configurations optimales du réseau scolaire selon plusieurs critères simultanés (accessibilité, coût,
équité, qualité). Enfin, l'intégration de techniques de traitement du langage naturel pourrait ouvrir
de nouvelles perspectives, notamment la génération automatique de synthèses narratives et
l'interaction avec le système par des requêtes en langage naturel, réduisant la barrière technique
pour les utilisateurs non spécialistes.

Conclusion du chapitre 2
Au terme de ce chapitre, la validation du prototype SIAMPS a permis de confirmer sa
pertinence fonctionnelle et son utilisabilité globalement satisfaisante, comme en témoignent un
score SUS moyen de 76,5 et des scores d'adéquation fonctionnelle supérieurs à 3,8 sur 5 pour
l'ensemble des modules. Les retours qualitatifs des participants ont par ailleurs mis en lumière la
valeur ajoutée perçue du système, tout en identifiant des axes d'amélioration importants,
notamment en matière d'interprétabilité des modèles prédictifs et de formation des utilisateurs. Au-
delà de la validation, ce chapitre a permis de situer notre travail dans une perspective plus large,
en soulignant ses contributions au champ de l'Educational Analytics et ses implications pour la
modernisation de la planification scolaire au Maroc. Les perspectives de recherche et de

Page | 29
développement identifiées ouvrent la voie à des travaux futurs visant à enrichir, généraliser et
pérenniser le système proposé.

Page | 30

Vous aimerez peut-être aussi