Libera Suite est une « nouvelle » suite bureautique libre pour Linux, Windows et macOS. Elle comprend actuellement un traitement de texte, un tableur, un logiciel de présentation et une visionneuse de fichiers Visio. Elle fonctionne sur votre ordinateur, sans compte, sans service en ligne et sans télémétrie. Elle sait ouvrir et enregistrer les formats de Microsoft Office et OpenDocument. Comparées à d’autres applications similaires, elle est relativement rapide à démarrer et légère.

Elle est bâtie sur les composants d’Euro-Office, le fork d’ONLYOFFICE lancé en avril par une coalition d’entreprises européennes, dont Abilian (société de l’auteur de cette dépêche), qui développe Libera Suite. Elle est en bêta publique depuis le 1ᵉʳ octobre.

Quatre applications

Une seule commande, libera, ouvre chaque document dans l’application qui lui correspond :

• Libera Words, le traitement de texte : .docx, .odt, .rtf, .txt, .md ;
• Libera Tables, le tableur : .xlsx, .ods, .csv ;
• Libera Slides, les présentations : .pptx, .odp ;
• Libera Diagrams, la visionneuse de fichiers Visio : .vsdx.

Les quatre applications partagent des fonctions comme l’export PDF, l’impression, la correction orthographique en cinq langues et la récupération du travail après un plantage.

Addition pratique: la commande libera --convert permet de convertir entre les différents formats pris en charge, ou d’exporter vers PDF. Par exemple, libera --convert *.docx -t pdf convertit un lot de documents vers PDF sans ouvrir de fenêtre. Son ergonomie est inspirée de Pandoc.

Comment l’installer

• Linux (Ubuntu 22.04, Debian 12, Fedora 36, RHEL 9 et plus récents, x86_64 et arm64) : curl -fsSL https://cdn.abilian.com/libera/install.sh | sh. Si Flatpak est présent, le script installe un paquet Flatpak qui contient tout ; sinon, il installe la commande libera.
• macOS (Apple Silicon) : brew install abilian/tap/libera, ou le même script. Homebrew fonctionne aussi sous Linux (à condition évidemment de l’avoir installé).
• Windows 10 et 11 : un installateur, sans droits d’administration.

Pour les utilisateurs et les utilisatrices de Python, Libera Suite est aussi publiée sur PyPI. Sous macOS et Windows, uvx libera suffit : au premier lancement, la commande propose de télécharger les composants d’Euro-Office. Sous Linux, un environnement Python isolé ne voit pas les liaisons GTK de la distribution : il faut passer par pipx install --python /usr/bin/python3 --system-site-packages libera.

La page d’installation de la doc donne le détail des principales méthodes d’installation ; la page autres façons d’installer couvre le reste.

Architecture

Euro-Office fournit ses outils d’édition sous forme de composants Web, écrits en JavaScript. Ces composants s’exécutent dans un moteur de navigateur et confient les conversions de fichiers, l’accès au disque et les autres aspects de l’intégration au système d’exploitation et à l’environnement graphique hôte (menus, boîtes de dialogue…) à l’application qui les héberge. Libera Suite est cette application hôte, écrite en Python. Elle affiche les composants dans le moteur de rendu web fourni par le système (WebKit sous Linux et macOS, WebView2 sous Windows) et confie les conversions de formats (y compris l’import/export de fichiers) au convertisseur d’Euro-Office.

Près de 700 tests automatisés vérifient son fonctionnement. Une partie d’entre eux ouvre de vrais documents dans ces composants et contrôle le résultat affiché.

Nous compilons nous-mêmes les composants d’Euro-Office, depuis ses sources, pour Linux, macOS et Windows. Les correctifs nécessaires sont tous publiés et expliqués. Nous avons aussi corrigé (à ce jour) 68 défauts du convertisseur dans la lecture et l’écriture des fichiers OpenDocument, repérés grâce aux fichiers de test de LibreOffice.

L’application hôte est sous licence Apache 2.0. Les composants issus d’Euro-Office / ONLYOFFICE restent sous licence AGPL 3.0.

