Project documentation: pdfly.readthedocs.io

pdfly is the youngest project of the py-pdf organization. It has been created by Martin Thoma in 2022.

It's simply a CLI tool to manipulate PDF files, written in Python and based on the fpdf2 & pypdf libraries.

I'm a maintainer of the project 🙂

What can it do & what's next?

Find out by reading the full article

Une bibliothèque Python avec les principes et objectifs suivants :

• Permettre la reproduction aussi simple que possible des recherches précédentes sur le dilemme du prisonnier itératif.
• Créer l'outil de facto pour les futures recherches sur le dilemme du prisonnier itératif.
• Fournir un moyen aussi simple que possible pour que tout le monde puisse définir et contribuer à de nouvelles stratégies originales pour le dilemme du prisonnier itératif.
  -Mettre l'accent sur la lisibilité ainsi que sur une communauté ouverte et accueillante qui s'adapte aux développeurs et aux chercheurs de différents niveaux de compétence.

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 !

255e émission « Libre à vous ! » de l’April. Podcast et programme :

• sujet principal : le langage de programmation Python
• La chronique Le truc que (presque) personne n'a vraiment compris mais qui nous concerne toutes et tous de Benjamin Bellamy sur les VPNs
• Une nouvelle Lecture buissonnière de Vincent Calame sur l'ouvrage d'Éric Sadin, « La vie algorithmique »
• Quoi de Libre ? Actualités et annonces concernant l'April et le monde du Libre

Rendez‐vous en direct chaque mardi de 15 h 30 à 17 h sur 93,1 FM en Île‐de‐France. L’émission est diffusée simultanément sur le site Web de la radio Cause Commune.

Je ne connais que très peu Python et je découvre que le système de typage introduit en 2014 est très similaire à celui de TypeScript.

Je ne connais que très peu Python et je découvre que le système de typage introduit en 2014 est très similaire à celui de TypeScript.

pip install git+https://github.com/superstarryeyes/lue.git

Et voilà, vous êtes prêts à transformer votre terminal en studio d’enregistrement de livres audio. Pour lancer la lecture d’un bouquin, c’est aussi simple que :

lue votre-livre.epub

lue --voice "fr-CH-ArianeNeural" livre.epub

La PyConFR 2025 a lieu du jeudi 30 octobre au dimanche 2 novembre au Campus René Cassin à Lyon. Le planning est en ligne et les inscriptions sont ouvertes !

Comme toujours, l’évènement est gratuit et l’inscription est obligatoire.

Les deux premiers jours de la conférence seront occupés par les sprints. Et les deux jours suivants seront dédiés aux conférences (longues et courtes) et ateliers.

Trois keynotes sont au programme :

• Embracing Weird Code, d’Ivana Kellyer
• Le rêve de tout enfant - devenir DBA ?, de Karen Jex
• Être un·e allié·e du numérique pour tou·te·s en environnement hostile, de Morgane Rozenn Hauguel

Un atelier de programmation pour les enfants (à partir d’environ 7 ans) a lieu le samedi après-midi.

Un espace enfants (de 3 ans à 12 ans) est aussi mis à disposition le samedi et dimanche gratuitement et sur inscription.

Un déjeuner PyLadies a également lieu durant la conférence. Un des objectifs est de tisser des liens entre la communauté PyLadies et le reste de la communauté Python francophone.

En plus du traditionnel repas du samedi soir, des visites guidées de Lyon sont aussi possibles les jeudi et vendredi soir, toujours sur inscription.

Enfin, le dimanche matin, l’AFPy tient son assemblée générale. Si vous souhaitez y voter, assurez-vous d’être à jour de cotisation.

Crée ton propre assistant vocal Jarvis en Python ! Suis notre tutoriel débutant pour intégrer IA locale (Ollama), reconnaissance et synthèse vocale. Apprends à coder ton IA !

