Ce 27 juillet 2026, le collectif Emmabuntüs vient d’annoncer la sortie de sa nouvelle version Emmabuntüs Debian Édition 6 1.02, basée sur la Debian 13.6 Trixie et supportant les deux environnements de bureau XFCE et LXQt.

Rappelons que cette distribution est née au sein du Mouvement Emmaüs, pour faciliter le reconditionnement des ordinateurs donnés aux associations, notamment humanitaires, mais aussi pour favoriser la découverte de GNU/Linux par les débutants, tout en prolongeant la durée de vie du matériel informatique, ce qui réduit le gaspillage lié à la surconsommation de matière première.

La nouvelle évolution de cette distribution concerne essentiellement des améliorations en matière d’accessibilité avec notamment un retour à la version stable d'Orca 48.1.1 ainsi qu’une meilleure prise en charge de la synthèse vocale Piper, ce qui améliore notablement le confort d’écoute du système.
Cette distribution a été utilisée lors de la première séance de formation dispensée au Centre Polyvalent Saint-Augustin de Lomé, à l'intention des futurs référents représentant les 10 structures spécialisées pour les personnes déficientes visuelles du Togo.

Pour mémoire ces actions se font en collaboration étroite avec l’A.S.I. YOVOTOGO qui prévoit aussi l’installation d’une première salle informatique au Cameroun, marquant une nouvelle étape dans l’expansion géographique de ses actions dans cette région d’Afrique.

Passer du système de gestion de contenu WordPress au générateur de sites statiques Hugo c’est changer de paradigme, il faut savoir ce que l’on va gagner et ce que l’on va perdre et il faut retrousser ses manches, un jour viendra où cela se fera en un clic, mais ce n’est pas aujourd’hui !

Sommaire

• Avant même de se poser la question comment, on peut se poser la question : pourquoi ?
  • Mais pourquoi Hugo et pas une autre solution, par exemple Jekyll ?
• Ma vie, mon œuvre
• WordPress via le navigateur, Hugo via le terminal
• On installe le plugin, clic ! On importe le résultat et c’est fini !
• Exportez votre site WordPress et appliquez un outil magique !
• La vérité est ailleurs ?
• On installe Hugo
• C’est pas beau hein ?
  • Les blocs réutilisables de WordPress
  • Les <figure>
  • URL permanentes
  • URL relatives
  • Le menu
• Un site WordPress c’est un site web comme un autre
• On repart de zéro et on mélange tout
  • Variations mais pas sur le même thème

Avant même de se poser la question comment, on peut se poser la question : pourquoi ?

Avec WordPress chaque page repose sur du PHP, un programme est exécuté qui peut faire de nombreuses actions, il y a une base de données. WordPress est un des classiques LAMP (Linux, Apache, MySql, PHP) et consorts, il nécessite l’installation de multiples composants. Quand le contenu à délivrer doit s’adapter au contexte utilisateur et à d’autres facteurs, c’est approprié, pour un site de commerce ça l’est, s’il s’agit d’une vitrine statique, ça ne l’est pas. Entre les deux on trouve le blog, qui peut se balancer d’un côté ou de l’autre si l’on souhaite gérer des accès utilisateurs, suivre les pages ou ajouter des interactions.

Avec Hugo, le site est généré une seule fois puis les pages sont délivrées, à l’ancienne dirait-on. À la grande époque où l’on éditait le HTML à la main et on publiait son site via FTP. Sauf qu’avec Hugo on manipule du Markdown plutôt que du HTML. Le Markdown est pratique, c’est l’héritage pragmatique d’Aaron Schwartz dont on peut encore trouver la trace dans le code PHP de génération. Le Markdown lui-même porte une étincelle de liberté, il est désormais normalisé dans la RFC 7763. Et on utilise le programme Hugo qui est un binaire fourni, ou bien compilé depuis du code Go, pour générer des pages HTML. Le site généré peut être délivré en http par Hugo ou bien par n’importe quel serveur web. Hugo repose aussi sur des en-têtes front-matter dans les fichiers Markdown qui est une extension plus récente.

Sortir de WordPress c’est sortir d’une zone de confort et ce sera nécessairement perdre des fonctionnalités, comme l’édition en ligne directe intégrée par exemple, le suivi de vues et les formulaires.

C’est aussi faire un choix simplificateur, économe et efficace. Beaucoup moins énergivore il est aussi beaucoup plus efficace et rapide. Il est aussi beaucoup plus facile à déployer qu’un WordPress puisqu’en définitive ce n’est qu’un binaire et un thème.
Une autre bonne raison de migrer est la sécurité, comme a pu le faire le projet Xubuntu à la fin de l’année dernière suite à la compromission de leur site de téléchargement sous WordPress

Mais pourquoi Hugo et pas une autre solution, par exemple Jekyll ?

Hugo est la version la plus efficace, écrit en Go et compilé, les performances se rapprochent sans les égaler de celles de Rust ou de C. Et il est maintenu, dispose d’une communauté qui maintient des thèmes permettant de facilement avoir un rendu à la mode. Jekyll est en Ruby qui n’est pas le plus performant des langages mais est très versatile. Jekyll est apparu avant Hugo ce qui explique sa notoriété.

Ces deux logiciels ont popularisé la génération de sites statiques, mais ce ne sont pas les seuls, eleventry par exemple a déjà été couvert par un journal sur LinuxFr.org.

Ma vie, mon œuvre

Dans mon cas je ne me suis pas posé la question puisque je réponds à une demande d’une personne qui a déjà fait son choix, il faut migrer !

Avant de me lancer dans l’aventure j’ai dû me renseigner, parce que j’opère bien un site statique qui me sert de vitrine et celui-ci est en Markdown sous Git, mais tout est fait à la main et je ne connais pas Hugo. Je ne suis pas non plus un grand utilisateur de WordPress, que j’ai toujours trouvé lourd, et d’ailleurs j’ai toujours eu un faible pour les challengers, et je m’étais penché sur Joomla qui a les mêmes défauts. Utiliser ces CMS c’est déjà avoir appris une façon de penser, avec les pages et les posts, cela ne m’a jamais paru intuitif.

Donc j’étais absolument et résolument prêt pour cette migration !

Vous pouvez à ce moment me demander pourquoi donc l’ai-je fait ?

