Il y a 15 ans j’écrivais un article faisant le résumé de ma première année d’activité en tant que développeur de logiciel libre. J’ai ensuite fait des bilans réguliers durant les 9 ans qui ont suivi où j’y ai discuté de sujets divers et variés tels que les premiers pas, la contribution, les échecs, etc.

Je pensais avoir conclu ce cycle mais plus tard, après avoir vécu de nouvelles aventures comme voir le projet Kitsu prendre son essor, collaborer avec le projet Blender, ou devenir parent, je me suis dit que je pouvais encore partager des choses. Voici donc mon retour d’expérience de ces cinq dernières années à temps plein sur Kitsu !

Sommaire

• État du projet Kitsu
• La rencontre avec Blender
• Logiciel libre et parentalité
• La pression de l’offre gratuite
• Standardisation
• Le premier Kitsu Summit
• Le code à l’heure de l’IA générative
• IA et données personnelles
• Conclusion
• Questions-réponses tirées du journal

Il y a 15 ans j’écrivais un article faisant le résumé de ma première année d’activité en tant que développeur de logiciel libre. J’ai ensuite fait des bilans réguliers durant les 9 ans qui ont suivi. J’ai discuté de sujets divers et variés tels que les premiers pas, la contribution, les échecs, etc. Enfin, j’avais conclu ces 10 années sur la satisfaction que j’avais tirée de toutes ces réalisations. Je pensais avoir fait le tour mais après 5 nouvelles années, j’ai eu le sentiment d’avoir encore des choses à partager.

Durant cette période, ma contribution a été faite exclusivement sur mon projet Kitsu (licence AGPL) porté par mon entreprise CGWire. Kitsu est un logiciel de gestion de projets pour les studios d’animation et de VFX basé sur Javascript (Vue.js), Python (Flask) et Postgres. C’est une brique importante de leur système d’information. Autour de ce logiciel, nous fournissons des services d’hébergement et de support. Ce qui me permet d’en vivre à temps plein depuis maintenant bientôt 10 ans.

Pour ce bilan, après un récapitulatif sur l’état d’avancement de Kitsu, je vais aborder différents thèmes : la collaboration avec un projet à très grand succès, être parent et développeur, l’organisation de notre premier événement dédié à notre solution, trouver un modèle d’affaires viable, faire du logiciel libre à l’heure de l’IA générative, et enfin je sortirai du champ Kitsu avec des réflexions autour des données personnelles et des LLM.

Bilans précédents : 1, 2, 3, 4, 5, 6, 8, 9

État du projet Kitsu

Aujourd’hui, Kitsu est reconnu comme une solution solide par tout le secteur de l’animation. Nous équipons environ 500 studios de 1 à 1000 personnes (la majorité d’entre eux est composée de 20 à 50 personnes) dans plus de 30 pays dans le monde.

Les films et séries utilisant Kitsu sont principalement des productions indépendantes. Nombre d’entre eux ont reçu des prix prestigieux avec notamment des succès récurrents au Festival d’Annecy (la référence en animation 2D) mais aussi à Cannes, aux Césars ou aux Oscars. Le film qui a reçu le plus de récompenses est Flow (pour le coup en 3D !).

C’est un résultat assez réjouissant. Toutefois, nous ne sommes jamais sortis de cette sphère indé, les gros studios ont toujours boudé notre solution, préférant le standard américain géré par Autodesk. Nous sommes donc restés sur des performances financières très modestes comparées à celles des start-ups classiques (500 k€/an de CA). Ce résultat est toutefois à mitiger, car le secteur subit une forte crise depuis 2023, y survivre est déjà une performance en soi.

Du point de vue de l’équipe, nous sommes 5 à travailler dessus à temps plein et bénéficions de contributions régulières de notre communauté (tickets, PR, plugins et récemment une application mobile). Il y a donc une activité soutenue autour du produit.

Pour ce qui est de la licence, Kitsu est toujours sous AGPL. Son installation et son usage sont pleinement documentés, mais il dépend encore beaucoup de la structure commerciale derrière (CGWire). Son fonctionnement est bien compris par plusieurs membres de la communauté, mais pas assez pour qu’ils le maintiennent eux-mêmes.

En somme, le projet avance lentement mais sûrement et se porte bien. L’outil remplit son rôle, la communauté est contente et se développe. Nous avons pu conserver la licence tout du long et l’adoption est grandissante.

La rencontre avec Blender

À travers mon projet précédent, feu Cozy Cloud, et plus récemment les événements OSS Founders, j’avais déjà eu l’occasion de rencontrer des fondateurs de projets libres populaires. Parmi eux, on compte les CEO de Matomo, Nextcloud ou Strapi. Ces échanges sont toujours grisants, intéressants et informatifs, mais ça n’est pas allé plus loin que quelques bonnes discussions et poignées de main.

Avec Kitsu, pour la première fois, j’ai eu l’occasion de collaborer directement avec un projet libre à succès et pas des moindres : Blender (un outil de création 3D en plein boom). J’ai non seulement pu assister aux premières loges de leur ascension récente, mais j’y ai aussi un peu participé.

En effet, la plupart des studios utilisant Blender se sont tournés naturellement vers notre solution pour gérer leurs projets. La fondation portait un outil similaire de gestion (Attract) mais son développeur principal n’était autre que Francesco Siddi (aujourd’hui CEO). Son implication grandissante dans tous les domaines de la fondation lui laissait peu de temps pour s’en occuper. Voyant les progrès de Kitsu, il s’est tout simplement dit qu’il était plus simple de nous soutenir que de continuer à maintenir son projet.

Ainsi, Kitsu a été choisi pour suivre les projets vidéo du Blender Studio, mais a aussi été plébiscité par celui-ci. Nous avons donc gagné en notoriété et avons bénéficié d’une visibilité internationale. Le studio ne s’est pas arrêté là puisqu’il nous a également un peu soutenus financièrement en commandant quelques fonctionnalités dans le logiciel. En contrepartie, notre logiciel leur a bien été utile pour s’organiser et faciliter la création de leurs films. J’en profite tout de même pour les remercier une nouvelle fois pour leur aide !

Un autre élément important, qui nous a beaucoup impactés, c’est la présentation que Ton Roosendal m’a faite du projet Blender lors de ma visite au studio (encore CEO à l’époque, mais il intervenait moins car il avait commencé les soins du cancer dont il sera guéri plus tard). Il a partagé avec moi les valeurs profondes de la fondation. Leur mission principale est de donner à n’importe quel artiste la liberté de créer en lui fournissant des outils de création numérique haut de gamme. Blender est en fait bien plus qu’un logiciel, c’est un vrai mouvement pour un monde plus ouvert.

Ce qui m’a amené à pousser la mission de Kitsu dans ce sens : l’idée n’était plus seulement de permettre de collaborer sereinement au sein des équipes d’animation. Nous voulions aussi permettre à n’importe quel studio dans le monde d’avoir les outils d’organisation et la méthode pour mener un projet de long métrage ou de série au bout, malgré des budgets toujours plus serrés.

En effet, les narratifs de film d’animation sont encore trop peu diversifiés et s’inspirent souvent de ceux de Disney. Chaque film indépendant qui émerge propose une autre vision du monde. Cette diversité nous libère des conceptions véhiculées par les films à grands budgets. Comme les maigres budgets des films indés ne suffisent pas toujours à finaliser le projet avec la qualité souhaitée, de bons outils d’organisation sont nécessaires pour optimiser les efforts. Ceux-ci étaient difficilement accessibles (chers et complexes à mettre en œuvre), Kitsu de par son aspect libre et sa simplicité, a rendu possible l’utilisation de ces outils.

De cette manière, de nombreuses œuvres originales comme Flow, Jim Queen, In Waves, Linda veut du poulet, Allah n’est pas obligé ont pu aller au bout de leur vision artistique. Et dans le monde entier, le phénomène s’est répété, comme encore récemment avec des films comme Bravecat en Amérique latine ou Igi (en cours) en Géorgie. Ces nouveaux points comptent, car ils libèrent nos imaginaires en nous offrant un autre regard sur le monde.

Vous l’avez compris : rencontrer et être accepté par l’équipe et la communauté de Blender a été transformateur pour notre projet. Nous avons, d’une part pu étendre notre visibilité, mais surtout viser une finalité encore plus porteuse.

Diapositive de présentation du pipeline du Blender Studio

Logiciel libre et parentalité

Dans un tout autre registre, il y a 3 ans environ je suis devenu père. Cet heureux événement a eu un impact significatif sur mes projets et mes contributions.

Cela ne surprendra personne, mais ça prend beaucoup de temps et d’énergie d’être parent. D’autant plus que cela s’est passé sur fond de crise du secteur de l’animation, ce qui a fait que je n’ai pas pu vraiment lever le pied sur Kitsu.

J’ai donc forcément dû sacrifier pas mal d’activités. À partir de ce moment-là, toute contribution était devenue trop difficile pour que je me motive. J’ai dû aussi arrêter l’organisation des meetups que j’ai mentionnés dans mon précédent post. Même suivre l’actualité des différentes associations du libre ne m’était pas toujours facile.

Mon emploi du temps a été chamboulé et les soirées drainaient suffisamment mon énergie pour me démotiver à regarder d’autres dépôts de code ou à démarrer de nouveaux projets. J’ai donc pris conscience à quel point c’est difficile pour un parent de contribuer. Je suis d’autant plus admiratif quand je rencontre un développeur parent désormais.

Pour tempérer, cela s’améliore avec le temps. Pour preuve, j’ai pu écrire cet article ! Et cette situation peut aussi être vue comme l’occasion de se donner des limites strictes et de se concentrer sur un problème donné plutôt que de papillonner sur plein de projets différents.

La pression de l’offre gratuite

Vouloir vendre un logiciel “gratuit” n’est pas chose aisée. En réalité, on vend de l’hébergement et du support autour de Kitsu. Alors, certes, l’accès gratuit facilite la dissémination, mais cela nous amène aussi à quelques écueils.

