Following Information for Python users regarding eMudhra / emSign CA certificate security incident - Announcements - Discussions on Python.org, we have updated the Docker images of Tryton because certifi is an indirect dependency of Tryton.
It is recommended to update your deployment to use the updated images.
If you deploy Tryton using a virtual environment, it must be updated following the instructions.

1 post - 1 participant

Read full topic

Le samedi 17 octobre 2026, l’Espace Wallon de Marsannay-la-Côte a vibré au rythme d’un concert réunissant plus de 30 musiciens des Maisons Pop de Chenôve et du Centre Musical de Marsannay (CMM), partenaire fidèle de nos projets musicaux. Initialement prévu en juin, l’événement avait été reporté en raison de la canicule. Les retrouvailles sur scène […]

L’article Plus de 30 musiciens sur scène pour un concert haut en énergie ! est apparu en premier sur Les Maisons Pop de Chenôve.

Le 7 octobre 2026, la loi pour une République numérique a eu dix ans. Son article 16 dispose que les administrations « encouragent » l'utilisation des logiciels libres et des formats ouverts. Le verbe employé avait fait débat : en 2016, l'April, le CNLL et des parlementaires de tous bords réclamaient une « priorité », que la ministre et le Législateur n'ont pas retenue. Dix ans plus tard, le bilan est maigre. Les administrations achètent chaque année pour environ 1,5 milliard d'euros de logiciels à des fournisseurs extra-européens, dont au moins un milliard pour des logiciels qui ont déjà un équivalent libre. Aucune administration de l'État n'a fait massivement passer ses postes de travail sous un système libre depuis la Gendarmerie, qui avait achevé sa migration en 2014, avant même la loi (Cour des comptes, 2025).

Ce constat vient de la commission d'enquête de l'Assemblée nationale sur les dépendances structurelles du secteur numérique, présidée par Philippe Latombe (MoDem), avec Cyrielle Chatelain (Écologiste) pour rapporteure. Son rapport, adopté le 8 juillet 2026, propose notamment de renforcer l'article 16 « en passant d'une logique d'encouragement à une logique contraignante ». Reste à savoir comment. Le CNLL y répond dans une proposition qui détaille aussi ce qui peut être engagé d'ici mai 2027.

