ThierryM : suite à un besoin exprimé par les enseignant⋅es d’une école et la découverte de SQLPage à travers l’application École Inclusive que j’ai découverte via ce site, je me suis lancé dans la réalisation d’une application en ligne permettant de suivre — sur toute leur scolarité dans le 1er degré — les différentes aides proposées aux élèves rencontrant des difficultés.
Bien que cette application soit encore en cours de développement et de test, je relate ici mon retour d’expérience car SQLPage, qui évolue rapidement, mérite d’être plus largement connue.
Jusqu’à présent je n’avais jamais osé me lancer dans ce genre de développements — principalement à cause de la sécurisation des accès et à la gestion de bases de données — mais SQLPage est arrivé…
Sommaire
- Besoins et cahier des charges
- Début de l’aventure
- Matériel, données techniques et application ASDAEL
- Utilisation locale due au RGPD et à la sécurisation des données
- Captures d’écran
- Perspectives
Besoins et cahier des charges
Le directeur d’une grosse école (13 classes + ULIS) avait besoin de pouvoir suivre pluriannuellement les différentes aides mises en place pour les élèves rencontrant des difficultés, ceci afin que les enseignant⋅es (dont les membres du RASED) disposent d’un historique pour voir ce qui avait déjà été proposé et ainsi décider ce que l’on pourrait mettre en place sans perdre de temps ni redite. Bref, l’idée était de gagner en temps et en efficacité.
Au niveau d’une seule école, un tableur LibreOffice Calc pouvait très bien faire l’affaire et suffire (ce classeur existe d’ailleurs) mais il ne pouvait pas être complété à distance et de façon collaborative facilement :
On aurait pu mettre en place un classeur sur le Nuage-Nextcloud des Apps Éducation proposé par l’Éducation nationale et travailler de façon collaborative en ligne ou en drive (pour profiter des macros). Mais cette solution n’est pas aisée à mettre en place, avec des problèmes de synchronisation et des conflits de version de fichiers (je le sais par expérience, car nous gérons l’absentéisme de cette façon et ça demande un gros accompagnement, chaque classe ayant son propre classeur que l’on doit retravailler par la suite pour faire des synthèses d’école).
L’idée était donc de disposer d’une application Web, en ligne pour que les enseignant⋅es puissent intervenir, compléter les données facilement et directement.
L’avantage de cette solution était aussi de disposer d’une application unique pour étendre par la suite son utilisation aux 4 écoles de la ville (voire d’une circonscription) si le projet est concluant : en effet, les infos des élèves de maternelle suivraient lors du passage à l’école élémentaire.
Seulement voilà, se posent pas mal de contraintes notamment par rapport à la sécurisation des données et au niveau du RGPD, l’outil envisagé contenant des informations sensibles. Il était impossible d’envisager un développement en Html/CSS/Javascript/PHP de zéro (manque de temps et de compétences). Et c’est là, que j’ai découvert l’existence de SQLPage qui paraissait répondre à nos inquiétudes avec des accès sécurisés, tout en étant à la portée de « débutant⋅es », à travers le récit de l’auteur de l’application « École Inclusive ».
Début de l’aventure
L’application « École Inclusive », bien que conçue pour le second degré, pouvait être adaptée à nos besoins plus modestes et a donc servi de base de départ : c’est beaucoup plus facile de partir de l’existant que d’une page blanche où il faut tout construire. Il s’est avéré que nous n’avions pas besoin de toutes les fonctionnalités et qu’il a fallu reprendre les logiques de fonctionnement mais la base étant là, c’était très rassurant d’autant que l'auteur de « École Inclusive » et le concepteur de SQLPage, très disponibles, étaient là pour m’éclairer, me conseiller ou rajouter des fonctionnalités au fil de mes demandes via les pages GitHub de leur projet respectif. Il faut rajouter que le site de SQLPage, conçu avec SQLPage ;-), regorge de ressources avec une documentation (en anglais) très claire et facilitante avec des exemples.
Il est vrai que ce concept de programmation est assez déstabilisant au début : ne passer que par des fichiers .sql (ou presque) pour développer un site Web, ça paraît inadapté. Mais, une fois qu’on est rentré dedans, on se rend compte que pour le type d’application qu’on recherchait, c’est tout bonnement bluffant et terriblement efficace.
Ce qui est aussi facilitant, c’est la possibilité d’utiliser des bases sqlite ne nécessitant pas la mise en place d’un serveur de type MySQL ou PostGreSQL rajoutant de la complexité. Mais SQLPage fonctionne aussi avec ces serveurs si on en a l’utilité : ce point est intéressant, car le temps consacré pour se former à SQLPage pourra être réinvesti avec d’autres types de bases de données.
Matériel, données techniques et application ASDAEL
Pour des tests les plus proches du fonctionnement prévu (on verra que ça changera), j’ai utilisé un NAS perso Synology 713+ sous DSM 7.1 avec un accès extérieur. Toutes les infos sont là pour ceux et celles que ça intéresse : https://lofurol.fr/joomla/logiciels-libres/104-bases-de-donnees/349-sqlpage-utilisation-sur-un-nas-synology-avec-docker-et-mysql-postgresql-sqlite.
Toujours dans un souci de partage, les sources de l’application de suivi des aides sont disponibles sur la « Forge des communs numériques éducatifs » ou Forge Éduc, le GitLab mis à disposition par l’Éducation nationale pour favoriser le partage et le développement de ressources numériques pour l’enseignement.
Source du projet: https://forge.apps.education.fr/thierrym/suivi-aides-eleves-ecoles
Utilisation locale due au RGPD et à la sécurisation des données
Cette application n’ayant pas reçu de soutien officiel et vu qu’elle contient des données sensibles sur les élèves (bien que ces données ne soient accessibles qu’aux seul⋅es enseignant⋅es concerné⋅es par le suivi des élèves), il a été décidé de ne pas exposer l’application sur Internet, comme prévu initialement. Elle sera donc installée sur un ordinateur localement sans accès de l’extérieur le temps de la tester. Après, il sera toujours possible d’évoluer vers une utilisation réellement en ligne si les essais sont concluants (et avec un audit sur la sécurité).
Et là, encore une fois, l’application est très bien faite, car elle fait office de serveur web et il suffit de saisir son adresse ip sur le port 8080 pour y accéder à partir d’un autre ordinateur sur le même réseau. On ne peut pas faire plus simple (pas besoin de se monter un serveur Apache/Ngnix) !!!
Pour lancer l’expérimentation, j’ai récupéré un “vieil” ordinateur HP 260 G2 Mini (Intel Pentium 4405U, 4 Go de Ram et HD de 100 Go) sur lequel j’ai installé Ubuntu 24.04 Server (avec accès SSH) avec le bureau Mate et Docker pour faire fonctionner les conteneurs Portainer et Adminer pour éventuellement agir sur la base de données SQLite.
J’ai ensuite installé SQLPage avec mes fichiers dans un dossier « ASDAEL » à la racine de mon home puis configurer un démarrage automatique lançant SQLPage et Firefox pointant vers la page « localhost:8080 ».
Captures d’écran
Structure de la base de données
Page d’accueil :
Page de connexion :
Localisation des écoles :
Liste des élèves suivi⋅es :
Fiche individuelle de suivi :
Vue synthétique du parcours de l’élève :
Page de paramétrage :
Perspectives
Avec l’arrivée du Livret de Parcours Inclusif (LPI) peut-être que ce genre d’applications ne sera plus utile… d’autant qu’elles n’ont aucun soutien institutionnel et qu’en l’état actuel elles ne peuvent être utilisées que localement, ce qui réduit pas mal leur intérêt.
Mais l’idée de ASDAEL est d’obtenir rapidement une vision synthétique des différentes aides mises en place pour l’ensemble des élèves tout au long des années en facilitant leurs saisies, ce que ne permettra certainement pas le LPI.
À suivre… ?
# un pavé de DB
Posté par gaaaaaAab . Évalué à 10 (+15/-0). Dernière modification le 03 juillet 2025 à 16:31.
Préambule: ayant eu plusieurs fois l'occasion de maintenir/concevoir des modèles de DB pour des appli serveurs relativement complexes et au cycle de vie relativement long, je vois des trucs qui me font tiquer (ou qui soulèvent simplement des questions) dans le modèle de DB.
Je sais que la modélisation de DB, c'est pas le truc le plus évident, et c'est souvent le parent pauvre du dév. Donc je salue le travail accompli, et livre des commentaires que j'espère constructifs.
Disclaimer: pas d'argument d'autorité ici, p-e que certaines de mes remarques auront un ton péremptoire (parce que c'est comme ça que j'écris) mais ce ne sont que des propositions/questions. D'autant que je ne connais pas le domaine, il y a des informations que j'ignore qui modifieraient probablement mes remarques.
PS: J'avais raté la mention de SQL page sur la nouvelle que tu références. Je suis allé jeter un oeil, et le modèle de DB proposée par école inclusive, et mes remarques ne semblent pas s'y appliquer.
(quand j'écris
truc.machin, ça veut dire que je fais référence à la colonnemachinde la tabletruc. Par exemple, la colonneidde la tableeleve=>eleve.id)sur la forme, je recommande d'essayer d'être homogène sur le nommage des tables et colonnes. Donc:
tout au singulier (
actions->action,niveaux->niveau,_sql_migrations->_sql_migration)pas de nom de colonne qui font référence au nom de la table. Par exemple,
enseignant.name_ens->enseignant.name, ça suffit. En SQL, si on prend l'habitude de toujours référencer les colonnes avec leur origine, ce n'est jamais ambigu. D'autre part, quand un colonne référence le nom de table, c'est pénible si on a plus tard une bonne raison de renommer la table. On se retrouve alors avec deux mauvaises options, soit renommer la colonne (et propager ça dans tout le code), soit ne pas la renommer, et se retrouver avec un nom de colonne incohérent.suffixe
_idtant que possible, réserver le suffixe
_idaux colonnes qui pointent vers des clefs étrangères. (ici,parcours.dispositif_id, est-ce que ça fait référence à une table dispositif non représentée dans cette capture d'écran ? Si oui, ok, sinon, voir si on peut trouver un autre nom de colonne)et systématiser son usage. (
enseignant.etab_ens->enseignant->etab_id, …)ajouter des id techniques sur les toutes les tables (par exemple,
niveau.id) et donc,eleve.niveau->eleve.niveau_id. Si, pour une raison quelconque, en ajoutant des colonnes, on doit faire porter la contrainte de clef primaire sur deux champs, il faut modifier toutes tables qui ont une contrainte de clef étrangère sur cette table). Perso, je préfère garder ma contrainte de clef étrangère sur les ID, et rajouter les contrainte d'unicité/non nullité nécessaires.homogénéiser l'ordre des colonnes (par exemple, (id, *_id, reste des colonnes)) dans les scripts de création de la DB.
sur la structure:
clefs étrangères
la table
parcoursa trop de clefs étrangères à mon goût. Parfois, la meilleure alternative, c'est bien d'avoir plusieurs clefs étrangères. D'ailleurs, deux clefs étrangères, c'est complètement normal (pour modéliser les relations de cardinalitén,n, il n'y a pas le choix). Mais à partir de 3, perso, je regarde si j'ai pas d'autres options.risque d'incohérence des données:
Certaines tables de la structure actuelle sont reliées à d'autres tables par plusieurs chemins. C'est parfois ce qu'ont veut, mais la plupart du temps, on ne veut qu'une seule façon de relier deux tables. Par exemple, ici,
eleve.etab_idfait le lien entreeleveetetablissement. Mais on peut aussi passer pareleve.enseignant_id, puisenseignant.etab_ens). Si c'est un cas normal qu'un enseignant suive des élèves d'un autre établissement que le sien, ce n'est pas forcément un problème. (Il semble aussi y avoir une duplication deeleve.etab_UAI, également un risque de incohérence)Cette remarque est valable pour
parcours (eleve_id, etab_id, enseignant_id), ou on a même trois chemins pour rejoindre la tableetablissement.
adéquation modèle/cardinalité
Je signale ce risque d'incohérence sur cet exemple
eleve/enseignant. Mais en fait, il y a potentiellement un problème plus fondamental sur cette relationeleve/enseignant. Par exemple, si le suivi peut avoir lieu sur plusieurs années, et si unenseignant(ou eleve)change d'établissement entre deux années, la relationeleve/enseignantn'est plus une relation de cardinalité1,n, mais de cardinalitén,n. Or on ne peut utiliser les clefs étrangères que pour modéliser des relations1,*. Dès que c'est dun,n, une table dédiée est nécessaire.classe
Faut-il une entité
classe? (user_info.classe, enseignant.class_ens, eleve.classe, parcours.classe). Sans plus d'infos, ça ressemble à une potentielle duplication de données.association implicite
Dans la table
parcours, le fait qu'une partie des colonnes s'appellent "action_" suggèrent qu'il y a une entité implicite, l'entité "action" qui mérite p-e d'être modélisée en tant que telle. D'ailleurs, il y a une tableactions, ce qui me fait penser que les champsparcours.action_*sont plutôt des attributs d'une relation entreparcoursetactions.Mon expérience, c'est qu'on finit souvent pas regretter de ne pas avoir investi un peu plus de temps sur la modélisation de la DB au début d'un projet.
C'est pour ça que je recommanderais de faire un modèle type entité-association en plus (voire avant) d'avoir le modèle technique. Ce n'est jamais trop tard pour le commencer.
Ça permet de prendre du recul sur ce qu'on modélise, et fait souvent économiser de la complexité lors de l'implémentation. C'est bien aussi de garder la question des formes normales en tête.
A noter que ce modèle entité-association ne peut pas être généré automatiquement. On ne peut pas inférer les cardinalités des relations à partir du seul modèle technique de la DB.
PS: Ça se voit que j'aime bien modéliser les DB ou pas ? :o)
# Commentaire supprimé
Posté par EdelmiraBanda . Évalué à -7 (+0/-7). Dernière modification le 04 juillet 2025 à 08:01.
Ce commentaire a été supprimé par l’équipe de modération.
# Très bien
Posté par Luc-Skywalker . Évalué à 3 (+1/-0). Dernière modification le 03 juillet 2025 à 17:20.
ça se dit à l'école non ?
Intéressant, bonne piqûre de rappel:
J'avais un peu joué avec SQLPage et trouvé l'application épatante.
En effet et selon mes souvenirs c'est là que j'ai vu LA grosse limitation de SQLPage.
Mais, dès que j'aurais un cas pratique à mettre en œuvre je n'hésiterais pas à me re pencher dessus.
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: Très bien
Posté par lovasoa (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 03 juillet 2025 à 18:48.
Je pense que l'auteur ne parlait pas d'une restriction technique mais d'une limitation demandée à cause de l'utilisation de données personnelles des élèves, comme mentionné plus haut dans la dépêche.
Sinon, les applications SQLPage sont assez faciles à héberger en ligne, normalement. Avec editor.datapage.app c'est même un seul clic ;)
[^] # Re: Très bien
Posté par Luc-Skywalker . Évalué à 2 (+0/-0).
Ah merci pour la précision.
Raison de plus pour s'y re pencher.
"Si tous les cons volaient, il ferait nuit" F. Dard
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.