Un premier souci est que les installations auto-hébergées sont rarement propres et que le logiciel n’est pas toujours utilisé de façon optimale. Cela nous arrive donc de croiser des utilisateurs mécontents sans comprendre l’origine du problème. Mais quand on creuse un peu, ils utilisent une version auto-hébergée et n’ont pas la dernière version ou ne sont simplement pas au courant de la disponibilité d’une fonctionnalité.

Les studios pensent faire des économies en se passant de nous, mais se priver d’un éditeur pour un logiciel clé a aussi un coût (installation, maintenance, impact des incidents, sous-optimisation). Et cela nous impacte négativement aussi dans le sens où on peut générer de l’insatisfaction sans que nous y puissions faire quoi que ce soit.

Ce problème est tout de même compensé par un autre phénomène : beaucoup de gens sont contents de pouvoir accéder à ce type d’outils alors que leur budget ne le permet pas. On ne compte plus les studios qui viennent nous remercier sur notre stand sans qu’on ait jamais entendu parler d’eux.

Pour autant, cela crée une situation où notre plus gros concurrent devient nous-mêmes. Nous sommes contraints d’argumenter en notre faveur auprès d’un utilisateur déjà convaincu. Il nous est aussi arrivé d’avoir des clients utilisant notre cloud, qui, au renouvellement, nous annoncent le prix qu’ils souhaitent payer en nous menaçant de basculer en auto-hébergement si nous refusons.

Et avec la crise du secteur, beaucoup de studios ont décidé de basculer sur la version auto-hébergée. Récemment, nous avons lancé une offre légère de support à petit prix. Le succès a été très timoré. Cela nous a mis dans la position inconfortable de devoir quémander des sous à des sociétés qui tirent un bénéfice conséquent de notre solution.

Cela crée une situation difficile à gérer. Nous ne l’avions pas anticipé, nous pensions que les productions avec des budgets significatifs n’oseraient pas se priver de la garantie de fonctionnement proposée par le fournisseur.

Ce manque à gagner freine clairement notre progression et surtout nous met toujours sur le fil. Quand les perspectives ne sont pas bonnes, cela nous met particulièrement sous pression. Malgré la dynamique vertueuse du logiciel libre, cela peut aussi engendrer des situations désagréables pour les mainteneurs. Pour pallier à ça, nous essayons aussi de mettre en place des fonctionnalités propriétaires externes au logiciel : système de synchronisation entre différents studios, serveur MCP, optimisations des traitements vidéo, configuration multi-régions, etc. Nous avons pas mal d’espoir que cela remotive les studios avec un budget à rebasculer sur une offre complète.

Pour résumer, le fait que Kitsu soit libre stimule énormément l’écosystème de l’animation. Pour autant, cela génère une pression importante sur l’entreprise soutenant son développement. Maintenir le projet à flot tout en restant libre requiert beaucoup de travail.

Standardisation

Mais le fait que l’application se diffuse facilement fournit aussi un avantage non négligeable : petit à petit, l’outil devient le standard de l’industrie. D’autant plus que notre modèle de données et nos interfaces sont plutôt légers comparés aux offres concurrentes. Kitsu est donc l’outil facile à adopter, sur lequel on peut démarrer très vite en passant de studio en studio.

Encore mieux, chaque studio peut scripter facilement des connexions avec ses propres outils et avec le Kitsu d’un autre studio. Comme il est courant de fonctionner en coproduction (plusieurs studios financent et fabriquent le projet), le côté standard de Kitsu facilite bien la collaboration.

Côté école, Kitsu a la cote aussi. Pour les étudiants, la facilité de prise en main les aide à mettre en place leurs premiers projets. Cela leur fournit aussi un cadre de studio. Ainsi, ils seront ce qui est attendu d’eux en matière de reporting et de communication une fois qu’ils intégreront une équipe. Les futurs professionnels de l’image connaissent déjà Kitsu et seront motivés pour en parler.

Étant donné que la difficulté du film réside dans la partie artistique, fournir une brique clé en main, facilement accessible, retire une bonne épine dans le pied à toutes les parties prenantes de l’industrie. Quand Kitsu devient le choix par défaut, le problème de l’outil d’organisation se règle. Les équipes de production peuvent se concentrer sur leurs métiers respectifs et, par conséquent, livrer de plus beaux films.

Le premier Kitsu Summit

Fort de ce succès, nous avons pu organiser le premier événement sur une journée entièrement dédiée à notre projet. 70 personnes ont été réunies autour de 12 conférences parlant de l’utilisation de Kitsu. Nous avons aussi accueilli quelques sponsors.

Cela nous a permis de faire se rencontrer tout un tas d’acteurs de notre écosystème. La communauté a pu échanger dans la joie et la bonne humeur. Nous avons aussi discuté avec tout un tas de personnes que nous ne voyons jamais directement. Ce genre d’événements est évidemment très stimulant.

Nous avons également pu récupérer beaucoup de captations vidéo. Ce qui nous a fourni un conséquent matériel vidéo à diffuser. Cela renforce notre crédibilité. Toutefois, organiser un tel événement a requis beaucoup d’énergie et a été assez coûteux (nous étions largement à perte). Nous ne sommes donc pas encore en capacité d’en faire un tous les ans, mais la motivation pour un autre est là !

Keynote d’ouverture au Kitsu Summit 2026

Le code à l’heure de l’IA générative

Comme si la crise du secteur ne suffisait pas, notre métier de développeur a été révolutionné récemment. Les IA génératives génèrent du code correct rapidement. Quand j’enfile ma casquette de développeur, je passe donc plus de temps à discuter avec un agent qu’à intervenir sur le code directement.

Bien qu’étant une petite équipe, ces nouvelles possibilités, nous ont pas mal occupés. Nous avons pu lancer des refactorings longtemps attendus, en planifier d’autres et lancer des audits à répétition sur notre existant (à chaque avancée des modèles). Nous avons pu aussi prendre beaucoup plus de tickets. En interne, nous avons également développé plein de petits utilitaires pour nous faciliter la vie, surtout au niveau de notre infrastructure d’hébergement.

La partie assurance qualité du projet a été la plus boostée, mais nous avons aussi pu fournir de nombreuses fonctionnalités rapidement et trouver des solutions à des problèmes posés depuis longtemps (exemple : appliquer une gomme sur des dessins vectoriels).

Les contributions ne sont pas en reste. Elles sont déjà plus nombreuses, plus conséquentes, et de meilleure qualité. Voici quelques exemples : support d’OpenID, serveur MCP, app mobile pour valider les vidéos stockées sur la plateforme, plugin applicatif, etc. Pour les encaisser, nous faisons appel aux modèles eux-mêmes afin de faciliter les relectures.

Néanmoins, qui dit plus de code, dit plus de travail. Cela nous demande aussi de repenser notre organisation en vue de gérer cette nouvelle masse. Surtout si les contributions et tickets s’accélèrent, nous allons devoir revoir complètement notre infrastructure d’intégration continue (automatisation de l’analyse et traitement des tickets, des pull requests, des remontées Sentry, etc.).

Nous avons aussi pu utiliser pour la première fois Kitsu pour gérer un projet de développement complet. En effet, lancer un agent sur un projet long n’offre pas de retours clairs sur l’avancement. Avec notre outil, nous avons pu suivre toute la progression, fournir des retouches via notre système de discussion et surtout nous avons pu tracker la consommation complète de tokens (ainsi que le temps total passé). C’est un usage détourné de Kitsu mais c’est intéressant qu’à l’heure de l’IA, les développements se suivent plus comme un projet industriel classique : de manière linéaire avec un suivi de consommation.

Mais tout ceci vient avec de lourdes contreparties. La manière dont sont fabriqués et distribués les modèles est délétère : extraction massive de ressources, esclavagisme des travailleurs du clic, consommation excessive d’énergie, concentration du contrôle des modèles et communication menaçante des acteurs du secteur. Et pour revenir à un souci plus terre-à-terre, le prix du token n’est pas encore déterminé. Ce qui est possible aujourd’hui ne le sera pas forcément demain.

Pour mitiger ces aspects, nous avons rédigé un manifeste pour placer quelques garde-fous : https://www.cg-wire.com/sustainable-ai-manifesto. Ces lignes nous permettent de garder un minimum de respect pour nos utilisateurs, mais elles ne résolvent pas tous les problèmes mentionnés.

Dans les autres aspects négatifs, j’aimerais aussi souligner le fait que la perte de contrôle induite par l’utilisation d’un logiciel tiers, n’est pas négligeable. On passe d’un stade où on peut tout coder chez soi sans connexion internet et de manière privée à une situation où on envoie tout sur un cloud extérieur facturé à l’usage et analysant nos données (Andrew Kelley en parle mieux que moi).

Les reviews aussi sont plus délicates. Avant, faire une review permettait de faire progresser le contributeur. Désormais, la review sert principalement à valider le code. L’impact d’une relecture est donc moindre. Il faut aussi revoir beaucoup plus de code généré avec une logique exhaustive. Certes, les modèles respectent les règles de l’art, mais pour autant la charge cognitive à la relecture est plus importante.

Autre souci, les agents de code poussent à la consommation et proposent toujours d’aller plus loin. L’agent ne se fatiguant jamais, le fait de définir des limites devient difficile. Minimalisme et code agentique ne font pas bon ménage.

Enfin, le plaisir de coder n’est plus le même. Passer une bonne journée à résoudre des problèmes, nettoyer son code, écrire la documentation associée est bien plus plaisant que de discuter des fonctionnalités, de l’architecture et des objectifs avec un LLM.

Voilà pour un premier tour d’horizon. Le sujet de l’IA générative dans le code est très complexe. Je n’ai pas de recommandation à faire. L’idée ici est de partager un premier retour d’expérience. Ce changement est encore très récent et il est difficile d’avoir du recul dessus. Au passage, je recommande l’excellente publication Limites Numériques, qui pose pas mal de bonnes questions sur le sujet des LLM et IA génératives, notamment sur la partie expérience utilisateur.

