L’intelligence artificielle (IA) fait couler de l’encre sur LinuxFr.org (et ailleurs). Plusieurs personnes ont émis grosso-modo l’opinion : « j’essaie de suivre, mais c’est pas facile ».

Je continue donc ma petite revue de presse mensuelle. Disclaimer : presque aucun travail de recherche de ma part, je vais me contenter de faire un travail de sélection et de résumé sur le contenu hebdomadaire de Zvi Mowshowitz (qui est déjà une source secondaire). Tous les mots sont de moi (n’allez pas taper Zvi si je l’ai mal compris !), sauf pour les citations: dans ce cas-là, je me repose sur Claude pour le travail de traduction. Sur les citations, je vous conseille de lire l’anglais si vous pouvez: difficile de traduire correctement du jargon semi-technique. Claude s’en sort mieux que moi (pas très compliqué), mais pas toujours très bien.

Même politique éditoriale que Zvi: je n’essaierai pas d’être neutre et non-orienté dans la façon de tourner mes remarques et observations, mais j’essaie de l’être dans ce que je décide de sélectionner ou non.

Sommaire

• Résumé des épisodes précédents
• OpenAI dévoile Codex et codex-1
• Google I/O 2025
• Anthropic publie Claude 4
• En vrac
• Pour aller plus loin

Résumé des épisodes précédents

Petit glossaire de termes introduits précédemment (en lien: quand ça a été introduit, que vous puissiez faire une recherche dans le contenu pour un contexte plus complet) :

• System Card: une présentation des capacités du modèle, centrée sur les problématiques de sécurité (en biotechnologie, sécurité informatique, désinformation…).
• Jailbreak: un contournement des sécurités mises en place par le créateur d’un modèle. Vous le connaissez sûrement sous la forme "ignore les instructions précédentes et…".

OpenAI dévoile Codex et codex-1

Les modèles actuels commençant à être relativement compétents sur les tâches de programmation, la ruée vers l’or arrive : comment en faire de véritables programmeurs, autonomes ou semi-autonomes ?

La première génération consistait à poser des questions à l’IA sur l’interface de chat, et copier-coller des bouts de code, ainsi que d’assistants à l’auto-complétion.

La seconde génération, Aider (open-source), Cline (également), Cursor, Claude CLI ou Codex CLI consistait à donner un accès direct à votre projet à l’IA, lui permettant de consulter et d’éditer le code ; soit intégré à un IDE, soit en ligne de commande.

La troisième génération revient aux racines de la première, où l’interface entre l’utilisateur et l’IA est à nouveau un simple chat dans le navigateur. Mais cette fois, l’IA clone votre projet dans un environnement de développement virtualisé et travaille dans cet environnement. Vous pouvez la superviser, ou la laisser travailler quelques temps.

C’est en tout cas ce que propose OpenAI avec Codex. L’annonce officielle :

Today we’re launching a research preview of Codex: a cloud-based software engineering agent that can work on many tasks in parallel. Codex can perform tasks for you such as writing features, answering questions about your codebase, fixing bugs, and proposing pull requests for review; each task runs in its own cloud sandbox environment, preloaded with your repository.

Traduction :

Aujourd'hui, nous lançons un aperçu de recherche de Codex : un agent d'ingénierie logicielle basé sur le cloud qui peut travailler sur de nombreuses tâches en parallèle. Codex peut effectuer des tâches pour vous telles que l'écriture de fonctionnalités, répondre à des questions sur votre base de code, corriger des bogues et proposer des demandes de fusion pour révision ; chaque tâche s'exécute dans son propre environnement sandbox cloud, préchargé avec votre dépôt.

OpenAI couple cette sortie avec un modèle spécialisé pour la programmation, codex-1, avec sa System Card (pas très intéressante, mais notons qu’elle a le mérite d’exister).

La force de ce mode de fonctionnement est le parallélisme : vous pouvez demander à l’IA de travailler sur plusieurs choses à la fois, voire lancer plusieurs sessions pour la même tâche et choisir le meilleur résultat.

Les réactions sont mitigées : la fiabilité n’est pas toujours au rendez-vous, mais quand elle l’est, le gain de temps est loin d’être négligeable. Et si vous avez les poches profondes, lancer plusieurs tentatives en parallèle est une bonne manière de pallier au manque de fiabilité.

Google I/O 2025

Google I/O est la conférence annuelle de Google, présentant leurs nouveaux produits. C’est à Google I/O 2008 qu’Android avait été présenté.

Pour cette édition 2025, sans surprise, c’est l’IA qui est sur le devant de la scène.

Sur la création audiovisuelle, tout d’abord :

