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 1^er 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… ?

La prise en charge de Windows 10 se termine le 14 octobre 2025, forçant ses utilisateurs à passer à Windows 11 qui requiert des performances beaucoup plus élevées tout en poursuivant la prise de contrôle de ses utilisateurs.

La campagne « End of 10 » (fin de [Windows] 10) initiée il y a quelques mois vise à dénoncer le gaspillage de ressources (en forcant le remplacement anticipé de machines), et incite à un passage à Linux.

Le lancement de la campagne sur les réseaux sociaux (i.e. Mastodon) a démarré le 28 mai.

De bonnes raisons

La campagne est axée sur cinq arguments principaux :

• les économies financières : pas de coût de licence, pas d'obligation de renouveler son matériel de manière anticipée.
• l'amélioration du respect de la vie privée : s'affranchir des publicités et logiciels espions intégrées de force dans Windows.
• l'écologie : éviter un remplacement d'ordinateur a un impact carbone direct.
• bénéficier d'un support adapté : communautaire ou professionnel, en ligne ou en physique.
• reprendre contrôle de son ordinateur : bénéficier des libertés des logiciels libres pour utiliser votre ordinateur comme vous le souhaitez.

La philosophie de la campagne

La campagne est née du groupe de travail KDE Eco réfléchissant sur les impacts environnementaux des logiciels, cependant il est important de noter que dans le cadre de cette campagne la communication doit promouvoir « Linux » de manière générale et non promouvoir telle ou telle distribution. L'objectif premier est de quitter Windows.

Le partage sur les réseaux sociaux vise à faire connaître l'initiative de manière plus large, cependant le succès est principalement attendu en s'appuyant sur des acteurs locaux existant : cafés réparation, boutiques informatiques, …

Le site de la campagne fourni à la fois un registre des lieux et des dates où il est possible de se renseigner et se lancer. Plusieurs dizaines de possibilités ont déjà été ajoutées.

Participer !

De nombreuses façons de participer sont possibles :

• prendre contact avec les structures locales (repair cafés, GULL, associations, …)
• aider lors d'une install party ou en organiser une près de chez vous (et déclarer l'évènement sur le site)
• en parler avec vos proches
• relayer les messages Mastodon
• …

Microsoft a ouvert la porte pour faire de 2025 l'année Linux ! À nous de mettre le pied dans la fenêtre !

Cette dépêche va présenter une méthode pour afficher sur un site personnel les traces, récits et photographies de balades (pédestres, cyclistes par exemple).

Comme le contenu à afficher est diversifié (texte, photographies, cartes), la solution retenue sera un blog. Dans un soucis de sobriété numérique, le site sera sans base de données.

Pour l'aspect esthétique, la barre de navigation et les cartes seront situées dans la partie gauche des pages et surtout, la carte ne bougera pas avec la navigation dans la page.

Sommaire

• 1 - Préparation de pelican
  • a) Le moteur
  • b) Installation du thème graphique
  • c) Écriture du premier billet
  • d) Génération de notre site
• 2 - Peaufinage de base
• 3 - Gestion cartographique
  • a) Gestion des cartes
  • b) Gestion des fichiers de trace (gpx)
  • c) Modification des gabarits
• 4 - Gestion des photographies associées à notre cartographie
  • a) Fichier des billets
  • b) Modification des gabarits
  • c) Gestion des photographies
• 5) Dernières modifications
  • a) Modifier les gabarits
  • b) Ajuster les feuilles de style
• 6) Conclusion

N'ayant pas trouvé d'alternative libre à Polarstep, la solution retenue se base sur les briques logicielles libres suivantes :

• un moteur de blog static : pelican (AGPL v3.0)
• des thèmes pour le blog
• des bibliothèques cartographiques : leaflet (BSD 2)

1 - Préparation de pelican

Pelican propose d'écrire chaque billet de blogs dans un fichier texte indépendant (au format markdown ou reStructuredText).

Pelican les convertit en html et l'organisation du site ainsi généré (catégories, mots-clefs, archivage) se fait par le biais de gabarits (qui sont dans un sous-répertoire templates)

a) Le moteur

L'installation ne sera pas développée ici, pelican étant disponible dans de nombreuses distributions.

Il faut créer la structure de travail (dans le répertoire personnel de notre choix) :

pelican-quickstart

b) Installation du thème graphique

En allant sur le dépôt des thèmes de pelican, il est possible de trouver le style graphique qui nous convient le mieux.

Nous allons utiliser le thème pelican-blue (sous licence MIT 2.0), qui a l'avantage d'être simple, et commençons son installation :

