Cette dépêche présente Zaibu, une application web auto-hébergeable permettant de conserver un journal structuré de ses dégustations de bières et de vins. Développée avec SQLPage, elle met l’accent sur la simplicité, l’indépendance et le respect de la vie privée. Contrairement aux solutions centralisées comme Untappd ou Vivino, Zaibu ne collecte aucune donnée et reste entièrement sous le contrôle de l’utilisateur.

Note : n’ayant absolument aucune compétence ni aucun talent en graphisme, le logo a été créé avec Bing Image Creator et retravaillé et vectorisé par mes soins. Je sais, çaymal.

Sommaire

• • Pourquoi créer Zaibu ?
    • Un besoin personnel
    • Une occasion de tester SQLPage
  • Une approche libre et auto-hébergeable
  • Une interface simple et accessible
  • Et maintenant ?

L’alcool est dangereux pour la santé, même en petite quantité. Le vin et la bière, comme les autres alcools, induisent une dépendance et tuent. Il est recommandé de ne pas consommer plus de 2 verres par jour, et de ne pas boire d’alcool au moins 2 jours par semaine. Si vous avez des doutes sur votre consommation, n’hésitez pas à contacter un professionnel de santé.

Pourquoi créer Zaibu ?

Zaibu répond avant tout à un besoin très concret : garder une trace de ses dégustations de boissons (uniquement bières et vins pour l’instant) sans dépendre d’applications trop encombrées ou propriétaires qui exploitent les données de leurs utilisateurs.

Ce projet est en fait l’évolution d’un simple fichier texte mis en forme selon une structure plus ou moins régulière. Il était à l’origine partagé via Nextcloud, un service de stockage et de synchronisation de fichiers, libre et auto-hébergeable. Pour passer de ce fichier brut à une véritable application, plusieurs outils ont été utilisés:

• Makefile : un fichier de configuration pour GNU Make, permettant d’automatiser diverses tâches (ici, la conversion du fichier texte).
• Gawk : une version libre de l’outil AWK, qui lit et transforme le contenu du fichier texte pour l’adapter au format voulu.
• textql : un utilitaire en ligne de commande qui interprète des fichiers texte (CSV, TSV…) comme des tables SQL, ce qui facilite le chargement des données dans une base SQLite.

Grâce à cette chaîne d’outils, le fichier texte initial a pu être converti en une base de données exploitable, pour ensuite alimenter l’application Zaibu.

Pour ceux qui collectionnent les bouteilles comme d’autres collectionnent les timbres, c’est un outil pratique et léger, conçu pour être maîtrisé de bout en bout : le code source est distribué sous licence libre (AGPLv3), l’application est facile à héberger sur son propre serveur, et consomme très peu de ressources.

Un objectif secondaire était de tester les capacités de l’outil SQLPage pour le développement rapide d’applications de gestion de données.

Un besoin personnel

Il peut être difficile de se souvenir d’une bonne bière artisanale goûtée l’année passée ou du vin qui vous a tant plu à un mariage. Un carnet de notes ou un tableau dans un logiciel de bureautique peuvent dépanner, mais on s’y perd vite, et ce n’est pas toujours très pratique à consulter sur son téléphone quand on est en pleine dégustation.

Zaibu propose un formulaire simple où vous pouvez renseigner le nom, le producteur, le style, l’amertume, le taux d’alcool, vos impressions… Une fois la dégustation terminée, vous conservez une trace précise, consultable à tout moment. En un coup d’œil, vous pouvez comparer vos différents coups de cœur ou vous rappeler pourquoi un vin particulier ne vous avait pas convaincu.

Une occasion de tester SQLPage

Zaibu a aussi été conçu comme une démonstration technique. Il a servi de terrain d’expérimentation pour un nouvel outil, SQLPage, qui permet de créer une application web de gestion et d’affichage de données complète sans s’encombrer de milliers de lignes de code. En partant de requêtes de bases de données très simples, on obtient un site fonctionnel rapidement.

Ici il s’agit d’une application de type CRUD dans sa plus simple expression, donc parfaitement adaptée à être écrite en pur SQL. Même si certains traitements nécessitent de se creuser un peu plus la tête quand rien d’autre n’est disponible, il existe généralement une manière d’arriver à ses fins (et on découvre parfois avec bonheur des subtilités du langage qu’on ignorait !).

C’est le framework parfait pour créer rapidement ses propres outils tout en gardant la maîtrise complète de sa donnée, en utilisant une base de données que l’on peut héberger soi-même facilement.

Une approche libre et auto-hébergeable

De nombreuses applications existent déjà, mais elles imposent souvent la création d’un compte, exploitent les données des utilisateurs et monétisent leur activité via la publicité ou des abonnements. Zaibu prend le contre-pied en offrant une solution entièrement libre, légère et indépendante.

L’application repose sur SQLite, un système de gestion de base de données qui se distingue des bases de données traditionnelles comme MySQL ou PostgreSQL. Contrairement à ces dernières, qui nécessitent un serveur dédié fonctionnant en arrière-plan pour gérer les requêtes et stocker les informations, SQLite est une base de données embarquée.

Cela signifie que toutes les données sont enregistrées directement dans un fichier unique sur l’ordinateur ou le serveur où l’application est installée. Il n’y a donc pas besoin d’installer et de configurer un logiciel supplémentaire pour gérer la base de données. Cette approche simplifie considérablement l’installation et l’utilisation de l’application, surtout pour des utilisateurs qui ne sont pas familiers avec l’administration de serveurs.

Et puis bien sûr, son code est ouvert. C’est comme une bière artisanale : vous savez exactement quels ingrédients sont utilisés, comment ils interagissent, et si l’envie vous prend, vous pouvez modifier la recette pour l’adapter à vos préférences. Vous pouvez la brasser tel quel, y ajouter une touche personnelle, ou même la partager améliorée avec d’autres passionnés. Ici, tout est transparent et modifiable.

Une interface simple et accessible

Pensée pour une utilisation mobile et desktop, l’interface de Zaibu permet d’ajouter rapidement une dégustation, sans fioritures. Sur smartphone, il devient facile de consulter ses notes en magasin ou chez un caviste pour retrouver une référence appréciée ou éviter une déception.

Et maintenant ?

Zaibu est encore jeune et perfectible. L’application pourrait évoluer avec des fonctionnalités comme le partage entre utilisateurs ou l’intégration d’une base collaborative… N’hésitez pas à faire vos retours dans les commentaires !

Et si le principe vous intéresse, vous pouvez aussi découvrir Mon petit potager du même auteur et construit sur le même framework, cette fois pour suivre les récoltes de son jardin et la pluviométrie.

L’archéologie est un domaine qui, depuis ses débuts, s’attache au catalogage, à la structuration et l’archivage de données issues de fouilles. Sur le terrain, elle a longtemps reposé sur la création de fiches, la collecte manuelle d’information sur papier, et le dessin à la main, retranscrit lors des phases d’étude sur support numérique. Ce n’est que récemment que certains archéologues ont lancé le mouvement de la fouille « tout numérique ». Je vous propose de raconter ici l’histoire de la numérisation de l’archéologie, qui, comme vous allez le voir, repose en partie sur le logiciel libre.

Sommaire

• Qu’est-ce qu’un chantier de fouilles ?
• Pratique de l’archéologie : exemple dans le préventif
• Le début de la numérisation
• Le mouvement tout numérique
  • Principe général
  • Logiciels et formats libres
  • Badass, spatial et attributaire réunis
  • Pour entrer dans Badass : la Bad’Mobil
• Cas d’utilisation et bénéfices concrets
  • Première expérience aux Mastraits
  • Perspectives d’avenir
• Conclusion

Qu’est-ce qu’un chantier de fouilles ?

L’archéologie française se divise en deux branches principales : l’archéologie préventive, qui intervient lors de projets de construction, et l’archéologie programmée, menée sur des sites choisis pour répondre à des problématiques de recherche. Supervisées par les Services Régionaux de l’Archéologie du Ministère de la Culture, ces activités sont réalisées par différents organismes : opérateurs publics et privés pour l’archéologie préventive, et associations, CNRS ou universitaires pour l’archéologie programmée. Cette dernière mobilise souvent des bénévoles, notamment des étudiants, leur offrant une formation pratique complémentaire.