• Veo 3 est un modèle permettant de générer une vidéo (avec son).
• Veo 2, la version précédente, gagne certaines capacités : en plus d’instructions textuelles, le modèle est maintenant capable de prendre des images ou une vidéo de référence, pour reprendre le style ou les détails d’un personnage (ou d’un objet, ou d’une scène). Un contrôle plus fin de la caméra (zoom/rotation) est également fourni à l’utilisateur.
• La génération d’image du nouveau modèle d’OpenAI avait fait parler d’elle en mars dernier. Google propose sa propre solution avec Imagen 4.
• Lyria 2 est un nouveau modèle de génération de musique (paroles comprises).

Pour lutter contre les nouvelles possibilités de désinformation offertes par ces outils, Google lance également SynthID, un outil pour détecter les contenus multimédia générés par les modèles d’IA de Google (et seulement de Google). Sur invitation uniquement, Google craignant probablement qu’un acteur malicieux puisse juste modifier le contenu jusqu’à ce que SynthID réponde « non-IA » si l’outil est publiquement accessible.

Sur les modèles plus classiques :

• Gemini 2.5 Flash, une version plus légère, rapide, moins chère, et moins puissante de Gemini 2.5 Pro.
• Jailbreaké immédiatement, ce que je ne prendrai pas la peine de noter s’il n’y avait l’ironie que ce jailbreak arrive le même jour que la présentation de Google DeepMind nommée « Advancing Gemini’s security safeguards ».
• Gemma 3, le modèle open-weights, gagne plusieurs variantes pour des tâches plus spécialisées : Gemma 3n, pour tourner sur des smartphone ; MedGemma spécialisé dans la médecine ; SignGemma pour le langage des signes et… DolphinGemma pour communiquer avec les dauphins ?
• L’annonce également d’un nouveau mode pour Gemini 2.5 Pro, Deep Think, consistant apparemment à lancer plusieurs chaînes de pensée en parallèle. Apparemment une bonne avancée sur les problèmes mathématiques, moins impressionnant sur d’autres tâches. Accessible sur invitation uniquement également.

Sur les IA « agentiques », capables d’utiliser des outils pour réaliser des tâches variées :

• Google répond à OpenAI Codex avec son propre IA-programmeur, Jules.
• Project Mariner est un prototype explorant l’interaction entre un utilisateur et une IA agentique.
• Un mode « agent » dans l’application Gemini.
• Project Astra, un assistant vous permettant de contrôler votre smartphone via l’audio et la vidéo (caméra/microphone).

Également proposés : plus d’intégration de l’IA dans les services classiques de Google (Search, Mail, Chrome…). Un usage notable : traduction en temps réel dans Google Meet.

Présenté quelques avant Google I/O, AlphaEvolve est un système pour découvrir de nouveaux algorithmes, utilisant Gemini en tant que sous-composant. L’utilisateur fournit une description textuelle du problème avec une solution naïve et une méthode pour évaluer un solution, et le système se charge de trouver de meilleurs algorithmes pour résoudre le même problème.

Ce système a trouvé de meilleures solutions relativement à l’état de l’art sur plusieurs problèmes évalués, par exemple en découvrant un moyen de multiplier deux matrices 4x4 à l’aide de 48 multiplications scalaires au lieu de 49.

Dans la catégorie innovations, Gemini Diffusion explore un paradigme entièrement différent pour les modèles de langage. Les modèles de langage actuels sont basés sur des transformeurs, suivant la méthode maintenant célèbre de « prédire le prochain token à partir des précédents ». Dans la génération d’image, c’est un paradigme complètement différent qui est suivi, celui de diffusion (qui a donné le nom au modèle StableDiffusion), où le modèle est essentiellement un modèle de « dé-bruitage » qui transforme une image bruitée en une image plus claire, et qui commence par du simple bruit blanc. Gemini Diffusion est une tentative d’adapter ce paradigme de « diffusion » à la génération de texte : un texte complet est présenté au modèle, et sa tâche est de l’« affiner » incrémentalement (où le texte initial est complètement aléatoire). Les premiers résultats sont encourageants, ce premier prototype arrivant au même niveau de capacités que Gemini 2.0 Flash.

Anthropic publie Claude 4

L’annonce officielle :

Today, we’re introducing the next generation of Claude models: Claude Opus 4 and Claude Sonnet 4, setting new standards for coding, advanced reasoning, and AI agents.

Claude Opus 4 is the world’s best coding model, with sustained performance on complex, long-running tasks and agent workflows. Claude Sonnet 4 is a significant upgrade to Claude Sonnet 3.7, delivering superior coding and reasoning while responding more precisely to your instructions.

Traduction :