Parce qu’un ami me l’a demandé, parce qu’il rémunère pour cela et parce que je trouve que cela va dans le bon sens. Celui de l’éco-responsabilité, une sobriété qui ne transige pas avec la qualité et un mouvement vers plus d’indépendance.

Donc je me renseigne.

WordPress via le navigateur, Hugo via le terminal

Si vous ne souhaitez pas utiliser de terminal et des scripts shells, alors je serais d’avis de vous déconseiller fortement de vous lancer dans l’aventure Hugo.
Parce qu’Hugo c’est du Web as code, très exactement l’inverse du WYSIWYG le PETALE Pris à l’écrit tel à l’écran. Tout se fait en Markdown dans votre éditeur favori.
Cela s’opère souvent via Git et le fait de pousser le commit git vers le serveur régénère le contenu du site.
S’il est possible de le faire via un VSCodium, je reste sur mon Emacs favori, mais évidemment ceci un choix très personnel.
Un bon éditeur de texte capable de te laisser saisir des codes Markdown est absolument nécessaire, un éditeur de texte dans ce cas ce n’est pas un traitement de texte, Libreoffice par exemple ne m’apparait pas comme l’outil adapté, mais je vous laisse juge.

On installe le plugin, clic ! On importe le résultat et c’est fini !

C’est assez évident en fait il suffit de suivre ce que propose le projet Hugo en matière de migration vers Hugo.

Ça c’est ce que l’on souhaite et j’y ai presque cru.

Il n’y a pas de plugin WordPress officiel pour exporter vers Hugo, mais il y en a pour exporter en Jekyll. Sachant que Hugo sait importer du Jekyll, cela semble évident.

Tout d’abord il faut importer le plugin sous WordPress.
Si cela semble évident quand le plugin est disponible dans le magasin des plugins WordPress, cela ne l’est plus quand il faut l’installer à la main.

Dans mon cas, et peut être dans le vôtre aussi vous n’avez pas installé le WordPress, il vous a été fourni en tant que service hébergé, et c’est pourquoi vous êtes limités aux plugins officiels, quand encore, on vous y autorise.

Donc en suivant le lien de migration depuis WordPress je lis (en anglais, mais je vous offre gratuitement la traduction) :

wordpress-to-hugo-exporter

Un plugin en un clic qui convertit tous les posts, pages, taxonomies, metadata, et settings en Markdown et YAML et déposable dans Hugo. (Note: Si vous avez des difficultés avec ce plugin, vous pouvez exporter le site pour Jekyll et utiliser le convertisseur intégré à Hugo listé ci-dessus)

Oui mais non, je n’ai pas accès au backend.

Et pourquoi ne pas juste installer un plugin officiel comme celui dont wordpress-to-hugo-exporter dérive ? Le jekyll-exporter

Ce n’est pas un échec, mais ça n’a pas marché.

Après l’installation du plugin et l’utilisation de l’export le site me réponds avec aplomb : 500 Internal ERROR.

Plutôt que d’abandonner, je cherche sur le projet source s’il y a un bug en cours et effectivement : Issue #400 sur wordpress-static-site-exporter. Sur ce, je rajoute mes informations sur le bug et j’attends une réponse.

Donc le ça fonctionne en un clic n’aura pas tenu bien longtemps, en attendant un correctif je me penche sur une alternative. Mais ne vous inquiétez pas, nous y reviendrons, si vous avez suivi le lien de l’issue vous le savez déjà !

Exportez votre site WordPress et appliquez un outil magique !

Ce n’est pas bien grave, il y a d’autres outils…

blog2md
Fonctionne sur l’XML exporté depuis le site gratuit votre VOTRE-DOMAIN.wordpress.com. Cela sauve aussi les commentaires approuvés sous forme YOUR-POST-NAME-comments.md à côté des posts.

Ce projet n’a pas évolué depuis quatre ans, je ne vais pas choisir cette option.

wordhugopress
Un petit utilitaire écrit en Java qui exporte le site WordPress depuis la base de donnée et les resources (c’est-à-dire par exemple les images) stockées localement ou à distance. Ainsi la migration depuis des backups est possible. Support de multiples sites vers un seul site Hugo.

Je n’ai pas accès à la base de données où à l’export des backups, je ne vais pas choisir cette option non plus.

wp2hugo

Celui-ci est un très bon candidat, sauf que je vends mon travail et la licence de cet outil est Attribution-NonCommercial-ShareAlike 4.0 International, donc je ne vais pas choisir cette option. Si mon budget avait été très important j’aurais envisagé de contacter l’auteur pour négocier, mais ce n’est pas le cas.

Donc aucun de ces autres outils ne répond à mes besoins.

La vérité est ailleurs ?

Oui, mais il n’y a pas que site Hugo de référence non plus.

Les forums et en particulier https://discourse.gohugo.io/t/wordpress-migration-url-rewriting/3827, mais il a été écrit il y a presque dix ans…
Et dans mes pérégrinations hors des sentiers battus des scripts Python émergent https://www.infinitescript.com/2024/01/migrate-from-wordpress-to-hugo/.
Ce guide aussi m’a inspiré https://fr.benchwiseunderflow.in/blog/guide-complet-migration-wordpress-hugo/ ceci dit fournir les scripts Python dans son blog sans l’indentation, ce n’est pas ce qui se fait de mieux.

Voici la liste des projets que j’ai regardés, je n’en ai testé qu’une sous partie entre ceux utilisant de l’IA ou pour lesquelles mon utilisation ne respecterait pas la licence et celles dont le contenu semble trop vieux…

C’est wordpress-export-to-markdown qui a remporté une partie du travail. Cela a nécessité l’installation de node puisque le code est en javascript.

J’exporte donc le site via la fonction standard d’export de site WordPpress qui fourni un fichier XML.

Cet export contient tout sauf les images et les autres ressources, donc il faudra que l’outil puisse les rechercher, et donc que le site WordPress soit toujours activé. Ceci ne peut donc pas se faire sur un site indisponible ou bien même déjà arrêté.

On installe Hugo

Et il faut un serveur, une vraie machine avec une adresse IP publique, un serveur web.
Là où pour du WordPress un hébergeur fournit la solution, en Hugo le plus classique est tout de même de mettre en place son propre serveur. Avec tout ce qui va bien, et le certificat pour HTTPS.