Pour l’archéologue, la fouille est un outil, et non un but en soi. Ce que l’archéologue cherche, c’est de l’information. En substance, il s’agit de comprendre l’histoire d’un site, son évolution, ses habitants à travers les éléments qu’ils ont laissés derrière eux, que ce soit les ruines de leurs habitats, de leurs activités artisanales ou leurs sépultures. Ceci est d’autant plus important que la fouille est un acte destructeur, puisque l’archéologue démantèle son sujet d’étude au fur et à mesure de la fouille.

Pour être exploitée, l’information archéologique doit être organisée selon des principes bien établis. Le premier concept clé est la couche sédimentaire (Unité Stratigraphique - US), qui témoigne d’une action humaine ou d’un phénomène naturel. L’étude de l’agencement de ces couches révèle la chronologie du site, la succession des évènements qui s’y sont déroulés. Ces couches peuvent être regroupées en faits archéologiques : fossés, caves, sépultures, sont en effet des regroupements de couches qui définissent un élément spécifique. Enfin, les objets trouvés dans ces couches, ou mobiliers, sont catalogués et identifiés par leur couche d’origine, fournissant des indications chronologiques et culturelles cruciales.

Le chantier de fouilles de la Nécropole des Mastraits, à Noisy-le-Grand (93).

Les actions menées par l’archéologue tout au long du chantier sont également enregistrées. En effet, l’archéologue procède à des sondages, réalise des tranchées, mais fait aussi de nombreuses photos, ou des dessins de tout ce qu’il découvre au fur et à mesure de l’avancement du chantier. La documentation produite peut être pléthorique, et un catalogage indispensable.

Cette information descriptive est complétée par une information spatiale, le plan des vestiges mis au jour étant essentiel pour l’analyse et la présentation des résultats. L’étude de ce plan, associée aux informations descriptives et chronologiques, met en évidence les grandes évolutions du site ou des détails spécifiques. Sa réalisation est généralement confiée à un topographe en collaboration avec les archéologues.

À l’issue de la phase de terrain, une phase d’analyse des données collectées est réalisée. Cette phase dite de post-fouille permet de traiter l’ensemble des informations recueillies, d’en réaliser la description complète, d’effectuer les études nécessaires à la compréhension du site en faisant appel à de nombreux spécialistes : céramologues, anthropologues, archéozoologues, lithiciens, carpologues, anthracologues, spécialistes de la paléométallurgie, etc.

Cette phase de post-fouille aboutit dans un premier temps à la réalisation d’un rapport d’opération, compte rendu le plus exhaustif possible du site et de son évolution. Ces rapports sont remis au ministère de la Culture qui en juge la qualité. Ils ne sont pas destinés à être largement diffusés, mais sont normalement accessibles à toute personne qui en fait la demande auprès de l’administration concernée. Ils sont une base de travail importante pour l’ensemble de la communauté scientifique.

Sur la base de ce rapport, la publication d’articles dans des revues spécialisées permet de présenter les résultats de l’opération plus largement, parfois en fonction de certaines thématiques ou problématiques spécifiques.

Pratique de l’archéologie : exemple dans le préventif

L’utilisation de très nombreux listings papier est une constante. Ces listings permettent de tenir à jour l’enregistrement de la donnée sous forme de tableaux d’inventaire des couches, des faits, des sondages, des photos, etc. Des fiches d’enregistrement spécifiques sont également utilisées dans de nombreuses spécialités de l’archéologie, telle que l’anthropologie funéraire.

Sur le terrain, les éléments mis au jour sont encore pour une très grande majorité dessinés à la main, sur papier calque ou millimétré, qu’il s’agisse d’un plan de vestiges ou des nombreux relevés de coupe stratigraphique. Ceci demande bien entendu un temps important, en particulier en cas de vestiges complexes.
L’utilisation de tachéomètres électroniques, puis du GPS différentiel a permis de se passer des décamètres, ou des systèmes de carroyage, lors de la fouille des sites. Des topographes, spécifiquement formés, ont alors commencé à intervenir sur site pour la réalisation des plans généraux.

La collection documentaire obtenue à l’issue d’un chantier de fouille est particulièrement précieuse. Il s’agit là des seuls éléments qui permettront de restituer l’histoire du site, en croisant ces données avec le résultat des études réalisées. La crainte de la disparition de ces données, ou de leur utilisation par autrui du fait d’une découverte remarquable, est un sentiment souvent partagé au sein de la communauté archéologique. L’archéologue peut se sentir dépositaire de cette information, voire exprimer un sentiment de possession qui va tout à fait à l’encontre de l’idée de science partagée et ouverte. L’idée que l’ouverture de la donnée est le meilleur moyen de la protéger est loin d’être une évidence.

Fiche de conservation, illustrant le coloriage manuel des parties de squelette retrouvées

Exemple, parmi tant d’autres, de fiche descriptive vierge d’une couche archéologique

Le début de la numérisation

C’est essentiellement après la phase terrain que les outils numériques ont été apprivoisés par les archéologues.

En post-fouille, la documentation papier est encore souvent une base documentaire fondamentale pour l’analyse du site. L’irruption de l’informatique au milieu des années 80 a conduit les archéologues à transcrire cette donnée sous forme numérique, afin de faciliter son analyse et sa présentation. Bien que les logiciels aient évolué, le processus est pratiquement le même aujourd’hui, avec une numérisation de la documentation sous de nombreux formats.

Les listings peuvent être intégrés à des bases de données (le plus souvent propriétaires tel MS Access, FileMaker ou 4D) ou des tableurs. De nombreuses bases ont été développées en interne, localement, par les archéologues eux-mêmes. Uniquement attributaires, elles se sont progressivement mises en réseau et adaptées au support, permettant d’envisager un usage sur le terrain, sans que ceci ne soit largement déployé.

Exemple d’une base de données au tournant des années 2000

Toute la documentation dessinée sur le terrain est amenée à être redessinée au propre sur support numérique, dans des logiciels de dessin vectoriel, très souvent Adobe Illustrator, parfois Inkscape.
Les données en plan, levées par le topographe, sont réalisées sous Autocad et étaient exportés en .dxf ou .dwg avant d’être remis au propre sous Adobe illustrator, ce qui est le cas également des dessins réalisés sur le terrain.
Le mobilier est confié à des spécialistes qui le décrivent, le dessinent, en dressent l’inventaire, le plus souvent dans des tableurs. Leurs dessins sont là encore scannés et remis au propre numériquement.

Avec le recul, nous constatons que les outils numériques sont majoritairement utilisés comme des outils de mise au propre de l’information collectée sur le terrain. Bien des tableurs ne sont ainsi que la stricte transcription des tableaux papier utilisés par les archéologues, auquel on ajoutera quelques totaux, moyennes ou médianes. Les dessins réalisés sur papier, sont décalqués dans des logiciels de vectorisation pour plus de lisibilité et les plus-values scientifique sont finalement assez limitées.

Il en résulte une documentation numérique relativement disparate, avec l’usage de nombreux outils propriétaires, des formats fermés, et une séparation très forte entre l’information spatiale et l’information descriptive (ou attributaire).

L’usage progressif des bases de données a cependant permis d’agglomérer certaines données et de rassembler et mettre en relation l’information. Des travaux universitaires ont également permis d’alimenter la réflexion sur la structuration des données archéologiques et de former de nombreux archéologues, permettant d’adopter des pratiques plus vertueuses.

Le mouvement tout numérique

Jusqu’à présent, passer au tout numérique dans le cadre archéologique semblait relativement utopique. Il a fallu que de nouvelles technologies apparaissent, que des supports portables et simples d’usage se mettent en place, que les réseaux se développent, et que les archéologues s’emparent de ces nouveaux outils.

Le collectif Ramen (Recherches Archéologiques en Modélisation de l’Enregistrement Numérique) est né des échanges et des expériences de divers archéologues de l’Institut National De Recherches Archéologiques Préventives (Inrap) qui se sont regroupés autour de la réalisation de la fouille programmée de la nécropole médiévale de Noisy-Le-Grand, fouille gérée par l’association Archéologie des Nécropoles et confiée à la direction scientifique de Cyrille Le Forestier (Inrap). Cette fouille programmée a permis de lancer une expérimentation sur la complète dématérialisation de la donnée archéologique en se basant sur la photogrammétrie, le SIG, et une base de données spatiale.

Principe général

