Html5 on Zwindler's Reflection

Marp : présentations rapides et jolies avec Markdown

Mon, 13 Sep 2021 06:05:00 +0000

J’ai remplacé Powerpoint par Marp en 2019

Pendant des années, j’ai rédigé mes présentations professionnelles avec Powerpoint. J’étais un utilisateur correct de la suite Office en général (pas un roxxor, mais à l’aise).

Et là, c’est le drame, j’ai (enfin !) pu passer sous Linux sur ma machine pro. Ma vie est devenue tellement plus simple pour toutes mes tâches quotidiennes… SAUF… la rédaction de présentations.

J’ai vraiment pesté en passant à Libre Office. Je ne vais pas tacler ce dernier, beaucoup de la difficulté réside dans les formats ultras verrouillés de MS et le reverse engineering doit être horriblement complexe. J’ai donc commencé à chercher des alternatives.

It’s time to Duel…

J’ai donc demandé à mes petits collègues et copains speakers autour de moi ce qu’ils utilisaient comme moteur pour leurs présentations.

Grosso modo, les nerds m’ont répondu qu’ils n’avaient jamais quitté LaTeX et que pour les présentations ils utilisaient simplement Beamer, et les autres m’ont répondu Ascii doctor.

Pour la première, c’est une bonne alternative si vous n’êtes pas allergiques à la syntaxe de LaTeX (c’est mon cas). D’autant plus qu’on avait pas à l’époque d’aperçu en temps réel du code LaTeX (je ne sais pas si c’est toujours le cas) et qu’un néophyte passe beaucoup de temps à juste corriger les erreurs de syntaxe et de mise en page…

La seconde alternative est intéressante aussi. La syntaxe est plus digeste (je trouve) que LaTeX, il existe des éditeurs de texte capable de montrer un aperçu en temps réel du rendu final, et les formats d’export natifs incluent HTML 5, les manpages, les PDFs et ebooks,… bref, à peu près tout type de format récent qui peuvent intéresser un ingénieur en informatique qui partage quotidiennement sa connaissance. Sauf que la syntaxe d’AsciiDoctor est proche de celle de Markdown (au moins dans la philosophie) et pour avoir jonglé quelque temps entre les deux, il est facile de se prendre les pieds dans le tapis.

Or, j’utilisais déjà Markdown pour la rédaction de documentations de projets hébergés sur gitlab et accessoirement, pour rédiger une partie des articles de ce blog. Pour éviter mon auto-confusion et capitaliser sur mon habitude de Markdown, j’ai donc cherché une alternative à AsciiDoctor pour les présentations, mais en Markdown !

Entre alors Marp

Heureusement pour moi, j’ai trouvé très rapidement l’outil que je cherchais, et il s’appelle Marp. Pour être parfaitement précis, Marp est une collection d’outils open source (Marpit, Marp Core, Marp CLI, Marp for VSCode).

Ce que vous avez besoin de retenir c’est qu’en tant qu’utilisateur, vous n’aurez besoin que de Marp CLI si vous voulez générer vos decks de slides en ligne de commande. Un des gros intérêts de la CLI par rapport à une interface graphique est qu’elle va vous permettre d’automatiser la génération de vos decks de slide très facilement.

D’ailleurs, si ça vous intéresse, il se retrouve que Rémi Verchère a fait un article là-dessus il y a très peu de temps sur le compte Medium de LinkByNet : Making slides from anywhere for anyone using Marp, GitLab Pages and Gitpod.

Si en revanche vous préférez rédiger comme moi dans votre éditeur de texte et voir en live le support prendre forme, il existe donc aussi une extension VSCode pour Marp.

Comment ça marche ?

Grosso modo, Marp vient étendre le Markdown classique pour y ajouter :

La commande marp: true pour indiquer qu’il s’agit d’un document Marp et pas Markdown et une balise --- pour indiquer les nouvelles slides
des styles de slides et des thèmes customizables en CSS
un logiciel pour transformer le code Markdown en PDF ou HTML

Si vous êtes déjà à l’aise avec Markdown, vous remarquez donc que la prise en main est extrêmement simple. Finalement, si vous avez déjà un document Markdown, vous pouvez juste le transformer en présentation en ajoutant régulièrement des --- entre les paragraphes (j’exagère, mais vous voyez l’idée).

