Je vous présente Tenzu, un logiciel libre de gestion de projets qui propose des tableaux Kanban en ligne collaboratif. Tenzu veut offrir une expérience de collaboration moderne, tout en restant léger à faire tourner et à utiliser.

Tenzu est sous licence AGPLv3 et n'est pas open core. Nous fournissons des recettes de déploiement sous Docker-compose et Kubernetes. Nous avons également un SaaS dont les revenus reposent sur la contribution libre.

L'équipe derrière Tenzu est une petite coopérative française nommée Biru (bonjour !).

Tenzu, anciennement connu sous le nom de Taiga-Next, est le successeur de Taiga. L'objectif derrière Taiga a été d'encourager les bonnes pratiques dans la mise en place de l'agilité au sein d'une équipe tout en restant facile à prendre en main. Tenzu reprend cette philosophie avec un outil plus moderne, qui permet par exemple l'édition collaborative en temps réel.

Dans cette dépêche, nous allons revenir plus en détail sur ce que fait Tenzu à l'heure actuelle, la stack technique, la genèse du projet ainsi que nos plans pour la suite.

Sommaire

• Tenzu, c'est quoi ?
  • Description
  • Stack technique et licence
  • L'équipe
• Comment le projet est né
  • L’héritier de Taiga
  • Reprise de Taiga Next
  • Nouveau nom et transmission
  • Transformation de la boîte et démarrage
  • Modèle financier
• Hier, aujourd'hui et demain
  • Première version
  • Améliorations apportées en 2026
  • Roadmap

Tenzu, c'est quoi ?

Description

Tenzu est actuellement une alternative à Trello. Cet outil permet d'organiser son travail, de répartir les tâches et d'en faire le suivi.

Les fonctionnalités disponibles sont :

• Espaces de travail : le logiciel s'organise autour d'un découpage par espace de travail puis par projet
• Kanban : Créez vos tableaux kanban avec des statuts personnalisables
• Cartes : une interface d'édition de cartes (appelé "story" pour l'instant) riche avec édition collaborative temps réel, commentaires, pièces jointes, commentaires, et plus à venir rapidement !
• Un thème sombre et trois langues (français, anglais, espagnol) sont disponibles
• Tout ce qui relève des cycles de développement (type SCRUM) est encore en spécification, nous sommes preneurs de testeurs motivés !

Stack technique et licence

Tenzu est une application web SPA, écrite en Angular et Django. Elle utilise django-ninja pour construire l’API et, pour ajouter de la réactivité temps-réel, nous utilisons django-channels à base de Redis et de websockets. La base de données utilisée est en PostgreSQL et l’API REST est entièrement documentée sous le standard OpenAPI.

Concernant le déploiement, l’environnement de développement tourne sous Docker et des recettes docker-compose ainsi qu’un helm-chart pour les environnements Kubernetes sont fournis par l’équipe dans la doc technique. Le helm-chart proposé est également celui utilisé pour le déploiement du SaaS officiel.

L’intégralité du logiciel est sous licence AGPL v3 et garanti sans open core. Pour l’instant nous ne sommes pas ouverts aux contributions de code, faute de ressources qui nous permettraient de mettre en place et d’encadrer une politique de contribution claire. Le fork reste évidemment possible et l’ouverture aux contributions externes est un objectif que nous souhaitons atteindre dès lors que le projet aura un socle fonctionnel plus avancé.

L'équipe

Tenzu est développé par Biru, une coopérative française créée en 2024 est dont le développement de Tenzu est l'activité principale.

L'équipe est actuellement composée de trois personnes :