Si le topographe intervient bien toujours pour la prise de points de référence, le relevé détaillé des vestiges est assuré, pour cette expérimentation, par la mise en œuvre de la photogrammétrie de manière systématique. Cette méthode permet, par la réalisation de multiples photos d’un objet ou d’une scène, de réaliser un modèle 3D précis, et donc exploitable à postériori par l’archéologue en post fouille. La photogrammétrie constitue à Noisy l’unique outil de relevé, remplaçant purement et simplement le dessin sur papier. En effet, à partir de ce nuage de points 3D, il est possible d’extraire de multiples supports en 2D et d’ajouter la géométrie ou des informations supplémentaires dans la base de données: contours de la sépulture, représentation du squelette in situ, profils, mesures, altitudes, etc.

Relevé photogrammétrique d’une sépulture

L’enregistrement des données est assuré par l’utilisation d’une base de données relationnelles et spatiales dont l’interface est accessible dans QGIS, mais également via une interface web directement sur le terrain, sans passer par des inventaires ou listing papier. L’interface web a été réalisée grâce à SQLPage, serveur web qui utilise un langage à base de SQL pour la réalisation de l’interface graphique, sans avoir à passer par les langages de programmation plus complexes classiquement utilisés pour la création d’applications web, tel PHP.

Bien entendu, cette démarche se poursuit également en laboratoire lors de l’étape d’analyse du site.

Logiciels et formats libres

Mais l’abandon du support papier nécessite de nous poser la question de la pérennité des fichiers et des données qu’ils contiennent.

En effet, dans un processus de dématérialisation complet, la mémoire du site n’est plus contenue sur des centaines de fiches manuscrites, mais dans des fichiers numériques dont nous ignorons à priori si nous pourrons les conserver sur le long terme. L’impossibilité d’accéder à cette donnée avec d’autres logiciels que ceux originellement utilisés lors de leur création équivaut à leur destruction. Seuls les formats standards peuvent répondre à cette problématique, et ils sont particulièrement utilisés par les logiciels libres. Pour la photogrammétrie, les formats .ply et .obj, qui sont implémentés dans de nombreux logiciels, libres et propriétaires, ont été choisis. Pour la donnée attributaire et spatiale, elle est enregistrée dans des bases de données relationnelles libres (Spatialite et Postgis), et facilement exportable en .sql, qui est un format standardisé et reconnu par de très nombreuses bases de données.

Malheureusement, le logiciel libre reste peu utilisé dans notre quotidien archéologique, et les logiciels propriétaires sont souvent très bien implantés. Le libre souffre encore aujourd’hui d’a priori et d’une mauvaise image au sein de la communauté archéologique, qui le trouve plus compliqué, moins joli, moins efficace, etc.

Le libre a cependant fait une incursion majeure avec l’arrivée du Système d’Information Géographique (SIG) libre QGIS, qui a permis d’installer un SIG sur tous les postes des agents de l’institut et de l’envisager comme un outil d’analyse à l’échelle d’un site archéologique. Par un accompagnement et la mise en place d’un plan de formation adéquat, de nombreux archéologues ont été formés à l’usage du logiciel au sein de l’Institut.

QGIS a véritablement révolutionné nos pratiques en permettant l’interrogation immédiate de la donnée attributaire par la donnée spatiale (quel est ce vestige que je vois sur le plan ?) ou, à l’inverse, de localiser un vestige par sa donnée attributaire (où se trouve la sépulture 525 ?). Il est cependant très fréquent d’avoir encore d’un côté la donnée attributaire dans des tableurs ou des bases de données propriétaires, et la donnée spatiale dans QGIS, l’interrogation des deux reposant sur des jointures.

Bien entendu, QGIS permet aussi l’analyse des données, la création de plans thématiques ou chronologiques, indispensables supports à nos réflexions. Nous pouvons, à partir de ces éléments, réaliser les très nombreuses figures du rapport d’opération, sans passer par un logiciel de dessin vectoriel, en plan comme en coupe (représentation verticale de la stratigraphie). Il permet de normaliser les figures par l’emploi des styles, et, par l’usage de l’outil Atlas, de réaliser des catalogues complets, pour peu que la donnée soit rigoureusement structurée.

Exemple d’analyse dans Qgis de répartition des rejets de céramique sur un site gaulois

Dans le cadre de l’expérimentation sur la nécropole des Mastraits, Si Qgis est bien un des piliers du système, quelques logiciels propriétaires sont encore employés.

Le logiciel de traitement utilisé pour la photogrammétrie est propriétaire. L’objectif à terme est de pouvoir utiliser un logiciel libre, MicMac, développé par l’IGN, étant un possible candidat. Il manque cependant encore d’une interface pleinement intuitive pour que les archéologues puissent s’approprier l’outil de manière autonome.

De même, les enthousiasmantes dernières évolutions du projet Inkscape devraient nous inciter à nous tourner davantage vers ce logiciel et à utiliser de manière systématique le .svg. L’usage de Scribus pour la PAO devrait également être sérieusement envisagée.

Le logiciel libre et ses indéniables avantages prend ainsi doucement place, essentiellement via QGIS, dans la chaîne de production de nos données archéologiques. Nous ne pouvons qu’espérer que cette place grandira. Le chemin paraît encore long, mais la voie libre…

Badass, spatial et attributaire réunis

Le développement de la Base Archéologique de Données Attributaires et SpatialeS a eu comme objectif d’intégrer, au sein d’une seule et même base de données, les informations attributaires renseignées par les archéologues et les informations spatiales recueillies par le topographe. Il s’agit même de rassembler, au sein des tables dédiées, les informations attributaires et spatiales, garantissant ainsi l’intégrité de la donnée.
Son principe s’appuie sur le fonctionnement de la chaine opératoire en archéologie, à savoir l’identification et l’enregistrement par l’archéologue des vestiges mis au jour, auquel succède le relevé tridimentionnel réalisé par le topographe. Ce dernier dispose, dans la base de données, de tables spécifiques dans laquelle il peut verser la géométrie et des données attributaires minimales (numéro, type). Des triggers vont ensuite alimenter les tables renseignées par les archéologues avec la géométrie, selon leur identifiant et leur type.

La base est ainsi l’unique dépositaire de l’information attributaire et spatiale tout au long de l’opération, du terrain à la post fouille.

Le format de la base de données est à l’origine SpatiaLite. Mais la masse documentaire produite par la nécropole des Mastraits nous a conduit à la porter sous PostGIS. Nombre d’opérations archéologiques ne nécessitent cependant qu’une petite base SpatiaLite, qui permet en outre à l’archéologue d’avoir la main sur son fichier de données. Seuls quelques gros chantiers peuvent avoir besoin d’une solution PostgreSQL, par ailleurs utilisée pour le CAtalogue de VIsualisation ARchéologique (Caviar) qui a vocation à accueillir les données spatiales et attributaires produites à l’institut.

Naturellement, Badass a été couplée à un projet QGIS proposant déjà des styles par défaut, mais aussi quelques requêtes ou vues communément utilisées lors d’une étude archéologique. Une extension QGIS a été développée par plusieurs étudiants afin de permettre la génération automatique du projet et de la base de données.

Pour entrer dans Badass : la Bad’Mobil

Il restait la question de la portabilité de ce système. QGIS est un logiciel demandant beaucoup de ressource et dont l’interface est inadaptée aux petits écrans, appréciés pour leur portabilité sur le terrain (téléphones et tablettes).

Choisir d’utiliser une base SpatiaLite ou PostGIS permettait d’envisager dès le départ une interface web, qui pourrait alors être utilisée sur n’importe quel terminal. Il avait d’abord été envisagé de lancer un développement en PHP/HTML/CSS avec un serveur web Apache. Mais ceci nécessitait de disposer d’un serveur web, et de programmer toute une interface. Il restait aussi à répondre à quelques questions d’infrastructure : où l’héberger, quels financements pour cela, et qui pour administrer l’ensemble ?

C’est ici même, sur LinuxFR, que l’un des membres du collectif a découvert SQLPage. Ce logiciel libre, développée par lovasoa, permet de disposer d’un serveur web très simple, et la réalisation d’une application de type CRUD avec une interface dont le développement ne repose que sur du SQL.

SQLPage repose sur un fichier exécutable, qui, lancé sur un poste informatique, transforme celui-ci en serveur web. Un fichier de configuration permet de définir notamment l’emplacement de la base de données qui sera interrogée. Pour chaque page web de l’interface, on écrit un fichier .sql pour définir les données à aller chercher ou modifier dans la base, et les composants d’interface qui permettront de l’afficher (tableaux, formulaires, graphiques…). L’accès à cette interface se fait dans un navigateur web. Si le poste est en réseau, l’adresse IP du poste permet d’y accéder à distance, avec une adresse comme http://192.168.1.5:8080 par exemple. L’utilisation d’un VPN nous permet d’utiliser le réseau de téléphonie mobile, ce qui nous dispense de toute mise en place d’un réseau local avec routeur, antennes, etc.