Et ce que j’apprécie particulièrement avec la preview Markdown, c’est qu’on a un visuel en temps réel de notre future documentation/présentation à partir de notre code.

Les styles

Out of the box, Marp propose 3 thèmes, qu’il est possible d’inverser (clair/sombre). La documentation sur ces thèmes est disponible ici.

En début de document, on indique qu’il ne s’agit pas d’un simple fichier Markdown, mais d’une présentation Marp de la façon suivante :

---
marp: true
theme: gaia
markdown.marp.enableHtml: true
paginate: true

Dans cet exemple, j’ai donc utilisé le thème Gaia, autorisé l’injection de HTML « perso » au milieu du code Markdown (on en reparlera) et ajouté le petit chiffre en fin de chaque slide avec « paginate: true ».

Bon… par défaut, c’est assez vite limité et pas super joli…

J’ai tout de suite voulu trouver d’autres thèmes (je n’en ai pas trouvé) et la documentation pour créer son propre thème est assez obscure.

Donc j’ai voulu customiser le mien, mais là aussi, la partie documentation sur la customisation/modification de thèmes existants est un peu légère, surtout si vous avez tout oublié en CSS comme moi.

Note: La documentation peu claire, c’est quasiment le seul reproche que je fais au projet Marp, tant j’en suis content. D’ailleurs, les développeurs de Marp travaillent à refaire la doc.

Grosso modo, la partie thème est gérée dans la partie « framework Marpit » (donc la partie la plus bas niveau du projet Marp). Vous trouverez ici la partie « customisation » via CSS Theme CSS (marp.app).

Ma personnalisation à moi

Je ne vais donc pas vous cacher mes petits secrets de speaker, je me suis donc fait un thème « par défaut » que j’utilise pour toutes mes conférences en tant que speaker et mes présentations internes (quand elles n’ont pas « besoin » du thème corporate).

En tout début de chaque deck, avant la première slide et après la partie Marp pure, j’ajoute ceci :

<style>
section {
background-color: #fefefe;
color: #333;
}
img[alt~="center"] {
display: block;
margin: 0 auto;
}
blockquote {
background: #ffedcc;
border-left: 10px solid #d1bf9d;
margin: 1.5em 10px;
padding: 0.5em 10px;
}
blockquote:before{
content: unset;
}
blockquote:after{
content: unset;
}
</style>

Le premier bloc change la couleur du fond des slides.
Le second me permet d’ajouter un paramètre « center » dans les images en Markdown pour la centrer (souvent très pratique quand on fait un peu de mise en page pour faire joli).
Les derniers me permettent de customiser l’apparence des blocs de « quotes ».

Ajouter des vidéos, du JS, etc

Si vous avez tout bien lu, vous vous souvenez peut-être que j’ai dit qu’on allait ajouter une option markdown.marp.enableHtml: true dans en début de fichier.

Ça va nous permettre de rajouter des bidouilles en HTML pour étendre un peu le Markdown et réaliser les 2-3% qui ne sont pas couverts par le langage.

Je l’utilise notamment de temps en temps pour rajouter un sauf de ligne pour faciliter la lecture, mais aussi lorsque j’ai besoin d’intégrer une vidéo dans un support.

Dans ce cas-là, j’ajoute la balise HTML suivante :

<div id=video><video controls="controls" width="800" src="binaries/microsoft_dance.mp4"></video></div>

Un exemple

Je ne vais pas continuer plus longtemps la liste des features de Marp, mais si vous voulez un exemple, j’ai mis à disposition le code Markdown ma conférence « Ciel ! Mon Kubernetes mine des Bitcoins ! »

Have fun !

Client web pour version ESXi hors vCenter, le VMware Host Client

Thu, 26 May 2016 11:55:27 +0000

VMware Host Client : Le Half Life 3 des clients d’administration des hyperviseurs

Oui alors on a bien une version gratuite, pas de souci. Mais … vous ne pourrez plus utiliser le client lourd. Du coup il vaudrait mieux que vous vous payez un vCenter pour l’administrer, non ?

Cela fait un moment que VMware nous a annoncé que le client lourd (Java) ne serait plus mis à jour avec les nouvelles fonctionnalités. Et il faut dire que ce n’était pas forcément simple car il fallait installer le client de chaque version mineure (par exemple 5.0, 5.1, 5.5) pour pouvoir vous connecter à toutes vos versions, pas simplement la plus récente. Mais il avait le mérite de plutôt bien marcher et restait une référence correcte.

