L'Agenda du Libre

Lieu : Cité des Sciences et de l'Industrie 75019 Paris, Pte de La Villette ou Pte de Pantin, Carrefour Numérique² niveau -1
Plan d'accès : http://osm.org/go/0BPKTMqg2?node=2371178855
Toutes les informations sont ici. Plan des salles et activités : https://samedis-du-libre.org/IMG/png/plan_cn_2024.png
Venez aider ou vous faire aider à installer et paramétrer des logiciels libres et toute distribution GNU/Linux ou Android avec les associations d'utilisateurices de Fedora, Mageia, (…)

Cet épisode du podcast du Festival des Solidarités remonte la chaîne de fabrication de l'IA, pour aborder les conséquences sociales et environnementales des IA génératives. Comment reprendre la main ? Comment penser un numérique non pas parfait, mais acceptable, sobre, choisi plutôt que subi ?

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.