Donner à son IA la mémoire de vos contenus avec pgvector
MAJ du 12 avril 2026
Vous avez branché votre IA sur vos contenus, et pourtant elle répond à côté : dès qu'un client emploie d'autres mots que les vôtres, elle ne retrouve rien. Une mémoire qui cherche des mots, pas des idées, ne sert à rien.
Cette masterclass vous montre comment donner à votre IA une mémoire qui cherche le sens, directement dans le Postgres que vous avez déjà, sans payer une base vectorielle à part. La méthode tient en quatre gestes.
Ce que cet exercice ne peut pas casser
L'exercice se fait sur une feuille : vous ne touchez ni au code ni à votre base. Vous écrivez un tableau, rien de plus. Et quand viendra le moment du SQL, le prompt l'écrira pour vous, ligne par ligne, commentaires compris.
Ce que vous saurez faire à la fin
- Comprendre ce qu'est la recherche sémantique, et pourquoi elle bat la recherche par mots-clés pour une IA.
- Activer pgvector dans votre Postgres et créer une colonne qui stocke des vecteurs.
- Écrire la requête de similarité qui retrouve les passages les plus proches d'une question, par le sens.
- Croiser la recherche sémantique avec vos filtres classiques (droits d'accès, type de document) dans une seule requête.
- Niveau membre· le prompt prêt à coller qui génère votre script d'installation complet, calibré pour votre cas réel.
- Niveau Pro· je le mets en place avec vous, sur votre base, et je débloque vos cas en direct.
De la base qui cherche des mots à la mémoire qui cherche le sens, sans rien installer d'autre que l'extension.
Pourquoi ces quatre gestes, et dans cet ordre
La recherche sémantique a mauvaise réputation : on croit qu'il faut un service spécialisé, une infrastructure de plus, un abonnement mensuel. C'est faux. Si vous avez déjà Postgres, vous avez déjà 90 % du chemin. Il manque une extension et quatre gestes, ni plus, ni moins. Chaque geste répond à un doute précis qui bloque les gens au moment de se lancer. C'est pour ça qu'ils sont quatre, et dans cet ordre.
1Activer l'extension : votre base sait déjà le fairedoute : « est-ce que ma base sait faire ça ? »
Le premier doute, c'est de croire qu'il faut une autre base de données. Non. Postgres sait stocker et comparer des vecteurs dès qu'on lui ajoute l'extension vector (c'est le nom technique de pgvector). Une extension, c'est un module qu'on allume une fois. Sur un Postgres managé comme Supabase, ça se fait en un clic dans l'interface, section Database puis Extensions. Sur un Postgres brut, c'est une ligne de SQL. Une fois l'extension active, votre base parle le langage des vecteurs, et rien n'a changé pour le reste de vos données.
2Créer la colonne qui stocke le sensdoute : « où je range mes idées ? »
Un vecteur, c'est une liste de nombres qui représente le sens d'un texte. « Un élève qui abandonne » et « un apprenant qui décroche » donnent deux listes très proches, même sans aucun mot commun. C'est ça, la magie. Pour stocker ces listes, vous ajoutez à votre table de contenus une colonne d'un type particulier : une colonne vector. Le nombre entre parenthèses (par exemple 1024) correspond à la longueur de la liste, imposée par le modèle d'embeddings qui fabrique vos vecteurs : vous ne le choisissez pas au hasard. Cette étape ne fait que préparer le tiroir. Le remplir, c'est l'objet de vectoriser vos contenus pour le RAG.
3Écrire la requête de similaritédoute : « comment je retrouve par le sens ? »
C'est le cœur. Vous prenez la question d'un visiteur, vous la transformez elle aussi en vecteur, puis vous demandez à Postgres : donne-moi les cinq contenus dont le vecteur est le plus proche de celui-ci. Le « plus proche » se mesure avec un opérateur spécial, la distance cosinus, écrite <=>. Vous triez vos contenus par cette distance et vous gardez les premiers. En clair : vous demandez à la base les cinq passages qui parlent le plus de la même idée que la question, même si les mots diffèrent. C'est cette requête, et elle seule, qui transforme une base relationnelle en moteur de sens.
4Croiser le sens et vos règlesdoute : « et mes droits d'accès, mes catégories ? »
La quatrième étape est celle qu'aucun service séparé ne vous offre simplement. Comme vos vecteurs vivent dans la même table que le reste de vos données, vous ajoutez vos conditions habituelles à la même requête : ne cherche que les fiches process, ou seulement les documents que ce client a le droit de voir, ou uniquement les contenus publiés. Une base vectorielle externe vous obligerait à synchroniser deux mondes et à recoller les morceaux après coup. Ici, le sens et vos règles vivent ensemble. Une seule requête, une seule source de vérité.
À vous de jouer : le cahier des charges de votre mémoire
Ne touchez pas encore au code. Prenez une feuille, trois colonnes. C'est l'étape que tout le monde saute, et c'est elle qui sépare un chatbot qui répond juste d'un chatbot qui répond n'importe quoi.
Le résultat, en 30 secondes
À partir de votre seul tableau (vos types de contenus, vos filtres, une question test), le prompt vous rend un script SQL complet et commenté, prêt à coller dans votre base.
Des blocs numérotés, chacun encadré d'une phrase qui dit ce qu'il fait et d'une phrase qui dit comment vérifier. Bloc 1, activer l'extension : CREATE EXTENSION IF NOT EXISTS vector; vérifier que la requête tourne sans erreur. Bloc final, la recherche par le sens : SELECT titre FROM contenus WHERE publie = true ORDER BY embedding <=> :question LIMIT 5; vérifier que « relancer un prospect » remonte vos notes, même sans le mot exact. En bas, votre checklist en trois points : extension active, colonne créée, requête testée.
Le prompt prêt à coller
# RÔLE Tu es un ingénieur Postgres senior, spécialiste de la recherche sémantique avec pgvector. Tu es rigoureux et pédagogue : tu expliques chaque ligne que tu produis. Tu ne t'appuies QUE sur ce que je te donne. Si une information te manque (le volume de documents, le modèle d'embeddings, la longueur des vecteurs, les filtres voulus), tu me la demandes au lieu de l'inventer ou de choisir une valeur par défaut silencieuse. # CONTEXTE Je veux donner à mon IA la mémoire de mes contenus en activant la recherche sémantique dans mon Postgres existant, sans service vectoriel séparé. Je travaille sur Postgres (souvent via Supabase). Ma matière, si je l'ai déjà préparée : [collez ici votre tableau des types de contenus, des filtres à appliquer, et votre question test]. # MODE DE TRAVAIL
Le prompt vous interroge sur vos contenus et vos règles si une information manque, puis génère votre script d'installation complet : extension, colonne vectorielle, requête de similarité avec vos filtres, index adapté à votre volume, checklist de vérification. Laissez votre email, je vous l'envoie.
Vérifiez que c'est à vous
Votre chatbot doit retrouver « un apprenant qui décroche » quand un client tape « un élève qui abandonne », mais seulement dans les documents que ce client a le droit de voir. À quoi ressemble la bonne requête ?
D'abord avec vos mots, sans regarder les options :
Expliquez-le pour l'ancrer
En une phrase, à quelqu'un qui croit qu'il faut un service spécialisé pour faire de la recherche sémantique : pourquoi son Postgres a déjà 90 % du chemin ? Si vous savez le dire simplement, c'est à vous.
Ce que vous savez faire maintenant
- Expliquer pourquoi une recherche par mots-clés ne suffit pas à une IA, et ce qu'un vecteur change.
- Activer pgvector et préparer la colonne qui stockera le sens de vos contenus.
- Écrire la requête qui croise distance cosinus et filtres classiques dans un seul ordre SQL.
Une mémoire qui cherche des mots, pas des idées, ne sert à rien.
Continuez seul
Le prompt vous donne le squelette technique. Pour fabriquer les vecteurs eux-mêmes, il vous faut un modèle d'embeddings : c'est l'étape suivante.
Voyage AI, le moteur de vectorisation →Faites-le avec moi
Je mets la recherche sémantique en place avec vous, sur votre base, et je débloque vos cas en direct. Vous repartez avec une mémoire qui marche, pas avec un tutoriel de plus.