Blog¶

Reranker RAG : Cohere, BGE, Jina, Voyage comparés

Le retrieval hybride récupère les bons chunks. Le reranker les met dans le bon ordre.

Vous avez implémenté un retrieval hybride BM25 + vectoriel. Votre recall@10 est correct. Pourtant, le LLM produit des réponses médiocres : l'information pertinente est bien dans les 10 chunks remontés, mais elle est au rang 8 ou 9. Le LLM l'ignore ou la dilue dans le bruit des chunks du dessus.

C'est le problème que le reranker résout. Pas le recall, la précision. Pas "trouver", mais "mettre en premier ce qui compte".

Dans cet article, je compare les quatre rerankers les plus utilisés en production (Cohere, BGE, Jina, Voyage) avec les arrivants notables de 2025-2026, les chiffres de benchmark publics, les prix réels, et une recommandation directe par profil de projet.

Sécuriser un RAG : injection, fuites de données, RBAC

Sécuriser un RAG, c'est plus simple qu'un audit de sécurité classique, et plus difficile qu'on le croit

Un RAG en production, c'est trois composants qui s'enchaînent : un retriever qui cherche dans vos documents, un contexte injecté dans un prompt, un LLM qui génère une réponse. Chacun de ces trois maillons est un vecteur d'attaque distinct. Ignorer l'un des trois, et votre système est vulnérable, même si les deux autres sont parfaitement sécurisés.

La bonne nouvelle : la moitié des garde-fous ne coûtent rien. La mauvaise : l'autre moitié demande une vraie refonte architecturale si vous n'y avez pas pensé dès le début.

Systèmes multi-agents : ce qui marche vraiment

Un système multi-agents, c'est bien souvent la première architecture qu'on envisage. Plusieurs agents spécialisés, un orchestrateur qui distribue les tâches, des hand-offs propres entre les rôles. Sur le papier, c'est élégant.

En production, c'est une autre histoire.

Les systèmes multi-agents échouent entre 41 % et 86,7 % du temps selon le framework utilisé, d'après l'étude MAST publiée par UC Berkeley en mars 2025 sur 1 600 traces d'exécution. Et quand ils échouent, le problème vient rarement du modèle lui-même : il vient de l'architecture.

Voici ce que les données disent réellement, et comment décider si vous avez besoin de plusieurs agents ou d'un seul bien équipé.

Outil IA sur mesure : aller au-delà de ChatGPT

Introduction : pourquoi on me contacte de plus en plus

Ces derniers mois, de plus en plus d'entreprises me contactent avec le même constat : "On utilise ChatGPT, c'est pratique, mais ça ne règle pas vraiment nos problèmes du quotidien."

Et je les comprends. ChatGPT, Claude et les autres plateformes généralistes sont d'excellents outils. Anthropic pousse même le concept encore plus loin avec Cowork, qui se veut hyper pratique et s'utilise directement au bureau pour nous aider dans nos tâches. Mais malgré tous ces efforts, il reste un problème de fond : dans un métier, ce qu'on veut automatiser, ce sont souvent des tâches très ciblées. Et c'est exactement là que les plateformes généralistes deviennent moyennement utiles.

CrewAI, LangGraph, AutoGen, Pydantic AI : comparatif 2026

Tous les trois mois, un nouveau framework d'agents IA sort en faisant la une de Reddit et de Hacker News. CrewAI. LangGraph. AutoGen. Pydantic AI. Smolagents. Et maintenant Mastra, Agno, Letta, OpenAI Agents SDK, Inferable... La liste grossit chaque trimestre.

La question que tout le monde pose : lequel choisir ?

Le piège, c'est de croire qu'il y a un "meilleur framework". La vérité, c'est que ces outils ne s'adressent pas au même public. Et certains ne sont franchement pas faits pour des data scientists sérieux qui veulent comprendre, optimiser et maîtriser ce qu'ils construisent.

Dans cet article, je vais passer en revue les cinq frameworks principaux avec leurs forces réelles, leurs faiblesses concrètes, et le public auquel chacun s'adresse honnêtement. Plus quelques outsiders à connaître. Et une recommandation directe sur ce que je choisis sur mes missions.