Pour autant, on ne peut pas dire que l’alternative proposée par VMware ait été particulièrement crédible. Le vSphere Web Client, censé corriger tous les défauts de la version client lourd avait quand même encore quelques gros défaut (mais certains étaient nouveaux alors c’est pas grave, non ?).

Pour avoir le vSphere Web Client, pas d’alternative, il vous faut vous payer un vCenter ! A quoi bon proposer un hyperviseur gratuit si c’est pour faire payer le client d’administration ? Ceci a longtemps été une vaste blague de la part de VMware avec aucune réponse officielle.

Pour autant votre client lourd reste vital pour certaines opération, comme l’accès direct aux ESXi sans passer par le vCenter. Le vCenter est down ? Dommage ! Vous pouvez ressortir le client lourd et tout refaire comme avant. Sauf ce que vous ne pouvez plus faire parce que réservé à la version web client.

Le vSphere Web Client nécessite l’installation de Flash sur le navigateur du poste d’administration, ainsi que plusieurs plugins à télécharger et à autoriser dans le navigateur pour pouvoir fonctionner à pleine capacité. Autant dire que l’avantage « c’est du web, donc 0 installation » vient instantanément de disparaitre…

Au delà de ces points rédhibitoires, le client web dans sa version actuelle est très lent et le serveur est assez gourmand en ressources (côté vCenter).

Bref on ne peut pas dire que je sois un grand fan. D’ailleurs, j’ai longtemps résisté à l’appel de la migration du hardware virtuel en v9, 10, et 11 car je savais que je ne pourrais plus modifier les paramètres (!!!) sur le client lourd une fois que ça aurait été fait (si le client web ne fonctionne plus, on fait quoi ? Oups…). Et oui, pas de mises à jour sur le client lourd ;-).

ENFIN !

Et bien CA Y EST !

Introduit avec la v6 en « test », VMware a créé un composant VIB (composant pour ESXi, à installer sur le serveur directement pour ceux qui ne connaissent pas) qui fourni un serveur web avec les fonctionnalités de base pour piloter l’ESXi et les VMs. Attention le but n’est pas de remplacer le vCenter mais bien de combler le vide d’un serveur pour piloter votre ESXi directement, sans vCenter et sans utiliser le client lourd.

Voici la liste des opérations qui peuvent être réalisées depuis ce Host Client :

Opérations basiques sur la machine virtuelle (démarrer, arrêter, etc)
Afficher la console de la machine virtuelle
Création d’une nouvelle machine virtuelle & déploiement d’un OVF/OVA
Afficher les informations sur l’état de de l’hyperviseur
Configuration du serveur ESXi et des ses composants comme vous le feriez avec le client lourd
Opérations basiques sur l’ESXi comme le rebooter

Initialement, pour l’installer il fallait installer soit même le fichier VIB sur l’ESXi et le rebooter. Cependant le composant étant passé en version 1, il est directement intégré à la toute nouvelle version d’ESXi 6.0 Update 2.

Les erreurs du passé

Et pour ne rien gâcher, même si l’interface web ressemble comme 2 gouttes d’eau au vSphere Web Client, il semblerait que VMware n’ait pas reproduit les erreurs du passé avec ce VMware Host Client, entièrement en HTLM5 et Javascript. Pas de Flash et de plugins navigateurs à installer, simplement le Javascript a autoriser sur les URLs de vos serveurs.

Dommage pour VMware que, faute d’une solution sans vCenter crédible, j’ai migré mon lab personnel sur KVM… ;-)

Sources

pubs.vmware.com/Release_Notes/en/vsphere/60/vmware-host-client-10-release-notes.html (lien mort comme tout chez VMware)
www.vladan.fr/esxi-free-web-client-interface/

Mise en place de Guacamole 0.9.5 sur CentOS 7

Sun, 31 May 2015 09:49:36 +0000

Pour information : je me suis basé sur le très bon article de Deviant Engineer, qui est concis, s’affranchit de la conf par fichier plat au profit du module MySQL, et surtout qui fonctionne, ce qui n’est pas le cas de tous les tutoriels que j’ai pu croiser sur la toile.