Développement d’un serveur MCP suivi avec Kitsu

IA et données personnelles

Cela me permet de faire la transition vers un sujet qui me tient particulièrement à cœur : la question des données personnelles (cf. l’ère Cozy Cloud). En effet, à travers les interactions avec les LLM, nous produisons et fournissons des données personnelles plus que jamais. Le besoin de récupérer le contrôle dessus se fait donc encore plus ressentir.

D’autant plus qu’un nouveau champ d’usage semble possible. Puisqu’avec plus de données de contexte, les réponses deviennent plus pertinentes et peuvent se baser sur des rapprochements intelligents. La mise à disposition d’un assistant virtuel paré à nous servir devient envisageable.

Aujourd’hui, des outils libres comme Hermes ou OpenClaw permettent déjà de mettre en place un tel agent pour organiser nos besoins personnels. Mais pour en tirer pleinement parti, il faut un accès à un LLM local (très coûteux aujourd’hui) et à des données personnelles structurées et privées. On peut évidemment fonctionner avec des LLMs du marché et la suite Google mais cela revient à se livrer totalement à un acteur tiers. Et comme on l’avait constaté avec Cozy Cloud, les données sont trop fragmentées entre plateformes concurrentes. C’est donc plus difficile de faire ça aussi bien qu’avec des services maîtrisés et déployés sur son propre hardware.

J’ai aussi pu observer que le principe d’autohébergement s’est popularisé : le Mac Studio est en rupture de stock, le Framework Desktop a un succès retentissant, Google propose des VM personnelles (Gemini Spark), NVidia propose sa box, etc. Toutefois, s’auto-héberger devient de plus en plus un sport de riches. Le prix du matériel explose et pour faire tourner un bon LLM, il faut compter plusieurs milliers d’euros.

Tout ça pour dire que l’informatique personnelle va probablement prendre une nouvelle dimension, mais cela profitera probablement surtout aux classes très aisées. Je suivrai tout de même cela de près et encouragerai toute initiative libre et protectrice de la vie privée dans ce domaine.

Conclusion

Ces cinq dernières années ont été très riches en événements, apprentissages, rencontres et découvertes.

Même si j’ai moins codé, j’ai beaucoup appris sur les dynamiques du logiciel libre et des modèles d’affaires liés tout en suivant les dernières évolutions technologiques. Mais surtout, j’ai pu voir mon projet se développer et rendre ses utilisateurs heureux. Enfin, j’ai pu travailler avec un des projets les plus excitants du monde libre.

Mon constat est que réaliser un projet utile et libre a un impact positif net sur le secteur ciblé. Cela amène à faire des rencontres inespérées auparavant. Mais plus l’outil progresse, plus l’alimenter nécessite des moyens conséquents. Les trouver requiert beaucoup d’énergie et amène à des situations ingrates. C’est dans ces moments que la mission prend tout son sens. Il faut savoir pourquoi on se lève le matin pour garder la motivation et trouver l’énergie pour continuer.

Kitsu a aussi permis à une brique libre de faire une percée dans un secteur où les solutions propriétaires étaient quasi omniprésentes (en dehors de l’adoption récente de Blender). C’est un pas de plus vers un monde numérique plus vertueux.

Tout ceci n’a pas été de tout repos, mais je dois dire que c’est une sacrée aventure dont je ne me lasse pas. J’ai tout de même hâte d’arriver à une forme de stabilité. Les aléas du marché créent une incertitude qui n’est pas toujours confortable. J’espère pouvoir vous dire que j’y suis arrivé lors de mon prochain bilan en y ajoutant plein d’autres apprentissages et nouvelles !

Session de validation de plans dans Kitsu (images : Wing it par le Blender Studio)

Questions-réponses tirées du journal

Est ce que tu penses que les difficultés dont tu parles sont liées à votre licence ? (piratebab2)

Avec la licence libre, on perd l’effet d’entraînement qui permet d’avoir plus de fuel pour continuer à faire grossir l’équipe et de rajouter des services. Et comme le marché est petit, d’une certaine manière ça diminue le nombre d’entreprises atteignables. Avec une approche propriétaire, il aurait été plus difficile de convaincre les premiers utilisateurs et le côté standard aurait été plus difficile à atteindre et la crise nous aurait aussi impactés. Ça n’aurait pas été simple non plus.

Avez-vous pensé à faire de la formation pour mettre du beurre dans les épinards ? (piratebab2)

Nous avions essayé sans succès, mais c’est peut-être une idée à relancer maintenant que la surface fonctionnelle du logiciel est plus importante. D’autant plus que les formations sont beaucoup subventionnées dans le secteur. Le coût pour un studio est faible.

Vous pouvez fournir une assistance à la mise en place de l’auto-hébergement, puis un contrat de maintenance (piratebab2)

Oui on a ajouté ça récemment avec notre programme Partners : https://www.cg-wire.com/partners/
Ça prend un peu, on va essayer de pousser ça pour se créer un flux de revenu supplémentaire. Si ça prend vraiment ça peut nous booster significativement (100 studios qui s’inscrivent = 350k€ / an en plus).

Pour pouvoir faire des formations professionnelles dont le paiement est pris en charge par les dispositifs en vigueur il faut avoir une certification Qaliopi ce qui entraîne des frais non négligeables parce que c’est payant. (Ysabeau 🧶)

Merci pour les infos. Dans le secteur de l’animation c’est L’AFDAS qui gère tout ça (la plupart des gens sont intermittents du spectacle), et idéalement il faut passer par un organisme de formation agréé.

Merci pour les suggestions !

Il fait trop chaud pour laisser un ordinateur allumé chez vous, qui va forcément générer des degrés celsius supplémentaires. C'est le bon moment pour ouvrir un magazine papier. Voici donc l'édition estivale de notre petit panorama, forcément subjectif et parti{e,a}l, de la presse papier (et en ligne) disponible en ce milieu d'année. Et comme c'est l'été, on se permet de déborder un peu pour ne pas parler qu'informatique libre, mais aussi jeux…

Voici donc les nouveautés des éditions Diamond sorties en ce début d'été et disponibles jusqu'à fin août, peu ou prou.

• GNU/Linux Magazine France n^o 282 : du Deep Learning et du python pour détecter les constructions illégales sur des jeux de données IGN ;
• SysOps Pratique n^o 156 fait tourner un LLM chez vous. Bref, #IA et #Souveraineté ;
• MISC magazine n^o 146 vous propose une trilogie d'attaque sur Windows Defender ;
• Hackable n^o 67 installe une surveillance vidéo dopée à l'IA, mais sans cloud ;
• MISC hors-série n^o 36 pirate l'humain avec son dossier consacré à l'ingénierie sociale.

Auxquels nous ajoutons pour le plaisir le hors-série n^o19 Jeux de plateau de Canard PC car nous savons qu'une partie des LinuxFrisés est aussi amatrice de jeux de société. Leur dossier est consacré à la triche ! Vous aurez tout l'été pour peaufiner vos techniques pour détecter vos amis tricheurs !

Bonnes lectures !

Les sommaires des numéros de l'été 2026

GNU/Linux Magazine numéro 282

Au sommaire de ce numéro de juillet — août 2026 :

• Quarkus par la pratique ;
• (Re)Découvrons Ada ensemble !
• Les codes fantastiques : vous ne passerez pas (deux fois) ;
• Détectez les constructions illégales avec le Deep Learning sur des jeux de données IGN ;
• L’horloge du Lapin Blanc : chroniques post-quantiques des signatures PDF ;
• Démystifions la commande dc, 2e volet : étudions les macros.

SysOps Pratique numéro 156 (ex Linux Pratique)

Au sommaire de ce numéro de juillet — août 2026 :

• Piloter la gestion des risques dans une organisation grâce à la méthode EBIOS ;
• Cron en pratique : automatiser efficacement les tâches système ;
• Avoir un LLM qui tourne sur site ;
• Atuin : synchronisez votre historique shell entre toutes vos machines ;
• Sécurisez votre accès Internet avec un routeur OpenWrt ;
• Vers un cluster Kubernetes auto-résilient ;
• L'Infra as a Conversation : reprenez le contrôle de Terraform avec Atlantis.

MISC Magazine numéro 146

Au sommaire de ce numéro de juillet — août 2026 :

• BlueHammer, RedSun et UnDefend : la trilogie zero-day qui transforme Windows Defender en vecteur d'élévation ;
• Top des chemins d’attaque vus en pentest ;
• Exploiter un driver vulnérable Lenovo pour neutraliser n’importe quel EDR - CVE-2026-2640 ;
• Schémas Android : des biais cognitifs au brute-force embarqué ;
• De la collecte au parsing : KAPE comme accélérateur d’investigation Windows ;
• Durcissement du boot Linux : TPM et OTP pour renforcer la sécurité du démarrage ;
• Déployer d'abord, sécuriser jamais : l'IA entre productivité et chaos de sécurité.

Hackable numéro 67

Au sommaire de ce numéro de juillet — août 2026 :

• Ethernet et ESP32 avec le tout nouveau ESP-IDF 6.0 : vers une sonde de surveillance réseau ;
• Un cluster de Raspberry Pi Pico pour explorer le monde de la communication réseau ;
• Construisez votre vidéosurveillance intelligente sans cloud ;
• Une idée (presque) tordue pour le framework FPGA LiteX : le remote build ;
• Les sondes JTAG du pauvre, ou comment configurer un FPGA sans se ruiner ;
• Satellites météo : APT s’éteint, que devient le LRPT ?

MISC hors‑série numéro 36

Au sommaire de ce numéro hors-série de juin — juillet 2026 :