• création du répertoire theme dans notre structure de travail
• décompression de l'archive du thème dans le répertoire « theme »
• modification du fichier pelicanconf.py pour configurer notre site. Il faut adapter quelques variables :

SITENAME = 'Mon blog'
SITEDESCRIPTION = 'Mes souvenirs de vacances'
THEME = "./theme/pelican-blue"
STATIC_PATHS = ['images', 'gpx']

• modifications propres au thème. Souvent l'auteur d'un thème propose de le personnaliser à partir de variables déclarées dans le fichier de configuration.

c) Écriture du premier billet

On va créer notre premier billet

Title: Première sortie
Date: 2025-05-01
Modified: 2025-05-01
Category: Lieux
Slug: depart
Tags: bonjour, balade

Bonjour tout le monde ! Quelle chouette sortie j'ai faite.

d) Génération de notre site

On lance la première compilation :

make clean
make html

On peut voir le résultat :

• soit en ouvrant directement le fichier index.html (présent dans le répertoire output)
• soit en lançant un mini serveur web (make serve) et lancer son navigateur web à l'adresse http://localhost:8000/

Pour plus de renseignements sur pelican, je vous invite à vous rendre sur la documentation du projet.

2 - Peaufinage de base

On va maintenant nettoyer le code des gabarits, en supprimant les choses que l'on trouve inutiles ou qui nous déplaisent. Tout se passe dans le répertoire templates de notre thème.

• il y a les fichiers analytics.html et disqus.html
• une recherche par mot nous informe des éventuelles références à Google, Twitter, Facebook

On supprime les parties qui ne nous conviennent pas.

3 - Gestion cartographique

Nous attaquons désormais notre objectif : rendre visibles sur des cartes des fichiers de trace.

a) Gestion des cartes

On va maintenant configurer la gestion des cartes, par l'intermédiaire de leaflet. Comme l'indique sa page wikipédia, leaflet est très largement utilisé et très pratique.

On va donc

• le télécharger,
• le décompresser dans le répertoire static de notre thème
• modifier les entêtes de nos gabarits (cela se fait le plus souvent dans le fichier base.html) pour y ajouter au niveau <head> les références à leaflet :

    <link rel="stylesheet" href="{{ SITEURL }}/theme/leaflet/leaflet.css"   integrity="sha256-p4NxAoJBhIIN+hmNHrzRCf9tD/miZyoHS5obTRR9BMY="  crossorigin=""/>
    <script src="{{ SITEURL }}/theme/leaflet/leaflet.js"  integrity="sha256-20nQCchB9co0qIjJZRGuk2/Z9VM+kNiyxNV1lvTlZBo="  crossorigin=""></script>

Comme on a récupéré en local les fichiers, on met des chemins propres à notre arborescence (via {{ SITEURL }}/theme/).

b) Gestion des fichiers de trace (gpx)

Elle va se faire par l’intermédiaire d'un module supplémentaire https://github.com/mpetazzoni/leaflet-gpx (BSD 2).

De la même manière qu'on a intégré dans nos entêtes l'intégration de leaflet, nous allons ajouter une ligne pour faire référence à leaflet-gpx (bien vérifier le nom du fichier javascript) :

<script src="{{ SITEURL }}/theme/leaflet-gpx/gpx.js"></script>

Par rapport à la documentation officielle, on retire l'attribut defer (puisque nous utilisons les fichiers locaux et non distants).

Pour tester notre environnement, on va déposer dans notre répertoire gpx un fichier de trace, puis on va ajouter dans notre billet les éléments de cartographie de notre voyage :

<div id="map" style="width: 600px; height: 400px;"></div>
<script>
        var map = L.map('map');
        L.tileLayer('http://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png', {
          attribution: 'Carte et données : <a href="http://www.osm.org">OpenStreetMap</a>'
        }).addTo(map);
        var gpx = '/gpx/FICHIER.gpx';
        new L.GPX(gpx, {async: true}).on('loaded', function(e) {
            map.fitBounds(e.target.getBounds());
        }).addTo(map); 
</script>

On regénère notre site web, et on peut visualiser notre billet

Globalement, ça fait le boulot.

Mais on peut améliorer la chose : on peut par exemple cacher les marques de début et de fin d'itinéraire en insérant la ligne suivante après le async: true

markers: {startIcon: null, endIcon: null, }

Mais surtout, nous souhaitons que pelican génère automatiquement la partie consacrée au fichier de trace (alors que dans notre test, nous avons dû l'ajouter nous-même) !

c) Modification des gabarits

Si l'on veut simplement ajouter notre fichier de trace et que notre gabarit le traite, on va ajouter cette information dans les entêtes de notre fichier markdown ! En effet pelican permet de créer des variables qui seront utilisables dans nos gabarits.