Il y a exactement deux mois, un incident était survenu suite à un redémarrage brutal du serveur hébergeant les conteneurs de production et de développement ayant entraîné une attribution inattendue d’adresses IP. Et des réponses techniques 502 Bad Gateway pour notre lectorat.

Ce 26 août, vers 15:22, un message peu engageant est arrivé par pneumatique sur nos téléscripteurs (via Signal pour être précis) : « Tiens c’est bizarre j’ai perdu accès au site. Et au serveur oups. » L’après-midi et la soirée furent longues.

Sommaire

• • Premier diagnostic
  • Eh bien des requêtes habituelles…
  • La boucle sans fin
  • Une dernière page d’epub ?
  • Retour en graphiques sur la journée
  • Mesures préventives et correctives
  • Bonus inattendu pour l’incident précédent du 26 juin 2025

Premier diagnostic

Le serveur répond au ping et permet les connexions TCP port 22, mais pas le SSH. Et les services web ne répondent plus. Souci matériel ? Noyau en vrac ? Attaque en cours ? Les spéculations vont bon train.

La connexion au serveur revient par intermittence, permettant à un moment d’exécuter quelques commandes, à d’autres d’attendre longuement pour l’affichage d’un caractère ou l’exécution de la commande tapée.

Le premier contact réétabli avec le serveur est assez clair (une forte charge) :

$ uptime
15:06:59 up 2 days,  2:54,  1 user,  load average: 50,00, 205,21, 260,83

(dernier redémarrage le week-end précédent, mais surtout une charge système moyenne respectivement de 50, 205 et 261 sur les 1, 5 et 15 dernières minutes)

Initialement on suppose qu’il s’agit d’un trop grand nombre de requêtes ou de certaines requêtes tentant des injections de code sur le site (bref le trafic de fond plutôt habituel et permanent), et on ajoute des règles de filtrage péniblement et lentement pour bloquer les IP qui ressortent le plus dans nos logs.

Le site est alors inaccessible pendant plusieurs périodes. On arrête et relance ensuite plusieurs fois les services en pensant avoir ajouté suffisamment de filtrage, mais rapidement le serveur se retrouve englué. Les services sont alors arrêtés plus longuement le temps d’analyser les logs au calme. Au calme inclut notamment ne pas juste disposer d’une connexion ssh depuis un smartphone, mais plutôt d’un clavier et d’un grand écran par exemple, de l’accès à tous les secrets et toute la documentation aussi.

Finalement le trafic n’est pas énorme (en volume total) et si les requêtes hostiles sont bien présentes, rien ne semble inhabituel. Par contre les processus de coloration syntaxique partent en vrille, consommant chacun un processeur et aspirant allègrement la mémoire disponible. Avant d’être éliminés par le noyau Linux.

La console est remplie d’élimination de processus de ce type :

Mais si rien n’a changé niveau logiciel sur le conteneur LXC de production et si les requêtes ne sont pas inhabituelles, qu’est-ce qui peut bien écrouler le serveur et créer ces processus gourmands ?

Eh bien des requêtes habituelles…

Pendant les phases d’attente lorsque le serveur ne répondait plus vraiment, nous avons noté qu'une nouvelle entrée de suivi a été créée (merci BAud et merci RSS/Atom pour nous avoir permis de la voir alors que le serveur ne répondait déjà plus). Elle indique que la coloration syntaxique ne marche plus sur le site. Notamment l’exemple donné dans la documentation.

Pourtant le rendu fonctionne en testant en ligne de commande avec pygmentize.

Mais oui en testant l’exemple donné via le site, il est créé un processus Python2 pygment qui commence à se gaver de ressources.

Et en regardant les différents contenus et commentaires créés sur le site autour de l’incident, en filtrant sur ceux contenant des blocs avec de la coloration syntaxique, la dépêche (alors en préparation) sur G'MIC 3.6 apparaît. Et en testant cette dépêche, il est bien créé quatre processus Python2 pygment qui se gavent de ressources et ne semblent jamais vouloir se terminer. À rapprocher par exemple d’une page qui a été servie en 6785.9978s.