• Sécuriser l’Espace : entretien avec Julien Airaud, Expert Senior en Cybersécurité Spatiale au CNES ;
• Dossier : Le social engineering :
  • L’ingénierie sociale : de la théorie à la pratique ;
  • Votre cerveau a une 0-day : le système 3 et les angles morts de la défense cognitive ;
  • Approche sociologique sur l'épistémologie de l'ingénierie sociale et de l'OSINT ;
  • Manipulation des modèles comme surface d'attaque : terrain de jeu fertile pour la Red Team ?
  • Voir ne suffit plus à croire : comment rétablir la confiance dans le numérique ?
  • De l’ingénierie sociale à la guerre cognitive : influences et manipulations de l’information à grande échelle ;
  • L’influence au service de la souveraineté ;
  • Des statues qui pleurent aux voix clonées : 2000 ans d'arnaques identiques ;
• Here be dragons, le risque humain comme enjeu stratégique.

Canard PC hors‑série Jeux sur un plateaux, numéro 19

Au sommaire de ce numéro hors-série de juillet — août 2026 :

• Dossier : La triche
  • La triche à travers l´histoire ;
  • La triche est-elle inévitable ?
  • Les plus grands scandales de triche ;
  • Dans la tête des tricheurs ;
• Tests :
  • Familiaux Panorama, L´encyclopédie des Monstres, First Giants, Bunny Kingdom Town…
  • Solo/Duo Leda, Ace of Spades ;
  • Party games Vroom, Hot Streak ;
  • Cartes The Last Wizard ;
  • Gestion Diktat, Heroes Write & Conquer, Star realms - Rise of Empire, Recall ;
  • Stratégie Feya´s Swamp, Night Soil, The Old King´s Crown ;
  • Dans les tuyaux Fragments - Solara ;
  • Extension Shackleton Base ;
  • Import Misfits ;
• Les autres dossiers
  • Portrait : Fanelia ;
  • Modder ses jeux de plateau ;
  • Les dés pimpés ;
  • Le capitalisme dans les jeux ;
  • Le jeu peut-il faire voyager ?
  • Les jeux régressifs ;
• Jeux de rôle
  • Tests: Drama Lamas, Voltige, Notre-Dame de Paris ;
  • Dans les tuyaux Triangle Agency ;
  • Le jeu de rôle à l´hôtel.

L’Association Francophone Python (AFPy) organise la PyConFR 2026 du jeudi 29 octobre au dimanche 1 novembre. Pour cette 17e édition, nous sommes accueillis par l'école ESTIA de Biarritz !

La PyConFR, c’est un évènement gratuit sur 4 jours autour du langage de programmation Python. Elle est composée deux jours de développements participatifs (sprints), puis de deux jours de conférences et ateliers.

L’appel à propositions est ouvert jusqu’au 31 juillet 2026. Peu importe votre niveau en Python, vous pouvez proposer un sujet de sprint, de conférence ou d’atelier ! Venez parler de développement logiciel, de diversité, de communauté, faire un retour d’expérience sur un outil, présenter votre projet, un domaine d’activité…

Comme tous les ans, nous proposons aux personnes habituellement peu représentées en conférence de l’aide pour trouver un sujet, rédiger la proposition de conférence, rédiger le support de conférence et pour répéter. Vous pouvez nous contacter à l’adresse diversite@afpy.org si vous pensez en avoir besoin.

Enfin, la PyConFR est entièrement financée par les sponsors. Si vous connaissez des sponsors potentiels, n’hésitez pas à leur parler de l’évènement !

curl -i -H 'Host: foo' http://target/admin # 403, bloqué
curl -i -H 'Host: foo?' http://target/admin # 200, ça passe !!

Et c'est tout ! Un simple point d'interrogation collé au Host header, et l'endpoint "/admin" qui jusqu'alors filtrait les non-authentifiés s'ouvre alors aussi facilement que le claque-merde de mes haters ^^.

Donc si votre infra utilise FastAPI, vLLM ou LiteLLM exposés directement en ASGI (uvicorn, hypercorn, granian) sans reverse proxy strict devant, vous pouvez tester votre exposition immédiatement grâce au scanner de BadHost développé par Nemesis et X41 D-Sec.

Niveau mécanique, Starlette reconstruit l'objet "request.url" en concaténant la valeur du header "Host" avec le path de la requête, puis re-parse le tout. Sauf que la valeur de "Host" n'est jamais validée donc si vous y injectez un "/", un "?" ou un "#", vous décalez la frontière entre path, query et fragment au moment du re-parse.

Du coup, le routeur Starlette dispatche sur le vrai path de la requête HTTP (donc votre endpoint sensible s'exécute bien), mais les middlewares qui lisent "request.url.path" voient simplement un path empoisonné qui ne correspond plus à rien d'interdit.

Donc le contrôle d'accès saute et le code derrière tourne quand même. On est sur un score CVSS de 7/10 et la boite de sécu Secwest estime même que cette note est largement sous-estimée... En gros c'est super grave !

Car la portée réelle ce sont surtout les serveurs MCP qui peuvent stocker ou manipuler des tokens et identifiants pour accéder aux ressources externes auxquelles les agents IA se connectent : bases de données, comptes mail, calendriers, S3, webhooks...etc

Bref, le genre de "coffre-fort" que vous ne voulez pas voir ouvert via un header HTTP à la con malformé. Markus Vervier de X41 D-Sec a même publié un petit échantillon de ce que leurs scanners ont déjà trouvé en production : Des bases de données d'essais cliniques chez des biopharmas, des données de vérification d'identité avec PII en temps réel, des accès SSH à des équipements industriels via bastion, des boites mails complètes en lecture/écriture, des listes de souscripteurs CMS, des topologies AWS complètes avec metric queries.

Bref, l'écosystème agents IA vient de passer en mode naturiste !

Pour régler ce problème, vous devez donc mettre à jour vers Starlette 1.0.1 ou supérieur, dans tous vos déploiements LLM qui l'intègrent... Et là c'est le bordel parce qu'il y en a partout : Dans les images Docker, les virtualenvs et les artefacts "vendorisés" un peu partout... Donc faut tout rebuilder.

Et si vous avez du code custom, l'OSTIF recommande aussi de remplacer request.url.path par request.scope["path"] partout où une décision de sécurité est prise.

En gros, lire la valeur non reconstruite est le "fix" qui survivra aux prochaines versions du bug, parce que croyez-moi, ça reviendra à coup sûr !

Maintenant, côté infra, X41 D-Sec et OSTIF indiquent que nginx, Apache httpd et Cloudflare rejettent le PoC par défaut, mais ça ne doit pas vous empêcher de vérifier votre config. Donc ne traitez votre reverse proxy comme une mitigation qu'après l'avoir testé explicitement avec le scanner Nemesis.

Au-delà du correctif technique, BadHost rappelle une mécanique qu'on a déjà vue avec la faille RCE de llama-cpp-python à savoir que la chaîne d'approvisionnement de l'IA ne tient que sur quelques mainteneurs bénévoles qui prennent des risques personnels énormes pour patcher proprement.

Kludex, le mainteneur de Starlette, est actuellement sous une avalanche de reports depuis des mois. L'audit qui a permis de trouver le bug a par ailleurs été financé par OSTIF et AWS et sans ça, BadHost serait encore probablement dans la nature pour un an voire plus avant d'être découvert plus naturellement.

Donc si votre boîte fait tourner du LLM en prod via FastAPI, vLLM ou LiteLLM, vous avez aujourd'hui 2 choses urgentes à faire : 1/ passer votre infra dans le scanner Nemesis, et 2/ envoyer un petit don à Kludex pour le soutenir !

Sources : Ars Technica , OSTIF

Le 20 avril 2026 est sortie la version 8.0 de long support de Tryton un progiciel de gestion intégré modulaire et multiplate-forme.

La version 8.0 de Tryton s'inscrit dans la continuité des versions précédentes en améliorant la stabilité, les performances et les fonctionnalités (dont ci-dessous les principales).
Cette version a un support long de cinq ans comparé à une année pour version précédentes.

Interface et usage quotidien

Quand un champ a été modifié par les actions de l'utilisateur, il est identifié afin de permettre une vérification visuelle avant de sauvegarder.

Les onglets peuvent être réorganisés maintenant aussi pour le client web et l'action de déconnexion est désormais dans le même menu qui contient déjà les notifications et les préférences utilisateurs afin de donner encore plus d'espace dans l'entête pour les onglets.

Modules métiers

Sur le plan fonctionnel, la version 8.0 s'enrichit avec de nouveaux modules : gestion des chèques, gestion des accises et suivi d’alcool ainsi que le suivi de la vente de service par des tâches de projet.

Les modules comptables espagnols et allemands ont été sortis du dépôt standard afin d'être gérés plus simplement par la communauté.

Administration et développement

La version 8.0 ajoute le support de Python 3.14 et arrête celui de Python 3.9.
La librairie psycopg est mise à jour à la version 3 ce qui permet d'envoyer les requêtes SQL et leurs paramètres séparément et ainsi lever les limitations sur la taille des paramètres (entre autre le nombre d'IDs dans les clause column IN (...)).