Nous allons donc créer et utiliser une variable (qui s'appellerait… Gpx par exemple), qui stockera le nom du fichier gpx à afficher (les chemins sont relatifs à notre site web)

Title: Première sortie
Date: 2025-05-01
Modified: 2025-05-01
Category: Lieux
Gpx: /gpx/monfichier.gpx
Slug: depart
Tags: bonjour, balade

Nous modifions ensuite notre gabarit article.html pour qu'il génère la carte à partir de notre variable.

Pelican est très souple : basé sur Jinja2, il permet les boucles, les conditions et les variables.

Tous les éléments qu'il utilise sont insérés dans des accolades. Le fonctionnement est facilement lisible et compréhensible.

On va donc conditonner (avec if) l'insertion de leaflet.

{% if article.gpx %}
    <div id="map" style="width: 600px; height: 400px;"></div>
<script>
    var map = L.map('map');
    L.tileLayer('http://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png', {
      attribution: 'Carte et données : <a href="http://www.osm.org">OpenStreetMap</a>'
    }).addTo(map);

    var gpx = '{{ article.gpx }}';
    new L.GPX(gpx, {async: true,
                       markers: {startIcon: null, endIcon: null, }
      }).on('loaded', function(e) {
         map.fitBounds(e.target.getBounds());
      }).addTo(map); 

</script>
{% endif %}

Bien entendu, nous supprimons ces références du fichier markdown correspondant à notre billet de test.

On regénère notre site web, et on peut visualiser notre billet… qui n'a pas changé : tout fonctionne. Pour chacune de nos sorties, il suffit donc d'indiquer le fichier de trace dans les entêtes pour que la carte soit insérée automatiquement dans notre billet.

Passons maintenant à l'intégration de nos photos.

4 - Gestion des photographies associées à notre cartographie

Nous avons besoin :

• d'une image
• de ses coordonnées géographiques (latitude et longitude)

Pour cela, nous allons procéder de la même manière que pour le fichier trace : nous allons créer et utiliser des variables dans les entêtes des fichiers markdown.

a) Fichier des billets

Nous modifions encore une fois les entêtes en ajoutant autant d'informations (image, latitude et longitude) que de photos à afficher en miniatures.

Title: Première sortie
Date: 2025-05-01
Modified: 2025-05-01
Category: Lieux
Gpx: /gpx/monfichier.gpx
Slug: depart
Img: /images/image1.jpg
Lat: 49.895517
Lon: 2.295983
Img: /images/image2.jpg
Lat: 49.89443
Lon: 2.30137
Tags: bonjour, balade

On remarque ici que l'on a mis plusieurs images avec les mêmes noms de variables.

b) Modification des gabarits

Nous allons ensuite modifier les gabarits de pelican pour qu'ils positionnent des miniatures des photos sur notre trajet.

Nous allons à nouveau modifier notre fichier article.html, en y ajoutant (à la suite de notre précédente modification, dans la condition {% if article.gpx %}) le code suivant :

Nous commençons par indiquer l'icône qui s'affichera sur la carte à chaque photo mise en valeur

var MonIcone = L.icon({
    iconUrl: '/images/app-photo.png',
    iconSize: [36, 36]
});

Puis nous codons l'affichage du marqueur (qui sera géré par leaflet).

{% if article.img %}
  {% if article.img is string %}
     imageTxt = 'Description';
     L.marker([{{ article.lat }}, {{ article.lon }}], {icon: MonIcone}).bindPopup(imageTxt + '<br><img src="{{ article.img }}" width="200px"><a href="#bal5">plus de détail</a>').addTo(map);    
  {% else %}
    {% for n in range(article.img| length) %}
       imageTxt = 'Description';
       L.marker([{{ article.lat[n] }}, {{ article.lon[n] }}], {icon: MonIcone}).bindPopup(imageTxt + '<br><img src="{{ article.img[n] }}" width="200px"><a href="#bal5">plus de détail</a>').addTo(map);
    {% endfor %}    
  {% endif %}

La difficulté réside dans la gestion des éléments répétitifs :

• s'ils sont plusieurs, on peut utiliser les méthodes python des listes.
• s'il n'y en a qu'un seul, cette méthode renvoie toutes les lettres de notre variable ! Il a donc fallu tester si celle-ci est une chaine de caractères ou une liste.

Les choix sont ici purement personnels ou démonstatifs :

• on a laissé une variable imageTxt en dur, elle pourrait être passée dans les entêtes de nos fichiers markdown
• le texte du popup peut être adapté (on pourrait y ajouter un lien direct vers notre image par exemple)
• le lien (ancre) est à créer dans notre fichier markdown
• la taille de l'image du popup est en dur (on peut passer par une feuille de style css)