Mais avant de faire le pas, cela s'installe en local sur une machine de développement avec docker, podman, inclus ou bien même directement puisque ce n’est qu’un exécutable.

sur une machine Linux :

sudo apt install hugo

ou

snap install hugo

Il suffit de lancer hugo server dans le répertoire du projet hugo et se connecter sur localhost avec l’URL qui a été fournie dans le terminal.

Dans le cas d’une migration vous aurez forcément à modifier de nombreuses pages de votre site qui comportent des problèmes de code markdown mal converti depuis le HTML.

Et il vous faudra utiliser des scripts, dans votre langage préféré, mais dans tous les cas l’utilisation d’expressions régulières sera nécessaire. C’est-à-dire : il faut connaître un minimum de programmation.

Voici le genre de commande qui recherche tous les fichiers avec l’extension.md et supprime le 'Proudly powered by WordPress' dedans :

text='Proudly powered by <a href="https://wordpress.org" rel="nofollow">WordPress</a>'
find content -name '*.md' -print0 | xargs -0 sed -i 's|'"$text"'||g'

Attention cette commande fonctionne, car le texte $text est compatible avec la syntaxe de commande sed en particulier utiliser un '|' dans la variable text serait problématique.

En suivant la procédure d’installation rapide https://gohugo.io/getting-started/quick-start/ on va créer un dépôt git. Si par la suite on souhaite le répliquer pour le tester ailleurs alors il ne faudra pas oublier les submodules pour le thème, sinon la génération du site rendra un site vide.

git clone user@server:quickstart --recurse-submodules mon_site
cd mon_site
hugo server

On termine avec un firefox http://localhost:1313 par exemple pour voir en local.

on pourra alors éditer le contenu sous content avec notre éditeur préféré et créer un commit git quand nous sommes contents de notre résultat local.

git add content
git commit -m 'édition numero xx du site'
git push

Cela doit pousser sur le git parent le contenu. Si le git parent est attaché à la production alors la production est mise à jour ainsi.

C’est pas beau hein ?

Le contenu généré par l’outil de migration ayant été copié dans le répertoire content du projet Hugo, il suffit de lancer le serveur Hugo pour qu’il soit délivré sur le port indiqué en console. En se connectant avec un navigateur firefox https://localhost:1313, le contenu apparait…

Ah j’oubliais, en Hugo toute la présentation est contrôlée par le thème, ici le thème choisi est ananke, c’est celui proposé dans la documentation de démarrage rapide de Hugo

Il y a du contenu, certes mais quand même il y a eu des dégâts collatéraux.

Cliquez sur l’image pour voir la vidéo.

Les blocs réutilisables de WordPress

Il s’agit d’une fonctionnalité ajoutée dans l’éditeur de WordPress Gutemberg, la possibilité de créer des blocs réutilisables qui seront référencés dans d’autres pages ou bien même dans d’autres blocs

Pratiquement tous les outils d’export ne conservent pas les items qui ne sont ni de type page ni de type post et quand ils conservent les autres type, ils ne gèrent pas les blocs réutilisables.

Dans le fichier d’export.xml de WordPress on les retrouve ainsi :

<item>
…
<wp:post_id>610</wp:post_id>
…
</item>

et sont utilisés par référence :

<!-- wp:block {"ref":610} /-->

Dans mon cas pour l’outil wordpress-export-to-markdown, j’ai créé une demande de fonctionnalité pour le support des blocs réutilisables.

En pratique les outils perdent complètement le contenu de ces blocs.

Une façon de résoudre le problème est d’utiliser la source HTML générée par WordPress directement et de la convertir en Markdown.

Les <figure>

Hugo ne gère pas le tag <figure>, il faut supprimer ces tags, sinon les images qu’ils contiennent n’apparaissent juste pas. Or WordPress génère souvent des blocks HTML avec des tags figure.

Voici un script bash qui supprime le tag figure partout dans tous les fichiers.md de content.

find_files=(find content -name '*.md' -print0)
command2=(xargs -0 sed -i 's|</\?figure[^>]*[>]||g;')
"${find_files[@]}" | "${command2[@]}"

URL permanentes

Il est crucial que les pages migrées se retrouvent au même endroit après migration. C’est crucial car cela fait partie du SEO, votre référencement, si vos pages changent de place, les moteurs de recherche vont vous perdre, tout comme les références depuis tout autre site.

En Hugo c’est le champ urldans l’entête front-matter du fichier markdown qui sert à indiquer où la page destinée à être délivrée.
Cette URL peut être totalement différente du répertoire dans lequel le fichier se trouve, même s’il est conseillé de conserver la mẽme hiérarchie, c’est une solution pratique.

URL relatives

WordPress délivre toutes ses pages avec des URL absolues dans le corps c’est-à-dire avec le nom du site intégré dans l’URL, ceci est un souci quand on souhaite déplacer le site, ou bien avec un site réplica lui aussi accessible en ligne mais sous une autre URL.

Les expressions régulières sont là pour ça, il faut supprimer http://monsite du début des toutes les URL. Pour rappel, à l’intérieur d’une page HTML un lien href='/article/linuxfr.html' est une référence relative dans le site courant, si l’URL du site est https://example.com alors le lien avec l’URL absolue est au lien `href='https://example.com/article/linuxfr.html'.

Si vous ne faites pas vous pourriez avoir la surprise lors de l’arrêt du site WordPress de ne plus avoir les images et autres ressources, car elles étaient sur le site original et non sur le nouveau site migré !

voici un exemple en bash

find_files=(find content -name '*.md' -print0)
command2=(xargs -0 sed -i "s|https://${site_domain}||g")
"${find_files[@]}" | "${command2[@]}"

Le menu

Le menu a été perdu, c’est ballot !
Via l’export Hugo il n’y a pas de menu du tout, il est perdu.
Dans WordPress le menu est supporté par du CSS les classes wp-block-navigation…
En Hugo c’est le thème qui le gère, ici avec ananke il faut rajouter des entrées de menu avec menu.main, dans mon cas j’ai rajouté le menu globalement dans le fichier de configuration Hugo, mais il y a plusieurs façons de définir les menus en Hugo.

Un site WordPress c’est un site web comme un autre