La règle proposée, que le gouvernement peut poser dès maintenant sans attendre une modification de la loi : quand une administration de l'État achète un logiciel, elle retient un logiciel libre, sauf justification écrite, publiée et examinée par l'autorité numérique de l'État. Deux mécanismes doivent empêcher cette règle de rester lettre morte. D'abord, la justification doit chiffrer le coût sur toute la durée du contrat (TCO ou coût total de possession), y compris celui d'un futur changement de fournisseur (coût de sortie). Ensuite, cette justification est examinée par ARIANE, l'autorité qui remplacera la DINUM (direction interministérielle du numérique) le 1er janvier 2027. Comme la règle ne vise que les nouveaux marchés et les renouvellements, le gouvernement fixe aussi une trajectoire pour le parc existant : les dépenses de licences propriétaires qui ont un équivalent libre (le milliard d'euros annuel cité plus haut) doivent être divisées par deux d'ici 2031 et ramenées à zéro en 2035.

• lien nᵒ 1 : Proposition du CNLL
• lien nᵒ 2 : Rapport n° 3054 de la commission d'enquête sur les dépendances structurelles du secteur numérique
• lien nᵒ 3 : Bilan : « Loi République numérique : dix ans d'« encouragements », pour quels résultats ? »
• lien nᵒ 4 : Papier conjoint franco-allemand sur la souveraineté numérique (17 juin 2026)

Sommaire

• Pourquoi l'encouragement n'a pas suffi
• La proposition du CNLL
• L'appui d'un papier franco-allemand peu connu
• Le droit et les précédents étrangers
• Quatre mesures d'ici mai 2027

Pourquoi l'encouragement n'a pas suffi

Remplacer « encourager » par « donner la priorité » ne suffirait pas sans contrôle : deux priorités écrites existent déjà, toutes deux contournées. Le ministère de la Défense s'en était donné une par directive dès 2006. Il a pourtant signé en 2009, sans appel d'offres, le contrat « open bar » avec Microsoft, reconduit en 2026. Dans l'enseignement supérieur, la loi de 2013 dispose que « les logiciels libres sont utilisés en priorité ». Il a tout de même fallu une procédure du CNLL pour que l'École polytechnique suspende, en 2025, sa migration vers Microsoft 365. Dans les deux cas, l'acheteur a décidé seul : aucune autorité extérieure ne lui demandait de justifier son choix. La dépense, elle, continue de croître : rien que par l'UGAP (la centrale d'achat public), les achats de produits Microsoft sont passés de 233 à 293 millions d'euros entre 2024 et 2025, selon la commission d'enquête.

La proposition du CNLL

• La règle. L'article 16 demande déjà aux administrations de préserver « la maîtrise, la pérennité et l'indépendance » de leurs systèmes d'information. Dans cet esprit, le gouvernement pose une règle d'achat : les administrations de l'État retiennent les logiciels libres et les formats ouverts, sauf justification écrite. Une circulaire du Premier ministre et les textes qui créent ARIANE suffisent pour cela. La règle s'applique à tout nouveau marché et à tout renouvellement. Son extension aux opérateurs de l'État, aux entreprises publiques et aux concessionnaires de service public (que propose la commission d'enquête), puis aux grandes collectivités, demandera une loi, qui pourra aussi renforcer l'article 16 lui-même.
• Les exceptions justifiées. L'acheteur qui écarte le libre indique les solutions libres qu'il a examinées et chiffre le coût sur toute la durée du contrat, sortie comprise. Il évalue aussi l'offre qu'il retient selon trois critères tirés du papier franco-allemand présenté plus bas : la possibilité de changer de fournisseur, la part de la valeur créée dans l'Union, la maîtrise de la technologie. Il joint un plan de sortie, qui dit comment l'administration pourra changer de solution à l'échéance ou en cas de coupure du service.
• Le contrôle. La justification est examinée par ARIANE avant la signature du marché ou de sa reconduction. La DINUM, à laquelle elle succède, rend déjà un avis conforme (que l'administration est tenue de suivre) sur les grands projets informatiques de l'État. Depuis le décret du 18 mars 2026, cet avis vérifie le respect de l'article 16 et couvre aussi les suites collaboratives de plus de 2 millions d'euros par an. Le mécanisme existe ; il suffit de l'étendre aux achats de logiciels. Au-dessus de 2 millions d'euros, l'avis d'ARIANE est lui aussi conforme. Pour les marchés plus petits qui dépassent les seuils européens (ceux qui imposent une procédure formalisée), l'avis est consultatif et publié. Sous ces seuils, la justification est publiée et contrôlée par sondage.
• La transparence. Les justifications sont publiées dans un registre ouvert. Chaque année, une annexe au budget mesure, ministère par ministère, la part du libre dans la dépense informatique et l'écart à la trajectoire de 2035.
• Les moyens. Examiner des justifications et conseiller des acheteurs demande du personnel. La mission logiciels libres de la DINUM n'a jamais compté plus de trois équivalents temps plein. ARIANE se dote donc d'un bureau du logiciel libre (un OSPO, pour « Open Source Programme Office »), en réseau avec celui de la Commission européenne et ceux des autres États membres. Ce bureau privilégie les logiciels libres existants et travaille avec les éditeurs et les mainteneurs qui les développent. Dans les grands marchés de support sur logiciels libres, l'État contracte directement avec l'éditeur ou le mainteneur de chaque logiciel, pour qu'une part de la dépense revienne à ceux qui le font vivre. Un fonds finance enfin la maintenance des logiciels libres dont l'État dépend.

L'appui d'un papier franco-allemand peu connu

Le 17 juin 2026, la France et l'Allemagne ont publié un papier conjoint sur la souveraineté numérique pour orienter les travaux législatifs européens. Les deux gouvernements y écrivent qu'il faut « éviter l'enfermement propriétaire ». Ils veulent des systèmes conçus pour permettre « de changer de fournisseur et de technologie dans un délai raisonnable et sans dépenses excessives ». Le texte ajoute : « Des solutions open source peuvent et devraient jouer un rôle important à cet égard. » Le gouvernement français a donc déjà souscrit à ces objectifs ; il lui reste à les appliquer à ses propres achats.

Le droit et les précédents étrangers

Sur le plan juridique, le Conseil d'État a jugé en 2011 que désigner un logiciel libre dans un marché ne favorise aucun opérateur, puisque toute entreprise peut l'adapter et le maintenir. En mars 2026, le service scientifique du Bundestag a conclu, dans un avis qu'un acheteur peut réserver un marché à l'open source si cette restriction est justifiée, proportionnée et motivée par écrit. L'avis concerne le droit allemand, mais celui-ci transpose les mêmes directives européennes sur les marchés publics que le droit français. La règle proposée remplit ces conditions : elle est justifiée par l'objet du marché (pouvoir changer de fournisseur), proportionnée (elle admet des exceptions) et motivée par écrit à chaque décision.

Dans les faits, l'Allemagne a pris de l'avance. La Thuringe inscrit une priorité au libre dans sa loi depuis 2020 ; au niveau fédéral, la loi sur l'administration électronique (EGovG) demande depuis 2024 de privilégier l'open source pour tout nouveau logiciel. Le Schleswig-Holstein, où le gouvernement du Land conduit lui-même la migration, montre qu'elle fonctionne. Sa messagerie est entièrement passée au libre en octobre 2025 ; près de 80 % des postes de son administration utilisaient LibreOffice en décembre 2025. En septembre 2026, la chancellerie du Land a fait passer ses postes de travail sous Linux.

L'Italie montre à l'inverse ce que devient une règle sans contrôle. Depuis 2012, son code de l'administration numérique oblige chaque administration à comparer les solutions avant d'acheter un logiciel, en examinant d'abord la réutilisation d'un logiciel public existant puis le logiciel libre. L'administration ne peut acheter une licence propriétaire que si aucune de ces options ne convient. Mais c'est l'acheteur qui mène la comparaison ; aucune autorité ne la relit. En 2020, la Cour des comptes italienne constatait que 16,7 % seulement des logiciels en usage dans les collectivités relevaient des options que le code déclare prioritaires. C'est ce contrôle extérieur, absent en Italie comme en France, que la proposition confie à ARIANE.

Quatre mesures d'ici mai 2027

Ces mesures relèvent de l'initiative du gouvernement et peuvent être engagées tout de suite.

1. Inscrire dans les textes qui créeront ARIANE au 1er janvier 2027 (ils ne sont pas encore parus) l'examen des justifications, le registre public et le bureau du logiciel libre.
2. Exiger dès maintenant, par une circulaire du Premier ministre, une justification écrite et publiée pour tout achat de logiciel propriétaire par l'État.
3. Créer, dans le budget pour 2027, l'annexe qui mesure la part du libre par ministère ; doter le fonds de maintenance, que la commission d'enquête propose elle aussi.
4. Défendre la même règle au Conseil de l'Union, qui prépare sa position sur le règlement européen sur le développement du cloud et de l'IA (Cloud and AI Development Act) : son article 41, dans sa rédaction actuelle qui peut encore être amendée par le Conseil et le Parlement, se contente lui aussi d'« encourager ».

Le texte complet de la proposition, avec ses références, est disponible sur le site du CNLL.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Le 20 octobre, la projection du film Oklahoma Honey, réalisé par Andrew Patterson, a été l’occasion de découvrir les coulisses de l’apiculture grâce à l’association chenevelière Des abeilles en ville. À travers cette fiction qui nous plonge dans le monde apicole américain, le réalisateur nous invite à mieux comprendre l’organisation d’une ruche, le rôle de […]

L’article « Oklahoma Honey » : le monde fascinant des abeilles à l’honneur est apparu en premier sur Les Maisons Pop de Chenôve.

Des vulnérabilités critiques ont été découvertes dans PHP qui impactent toutes les versions à partir de PHP 7.0. Ces failles ne devaient être annoncées publiquement que demain. Cependant, en raison de fuites, ceci a été devancé en urgence à aujourd'hui.

Pour plus de détails: https://www.php2shell.com/

= Si vous avez un contrat de support avec Koumbit =

Si nous gérons votre serveur ou que vous avez un hébergement partagé ou le Nextcloud mutualisé, nous avons fait le nécessaire en urgence ce matin. Les versions de PHP ayant déjà reçu les fixes de sécurité sont à jour sur vos services. Lorsque la version de PHP concernée n'a pas encore été patchée (ou est trop ancienne), nous avons avons appliqué des modifications au "php.ini" afin de mitiger ces failles et empêcher leur exploitation.

Notez que si nous ne gérons que les mises à jour de votre installation NextCloud, ceci n'est pas inclus.

= Si nous ne gérons pas votre serveur =

Assurez-vous d'appliquer le plus rapidement possible les mises à jour disponibles pour PHP!

Si votre serveur installe PHP depuis les sources Debian, notez que seules les versions 8.2 et 8.4 ont présentement reçu les fixes de sécurité. Vous pouvez vérifier l'état des mises à jour pour les deux failles ici:

• https://security-tracker.debian.org/tracker/CVE-2026-109618
• https://security-tracker.debian.org/tracker/CVE-2026-109619

Si vous installez PHP depuis les sources Sury, toutes les versions ont été patchées.

Si votre serveur utilise une version de PHP qui n'est pas encore patchée, ou qui ne le sera pas, vous pouvez modifier les options PHP comme suit dans votre php.ini afin de mitiger.

memory_limit = -1 post_max_size = 8M upload_max_filesize = 8M session.upload_progress.enabled = 0 display_errors = 0 fatal_error_backtraces = 0 expose_php = 0

Notez qu'idéalement ceci ne devrait être qu'une solution temporaire. Si votre serveur utilise une version non patchée, vous devriez planifier rapidement une mise à jour de PHP. Vous pourriez également choisir d'utiliser la version fournie par les sources Sury d'ici là: https://packages.sury.org/php/

Si vous avez des questions ou besoin d'aide à ce sujet, contactez-nous à support@koumbit.org.

Le Réseau Koumbit

Cet article est le deuxième d’une série consacrée aux bases de données graphiques et à PostgreSQL. Le premier a posé les bases: qu’est-ce qu’un graphe, ce qu’on peut modéliser comme graphe, et le paysage des systèmes graphiques. Celui-ci passe du général au spécifique: comment on interroge les graphes, pourquoi SQL peut être maladroit pour cela, et ce que SQL/PGQ change. Il s’achève sur l’implémentation PostgreSQL, les raisons de son annulation, et quelques notes sur les fonctionnalités principales encore à venir.

Les langages d’interrogation des graphes

Dans l’article précédent, nous avons terminé par l’observation que les bases de données graphiques existent sous de nombreuses formes, qu’elles diffèrent dans leur façon de stocker les graphes et les modèles de données supportés. Elles diffèrent aussi sur la manière de les interroger.

Contrairement au monde relationnel, qui s’est convergé précocement vers SQL et l’a conservé comme standard dominant pendant des décennies, l’écosystème des graphes a engendré une prolifération de langages:

• Cypher^[1], créé chez Neo4j, représente les motifs en ASCII art:
  (a:Person)-[:KNOWS]->(b:Person) ;
• Gremlin^[2], issu d’Apache TinkerPop, est impératif et basé sur des étapes:
  g.V().hasLabel('Person').out('KNOWS') ;
• PGQL^[3], d’Oracle, intègre les motifs de graphe dans une enveloppe de type SQL ;
• Et en 2024, GQL^[4] a été ratifié comme norme ISO/IEC 39075, le premier nouveau langage de requête de base de données à atteindre une standardisation ISO depuis SQL lui-même.

Pour cette série, le plus pertinent est SQL/PGQ^[5], standardisé dans SQL:2023. C’est une extension de SQL qui permet de définir des graphes à propriétés sur des tables existantes et de les interroger avec une syntaxe de motifs de type GQL/PGQL intégrée dans un SELECT standard.

À quel point SQL est-il bon pour les graphes ?

Prenons un réseau social stocké dans deux tables: person et knows.
Une requête Cypher qui cherche les amis d’amis ressemble à:

L’équivalent en SQL pur est une double jointure croisée:

Ce n’est pas mal. C’est verbeux, mais c’est expressible, le JOIN est explicite, et que ce soient deux sauts ou dix, chaque saut est conciste à écrire d’avantage de JOINs.

Essayons quelque chose de plus centré sur les graphes maintenant. Supposons que nous voulons toutes les personnes atteignables depuis Alice en cinq sauts KNOWS. En SQL/PGQ (très similaire à Cypher), c’est un seul motif:

En SQL, cela devient un peu lourd:

L’auteur encode désormais la limite de profondeur, transporte le chemin dans un tableau pour éviter les cycles, et retire la ligne racine à la fin. PostgreSQL 14 a ajouté les clauses SEARCH et CYCLE^[6] qui masquent une partie de cette gestion administrative, mais la requête reste un calcul de point fixe récursif qui arrive à produire le bon résultat.

Bien que ce soit un parcours de graphe basique, les choses deviennent encore plus complexes. Pour les plus courts chemins, il faudrait suivre la distance et faire du “pruning”. Si on demande un tracé (pas de répétition d’arêtes), il faudrait suivre les arêtes, pas seulement les sommets.

Définir et interroger un graphe en SQL/PGQ

À partir d’ici, nous utilisons un exemple plus riche, situé dans la galaxie Star Wars. Les Jedi combattaient sur des planètes, et les Sith sur des stations. Les tables de sommets sont jedi, sith, planet et station, chacune avec un id et un name, plus un title pour les combattants et une region pour les lieux. Deux tables d’arêtes, fought_on_planet et fought_on_station, contiennent chacune un identifiant source, un identifiant destination, et le nom de la bataille.

Le graphe est déclaré sur celles-ci:

Les labels regroupent des tables: force_user couvre deux tables de sommets, place en couvre deux, et fought_at couvre les deux tables d’arêtes. Le graphe ne contient aucune donnée.
Dans PostgreSQL, c’est un nouveau type de relation (RELKIND_PROPGRAPH) qui vit dans pg_class sans “heap” (table) et sans colonne propre, ce qui fait qu’il se comporte comme une vue. Cinq nouveaux catalogues (pg_propgraph_element, pg_propgraph_label et trois autres) enregistrent ses éléments, labels et propriétés.

L’interroger:

Comment fonctionne la réécriture ?

PostgreSQL n’a pas de nouveau nœud “exécuteur”. L’analyseur transforme GRAPH_TABLE en un nouveau type de “range-table”, RTE_GRAPH_TABLE. La réécriture, le même stade qui étend les vues, la remplace ensuite par une sous-requête ordinaire.
Il procède en quatre étapes:

1. Le motif est lu de gauche à droite dans une liste de motifs d’éléments: sommets, arêtes dans les deux sens, et sous-motifs imbriqués.
2. Chaque nom de variable unique devient un facteur de chemin. Une variable qui apparaît deux fois, dans un cycle qui retourne à a, partage un même facteur, et ses prédicats sont conjoints par AND.
3. Chaque expression de label est résolue vers les tables qu’elle couvre, donnant un élément de chemin par table.
4. Chaque combinaison d’éléments le long du chemin est énumérée par un DFS (recherche en profondeur d’abord) récursif. Une combinaison n’est valide que si les clés source et destination de chaque table d’arêtes relient vraiment les deux tables de sommets voisines. Chaque combinaison valide devient un JOIN entre les tables d’arêtes et de sommets sur ces clés, et toutes sont combinées par UNION ALL.

Dans notre requête, force_user a deux tables, fought_at en a deux, et place en a deux, il y a donc 2 × 2 × 2 = 8 combinaisons. Seulement deux sont valides: un Jedi sur une planète, et un Sith dans une station. La requête devient équivalente à:

À partir de ce point, le planificateur et l’exécuteur voient des jointures et une union, rien de spécifique aux graphes. Ceci a une certaine valeur car nous bénéficions des index, des statistiques, de l’interrogation parallèle et de tout ce que PostgreSQL possède — ce qui rappelle l’argument que nous faisons dans le précédent article de la série sur les bases de données graphes construites sur des systèmes matures.

Il y a ici une subtilité qui compte pour la lecture de tout benchmark comparant les deux formalismes.

Dans un motif de longueur fixe, SQL/PGQ est obligé de toucher les tables de sommets. Le motif lie les sommets, donc la jointure vers la table de sommets fait partie de la sémantique même lorsqu’aucune propriété de sommet n’est demandée, car il n’y a pas de clés étrangères (FK). Si vous modélisiez le même graphe vous-même en SQL pur et aviez seulement besoin de la traversée des arêtes, à condition d’avoir défini des FK, joindre les tables d’arêtes seules suffit.

Note: il y a un effort récent, non validé, de la part de hackers PostgreSQL pour éliminer les inner joins basés sur les clés étrangères, ce qui serait bénéfique pour la réécriture SQL/PGQ + FK sur les tables élémentaires du graphe^[7].

Ce qui est supporté et ce qui ne l’est pas

La norme recense 100 fonctionnalités. L’implémentation validée en couvrait 26. Elle supporte les motifs graphiques avec WHERE, les motifs de sommets, les motifs d’arêtes sous forme complète et abrégée, la disjonction de labels (label1|label2), les références de propriétés, GRAPH_TABLE, le DDL incluant ALTER et DROP, plusieurs labels par table élémentaire, et les vues comme tables élémentaires.

Les plus intéressantes des 74 manquantes relèvent (pour la plupart) de cinq mécanismes que la norme définit au-dessus d’un motif de base:

PostgreSQL n’est pas seul ici. Le SQL/PGQ d’Oracle est tout aussi réduit, DuckPGQ n’ajoute que ANY SHORTEST, et l’ancien PGQL d’Oracle supporte la plupart de ces fonctionnalités.

L’annulation (“git revert”)

SQL/PGQ a été validé le 16 mars 2026 pour PostgreSQL 19. Début septembre, une discussion sur pgsql-hackers concernant certains problèmes dans sa représentation/catalogue et ses dépendances d’objets s’est achevé par une décision de le retirer.
Les reviewers ont estimé qu’il devait être retiré de cette version afin que les problèmes puissent être corrigés proprement pour 20, sans la pression de la compatibilité ascendante.

La fonctionnalité devrait revenir dans une version future. La réécriture elle-même n’est pas la partie en cours de refonte, elle devrait donc survivre, inchangée, ce qui signifie que le travail supplémentaire — VLE (variable length edge), motifs multi-chemins, etc. — pourra s’appuyer sur le même socle.

Il est d’ailleurs à noter que tout cela n’a pas à être nécessairement dans le noyau. PostgreSQL n’a pas de parser hook, donc une extension ne peut pas ajouter de grammaire, et les parser hooks ont été proposés et discutés à maintes reprises sans aboutir. La dernière mention concernait la manière de publier SQL/PGQ comme fonctionnalité expérimentale^[8].
Il ne reste à SQL/PGQ que deux options: travailler dans le noyau, ou faire ce que fait Apache AGE et parser une chaîne à l’exécution ; bien sûr, la deuxième est un élément pour une extension, pas pour une fonctionnalité du noyau.
Si les extensions avaient pu étendre le parseur, cela aurait pu être construit et prouvé hors de l’arbre, puis ensuite considéré pour un module contrib ou pour le noyau. Ce n’est pas un argument en faveur des parser hooks. C’est une observation sur là où le coût de ne pas les avoir finit par peser.

La fonctionnalité que tout le monde réclame

Des morceaux manquants, l’un domine chaque conversation sur les requêtes de graphe: les arêtes de longueur variable (VLE).
C’est la fonctionnalité que les utilisatrices et utilisateurs de graphes réclament en premier, et c’est souvent la raison pour laquelle on se tourne vers un langage de requête de graphe plutôt que d’écrire des jointures. La difficulté est proportionnelle à l’échelle. Un motif borné sur deux ou trois sauts peut être fait avec une réécriture similaire vers des jointures. Un motif pouvant atteindre des centaines de sauts, ou s’exécuter de manière non bornée jusqu’à épuisement du graphe, est un problème différent avec ses propres exigences de mémoire, de terminaison et de gestion des cycles.

La norme rend cela plus difficile qu’il n’y paraît, car elle définit plusieurs mécanismes et fonctionnalités qui interagissent avec elle. Comment le motif s’étend, quels chemins comptent comme admissibles, et lesquels de ceux-ci sont retournés sont décidés indépendamment, et chaque combinaison implique une stratégie d’exécution différente. Tous les chemins sur une profondeur bornée, un seul chemin le plus court, et les extrémités atteignables distinctes sont des motifs différents dont il faut tenir compte dans la conception. Bien sûr, on NE peut PAS tout supporter, mais il est important de garder ces sémantiques en tête.

Les implémentations varient. Une approche est une nouvelle réécriture, cette fois vers des CTE récursifs, s’appuyant sur les clauses SEARCH et CYCLE et faisant beaucoup de gestion administrative directement dans la requête pour les différentes sémantiques. En bout de ligne, c’est un BFS (recherche en largeur) basé sur des ensembles exprimé sous forme de jointures ; c’est acceptable mais ce ne sera ni performant ni flexible à combiner avec d’autres fonctionnalités comme les variables de chemin.

Une autre approche étend chaque longueur possible dans son propre UNION ALL, ce qui ne peut pas gérer le cas non borné. C’est une très mauvaise idée ; Oracle fait ça. Puis il y a les stratégies au niveau de l’exécuteur: DFS avec état de chemin pour le backtracking, ou BFS exécuté directement dans l’exécuteur (tous avec de nouveaux nœuds exécuteur). Chacune est adaptée à un objectif différent, qu’il s’agisse d’accessibilité, de plus court chemin, ou d’énumération de tous les chemins possibles. L’implémentation future prendra en compte toutes celles-ci, autrement on ne peut pas considérer Postgres dans la course, en aucune manière.

Points clés

SQL/PGQ réécrit les motifs de graphe en jointures — pas de nouveaux nœuds exécuteur, pas de moteur de graphe. Le planificateur gère le reste avec les index, les statistiques et l’interrogation parallèle.

L’implémentation validée couvrait 26 des 100 fonctionnalités de la norme, de quoi prouver l’approche mais en s’arrêtant avant les problèmes difficiles. Les quantificateurs, les modes de chemin et les arêtes de longueur variable étaient intentionnellement différés.

L’annulation est lié au “timing”. Les catalogues et le suivi des dépendances nécessitent une base plus propre pour PostgreSQL 20. Le moteur de réécriture lui-même n’est pas en cours de refonte.

La gestion des arêtes de longueur variable est la fonctionnalité requise. La norme définit plusieurs mécanismes au-dessus du VLE qui impliquent différentes stratégies d’exécution — BFS basé sur des ensembles via des CTE récursives, bras UNION ALL par longueur, ou DFS/BFS au niveau de l’exécuteur avec de nouveaux nœuds. Chacune sert un objectif différent.

Sans parser hooks, SQL/PGQ doit vivre dans le noyau ou utiliser un analyseur de chaîne à l’exécution.

Et maintenant ?

Le prochain article examine les autres options de graphes dans PostgreSQL: Apache AGE, pgRouting, et le cas pratique pour ou contre chacune.
Ensuite, un benchmark comparant SQL/PGQ à Apache AGE.
Et enfin, à quoi ressemble la vision à long terme pour les requêtes de graphe dans PostgreSQL, et pourquoi la trajectoire pointe vers l’absorption des charges de travail des graphes dans les systèmes relationnels.

1. https://neo4j.com/docs/getting-started/cypher/ ↩︎

2. https://tinkerpop.apache.org/gremlin.html ↩︎

3. https://pgql-lang.org/ ↩︎

4. https://www.iso.org/standard/76120.html ↩︎

5. https://www.iso.org/standard/79473.html ↩︎

6. https://www.postgresql.org/docs/current/queries-with.html#QUERIES-WITH-SEARCH ↩︎

7. https://www.postgresql.org/message-id/CAMbWs49-v9FGX+B=tsCxUq_FPX09ZNvXjj+TaTx0m-MAVmY5TA@mail.gmail.com ↩︎

8. https://www.postgresql.org/message-id/33d590a7-4e26-41a8-acd4-51720dddf969%40eisentraut.org ↩︎

L’article MedTech et BioTech : les clés pour passer de l’innovation au marché est apparu en premier sur Telecom Valley.

L’article Azur Tech Winter 2026 est apparu en premier sur Telecom Valley.

Dans le cadre des Semaines d’Information sur la Santé Mentale, les Maisons Pop ont organisé la projection du film Au bord du monde, réalisé par Guérin van de Vorst et Sophie Muselle, en partenariat avec le Conseil Local de Santé Mentale Franco Basaglia. Ce film belge nous plonge dans le quotidien d’Alexia, infirmière stagiaire en […]

L’article Santé mentale : un ciné-débat pour ouvrir le dialogue est apparu en premier sur Les Maisons Pop de Chenôve.

Pour la quatrième année consécutive, les Maisons Pop ont accueilli le festival Les Écrans de l’Aventure, qui célébrait en 2026 sa 35ᵉ édition. Deux films en compétition ont marqué cette nouvelle édition, placée sous le signe de l’exploration et de l’aventure humaine. Une exploration souterraine au cœur de la Papouasie-Nouvelle-Guinée Plus de 100 collégiens ont […]

L’article « Festival les Ecrans de l’Aventure » : Une nouvelle édition couronnée de succès aux Maisons Pop est apparu en premier sur Les Maisons Pop de Chenôve.

BarkDog est un logiciel libre, sous licence MIT, qui transforme un Raspberry Pi et un micro USB en enregistreur de nuisances sonores. Une IA qui tourne sur la carte reconnaît aboiements, hurlements, musique ou travaux, et ne garde que les épisodes, horodatés et scellés par une empreinte SHA-256. Les voix humaines sont rendues muettes par défaut, et aucun son ne part sur Internet.

La version 1.0 vient de sortir.

• lien nᵒ 1 : site officiel
• lien nᵒ 2 : Code source (GitLab)
• lien nᵒ 3 : Notes de version 1.0
• lien nᵒ 4 : Documentation en français
• lien nᵒ 5 : Modèle YAMNet

Pourquoi

Quand une nuisance sonore se répète la nuit, la première chose qu’on vous demande est un relevé : quels jours, à quelle heure, combien de temps. Le tenir à la main est épuisant, et un dictaphone qui tourne toute la nuit produit des heures d’audio que personne n’écoute. BarkDog fait ce tri tout seul.

Fonctionnement

1. Le Pi écoute en continu, à 16 kHz, avec un filtre coupe-bas contre le ronflement électrique.
2. Toutes les demi-secondes, le modèle YAMNet de Google (521 classes de sons AudioSet, au format TensorFlow Lite) attribue un score à chaque nuisance choisie.
3. Au-delà du seuil, un épisode commence, avec les dix secondes qui précèdent. Il se termine après un calme réglable.
4. Le fichier WAV reçoit une chronologie par catégorie et une empreinte SHA-256, inscrite dans un journal CSV qui n’est jamais réécrit.

Tout tourne sur la carte. Un Raspberry Pi Zero 2 W suffit ; les Pi 3, 4 et 5 conviennent aussi.

Treize nuisances sont proposées (aboiements, hurlements, coqs, chats, musique, basses, travaux, pétards, tondeuses, deux-roues, alarmes, klaxons…), avec un seuil par nuisance si besoin. Des « sons à ignorer » annulent une détection quand ils dominent : les canards, par exemple, sont souvent confondus avec des aboiements.

Vie privée

Enregistrer les paroles d’autrui sans leur consentement est interdit (article 226-1 du Code pénal). Dès que l’IA entend une voix, BarkDog efface ce passage du fichier, avec de courts fondus, et le signale sur la frise. On peut aussi choisir d’écarter complètement un épisode composé surtout de parole.

La page web

Une page en Python pur, sans framework, sert de tableau de bord depuis un téléphone :

• écoute de chaque épisode, avec une frise par catégorie et des boutons pour sauter au bon moment ;
• journées repliables, filtres jour ou nuit, graphique par jour, exports CSV ;
• annotations (faux positif, notes) stockées à part, corbeille ;
• mode test qui affiche les scores de l’IA en direct, pour régler les seuils sans rien enregistrer ;
• interface en français et en anglais.

Côté sécurité : mot de passe haché en PBKDF2, sessions signées, protection anti-CSRF, CSP stricte, services systemd cloisonnés (l’enregistreur n’a même pas accès au réseau). La page est prévue pour le réseau local ou un VPN, pas pour une exposition directe sur Internet.

Ce que ce n’est pas

Les niveaux sont relatifs et le micro n’est pas calibré : ce n’est pas un sonomètre, et le journal ne remplace pas un constat de commissaire de justice. C’est un outil pour objectiver la répétition et les horaires, et pour arriver devant un conciliateur ou un propriétaire avec autre chose qu’une impression.

Installation

Sur Raspberry Pi OS 64 bits, avec un micro USB :

Le script installe les dépendances et le modèle, règle l’heure, demande le mot de passe de la page et crée les deux services.

Contribuer

Le développement se fait sur GitLab, avec un miroir sur GitHub. Les retours, tickets et contributions sont les bienvenus, en particulier sur les micros qui fonctionnent bien en extérieur et sur la qualité de détection selon les environnements.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Le 19 mai 2026, Survie Paris-IDF organisait une soirée intitulée "Négrophobie, violences d'État et territoires à décoloniser" avec des invité·es analysant la persistance d'un imaginaire colonial et raciste qui imprègnent les institutions de la République. Nous republions la vidéo de cette table-ronde.

L'association des Grands-parents pour le climat nous offre une tribune dans leur INFOLettre d'octobre. Nous nous intéressons aux liens de causalité entre nos actions (la prolongation de la durée de vie des appareils, le choix des logiciels libres au profit des logiciels privateurs et un refus des IA génératives étasuniennes) et la défense du climat.

itopie est invitée dans l’INFOlettre des Grands-parents pour le climat est issu du site itopie informatique.

Le PostgreSQL Global Development Group a annoncé la publication de la première Release Candidate de PostgreSQL 19. En tant que Release Candidate, la version de PostgreSQL 19 RC1 sera quasiment identique à la publication initiale de PostgreSQL 19, cependant, des corrections pourront être appliquées avant la mise à disposition de la version finale de PostgreSQL 19.

La prochaine mise à jour planifiée pour les versions supportées de PostgreSQL, prévue le 12 novembre 2026, inclura un grand nombre de correctifs. Pour cette raison, l’équipe de publication a décidé d’intégrer ces correctifs dans PostgreSQL 19 avant sa sortie officielle. Cela signifie qu’une deuxième version candidate, PostgreSQL 19 RC 2, sera publiée le même jour que cette mise à jour.

La date de publication pour la version finale de PostgreSQL 19 est prévue au 19 novembre 2026. Consulter la section Planning des publications pour plus de détails.

Mise à jour vers la RC1 de PostgreSQL 19

Pour mettre à jour votre version de PostgreSQL depuis une précédente version de PostgreSQL, vous pouvez utiliser la même stratégie que pour mettre à jour vers toute version majeure de PostgreSQL (par exemple avec la commande pg_upgrade ou pg_dump/pg_restore).

Pour plus d’information, consultez la section mise à jour de la documentation officielle : https://www.postgresql.org/docs/19/upgrading.html

Changements depuis la bêta 4

Plusieurs corrections ont été apportées à PostgreSQL 19 suite aux remontées d’utilisateurs ayant testé la bêta 4.

Dont notamment :

• Plusieurs correctifs pour REPACK (CONCURRENTLY).
• Plusieurs correctifs pour pg_plan_advice.
• Plusieurs correctifs pour les nouvelles optimisations du planificateur de requêtes qui dépendent de la possibilité qu’une expression soit NULL.
• Plusieurs correctifs concernant l’activation automatique de la réplication logique lorsque wal_level est configuré sur replica.
• Correction de l’importation des statistiques de postgres_fdw afin qu’elle s’exécute en tant que propriétaire de la table distante (foreign table) et non en tant qu’utilisateur exécutant la commande ANALYZE.
• Plusieurs correctifs pour l’autovacuum en parallèle.
• Correction de la commande COPY (query) TO … (FORMAT json) pour utiliser les noms de colonnes de la requête, y compris les alias, comme clés JSON à la place des noms de colonnes originaux de la table.

Pour la liste complète des corrections, veuillez consulter la page des tickets ouverts.

Planning des publications

Il s’agit de la première Release Candidate de la version 19. L’équipe de publication prévoit de sortir une deuxième version candidate, PostgreSQL 19 RC 2, le 12 novembre 2026. Sauf si un problème majeur nécessitant un report ou une version candidate supplémentaire est découvert, PostgreSQL 19 devrait être officiellement disponible le 19 novembre 2026.

Pour plus d’information, veuillez consulter la page Beta Testing.

Liens

• Téléchargement
• Information sur le Bêta Testing
• Note de publication de PostgreSQL 19
• Problèmes connus de PostgreSQL 19
• Soumettre un bogue
• Faire un don

288ème émission « Libre à vous ! » de l’April. Podcast et programme :

• sujet principal : Parcours libriste de Julie Rymer de BIRU : interview d’une seule personne pour parler de son parcours personnel et professionnel
• chronique d'Antanak intitulée « Jeunes et autodéfense numérique »
• chronique de Maryse Artiguelong intitulée « Ados et médias sociaux, l’interdiction ? »
• Quoi de Libre ? Actualités et annonces concernant l’April et le monde du Libre

• lien nᵒ 1 : Podcast de la 288ᵉ émission
• lien nᵒ 2 : Les références pour la 288ᵉ émission et les podcasts par sujets
• lien nᵒ 3 : Transcription
• lien nᵒ 4 : S'abonner au podcast
• lien nᵒ 5 : S'abonner à la lettre d'actus
• lien nᵒ 6 : Libre à vous !
• lien nᵒ 7 : Radio Cause Commune

Rendez‐vous en direct chaque mardi de 15 h 30 à 17 h sur 93,1 MHz en Île‐de‐France. L’émission est diffusée simultanément sur le site Web de la radio Cause Commune. Vous pouvez nous laisser un message sur le répondeur de la radio : pour réagir à l’un des sujets de l’émission, pour partager un témoignage, vos idées, vos suggestions, vos encouragements ou pour nous poser une question. Le numéro du répondeur : +33 9 72 51 55 46.

Commentaires : voir le flux Atom ouvrir dans le navigateur

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.

• lien nᵒ 1 : Site principal
• lien nᵒ 2 : Forum communautaire
• lien nᵒ 3 : Démo en ligne
• lien nᵒ 4 : Code source
• lien nᵒ 5 : Doc technique
• lien nᵒ 6 : Le site de l'entreprise

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.

Commentaires : voir le flux Atom ouvrir dans le navigateur