Principe de fonctionnement général

Ainsi, l’installation de l’ensemble est très simple et ne repose que sur une arborescence de fichiers à déployer sur le poste serveur : la base de donnée, et un répertoire contenant le binaire SQLPage et les fichiers constituant les pages web.

En nous appuyant sur la documentation (et en posant parfois des questions à l’auteur du logiciel), nous avons pu développer seuls une interface très complète répondant bien à nos besoins sur le terrain. Nommée Bad’Mobil, l’interface web permet d’accéder à l’ensemble des données attributaires renseignées par les archéologues et permet désormais, grâce aux évolutions constantes de développement de SQLPage, de visualiser la donnée spatiale. La documentation produite au cours du chantier peut également être consultée si les fichiers (photos, dessins scannés, etc.) sont placés au bon endroit dans l’arborescence. Les pages se composent principalement de formulaires de création ou de modification, ainsi que de tableaux listant les éléments déjà enregistrés. La visualisation de la géométrie permet de se repérer spatialement sur le terrain, en particulier en cas de chantier complexe, et d’interagir avec la donnée attributaire.

L’interface de BadMobil, avec SQLPage

Cas d’utilisation et bénéfices concrets

Première expérience aux Mastraits

Le chantier de fouille de la Nécropole des Mastraits a été le chantier test de ces développements. L’importante quantité de données récoltées, mais également son statut de fouille programmée permet de mettre en place ce genre d’expérimentation avec un impact bien moindre que dans une fouille préventive où les délais sont particulièrement contraints.

La mise en place de l’interface SQLPage a permis la dématérialisation complète de l’enregistrement attributaire, et se révèle très performante. Il s’agit d’un changement majeur de nos pratiques et va nous permettre gagner un temps extrêmement important lors du traitement des données.

Ceci permet également de centraliser l’information, de travailler à plusieurs personnes en même temps sans attendre la disponibilité des classeurs d’enregistrement traditionnellement utilisés, et de guider les archéologues au cours du processus d’enregistrement, évitant les oublis et les erreurs. Grâce à une interface simplifiée, la saisie peut se faire de manière très intuitive sans réelle nécessité de formation approfondie.

L’homogénéité de la donnée saisie est ainsi meilleure, et les possibilités d’interrogation bien plus importantes.

Perspectives d’avenir

À l’issue du développement de Badass et Bad’mobil sur la nécropole des Mastraits, il nous a paru possible d’envisager son déploiement dans le cadre de l’archéologie préventive. Si la question de l’infrastructure réseau nécessaire au fonctionnement de cette solution peut se poser (nécessité de disposer d’une alimentation électrique stable sur des chantiers perdus en pleine campagne, disponibilité des tablettes, couverture réseau…), les bénéfices en termes d’homogénéité des données et de facilité de saisie sont très importants. Quelques chantiers d’archéologie préventive ont ainsi pu tester le système, la plupart du temps sur des sites de petite ampleur, en bénéficiant de l’accompagnement des membres du collectif.

Les développements futurs s’orienteront sans doute vers l’intégration de nouveaux formulaires, ou de nouveaux outils de suivi. Actuellement, Badass permet de recueillir les observations communes à tous les sites archéologiques, ainsi que les observations anthropologiques du fait de son utilisation au sein de la nécropole des Mastraits.
Nous pourrions ainsi envisager d’intégrer les nombreuses spécialités de l’archéologie, mais il est probable que nous obtenions alors une énorme machine dont la maintenance pourrait s’avérer complexe. Nous restons donc prudents à ce sujet.

Conclusion

Petit à petit, l’emploi des outils numériques s’est généralisé dans les métiers de l’archéologie. Après les traitements de texte et tableurs des années 90 (souvent sous mac), les premiers dessins vectoriels numérisés sous Adobe Illustrator, et les bases de données sous Filemaker, Access ou 4D, les outils numériques sont aujourd’hui en mesure d’être utilisés au cours de toute la chaîne d’acquisition de la donnée.

L’apport des logiciels et des formats libres est majeur pour cette nouvelle étape.

QGIS a fondamentalement révolutionné la pratique archéologique en offrant au plus grand nombre l’accès au SIG, permettant de relier et de manipuler les données attributaires et spatiales. Il a ouvert la voie à de nouvelles évolutions, et à l’intégration de technologies jusque-là peu utilisées par l’archéologie (notamment l’utilisation de bases de données relationnelles et spatiales au format SQL).
SQLpage nous a permis d’offrir à l’archéologue une interface complète et simple afin d’accéder à une base de données en réseau. Si son développement nécessite une connaissance certaine du SQL et du fonctionnement d’un site web, son déploiement et sa maintenance sont tout à fait abordables.
SQLPage répond à un réel besoin sur le terrain. Pour les archéologues, il permet de simplifier leur pratique tout en répondant à la complexité grandissante face à la masse documentaire à traiter, et à l’accroissement de l’exigence qualitative des rendus.

L’association de QGIS, des bases de données spatiales et relationnelles et d’une interface web parfaitement adaptée au terrain comblent désormais le manque constaté d’un outil efficace et fiable d’enregistrement archéologique à l’échelle de l’opération. À ce titre, Badass associée à Bad‘Mobil comblent totalement les attentes des archéologues qui les ont expérimentés.

Si les logiciels libres ont, ces dernières années, entamé une timide percée chez de nombreux opérateurs d’archéologie (certains les ont pleinement adoptés), des réticences restent présentes, que ce soit des utilisateurs, mais aussi parfois des DSI des administrations publiques, qui peuvent préférer opter pour un service tout-en-un doté d’un support technique.

Mais la persistance des usages des logiciels propriétaires n’est pas sans poser de réels problèmes quant à la pérennité des données archéologiques et les archéologues commencent juste à découvrir le problème. Leur attachement à leurs données — si elle va parfois à l’encontre du principe de la science ouverte — devrait cependant les inciter à opter pour des formats dont la pérennité apparaît certaine, garantissant par là même l’accès à ces données dans le futur, quel que soit le logiciel ou le système d’exploitation utilisé, s’ils ne veulent pas que leur travail tombe dans l’oubli…

Directeur adjoint d’un collège en Occitanie, chargé de la SEGPA et de l’accueil des élèves en situation de handicap, je me suis retrouvé dans une situation où le suivi des élèves et de leurs accompagnants devenait difficile, notamment par manque d’outils adaptés.

Loin de me décourager, j’ai créé ma propre application de suivi, École Inclusive, en utilisant le cadriciel libre SQLPage et la publie aujourd’hui sous licence GPLv3. Ce projet a été possible grâce au support proposé par la documentation en ligne et à de fréquents échanges avec Ophir Lojkine, créateur de SQLPage.

Sans aucune connaissance préalable en programmation, j’ai réalisé toute cette application en SQL. Cela permet un large panel de fonctionnalités pour École Inclusive, qui gère tout le suivi horaire des élèves, des classes et des accompagnants, les emplois du temps, les statistiques, les notifications, l’identification des utilisateurs avec plusieurs niveaux de permission.

Sommaire

• L’application « École inclusive »
  • Une application pour améliorer la prise en charge pédagogique des élèves en situation de handicap
  • De professeur d’histoire-géo à créateur d’applications
    • Un début de carrière déjà marqué par les logiciels libres
    • Changement de cap
    • Rentrer dans une nouvelle logique
      • Quelles devront être les grandes fonctions de la nouvelle application ?
      • Qui s’y connectera ?
      • Comment ça marche ?
  • Un besoin au tout début : le suivi de l’aide humaine dans le cadre des PIAL
    • Le suivi
      • Quelles données est-il utile de rassembler ?
      • Pourquoi enregistrer ces données ?
    • Un modèle de gestion à perfectionner…
      • Comment se faisait le suivi avant la création du nouvel outil ?
      • Quelles étaient les limitations ?
      • Pourquoi cela n’existe-t-il pas ?
    • SQLPage : créer une application web rapidement sans expérience de développeur web
    • Principes généraux de SQLPage
      • Un outil pertinent pour créer « école inclusive »
      • Un SQLpager averti en vaut deux
  • Création de l’application
    • Les grandes étapes du développement
      • Principales fonctionnalités et rythme de développement
      • Comment est structurée l’application ?
  • Une interface utilisateur simplifiée
    • Un code puissant et dynamique
    • Les points techniques intéressants
      • Les fonctionnalités de sqlpage utilisées
      • Publication en open-source
  • Réception de l’application
    • par les services de l’Éducation Nationale
    • par les collègues
  • Le futur de l’application École Inclusive
    • évolutions techniques envisagées
    • Vers un déploiement de l’application dans un cadre légal…
    • … et dans le respect des données privées
    • Vers un élargissement de l’utilisation à d’autres établissements ?
    • Exemple de code: affichage du profil d’un élève dans l’espace AESH