• Julie Rymer (c'est moi !), co-fondatrice et qui s'occupe principalement du développement backend ;
• Paul Guichon, co-fondateur qui s'occupe principalement du développement frontend et de l'administration système ;
• Marie Jubault-Bregler, associée et notre précieuse Product Designer.

L'équipe au complet qui expose pour la première fois en 2026

Comment le projet est né

L’héritier de Taiga

BIRU, l’entreprise derrière Tenzu, était au départ une ESN (Entreprise de Services du Numérique) qui faisait du développement à la demande d'applications web. En accord avec leurs convictions personnelles, Julie et Paul ont choisi de fonder Biru sous la forme d’une SCOP, une coopérative où chaque membre peut participer aux décisions stratégiques et où les bénéfices sont répartis équitablement. Très engagés dans le libre et l'opensource, l'objectif de Paul et Julie (les fondateurs) était, à terme, de pouvoir reverser une partie de leurs bénéfices à tous les outils libres qu'ils utilisent au quotidien au sein de l'entreprise et de transitionner dès que possible pour devenir eux-mêmes éditeurs opensource, en lieu et place de leur activité d'ESN.
Tenzu est d’abord né d’un projet interne visant à servir de bac à sable didactique à une nouvelle recrue sur les technologies de l'entreprise : Django et Angular. Le projet choisi était la réécriture du frontend de Taiga 6.

Taiga est un logiciel libre de gestion de projets pensé pour être léger, facile à prendre en main et encourageant les bonnes pratiques dans la mise en place de l'agilité au sein d'une équipe. Julie et Paul sont des utilisateurs de Taiga de longue date, notamment Paul, qui a commencé à le déployer dans son équipe dès sa sortie en 2014. Taiga, dans sa version 6 actuelle, est toujours maintenu par une entreprise qui en assure le support technique, mais n'évolue plus depuis des années. La stack technique, composée de Django 3 et d’AngularJS en CoffeeScript, est vieillissante, très difficilement reprenable, et cela se ressent de plus en plus sur le produit.

Quelques années plus tôt, l’équipe de Kaleidos, auteurs originels de Taiga, avait déjà commencé une réécriture, sous la forme du projet nommé Taiga Next. Plus moderne, repensée grâce à l'expérience de leur premier logiciel et avec un fort accent mis sur l'accessibilité, Taiga Next a suscité l'engouement de la communauté Taiga dont nous faisions partie.
Taiga Next était malheureusement resté au stade de pré-alpha depuis juillet 2023, et la communication se faisait absente depuis.

Le logo de Biru embraçant celui de Taiga Next

Reprise de Taiga Next

Au bout de quelques mois, le 19 avril 2024, notre propre projet de réécriture a bien avancé et nous décidons de contacter Kaleidos pour leur présenter notre travail et vérifier auprès d'eux qu'une future communication de notre part à son sujet ne les embêterait pas. Ils nous répondent rapidement pour nous apprendre qu'ils sont activement à la recherche de repreneurs pour Taiga Next.

Nous obtenons à ce moment là une confirmation de la raison de l’arrêt de l’activité sur Taiga Next : à peu près en même temps que celui-ci, Kaleidos se lance sur Penpot, un concurrent libre de Figma pensé pour permettre une collaboration sans heurt entre développeurs et designers. En plus d'offrir une alternative opensource, Penpot résout un véritable besoin non satisfait sur le marché et le projet décolle, avec des levées de fonds à la clé. Kaleidos doit se rendre à l'évidence : il leur est impossible de continuer à travailler sur les deux projets à la fois.

Le 5 juin 2024, après avoir longuement étudié la question, nous candidatons publiquement à la reprise du projet. Fin juillet cette candidature est validée et nous commençons à travailler à temps plein dessus. La transition d'ESN à éditeur opensource est arrivée bien plus vite que prévu, pour notre plus grand bonheur.

Nouveau nom et transmission

Plusieurs échanges permettent à l’équipe espagnole de confirmer que nous partageons ses idéaux. Nos deux entreprises tiennent à ce que Taiga Next reste opensource, inclusif et simple d'utilisation. Kaleidos (d'ailleurs également une ancienne ESN devenue éditrice opensource) nous cède la propriété intellectuelle sur le code de Taiga Next, nous accorde un financement pour démarrer le projet (100 000€) et nous accompagne dans la reprise. Cette générosité totalement désintéressée a fait hausser les sourcils de plus d'une personne à qui nous l'avons comté, à commencer par notre comptable et notre avocate !

Cette reprise s'accompagne d'un changement de nom et d'identité graphique afin de ne pas empiéter sur Taiga. Taiga Next devient alors Tenzu (après un bref détour par MotherShip/MotherSheep dont nous avons conservée l'idée pour le logo), en référence aux kanjis japonais 天図 qui signifient individuellement "carte" + "céleste". (Anecdote : BIRU vient lui du mot japonais ビール, bière). Ces mots reflètent notre ambition de construire un logiciel qui pourra guider naturellement ses utilisateurs.

Taiga Next devient Tenzu

Transformation de la boîte et démarrage