Réseau

Libera Suite se connecte pour télécharger les composants d’Euro-Office à l’installation. Une fois par jour au plus, elle vérifie aussi si une nouvelle version existe, sans rien télécharger ; la ligne check_updates = false du fichier de configuration désactive cette vérification.

Les limites de la bêta

L’interface est en anglais. Chaque document a sa propre fenêtre, sans onglets. Microsoft Office ne voit pas les verrous de Libera Suite. L’application Diagrams est en lecture seule. Ni l’édition des PDF ni le publipostage ne sont encore disponibles. L’installateur Windows et l’application macOS ne sont pas encore signées. La page État des lieux en donne la liste complète.

Vos retours

Nous cherchons des testeurs. Le moteur de mise en page est relativement éprouvé (plus pour les formats MS-Office que pour ODF, mais on y travaille). La cause des bugs éventuels se trouve le plus probablement dans notre processus de build, de paquetage et de distribution, dans l’absence d’une police ou d’une ressource. Ces défauts se corrigent vite, à condition de les voir. Le retour le plus utile est donc un document qui s’affiche mal, joint à un ticket avec la sortie de libera --diagnose.

Tout administrateur système a croisé un jour, au détour d'un serveur, un script_final_old_v3_OK_last.py sans logs, sans historique, avec un mot de passe en clair à la ligne 42 et un commentaire # TODO: gérer les erreurs daté de 2014.

Après cinq ans de développement en parallèle de mes activités professionnelles, je publie Scrippy, un framework Python sous licence MIT pour écrire des scripts d'exploitation standardisés, robustes et prêts pour la production.

Sommaire

• • Le constat : le script d'exploitation, ce grand oublié
  • Le principe : un en-tête déclaratif
  • Un exemple vaut mieux qu'un long discours
  • Le double bénéfice
  • Les modules
  • Pas un prototype
  • Pourquoi seulement maintenant ?
  • La question qui fâche : et l'IA dans tout ça ?
  • Licence
  • Vos retours sont les bienvenus

Le constat : le script d'exploitation, ce grand oublié

Dans beaucoup d'équipes, les scripts d'exploitation sont écrits vite, chacun à sa manière, puis maintenus dans la douleur. Le cycle de vie typique est bien connu :

1. « C'est juste un petit script, je l'écris vite fait. »
2. Le petit script part en production.
3. L'auteur part en vacances (ou change d'entreprise).
4. Le script plante un dimanche à 3 h du matin.
5. L'astreinte découvre qu'il n'y a ni logs, ni historique, ni documentation, et que la configuration est codée en dur entre deux print("ici").

Le tout agrémenté d'un mot de passe qui s'affiche fièrement dans la sortie standard. Oui, hunter2, on te voit.

Le principe : un en-tête déclaratif

Avec Scrippy, un script décrit son comportement dans un en-tête déclaratif : auteur, version, description, configuration attendue, options acceptées, utilisateurs autorisés, nombre d'exécutions simultanées. Une seule instruction with dans le code suffit ensuite pour bénéficier de l'ensemble des fonctionnalités, sans écrire une seule ligne de plomberie :

• un fichier de log par exécution, avec sortie colorée sur le terminal ;
• un historique complet des exécutions (paramètres, durée, code retour) ;
• un fichier de configuration par script, chargé et validé au démarrage ;
• des options de ligne de commande analysées et validées depuis l'en-tête, avec un --help généré automatiquement (personne n'aura plus d'excuse pour ne pas RTFM) ;
• le masquage automatique des secrets dans les logs et l'historique ;
• la restriction des utilisateurs et groupes autorisés à lancer le script ;
• une limite d'exécutions simultanées, avec file d'attente ;
• un répertoire de travail temporaire par exécution, supprimé automatiquement ;
• une gestion d'erreurs propre et des codes retour exploitables par votre ordonnanceur préféré.

Un exemple vaut mieux qu'un long discours

Voici un script de surveillance de l'occupation d'un système de fichiers. Toute ressemblance de l'auteur avec un personnage des Monty Python n'est évidemment pas fortuite : on fait du Python, on a des traditions.