Aujourd’hui, au même titre que l’informatique s’est généralisée, Internet est de plus en plus présent, où qu’on se trouve. Mais ce n’est pas toujours un Internet comme à la maison.

Pour des raisons de sécurité et/ou de bande passante, certains ports/protocoles/site web sont souvent bloqués sur les points d’accès public ou d’entreprise. Il n’est pas rare que seul l’HTTP et l’HTTPS soient disponible, me privant ainsi de mes accès SSH/VPN/FTP/…
C’est un vrai casse tête pour moi : je déploie des services chez moi et j’en deviens dépendant au point d’être agacé de ne pas y avoir accès en toutes circonstances. Et plutôt que de relativiser cet absence d’accès absolu à mes services/données, je préfère chercher des moyens de contournement ;).

Si l’autohébergement d’applications web et l’utilisation d’un reverse proxy (Vulture/Apache) répond à une partie de cette problématique, des fois, j’ai parfois besoin d’avoir accès aux machines qui hébergent ces services. C’est pourquoi j’utilisais jusqu’à présent Ajaxterm, puis Gateone pour disposer d’un accès SSH à mes serveurs en cas de filtrage.

Cependant, j’ai aussi besoin de me connecter en mode graphique sur mes serveurs. En présentant au travers d’une interface HTML5 des clients pour les protocoles SSH, VNC et RDP, Guacamole répond à ce besoin.

Quelques ressources pour bien commencer :

La documentation officielle décrit comment l’installer à partir des sources. Cependant, sur certains systèmes, les applications ont été packagées et sont disponibles (0.8.4 si je ne m’abuse sur RHEL et CentOS). Je voulais avoir la version la plus récente, je me suis donc penché sur la solution « compilation ».

Et pour avoir une compatibilité maximale en terme de fonctionnalités, il faut disposer de Tomcat 7, présent nativement dans RHEL7/CentOS7, que j’ai donc installé (mon premier CentOS7, youhou !)

Prérequis

Forcément, la première chose à faire lorsqu’on installe une application web un peu exotique sur un CentOS, c’est d’installer les dépôts additionnels pour les dépendances (ici EPEL).

rpm -Uvh http://mirror.metrocast.net/fedora/epel/7/x86_64/e/epel-release-7-5.noarch.rpm # EPEL Repo
yum -y install wget
wget http://download.opensuse.org/repositories/home:/felfert/Fedora_19/home:felfert.repo && mv home\:felfert.repo /etc/yum.repos.d/ # Felfert Repo
yum -y install tomcat libvncserver freerdp libvorbis libguac libguac-client-vnc libguac-client-rdp libguac-client-ssh
yum -y install cairo-devel pango-devel libvorbis-devel openssl-devel gcc pulseaudio-libs-devel libvncserver-devel \
freerdp-devel uuid-devel libssh2-devel libtelnet libtelnet-devel tomcat-webapps tomcat-admin-webapps java-1.7.0-openjdk.x86_64

Installation du composant « serveur »

Le logiciel est découpé en deux parties. Une partie « serveur » qui correspond au portail web, et une partie dite « cliente », qui se charge de la connexion aux différents serveurs SSH/~~telnet~~/VNC/RDP que vous aurez configurés. J’ai rayé telnet car je refuse d’utiliser ce protocole (à l’exception de certaines contraintes de travail très particulières).

cd /distrib
wget http://sourceforge.net/projects/guacamole/files/current/source/guacamole-server-0.9.5.tar.gz
tar -xzf guacamole-server-0.9.5.tar.gz && cd guac*0.9.5
./configure --with-init-dir=/etc/init.d
make
make install
ldconfig

Installation du du composant « client »

La partie client peut directement être récupérée tel quel sur le site du projet.

mkdir -p /var/lib/guacamole && cd /var/lib/guacamole/
wget http://sourceforge.net/projects/guacamole/files/current/binary/guacamole-0.9.5.war -O guac.war
ln -s /var/lib/guacamole/guac.war /var/lib/tomcat/webapps/
rm -rf /usr/lib64/freerdp/guacdr.so
ln -s /usr/local/lib/freerdp/guacdr.so /usr/lib64/freerdp/

MariaDB (MySQL)