Une autre approche est de considérer qu’un site WordPress c’est un site web comme un autre.
Un navigateur n’a pas de code particulier pour visualiser un site WordPress, donc un site WordPress est juste un site web, certes avec beaucoup de JavaScript et CSS, mais un site web.
Et un site web, ça se siphonne, et c’est facile, il suffit de regarder le projet internet archive, par exemple le site de LinuxFr.org le 2 avril 2018 pour s’en convaincre, il est très facile de récupérer le contenu visible d’un site web, à condition de connaître tous les points d’entrée et en pratique il suffit de partir de la page principale.
Puisque vous migrez un site que vous possédez, il n’y a pas de souci à utiliser un aspirateur de site.

Une fois le site récupéré, il y a des convertisseurs Markdown.

En particulier j’ai employé le convertisseur de HTML vers Markdown de Johannes Kaufmann, qui est aussi une base pour d’autres projets de conversion pour des applications particulières dont WordPress.

Et le tour est joué ! Ou presque…

On repart de zéro et on mélange tout

Si aucune des solutions ne fonctionne, chacune permet de créer une partie du site. En utilisant toutes les générations on peut récupérer les meilleurs pages.

Dans mon cas le plugin officiel de migration de jekyll vers hugo a été corrigé et j’ai donc pu l’utiliser.

En utilisant aussi des parties générées depuis le site statique, j’ai obtenu un résultat acceptable, mais cela ne s’est pas fait sans une série de petits scripts en bash à base de find et de sed et donc d’expression régulières, les fameuses regex.

Variations mais pas sur le même thème

Une fois le contenu cohérent, il est temps de tester d’autres thèmes Hugo pour donner au site une apparence différente.
Ces thèmes aussi peuvent être personnalisés. La notion de thème existe déjà dans WordPress, donc vous ne devez pas être surpris, mais les thèmes de WordPress ne peuvent pas être transposés tels quels dans Hugo, par exemple le thème twentytwo désormais classique ne se résout pas en la copie de son continu sur Hugo.
Mais passer à Hugo c’est aussi l’opportunité de se démarquer.

Le 7 avril 2026 est sortie la version 2.8 du logiciel de gestion de la relation client Crème CRM (sous licence AGPL-3.0).

Au programme notamment, de nombreuses améliorations autour des droits, l’épinglage de fiches et des totaux calculés dans les vues en liste. Les nouveautés sont détaillées dans la suite de la dépêche.

Sommaire

• Description du logiciel
• Principales nouveautés de la version 2.8
  • Meilleure synchronisation avec les sorties de Django
  • Améliorations des droits
  • Épinglage de fiche
  • Totaux calculés dans les vues en liste
  • Amélioration des champs personnalisés
  • Quelques autres améliorations notables
• Le futur

Description du logiciel

Crème CRM est un logiciel de gestion de la relation client, généralement appelé CRM (pour Customer Relationship Management). Il dispose évidemment des fonctionnalités basiques d’un tel logiciel :

• un annuaire, dans lequel on enregistre contacts et sociétés : il peut s’agir de clients, bien sûr, mais aussi de partenaires, prospects, fournisseurs, adhérents, etc. ;
• un calendrier pour gérer ses rendez‐vous, appels téléphoniques, conférences, etc. ; chaque utilisateur peut avoir plusieurs calendriers, publics ou privés ;
• les opportunités d’affaires, gérant tout l’historique des ventes ;
• les actions commerciales, avec leurs objectifs à remplir ;
• les documents (fichiers) et les classeurs.

Crème CRM dispose en outre de nombreux modules optionnels le rendant très polyvalent :

• campagnes de courriels ;
• devis, bons de commande, factures et avoirs ;
• tickets, génération des rapports et graphiques…

L’objectif de Crème CRM est de fournir un logiciel libre de gestion de la relation client pouvant convenir à la plupart des besoins, simples ou complexes. À cet effet, il propose quelques concepts puissants qui se combinent entre eux (entités, relations, filtres, vues, propriétés, blocs), et il est très configurable (bien des problèmes pouvant se résoudre par l’interface de configuration) ; la contrepartie est qu’il faudra sûrement passer quelques minutes dans l’interface de configuration graphique pour avoir quelque chose qui vous convienne vraiment (la configuration par défaut ne pouvant être optimale pour tout le monde). De plus, afin de satisfaire les besoins les plus particuliers, son code est conçu pour être facilement étendu, tel un cadriciel (framework).

Du côté de la technique, Crème CRM est codé notamment avec Python/Django et fonctionne avec les bases de données MySQL, SQLite et PostgreSQL.

Principales nouveautés de la version 2.8

Voici les changements les plus notables de cette version :

Meilleure synchronisation avec les sorties de Django

C’est une version plus petite qu’à l’accoutumée (Creme 2.7 est sortie le 2 septembre 2025 et nous sortons une version par an). Cela nous permet de nous caler enfin sur les cycles de sortie de Django (dont les versions LTS—gérée pendant 3 ans—sortent en avril une fois tous les 2 ans) et donc éviter d’avoir des périodes où une version de Crème CRM est encore gérée mais pas la version de Django sous-jacente.

Améliorations des droits

Les utilisateurs peuvent avoir plusieurs rôles. Il arrive que des personnes aient plusieurs casquettes, et finissent par posséder plusieurs utilisateurs, se connectant avec le bon utilisateur en fonction des tâches à effectuer. Mais c’est un peu contraignant de devoir à chaque fois se déconnecter puis se reconnecter (et ça peut aussi être gênant d’avoir plusieurs utilisateurs pour une seule identité). Un utilisateur peut désormais posséder plusieurs rôles, et peut passer de l’un à l’autre sans devoir se déconnecter. Voir ce lien pour plus de détails.

Les rôles peuvent désormais être désactivés. De manière générale, on essaie d’ajouter, au fur et à mesure des versions, la possibilité pour les différents objets que les utilisateurs peuvent supprimer de pouvoir d’abord passer par un état “désactivé”. Cela permet de tester un certain temps si un objet ne manque pas au final ; s’il y a un souci on peut revenir en arrière. C’est donc au tour des rôles d’avoir une telle fonctionnalité.

