Il y a un problème que tout le monde rencontre dès qu'il essaie de faire travailler un agent IA sur ses propres données : le modèle ne sait pas ce que vous savez. Il connaît le monde jusqu'à sa date d'entraînement, il parle bien, mais votre catalogue produit, vos tarifs du mois, votre base de connaissances interne, vos pages FAQ — il n'en sait rien. Et quand il ne sait pas, il invente.
C'est pour résoudre ce problème qu'on a construit Pulse.
🧠 Ce qu'est vraiment RAG — et pourquoi c'est indispensable
RAG (Retrieval-Augmented Generation) est une technique simple dans sa conception et redoutablement efficace : avant de répondre, l'agent cherche dans une base de connaissance vectorielle les passages les plus pertinents pour la question posée, les injecte dans son contexte, puis génère une réponse ancrée sur ces sources.
Résultat : l'agent répond sur la base de vos données actuelles, avec citations vérifiables. Pas d'invention, pas d'hallucination sur vos tarifs ou vos conditions. S'il ne trouve rien dans la base, il le dit.
Ce n'est pas une technologie nouvelle — elle existe depuis 2020. Ce qui manquait, c'est une implémentation souveraine, maintenue, branché sur des sources hétérogènes, et intégrée dans un workflow d'agents réels. C'est ça, Pulse.
🛠 Ce que Pulse fait concrètement
Pulse est articulé en trois couches :
Crawl. Pulse sait aller chercher l'information là où elle est : une URL (page, site entier, sitemap), un document PDF uploadé, une base Notion, une API REST qui renvoie du JSON, une transcription vidéo. Le crawler tourne en continu — quand votre page produit change, Pulse le détecte et réindexe.
Extraction. Chaque contenu crawlé est découpé en chunks sémantiques (pas au caractère ni à la phrase — au sens), convertis en vecteurs via un modèle d'embedding. Ces vecteurs sont stockés dans une base PgVector hébergée chez nous en France, sur Scaleway. Aucune donnée ne transite vers un service tiers d'indexation.
Génération. Quand un agent (le nôtre ou le vôtre, via API) pose une question, Pulse fait une recherche vectorielle, récupère les N passages les plus proches, et les renvoie au LLM avec la question originale. Le LLM répond en citant ses sources — chaque affirmation est traçable.
📊 Qui utilise Pulse en interne
La majorité de nos produits s'appuient sur Pulse :
- Support l'utilise comme base de connaissance : quand l'agent répond à un client, il cherche d'abord dans les sources indexées (FAQ, guides, conditions) avant de formuler sa réponse.
- Reach s'en sert pour qualifier les prospects : quand Reach génère un email personnalisé, il peut aller chercher dans la base de connaissance du client pour adapter l'accroche.
- Notre dashboard interne l'utilise pour les agents de monitoring : « quel est le statut du pipeline de tel repo ? » — la réponse est extraite en live de l'API GitLab, stockée dans Pulse, interrogeable par n'importe quel agent.
Ce n'est pas un outil qu'on a construit pour en faire un produit — c'est un outil qu'on a construit parce qu'on en avait besoin, et qu'on a décidé d'exposer parce que les autres en ont besoin aussi.
Et pour vous ?
Si vous avez une documentation existante (Notion, site, PDFs, base de support) et que vous voulez qu'un agent IA puisse l'interroger avec précision — sans hallucination, sans entraîner un modèle, sans exposer vos données à un tiers — c'est le bon moment pour regarder Pulse.
L'intégration via API prend quelques heures. Le crawler peut démarrer sur une liste d'URLs aujourd'hui. Et si vous utilisez déjà notre produit Support, Pulse est inclus dans le plan.
À très vite, Julien