L’application « École inclusive »

Une application pour améliorer la prise en charge pédagogique des élèves en situation de handicap

Tout a commencé pendant un match de la dernière coupe du monde de rugby, un dimanche soir à une heure déjà tardive.

Énième appel à l’arbitre vidéo dans cette compétition. Les données et leur gestion, leur analyse, leur partage, l’aide à la décision. Cette problématique m’a rappelé que, dans le cadre d’une de mes missions, j’étais moi aussi confronté à une vague d’informations pas toujours très claires et toujours plus nombreuses ne rendant pas mes arbitrages très faciles dans la prise en charge des élèves que je suivais.

Profitant de cet arrêt de jeu, je tapotais sur le site de Framasoft à la recherche d’une Webapp libre pour la gestion de mes données. C’est ainsi que je laissais les Springboks s’envoler au score et que je fis la connaissance de SQLpage.

De professeur d’histoire-géo à créateur d’applications

Un début de carrière déjà marqué par les logiciels libres

Le problème à résoudre avant tout, c’est que je ne suis pas un programmeur et que je n’ai suivi aucune formation dans ce domaine. Formé dans les dernières années du XXᵉ siècle au métier de professeur d’histoire-géographie, j’avais intégré l’usage d’outils numériques à mes pratiques dès le départ. Dans le cadre de mes missions de référent numérique dans mon collège, j’avais déjà mis la main à la pâte pour monter un logiciel de traitement de texte collaboratif (Framapad) sur un petit serveur privé, installer des logiciels en ligne libres comme Moodle, Joomla ou Wordpress, adapter de-ci de-là quelques lignes de PHP ou de CSS. À titre personnel, fervent adepte du libre, je ne travaille plus que sur des versions d’Ubuntu depuis 2005 et il m’arrive d’utiliser régulièrement la ligne de commande.

Changement de cap

Retour au collège. La crise sanitaire est passée par là et les restrictions ne me permettent plus de travailler de manière collaborative entre élèves de niveaux ou de profils différents. C’est notamment le cas pour les travaux par groupes de compétences que j’organisais avec le logiciel libre Sacoche, projet très actif sur l’évaluation par compétences et l’analyse des résultats des élèves.

Mes missions vont alors se diversifier encore et je n’enseigne plus directement depuis l’automne 2020. Toujours dans le même établissement, en raison de la vacance de ces postes, je vais remplir les fonctions de principal-adjoint ou de directeur de SEGPA (Section d’Enseignement Général et Professionnel Adapté pour des élèves ayant des difficultés d’apprentissages importantes). Parmi les dossiers suivis dans ces postes figure la gestion des « pôles inclusifs d’accompagnement localisé » (PIAL) et de leur AESH, les Accompagnants d’Élèves en Situation de Handicap. Le sujet de l’École Inclusive pour tous les élèves ayant besoin d’aménagements est ainsi devenu un axe majeur dans mon implication sur notre collège. Avec des élèves toujours plus nombreux…

Rentrer dans une nouvelle logique

Et cette année, j’ai rajouté une corde à mon arc en m’essayant à la programmation d’applications. Pendant les quelques minutes où les directeurs de jeu visionnaient l’action au ralenti, j’ai concentré ma réflexion sur trois points importants, sur trois arbitrages plus personnels :

Quelles devront être les grandes fonctions de la nouvelle application ?

Je cherchais avant tout un outil qui fournisse des informations claires et précises en m’échappant des documents de tableur reçus tous les mois avec des actualisations ou des suppressions, des erreurs possibles, de transcription de nom, des propositions de responsables impossibles à respecter et surtout des données non croisées avec la réalité du terrain. Des collègues avaient tenté de revenir au classeur papier avec un côté élève et un autre adulte. Mais tout changement d’un côté demandait la même charge de travail de l’autre.

Qui s’y connectera ?

Si à l’origine j’envisageai un usage mono-utilisateur avec un outil hors-ligne, la possibilité d’avoir un outil collaboratif avait son charme et une utilité justifiée pour suivre les différents besoins de nos élèves. Je n’oublie pas non plus le sentiment de frustration en tant que professeur quand – au début des inclusions dans les années 2000 – j’accueillais des élèves en situation de handicap sans avoir suffisamment de précisions ou de solutions d’aides à ma disposition. Élargir la communauté d’utilisateur n’est pas un sujet à exclure.

Comment ça marche ?

Je devais pouvoir croiser plusieurs données qui ne se recouvraient qu’en partie : celles reçues via les parents d’élèves notifiés par la MDA-MDPH (Maison De l’Autonomie – Maison des Personnes Handicapées), celles transmises par les services de la DSDEN (Direction des Services De l’Éducation Nationale), avec nos informations ou décisions internes provenant de plusieurs coordonnateurs. Au vu de l’augmentation incessante des demandes et des aménagements attribués, un outil puissant et numérique ne pouvait être que la solution pour éviter des erreurs et rationaliser les suivis. En quelques clics Framasoft me suggérait SQLpage.

Un besoin au tout début : le suivi de l’aide humaine dans le cadre des PIAL

• Qu’est-ce que le PIAL ? Cela correspond pour nous à une zone géographique avec des écoles primaires urbaines et rurales, un collège et deux lycées. À la dernière rentrée de septembre 2023 cela représente 85 élèves et 42 accompagnants.
• Les accompagnants, terme que je préfère à l’acronyme AESH ou AVS, sont devenus des pièces essentielles à la bonne scolarisation d’élèves toujours plus nombreux. Sur notre collège de 700 élèves, 12 accompagnants interviennent. Certains ont une quotité de travail de 35h mais les plus récents n’ont des contrats que de 24h. Deux d’entre eux exercent une partie de leur mission sur un lycée ou sur une école.
• Leurs missions. Ils aident les élèves dans leurs apprentissages mais parfois pour des actes de la vie quotidienne ou sociale (repas, toilette, relations sociales…). Ils suivent en général plusieurs élèves, de 2 à 4, individuellement ou de manière mutualisée quand les élèves à besoin ont pu être placés dans la même classe. La plupart des élèves du PIAL font la totalité de leur temps scolaire sur une classe de référence avec un accompagnement qui ne cible que quelques matières. Les AESH positionnés sur les dispositifs ULIS peuvent suivre sur la semaine la totalité des élèves de leur groupe : 10 maximum d’après les textes, de 13 à 15 en réalité. Les élèves de ces dispositifs ont une scolarité partagée entre la classe de référence et l’enseignement d’un coordonnateur de l’ULIS.
• Comment sont attribuées les aides ? Toutes les notifications d’aménagements ou accompagnements attribués en compensation d’un handicap sont issues d’un long parcours administratif de plusieurs mois. Ce délai qui part du dépôt de la demande par la famille se termine par une commission qui a pris l’avis de professionnels du monde médico-social et de l’éducation. Dans notre collège 84 élèves ont une notification MDPH, pas nécessairement un accompagnant. Cela représente 1 élève sur 8. Si l’on ajoute les autres dispositifs d’aides attribués en interne ou par la médecine scolaire nous arrivons à 1 élève sur 4 soit 6 élèves par classe en moyenne.

Le suivi

Quelles données est-il utile de rassembler ?

Au-delà des données basiques d’identification des élèves, il est important de noter la nature des aménagements (AESH, ULIS, Ordinateur, etc.), la date de fin d’attribution et le nom de l’enseignant-référent auprès de la MDPH. Ensuite, nous devons relier l’élève à un (ou plusieurs dans quelques cas) accompagnants sur un certain nombre d’heures. De plus, au début de l’année les coordonnateurs des ULIS ou du PIAL donnent des conseils de mise en œuvre des aides et des objectifs progressifs à atteindre. Ces éléments peuvent être réactualisés régulièrement.

Pourquoi enregistrer ces données ?