Il est maintenant possible de définir des champs Function (c-à-d calculés par l'ORM) uniquement par une expression SQL. Cette expression sera utilisée pour la lecture, la recherche et le tri.

La définition des modules a été améliorée pour permettre l'utilisation de sous-répertoires plus facilement. En effet, on peut maintenant créer un fichier tryton.cfg dans un sous-répertoire et utiliser un chemin relatif depuis celui-ci vers ses fichiers ressources.

Une API REST a été ajoutée au serveur et une librairie cliente naiad a été publiée. Elle permet de remplacer l'utilisation du module trytond directement pour la création d'applications connexes telles que des sites web. C'est une architecture plus flexible que celle utilisée jusqu'à maintenant comme dans le module flask-tryton.

Les sessions pour le client web sont maintenant stockées comme cookie pour plus de sécurité.
Le client web utilise à présent uniquement des chemins relatifs, ce qui permet de le servir depuis un sous-répertoire.

Appel à sponsor

Pour préparer l'obligation de facturation électronique en France, un appel à sponsor a été lancé pour intégrer la plateforme agrée SUPER PDP.

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 !

MALT c'est quoi ?

L'optimisation est une activité connue de bien des développeurs, fouiller, chercher dans son code, pour, peut être, gagner un peu de performance (beaucoup, parfois). Dans cette tâche ardue, face à des codes grandissants, massifs, utilisant de nombreuses bibliothèques externes, un outil central dans ce travail de fourmi : le profileur.

Le profileur fait partie des outils importants pour le développeur qui se soucie des ressources qu'il utilise. Il lui permet de chercher les points chauds dans son code, comprendre le cout de chaque fonction, chaque ligne implémentée. Bien des outils s'intéressent à une chose : bien utiliser votre processeur.

Mais que se passe-t-il si vous rencontrez des difficultés avec l'utilisation de votre mémoire ? Si vous pensez mal utiliser la fonction malloc() du C ou l'opérateur new du C++ ? Si vous avez oublié qu'une de vos variables globales occupe 10 Go (surtout en Fortran) ?

Publié il y a quelques années MALT (licence CeCILL-C) permet de répondre à la question en cherchant toutes les allocations mémoires faites par votre code. Cet outil avait fait l'objet d'un article sur LinuxFR en 2018 lors de sa mise en open source : Profileurs mémoire MALT et NUMAPROF.

Versions 1.6.0

Avancées

Depuis, cet outil fait son chemin avec l'ajout du support de Rust ainsi que nombreuses corrections et ajouts tels que la possibilité de dumper le profile mémoire juste avant que le système ne soit plein.

malt -o dump:on-sys-full-at=80% -o watch-dog=true ./mon_programme

# également :
#  -o dump:on-app-using-rss=10G
#  -o dump:on-app-using-virt=80%
#  -o dump:on-app-using-req=500M

La possibilité de suivre les appels à mmap, mremap, munmap si vous les appelez directement dans votre code au lieu de laisser malloc faire son travail.

Support de python

MALT a initialement été développé dans le contexte du calcul à haute performance — HPC (High Performance Computing) donc surtout pour le C / C++ / Fortran / Rust.

Dans la communauté scientifique, nous voyons dans les laboratoires de plus en plus fleurir l'usage d'un langage à priori bien éloigné de nos prérogatives de performances : Python.

Dans un cadre de calcul scientifique, il est souvent utilisé plutôt comme un wrapper permettant d'appeler et d'orchestrer des bibliothèques en C /C++ / Fortran, elles, performantes. Quoi que l'usage amène aussi à l'écrire de certaines parties du code en Python grâce à Numpy ou Numba pour accéléré la partie calcule sur des tableaux ou autres frameworks d'exploitation des GPU.

La version 1.6.0 de MALT vient d'ajouter le support (encore quelque peu expérimental) natif de Python permettant d'analyser un code pur python ou mix Python / C / C++…. Il s'agit pour l'instant de la première version avec ce support, il reste donc du travail.

Sont supportés les versions Python supérieures à 3.11 ainsi que les environnements Conda / Anaconda / Venv. À l'heure de rédaction de cet article, cela comprend les versions 3.11 à 3.14.

MALT étant orienté C / C++, il ne supporte que Linux comme système d'exploitation. (NdM: la causalité évoquée ici devrait faire réagir des développeurs d'autres systèmes libres notamment :))

Utilisation sur Python

Si la commande malt fonctionne parfaitement, il est recommandé d'utiliser le wrapper malt-python qui adapte quelques configurations spécifiques à Python non encore automatiques.

malt-python ./script.py

# équivalent à 
malt --profile python-default ./script.py

# liste des profiles
malt --profile help

# Afficher le profile
malt-webview ./malt-script-py-6889.json

Profilage rapide

Notons que l'overhead de MALT est important en Python du fait du large nombre d'allocations générées par ce langage et de la méthode de résolution des piles d'appels pour retrouver les lignes dans votre code. Ces détails d'analyse peuvent être désactivés via :

# Désactivé complète de l'analyse des piles
malt-python -p python-no-stack ./my_script.py

# Analyse des piles par "sampling"
malt-python -p python-sampling ./my_script.py

Nouvelle interface

La version 1.6.0 arrive également avec une nouvelle interface graphique avec un code remis à jour
par rapport à sa version originale vieillissante.

Profil statique

Pour ceux qui voudraient échanger les profils avec d'autres sur d'autres OS, il est possible depuis la 1.6.0 de générer une version statique des pages de l'interface (hors annotation des sources et arbre d'appel navigable) via :

# Toues les pages possible en statique
malt-webview -static ./report malt-progr-123456.json

# Seulement la page de résumé.
malt-webview -static-summary ./report malt-progr-123456.json

Installation

MALT n'est pas encore disponible dans les distributions classiques, vous devez donc le compiler et l'installer à la main. Le nombre réduit de dépendances obligatoires en fait un outil relativement facile à installer.

On trouvera la procédure dans la documentation du projet.

Documentation

La documentation a été complètement ré-écrite et disponible sur le site officiel : documentation.

Outils similaires pour Python

Découvrir un outil est aussi l'occasion d'en découvrir d'autres. Restons dans le monde du Python, si MALT ne vous convient pas vous trouverez peut-être votre bonheur avec les outils suivants et complémentaires à MALT et eux totalement dédiés au Python toujours pour la mémoire :

• Memray (Apache Public License 2)
• Scalene (Apache Public License 2)

MALT se positionne par rapport aux deux présentés en apportant une analyse fine en annotant tout le source code de l'application. Il offre également une analyse des variables globales et TLS coté C/C++/Fortran/Rust.

Le 15 décembre 2025 est sortie avec un petit délai, la version 7.8 de Tryton, un progiciel de gestion intégré modulaire et multiplate-forme.

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).

analyzer = SemanticLogAnalyzer()
output = analyzer.analyze_file(Path("system.log"))

C'est top moumoute pour le prétraitement de logs avant de les balancer à un LLM (pour réduire le contexte), le triage initial de fichiers de logs inconnus, ou la découverte de patterns inattendus. Par contre, si vous cherchez une erreur spécifique que vous connaissez déjà, grep reste votre ami. Et si vous avez besoin d'un historique complet pour la conformité, oubliez Cordon qui est volontairement "lossy".

Notez qu'au premier lancement, Cordon téléchargera le modèle d'embedding (environ 80 Mo) donc ce sera un peu lent, mais ensuite, ça sera quasi instantané car les lancements suivants utiliseront le cache. Et si vos logs sont très verbeux avec de longues lignes, le modèle par défaut (256 tokens max) risque de tronquer les lignes, dans ce cas, passez à un modèle plus costaud comme BAAI/bge-base-en-v1.5 qui supporte 512 tokens avec le paramètre --model-name.

Voilà, j'espère que ça vous sera utile ! C'est open source sous licence Apache 2.0 et ça se trouve sur GitHub .

from cm_colors import ColorPair

# Your colors
pair = ColorPair("#999999", "#ffffff")

# Fix them and preview in the terminal
fixed_color, success = pair.make_readable(show=True)

print(f"Use {fixed_color} instead of #999999")
# Output: Use #8e8e8e instead of #999999

Le truc vraiment cool, c’est que l’outil gère plusieurs niveaux de lisibilité. Y’a “Readable” qui correspond au AA, “Very Readable” pour le AAA, et même une option large_text=True pour les gros titres qui ont des exigences moins strictes. Vous pouvez donc adapter selon vos besoins et pour les devs qui bossent sur de gros projets, y’a aussi une fonction make_readable_bulk qui permet de corriger plusieurs paires de couleurs d’un coup.

from cm_colors import make_readable_bulk

my_colors = [
 ("#777", "#fff"),
 ("#888", "#000"),
]

results = make_readable_bulk(my_colors)

for color, status in results:
 print(f"{color} is {status}")

git clone https://github.com/zakirkun/deep-eye.git
cd deep-eye

Puis sous Windows :

cd scripts
./install.ps1

chmod +x scripts/install.sh
cd scripts
./install.sh

python deep_eye.py -u https://example.com

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.

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.

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.

python animal-crossing-nes-roms.py ./AnimalCrossing.iso

Kivy est un cadriciel (framework) graphique, permettant de développer des interfaces tactiles (ou utilisable à la souris) sur toutes les plateformes, y compris mobiles. Il s'accompagne d'une suite de logiciels très pratiques que nous allons présenter ici.

Sommaire

• Kivy : boîte à outils graphique multi-plateformes
• kv : interface graphique en déclaratif
  • Les propriétés
• Plyer : accéder facilement aux fonctionnalités matérielles de votre appareil
• Python For Android : utiliser Python… sur Android
• Kivy for iOS : déployez sur les appareils Apple
• Pyjnius : utiliser l’API Java Android depuis Python
• KivyMD, des widgets Material Design
• Quelques limitations
• Conclusion
• Une note d’histoire

Kivy : boîte à outils graphique multi-plateformes

Kivy permet de créer des interfaces graphiques naturellement adaptées aux écrans tactiles (mais qui restent utilisables sur un environnement de bureau traditionnel, à la souris et sans écran tactile). Il est écrit principalement en Python mais les parties critiques sont écrites en Cython, ce qui lui permet d’avoir de bonnes performances.

Une interface Kivy peut s’écrire de deux façons (ou, plus couramment, par une combinaison de ces deux façons) : en Python directement, ou via kv, une syntaxe déclarative dont nous parlons plus bas.

Pour vous donner une idée, voici un exemple de hello world repris du site officiel de Kivy :

from kivy.app import App
from kivy.uix.button import Button

class TestApp(App):
    def build(self):
        return Button(text='Hello World')

TestApp().run()

Ce qui donnera :

Une interface est composée de « widgets » agencés via des « layouts ». Certains widgets permettent de facilement mettre en place des composants communs de nos jours, comme par exemple le widget Carousel :

