PostgreSQL, les 4 services qu’il rend facultatifs

Commençons par l’histoire, parce qu’elle explique tout le reste.

En 2014, une base de données spécialisée dans les documents souples était la recommandation par défaut de toute l’industrie. Il fallait, disait-on, une base à part pour stocker ce qui ne rentrait pas dans des colonnes.

Cette année-là, PostgreSQL a ajouté un format de stockage souple avec indexation complète. Le travail a été mené par un astronome professionnel de l’observatoire de Moscou, arrivé au sujet parce qu’il lui fallait une base gratuite pour étudier l’univers. En une version, l’argument principal de la base spécialisée disparaissait pour la grande majorité des usages.

LE MEME MOUVEMENT, 4 FOIS EN 12 ANS

  2014  DOCUMENTS SOUPLES
        L'argument de la base « NoSQL » tombe.

  2021  VECTEURS
        L'extension pgvector met la memoire des
        IA dans la base. L'argument de la base
        vectorielle dediee tombe pour la
        plupart des projets.

  2025  RECHERCHE PAR MOTS-CLES
        Une extension apporte le classement
        BM25, celui des vrais moteurs de
        recherche. L'argument du moteur externe
        tombe pour les catalogues et la
        documentation.

  2026  FILES DE TRAITEMENT ET GRAPHES
        Workflows resistants aux pannes dans la
        base, et syntaxe de graphe native dans
        la version 19.

➜ A chaque fois, le meme resultat. Pas la
  disparition de l'outil specialise, mais la fin
  de son caractere OBLIGATOIRE.

Ce n’est pas une prédiction, c’est un constat sur 12 ans. Et il a une conséquence directe sur ce que vous payez.

Voici pourquoi ce sujet n’est pas réservé aux techniciens.

Une entreprise qui a monté un assistant sur ses documents ces 2 dernières années paie souvent 4 choses en parallèle. La base principale, une base spécialisée pour la mémoire de l’assistant, un moteur de recherche externe et un orchestrateur de tâches. Le montage est décrit dans RAG, brancher une IA sur vos propres documents. Chacune avec son abonnement, ses accès et sa facture.

Le vrai coût n’est pas l’abonnement, c’est la synchronisation. Chaque service supplémentaire détient une copie de vos données, qu’il faut tenir à jour. Une fiche produit modifiée dans la base principale doit se propager dans le moteur de recherche, puis dans la base de vecteurs. Le jour où l’une des 3 décroche, personne ne s’en aperçoit tout de suite, et l’assistant se met à répondre avec des informations périmées.

LES 3 QUESTIONS A POSER AVANT D'AJOUTER UNE BRIQUE

  1. MA BASE ACTUELLE SAIT-ELLE DEJA LE FAIRE ?
     Depuis 2 ans, la reponse est souvent oui,
     et le prestataire ne le sait pas toujours.

  2. QUI GARDE LES 2 COPIES A JOUR ?
     Si la reponse est « un script », demandez
     ce qui se passe quand il tombe la nuit.

  3. QUE SE PASSE-T-IL SI CE SERVICE FERME ?
     Une brique payante de plus est une
     dependance de plus. Une extension ouverte
     installee chez vous n'en est pas une.

⚠ Aucune de ces 3 questions n'est technique. Ce
  sont des questions de direction, et c'est a
  vous de les poser, pas au prestataire d'y
  repondre spontanement.

La bonne nouvelle est qu’une fonction absorbée par la base ne coûte plus rien de plus. Elle s’active et elle vit dans la même sauvegarde.

Prenons le cas le plus parlant, parce qu’il concerne tout le monde et que le défaut était réel.

PostgreSQL sait chercher du texte depuis longtemps, mais son classement est faible, et pour 4 raisons précises.

POURQUOI LA RECHERCHE NATIVE CLASSAIT MAL

  1. AUCUNE NOTION DE RARETE
     Un mot banal comme « service » pesait
     autant qu'un mot rare et decisif.

  2. LA REPETITION PAYAIT
     Un long document qui repete 40 fois le
     meme mot remontait devant un texte court
     et precis.

  3. LES LONGS DOCUMENTS GAGNAIENT TOUJOURS
     Aucune correction selon la longueur.

  4. ⛔ LE PLUS GRAVE, LE TOUT OU RIEN
     Tous les mots de la question devaient
     etre presents. Un document parfait a qui
     il manque UN mot etait ecarte AVANT meme
     d'etre classe.

➜ Le point 4 est celui qui casse un assistant.
  La bonne reponse n'est pas mal classee, elle
  n'existe pas.

Une extension apporte désormais le mode de classement des vrais moteurs de recherche, qui corrige les 3 premiers points, et abandonne le tout ou rien. Elle se combine avec la recherche par le sens dans une seule requête, ce qui donne la précision des mots-clés et la souplesse du sens en même temps. C’est exactement la matière première dont a besoin l’étape de tri décrite dans reranker, ressemblant n’est pas pertinent.