#!/usr/bin/env python3
"""
--------------------------------------------------------------------------------
  @author         : Luiggi Vercotti
  @date           : 2026-10-08
  @version        : 1.0.0
  @description    : Monitor filesystem usage
--------------------------------------------------------------------------------
  Configuration:
    @conf:thresholds|warning|int|false
--------------------------------------------------------------------------------
  Options:
    @args:mount-point|str|Mount point to check|1|/|||false|false
--------------------------------------------------------------------------------
"""
import shutil
import scrippy_core
from scrippy_core import logger

def main():
  with scrippy_core.ScriptContext() as _context:
    usage = shutil.disk_usage(_context.args.mount_point)
    percent = round(usage.used * 100 / usage.total, 1)
    if percent >= _context.config.get("thresholds", "warning", "int"):
      logger.warning(f"[+] {_context.args.mount_point}: {percent}% used")

if __name__ == '__main__':
  main()

Ce court script dispose déjà de --help, --version, d'un fichier de configuration validé, d'une option --mount-point validée, d'un log par exécution (--log), d'un historique (--hist), d'un mode debug (--debug) et d'un espace de travail temporaire. Le tout sans avoir vendu son âme à un fichier YAML de 800 lignes, ni avoir à relire une n-ième fois la doc de argparse, ni sans incantation mystique pour la configuration de log, ni pentacle renversé. Ni !

Le double bénéfice

D'une part, tous les scripts d'exploitation suivent le même standard : ils se lisent, s'exploitent et se maintiennent de la même façon, quel que soit leur auteur. Le script du collègue parti n'est plus une boîte noire.

D'autre part, ils s'écrivent beaucoup plus vite : inutile de recoder ces contrôles dans chaque script, on se concentre sur ce qu'il doit réellement faire. Le temps gagné peut être réinvesti dans des activités à haute valeur ajoutée, comme le troll sur systemd.

Les modules

Le cœur (scrippy-core) est complété par des modules optionnels :

• scrippy-remote : exécution distante et transferts de fichiers (SSH/SFTP, FTP/FTPS, CIFS) ;
• scrippy-api : client d'API REST, avec prise en charge d'OpenAPI ;
• scrippy-db : requêtes PostgreSQL, MySQL et SQLite ;
• scrippy-mail : envoi et lecture de courriels (SMTP, IMAP, POP3) ;
• scrippy-snmp : opérations SNMP get, walk et set ;
• scrippy-git : gestion de dépôts Git ;
• scrippy-template : génération de documents à partir de modèles Jinja2.

Pas un prototype

Scrippy n'est pas né d'un week-end pluvieux. Il tourne depuis plusieurs années en production, sur des usages bien réels. Il a donc survécu à des mises à jour, des migrations et des vendredis après-midi, ce qui constitue une forme de certification assez exigeante.

Pourquoi seulement maintenant ?

Parce que je n'étais pas satisfait de la documentation. Un outil mal documenté ou dont la documentation n'est pas à jour est un outil qu'on n'adopte pas, et, même si jusque là celà a été le cas pour Scrippy, « Use The Source, Luke » n'est pas une stratégie d'adoption. Je ne voulais pas publier un projet que d'autres ne pourraient pas s'approprier.

Dans les faits le code a toujours été publié mais n'ayant jamais fait aucune annonce l'adoption de Scrippy est relativement comparable à celle de GNU Hurd !

La question qui fâche : et l'IA dans tout ça ?

Avant que le Jihad butlérien ne se lève dans les commentaires, par souci de transparence : le code de Scrippy a été écrit par un humain, sur cinq ans.

Claude m'a aidé à remettre à plat la documentation, à l'enrichir d'un tutoriel progressif (voir la documentation pas à pas) et à maintenir à jour les README.md des dépôts. Il m'a également permis de détecter et corriger quelques bogues passés sous les radars malgré des années d'exploitation, ce qui est à la fois utile et clairement vexant.