Les rôles gèrent maintenant les types de fiches qu’on peut lister, et 2 permissions spéciales peuvent être données : administration des utilisateurs & des rôles (il fallait être super-utilisateur pour les administrer dans les versions précédentes).

Épinglage de fiche

Vous pouvez désormais épingler les fiches auxquelles vous accédez souvent, pour aller dans leur vue détaillée.

Vous pouvez accéder aux dernières fiches épinglées dans l’entrée de menu « Accès rapide » ; cette entrée remplace l’entrée qui proposait uniquement les fiches visitées récemment, et propose ces dernières ainsi que les fiches épinglées :

Totaux calculés dans les vues en liste

Certaines colonnes de vue en liste affichent désormais des totaux calculés sur toutes les fiches de cette liste :

• la somme et la moyenne des totaux (avec et sans TVA) des Factures/Devis/Avoirs/Bons de commande.
• la somme et la moyenne des chiffres d’affaires estimé & final des opportunités d’affaire.

Amélioration des champs personnalisés

Les champs personnalisés (les champs de fiches ajoutés par les utilisateurs) peuvent posséder :

– une description ; celle-ci est utilisée notamment dans les formulaires afin de donner plus de détails aux utilisateurs sur le sens dudit champ.
– une valeur par défaut, utilisée à la création de nouvelles fiches ; voir ce lien pour plus de détails.

Quelques autres améliorations notables

• L’éditeur de texte HTML (utilisé pour les corps HTML d’e-mail par exemple) a subi une grosse mise-à-jour (l’interface est bien plus légère et moderne maintenant), et est utilisé à plus d’endroits.
• On peut désormais télécharger plusieurs Documents, Factures ou Devis en une fois sous forme d’archive zip.

Le futur

La prochaine version devrait être la 3.0, et se concentrera sur une grosse revisite de l’interface graphique. À l’année prochaine !

En septembre 2023, nous publiions une dépêche sur HCW@Home, notre logiciel libre de téléconsultation médicale sous licence GPL-3.0. Les retours avaient été nombreux et constructifs, et nous remercions chaleureusement la communauté.

Qu’est-ce que HCW@Home ?

HCW@Home (Healthcare Worker @Home) est un logiciel libre (GPLv3) de téléconsultation médicale, conçu pour permettre aux professionnels de santé de mener des appels vidéo avec leurs patients sans friction : la création d’un compte patient n’est pas nécessaire, un simple lien suffit pour rejoindre une consultation. Les comptes existent mais restent optionnels. Le logiciel intègre une salle d’attente virtuelle, la gestion des rendez-vous, l’échange de documents et de messages, et s’interface avec les systèmes SSO existants via OpenID Connect. Le projet est né d’une collaboration avec les Hôpitaux Universitaires de Genève et a permis des dizaines de milliers de consultations à distance pendant la crise du COVID. Il est aujourd’hui utilisé notamment par des organisations humanitaires comme MSF et le CICR.

Pourquoi une réécriture ?

La critique principale de la communauté était légitime : notre dépendance à MongoDB (licence SSPL, non reconnue comme libre par la FSF ni l’OSI) rendait l’ensemble de la stack discutable d’un point de vue copyleft. Des échanges avaient même eu lieu avec l’équipe de FerretDB, qui s’était manifestée directement sur la dépêche. Malgré leur bonne volonté, la migration n’avait pas été concluante à l’époque. Autre faiblesse pointée : une architecture difficile à maintenir sur le long terme.

Nous avons entendu tout cela.

HCW@Home v6 : réécriture from scratch

Grâce à un financement obtenu ces dernières années, nous avons pu reprendre le projet à zéro. Les changements majeurs :

• Backend : réécriture complète en Python/Django, avec l’interface d’administration native, une API REST et une architecture bien plus maintenable.
• Visioconférence : remplacement de l’ancienne solution par LiveKit (Apache 2.0), serveur WebRTC auto-hébergeable et extensible.
• Fonctionnalités disponibles en option, sans aucune dépendance à un service tiers : enregistrement des réunions, sous-titres en temps réel via Whisper, connectivité SIP.
• Calendrier : intégration CalDAV pour la gestion des rendez-vous.
• Côté praticien : mode Picture-in-Picture pendant les appels, gestion des suivis, possibilité de publier des créneaux de disponibilité que les patients peuvent ensuite réserver directement.
• Coté patient : nouveau tableau de bord permettant aux patients de faire une demande de consultation.

La solution est déployable via Docker Compose, Kubernetes ou paquet Debian, selon les préférences et contraintes de l’hébergeur.

Une convergence involontaire avec La Suite Numérique

En choisissant cette stack, nous avons sans le vouloir rejoint les mêmes choix techniques que La Suite Numérique, l’initiative open source de la DINUM (Direction interministérielle du numérique) visant à fournir aux agents de l’État français une alternative souveraine aux outils Microsoft et Google. Leur outil de visioconférence Meet repose en effet exactement sur la même combinaison Django + LiveKit + PostgreSQL qui est pour nous validation plutôt rassurante.

Le collectif Emmabuntüs annonce deux publications récentes mettant fortement l’accent sur l’accessibilité numérique, fruit d’un travail mené en grande partie avec et par des bénévoles non-voyants et malvoyants, directement impliqués dans la conception, les tests et les améliorations ergonomiques de la distribution.

La version Emmabuntüs Debian Édition 6 1.00, basée sur Debian 13 (Trixie) avec les environnements Xfce et LXQt, introduit de nombreuses améliorations destinées aux personnes malvoyantes ou non-voyantes : interface dédiée à l’accessibilité, synthèse vocale améliorée (espeak, MBROLA, Piper), profils Orca, support d’embosseuses Braille, intégration de LIOS (OCR), ainsi que divers scripts simplifiant la prise en main. Cette version est notamment destinée à des déploiements au Togo, en partenariat avec les associations françaises A.S.I YOVOTOGO, Mutualistes Sans Frontières et la FETAPH (Fédération Togolaise des Associations de Personnes Handicapées).

En parallèle, la version Emmabuntüs Debian Édition 5 1.05, basée sur Debian 12 (Bookworm) et disponible en 32 et 64 bits, bénéficie des mêmes avancées en matière d’accessibilité. Elle permet ainsi de poursuivre le reconditionnement d’ordinateurs plus anciens, tout en offrant une expérience utilisateur inclusive.