Les premières données sont indispensables pour programmer des réunions de suivis et de renouvellement dans les temps. Les suivantes ont tout leur intérêt pour donner du sens et du contenu à l’accompagnement. En cas de remplacement ponctuel d’un AESH, on pourrait ainsi facilement lui transmettre les informations essentielles.

Enfin dans un cadre plus administratif, les services de l’Éducation Nationale nous contactent afin de vérifier que les accompagnants sont bien sollicités à la hauteur de leur quotité de travail et pour des statistiques comparant les aides individuelles ou mutualisées. Cela permet aussi de motiver des demandes de recrutement.

Un modèle de gestion à perfectionner…

Comment se faisait le suivi avant la création du nouvel outil ?

Pendant trois ans, les coordonnateurs du PIAL mettaient à jour un lutin¹ avec les emplois du temps élèves et ceux des accompagnants. Mais aussi, quand on les recevait, les notifications de la MDPH ; en effet, ce n’est pas automatique voire souvent non autorisé par certains inspecteurs. Ces derniers préférant que l’information soit donnée par les parents, ce qui n’est pas toujours le cas et ce qui ne permet pas d’anticipation des besoins.

Quelles étaient les limitations ?

Si la mise à jour d’emploi du temps peut se faire régulièrement dans le classeur, la diffusion de l’information auprès de l’ensemble des acteurs n’est pas forcément rapide quand il y a plusieurs acteurs pédagogiques dans le suivi. Enfin, si une gestion classique peut suffire sur de tous petits effectifs, elle ne permet pas de vue d’ensemble dès que l’on atteint des effectifs d’élèves et d’AESH importants et elle ne permet pas de rationaliser certaines aides. Transmettre rapidement des informations précises restait un défi dans le cas de remplacements de dernière minute.

Un détail qui a également son importance, la fonction de pilotage et de coordination du PIAL reste une mission qui s’ajoute aux tâches de sa fonction d’origine. Cela est rémunéré à hauteur d’une indemnité correspondant très rarement au temps réellement passé sur cette gestion de plus en plus lourde.

Comme dans l’exemple de notre arbitre, avoir un outil moderne, réactif, croisant les regards ne peut qu’être la solution !

Pourquoi cela n’existe-t-il pas ?

J’ai débuté comme enseignant l’année où le ministre de l’Éducation Nationale comparait notre institution à un mammouth. Nous avons (souvent) changé de dirigeant mais pas forcément de rythme. Et j’ai parfois l’impression que nous n’avançons pas très vite. J’ai posé la question en 2020 et l’on m’a répondu qu’un logiciel était en préparation pour la gestion des AESH. Depuis, rien. Cela bouge un peu côté suivi des élèves avec le Livret de Parcours Inclusif. J’ai bien vu un menu apparaître dans notre Intranet mais aucune directive ne nous est parvenue pour l’activer. La MDPH devrait pouvoir nous communiquer les notifications via cette interface, en contradiction d’ailleurs avec les recommandations actuelles. Depuis octobre dernier, rien de plus. Cela reste une coquille vide…

SQLPage : créer une application web rapidement sans expérience de développeur web

Principes généraux de SQLPage

J’ai tout de suite été séduit par l’idée de pouvoir me concentrer sur les données et sur la personnalisation de leur traitement sans avoir à perdre du temps sur de la mise en page. SQLpage fonctionne comme un petit serveur web. Le binaire de l’application pèse un peu moins de 20 Mo. Quant aux fichiers créés, l’ensemble reste vraiment très léger

Un outil pertinent pour créer « école inclusive »

Maitriser ses propres données et avoir le choix dans la mise en relation et l’affichage des informations me semblait primordial. De plus SQLpage apparait être un outil léger dont on peut utiliser plusieurs briques au choix suivant ses besoins. Et, en tant qu’adepte du logiciel libre, le fait de pouvoir utiliser un programme ouvert, avec une communauté naissante et active correspondait bien à ma philosophie. Détail important à mes yeux, pouvoir retrouver ses données en cas de changement de support à l’avenir était plutôt rassurant. En effet les données stockées dans un fichier de base de données peuvent être facilement exportées au format tableur.

Un SQLpager averti en vaut deux

Comme je vais le détailler dans la partie suivante, s’engager sur SQLpage ne s’est pas révélé aussi simple que cela pour quelqu’un qui n’est pas habitué à coder et qui ne maitrise pas le langage SQL. Ceci dit, je ne regrette pas d’avoir franchi le cap et cela m’a permis de me familiariser avec la plateforme github et de faire d’indéniables progrès tant dans le langage SQL, très accessible au demeurant, que dans la langue de Shakespeare. Si on est prêt à perdre un peu de son temps sur la documentation de SQLpage et quelques tutoriels sur le SQL, on gagne en rapidité de codage par la suite…

Création de l’application

Les grandes étapes du développement

Principales fonctionnalités et rythme de développement

Lorsque j’ai suivi le lien de Framasoft, je m’attendais à trouver un logiciel avec une interface utilisateur qui permette par glisser déposer de construire des formulaires, un peu sur le modèle d’extensions que j’avais parfois utilisées sur Joomla ou Wordpress. Se retrouver devant un dossier avec un fichier nommé index.sql à rédiger soi-même est plutôt déstabilisant quand, comme moi, on ne maitrise pas le langage SQL. J’ai testé pendant deux jours en fonctionnant par copier-coller depuis la documentation ou depuis les exemples mis à disposition sur Github. Mon inexpérience dans le domaine du codage et ma connaissance de l’anglais sommaire dans ce domaine ont failli me pousser à abandonner SQLpage très rapidement. Heureusement, j’ai trouvé ce tutoriel dans la langue de Molière : Écrire une appli web en une journée avec SQLPage (publié sur linuxfr). Il m’a permis de bien comprendre les rudiments à la fois du langage SQL et du fonctionnement de SQLpage.

Après ces deux jours de tâtonnements, je me suis donné quatre semaines pour parvenir à un logiciel basé autour de trois pages principales en SQL, une pour recenser les élèves, une autre pour leurs accompagnants et une dernière pour mettre en relation les notifications et aménagements accordés. En ne travaillant qu’à temps perdu, c’est-à-dire très tard le soir ou très tôt le matin, j’ai pu parvenir en deux semaines à un premier logiciel, encore imparfait mais répondant à une grande partie du cahier des charges que je m’étais fixé. Pour cela, je me suis appuyé principalement sur des fonctionnalités de base comme les composants form pour insérer des informations via un formulaire, et list, card ou table pour afficher les données et csv pour les exporter. On se prend au jeu et on progresse très vite. Il est possible de voir très rapidement le résultat de ses requêtes et d’affiner les composants à utiliser ainsi que leurs paramétrages.

Pour un débutant, comme pour un programmeur plus chevronné, on apprécie grandement l’interprétation des erreurs de code éventuelles que ce soit dans la syntaxe SQL (Ah, les virgules oubliées par-ci par-là !) ou dans la mauvaise utilisation des composants de SQLpage…

La mise en place de mon projet s’est déroulée en parallèle d’une phase de développement intense de SQLpage avec une version nouvelle par semaine et une documentation enrichie au même rythme. Plusieurs nouvelles fonctionnalités sont ainsi venues enrichir le code d’École Inclusive. Au bout de quatre semaines, je tenais un logiciel fonctionnel, enrichi par des composants mis à jour comme map, datagrid ou nouveaux comme button.

Entre-temps, j’ai opté pour une version en ligne du logiciel et des données. Cela m’a obligé à me pencher sur les composants authentication et cookie.

Huit semaines après ma découverte de SQLpage, je pouvais déployer une version aboutie, collaborative et en ligne via un protocole HTTPS grâce à la version majeure 0.17 de SQLpage.

Comment est structurée l’application ?

La structure de la base de données, c’est l’étape la plus importante avant de débuter le codage. Même s’il reste possible de modifier, rajouter des tables ou des champs en cours de projet, établir un schéma clair et détaillé de la structure des données utiles aide à anticiper la construction future du logiciel.

Pour ma part, j’avais besoin de plusieurs tables pour respectivement les élèves, les accompagnants, les enseignants-référents, les établissements scolaires, les notifications, les aménagements et enfin une pour rassembler les suivis. Cela se calquait sur le fonctionnement classique des procédures.

Au fil de l’avancée du projet, j’ai ajouté des tables pour gérer les utilisateurs et leurs sessions. Et afin de faciliter la gestion des notifications ou aménagements, j’ai construit deux tables "many to many" pour enregistrer de manière plus lisible les notifications multiples (par exemples AESH et Matériel pédagogique) ainsi que les pluri-dispositifs qui peuvent en découler (comme SEGPA et AESH). Cette étape a bénéficié du développement du composant 'form' et de sa fonction multi-select.