D’autre part, Kivy fournit des outils qui simplifient la vie du développeur ou de la développeuse, en particulier un système de propriétés (à ne pas confondre avec les propriétés Python) qui permet de mettre automatiquement l’interface à jour quand elles sont modifiées, ou de facilement attacher une fonction de rappel (« callback »), voir plus bas pour un exemple simple. On peut aussi citer un mécanisme d’animations très pratique et efficace.

kv : interface graphique en déclaratif

kv est un langage permettant de décrire des interfaces, il met à profit les propriétés mentionnées plus haut et l’interface va se mettre à jour automatiquement quand des propriétés utilisées dans kv sont modifiées.

Reprenons le hello world vu plus haut, et faisons-le avec kv:

Widget:
    Button:
        text: "Hello World"

Plutôt simple non ?
Le code kv est généralement mis dans des fichiers séparés avec l’extension .kv.

Les propriétés

Kivy a donc un concept de propriété, qui permettent la liaison de données bidirectionnelles (two-way data binding), ou en d’autres termes de facilement avoir l’état mis à jour entre le code python et l’interface décrite dans le fichier kv. C’est à l’usage très pratique et facile.

Un exemple va sans doute aider à comprendre.

Commençons par faire un environnement virtuel Python avec Kivy:

$ mkdir demo

$ cd demo

$ python -m venv env

$ source env/bin/activate

$ pip install kivy

Ensuite créez le fichier demo.py suivant :

from kivy.app import App
from kivy.uix.boxlayout import BoxLayout
from kivy.properties import NumericProperty

class CompteurWidget(BoxLayout):
    compteur = NumericProperty(0)

    def increment(self):
        self.compteur += 1

class DemoApp(App):
    def build(self):
        return CompteurWidget()

DemoApp().run()

Et maintenant, dans le même répertoire, ajoutez le fichier demo.kv suivant, ce dernier sera automatiquement découvert par Kivy parce qu’il s’appelle comme notre application (DemoApp) sans le suffixe App et en minuscule :

<CompteurWidget>:
    orientation: 'vertical'
    padding: 20

    Label:
        text: str(root.compteur)
        font_size: 30

    Button:
        text: "Incrémenter"
        on_press: root.increment()

Il ne nous reste plus qu’à lancer le programme :

python demo.py

Et à admirer :

Le label se met automatiquement à jour quand le compteur compteur est incrémenté.

La lectrice ou le lecteur assidu de DLFP pourra faire un TapTempo en exercice.

Note: Ne vous arrêtez pas au fait que l’UI est un peu "moche" par défaut, il y a des extensions beaucoup plus attractives (cf. KivyMD plus bas), et il est très facile de personnaliser l’interface et d’en faire une très belle en modifiant un peu ses fichiers .kv.

Plyer : accéder facilement aux fonctionnalités matérielles de votre appareil

Plyer est une bibliothèque permettant d’accéder à nombre de fonctions utiles de manière indépendante de la plateforme. Ainsi vous avez une API commune pour afficher une notification, demander l’état de la batterie, faire vibrer l’appareil, faire de la synthèse vocale de texte (« text-to-speech »), ouvrir un fichier avec le dialogue natif de la plateforme, etc.

Bien que développé par la même équipe que Kivy, ce paquet est utilisable indépendamment et est donc particulièrement utile pour n’importe quel projet multi-plateformes. Référez-vous à la page du projet pour avoir un tableau des fonctionnalités supportées selon les plateformes, et à la documentation pour plus de détails.

Python For Android : utiliser Python… sur Android

Si vous souhaitez distribuer votre application sur Android, vous allez devoir avoir une version de Python compilée pour cette plateforme, ainsi que de tous les paquets nécessitant une compilation.

C’est le rôle de Python pour Android, qui est une collection d’outils qui s’appuient sur l’Android SDK pour permettre d’utiliser Kivy ou d’autre paquets Python sur Android, et ainsi faire votre propre distribution Python.

Si vous utilisez un paquet qui n’est pas en pur Python (c’est-à-dire qu’il y a des parties à compiler) et qui n’est pas encore disponible ou qui l’est mais dans une version trop ancienne, vous pouvez écrire ou mettre à jour des « recettes » (recipes en anglais) qui indiquent comment compiler. Référez-vous à la documentation pour voir comment faire.

Notez toutefois qu’il y a une pénalité à utiliser du Python par rapport à une application dans un langage compilé : il faut charger l’interprète au démarrage, et au tout premier lancement de votre application (et uniquement au premier) il y a aura une phase de décompression de vos fichiers. En dehors de ces petits inconvénients, ça fonctionne très bien.

Là encore, le projet est indépendant de Kivy et peut être utilisé avec un autre cadriciel.

Kivy for iOS : déployez sur les appareils Apple

À l’instar d’Android, l’équipe de Kivy fournit les outils pour faire votre distribution Python pour iOS.

Il vous faudra posséder une machine Apple pour les utiliser, à cause des restrictions imposées par cette plateforme (ceci n’est pas spécifique à Kivy pour iOS, mais s’applique à tous les outils pour développer sur iOS).

Ainsi avec une seule base de code (et après avoir passé un peu de temps pour configurer correctement les outils de compilation), vous pouvez déployer votre application Kivy/Python sur toutes les plateformes majeures (hormis le web, pour lequel il existe d’autres options comme Brython, Pyodide ou PyScript, mais c’est un sujet pour une autre dépêche).

Pyjnius : utiliser l’API Java Android depuis Python

Parfois l’utilisation de Plyer mentionné plus haut et de la bibliothèque standard Python ne suffisent pas, et vous avez besoin d’accéder à l’API d’Android, mais cette dernière est faite pour être utilisée avec Java ou Kotlin.

Pour pouvoir utiliser l’API d’Android depuis Python, PyJNIus est disponible. Ce paquet permet d’accéder aux classes Java comme à des classes Python en utilisant JNI (« Java Native Interface » ou « Interface Native de Java »).

Ce paquet fournit une méthode autoclass qui convertit automatiquement une classe Java en Python, c’est très facile à utiliser et souvent suffisant pour les cas simples.

KivyMD, des widgets Material Design

KivyMD n’est pas un projet officiel de l’équipe Kivy, mais un projet tiers dédié à la création d’un ensemble de Widgets thémables adoptant Material Design.

L'image ci-dessus est issue de la documentation de KivyMD, vous trouverez également des démos vidéo sur le dépôt du projet.

Quelques limitations

Une petite note sur mon expérience personnelle (Goffi). Kivy est un excellent cadriciel, et l’équipe est accueillante et réactive : c’est un projet que je recommanderais en général. Ceci dit, dans mon cas particulier (un client XMPP ayant de nombreuses fonctionnalités), j’ai quelques limitations qui me poussent actuellement à chercher des alternatives, notamment basées sur Qt (PyQt et PySide) :

• l’accessibilité est un problème majeur. L’équipe y travaille, mais aujourd’hui les applications Kivy ne sont pas accessibles. C’est notamment dû au fait que l’interface utilisateur est entièrement gérée par Kivy, au lieu d’utiliser des composants natifs, et c’est un point complètement bloquant pour moi.
• il n’y a pas de webview ou de rendu HTML natif, ce qui est bloquant parce que je fais du rendu de blogs.
• le rendu de texte est incomplet, notamment sur les plateformes mobiles. C’est compliqué de faire un rendu riche avec des émojis, par exemple, un gros problème pour une application de messagerie de nos jours.
• le support des portails Freedesktop est inexistant : il faut faire l’implémentation à la main, alors qu’il est natif sur des cadriciels majeurs comme GTK ou Qt. Je pense par exemple à l’ouverture ou l’enregistrement de fichier. Les portails sont particulièrement nécessaires si on veut voir son application sur Flatpak. Plus de détails sur ce ticket.
• le support Wayland existe, mais lors de mes tests sur des distributions GNU/Linux sur Pinephone, il n’a pas fonctionné et je n’ai pas pu afficher l’application.
• le chargement de l’interprète Python prend un certain temps, ce qui rend le lancement de l’application sur plateformes mobiles telle qu’Android et probablement iOS (que je n’ai pas testé) un peu lent. Sachant que sur ces plateformes l’application peut être tuée à n’importe quel moment auquel cas il faut tout relancer, cela peut mener à une mauvaise expérience utilisateur. Ceci dit, avec une distribution optimisée (en enlevant les paquets non utilisés), et sur les téléphones actuels qui sont très puissants, le problème est sans doute moindre.

Notez que je n’ai pas eu l’occasion de travailler avec Kivy récemment, peut-être que ces remarques ne sont plus à jour. Merci d’indiquer en commentaires s’il y a eu de l’évolution sur ces points.

Aussi, mon cas d’utilisation est très demandant (rendu HTML, affichage de texte performant, etc). Dans la plupart des cas, Kivy remplit sans problème toutes les cases (sauf l’accessibilité, qui reste son problème le plus important à mon sens).

Conclusion

Comme vous pouvez le voir, un travail considérable a été effectué sur Kivy et son écosystème, et il en sort un cadriciel performant, pratique, et qui peut potentiellement fonctionner sur la plupart des plateformes. Kivy est agréable à utiliser, et dispose d’une communauté très active et disponible.

Ce cadriciel mérite de s’y attarder, et est une option sérieuse si vous voulez développer un projet rapidement pour une ou plusieurs plateformes.

Une note d’histoire

Cette dépêche a été commencée le 04 octobre 2018 à 14:19 (au premier jour de la Pycon FR 2018, à Lille, où une partie de l’équipe de Kivy était présente). Je crois que c’est haut la main la dépêche qui est restée le plus longtemps dans l’espace de rédaction. Comme quoi, tout vient à point à qui sait attendre, comme dirait l’autre.

Merci à toutes les personnes qui ont participé à la correction de la dépêche.

L’Association Francophone Python (AFPy) organise la PyConFR 2025 du jeudi 30 octobre au dimanche 2 novembre. Pour cette 16e édition, nous sommes accueillis par le Campus René Cassin de Lyon !