Aujourd'hui, nous présentons la prochaine génération de modèles Claude : Claude Opus 4 et Claude Sonnet 4, établissant de nouveaux standards pour le codage, le raisonnement avancé et les agents IA.

Claude Opus 4 est le meilleur modèle de codage au monde, avec des performances soutenues sur des tâches complexes et de longue durée ainsi que des flux de travail d'agents. Claude Sonnet 4 est une amélioration significative par rapport à Claude Sonnet 3.7, offrant un codage et un raisonnement supérieurs tout en répondant de manière plus précise à vos instructions.

Tout comme Google et OpenAI, Anthropic se focalise sur la course aux agents, souligné par le choix des benchmarks présentés par Anthropic pour vendre leur modèle : « Agentic coding » (SWE-bench-verified), « Agentic terminal coding » (terminal-bench), « Agentic tool use » (TAU-bench). Claude Opus 4 donne un nouveau état de l’art sur tous ces benchmarks, tout en restant au niveau de l’état de l’art (OpenAI o3 / Gemini 2.5 Pro) sur les tâches plus classiques. Ne vous attendez pas à un gros bond en avant, il s’agit là d’une amélioration incrémentale, contrairement à ce que pourrait laisser penser la numérotation de version.

À noter un benchmark sur lequel Claude 4 montre un gros progrès : LoCoDiff, qui cherche à mesurer la capacité des modèles à maintenir de bonnes performances sur un long contexte.

Une bonne nouvelle : OpenAI o3 avait cassé la tendance « les modèles plus avancés hallucinent moins », où o3 hallucinait plus que ses prédécesseurs. Anthropic a réussi à éviter cet écueil, avec un taux d’hallucinations en baisse. En baisse également (sans pour autant disparaître), la tendance des modèles à « tricher ».

L’événement le plus intéressant de cette publication se trouve principalement dans la politique de sécurité des modèles. N’ayant pu déterminer avec confiance que Opus 4 ne possédait pas de capacités dangereuses (telles que « capacité à aider significativement à la création d’armes chimiques/biologiques ») nécessitant des précautions supplémentaires (contrairement à Opus 3 ou Sonnet 4), Anthropic a décidé de mettre en place ces précautions (AI Safety Level 3 ou ASL-3), au moins provisoirement (le temps de déterminer plus précisément les capacités du modèle sur ces points), et pour Opus 4 uniquement. Ce qui signifie principalement : surveillance (automatisée) des requêtes et restrictions supplémentaires sur les requêtes acceptées. Pour plus de détails, je vous renvoie à la System Card et à la politique de sécurité des modèle d’Anthropic.

Ce qui n’a pas empêché Opus 4 d’être jailbreak immédiatement. Pour la défense d’Anthropic, la System Card mentionne explicitement que le but de ces précautions supplémentaires n’est pas de rendre plus difficile le jailbreak sur les requêtes « classiquement » interdites.

En vrac

Chatbot Arena est l’un des benchmarks les plus connus, utilisé notamment comme critère d’arbitrage sur les marchés de prédiction. Sa pertinence est de plus en plus remise en question, où le classement ne semble pas réellement refléter les capacités des modèles, sur d’autres benchmarks ou des évaluations privées/subjectives. Un papier publié sur arXiv, The Leaderboard Illusion, analyse l’impact de certaines pratiques pouvant expliquer ces différences. Les mainteneurs de Chatbot Arena répondent sur Twitter.

Le gouvernement américain ouvre une consultation publique sur la politique à suivre concernant l’IA.

Un chiffre intéressant: Cursor, un assistant de code, produit actuellement 1 milliard de lignes de code par jour.

DeepSeek publie DeepSeek-Prover-V2, un LLM spécialisé dans les preuves mathématiques. Surpasse tous les modèles actuels sur PutmanBench.

Dans la sécurité des modèles, "Scalable Oversight" désigne la technique suivante : utiliser un modèle considéré comme sûr pour évaluer la sécurité d’un modèle plus sophistiqué. Se posent diverses questions comme : "jusqu’à quel point un modèle moins sophistiqué peut juger un modèle plus sophistiqué" ? Ce papier tente de répondre à cette question (et d’autres adjacentes).

Google DeepMind met à jour son modèle le plus avancé, Gemini 2.5 Pro. De meilleures performances sur les tâches de programmation, mais au prix de moins bonnes sur… presque tout le reste ?

Le Copyright Office aux US publie un premier brouillon sur l’utilisation de données publiques pour l’entraînement des IA. Verdict temporaire: c’est un usage transformatif (autrement dit: pas du plagiat), mais ne rentre pas dans la doctrine du « fair use » (ce qui permettrait aux développeurs d’IA de ne pas offrir de compensation). Une victoire préliminaire pour les créateurs de contenu s’estimant lésés. Cependant, le directeur du Copyright Office aurait été limogé peu après la publication de ce rapport.

