Comme vous l’avez peut-être entendu il y a quelques mois, le Sovereign Tech Fund a réalisé un investissement important dans le développement des logiciels de la communauté KDE. L’annonce ne donne toutefois que peu de détails sur ce que cela implique concrètement, notamment en ce qui concerne la partie mentionnant « the frameworks underlying its communication services ». Il s’avère que c’est précisément sur ce sujet que KDE e.V. a confié une mission à enioka Haute Couture. Permettez-moi de vous donner un peu plus de détails.

Quoi ? Pourquoi ?

L’objectif général de cet investissement est de rendre l’écosystème KDE plus attractif pour les entreprises et les institutions publiques. On pense bien sûr immédiatement à l’environnement de bureau (Plasma) et à une base solide pour le distribuer (KDE Linux, aujourd’hui en alpha), mais cela concerne également le domaine de la gestion des informations personnelles (PIM). De nos jours, une grande partie de la vie institutionnelle (publique ou non) consiste à gérer des e-mails, des contacts et des agendas. Nous nous sommes donc lancés dans le renforcement de Kontact, KMail, Korganizer et autres outils similaires. Plus précisément, nous souhaitons renforcer l’infrastructure sous-jacente : Akonadi et ses ressources.

Sur quoi travaillons-nous exactement en ce moment ? Je vous propose d’assister à la conférence de mes collègues à l’Akademy 2026, qui présentera nos travaux sur KDE PIM !

Le travail

Bon, vous êtes toujours là ? Alors poursuivez votre lecture pour en savoir un peu plus, même si je ne veux évidemment pas leur voler la vedette.

Nous nous concentrons sur trois axes :

• La qualité
• La prise en charge et la modernisation des protocoles
• La facilité d’utilisation et de déploiement

La qualité

Ceux qui me connaissent savent ce que cela signifie : encore plus de tests !!!

Pour être honnête, du côté du serveur Akonadi et des ressources, nous ne nous en sortons pas trop mal en matière de tests unitaires. Les bibliothèques de protocoles sous-jacentes disposent également de quelques tests unitaires. Le côté DAV est peut-être un peu faible et nous espérons y remédier, mais du côté IMAP, les choses ne sont pas si mal.

Cela dit, le produit ne disposait pas vraiment d’une suite de tests couvrant l’ensemble des composants intégrés ensemble. Ces tests sont plus coûteux et moins agréables à développer ; nous allons donc nous y atteler en reprenant un prototype réalisé il y a quelque temps par Dan Vratil. Il a beaucoup évolué, mais il gagne en robustesse grâce à une suite de tests complète couvrant IMAP et DAV.

Sans surprise, cela a permis de mettre au jour un certain nombre de bugs dont nous ignorions l’existence avant de commencer ce travail, et nous a fourni un environnement idéal pour reproduire des bugs connus de longue date qu’il était difficile de traquer jusqu’à maintenant.

Bien sûr, nous passons en revue la liste des tests ayant échoué pour corriger tout ce que nous pouvons. Certains des bugs que je détestais depuis longtemps ont déjà disparu ! Il se trouve que j’utilise la branche « master » de ces produits… je vis donc dans le futur par rapport à vous, chers lecteurs, mais je peux vous dire que l’avenir est clairement meilleur ici.

Prise en charge et modernisation des protocoles

La suite PIM prend en charge de nombreux protocoles… mais dans le cadre d’une utilisation en entreprise dans un contexte souverain (c’est-à-dire avec un certain contrôle côté serveur et l’utilisation de protocoles ouverts), IMAP4, CalDAV et iTIP (pour les invitations) sont les protocoles phares. Nous nous concentrons donc sur la modernisation de leur prise en charge.

Nous visons en particulier une meilleure prise en charge des serveurs compatibles IMAP4rev2, mais aussi de QRESYNC. Cela devrait permettre une meilleure utilisation des ressources réseau et une resynchronisation plus rapide.

Du côté DAV, nous envisageons de prendre en charge les push notifications. Cette extension n’est pas encore entièrement normalisée, mais nous serons prêts dès qu’elle le sera. Tout sera en place pour suivre l’évolution de la spécification au fur et à mesure de sa maturation. Grâce à ce travail, nous améliorerons également le code de synchronisation des ressources DAV, ce qui permettra, là encore, de réduire la bande passante réseau utilisée.

Bien entendu, la prise en charge d’iTIP bénéficie de ces deux avancées. Elle met également en évidence des problèmes liés à la prise en charge DAV, que nous corrigeons au fur et à mesure que nous les identifions.

Facilité d’utilisation et de déploiement

L’architecture d’Akonadi implique que la configuration de la solution par l’utilisateur nécessite de paramétrer un certain nombre de composants. Ce n’est pas nécessairement un problème en soi, mais nous pourrions simplifier les choses. En effet, il s’agit souvent de configurer chaque protocole manuellement et séparément.

Bien sûr, une spécification a été proposée pour prendre en charge l’autoconfiguration à partir d’une simple adresse e-mail et d’un mot de passe. Nous disposons d’une prise en charge partielle de cette fonctionnalité dans KMail, mais nous allons travailler à la parachever et à la rapprocher de l’application de réglages système de Plasma. Si l’on ajoute à cela certaines fonctionnalités de gestion des appareils (MDM), par exemple dans KDE Linux, cela commence à constituer une proposition très intéressante pour les entreprises.

Enfin, nous allons nous pencher sur la version Flatpak de la suite PIM et voir comment faciliter son intégration dans l’environnement de bureau. Les possibilités sont pour l’instant assez limitées et nous aimerions en faire une fonctionnalité de premier plan.

À quoi s’attendre

De toute évidence, pour l’instant, nous pouvons nous attendre à davantage d’activité au sein de KDE PIM, ce qui est une bonne chose. Nous avons déjà un certain nombre de correctifs dans les dépôts PIM à ce stade, et certaines de ces améliorations seront publiées très prochainement dans le cadre de la version 26.08 ! D’autres suivront bien sûr dans la prochaine version (26.12), mais elles nécessitaient encore des vérifications d’assurance qualité et n’ont pas pu être intégrées avant le freeze de la version. Quoi qu’il en soit, l’attente ne sera pas longue.

De plus, nous espérons que le déploiement et la configuration seront plus faciles lorsque nous nous attaquerons aux tâches liées à Flatpak. Nous avons vraiment hâte d’y être ! Nous espérons livrer cette fonctionnalité d’ici la fin de l’année ou début 2027. Ce qui marquerait la fin du projet pour nous.

Par la suite, j’espère que ce travail d’infrastructure attirera à nouveau davantage d’utilisateurs et de contributeurs. En effet, il reste encore du travail intéressant à faire du côté des applications, mais si la prise en charge des protocoles et la qualité du système de base sont renforcées, il sera plus facile d’expérimenter de nouvelles choses avec les applications. Moins il y aura d’obstacles à surmonter, plus l’ensemble du projet deviendra attrayant.