L'IA reste un outil. Le meilleur des outils, entre les mains de quelqu'un qui ne sait pas ce qu'il fait, ne le rendra pas meilleur : un rm -rf reste un rm -rf, quelle que soit la qualité du clavier. C'est l'expérience, la compréhension du besoin et l'exigence qui font la qualité d'un projet. L'outil permet d'aller plus loin et plus vite.

Licence

Scrippy est un logiciel libre distribué sous licence MIT : vous pouvez l'utiliser, le modifier, le redistribuer et l'intégrer à vos projets, y compris commerciaux, à la seule condition de conserver la mention de copyright et le texte de la licence.

Vos retours sont les bienvenus

Si vous écrivez des scripts d'exploitation en Python, je serais ravi d'avoir vos retours, critiques comprises : la syntaxe de l'en-tête, les fonctionnalités manquantes, ou la comparaison avec ce que vous utilisez aujourd'hui.

Les rapports de bogues sont acceptés. Les trolls aussi, tant qu'ils sont de qualité (et vous pouvez y aller car mon Prumpleffer a été calibré par tTh).

L'édition 2026 de la PyConFR aura lieu à Biarritz 🌊 le week-end de la Toussaint (du jeudi 29 octobre au dimanche 1er novembre) !

La PyConFR est la conférence annuelle francophone dédiée au langage de programmation Python 🐍 et à sa communauté, entièrement gratuite car organisée par les bénévoles de l'AFPy (Association Francophone Python) avec le soutien de sponsors (voir plus bas).

Présentation de l'événement

L'événement se déroule donc sur 4 jours en se divisant en deux parties :

• 💻 Les sprints ont lieu le jeudi (29/10) et le vendredi (30/10) : il s'agit de sessions participatives de code pour travailler en groupe sur des projets open-source.
• 🎤 Les conférences et ateliers ont lieu le samedi (31/10) et le dimanche (01/11) : ce sont des présentations sur divers sujets autour de la programmation en Python ou d'horizons plus larges et des ateliers de codage participatifs.

Vous trouverez plus d'informations sur la PyConFR sur le site de l'événement.

Inscriptions

La conférence est gratuite mais l'inscription reste obligatoire, afin de nous aider à prévoir le nombre de participant·e·s et d'adapter l'événement en fonction.

Lors de votre inscription, vous pourrez aussi choisir de commander un t-shirt de l'événement (15€) et une place pour la soirée du samedi qui aura lieu à la brasserie SPOT à proximité du lieu de conférence (30€).

Inscriptions à la PyConFR 2026

Programme de l'événement

Le programme des différents sprints, conférences et ateliers qui auront lieu pendant l'événement a été publié : https://www.pycon.fr/2026/fr/schedule.html.

Vous pourrez y retrouver les descriptions complètes des interventions ainsi que les biographies des orateurs et oratrices.

Les sujets sont majoritairement en français (l'association s'adresse principalement à la communauté francophone) mais une salle de conférence est réservée aux sujets en anglais pour notre public non-francophone.

Conférences plénières

L'association, dans le but d'augmenter la diversité de l'événement, fait tenir par des femmes les trois conférences plénières proposées pendant la PyConFR.

Les conférences plénières annoncées cette année sont :

• « Typographie et code : expérimentations pour la broderie et le tricot » par Amélie Dumont, designer graphique typographe.
• « Le mot esquive, l'instrument tranche : autonomie stratégique, souveraineté numérique et l'épreuve de la cyber » par Rayna Stamboliyska, fondatrice et CEO de RS Strategy.
• « Sustaining Open Source for the Future » par Georgi Ker, vice-présidente de la Python Software Foundation.

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

Sponsoring

L'événement existe grâce aux dons des sponsors qui permettent chaque année de couvrir les différentes dépenses liées à l'organisation (locaux, assurance, captation vidéo, boissons, bourses, etc.).

Si vous, votre entreprise ou l'un de vos contact souhaite participer au financement de cet événement, vous pouvez contacter le trésorier de l'AFPy (tresorier@afpy.org) pour discuter des modalités.

Les différents niveaux de sponsoring et les contreparties associées sont détaillées sur cette page.