ARC-AGI-2 est publié. ARC-AGI est un benchmark spécialement conçu pour être dur pour les IA actuelles, se reposant principalement sur des tâches de type raisonnement visuel. Malgré ceci, o3 est arrivé à 75%, dépassant les performances des évaluateurs humains. Cette seconde édition tente un nouveau format mais garde le même objectif, « difficile pour l’IA, facile pour les humains ».

Quelque chose que je n’ai pas couvert jusqu’ici car un point secondaire dans beaucoup d’annonces plus importantes, mais qui mérite sa mention du fait justement d’être aussi commun : MCP (Model Context Protocol) est une tentative d’uniformiser la communication entre un modèle et d’autres systèmes (IDEs, sites internet,…). Développé par Anthropic (les développeurs de Claude), adopté par OpenAI et Google DeepMind, il devient de plus en plus un standard de fait.

Dans la série « l’IA fait de la recherche », des chercheurs font leur propre système, nommé Robin, où l’IA propose des hypothèses et des expériences pour les tester, les chercheurs réalisent les expériences, et l’IA se charge de l’analyse des résultats et des prochaines étapes (plus d’expériences, plus d’hypothèses, ou tirer une conclusion). Premier résultat : un candidat pour traiter la forme atrophique de la dégénérescence maculaire liée à l’âge.

OpenAI o3 découvre une faille de sécurité dans Linux.

Le mois dernier, nous avions brièvement mentionné que OpenAI 4o était flagorneur, au point d’opiner sur des prompts relevant manifestement de l’épisode psychotique. Un utilisateur anonyme explore la même tendance à un moindre niveau Opus 4, et travaille à mesurer ça plus précisément. Il mentionne que ses résultats préliminaires montrent que les modèles plus avancés ont plus tendance à exhiber ce comportement.

Dario Amodei, le patron d’Anthropic, prévient que l’IA pourrait supprimer la moitié des postes « débutants » dans des domaines tels que la technologie, la finance ou le droit d’ici 1 à 5 ans.

Pour aller plus loin

Non couvert ici :

• OpenAI Preparedness Framework 2.0: analyse de la nouvelle politique de sécurité des modèles d’OpenAI.
• GPT-4o Sycophancy Post Mortem: le mois précédent, une mise à jour de GPT-4o l’a rendu bien trop flatteur. Retour sur les raisons de l’incident en question.
• Zuckerberg's Dystopian AI Vision: Mark Zuckerberg a donné plusieurs interviews sur sa vision de l’utilisation de l’IA, en particuliers sur les réseaux sociaux. Résumé de cette vision.
• OpenAI Claims Nonprofit Will Retain Nominal Control: OpenAI annonce abandonner sa tentative de casse du siècle (même si certains doutent de l’honnêteté de cette annonce).
• Cheaters Gonna Cheat Cheat Cheat Cheat Cheat: témoignages et anecdotes sur l’utilisation de l’IA par les étudiants.
• A Live Look at the Senate AI Hearing: résumé des auditions que le sénat US a tenues sur le sujet de l’approche à prendre sur la régulation de l’IA. Pour faire court : « — il ne faut pas nous réguler pour que l’on continue à devancer la Chine — d’accord ».
• Fighting Obvious Nonsense About AI Diffusion: continuation de l’article précédent, où Zvi donne son point de vue sur la politique que devrait suivre le gouvernement US pour rester compétitif.
• Regarding South Africa: Grok, l’IA de xAI, s’est mise à répondre « le Génocide Blanc en Afrique du Sud est réel », sur des sujets complètement sans rapport. L’explication officielle est « une modification non-autorisée du message système ». Tout le monde se pose évidemment la question : qui donc a bien pu faire une telle modification ⸮
• America Makes AI Chip Diffusion Deal with UAE and KSA: analyse et critique de la décision du gouvernement US d’autoriser (et encourager) la vente de GPUs pour la création de datacenters dédiés à l’IA en Arabie Saoudite et aux Émirats arabes unis.
• Fun With Veo 3 and Media Generation: quelques exemples d’utilisation de Veo 3.

En audio/video :

• Une fois n’est pas coutume, une vidéo sur l’IA fait parler d’elle dans la sphère francophone: Maxime Fournes défend la thèse "Il est urgent de mettre l’IA en pause" chez Le Futurologue.
• Yoshua Bengio, que l’on a plus à présenter, donne une courte présentation destinée au grand public à TED (en anglais) sur le même sujet.

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.