Ce changement entraîne aussi un renouvellement de l'équipe. En effet, l’entreprise quitte le modèle économique de l'ESN, c'est-à-dire la vente de prestations informatiques et technologiques, pour transitionner vers un fonctionnement type "startup" où l’équipe fabrique un produit et qui implique des profils de “builders”. La prise de risque et l’incertitude associées à ce changement ne conviennent pas à tous les caractères ni à toutes les situations de vie. Nous étions six dans l'équipe à ce moment-là ; nous sommes redescendus à trois dans les mois qui ont suivi pour arriver à l'équipe actuelle.

Modèle financier

Le modèle financier de Tenzu repose sur plusieurs offres :

1. Nous mettons à disposition un SaaS rémunéré par la contribution libre : chacun décide du montant qu’il ou elle souhaite nous reverser, y compris zéro. Ce modèle permet à chacun de participer à la hauteur de ses moyens et selon son utilisation de l'outil, sans engagement respectif.
2. Nous travaillons également avec des partenaires qui proposent du support, de l’hébergement, de l'infogérance ou encore de la formation pour celles et ceux qui voudraient être accompagnés dans leur utilisation de Tenzu.

Aujourd’hui encore, nos revenus viennent uniquement des contributions et des subventions reçues pour ce projet.
Tenzu n'est pas gratuit, d'ailleurs aucun projet opensource ne l'est, mais nous avons choisi un modèle de financement qui convient à nos valeurs et nos ambitions.

Hier, aujourd'hui et demain

Première version

Notre ambition est claire : nous allons reprendre les fonctionnalités principales de Taiga en les améliorant en termes d’interface et d’expérience utilisateur, tout en conservant sa légèreté et sa simplicité. Nous avons pour objectif d’atteindre le plus rapidement possible un nombre d’utilisateurs qui nous permette de vivre de notre travail.

Nous sommes repartis de la dernière version de Taiga Next. Nous avons conservé en grande partie le backend existant mais avons dû repartir de zéro pour le frontend.

Le 30 octobre 2024, la première bêta de Tenzu sort sous la forme d'une démo en ligne, avec la mise à disposition de son code source. Nous y avons intégré les fonctionnalités cœur du logiciel : le multi-Kanban, les stories et les espaces de travail.
Le 4 mars 2025, nous sortons la documentation avec des recettes et toutes les explications nécessaires pour faire tourner Tenzu chez soi.

Le 30 septembre 2025, exactement 11 mois après la sortie de la démo, la première version stable de Tenzu sort. L’intégration du SSO ainsi que l’ajout de commentaires arrivera très vite par la suite.
Notre SaaS sera hébergé par IndieHosters, une autre coopérative impliquée dans le libre, rencontrée via le réseau Libre Entreprise et qui a choisi de participer à l'aventure.

Améliorations apportées en 2026

De gros chantiers ont été finalisés en 2026, à commencer par l’écriture collaborative.
L’éditeur existant n’a pas changé en apparence, mais désormais, lorsque deux personnes ouvrent en même temps une même story, elles voient l’avatar de l’autre apparaître et un curseur individuel dans le champ de description leur permet de suivre en temps réel toutes les modifications apportées.

Puis est arrivée la possibilité d’importer vos projets depuis Taiga. Vous pouvez désormais récupérer vos projets et leurs rôles, ainsi que le contenu de vos Kanbans avec vos statuts, stories, commentaires et pièces jointes, ainsi que réinviter automatiquement vos utilisateurs !

Un fil d'actualité a également été ajouté pour permettre d’annoncer les nouvelles versions, les maintenances et poser d’éventuelles questions aux utilisateurs.
Le design system a été complètement revu, du point de vue de l’interface comme de la technique, pour apporter plus de simplicité et d’accessibilité. C’est un premier pas vers un système de configuration dynamique du thème qui permettra aux utilisateurs de personnaliser leur expérience.

Enfin, nous avons très récemment ajouté un système de tags afin d’enrichir et catégoriser vos stories.

Roadmap

Nous continuons de travailler sur plusieurs chantiers :

• Permettre l’ajout de davantage de méta-informations sur les stories ;
• La mise en place d’une barre de recherche et de filtres ;
• La traduction communautaire, pour ajouter de nouvelles langues ;
• L’exportation de vos données au format JSON.

Et rapidement nous allons mettre en place les cycles de développement de type SCRUM, le deuxième module majeur de Taiga et celui qui lui a permis de conquérir le cœur de ses utilisateurs face à la concurrence.

Tenzu a bientôt deux ans et nous continuons de le faire évoluer avec passion. Ancien utilisateurs de Taiga aguerris ou nouveaux venus, nous vous souhaitons la bienvenue à la découverte de notre aventure.

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.