⚠ Une réserve d’honnêteté. Le titre de la vidéo qui présente cette extension annonce la mort d’un concurrent bien connu. Le contenu de la même vidéo explique pourtant que ce concurrent domine un usage que l’extension ne couvre pas du tout, le filtrage de millions de lignes de journaux en temps réel. Et la vidéo est sponsorisée par l’éditeur de l’extension.

Voici l’absorption la plus récente, et celle qui nous a le plus intéressés.

Une extension ouverte, développée par Microsoft, met dans la base des traitements qui survivent à un redémarrage. Chaque étape est écrite sur le disque au fur et à mesure. Concrètement, cela couvre 4 besoins pour lesquels on installe habituellement un outil séparé.

Les tâches planifiées, sans passer par le planificateur du serveur. Les reprises automatiques après échec. Les traitements longs, lancés puis interrogés plus tard sur leur avancement. Et surtout, l’attente d’une validation humaine.

LE CAS QUI NOUS PARLE, LA VALIDATION HUMAINE

  Un traitement se lance, prepare son travail,
  puis s'ARRETE et attend un accord. Il peut
  attendre 24 heures. Pendant ce temps il ne
  consomme rien, et il survit a un redemarrage
  du serveur.

  Quand la validation arrive, il reprend
  exactement ou il s'etait arrete.

➜ C'est la forme technique exacte de la regle
  que nous appliquons a nos agents. Ce qui
  coute de l'argent, ce qui part chez des tiers
  et ce qui engage juridiquement attend un
  accord. Le reste se fait seul.

⚠ Ce qui circule sous ce nom recouvre en fait
  PLUSIEURS produits d'editeurs differents, dont
  une bibliotheque et une extension encore en
  avant-premiere. Verifier lequel on vous propose
  avant de comparer quoi que ce soit.

Le rapprochement avec nos propres règles n’est pas une coïncidence. La validation humaine avant l’irréversible est un motif qui revient partout, et c’est le sujet de fond de agent IA ou automatisation.

La version 19, attendue à l’automne 2026, ajoute une écriture de requête en forme de chemin.

Le problème qu’elle règle est concret. Pour savoir quels produits un client a commandés, il faut aujourd’hui enchaîner les liaisons entre 5 tables. Ce n’est pas difficile, c’est illisible, et ça devient ingérable quand les relations se multiplient.

La nouvelle écriture permet de décrire le chemin, du client vers ses commandes puis vers les produits. Aucune table n’est créée, on déclare simplement quelles tables portent les données et quelles tables portent les liens. Votre structure existante ne bouge pas.

LA REPONSE HONNETE DE L'AUTEUR, A GARDER

  Question  Est-ce que ca remplace une base de
            graphes dediee ?

  Reponse   Si vous en vouliez une pour ses
            performances de parcours, NON,
            l'outil dedie reste meilleur.
            Si vous en vouliez une parce
            qu'ecrire 10 liaisons en SQL est
            penible, alors OUI.

➜ C'est la formulation la plus utile du lot, et
  elle vaut pour les 4 absorptions. La base
  generaliste ne bat pas le specialiste sur son
  terrain. Elle rend le specialiste FACULTATIF
  pour tous ceux qui n'etaient pas sur ce
  terrain.

La même version apporte 2 autres choses utiles à qui exploite un site. Une commande qui récupère enfin l’espace disque libéré par les suppressions, sans bloquer la table pendant l’opération. Et la possibilité de figer un plan d’exécution rapide, pour éviter qu’une requête stable depuis un an ne ralentisse brutalement sans qu’une seule ligne de code ait changé.

Pourquoi cette place n’était pas récupérée jusqu’ici, et c’est une conséquence directe du fonctionnement interne. PostgreSQL ne modifie jamais une ligne sur place. Il écrit une nouvelle version et laisse l’ancienne derrière lui, ce qui permet à des milliers d’utilisateurs de lire et d’écrire en même temps sans se bloquer. Le revers est que l’espace mort s’accumule, et qu’il n’était jusqu’ici marqué que réutilisable, jamais rendu.

⚠ Une contrainte à connaître. L’opération réécrit la table, elle a donc besoin d’assez de place libre pour en héberger une seconde copie. Il faut de la place pour récupérer de la place.

Une question revient légitimement chez les dirigeants. Si c’est gratuit et sans propriétaire, qui répond en cas de problème ?

L’histoire de ce projet répond mieux qu’un argumentaire.

Il naît en 1986 à Berkeley, sous la direction d’un professeur qui, de son propre aveu, n’a jamais écrit une ligne de son code. En 1994, il part, l’université publie une dernière version et abandonne. Le projet est sauvé par 2 étudiants qui avaient simplement besoin d’une base pour leur recherche. Ils remplacent le langage de requête par SQL, retirent un quart du code, et la performance progresse de moitié. La publication en 1995 est, disent-ils, un à-côté.

