Puisqu'il n'est jamais trop tard pour écrire sur DLFP, voici donc une note de journal concernant Modoboa une application écrite en python qui, près de 11 ans après la dernière dépêche à son sujet concernant la version 1.2.0 (nous sommes en version 2.6.5, la version 2.7.0 pointe le bout de son nez) continue de toujours être une solution adaptée pour avoir rapidement un serveur de messagerie fonctionnel et bien doté.
Le logiciel est toujours développé par @anguyen et je l'en remercie.
Rappel des fonctionnalités offertes
Une interface d'administration
Celle-ci vous permet de gérer les comptes voire de déléguer la gestion d'un domaine, définir des quotas par domaine ou compte, de définir des relais et d'autres choses.
Il est à noter que l'interface a visuellement bien changé depuis la version 1.2.0.
Cette interface permet une multitude de réglages et notamment pour celles et ceux qui le souhaitent, d'intégrer rspamd ou amavis, de signer ses messages sortants avec dkim, de valider les enregistrements DNS d'un domaine, de s'interfacer avec un annuaire LDAP, etc.
Un webmail
Pratique pour lire ses messages et y répondre si l'envie nous en prend.
Des filtres sieve
Établir des règles sieve pour son tri automatique des messages est clairement le must-have pour s'épargner une tâche rébarbative.
Une gestion des calendriers
Le logiciel propose via radicale et un petit module à installer via pip une gestion des calendriers
Un gestion des carnets d'adresse
C'est toujours mieux de pouvoir enregistrer ses contacts n'est-ce pas ?
Un répondeur automatique
Le meilleur outil pour annoncer ses vacances à la Terre entière (ou pas).
Quels changements depuis 11 ans ?
Plein de choses, je vais donc les citer pêle-mêle:
l'ajout d'un service de notification pour prévenir de l'arrivée d'une nouvelle version
une modularisation de Modoboa puis le retour à un fonctionnement quasiment monolithique
l'implémentation d'un contrôle de la robustesse des mots de passe
l'implémentation d'une API REST
la vérification des enregistrements DNS pour un domaine
la fin du support de python 2.x
un démon policy et le support de Redis (Valkey sans doute prochainement)
le support de TOTP (oui !)
une nouvelle interface telle que montrée plus haut
la possibilité de créer et gérer ses clefs DKIM dans Modoboa
la fin programmée des cronjobs (RQ se chargera de tout cela prochainement)
OAUTH2 est supporté (très bien pour intégrer des applications externes)
un service d'auto-configuration pour permettre aux clients lourds de savoir comment se connecter au serveur mail
Pourquoi continuer à utiliser modoboa face à l'alternative X, Y ou Z ?
Voici une question qui se pose et à laquelle j'ai quelques éléments de réponse. Étant utilisateur depuis plus de 12 ans et ayant même testé la version 0.9.0 sans être convaincu à l'époque, j'ai pu voir le logiciel évoluer avec toujours la possibilité de garder le contrôle de son installation car Modoboa s'installe avec soit un script fourni par les développeurs soit manuellement et à l'heure où certains développeurs ne jurent plus que par docker (pour ne pas le citer), c'est toujours appréciable car cela permet aux personnes comme moi de tuner leur installation plus facilement même si cela implique de bien conserver la trace de ce que l'on fait. En outre, je trouve le logiciel bien pensé et rationnel dans son approche, les fonctionnalités proposées sont souvent celles les plus utiles pour les utilisateurs.
J'ai pu migrer de la version 1.2.0 à la version 2.6.5 avec assez peu de problèmes et c'est fort appréciable de ne pas devoir repartir de zéro.
On organise à Grenoble mardi 27 janvier 2026 un Meetup Python avec un quiz sur les nouveautés et les avancées marquantes de l’année 2025. On aura aussi des questions sur le documentaire sur Python sorti en août 2025 : https://www.youtube.com/watch?v=GfH4QL4VqJ0
Je commence l'année par une petite contribution open-source pour les documentations de projets python: sphinxcontrib-run.
TLDR; une directive qui permet d'exécuter du code à la volée pendant la génération d'une doc.
Cette extension au générateur de documentation sphinx concerne la partie des documentations d'API générées automatiquement à partir des commentaires dans le code source, les "docstrings". Les docstrings sont rédigées au format reStructuredText qui est un peu plus évolué que markdown et permet d'appeler des directives avec des arguments pour désigner un bloc de code, une référence, un argument de fonctions, etc.
L'extension sphinxcontrib-run ajoute une nouvelle directive .. run:: qui prend un morceau de code python en argument et l'exécute immédiatement pendant la construction de la documentation. Plus précisément, un interpréteur python est démarré pour chaque page de documentation traitée par sphinx et, à chaque fois que sphinx insère dans la page un nœud correspondant à la directive .. run::, le code est exécuté dans cet interpréteur.
Au passage, ce que le code écrit sur la sortie standard est inséré dans la documentation.
Voici un exemple pour un module python jouet:
""".. run:: from example import square_text_50 lorem = ( "Lorem ipsum dolor sit amet, consectetur adipiscing elit." + " Pellentesque faucibus vestibulum est id consequat." + " Cras sed enim sed ex maximus blandit." )"""defsquare_text_50(text):"""Wrap text to 40 columns. .. run:: print("::") print("") for line in square_text_50(lorem): print(" " + line) print("") """foriinrange(0,len(text),50):yieldtext[i:i+50]
Si l'on utilise automodule, sphinx va traiter toutes les docstrings à la suite dans la même page, et donc sphinxcontrib-run exécutera les morceaux de code dans le même interpréteur.
La première directive .. run:: fait les imports et instancie une variable globale qui pourra servir plusieurs fois.
La seconde directive intervient dans la documentation de la fonction, elle génère dynamiquement la sortie de la fonction pour faire un exemple.
Dans la documentation, le résultat ressemble à ceci:
Je vais personnellement utiliser ce projet pour générer automatiquement des figures à insérer dans la doc d'un autre projet, ça m'évitera de les ajouter au dépôt git et d'avoir à les tenir à jour.
Au passage, je note que l'API sphinx pour ajouter des directives est très bien faite et bien documentée.
Enfin, il faut aussi mentionner un projet similaire au mien: https://github.com/sphinx-contrib/eval
Un aide-mémoire contenant des chiffres réels de timing et de consommation mémoire pour guider les décisions critiques en matière de performance en Python. Cette ressource fournit aux développeur·se·s les métriques essentielles pour optimiser leurs applications Python de manière éclairée.
La version 7.8 de Tryton est sortie mi‑décembre 2025 et s’inscrit dans la continuité des branches précédentes, avec une mise à jour axée sur la stabilité, les performances et une série de raffinements fonctionnels dans tous les domaines de gestion. Elle apporte de nombreuses corrections de bogues, améliore la réactivité du serveur et peaufine à la fois l’interface utilisateur, les modules métiers et les outils destinés aux administrateurs et développeurs.
Support PEPPOL
Suite à l'obligation pour 2026 en Belgique d’envoyer les factures entre sociétés belges au format électronique via le réseau PEPPOL, la version 7.8 inclut à temps les modules nécessaires dont un module de connexion au point d’accès gratuit Peppyrus.
Quand ces modules sont activés, Tryton envoie automatiquement à partir de 2026 sur le réseau PEPPOL les factures si le client a un numéro de TVA belge (ainsi que la société gérée). Il est aussi possible de forcer l’envoi pour certains clients.
Les modules sont conçus pour être étendu à d’autres points d’accès futures afin de diversifier l’offre.
Interface et usage quotidien
Cette version introduit un système de notifications plus moderne : un menu dédié regroupe les messages, un compteur signale les notifications non lues et des pop‑ups informent l’utilisateur des nouveaux événements sans quitter son écran. Les vues en liste sont plus agréables, avec des boutons d’action visibles en pied de page et des recherches simplifiées, par exemple pour trouver les documents sans entrepôt défini, ce qui rend la navigation au quotidien plus fluide.
Le chat intégré, apparu dans la version précédente comme fonctionnalité émergente, est désormais activée de base sur les documents clés (ventes, achats, factures…) pour centraliser les échanges directement dans le logiciel. Les utilisateurs peuvent s’abonner à un document via une icône de cloche et recevoir des notifications ciblées, renforçant le suivi collaboratif sans dépendre d’outils externes.
Modules métiers
Sur le plan fonctionnel, la version 7.8 enrichit l’écosystème de modules : gestion des formats de factures électroniques UBL et PEPPOL, gestion de contrats de location (avec facturation progressive), support des agents et de documents (facture commerciale) de douane, ainsi que définition plus fine des points d’expédition logistiques par entrepôt.
L’intégration e‑commerce, notamment avec Shopify.com, est nettement améliorée avec la prise en charge des remboursements, des taxes sur les frais de port, des produits de type kit, un choix plus intelligent du transporteur et la synchronisation de la langue du client et des liens d’administration entre boutiques en ligne et Tryton.
Le moteur d’approvisionnement a été ajusté pour mieux gérer les contraintes de délais : si aucun fournisseur ne peut livrer dans le délai idéal, le système choisit automatiquement celui qui offre le délai le plus court, limitant les ruptures tout en restant réaliste. De nouveaux rapports sur la quantité de stock et la rotation de stock permettent de suivre plus précisément les niveaux et mouvements, et de prendre de meilleures décisions sur les points de commande et les réassorts.
Les modules de comptabilités supportent maintenant les références de paiement sur les factures et les relevés de compte. Pour l’instance les formats « Creditor Reference » et « Communication structurée » belge sont supportées en standard.
Administration et développement
Côté serveur, Tryton 7.8 réduit la consommation mémoire en envoyant les réponses JSON comme flux et en ne chargeant plus que les modules activés, ce qui profite aux installations avec peu de modules activés (on a mesuré des réductions de la consommation mémoire entre 10% et 20%). Les administrateurs disposent d’un mode console: trytond-console capable d’exécuter maintenant des scripts depuis un fichier et d’un paramètre de rotation des logs basé sur la taille plutôt que sur l’âge, tandis que les développeurs bénéficient du nouveau système de notifications côté serveur, d’optimisations SQL avec l’usage de FILTER et EXISTS et de la possibilité de matérialiser les modèles basés sur une requête SQL (au lieu d’une table).
En septembre, j’ai changé de poste, et me voilà à manger du Python toute la journée. Je décrirai dans cet article mon expérience avec le langage.
Background
J’ai appris à programmer comme beaucoup en lisant des tutoriels sur internet il y a presque 20 ans, avec HTML/PHP et C.
Pendant mes études, j’ai eu l’occasion de toucher à plein de langages: Java, C, PHP (que j’aimais beaucoup car je pouvais facilement faire un site web sympa en codant comme un cochon), Ocaml, ou des choses un peu plus obscures comme VHDL (c’était ultra fun et intéressant) et Cobol.
Durant ma carrière, j’ai alterné entre des rôles de dev/lead dev et de SRE (où je codais toujours énormément: infrastructure API-first, self-service, platform engineering, tooling…). J’ai notamment travaillé 6 ans avec Golang, 4 ans avec Clojure, j’ai été payé pour faire du Java et du Typescript, et je continue d’explorer d’autres langages sur mon temps libre. Bien sûr, nous sommes entre personnes civilisées, donc je ne mentionnerai pas shell/bash ici.
Comme tout bon sysadmin/SRE qui se respecte, j’ai fait du Python, mais à l’arrache. D’ailleurs, le second article de ce blog (2016!) explique comment développer un plugin Ansible (donc en Python) pour générer des logs structurés de l’outil et en dériver des métriques.
J’avais aussi de temps en temps l’occasion de contribuer à des codebases Python, et je n’aimais pas ça, notamment à cause de la gestion des dépendances qui était en dessous de tout.
En septembre 2025, après 3 ans et demi à bosser comme SRE, j’ai décidé de revenir sur un rôle plus proche du produit et du développement, toujours au même endroit mais dans une nouvelle équipe. Vu que c’est un rôle avec également une grosse composante AI, on est parti sur Python.
Quatre mois plus tard et avec un premier produit en prod, j’ai envie de faire un REX sur Python vu que j’ai énormément appris sur le langage pendant cette période.
