IA¶

MCP (Model Context Protocol) : Le Standard des Agents IA

Tout le monde parle d'agents IA. Personne ne parle de comment ils se connectent vraiment à vos outils.

Voici le problème concret que rencontrent 90% des équipes qui veulent construire un agent IA sérieux : elles ont un LLM capable, un cas d'usage clair, et 4 ou 5 outils à connecter (une base SQL, un Slack, un Notion, un GitHub). Et là, elles se retrouvent à coder une intégration custom pour chaque outil, pour chaque modèle. Si demain elles changent de LLM, elles recommencent. Si un collègue veut réutiliser l'intégration Slack sur un autre agent, il repart de zéro.

C'est le problème N fois M. N agents, M outils. On aboutit à N×M intégrations à coder et à maintenir.

MCP résout exactement ce problème. Le Model Context Protocol est le standard ouvert lancé par Anthropic en novembre 2024, et il est en train de devenir en 2026 ce qu'HTTP est au web : l'infrastructure invisible sur laquelle tout repose. OpenAI, Google, Microsoft, AWS : tout l'écosystème converge dessus. 97 millions de téléchargements mensuels du SDK en mars 2026, contre 2 millions au lancement. C'est une adoption sans précédent dans l'outillage IA.

Dans cet article, je vais vous expliquer ce qu'est MCP vraiment, comment son architecture fonctionne, en quoi il diffère du function calling classique, et surtout : sur quels projets l'utiliser (et sur quels projets ne pas l'utiliser).

Les 5 domaines de l'IA au-delà de ChatGPT

Introduction

Depuis deux ans, dès que je dis « je travaille dans l'IA », la première réaction est presque toujours la même : « Ah, comme ChatGPT ? ». Et c'est normal. ChatGPT a complètement aspiré l'image que les gens se font de l'intelligence artificielle. Pour beaucoup, IA = ChatGPT, et en dehors de ça, il n'y a rien.

Sauf que c'est très loin de la réalité. ChatGPT, c'est une partie de l'IA, parmi beaucoup d'autres. La plupart des IA qui tournent aujourd'hui dans les entreprises et dans nos vies n'ont rien à voir avec ChatGPT. Elles existent depuis bien plus longtemps, elles sont moins visibles, mais elles font tourner Netflix, votre filtre anti spam, votre application bancaire ou les usines qui produisent les pièces de votre voiture.

Sur le terrain, je vois souvent des entreprises me demander un projet « ChatGPT » alors que ce dont elles ont vraiment besoin, c'est d'un modèle de prévision sur leurs données Excel ou d'un système de vision sur leur ligne de production. Et la confusion est compréhensible : on ne peut pas choisir le bon outil si on ne connaît pas la boîte à outils.

Dans cet article, je vais faire le tour des grands domaines de l'IA, avec des exemples concrets de ce que les entreprises font vraiment avec (et certains projets sur lesquels j'ai travaillé personnellement). L'objectif : que vous compreniez en lisant que ChatGPT, c'est juste un type d'IA parmi d'autres, et que selon ce qu'on veut faire, on choisit un domaine différent et un modèle différent.

RAG, Finetuning ou Entraînement : Quel choix pour votre IA ?

Introduction

Une question revient souvent quand j'accompagne des entreprises sur leurs projets IA : « Est-ce qu'on doit entraîner notre propre modèle ? ». Ou alors la variante un peu plus avancée : « On veut finetuner un modèle sur nos données ».

Et à chaque fois, je dois prendre un peu de temps pour expliquer ce que ça veut dire concrètement. Parce que entre entraîner un modèle de zéro, le finetuner sur ses propres données, ou simplement lui donner du contexte avec un RAG, il y a un monde de différence. En coût, en temps, en complexité, et surtout en résultat.

Dans cet article, je vais essayer de poser les choses simplement. C'est quoi un modèle d'IA, comment on l'entraîne, combien ça coûte, à quel moment ça vaut le coup, et surtout pourquoi dans 95% des cas, vous n'avez probablement pas besoin de faire ni l'un ni l'autre.

Optimiser un RAG : 8 techniques aux gains mesurés

Vous optimisez probablement dans le mauvais sens

Quand un RAG ne fonctionne pas bien, voici ce que font 90% des équipes : elles changent le prompt.

On reformule les instructions, on essaie différents modèles, on ajuste la température. Et parfois ça aide un peu. Mais le plus souvent, le problème n'est pas là.

Jason Liu, l'un des experts RAG les plus suivis, a une formulation que j'ai trouvée juste : "Avant de toucher à quoi que ce soit, atteignez 97% de recall en retrieval."

97% de recall, ça veut dire que dans 97 cas sur 100, le chunk qui contient la bonne réponse est bien dans les résultats que vous passez au LLM. Si vous n'êtes pas là, le meilleur prompt du monde ne changera rien. Le LLM ne peut pas inventer une information qui n'est pas dans son contexte.

Le vrai ordre d'optimisation d'un RAG, c'est : mesurer d'abord, puis retrieval, puis génération. Pas l'inverse.

Chunking RAG : quelle stratégie choisir en 2026 ?

Le chunking que vous utilisez probablement est le pire testé

Je vais commencer par un résultat qui m'a surpris quand je l'ai vu.