La PyConFR, c’est un évènement gratuit sur 4 jours autour du langage de programmation Python. Elle est composée deux jours de développements participatifs (sprints), puis de deux jours de conférences et ateliers.

L’appel à propositions est ouvert jusqu’au 20 juillet. Peu importe votre niveau en Python, vous pouvez proposer un sujet de sprint, de conférence ou d’atelier ! Venez parler de développement logiciel, de diversité, de communauté, faire un retour d’expérience sur un outil, présenter votre projet, un domaine d’activité…

Comme tous les ans, nous proposons aux personnes habituellement peu représentées en conférence de l’aide pour trouver un sujet, rédiger la proposition de conférence, rédiger le support de conférence et pour répéter. Vous pouvez nous contacter à l’adresse diversite@afpy.org si vous pensez en avoir besoin.

Enfin, la PyConFR est entièrement financée par les sponsors. Si vous connaissez des sponsors potentiels, n’hésitez pas à leur parler de l’évènement !

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.

Multigit est un outil graphique conçu pour simplifier la gestion de projets composés de beaucoup de dépôts git.

Une image et une vidéo valant mieux qu'un long discours, voici à quoi ça ressemble:

Je l'ai développé dans le cadre de mon travail chez IDEMIA où nous sommes souvent confrontés à plus de trente (voire plus de soixante) dépôts à gérer conjointement sur un projet. Dans ce contexte, la moindre opération git devient un mini-défi qu'il fallait relever quotidiennement.

Multigit est abouti et stable, il est utilisé au quotidien par plus d'une centaine de personnes (sous Windows), depuis plusieurs années. Mon employeur m'a aimablement autorisé à le publier en Open Source, ce dont je lui sais gré. Il est publié sous licence Apache 2.0

La problématique de gestion de plusieurs dépôts git conjoints pour un projet est assez peu répandue dans le monde du logiciel libre. Mais beaucoup plus dans le monde de l'entreprise. En effet, git ne gère pas la notion de droit d'accès à une partie d'un dépôt. La seule façon de restreindre l'accès à certains parties d'un projet est donc de créer un dépôt spécifique pour les y stocker, avec des droits d'accès au niveau du dépôt. Ajoutons à cela beaucoup de personnes, beaucoup de projets parfois complexes, beaucoup de sous-projets, beaucoup d'historique et on se retrouve avec une gestion des sources particulièrement complexe. Complexe … avant l'arrivée de Multigit en tout cas.

Installation

Sous Linux, la seule option d'installation disponible à l'heure actuelle est Python + pip, ou encore mieux avec pipx:

    $ sudo apt install python-pipx
    $ pipx install multigit_gx
    $ multigit

Sous Windows, un installeur graphique click-and-play vous permettra d'arriver au même résultat.

J'ai bien tenté de fournir un snap pour Linux mais snap est conçu pour empêcher à peu près tout ce que veut faire Multigit: accèder à tous vos fichiers et lancer des programmes de votre distribution (git, gitk, …)

Je ferai mieux dans la prochaine version. D'ailleurs, si vous avez des recommandations pour un packaging moderne, simple, facile à maintenir et couvrant toutes les distributions Linux, je suis preneur.

Contribution

Le projet est géré sous GitHub, les contributions ou les retours sont les bienvenus.

La PyConFR 2024 a lieu du jeudi 31 octobre au dimanche 3 novembre à l’UFR Mathématique et d’Informatique de Strasbourg. Le planning est disponible et les inscriptions sont ouvertes !

Comme toujours, la PyConFR est un évènement 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 également au programme :

• De villageoise à l’itWoman… Quelles actions pour faire de mon rêve TECH une réalité ?, par Houleymatou Baldé
• Recherche des bonnes pratiques de packaging, par Françoise Conil
• Reality is not an end-to-end prediction problem: Applied NLP in the age of Generative AI, par Ines Montani

Cette année, un espace enfants (de 3 ans à 12 ans) est mis à disposition gratuitement sur inscription. Vous pouvez inscrire vos enfants jusqu’au 15 octobre.

Durant cette édition, c’est aussi le retour du déjeuner PyLadies. Un des objectifs est de tisser des liens entre la communauté PyLadies et le reste de la communauté Python francophone.
Les inscriptions au déjeuner PyLadies sont ouvertes jusqu’au 27 octobre.

Le dimanche matin, l'AFP y tiendra son assemblée générale. Si vous souhaitez y voter, assurez vous d'être à jour de cotisation.

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 !

La conférence ConFoo est de retour pour sa 23ᵉ édition, du 26 au 28 février 2025 à l’Hôtel Bonaventure de Montréal ! Venez découvrir pourquoi ConFoo est devenu l’un des événements phares pour les développeurs et développeuses en Amérique du Nord et de partout à travers le monde.

Nous sommes présentement à la recherche de conférenciers et de conférencières avides de partager leur expertise et leur savoir dans une multitude de domaines des hautes technologies ; PHP, Ruby, Java, DotNet, JavaScript, Intelligence Artificielle, et plus encore !

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 et conférencières invitées profitent d’un traitement privilégié ; avec notamment 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 22 septembre prochain pour soumettre votre projet de présentations !

Si vous souhaitez simplement vous inscrire en tant que participant, profitez dès maintenant d’un rabais de 300$ en réservant votre inscription d'ici au 18 octobre !

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

Il y a un nouveau venu parmi les logiciels de supervision : Argos Panoptès !

Loin de la complexité des Nagios, Centreon, Icinga et autres mastodontes qui font le café, Argos Panoptès (on l’appellera Argos dans la suite de ce texte) ne surveille que des sites web, ce qui lui permet d’être bien plus simple et léger.

Argos a été développé par Alexis Métaireau pour Framasoft dans le cadre de Framaspace (du Nextcloud fourni gracieusement par Framasoft aux associations et collectifs militants).
Framasoft a fait appel à un prestataire, faute de temps disponible pour développer nous-même l’outil.

Sommaire

• Le nom
• Le cahier des charges
• Le code
• Le fonctionnement en production
• Le futur
• One more thing

Pourquoi cet outil ? Lorsque l'on prévoit de créer plein d’espace Nextcloud, il semble pertinent de les surveiller.
Et comme Framasoft prévoit de déployer jusqu’à 10 000 espaces, il fallait quelque chose qui tienne la route… ce que le Shinken de l’association ne permettait pas : trop de sondes à exécuter, trop peu de temps pour le faire et on se retrouve avec des coups de sondes pas assez fréquents, laissant les sites avec des problèmes avec de trop longs délais de détection.

Sans compter que Shinken est en Python 2, qui est obsolète depuis déjà bien longtemps.

Le passage à une nouvelle solution de supervision complète (nous lorgnons sur Icinga) étant trop chronophage pour le temps que nous avons à lui consacrer pour l’instant, nous avons préféré partir sur une solution de surveillance de sites web, suivant l’adage UNIX « un logiciel qui fait une seule chose, mais qui la fait bien ».

Mais enfin, y a déjà des outils pour ça !

Bien sûr ! Nous avons testé statping-ng et Uptime Kuma mais avec nos très nombreux sites à surveiller, cela les mettait à genoux… ou alors c’est le navigateur qui ne tenait pas : ces deux solutions affichent sur la page d’accueil l’état de tous les sites à surveiller, et avec un historique de leur état en plus. Lorsque l'on veut surveiller des centaines de sites avec au moins trois coups de sondes chacun (un pour vérifier que le site HTTP redirige bien vers la version sécurisée, un pour vérifier que la version sécurisée répond bien, et un pour vérifier l’expiration du certificat du site), ça fait énormément d’appels AJAX au serveur quand on consulte le site et soit c’est le serveur qui a du mal, soit c’est le navigateur qui peine.

Ainsi est née l’idée du développement d’une solution qui remplisse notre cahier des charges

Le nom

Argos Panoptès fait référence au géant aux cent yeux de l’antiquité grecque, « Panoptès » signifiant « celui qui voit tout ».

Le cahier des charges

Il était simple mais toutefois complet, rédigé par votre serviteur (étant adminSys et développant aussi, j’avais mon idée sur ce que je voulais déployer et ce que j’aurais voulu coder moi-même) :

• un langage simple, qui peut attirer du monde pour les contributions : Python ;
• un langage moderne : la cible était Python 3.11, à savoir la version de Debian Bookworm ;
• le support d’une base de donnée robuste : PostgreSQL ;
• une architecture agents / serveur, permettant d’ajouter des agents pour les coups de sondes au fur et à mesure de l’augmentation des besoins. Ceci pour éviter le goulot d’étranglement constaté sur Shinken (l’ajout de plus d’agents Shinken n’étant pas possible puisque Python2) ;
• une configuration simple et automatisable : l’infrastructure de Framasoft étant gérée via Salt, de même que la configuration des sondes de Shinken, il était vital de pouvoir créer la configuration des sites à surveiller de façon programmatique. Le YAML fut choisi pour cela ainsi que pour sa simplicité de lecture par un humain ;
• divers moyens de notifications, courriel et Gotify a minima.

Le code

Le code d’Argos est sur la forge logicielle de Framasoft : https://framagit.org/framasoft/framaspace/argos/.

Une suite de tests est exécutée en intégration continue, ainsi que du linting, ce qui permet d’éviter autant que possible les régressions et de maintenir un style de code uniforme.

Pour les dépendances, rien d’exotique (et c’est tant mieux !) :

• Click pour l'interface en ligne de commande ;
• FastAPI est le cadriciel qui nous permet d'exposer l'API HTTP ;
• HTTPX est utilisé pour émettre des requêtes asynchrones dans les agents ;
• Jinja gère la mise en page ;
• Pydantic est utile pour s'assurer que les données correspondent à nos attentes ;
• SQLAlchemy est l'ORM que nous utilisons pour nous connecter à notre base de données et lancer des requêtes ;
• Alembic est utilisé pour les migrations de bases de données ;
• Tenacity un petit utilitaire pour réessayer une fonction en cas d'erreur ;
• Uvicorn est l'outil utilisé pour faire tourner notre serveur ;
• Gunicorn est le serveur WSGI HTTP recommandé pour la production.