Comment fonctionne la mémoire de ChatGPT et Claude

Comment ChatGPT fait pour se souvenir de vous d'une conversation à l'autre ?

Ce n'est pas le modèle d'IA en lui-même. Le modèle, il ne change pas, il ne vous connaît pas. Ce qui retient les infos, c'est une couche posée par-dessus, ce qu'on appelle la mémoire long terme. Et chaque outil la gère différemment.

LLM-as-a-judge : quand l'utiliser, avec le coût réel en €

Ce qu'est un LLM-as-a-judge, en une phrase citable

Un LLM-as-a-judge, c'est un second modèle de langage qui évalue la sortie d'un premier modèle selon une grille de critères explicites : pertinence, fidélité aux sources, complétude, ton. Il produit un score et une justification. C'est tout.

Ce mécanisme est utile. Mais il est cher, lent, et biaisé si on l'applique sans discernement. La question n'est pas "est-ce que je dois utiliser un juge LLM" mais "à quel endroit de mon pipeline, à quelle fréquence, avec quel modèle".

La règle que j'applique sur mes missions : les tests déterministes d'abord, le juge LLM en dernier recours, jamais dans la boucle de développement rapide.

Tester un LLM : regex, longueur, entités et JSON

Avant de payer un juge LLM, testez comme un développeur

Avant de sortir un LLM-as-judge à 0,60 $ du million de tokens, 80 % des régressions d'un système LLM se détectent avec des assertions gratuites et instantanées : format de sortie incorrect, réponse trop courte, entité attendue absente, JSON invalide, mot interdit présent. Ces vérifications ne nécessitent pas d'IA pour évaluer de l'IA. Elles se codent en 10 lignes de Python et se branchent sur n'importe quelle pipeline CI/CD avec pytest.

C'est l'approche que j'applique systématiquement avant de mettre en place un évaluateur sémantique sur mes missions. Cet article couvre les assertions qui attrapent le plus de bugs, comment les organiser en suite pytest, et à quel moment il faut effectivement passer à l'étage supérieur.

Construire un dataset d'évaluation RAG en 30 minutes

Un dataset imparfait bat l'absence totale de mesure

Pas besoin de semaines d'annotation ou d'un expert métier disponible dès la première heure. En 30 minutes, vous pouvez générer un dataset de départ exploitable directement depuis vos chunks, mesurer le recall@k, et lancer un premier cycle d'amélioration.

Ce dataset sera imparfait. C'est normal et c'est acceptable. L'objectif n'est pas la perfection : c'est d'avoir une mesure reproductible plutôt que le vide. Un recall@5 de 0.71 mesuré sur 50 questions synthétiques vous dit déjà infiniment plus que "ça marche à peu près en démo".

La méthode que je décris ici se déroule en quatre étapes : générer les questions depuis vos chunks, calculer le recall@k, itérer sur le retrieval (hill climbing), et intégrer les retours "pas pertinent" comme hard negatives pour le reranker. Pour les métriques de génération (faithfulness, answer relevancy, context recall) et le choix entre RAGAS, DeepEval et TruLens, voir Évaluer un RAG en production : métriques et RAGAS.

Embeddings : la brique de base de toute l'IA moderne

Sans embeddings, pas de ChatGPT qui répond à vos questions sur vos documents. Pas de recherche sémantique qui retrouve un article même quand vous tapez des synonymes. Pas d'agent IA qui se souvient de ce que vous lui avez dit la semaine dernière.

Les embeddings sont la brique de base de toute l'IA moderne. Et pourtant, dans la grande majorité des projets que j'accompagne, c'est la brique la moins bien comprise. On les utilise, souvent sans trop savoir pourquoi, et on s'étonne des résultats décevants.

Dans cet article, je vous explique ce que c'est vraiment, comment ça fonctionne vu de loin, pourquoi c'est aussi important, comment choisir le bon modèle en 2026, et les pièges concrets à éviter. Que vous soyez manager ou développeur, vous devriez repartir avec une compréhension solide du sujet.