Ces deux versions illustrent l’engagement d’Emmabuntüs en faveur de l’inclusion numérique, du logiciel libre, du réemploi de matériel informatique, ainsi que la place centrale offerte à l’expertise d’usage apportée par ses bénévoles concernés par le handicap visuel.

Le projet reste ouvert aux contributions, notamment pour les tests d’accessibilité, la documentation et l’amélioration des outils destinés aux utilisateurs malvoyants ou non-voyants.

Fin mars, nous publierons une nouvelle version d’Emmabuntüs Debian Édition 6 1.01, plus légère et plus modulable, afin de permettre à chacun de choisir les logiciels dont il a réellement besoin. Nous recherchons des bénévoles pour participer aux tests de cette version.

Le 2 septembre 2025 est sortie la version 2.7 du logiciel de gestion de la relation client Crème CRM (sous licence AGPL-3.0), un peu plus d’un an après Creme 2.6 (5 août 2024).

Au programme notamment, le passage à Django 5.2, les types de fiches personnalisés et un système de processus automatisés. Les nouveautés sont détaillées dans la suite de la dépêche.

Sommaire

• Description du logiciel
• Principales nouveautés de la version 2.7
  • Le passage à Django 5.2
  • Les types de fiches personnalisés
  • Les processus automatisés
  • Quelques autres améliorations notables
• Le futur

Description du logiciel

Crème CRM est un logiciel de gestion de la relation client, généralement appelé CRM (pour Customer Relationship Management). Il dispose évidemment des fonctionnalités basiques d’un tel logiciel :

• un annuaire, dans lequel on enregistre contacts et sociétés : il peut s’agir de clients, bien sûr, mais aussi de partenaires, prospects, fournisseurs, adhérents, etc. ;
• un calendrier pour gérer ses rendez‐vous, appels téléphoniques, conférences, etc. ; chaque utilisateur peut avoir plusieurs calendriers, publics ou privés ;
• les opportunités d’affaires, gérant tout l’historique des ventes ;
• les actions commerciales, avec leurs objectifs à remplir ;
• les documents (fichiers) et les classeurs.

Crème CRM dispose en outre de nombreux modules optionnels le rendant très polyvalent :

• campagnes de courriels ;
• devis, bons de commande, factures et avoirs ;
• tickets, génération des rapports et graphiques…

L’objectif de Crème CRM est de fournir un logiciel libre de gestion de la relation client pouvant convenir à la plupart des besoins, simples ou complexes. À cet effet, il propose quelques concepts puissants qui se combinent entre eux (entités, relations, filtres, vues, propriétés, blocs), et il est très configurable (bien des problèmes pouvant se résoudre par l’interface de configuration) ; la contrepartie est qu’il faudra sûrement passer quelques minutes dans l’interface de configuration graphique pour avoir quelque chose qui vous convienne vraiment (la configuration par défaut ne pouvant être optimale pour tout le monde). De plus, afin de satisfaire les besoins les plus particuliers, son code est conçu pour être facilement étendu, tel un cadriciel (framework).

Du côté de la technique, Crème CRM est codé notamment avec Python/Django et fonctionne avec les bases de données MySQL, SQLite et PostgreSQL.

Principales nouveautés de la version 2.7

Voici les changements les plus notables de cette version :

Le passage à Django 5.2

La nouvelle version LTS (Long Time Support, car maintenue pendant 3 ans) du cadriciel Web est sortie en avril 2025.

Pour les personnes qui déploient Creme, cela implique de nouvelles versions minimales :

• La version minimale de Python est maintenant la 3.10
• Pour les systèmes de gestion de base de données (SGBD) les versions minimales sont SQLite 3.31, MySQL 8.0.11, PostgreSQL 14 & MariaDB 10.5.

Python 3.13 est désormais géré officiellement.

Les types de fiches personnalisés

Il a bien sûr toujours été possible de créer ses propres types de fiches (entités) via du code (c’est même plutôt simple, notamment grâce aux outils que fournis Django).
Mais ici il s’agit de créer des types de manière visuelle, via l’interface de configuration. Pour créer un nouveau type il suffit de lui donner un nom (genre “Boutique”), ainsi que son nom au pluriel (donc “Boutiques” dans notre exemple). Ensuite des champs personnalisés peuvent être ajoutés, comme pour n’importe quel type de fiche. Et évidemment vous pouvez utiliser derrière tous les outils de configuration classiques pour construire l’interface qui vous convient (blocs, boutons, formulaires, menu…).

Techniquement, les tables correspondant aux types sont en fait toutes créés dès l’installation (mais seuls les types activés sont visibles) ce qui permet de fonctionner sereinement même sur les SGBD ne gérant pas les transactions de schéma. C’est pourquoi le nombre de types personnalisés est limité (à 20 en l’occurrence, cela devrait être largement suffisant en pratique).

Ce nouveau système était attendu depuis longtemps, et devrait encore un peu abaisser la barrière d’entrée en permettant d’éviter d’écrire du code dans pas mal de cas.

Les processus automatisés

Ce nouveau système permet de programmer des actions qui seront effectuées de manière automatique lorsque certains évènements se produisent. Pour mieux comprendre les possibilités offertes, voici un processus créé lors de l’installation de Creme 2.7 : lorsqu’une fiche Opportunité d’affaire est modifiée et que son nouveau statut est un statut considéré comme gagné, alors la société cible de l’Opportunité devient cliente (si elle ne l’était pas déjà évidemment).

Dans cette première version, les évènements qui peuvent déclencher un processus sont :

• une fiche est créée
• une fiche est modifiée
• une propriété (il s’agit d’une sorte de tag) est ajoutée à une fiche
• une relation est ajoutée entre 2 fiches

Les actions actuellement disponibles sont :

• ajouter une propriété
• ajouter une relation
• envoyer un courriel

Cette version initiale nous a demandé pas mal de travail afin de trouver une conception satisfaisante, mais de nombreuses améliorations sont d’ores et déjà prévues (notamment les évènements temporels & une action qui peut modifier une fiche).

Les processus automatisés étaient, à l’instar des types personnalisés, très attendus ; et combiner ces 2 nouveaux systèmes ouvre pas mal de perspectives.

La version plus détaillée est ici

Quelques autres améliorations notables