Ne soyez pas surpris de découvrir MariaDB. MariaDB, c’est MySQL. Ou plutôt ce que MySQL aurait du devenir. Il s’agit d’un fork de MySQL initié par son créateur qui a réalisé qu’Oracle (qui a racheté Sun Microsystems en 2009) risquait d’envoyer le produit dans le mur (en concurrence avec Oracle Database).
MariaDB a donc progressivement remplacé MySQL dans les communautés Open Source et les entreprises (citons Google en 2013), et RedHat a suivi le mouvement avec la version 7 de RHEL.
Pas de mauvaise surprise si vous êtes habitués à MySQL : tout est identique en terme d’administration. Vos scripts fonctionneront toujours, les binaires n’ont pas changés.

Installation de la base de données

yum -y install mariadb mariadb-server
cd /distrib
wget http://sourceforge.net/projects/guacamole/files/current/extensions/guacamole-auth-mysql-0.9.5.tar.gz
tar -zxf guacamole-auth-mysql-0.9.5.tar.gz
wget http://dev.mysql.com/get/Downloads/Connector/j/mysql-connector-java-5.1.32.tar.gz
tar -zxf mysql-connector-java-5.1.32.tar.gz
mv mysql-connector-java-5.1.32/mysql-connector-java-5.1.32-bin.jar guacamole-auth-mysql-0.9.5/lib/
mkdir /var/lib/guacamole/classpath/
cp /distrib/guacamole-auth-mysql-0.9.5/lib/* /var/lib/guacamole/classpath/
systemctl restart mariadb.service

Configuration de la base de données

mysqladmin -u root password MySQLRootPass
mysql -u root -p # Enter above password
create database guacdb;
create user 'guacuser'@'localhost' identified by 'guacDBpass';
grant select,insert,update,delete on guacdb.* to 'guacuser'@'localhost';
flush privileges;
quit

Création du schéma pour Guacd

cd /distrib/sqlauth/guacamole-auth-mysql-0.9.5/schema/
cat ./*.sql | mysql -u root -p guacdb # Enter SQL root password set above

Configuration, création du fichier « .properties »

mkdir -p /etc/guacamole/ && vi /etc/guacamole/guacamole.properties
# Hostname and port of gucamole proxy
guacd-hostname: localhost
guacd-port: 4822
# Location to read extra .jar's from
lib-directory: /var/lib/guacamole/classpath/
# Authentication provider class
auth-provider: net.sourceforge.guacamole.net.auth.mysql.MySQLAuthenticationProvider
# MySQL properties
mysql-hostname: localhost
mysql-port: 3306
mysql-database: guacdb
mysql-username: guacuser
mysql-password: guacDBpass
# Additional settings
mysql-disallow-duplicate-connections: false

Post-installation

Ne pas oublier de nettoyer les répertoires contenant les sources (dans /distrib chez moi), ajouter un lien symbolique vers le fichier de configuration et ajouter le démarrage automatique des services

mkdir -p /usr/share/tomcat/.guacamole
ln -s /etc/guacamole/guacamole.properties /usr/share/tomcat/.guacamole/
systemctl enable tomcat.service && systemctl enable mariadb.service && chkconfig guacd on

Le serveur devrait être accessible à l’adresse http://@IP_serveur:8080/gucamole**/**. A partir de là, vous pouvez configurer vos serveurs SSH/RDP/VNC, créer des utilisateurs et vous connecter.

Deux derniers points :

les logs ne sont pas toujours très locaces. Chez moi, il se trouvent dans /var/log/messages et /var/log/tomcat/
il manque selon moi un menu pour gérer les connexions actives. Typiquement, dans le cas de VNC, le soft m’indique que j’ai 4 ou 5 sessions ouvertes. Elles n’ont pas l’air concurrentes (je n’en ai qu’une réellement active), mais me parait potentiellement même problématique

Publier sur le WAN la WebUI de Shinken via Vulture

Sun, 21 Oct 2012 19:13:14 +0000

Ceux d’entre vous qui me suivent savent déjà que je suis de manière avide tous les développements du projet Shinken, un outil de supervision compatible avec Nagios, mais qui apporte des fonctionnalités de haute dispo et de vue business bien supérieures à ce qu’on peut faire simplement avec Nagios. Depuis quelques temps, les développeurs de Shinken ont beaucoup bossé sur une interface plus épurée et pourtant plus puissante que celle de Nagios (voire même Centreon pour certaines idées) en HTML 5.

