La sortie de PostgreSQL 19 est reportée après la détection par des outils de relecture de code IA de plus de bogues que les humains ne peuvent en corriger

Le lancement de PostgreSQL 19, initialement prévu pour l'automne, a été repoussé au 19 novembre 2026. Motif: des outils de relecture de code IA ont détecté plus de bogues que les humains ne peuvent en corriger. C'est l'un des premiers exemples publics où l'utilisation de l'intelligence artificielle a directement provoqué le décalage du calendrier de sortie d'un logiciel d'infrastructure critique.

Des contributeurs clés (comme Robert Haas ou Noah Misch) ont soumis des commits ou des patchs à des LLM (comme Claude d'Anthropic ou Opus 5). L'IA a instantanément détecté une multitude de failles d'architecture profondes, de défauts de concurrence et de bugs de cas limites ("edge cases"). Ces anomalies auraient normalement mis des années à faire surface en production.

Face à ce flux de rapports, les développeurs humains se sont retrouvés submergés (la charge fixe pour trier, reproduire et corriger chaque bug — même pour une correction mineure de trois lignes — demande un temps précieux). Pour préserver la légendaire stabilité du SGBD, l'équipe a dû retirer entre 8 et 10 fonctionnalités majeures (telles que les requêtes de graphes SQL/PGQ, GROUP BY ALL ou ALTER TABLE MERGE/SPLIT PARTITION) pour les reporter à Postgres 20.


Le cas PostgreSQL 19 fait suite à de similaires qui illustrent que l'IA déplace le goulot d'étranglement de la phase de détection vers la phase de correction

L'intégration généralisée des outils d'analyse statique et de fuzzing pilotés par l'IA (comme Google OSS-Fuzz combiné à des LLM) a provoqué une saturation des équipes de maintenance informatique. À titre d'exemple, le patch d'août 2026 pour PostgreSQL 18 a dû traiter d'un coup 28 vulnérabilités CVE, un volume anormalement élevé induit par ces tests automatisés par l'intelligence artificielle.

En effet, il y a la question de la légitimité de l’inflation des vulnérabilités CVE découvertes par ces outils IA, comme l’illustre le cas du noyau Linux. Le nombre de vulnérabilités frôle désormais les 2000 CVE par version du noyau Linux. Cette hausse spectaculaire est en partie due au fait que la communauté du noyau Linux est devenue sa propre autorité de numérotation des CVE (CNA). Elle attribue un identifiant CVE à presque n'importe quel bogue au motif qu'un défaut système peut potentiellement être exploité. Beaucoup critiquent cette politique qui mélange des failles critiques réelles et des anomalies mineures, forçant Canonical à accélérer son cycle pour des correctifs parfois superflus.

L’impact pour équipes de sécurité seniors est qu’elles passent tout leur temps à trier les "faux positifs" et à corriger les failles réelles au détriment du développement de nouvelles fonctionnalités.

De plus, dans les systèmes distribués complexes (comme les bases de données distribuées à l'instar de FoundationDB ou TigerBeetle), les ingénieurs utilisent désormais l'IA pour coder et orchestrer des frameworks de Deterministic Simulation Testing (DST).

La conséquence est que l'IA simule des scénarios réseau extrêmes (ex: coupure réseau microseconde exacte au moment d'une écriture sur disque avec un crash de nœud). Cela génère des centaines de violations de consensus impossibles à reproduire manuellement, forçant le gel ou le report de versions logicielles majeures le temps de réécrire des pans entiers de l'architecture.


Quelles leçons pour la filière IT dans son ensemble?

Le cas de Postgres 19 sert de cas d'école mondial pour la gouvernance de la qualité logicielle à l'ère de l'IA. En effet, automatiser la révision du code avec l'IA augmente mécaniquement la charge de travail des développeurs en aval. Les managers IT ne doivent pas seulement planifier le temps de codage, mais allouer un budget temps bien plus large pour le tri et la remédiation des alertes IA. Le récent exemple de la Bank Of America l’illustre. L’institution financière a recruté 1000 prestataires pour corriger les failles logicielles mises en évidence par Mythos d'Anthropic.

La décision de l'équipe PostgreSQL de reporter sa version majeure et de sacrifier ses fonctionnalités phares prouve qu'un projet mature préfère assumer un retard plutôt que de livrer du code potentiellement instable. La filière des technologies de l’information doit apprendre à utiliser l'IA comme un outil de rigueur et non comme un accélérateur aveugle.

Source: Annonce officielle du report de la sortie de PostgreSQL 19

Et vous ?

Que pensez-vous de l’utilisation de l’intelligence artificielle pour la découverte des failles logicielles ? Comment cela affecte-t-il vos flux de travail d’entreprise ? Partagez vos anecdotes.

Voir aussi :

La Fondation Linux lance l'initiative Akrites, qui vise à coordonner la divulgation et la correction des vulnérabilités des logiciels open source, alors que l'IA accélère la découverte de ces vulnérabilités
Linux fixe les règles en matière de code généré par IA : oui à Copilot, les humains endossent les erreurs. Après des mois de débats acharnés, Torvalds et les mainteneurs parviennent à un accord
Apocalypse des bogues : l'IA détecte les failles logicielles plus rapidement que les équipes de sécurité de Microsoft ne parviennent à les corriger, la dette technique du code hérité suscite des inquiétudes