« PostgreSQL 19 est en retard, et c’est la faute de l’IA. » Le titre choisi par Robert Haas, développeur majeur du projet, a forcément de quoi faire réagir. Il ne signifie pourtant pas qu’une intelligence artificielle a pris le contrôle du code de PostgreSQL ou créé à elle seule une série de bugs catastrophiques.
Le problème est plus concret : des contributions et signalements assistés par des modèles de langage ont augmenté la charge de vérification au pire moment du cycle de sortie.
PostgreSQL 19 sortira le 19 novembre
Le calendrier officiel a glissé. Dans son annonce de PostgreSQL 19 RC1, le projet prévoit une deuxième version candidate le 12 novembre 2026, puis une disponibilité générale le 19 novembre.
La raison officielle formulée par l’équipe de publication est prudente : le lot de correctifs prévu pour les versions maintenues le 12 novembre doit aussi être intégré et testé dans PostgreSQL 19. Une nouvelle RC permet de valider cet ensemble avant la sortie finale.
Il serait donc excessif d’écrire que le communiqué officiel accuse l’IA. Cette lecture vient du retour d’expérience de Robert Haas, pas d’une conclusion collective publiée par PostgreSQL.
Le vrai coût des rapports générés avec un LLM
Dans son billet Postgres 19 is late, and it’s AI’s fault, Haas décrit une hausse de rapports et de propositions produits avec l’aide de modèles de langage. Certains ont révélé de vrais problèmes. D’autres semblaient plausibles, mais mélangeaient erreur réelle, hypothèse fragile et correctif incorrect.
C’est précisément là que la charge explose. Un rapport bien rédigé par une IA peut demander plusieurs heures à un mainteneur humain pour être reproduit, compris et comparé au comportement attendu. Si le correctif proposé touche une zone sensible, il faut ensuite vérifier les performances, la compatibilité et les effets de bord.
Le temps gagné par la personne qui soumet le rapport peut donc devenir du temps perdu pour ceux qui doivent le valider.
L’IA n’a pas remplacé la revue humaine
PostgreSQL reste un projet open source à forte exigence. Une modification ne rejoint pas automatiquement le produit parce qu’un outil génère un patch convaincant. Les développeurs examinent le code, discutent sa conception et le testent sur plusieurs configurations.
Cette prudence est la bonne nouvelle de l’histoire. Le retard montre que l’équipe préfère enlever ou reporter une fonctionnalité douteuse plutôt que maintenir artificiellement une date. Avec tout ça, PostgreSQL 19 ne devient pas moins fiable parce que des contributeurs utilisent des LLM. Il devient simplement plus coûteux à stabiliser lorsque la quantité de propositions augmente plus vite que la capacité de revue.
Un problème qui dépasse PostgreSQL
La situation rappelle un point souvent oublié dans les débats sur le Web et l’IA : produire du texte ou du code n’est pas la même chose que produire une information vérifiée. Notre article sur le signal commun pour refuser l’entraînement des IA montrait déjà que les standards techniques ne valent que si les acteurs les interprètent correctement. Le projet Pay Per Crawl de Cloudflare illustre, lui, le coût croissant de l’automatisation pour les éditeurs.
Dans un projet logiciel, ce coût prend la forme de temps de revue. Une IA peut aider à chercher un cas limite, écrire un test ou expliquer une portion de code. Par contre, elle ne porte pas la responsabilité de la version publiée. Cette responsabilité reste humaine.
Faut-il éviter PostgreSQL 19 au lancement ?
Pas nécessairement. Une RC supplémentaire est plutôt un signe de prudence. Les administrateurs de production devraient de toute façon tester une nouvelle version majeure avec leurs extensions, leurs sauvegardes et leurs charges réelles avant une migration.
Le calendrier à retenir est simple : RC2 le 12 novembre, version finale prévue le 19 novembre. D’ici là, les entreprises peuvent préparer leurs essais sans installer RC1 sur un système critique.
Au final, l’IA n’a pas « cassé PostgreSQL ». Elle a facilité la création de propositions dont la qualité variait fortement, puis laissé aux mainteneurs le travail difficile : déterminer ce qui était vrai, utile et suffisamment sûr pour entrer dans une base de données utilisée partout.