Pour aider les potentiels contributeurs, une partie du site officiel est dédiée au développement.

L’API d’Argos est auto-documentée : en installant Argos, vous aurez des pages de documentation aux formats Swagger et Redoc.

Le fonctionnement en production

Si Argos a été annoncé sur le Framablog mi-mai 2024, cela faisait déjà plusieurs mois que la version de développement était en production.

Le moins qu’on puisse dire, c’est qu’Argos tient ses promesses ! Il est rapide… très rapide !

Lors du dernier démarrage à vide d’une version de développement, Argos a lancé ses 2145 tests configurés à une vitesse impressionnante : il ne lui a fallu qu’une minute et 15 secondes pour tous les effectuer.

L’API présentant un point permettant de connaître le nombre de sondes dans chaque état (les classiques ok, warning, critical et unknown), nous avons ajouté une sonde à notre Shinken pour intégrer les résultats d’Argos dans celui-ci.

En effet, avoir un outil dédié, c’est sympa, mais si ça fait une page web de plus à consulter, c’est enquiquinant. La centralisation de la supervision au sein de Shinken permet de contourner ce problème.

Le futur

Depuis la première version et une version de micro-changements, la majeure partie des modifications s’est concentrée sur l’amélioration de la documentation, ainsi que sur la simplification de la configuration et de l’installation.

Quelques nouvelles fonctionnalités seront de la partie, réduisant quelques frictions rencontrées depuis la mise en production de la dernière version.

Les contributions sont les bienvenues (peut-être quelqu’un intégrera-t-il les notifications via Apprise ?) 😉

One more thing

Framasoft est actuellement en pleine campagne de collecte de fonds dans le cadre de la démarche de soin de nos services en ligne « Dorlotons Dégooglisons » (mais ça, vous le saviez peut-être déjà).

Merci de nous soutenir si vous le pouvez ! 🙂

VenC, un générateur libre (GPLv3) de site statique en python qui avait déjà été présenté dans une dépêche précédente, est de retour en version 3.2.2 avec tout un tas de nouvelles fonctionnalités cool qu’on va voir ici.

Sommaire

• Auto-rafraîchissement lors de la prévisualisation
• Assignation d’un thème par défaut
• Amélioration des fonctionnalités FTP
  • Transfert parallèle
  • Verbosité accrue
  • Transfert intelligent
  • Configuration FTP plus fine
• Thème par défaut
• Nouvelles balises VenC
  • Accès amélioré à des métadonnées YAML
  • Accéder à la date de la dernière publication
  • Taxonomie Avancée
• Le mot de la fin

Auto-rafraîchissement lors de la prévisualisation

Quand vous prévisualisez votre site avec venc -s vous n’avez plus besoin de tuer le processus du serveur HTTP local et de régénérer manuellement le site à chaque modification. Le mécanisme est à présent automatique et détecte lui-même un changement pour vous présenter la version à jour de votre contenu ! La cache du navigateur étant parfois capricieux, VenC vous notifie dans la sortie standard de ses actions si jamais vous avez un doute.

Assignation d’un thème par défaut

Si vous utilisez le thème par défaut concrete ou tout autre thème installé en dehors de votre projet il est possible de l’indiquer dans votre fichier de configuration. Ainsi venc -s sait comment régénérer votre site si nécessaire, et vous n’avez plus besoin d’indiquer le nom du thème installé sur votre système lorsque vous utilisez la commande venc -xb ou venc -xftp.

Amélioration des fonctionnalités FTP

De nombreuses améliorations ont été apportées, en voici quelques-unes !

Transfert parallèle

Vous pouvez maintenant définir un nombre arbitraire de connexions FTP simultanées pour le transfert de votre site en ligne. Pour un petit site, ça ne fait pas de grosse différence, mais quand comme moi votre site comporte plusieurs centaines de pages, ça fait gagner un temps fou !

Verbosité accrue

• Affichage du prompt FTP
• Affichage des commandes FTP associées à leur numéro de session

Transfert intelligent

Pour économiser de la bande passante, VenC compare les fichiers locaux avec ceux en ligne. Ce faisant, il ne réalise que les opérations d’I/O strictement nécessaires.

Configuration FTP plus fine

Vous pouvez maintenant paramétrer les options suivantes :

• ftp_encoding : VenC affichant à présent le prompt FTP du serveur, il est maintenant possible d’avoir des informations sur celui-ci, et notamment l’encodage. Avec l’option ftp_encoding, il est donc possible de configurer l’encodage de la session pour être en phase avec le serveur distant et éviter de mauvaises surprises.
• ftp_sessions : comme on l’a vu plus haut, c’est le nombre de connexions parallèles possibles.
• ftp_port : avant, pour une raison obscure et injustifiable par le bon sens, le port de la connexion FTP était codé en dur… Maintenant c’est une valeur par défaut qu’il est possible de redéfinir.

Thème par défaut

Le thème par défaut a été amélioré, notamment au niveau de l’ergonomie et de la qualité visuelle du thème. Ce nouveau thème intègre par ailleurs les nouvelles fonctionnalités de la version 3.2 !

Nouvelles balises VenC

Accès amélioré à des métadonnées YAML

Une fonctionnalité ultérieurement manquante et utile dans certains cas d’usage est de pouvoir accéder à des valeurs qui sont imbriquées dans un ou plusieurs dictionnaires YAML dans le fichier de configuration principal ou dans les métadonnées d’une publication.

Pour ce faire, quatre fonctions VenC ont été ajoutés :

• CherryPickBlogMetadata
• CherryPickBlogMetadataIfExists
• CherryPickEntryMetadata
• CherryPickEntryMetadataIfExists

Pour les champs non obligatoires ou non prédéfinis par VenC, ça permet donc en conséquence une plus grande liberté dans l’organisation du contenu YAML.

Accéder à la date de la dernière publication

Utile pour la génération de flux Atom ou RSS, récupérer la date de la dernière publication d’un fil de publication permet d’indiquer la vraie date de mise à jour du flux :

GetLastEntryTimestamp

Taxonomie Avancée

C’est la grosse fonctionnalité de cette mise à jour !

Avant la version 3.2 vous ne pouviez organiser vos publications “que” par catégories hiérarchisées. C’était déjà pas mal dans la mesure où ça permettait de créer des menus arborescents pour organiser votre contenu, mais parfois ça n’est pas suffisant. Par exemple, tout à fait au hasard, vous êtes un⋅e artiste et vous gérez votre portfolio avec VenC. Vous pourriez alors avoir un menu de la forme suivante pour organiser vos œuvres :

- Peintures
  - Huile
  - Acrylique
  - Aquarelle
- Dessins
  - Encre
  - Crayon
- Mediums Mixtes

Et comme vous êtes un⋅e bon⋅ne p'tit⋅e libriste auto-radicalisé⋅e sur Framasoft et LinuxFr vos œuvres sont en partie sous licence CC-By-SA. En partie seulement car oui, vous faites aussi des fanarts, des travaux dérivés d’œuvres sous licences propriétaires. Vous voulez donc séparer ce qui est véritablement libre de ce qui ne l’est pas. En générant par exemple ce type de menu :

# Mediums

- Peintures
  - Huile
  - Acrylique
  - Aquarelle
- Dessins
  - Encre
  - Crayon
- Mixtes

# Licences

- CC
  - By-NC-ND
  - By-SA
- Copyright
- Licence Art Libre

Ça tombe bien, c’est précisément ce que permet maintenant de faire VenC 3.2.

L’idée est la suivante : puisque l’arbre de toutes les catégories construit à partir de toutes les publications est un arbre hiérarchisé, il suffit de sélectionner une ou plusieurs branches de cet arbre pour créer nos menus et présenter notre contenu de la façon qu’il nous plaira.

Dans notre exemple précédent l’arbre hierarchisé de toutes les catégories aurait donc la forme suivante :

- Mediums:
  - Peintures:
    - Huile
    - Acrylique
    - Aquarelle
  - Dessins:
    - Encre
    - Crayon
  - Mixtes
- Licences:
  - CC:
    - By-NC-ND
    - By-SA
  - Copyright
  - Licence Art Libre

Nous sélectionnons donc les branches Mediums et Licences. Avec les nouvelles fonctions VenC qui vont bien :

• GetBlogCategoriesTreeFromBranches
• GetFlattenedBlogCategoriesFromBranches
• GetEntryCategoriesTreeFromBranches
• GetFlattenedEntryCategoriesFromBranches

Sur le thème par défaut concrete, vous pouvez ainsi avoir un nombre arbitraire de menu de catégories en configurant comme indiqué dans la documentation votre fichier de configuration principal.

À noter que même si ça n’est pas encore idéal, ce système ouvre la voie pour créer des blogs multilingues. Le brainstorming sur le sujet se passe ici. Pour l’heure, il est donc possible de tirer avantage de la taxonomie avancée pour créer des branches pour chaque langue que vous souhaitez utiliser. Avec un peu de JS vous pouvez aller plus loin pour rendre ça plus dynamique à votre convenance.

Le mot de la fin

Voilà pour cette nouvelle version !

La version 3.3 est déjà en cours de développement et vous pouvez suivre l’aventure ici. Un grand merci à Sidoine, Rollniak et Jérémy pour leur aide, leur confiance et leurs feedbacks !

Les sources GIMP des illustrations sont accessibles ici sous licences CC-By-SA

• Enhanced FTP Transfert
• Advanced Taxonomy
• Microcode

Toutes les contributions sont évidemment les bienvenues :

• Corriger, relire ou améliorer la documentation.
• Signaler des bugs ou faire des suggestions.
• Écrire du code.
• Me faire aumône pour me payer un p'tit shot de Baileys Irish Cream !