Imaginez un employé qui pose une question à 14h un lundi : « combien de jours à l'avance je dois poser mes congés ? » Il cherche dans ses mails, dans le livret PDF envoyé il y a trois ans, dans le dossier partagé que personne n'entretient. Cinq minutes plus tard, il abandonne et va demander à la RH qui est déjà débordée.
Ce problème existe dans toutes les PME. Et il a une solution technique propre, qui tourne, qui cite ses sources — et qui coûte 0€ à faire tourner.
Je l'ai construit en un week-end. Voici exactement comment.
Ce qu'on va construire
Un assistant de type RAG (Retrieval-Augmented Generation) : on lui donne des documents internes (PDF, Word), il les indexe, et quand un employé pose une question, il retrouve les passages pertinents et génère une réponse en citant sa source.
La stack, 100% gratuite :
- Ollama — modèles d'IA en local (embeddings + LLM)
- Supabase — base PostgreSQL avec extension vectorielle pgvector
- Groq — API d'inférence ultra-rapide (tier gratuit)
- Transformers.js — embeddings dans le navigateur pour la démo en ligne
- React + Vite + Tailwind — interface
- Vercel — déploiement
Le résultat est accessible en ligne : rag-pme.vercel.app
L'architecture en deux chaînes
Un RAG, ce sont deux pipelines distincts qu'on confond souvent.
Chaîne A — l'ingestion (une fois par document)
Quand on donne un document au système :
-
Extraction — on récupère le texte brut page par page (avec
unpdfpour les PDFs,mammothpour les Word) - Découpage — on coupe en chunks de ~900 caractères avec un recouvrement de 150 caractères entre chunks voisins. Le recouvrement est crucial : il évite de perdre une idée coupée en plein milieu. Et surtout, chaque chunk embarque ses métadonnées : nom du fichier, numéro de page.
-
Embedding — chaque chunk est transformé en vecteur de 768 dimensions via
nomic-embed-text - Stockage — les vecteurs sont rangés dans Supabase via pgvector, avec les métadonnées
Chaîne B — la requête (à chaque question)
- Embedding de la question — même modèle qu'à l'ingestion
- Recherche par similarité — pgvector compare les vecteurs et remonte les top-3 chunks les plus proches sémantiquement
- Construction du prompt — la question + les chunks + leurs sources + une consigne stricte anti-hallucination
- Génération — le LLM répond en citant ses sources
- Affichage — des chips cliquables montrent la source et le score de similarité
La clé de tout : la métadonnée voyage avec le texte du début à la fin. Sans ça, pas de citation. Sans citation, pas de confiance. Sans confiance, pas de client.
Le code — les parties importantes
Extraction et découpage avec métadonnées
export interface Chunk {
text: string;
metadata: {
source: string; // nom du fichier
page: number; // numéro de page
chunkIndex: number;
};
}
const TARGET_CHARS = 900;
const OVERLAP_CHARS = 150;
function splitIntoChunks(text: string): string[] {
const paragraphs = text.split(/\n\s*\n|\n/).map(p => p.trim()).filter(Boolean);
const chunks: string[] = [];
let current = "";
for (const para of paragraphs) {
if (current && current.length + para.length > TARGET_CHARS) {
chunks.push(current.trim());
// Recouvrement : on repart avec la fin du chunk précédent
current = current.slice(-OVERLAP_CHARS) + " " + para;
} else {
current = current ? current + " " + para : para;
}
}
if (current.trim()) chunks.push(current.trim());
return chunks;
}
La fonction de recherche dans Supabase
create or replace function match_documents (
query_embedding vector(768),
match_count int default 3
)
returns table (
id bigint,
content text,
source text,
page integer,
similarity float
)
language sql stable
as $$
select id, content, source, page,
1 - (embedding <=> query_embedding) as similarity
from documents
order by embedding <=> query_embedding
limit match_count;
$$;
L'opérateur <=> est la distance cosinus entre vecteurs. Plus deux textes parlent de la même chose, plus leurs vecteurs sont proches, plus le score de similarité est élevé.
Le prompt anti-hallucination
const prompt = `Tu es un assistant interne d'entreprise. Réponds en français
Ă la question en te basant UNIQUEMENT sur les extraits fournis.
Pour chaque affirmation, cite la source entre parenthèses (nom du fichier et page).
Si l'information n'est pas dans les extraits, réponds :
"Je ne trouve pas cette information dans les documents disponibles."
EXTRAITS :
${context}
QUESTION : ${question}
RÉPONSE :`;
La consigne « si l'information n'est pas dans les extraits, dis-le » est non négociable. Sans elle, le LLM comble les trous et invente. Pour une PME qui consulte ses procédures RH, une réponse inventée c'est un risque juridique.
Le problème des embeddings en production
Premier piège rencontré : Ollama tourne en local, mais sur Vercel il n'y a pas de serveur local. J'ai testé plusieurs solutions :
- Hugging Face Inference API — bloqué par des restrictions réseau sur les serveurs Vercel (ENOTFOUND)
- API OpenAI embeddings — payant, même si peu cher
- Transformers.js — ✅ la solution retenue, pour les questions ET pour l'ingestion
Transformers.js fait tourner le modèle d'embedding directement dans le navigateur de l'utilisateur. Zéro API externe, zéro clé, zéro coût. La première utilisation prend 5-10 secondes (chargement du modèle ~30MB), ensuite c'est instantané et mis en cache.
L'avantage inattendu : c'est aussi un argument de confidentialité. Les embeddings se calculent localement dans le navigateur — les documents ne transitent jamais par un serveur tiers pour être vectorisés.
const IS_PROD = import.meta.env.PROD;
let _pipeline: any = null;
async function embedText(text: string): Promise<number[]> {
if (IS_PROD) {
if (!_pipeline) {
const { pipeline } = await import("@xenova/transformers");
_pipeline = await pipeline(
"feature-extraction",
"Xenova/nomic-embed-text-v1"
);
}
const output = await _pipeline(text, { pooling: "mean", normalize: true });
return Array.from(output.data) as number[];
} else {
const res = await fetch("http://localhost:11434/api/embeddings", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ model: "nomic-embed-text", prompt: text }),
});
return (await res.json()).embedding;
}
}
Même logique pour l'ingestion : le PDF est lu, découpé et vectorisé directement dans le navigateur. Seuls les vecteurs finaux sont envoyés à Supabase — pas le contenu brut du document via un serveur intermédiaire.
Ce que ça donne en pratique
Voici quelques échanges réels avec le système sur le corpus fictif "Martin & Dubois SARL" :
Question : Combien de jours à l'avance dois-je poser mes congés ?
Réponse : Toute demande de congés payés doit être déposée au minimum quatre semaines avant la date de départ souhaitée. (livret_accueil.pdf, page 2)
Question : Quel est le plafond pour un repas professionnel ?
Réponse : Le plafond de remboursement pour un repas est fixé à 25 euros. (livret_accueil.pdf, page 3)
Question : Puis-je télétravailler toute la semaine ?
Réponse : Non, le télétravail est limité à deux jours par semaine. (livret_accueil.pdf, page 4)
La bonne page remonte en tête à chaque fois, avec un score de similarité entre 62% et 75%. Les réponses sont correctes, sourcées, et le système dit clairement quand il ne sait pas.
Ce que j'aurais fait différemment
Le découpage est plus important que le modèle. J'ai passé plus de temps à tester des tailles de chunks qu'à choisir entre différents LLMs. 900 caractères avec 150 de recouvrement fonctionne bien sur de la prose française — mais c'est à régler empiriquement selon le type de document.
Les PDFs scannés sont un vrai problème. Un PDF qui est en réalité une image scannée donne 0 chunks. Il faudrait ajouter un OCR (Tesseract, ou l'API Vision d'un LLM) pour les cas réels. C'est la prochaine feature.
Tester les restrictions réseau de Vercel en amont. J'ai perdu plusieurs heures à déboguer l'échec de Hugging Face Inference API sur Vercel — une restriction réseau invisible en local. La règle : tester chaque service externe directement depuis un environnement serverless, pas depuis sa machine.
Ce qui a été ajouté depuis la première version : authentification Supabase (email/mot de passe), clé Groq déplacée côté serveur via API Route Vercel, suppression de documents depuis l'interface, et ingestion 100% client-side via Transformers.js pour contourner les restrictions réseau. Le système est maintenant prêt pour un premier client.
Pourquoi c'est vendable
Ce système résout un problème réel que chaque PME de 10 à 200 personnes a : l'information existe quelque part, personne ne sait où la trouver. La RH répond 20 fois par semaine aux mêmes questions basiques.
La démo prend 30 secondes à comprendre pour un non-technique : on pose une question, on voit la réponse, on voit la source. C'est vérifiable, c'est concret.
Et le coût de fonctionnement une fois déployé ? 0€ par mois sur le tier gratuit de Supabase + Groq + Vercel.
Pour aller plus loin
Le code source est disponible sur GitHub : github.com/sharklandy/rag-pme
La démo tourne sur : rag-pme.vercel.app
Accès démo : demo@rag-pme.fr / demo1234 — ou cliquez directement sur "Accès démo" sur la page de connexion.
Dans le prochain article : support des PDFs scannés via OCR, et activation du RLS Supabase pour une isolation complète des données par client.
Landry Lhomme — développeur junior spécialisé en intégration IA pour PME. Disponible pour des missions freelance.
GitHub : sharklandy
