PostgreSQL 19 retardé par les bugs que trouve l'IA : ce que ça change pour ceux qui l'utilisent

En une phrase : Les modèles d'IA font remonter dans PostgreSQL de vrais bugs, vieux parfois de plusieurs années, plus vite que les mainteneurs ne peuvent les corriger : la version 19 est repoussée au 19 novembre 2026, et ceux qui exploitent une base PostgreSQL ont surtout plus de correctifs de sécurité à appliquer.

PostgreSQL est un logiciel de base de données libre, très répandu dans les applications web et les logiciels métier. Il n'a pas d'éditeur : c'est un projet non commercial porté par des bénévoles, comme le rappelle sa feuille de route. Ce qui lui arrive en 2026 n'est pas le problème déjà connu des faux rapports de bugs générés par IA : ce sont de vrais défauts, en grand nombre, et c'est le temps humain pour les traiter qui manque. Cet explicatif s'appuie sur les textes de deux mainteneurs du projet et sur les pages officielles de PostgreSQL, telles qu'elles étaient en ligne le 4 novembre 2026.

Ce qui s'est passé avec PostgreSQL 19

Depuis une dizaine d'années, les versions majeures de PostgreSQL sortent entre la mi-septembre et la mi-octobre, rappelle Robert Haas, l'un des principaux contributeurs du projet, dans un billet du 30 octobre 2026. Le 10 octobre, l'équipe chargée des publications a annoncé sur la liste des développeurs que la sortie de PostgreSQL 19 passait au 19 novembre : vu le volume de corrections ajoutées aux versions déjà en service, elle veut les intégrer d'abord dans une seconde version candidate, prévue le 12 novembre.

Avant ce report, plusieurs fonctions attendues avaient été retirées de la version en préparation. Robert Haas en cite trois, retirées entre le 27 août et le 15 septembre 2026 : la modification de lignes sur une période (UPDATE/DELETE FOR PORTION OF), les requêtes de graphe en SQL (SQL/PGQ) et la fusion ou la division de partitions de tables. Peter Eisentraut, membre de l'équipe dirigeante et auteur de certaines de ces fonctions, compte « environ 8 à 10 » fonctions importantes retirées selon la façon de compter (traduction Le Latent), là où un retrait par cycle serait habituel.

Pourquoi l'IA trouve plus vite qu'on ne corrige

La réponse de Robert Haas tient en une phrase : « La réponse courte, c'est que les LLM sont arrivés » (traduction Le Latent, billet du 30 octobre). Le code de PostgreSQL est vaste et ancien : son historique remonte à plus de 30 ans. Il contient donc beaucoup de bugs, comme tout logiciel. Ce qui a changé, selon lui, c'est qu'il est devenu bien plus facile de les trouver. Les corriger aussi, mais pas dans les mêmes proportions.

Le mécanisme se comprend en trois temps :