OK, le souci vient de requêtes tout à fait habituelles de coloration syntaxique, reste à comprendre pourquoi ces processus tournent mal.

La boucle sans fin

Un petit strace pour suivre les appels système en cours sur un des processus infernaux relève une boucle assez violente :

(...)
close(623199355)                        = -1 EBADF (Bad file descriptor)
close(623199356)                        = -1 EBADF (Bad file descriptor)
close(623199357)                        = -1 EBADF (Bad file descriptor)
(...)

Il semble y avoir une immense itération sur des descripteurs de fichiers, en vue de les fermer, mais à l’aveugle, sans savoir s’ils existent réellement.

En regardant le code du composant utilisé (pygments), il semble n'y avoir qu'un seul appel à close() :

# close fd's inherited from the ruby parent
        import resource
        maxfd = resource.getrlimit(resource.RLIMIT_NOFILE)[1]
        if maxfd == resource.RLIM_INFINITY:
            maxfd = 65536

        for fd in range(3, maxfd):
            try:
                os.close(fd)
            except:
                pass

Donc on itère sur tous les descripteurs entre 3 et le maximum déterminé…

>>> import resource
>>> print(resource.getrlimit(resource.RLIMIT_NOFILE)[1])
524288
>>> print(resource.RLIM_INFINITY)
-1

Un demi-million de fois ici donc. L’objectif initial de la boucle est de fermer les descripteurs de fichiers provenant du processus Ruby père, issue du fork via Open3.popen3. La version suivante du composant la remplace d’ailleurs par un ajout de l'option :close_others, qui précisément « modifie l’héritage [des descripteurs de fichiers du processus parent] en fermant les non-standards (numéros 3 et plus grands) ».

Sur une Debian 12, la limite du nombre de fichiers par défaut, c’est 1 048 576. C’est déjà probablement bien plus que la valeur qui prévalait à l’époque où a été écrit la boucle Python (on avait des limitations à 4096 à une époque reculée). Mais il s’avère que durant le week-end l’hôte du conteneur de production a été migré en Debian 13. Sans modification du conteneur de production pensions-nous. Sans modification directe du conteneur de production. Mais quid d’une modification indirecte ? Par exemple si la limite par défaut des « Max open files » était passée à 1 073 741 816 sur l’hôte, soit 1024 fois plus que quelques jours auparavant. Et donc des boucles nettement plus longues voire sans fin, sans libération de mémoire.

On ne peut mettre à jour le composant pygments dans l’immédiat, mais on peut limiter les dégâts en abaissant la limite du nombre de descripteurs de fichiers à quelque chose de raisonnable (i.e. on va gaspiller raisonnablement des cycles CPU dans une boucle un peu inutile mais brève…). Une édition de /etc/security/limits.conf, un redémarrage du conteneur de production et on peut vérifier que cela va nettement mieux avec cette réparation de fortune.

Une dernière page d’epub ?

Le conteneur LXC portant le service epub de production a assez mal pris la surcharge du serveur, et vers 20h08, systemd-networkd sifflera la fin de la récré avec un eth0: The interface entered the failed state frequently, refusing to reconfigure it automatically (quelque chose comme « ça n’arrête pas d’échouer, débrouillez-vous sans moi »). Le service epub est resté en carafe jusqu’au 27 août vers 13h31 (merci pour l’entrée de suivi).

Voir ce commentaire sur la dépêche de l’incident précédent expliquant la séparation du service epub et du conteneur principal de production (en bref : dette technique et migration en cours).

Retour en graphiques sur la journée

Le serveur était très occupé. Au point de n’avoir pas le temps de mettre à jour les graphiques de temps en temps.

Rétrospectivement les processeurs du serveur ont travaillé dur : 140 de charge sur le graphique (mais avec des pics jusque 260 d’après la commande uptime), contre moins de 5 en temps normal (un petit facteur de 28 à 52   ô_Ô)