QUI A CONSTRUIT CE QUE VOUS UTILISEZ

  Le format qui a neutralise toute une mode
  technologique   un ASTRONOME de l'observatoire
                  de Moscou

  L'acces simultane de milliers d'utilisateurs
  sans blocage    un developpeur de Krasnoyarsk

  La replication qui a fait taire les critiques
                  les equipes d'un operateur
                  japonais, apres un revirement
                  public de l'equipe en 2008

  L'organisateur du projet pendant 30 ans
                  un ancien PROFESSEUR
                  D'INFORMATIQUE
                  de lycee

⚠ Ce n'est pas une jolie histoire, c'est un
  argument de robustesse. Aucune de ces
  personnes ne pouvait etre rachetee, licenciee
  ou reorientee par un actionnaire.

Un dernier fait résume la solidité de cet entourage. En mars 2024, un ingénieur de ce projet remarque que ses connexions à distance prennent une demi-seconde de trop. La plupart des gens auraient laissé passer. Il a cherché, et il a trouvé une porte dérobée introduite dans une bibliothèque de compression par un attaquant qui avait passé 2 ans et demi à gagner la confiance du projet. ⚠ Contrairement à ce qui s’est beaucoup écrit, elle n’avait pas atteint les machines du grand public. Elle n’était présente que dans les versions de développement de quelques distributions, et c’est précisément là qu’elle a été arrêtée, avant les versions stables.

Reste ce qu’on en fait, et rien de tout cela ne justifie de bouger aujourd’hui.

Un argument auquel personne ne pense. Plus une technologie est répandue et ouverte, plus l’IA vous aide correctement dessus, tout simplement parce que les modèles ont été entraînés sur des montagnes d’exemples publics. Poser une question en français et obtenir une requête juste marche nettement mieux sur une base très répandue que sur un outil de niche. Le choix d’une technologie courante est devenu, en soi, un choix d’assistance.

Ne migrez rien. Un système qui fonctionne n’a aucune raison d’être touché parce qu’une version apporte des nouveautés. C’est la leçon des 3 solutions miracles qui ont échoué, où le changement d’outil servait presque toujours à éviter le vrai travail. Ce n’est pas un plan de travail, c’est une grille de lecture pour la prochaine décision.

QUAND RESSORTIR CET ARTICLE

  1. UN PRESTATAIRE PROPOSE D'AJOUTER UNE BRIQUE
     Demandez si la base ne le fait pas deja.
     Depuis 2 ans, elle le fait souvent.

  2. VOUS BRANCHEZ UNE IA SUR VOS DOCUMENTS
     La memoire de l'IA peut vivre dans la meme
     base que vos clients. Une copie et une
     synchronisation en moins.

  3. VOTRE MOTEUR DE RECHERCHE INTERNE DECOIT
     Le probleme est souvent le CLASSEMENT, pas
     le moteur. Regardez d'abord de ce cote.

  4. UN ABONNEMENT AUGMENTE
     C'est le meilleur moment pour verifier si
     la fonction est devenue native.

⛔ CE QUI N'EST PAS DANS LA LISTE
  Changer de base de donnees. Si vous n'etes
  pas sur PostgreSQL, ce n'est pas un motif
  suffisant pour migrer, et le cout d'une
  migration depasse largement les abonnements
  economises.

Un dernier point, et il concerne directement les agents. Quand on branche un assistant sur une base, la bonne pratique observée chez les 2 grands éditeurs est toujours la même. L’assistant se connecte avec un utilisateur de base de données dédié, et il ne voit que ce que cet utilisateur a le droit de voir. Dans une démonstration publique, l’agent répond d’abord qu’il n’y a aucune table, simplement parce que les droits n’avaient pas encore été donnés. C’est le bon comportement.

LES 3 REGLES OBSERVEES CHEZ LES 2 EDITEURS

  1. UN UTILISATEUR DEDIE, PAS UN ADMINISTRATEUR
     Ce que l'agent ne peut pas lire, aucune
     consigne ne le lui fera lire. Une regle
     ecrite dans un prompt se contourne, un
     droit de base de donnees non.

  2. LE MOT DE PASSE HORS DES FICHIERS
     L'outil REFUSE de le prendre en ligne de
     commande, ouvre une invite protegee et le
     range dans le trousseau du systeme. Il ne
     passe donc pas dans l'historique du
     terminal.

  3. UNE AUTORISATION PAR OUTIL
     L'agent demande avant d'utiliser chaque
     outil. On peut tout autoriser d'un coup,
     et l'auteur de la demonstration precise
     lui-meme qu'il vaut mieux garder la
     demande active sur ce qui MODIFIE la base.

La formulation la plus juste de tout ce dossier tient en une phrase, et elle vaut aussi bien pour les documents souples en 2014 que pour les graphes en 2026. La base généraliste ne bat pas l’outil spécialisé sur son terrain, elle le rend facultatif pour tous ceux qui n’étaient pas sur ce terrain. La plupart des entreprises n’y ont jamais été.