Enfin, j’ai créé des tables supplémentaires pour pouvoir utiliser les fonctions 'upload' du composant 'form' et stocker des fichiers images contenant des photos des élèves et les emplois du temps de chaque accompagnant.

Une interface utilisateur simplifiée

Le principal avantage de SQLpage est de pouvoir se focaliser sur le travail de codage du contenu sans se soucier de la mise en page. Pas de temps perdu sur des fichiers css ou html pour organiser la présentation, ceci est délégué à SQLpage qui propose une mise en forme par défaut pour chaque composant. Ceci est très appréciable et le rendu est sobre et élégant dès le début de la construction du projet.

Au niveau de la charte graphique d’École Inclusive, j’ai choisi d’avoir un menu horizontal en haut de page pour accéder aux pages consacrées à chaque catégorie d’acteurs. L’autre choix a été sur le code couleur où j’ai opté pour des tonalités vertes et orange.

Au fur et à mesure de l’avancement du logiciel et de son enrichissement en fonctionnalités, j’ai prévu d’autres outils de navigation. Si au départ je m’étais focalisé sur des onglets, qui renvoient en réalité sur des pages différentes. Il est possible d’utiliser des variables et de construire un système d’onglet sur un seul et même fichier sql. Le composant button a grandement facilité la tâche. Ceci d’autant plus que l’on peut générer des boutons de façon dynamique. Ainsi, je peux avoir des listes de boutons qui reprennent l’ensemble des classes ou des dispositifs créés pour chaque collège ou lycée du PIAL.

Vers la fin du projet, j’ai mis en place l’appel à un menu stocké dans un fichier json ce qui évite d’avoir à modifier le composant shell sur chacune des pages, ce qui est - pour l’avoir testé à mes dépens - une tâche très fastidieuse.

Un code puissant et dynamique

La seule limite à l’interface et au codage est celle de notre imagination, en effet SQLpage m’a permis de mettre en œuvre chacune de mes idées à chaque fois que je cherchais à améliorer les fonctionnalités « d’École Inclusive ». Ainsi d’une structure prévue sur 4 fichiers sql je suis passé à une structure de 94 fichiers dans la version actuelle. Maintenant que je maîtrise mieux SQLpage, je pense qu’il serait possible de réduire le nombre de pages, mais, dans ma découverte du code à mes débuts, il était plus facile d’écrire des pages plus courtes.

En s’appuyant sur la documentation en ligne, il est facile d’utiliser les composants de bases pour rentrer les données et les afficher sous forme de listes, de tables (avec fonction de recherche) ou de cartes (avec l’ajout d’images ou de photos) de manière dynamique en étant redirigé vers un contenu spécifique grâce à l’écriture de requêtes sur une variable comme l’id d’un élève ou d'un établissement scolaire ou d’une classe.

Ce qui m’a demandé davantage de réflexion a été de me lancer dans l’édition et la modification de données existantes. Depuis une icône présente sur une ligne de données d’un tableau, je voulais pouvoir, suivant les cas, éditer ou supprimer une entrée. J’avoue qu’il m’a fallu quelques jours pour arriver à un résultat correct pour dans l’ordre : afficher le formulaire, appeler les données concernées et lancer une mise à jour de la table dans la base. Pour cela j’ai contourné certaines difficultés en faisant appel à des variables afin de stocker certaines données et les réutiliser plusieurs fois sur la page, par exemple pour créer des liens dynamiques.

Dans les tables, j’ai souhaité mettre en évidence des situations demandant une vigilance comme une date d’expiration de notification proche de l’échéance ou l’ayant dépassée ou une fiche incomplète. Il est possible de mettre en place des conditions pour jouer soit sur la couleur d’une ligne soit sur l’affichage d’une icône particulière.

Enfin, la sécurisation du site dans le cadre d’une authentification avec des droits d’accès, des codes d’activation et des mots de passe forts a demandé une réflexion plus poussée et l’aide du concepteur de SQLpage.

Les points techniques intéressants

Les fonctionnalités de sqlpage utilisées

Au-delà des fonctionnalités alliant formulaires et données en liste ou en tableau, SQLpage offre des possibilités puissantes à la fois sur le plan fonctionnel et sur le plan esthétique.

Ainsi, il est possible de générer un trombinoscope ou des fiches de synthèse des élèves de chaque AESH. Cela se base sur le composant 'card' qui permet une présentation claire et concise des informations.

Le composant 'map' permet de situer chaque établissement scolaire, de différencier par des icônes les différents types de structures et bien évidemment de créer un lien vers leur page respective.

La visualisation des données sous forme de graphiques avec le composant 'chart' est un des points que je voulais pouvoir afficher pour analyser le temps de suivi de chaque élève et la répartition des missions des AESH.

En termes d’import/export, SQLpage permet de récupérer le résultat de requêtes sous forme de fichiers au format csv avec un composant dédié. L’importation à travers le composant 'form' autorise des envois de fichiers uniquement ou des traitements par lots comme dans le cas d’importations d’utilisateurs.

Enfin, les composants 'autenthication' et 'cookie' sont très efficaces pour mettre en place un site sécurisé.

Dernier point fondamental dans le cadre de la sécurisation des données, SQLpage qui reste un mini-serveur web supporte directement le protocole https.

Publication en open-source

Un simple outil comme SQLpage permet ainsi de développer relativement facilement des applications en open-source qui sont facilement fonctionnelles et attrayantes d’un point de vue graphique. De plus, l’ensemble logiciel, fichiers et base de données reste très léger et l’affichage des pages est instantanée même dans le cas de requêtes complexes.

Réception de l’application

par les services de l’Éducation Nationale

L’École Inclusive me parait naturellement devoir se pencher sur le suivi des élèves. Aussi ai-je fait part rapidement de mon projet aux enseignants-référents qui suivent les dossiers des élèves sur l’ensemble du département. Ils ont été séduits par l’idée car, eux aussi, font face à une échelle encore plus vaste à l’augmentation du nombre d’enfants à besoins particuliers. Intégrer leur rôle dans l’application était une évidence car ce sont eux qui programment et dirigent les réunions de suivis de la scolarité. Chaque début d’année, nous organisons une rencontre pour croiser nos données qui peuvent être parfois divergentes quant à des dates de fin de notification ou des aménagements multiples.

Mais les services de l’École Inclusive revêtent également des aspects administratifs à travers le déploiement et la gestion des accompagnements humains. Je suis rentré en contact avec les services administratifs de la DSDEN de la Lozère. L’accueil du logiciel (encore en version de test) a été bon, notamment sur son volet administratif avec les possibilités de quantifier en heures les accompagnements et la différenciation entre les accompagnements individuels ou mutualisés mais aussi sur son volet de traitement et de croisement des bases de données élèves et AESH.

par les collègues

Dans notre collège, où plusieurs dispositifs coexistent et où un quart des élèves bénéficient d’un aménagement particulier, nous avions l’habitude depuis trois ans de distribuer une fiche A4 par classe avec la liste des élèves et trois colonnes recensant de manière synthétique le constat des difficultés, les aménagements et les objectifs. La mise à jour du tableur était complexe avant la rentrée ou en cours d’année. Certains renseignements sur les suivis manquaient sans parler des oublis ou petites erreurs d’actualisation ou problèmes de mise en page qui pouvaient se glisser dans les listes.

Aussi, proposer à tous les coordonnateurs de dispositifs un outil en ligne, collaboratif, plus complet et toujours à jour les a convaincus immédiatement. Sans tutoriel, ni formation, la prise en main a été très facile du fait de la navigation simplifiée et très intuitive. En moins de trois semaines, l’ensemble des fiches de 184 élèves a été mis à jour.

Cela a permis d’avoir un retour constructif de mes collègues et de recueillir des suggestions pour améliorer le logiciel. L’ajout d’une icône pour ajouter un premier aménagement, masquer des onglets inutiles pour des élèves sans accompagnement, la création d’un champ précisant le rôle de l’accompagnant ou encore l’import des emplois du temps des AESH.

Le logiciel a été testé lors de remplacements d’AESH, dans un premier temps en faisant des captures d’écran des pages des consignes de suivis puis avec un compte actif pour une AESH. Cela s’est révélé très pratique et très facile d’utilisation.