Dans les débuts de cette interface, j’ai eu le plus grand mal à la faire passer au travers de mon web proxy applicatif personnel (Vulture). Aujourd’hui, avec la stabilisation du code de la WebUI de Shinken et aussi une meilleure compréhension des mécaniques de vulture, j’ai réussi à la faire passer sur Internet et je peux donc consulter à tout instant l’état de mon infra perso, ce qui, vous en conviendrez, est une nécessité absolue.

Mais trêves de bavardages. La première chose que je tiens à dire, c’est que cet articule ne couvrira pas l’installation de Shinken, pour la bonne et simple raison que j’ai horreur d’écrire des articles quand des blogs/forum/wiki existent déjà pour dire la même chose. Pour rappel :

Si vous souhaitez installer Shinken, vous n’avez qu’à exécuter la commande suivante :

Page de download de Shinken (lien mort, remplacé par Internet Archive)

Pour configurer Shinken

10 Minute Shinken Installation Guide (lien mort, remplacé par Internet Archive)

Passons maintenant aux choses sérieuses. Dans un premier temps, vous avez installé et configuré Shinken, il fonctionne, et vous pouvez ouvrir votre WebUI en local

Le dashboard classique de l’outil de supervision de base. C’est la moins sexy des vues de Shinken mais je reste un peu vieux jeu

Maintenant, tout se passe côté Vulture. Je pars du principe que vous disposer d’un nom de domaine (on n’a qu’à prendre vulture.fr, au hasard), et que vous avez mappé les adresses suivantes sur l’IP depuis votre domaine vers votre serveur vulture

portal.vulture.fr
shinken.vulture.fr
pnp.vulture.fr

Vous l’aurez certainement deviné, la première sert au portail et est rattaché à la définition de l’interface vulture. Tout arrivera sur cette interface (pour ceux qui en ont plusieurs, pour les autres qui n’en ont qu’une, c’est évident). Cependant pour les deux autres, vous pouvez remarquer que j’ai été obligé d’utiliser deux noms différents pour ma WebUI (au moins dans un premier temps, en attendant de trouver une meilleure façon de faire). Et pour cause…
Malheureusement, la WebUI utilise un composant python qui génère du code HTML 5 à la volée, en écoute sur le port 7767. Cependant, pour compléter un peu la vue des services et notament pour ce qui est des perfdata, l’équipe de Shinken à pris le parti de réutiliser le travail de pnp4nagios, qui est intégré directement dans l’interface. Or, pnp4nagios est un composant web tout ce qu’il y a de plus basique, qui tourne dans un apache sur le pour 80 (ou n’importe quelle autre port, on s’en fiche, juste pas le 7767).

Du coup, vu de vulture, j’ai été contrains à créer deux applications, et donc à leur donner deux noms distincts. C’est là la partie qu’il reste à améliorer. Il est surement possible de faire mieux, pour l’instant je n’ai pas trouvé…

Une fois nos deux applications définies dans vulture, il reste encore un petite opération pour que le tout fonctionne. A l’heure actuelle, le code de Shinken à la facheuse tentance à générer des liens et à rediriger automatiquement vers des pages via des URLs absolues… du type http://@IP_locale/webui. En local, votre navigateur saura résoudre cette IP privée, mais pas sur Internet. C’est pourquoi nous allons demander à vulture de réécrire tous les contenus qui posent problèmes à la volée. Pour cela il faut aller dans le menu « Plugin de réécriture de contenu ». Il faudra transformer toutes les requêtes qui sont en HTTP en local en HTTPS derrière vulture, et transformer les URL pnp pour qu’elles pointent vers la bonne application.

Shinken crache des liens HTTP simple toutes les 30 secondes, ce qui est fâcheux quand votre vulture écoute sur du HTTPS

la webui génère de moches adresses IP locales que vulture n’ose pas modifier sans notre accord explicite

Une fois ces étapes réalisées, vous devriez pouvoir afficher la webui derrière votre vulture comme si vous étiez en local. Reste donc à accepter les certificats autosigner, à s’authentifier dans la WebUI PUIS dans pnp4nagios, et le tour est joué. Et comme vulture est un SSO en plus d’être un firewall applicatif, il sera aussi possible de bypasser ces deux authentifications, mais ceci fera l’objet d’un article ultérieur (quand j’aurai pris le temps de comprendre comment ça fonctionne)