1. Trouver devient bon marché. Un modèle de langage peut relire du code ou explorer automatiquement des combinaisons de cas inhabituels (ce qu'on appelle le fuzzing). Peter Eisentraut prend le cas d'une requête SQL qui croise des types de données personnalisés, des colonnes supprimées puis recréées, des partitions détachées et un déclencheur : personne ne peut énumérer ces combinaisons à la main, mais le test automatique assisté par IA y trouve des problèmes « très vite », écrit-il sur son blog.
2. Corriger reste humain. Les modèles savent proposer un correctif, mais il n'est pas toujours juste ni conforme aux règles du projet : il doit être relu et intégré par des personnes, qui ne sont « pas devenues plus intelligentes entre 2025 et 2026 », note Robert Haas (traduction Le Latent). C'est le même travers que les hallucinations des chatbots : une réponse plausible n'est pas une réponse vérifiée.
3. Chaque rapport a un coût fixe. Peter Eisentraut décrit une liste d'une quarantaine de rapports de défauts : même si chacun ne demande en moyenne qu'une correction de trois lignes, chaque rapport a un coût de traitement incompressible, et le temps finit par manquer (billet du 9 octobre).

Robert Haas chiffre l'effet à partir de l'historique du code, entre le 8 avril (gel des fonctions) et le 25 septembre de chaque année. Les correctifs reportés sur la version en préparation sont passés de 724 en 2025 à 1 169 en 2026, et ceux reportés aussi sur la version précédente, déjà en service, de 248 à 433, soit plus de 74 % de hausse, selon son billet. Il ne pense pas que les développeurs se soient mis à faire plus d'erreurs : beaucoup plus de gens signalent des bugs trouvés avec des modèles de langage, et les mainteneurs passent leur temps à les corriger.

Peter Eisentraut ajoute deux précisions utiles. Les fonctions retirées avaient été écrites avant que la relecture assistée par IA devienne efficace : ce n'est pas du code généré par IA, mais du code ancien jugé à une exigence relevée après coup. Et entre avril et août 2026, beaucoup de développeurs expérimentés étaient occupés à corriger des failles de sécurité, au lieu de relire la version en préparation (billet du 9 octobre).

Ce que montrent les chiffres officiels de sécurité

La page des vulnérabilités connues du projet permet de vérifier une partie du constat. Elle liste, pour les versions encore maintenues, chaque faille avec son identifiant CVE et la mise à jour qui la corrige. Le relevé ci-dessous a été fait par la rédaction le 4 novembre 2026 sur la liste officielle des vulnérabilités de PostgreSQL, en regroupant les failles par mise à jour trimestrielle.

Soit 7 failles sur les quatre mises à jour de 2025 et 44 sur les trois premières de 2026, d'après la page des vulnérabilités. La mise à jour du 13 août 2026 corrigeait aussi plus de 110 bugs ordinaires, selon son annonce, et plusieurs de ses failles permettaient d'exécuter du code sur le serveur à un utilisateur connecté.

Deux limites à garder en tête. Ni cette page ni les billets des mainteneurs ne disent combien de ces failles ont été trouvées grâce à l'IA, ce que Numerama relevait aussi le 2 novembre 2026. Et un nombre de failles mesure ce qui a été trouvé et corrigé, pas ce qui reste : une hausse peut signaler un logiciel mieux contrôlé, pas forcément plus fragile. Robert Haas le dit à sa façon : le code de PostgreSQL reste à ses yeux l'un des plus propres sur lesquels il ait travaillé.

Ce que ça change si ton entreprise utilise PostgreSQL

Si tu gères une application, un site ou un logiciel métier qui s'appuie sur PostgreSQL, en direct ou via un hébergeur, voici ce que disent les pages officielles du projet :

• Le 12 novembre 2026 est une date à noter. La mise à jour trimestrielle de ce jour-là comportera « un grand nombre de correctifs », annonce le projet dans l'annonce de la première version candidate (traduction Le Latent). Le projet recommande de toujours utiliser la dernière version mineure ; une mise à jour mineure ne demande ni export ni réimport des données, seulement un arrêt, le remplacement des binaires et un redémarrage, après lecture des notes de version, selon sa politique de versions.
• PostgreSQL 14 ne sera plus maintenu après le 12 novembre 2026. C'est sa dernière mise à jour : ensuite, plus aucun correctif, y compris de sécurité, d'après la politique de versions et l'annonce du 13 août, qui conseille de prévoir la migration. Avec le rythme de failles relevé plus haut, une version qui ne reçoit plus de correctifs devient vite risquée.
• Ne planifie pas de projet sur les fonctions retirées. Les requêtes de graphe, FOR PORTION OF et la fusion ou division de partitions ne seront pas dans PostgreSQL 19, selon Robert Haas. Peter Eisentraut pense que plusieurs reviendront « avant longtemps », sans date (son billet).
• La date du 19 novembre n'est pas garantie. L'équipe de publication la maintient « sauf problème découvert » (annonce du 15 octobre). La page de feuille de route du projet indiquait encore, le 4 novembre 2026, une version 19 « prévue pour octobre 2026 » (roadmap) : c'est l'annonce de la liste des développeurs qui fait foi.

Ce que ça dit des logiciels libres face à l'IA

Jusqu'ici, les plaintes des projets libres visaient surtout des rapports de bugs générés par IA et sans valeur. Numerama rappelle que le projet curl a fermé son programme de primes aux bugs en janvier 2026 pour cette raison, et que Google a suspendu le 1er octobre 2026 les nouvelles soumissions à son programme de récompenses pour l'open source, en invoquant une majorité de rapports automatisés non valides. Le cas de PostgreSQL est l'autre face : des rapports justes, trop nombreux pour les mains disponibles.

Les deux mainteneurs ne tirent pas la même conclusion. Pour Peter Eisentraut, la situation devrait se résorber aux prochains cycles, sauf si les capacités de relecture par IA continuent de progresser au rythme actuel, et il propose d'intégrer le test assisté par IA au développement de chaque nouvelle fonction (billet du 9 octobre). Robert Haas juge le retard de la version 19 peu inquiétant, mais pas la suite : avec quarante ans de bugs que les humains n'avaient pas trouvés, « comment allons-nous rattraper notre retard », demande-t-il, sans réponse pour l'instant (son billet, traduction Le Latent).

Le même déséquilibre vaut pour tout projet libre dont tu dépends : les agents IA qui fouillent le code sont aussi à la portée de ceux qui cherchent des failles à exploiter. Le noyau Linux en offre un cas détaillé : nous avons analysé ce que mesure l'expérience d'OpenAI qui a produit des centaines d'exploits root du noyau Linux, et ce qu'elle demande aux administrateurs. Pour une équipe, la conséquence pratique est simple : prévoir le temps d'appliquer les mises à jour de sécurité à chaque échéance, plutôt que de les laisser s'accumuler. D'autres notions de fond sont expliquées dans la rubrique Comprendre.