• La génération des numéros des Factures/Devis/Bons de commande a été entièrement revue. Elle se configure maintenant depuis l’interface (là où avant on pouvait juste rentrer des préfixes dans le fichier de configuration) et offre de nombreuses options.
• La configuration des boutons peut désormais se faire par rôle (comme c’était déjà le cas avec les blocs, formulaires, etc.).
• Les vues de liste & les filtres peuvent être clonés (afin de gagner du temps, plutôt que de partir de zéro).
• Le calendrier a été mis-à-jour (version 6.1.18 de la bibliothèque JavaScript FullCalendar), et un nouveau bloc permet d’afficher son calendrier sur la page d’accueil.
• Pas mal de code de suppression a été amélioré, que ça soit pour empêcher plus souvent la suppression à cause de dépendances (plutôt que supprimer des choses en cascade), ou pour mieux afficher lesdites dépendances bloquantes.

Le futur

La prochaine version devrait être plus courte que la 2.7 (qui a été un peu plus grosse que prévu à la base), afin de mieux coller aux sorties de Django. À l’année prochaine !

Sportifs du dimanche, on a souvent besoin de gérer des tournois très simples du type « tout le monde rencontre tout le monde » avec quelques contraintes:

• nombre de terrains limité ;
• temps d’attente minimal entre deux matchs ;
• règles variées sur la gestion des scores.

Depuis une vingtaine d’années, je développe différents sites en Python/Django. Du coup j’ai fabriqué un début de site :).

Code

Libriste depuis toujours, le code du projet est sous licence GPL. Actuellement très simple, le site permet de gérer uniquement le mode « toutes les équipes se rencontrent ». Plus tard, suivant les retours, les utilisations et mon temps libre, j’ajouterai d’autres modes (par exemple pour gérer des groupes de placements).

Pour éviter les calculs inutiles, l’affectation des rencontres utilise des grilles de placement. Ces grilles sont calculées une fois pour toutes et contenues dans le projet. L’avantage est d’être efficace et rapide sur la génération de toutes les rencontres. L’inconvénient est que seules quelques combinaisons sont actuellement disponibles :)

Fonctionnement

Le fonctionnement est très simple, le principe de base est que toutes les informations sont visibles sans connexion. Il y a quatre grands rôles utilisateurs:

• administrateur: sert surtout pour créer des comptes utilisateurs ;
• organisateur: peut créer des équipes et réinitialiser un tournoi ;
• arbitre: peut enregistrer/modifier les résultats des matchs ;
• anonyme: accès à la liste des matchs et au classement.

Les règles de classement sont affichées. On peut également définir un message d’accueil. Si on veut sauvegarder les résultats d’un tournoi, il y a un export au format CSV.

Démonstration

Il y a évidemment un site de démonstration du projet. Le lien se trouve ci-dessous. Les ressources nécessaires pour faire tourner le site sont extrêmement limitées. Si les fonctionnalités du site vous conviennent et que vous voulez l’utiliser pour un club/tournois, n’hésitez pas à me contacter. Je pourrais mettre en ligne une version dédiée gratuitement.

Le 5 août 2024 est sortie la version 2.6 du logiciel de gestion de la relation client Crème CRM (sous licence AGPL-3.0), environ 11 mois après Creme 2.5 (11 septembre 2023).

Au programme notamment, un système de notification, des améliorations pour le calendrier ou des filtres réservés aux rapports. Les nouveautés sont détaillées dans la suite de la dépêche.

Sommaire

• Description du logiciel
• Principales nouveautés de la version 2.6
  • Le nouveau système de notification
  • Améliorations du calendrier
  • Filtres spécifiques aux Rapports
  • Quelques autres améliorations notables
• Le futur

Description du logiciel

Crème CRM est un logiciel de gestion de la relation client, généralement appelé CRM (pour Customer Relationship Management). Il dispose évidemment des fonctionnalités basiques d’un tel logiciel :

• un annuaire, dans lequel on enregistre contacts et sociétés : il peut s’agir de clients, bien sûr, mais aussi de partenaires, prospects, fournisseurs, adhérents, etc. ;
• un calendrier pour gérer ses rendez‐vous, appels téléphoniques, conférences, etc. ; chaque utilisateur peut avoir plusieurs calendriers, publics ou privés ;
• les opportunités d’affaires, gérant tout l’historique des ventes ;
• les actions commerciales, avec leurs objectifs à remplir ;
• les documents (fichiers) et les classeurs.

Crème CRM dispose en outre de nombreux modules optionnels le rendant très polyvalent :

• campagnes de courriels ;
• devis, bons de commande, factures et avoirs ;
• tickets, génération des rapports et graphiques…

L’objectif de Crème CRM est de fournir un logiciel libre de gestion de la relation client pouvant convenir à la plupart des besoins, simples ou complexes. À cet effet, il propose quelques concepts puissants qui se combinent entre eux (entités, relations, filtres, vues, propriétés, blocs), et il est très configurable (bien des problèmes pouvant se résoudre par l’interface de configuration) ; la contrepartie est qu’il faudra sûrement passer quelques minutes dans l’interface de configuration graphique pour avoir quelque chose qui vous convienne vraiment (la configuration par défaut ne pouvant être optimale pour tout le monde). De plus, afin de satisfaire les besoins les plus particuliers, son code est conçu pour être facilement étendu, tel un cadriciel (framework).

Du côté de la technique, Crème CRM est codé notamment avec Python/Django et fonctionne avec les bases de données MySQL, SQLite et PostgreSQL.

Principales nouveautés de la version 2.6

Voici les changements les plus notables de cette version :

Le nouveau système de notification

Depuis toujours Crème possède un système de Mémentos (Reminders), qui permet de recevoir des e-mails pour vous prévenir d’une échéance. Ce système est utilisé par les Alertes & les ToDos ; par exemple vous recevez un e-mail lorsqu’une Alerte qui vous est attribuée va expirer dans 30 minutes. Et comme vous pouvez créer des Alertes dont la date d’expiration est un champ date de la fiche associée, cela permet par exemple d’être prévenu qu’une activité importante à laquelle vous participez va bientôt avoir lieu.

Le nouveau système de notification qui a été introduit amène 2 avancées principales :