Il reste à franchir le pas de l’ouverture à l’ensemble des équipes pédagogiques et cela sera facilité par les récentes fonctionnalités d’importation permise par SQLPage.

Le futur de l’application École Inclusive

évolutions techniques envisagées

Pour répondre à une utilisation pratique pour tous et plus particulièrement pour les enseignants, une sortie au format PDF pour chaque classe permettrait une diffusion claire aux équipes pédagogiques. Une gestion plus fine des droits avec un mode d’édition intermédiaire est à envisager pour que chaque professeur principal puisse intervenir sur les informations des élèves de sa classe.

Vers un déploiement de l’application dans un cadre légal…

La mise en ligne d’École Inclusive sur un serveur reste une démarche relativement simple chez un hébergeur qui offrirait une solution dédiée ou virtualisée. Il est possible de déployer un serveur Linux sur lequel on lance SQLpage comme service. Pour une utilisation sur un seul établissement et par un seul coordonnateur, 'École Inclusive' peut tourner hors-réseau sur différents systèmes d’exploitation. Pour rester dans un strict cadre légal, il faut que le logiciel soit déployé sur une machine ou un hébergement pris en charge par l’Éducation Nationale.

… et dans le respect des données privées

Les services du Rectorat chargés de la Protection des Données nous accompagnent dans cette démarche afin de respecter les préconisations de la CNIL. Le type de données utilisé par le logiciel ne pose pas de problème. Pour les utilisateurs de l’application dont des données personnelles sont conservées dans la base de donnée, il faut prévoir un droit de regard et de rectification conformes au standard du RGPD. Mais, rappelons que cet outil permet déjà une gestion des droits à plusieurs niveaux en tant qu’administrateur, éditeur ou consultant. Dans ce dernier cas, certaines données comme les numéros de téléphone personnels sont masqués.

Vers un élargissement de l’utilisation à d’autres établissements ?

Le logiciel 'École Inclusive' va être présenté mi-mars aux chefs d’établissements publics de Lozère (13 collèges et 3 lycées). Cette démarche trouve sa pertinence dans le fait que les PIAL regroupent plusieurs établissements et que les enseignants-référents sont déployés à l’échelle du département. Cependant il sera difficile de mettre en concurrence cette application avec le Livret de Parcours Inclusif quand il sera un jour opérationnel. École Inclusive devra peut-être se recentrer sur la gestion des accompagnants et sur le suivi horaire dans une optique plus administrative que pédagogique. Mais il faut noter une plus grande souplesse et une saisie plus simple et plus directe dans École Inclusive qui ne se limite pas aux situations classiques des PPRE, PAP et Gevasco mais qui peut s’adapter à la physionomie des établissements. Chaque accueil réalisé dans la structure peut être suivi avec par exemple les élèves inclus venant d’établissements médico-sociaux, les élèves allophones, les PAI pour situations médicales…

En conclusion, le plus important n’est pas l’arrivée mais la quête. Celle qui m’a conduit à me poser des questions et à construire École Inclusive dans l’intérêt des élèves à besoins particuliers et des membres des équipes éducatives qui les suivent. Cette application est disponible en open-source sur Github (https://github.com/DSMejantel/Ecole_inclusive). Elle reste encore en évolution et elle se perfectionne au fur et à mesure de l’apparition de nouvelles fonctionnalités de SQLpage. Elle demeure très perfectible : code et interface pourront évoluer en fonction des retours des utilisateurs et de mes progrès en programmation… Pour cela SQLpage reste un allié puissant et très didactique dans les exemples de sa documentation.

Exemple de code: affichage du profil d’un élève dans l’espace AESH

-- Résumé de suivis des élèves
SELECT 'card' AS component, 4 AS columns WHERE $tab = 'Profils';
SELECT eleve.nom || ' ' || eleve.prenom || ' (' || eleve.classe || ') ' AS title,
       'green' AS color,
       CASE
              WHEN EXISTS (SELECT eleve.id FROM image WHERE eleve.id = image.eleve_id) THEN image_url
              ELSE './icons/profil.png'
       END AS top_image,
       COALESCE('Mission de l''AESH : ' || suivi.mission,
                'non saisi') AS description,
       group_concat(DISTINCT dispositif.dispo) AS footer,
       '[
              ![](./icons/list-check.svg)
       ](notification.sql?id=' || eleve.id || '&tab=Profil)
       [
              ![](./icons/user-plus.svg)
       ](notification.sql?id=' || eleve.id || '&tab=Suivi)' AS footer_md,
       'notification.sql?id=' || eleve.id || '&tab=Profil' AS link
FROM eleve
       INNER JOIN affectation ON eleve.id = affectation.eleve_id
       LEFT JOIN amenag ON amenag.eleve_id = eleve.id
       JOIN dispositif ON dispositif.id = affectation.dispositif_id
       JOIN etab ON eleve.etab_id = etab.id
       JOIN suivi ON suivi.eleve_id = eleve.id
       LEFT JOIN image ON eleve.id = image.eleve_id
       JOIN aesh ON suivi.aesh_id = aesh.id
WHERE aesh_id = $id AND $tab = 'Profils'
GROUP BY eleve.id
ORDER BY eleve.nom ASC;

Cet élément fait partie de la page du profil d’un AESH. Dans un premier paragraphe, on appelle le composant 'card' avec ses paramètres. Ici, il y aura quatre cartes affichées par ligne si l’on se trouve sur l’onglet nommé « Profils ».
Ensuite on trouve le contenu de chaque fiche élève. Son identité et sa photo si elle existe dans la base ; cela est déterminé par le CASE WHEN. Dans le cas inverse une image par défaut est affichée.
Si le rôle de l’AESH a été renseigné, il est affiché en dessous. Puis viennent les dispositifs d’aide auxquels l’élève est rattaché.
Enfin, trois icônes renvoient vers différents onglets de la fiche personnelle de l’élève.
Cet affichage est dynamique et s’adapte au profil de chaque AESH comme le définit la condition WHERE aesh_id=$id. Le contenu de la fiche va piocher les différentes informations dans les tables.

Exemple d’alertes et d’informations personnalisées

-- Liste des notifications
SELECT 'table' as component,
       'actions' as markdown,
       1 as sort,
       1 as search;
SELECT eleve.nom as Nom,
       eleve.prenom as Prénom,
       notification.Departement as Dpt,
       group_concat(DISTINCT modalite.type) as Droits,
       etab.nom_etab as Établissement,
       strftime('%d/%m/%Y', datefin) AS Fin,
       CASE
              WHEN notification.datefin < datetime(date('now', '+1 day')) THEN 'red'
              WHEN notification.datefin < datetime(date('now', '+350 day')) THEN 'orange'
              ELSE 'green'
       END AS _sqlpage_color,
       coalesce('[ ![](./icons/user-plus.svg) ](aesh_suivi.sql?id=' || suivi.aesh_id || '&tab=Profils)', '[ ![](./icons/user-off.svg) ]()') AS actions,
       '[ ![](./icons/briefcase.svg) ](notification.sql?id=' || eleve.id || '&tab=Profil)' as actions
FROM notification
       INNER JOIN eleve on notification.eleve_id = eleve.id
       LEFT JOIN suivi on eleve.id = suivi.eleve_id
       LEFT join notif on notif.notification_id = notification.id
       LEFT join modalite on modalite.id = notif.modalite_id
       JOIN referent on eleve.referent_id = referent.id
       JOIN etab on eleve.etab_id = etab.id
Where referent.id = $id
GROUP BY notification.eleve_id
ORDER BY eleve.nom ASC;

Cet élément fait partie de la page du profil d’un enseignant-référent de la MDA-MDPH.
Dans un premier paragraphe, on appelle le composant table avec ses paramètres. On trouve le formatage d’une colonne en markdown et les options de recherche et de tri qui sont activées.
Ensuite on trouve le contenu de chaque ligne avec l’élève dont le dossier est suivi par ce référent.
Afin de planifier avec lui les priorités pour les dates de réunions de suivi, il est possible d’attribuer une couleur de ligne en fonction de la date de fin de notification avec :
CASE
WHEN notification.datefin < datetime(date('now', '+1 day')) THEN 'red'
WHEN notification.datefin < datetime(date('now', '+350 day')) THEN 'orange'
ELSE 'green'
De même les icônes sont personnalisables pour indiquer si l’élève bénéficie d’un AESH ou non. Et bien sûr des liens permettent de passer sur la fiche de l’élève ou de son AESH.

Licence de l’article: CC0