On regénère notre site web, et on peut visualiser notre billet :

Et lorsqu'on clique sur une icône d'appareil photo, on voit bien notre popup :

c) Gestion des photographies

Comme indiqué plus haut, la taille des miniatures affichées peut se gérer :

• par CSS
• ou créer des miniatures (avec imagemagick) pour diminuer la charge de notre serveur (afficher une photo de 3000 pixels à 200 pixels n'est pas optimal). Dans ce cas, il suffira d'adapter notre gabarit pour lui indiquer où aller chercher les petites images (/images/miniatures/ par exemple)

Par contre, le point le plus compliqué est la gestion des coordonnées des photographies : il faut les rentrer à la main !

• Pour les photographies qui n'intègrent pas les coordonnées dans leurs métadonnées, il n'y a pas d'autre solution que d'aller chercher sur une carte (openstreetmap par exemple) et de trouver le lieu de la prise de vue et de repérer les coordonnées.

• Pour les photographies qui contiennent leurs coordonnées géographiques, on peut utiliser l'outil exiftool pour les récupérer. On peut éventuellement faire un script bash qui affiche les lignes d'entête pour notre billet (on n'a plus qu'à les recopier ou les rediriger vers un fichier texte) :

    for photo in $(ls ./content/images);
    do
        echo ""
        echo "Img: /images/"$photo
        LAT=$(exiftool -n -s3  -gpslatitude ./content/images/$photo)
        echo "Lat: "$LAT
        LONG=$(exiftool -n -s3  -gpslongitude ./content/images/$photo)
        echo "Lon: "$LONG
    done

Nous avons utilisé les options -n qui affichent les valeurs numériques au format décimal (celui utilisé par openstreetmap pour les coordonnées) et -s3 pour avoir la valeur du champ sans le nom de son attribut.

5) Dernières modifications

Nous venons de voir les différentes techniques qui permettent d'avoir le rendu que nous souhaitions. Et le résultat est déjà agréable à regarder.

Nous pourrions nous arrêter ici, mais vous voulons que la carte reste en permanence dans le menu latéral. La solution est de la mettre dans une balise <aside>.

a) Modifier les gabarits

Notre thème comporte déjà une telle balise : elle est dans le fichier base.html… ce qui signifie qu'il ne peut pas voir les informations sur les articles (donc nos entêtes) !

La solution va donc consister à déplacer, à l'intérieur du fichier article.html, tout notre code dans une section (que nous appellerons mamap :

{% block mamap %}
    Mettre ici tout le code sur notre gestion cartographique
{% endblock %}

Et dans le fichier base.html, on va insérer à l'intérieur des balises <aside> son appel (qui ne tient que sur deux lignes) :

{% block mamap %}
{% endblock %}

b) Ajuster les feuilles de style

Il faut surcharger le comportement de la carte gérée par leaflet :

    .leaflet-container {
        width: 400px;
        height: 300px;
        max-width: 100%;
        max-height: 100%;
        margin: auto;
    }

Et vérifier que les largeurs de la carte, et de <aside> soient compatibles.

Le résultat avec nos dernières modifications est désormais le suivant

6) Conclusion

Il est temps de finir cette dépêche, dans laquelle nous avons pu découvrir la souplesse et la richesse des gabarits gérés avec jinja2, ainsi que la facilité d'utilisation de leaflet.

Désormais, dans notre flux de travail, nos répertoires sont organisé ainsi :

content 
    + gpx : les fichiers de trace
    + images : les photos que l'on veut afficher sur notre blog
    fichierXX.md : les billets
output : notre site web (généré par pelican)
theme
    + pelican-blue  : le thème choisi
        + static
            + css
            + leaflet
            + leaflet-gpx
        + templates

Et la rédaction de nos billets consiste à :

• ajouter le fichier gpx de notre trace dans les entêtes
• ajouter les informations sur chaque photo que l'on veut voir (toujours dans les entêtes)
• écrire notre billet normalement (en y ajoutant éventuellement d'autres photos ou des ancres de navigation)

Cette dépêche démontre qu'il est possible d'avoir, avec les outils actuels, un rendu intéressant pour partager ses sorties. Et totalement utilisable en auto-hébergement.

Les outils utilisés sont très personnalisables et je vous invite à lire leurs documentations ou à parcourir leurs extensions respectives et de vous les approprier selon votre usage.

Malheureusement, la solution présentée ne conviendra qu'à une minorité d'utilisateurs. En effet, elle se base sur des éléments qui sont le plus souvent rendus invisibles (site web, transfert de fichiers, métadonnées) et elle est inutilisable sur téléphone.