• les notifications envoyées ne sont pas limitées à des e-mails, vous pouvez aussi les voir dans votre navigateur (donc sans quitter Crème).
• si les mémentos ont été retravaillés pour utiliser ce nouveau système, d’autres parties de Crème en profitent aussi. Par exemple, une notification vous est envoyée si un administrateur a changé votre mot de passe ; ou bien quand un job d’import CSV vient de s’achever.

Chaque notification est associée à un canal, et vous pouvez configurer les canaux pour savoir si la notification est envoyée dans le navigateur, par e-mail ou bien les 2. Si le canal n’est pas obligatoire, vous pouvez aussi choisir de ne pas recevoir les notifications du tout. Chaque utilisateur peut utiliser sa propre configuration si la configuration générale du canal ne lui convient pas.

Améliorations du calendrier

• Le composant JavaScript FullCalendar est passé à la version 5. Même si ce n’est pas la toute dernière version (il faut dire qu’il y a pas mal de changements cassants entre chaque version), on profite de pas mal d’améliorations diverses.
• Il est maintenant possible de configurer graphiquement le calendrier (premier jour de la semaine, plage horaire, jour travaillés…). Il y a une configuration globale utilisée par tout le monde, mais comme presque toujours dans Creme, il est possible de créer des configurations par rôle.

Filtres spécifiques aux Rapports

Les Rapports utilisent généralement un filtre, afin d’affiner leurs résultats. Ces filtres sont les mêmes que ceux qu’utilisent les vues en liste ; par exemple si vous faites un Rapport sur les Devis, il peut utiliser les filtres disponibles sur la liste des Devis.

Un problème que cela entraîne est que beaucoup d’utilisateurs créent des filtres un peu spécifiques afin de les utiliser dans leurs Rapports, mais ces filtres viennent « polluer » la vue en liste correspondante (car la sélection de filtres proposent de nombreux filtres non pertinents). Afin de corriger ce souci, il est désormais possible de créer des filtres utilisables uniquement dans les Rapports. Les Rapports peuvent bien sûr continuer à utiliser les filtres classiques, mais les filtres spécifiques aux Rapports ne sont pas utilisables dans les vues en liste évidemment.

Quelques autres améliorations notables

• Python 3.12 est officiellement géré.
• Dans le module facturation, vous pouvez maintenant configurer les statuts sélectionnés par défaut (dans les formulaires), ainsi que les statuts utilisés par les Factures lorsque leur numéro est généré.
• Un nouveau bouton, qui peut être mis sur la vue détaillée des Contacts, est disponible: « Créer un appel non abouti » (détails).
• La configuration des blocs d’un rôle peut maintenant être créée en clonant la configuration d’un autre rôle (les rôles pouvant avoir des configurations assez proches, ça peut être un gain de temps appréciable).
• Les blocs basés sur OpenStreetMap sont maintenant utilisés dans l’installation par défaut (à place de ceux basés sur GoogleMaps).
• Un rôle «Utilisateur normal» est créé dans les nouvelles installations. Dans la mesure où c’est une bonne chose que tout le monde ne soit pas connecté en tant que super-utilisateur, ce rôle devrait permettre de gagner du temps et servir au moins de base de travail.
• Un bouton permettant de transformer un simple Contact en utilisateur a été ajouté. Auparavant il fallait fusionner ce Contact avec le Contact automatiquement créé à la création d’un utilisateur.
• Les Graphes ont reçu de nombreuses améliorations : plus de champs sont disponibles en abscisse, plus de champs sont disponibles pour le filtrage, les couleurs associées aux petits modèles auxiliaires (du genre « Statut ») sont utilisées…
• La validation des URLs est désormais moins stricte dans les champs informatifs. Cela posait pas mal de problèmes notamment lors des imports, les gens mettant rarement le « http:// » dans leur base de données.

Le futur

La prochaine version marquera notamment le passage à Django 5.2, la future LTS qui sortira en avril 2025. À l’année prochaine !

Ce 29 juillet 2024, le collectif Emmabuntüs vient d’annoncer la sortie de sa nouvelle version Emmabuntüs Debian Édition 5 1.02, basée sur la Debian 12.6 Bookworm (32 et 64 bits) et supportant les deux environnements de bureau Xfce et LXQt.

Rappelons que cette distribution est née au sein d’Emmaüs, pour faciliter le reconditionnement des ordinateurs donnés aux associations, notamment humanitaires, mais aussi pour favoriser la découverte de GNU/Linux par les débutants, tout en prolongeant la durée de vie du matériel informatique, ce qui réduit le gaspillage lié à la surconsommation de matière première.

Cette nouvelle version fait suite à une demande de l’A.S.I. YOVOTOGO, afin de donner 90 ordinateurs embarquant cette évolution à la « Fédération togolaise des associations de personnes handicapées » (FETAPH) pour équiper leurs 11 centres de formation.
Pour inclure cette évolution, sans perturber ses anciens utilisateurs, une fenêtre d’activation et de configuration de ces fonctions d’accessibilité a été ajoutée :
Fenêtre de configuration de l’accessibilité personnalisée

Les principales fonctions d’accessibilité ajoutées dans cette évolution sont :

• le lecteur d’écran Orca associé à la synthèse vocale Svox Pico pour aider les non-voyants,
• le gestionnaire de fenêtre Compiz avec son module d’accessibilité (zoom plein écran, changement de la luminosité de l’écran, etc) pour aider les mal-voyants,
• MouseTweaks et l’émulation de la souris avec le pavé numérique pour les personnes ayant des handicaps physiques,
• eBook-speaker pour la lecture audio des livres numériques au format ePub,
• Daisy-player pour la lecture des livres audio au format Daisy,
• Kiwix en mode accessibilité pour la lecture de Wikipédia hors-ligne,
• Ocrizer pour scanner un document en mode OCR, puis l’ouvrir dans LibreOffice,
• Elograf pour la dictée vocale,
• Tux Typing version vocale pour l’apprentissage du clavier de Zendalona,
• NatBraille logiciel pour générer des livres en Braille,
• Gnome-calculator calculatrice en mode accessibilité.

Menu des applications d’accessibilité

Le collectif a aussi réalisé pour cette évolution un ensemble de manuels pour l’accessibilité ainsi que la mise en place d’une page dédiée sur son site regroupant ces manuels en français et en anglais.