Et l’utilisation de la mémoire montre aussi de brutaux changements de comportement : libération intempestive de mémoire (Free, en vert), utilisation mémoire plus importante que d’habitude (Used, en jaune), là où le comportement normal est d’avoir le maximum en cache (Cached, en orange) et des processus tellement peu consommateurs en RAM que cela n’apparaît normalement pas.

Mesures préventives et correctives

Dans les actions en cours ou à prévoir :

• mettre à jour la documentation pour disposer facilement et rapidement des informations pour les connexions aux cartes d’administration ou les procédures de blocages d’IP
• procéder à la montée de version des composants (yapuka, épineux sujet de la dette technique à éponger)
• vérifier l’efficacité des limitations CPU/mémoire mises sur certains conteneurs LXC et les étendre aux autres
• mettre des limites sur des processus particuliers (comme ceux de pygments)
• ajouter le déploiement des limites par utilisateur dans le code Ansible
• corriger la collecte rrd des métriques concernant les interfaces réseau
• remonter les alertes OOM qui ne sont pas normales
• comprendre la surconsommation mémoire ? (les boucles actives expliquent la consommation processeur, mais pour la mémoire ?)

Bonus inattendu pour l’incident précédent du 26 juin 2025

De façon cocasse, ce nouvel incident et le temps passé à parcourir les différents logs ont permis de retrouver les infos de la carte d’administration distante et d’expliciter l’origine du redémarrage serveur intempestif. À quelque chose malheur est bon, si on peut dire. Ceci n’est pas une invitation pour un prochain incident.

Créer / Utiliser python3 avec venv, afin de ne pas pourrir votre système par l'ajout de packages pip

# Création des répertoires et scripts
python3 -m venv ./project
# Activation pour votre shell
. ./project/bin/activate
# Désactivation pour votre shell
deactivate

Vous pouvez désormais utiliser pip, les packages seront localisés dans votre projet.

Utiliser requirements.txt pour faciliter l'instalation des packages

# Setup du fichier normalisé requirements.txt
pip freeze > requirements.txt
# Installation des packets
pip install -r requirements.txt

Note: Sous debian, il vous faudra le packet python3-venv

Il existe d'autres outils similaires pyenv et pyenv:

# Avec virtualenv:
python3 -m virtualenv ./venv
. ./venvbin/activate
deactivate

# Avec pyenv
# Il s'agit d'une gestion plus avancée vous permettant de basculer entre versions de python
# Voir https://github.com/pyenv/pyenv?tab=readme-ov-file

La conférence ConFoo est de retour pour sa 24 e édition, du 25 au 27 février 2026 à l’Hôtel Bonaventure de Montréal! Que vous soyez un développeur junior ou un CTO, venez découvrir pourquoi ConFoo est devenu l’un des événements phares pour les professionnels en hautes technologies.

Nous sommes présentement à la recherche d’experts d’expérience souhaitant joindre notre équipe de conférenciers pour l’édition 2026! De PHP à JavaScript, en passant par tous les enjeux liés à la sécurité et au développement de l’IA, ConFoo couvre chaque année l’ensemble des sujets qui font bouger l’industrie.

Offertes en français ou en anglais, nos présentations sont généralement d’un format de 45 minutes, incluant un 10 minutes de questions des participants. Nos conférenciers invités profitent aussi d’un traitement privilégié; comprenant la couverture de leurs frais de déplacement et d’hébergement, en plus de l’accès à l’expérience complète de l’événement (présentations, repas, etc.).

Vous avez jusqu’au 21 septembre prochain pour soumettre votre projet de présentation!

Vous cherchez simplement à vous inscrire? Profitez dès maintenant d’un rabais de 300$ en réservant votre place d’ici le 17 octobre!

Faites partie de l’aventure avec nous et découvrez comment l’intelligence humaine est en train de façonner le milieu des hautes technologies!