Chroma Research a publié un benchmark comparant toutes les stratégies de chunking courantes. Ils ont testé les paramètres par défaut d'OpenAI Assistants : 800 tokens, 400 tokens d'overlap. Leur verdict est sans appel, c'est la configuration avec la précision la plus basse de tous les tests. 1.4% de précision. Leur commentaire exact : "particularly poor recall-efficiency tradeoffs".

Ce sont les paramètres que des dizaines de milliers de projets utilisent en ce moment, souvent parce que c'est ce que suggère le quick start de LangChain ou LlamaIndex.

Et pendant ce temps, des configurations 4x plus simples (200 tokens, zéro overlap) font 3.7x mieux en précision.

Le chunking, c'est la décision sur laquelle la plupart des équipes passent le moins de temps. Et pourtant, c'est probablement celle qui a le plus d'impact sur la qualité de votre RAG.

GEO : fonctionnement des moteurs de recherche IA

Introduction

Vu que j'ai eu pas mal de retours autour du GEO ces derniers temps, et que le sujet a l'air d'intéresser, je me suis dit que ce serait bien de creuser les bases pour ceux qui veulent comprendre comment ça fonctionne.

Le GEO, pour Generative Engine Optimization, c'est l'art de se faire référencer et citer par les moteurs de recherche basés sur l'IA. En gros, c'est le SEO version IA. Et comme pour le SEO classique, avant de chercher à optimiser quoi que ce soit, il faut d'abord comprendre comment ça marche derrière.

Ce post est le premier d'une série de trois. Comment les moteurs de recherche IA fonctionnent (1). Comment se faire référencer dessus (2). Et comment analyser sa visibilité (3).

Commençons par le fonctionnement.

RAG hybride BM25 + vectoriel : implémentation

Votre RAG vectoriel rate des questions que vous ne voyez pas

C'est une remarque que j'entends souvent sur les projets RAG : "Ça marche bien en général, mais parfois il ne trouve rien sur des questions pourtant simples."

Exemple concret : "Quelle est la procédure ISO-27001 pour les accès distants ?" → 0 résultat pertinent.

Le vectoriel encode le sens. Mais quand la question contient un identifiant exact (une norme, un code produit, un acronyme métier), l'encodage sémantique rate complètement.

C'est ce qu'on appelle le vocabulary mismatch. Et c'est le problème que le hybrid search résout.

Agentic RAG vs RAG classique : quand basculer ?

Votre RAG ne suffit plus. Vraiment ?

On en parle partout. L'Agentic RAG. Le RAG agentique. Le futur du RAG.

Et comme d'habitude avec les tendances IA, on a l'impression que si vous n'êtes pas encore passé à l'Agentic RAG, vous êtes en retard. Que votre RAG "classique" est dépassé. Qu'il faut tout refaire.

Je vais vous dire ce que j'en pense vraiment : ce n'est pas aussi simple, et la plupart des projets n'ont pas besoin d'Agentic RAG.

Mais, car il y a toujours un mais, l'Agentic RAG répond à des problèmes réels que le RAG classique ne peut tout simplement pas résoudre. Et si vous tombez sur ces problèmes, vous en aurez besoin.

Alors dans cet article, je vais faire simple : ce qu'est vraiment l'Agentic RAG, en quoi il diffère du RAG classique, et surtout, comment décider si vous en avez besoin ou pas.

RAG BTP : automatiser les réponses aux appels d'offres

Le RAG appliqué à la rédaction : bien plus qu'un chatbot Question-Réponse

Quand on parle de RAG (Retrieval-Augmented Generation), la plupart des gens pensent à un chatbot qui répond à des questions sur des documents internes. C'est le cas d'usage classique, celui qu'on voit dans tous les tutos.

Mais le RAG peut faire bien plus que ça. Quand il est bien intégré dans un workflow métier, le RAG devient un moteur de rédaction contextuelle. Il ne se contente pas de retrouver l'information : il la comprend, la structure, et produit un texte professionnel prêt à être validé par un humain.

Je vais illustrer ça avec un cas concret qu'on a réalisé récemment : l'automatisation de la rédaction d'appels d'offres pour un acteur du BTP.

IA et rapports de sinistre : 80% de temps gagné

La façon dont on intègre l'IA, c'est ce qui fait la différence

Quand on travaille dans l'IA, le plus important souvent ce n'est pas quel modèle on utilise ou quelle dernière techno à la mode est la plus performante.

Le plus important, c'est comment on intègre l'IA dans un workflow déjà existant.

A chaque nouveau projet, il y a deux défis. Le premier, c'est de réussir à atteindre de bonnes performances avec mes algorithmes d'IA pour résoudre une problématique donnée. Le deuxième, c'est l'intégration : comment je mets à disposition cet algorithme pour qu'il soit utilisé et qu'il soit utile. Car trop souvent, des projets IA tombent dans l'oubli parce qu'ils ne sont pas exploitables, ou qu'ils ne s'intègrent pas bien dans le travail quotidien des employés (j'en parle dans les 5 erreurs que tout le monde fait avec le RAG, mais le constat dépasse largement le RAG).

Je vais illustrer ça avec un cas concret qu'on a réalisé récemment : l'automatisation de rapports de sinistre pour un acteur de l'expertise bâtiment et menuiserie.