IA¶

Stack IA en production : limites des frameworks

Il n'y a pas de librairie IA parfaite. Et ce n'est pas grave.

J'ai utilisé LangChain et LlamaIndex sur plus d'une vingtaine de projets, d'abord comme développeur, ensuite comme lead data scientist chargé de piloter des équipes. Sur des RAG de gestion documentaire, des agents de traitement de données métier, des pipelines d'extraction, des assistants sectoriels.

Voilà ce que j'en pense vraiment : il n'y a pas de librairie IA parfaite. Ni LangChain, ni LlamaIndex. Et toutes les équipes qui construisent des produits IA sérieux sur le long terme finissent par développer leur propre stack.

Ce n'est pas un bashing. C'est un constat pragmatique, fondé sur ce que j'ai vécu sur le terrain. Ces librairies ont de vraies qualités, elles rendent de vrais services, et il y a des situations où les utiliser est clairement le bon choix. Mais il y a aussi une réalité qu'on entend rarement : au fond, LangChain et LlamaIndex ne font qu'appeler des APIs. Les APIs d'OpenAI, d'Anthropic, de Google, de Mistral. Et ces APIs, on peut les appeler directement, avec un code qui reste sous notre contrôle.

Dans cet article, je couvre les vraies limites des deux librairies, quand elles conviennent, pourquoi on bascule vers du custom, et comment le SDK OpenAI seul couvre aujourd'hui une fraction énorme des besoins en production.

7 mauvais réflexes RAG et comment les corriger

Introduction

Quand un projet RAG patine, ce n'est presque jamais à cause d'une techno manquante. C'est à cause d'un enchaînement de réflexes contre-productifs que les équipes adoptent sans s'en rendre compte. On retouche le prompt alors que le problème est dans le retrieval. On juge "ça marche" sur quatre essais à la main. On empile les techniques avancées avant d'avoir compris où ça bloque.

Après une vingtaine de projets RAG en mission ou en audit, je retrouve toujours les mêmes 7 réflexes. Ce ne sont pas des erreurs techniques, ce sont des biais cognitifs. Mais ils sabotent les performances aussi sûrement qu'un mauvais chunking. Voici la liste, et à chaque fois le réflexe à substituer.

Prompt caching : divisez la facture LLM jusqu'à 90% en 2026

Si vous payez plein tarif vos appels LLM en 2026, vous laissez 50 à 90% de réduction sur la table

Le prompt caching est devenu la première optimisation de coût à mettre en place dans tout projet LLM en production, et bizarrement, personne n'en parle assez.

La réalité des projets que j'accompagne : les équipes passent des heures à comparer les modèles, à négocier des remises volume avec les providers, à chercher des alternatives open-source. Et pendant ce temps, leur code repaie intégralement le même system prompt de 10 000 tokens à chaque appel, sans jamais avoir entendu parler de cache_control.

Dans cet article, vous allez voir comment fonctionne le prompt caching au niveau technique (le KV cache), comment les trois providers majeurs l'implémentent différemment (Anthropic, OpenAI, Gemini), les patterns qui font vraiment chuter la facture, et le calcul de ROI sur un cas concret.

UX produit IA : 5 patterns pour multiplier le feedback

L'UX est le levier d'optimisation IA le plus sous-estimé

Quand un produit IA fonctionne mal, les équipes techniques se ruent sur le pipeline : nouveau modèle d'embeddings, reranker plus malin, prompt retravaillé, chunking modifié. Tout ça est utile, mais ça passe à côté du levier qui a le meilleur rapport effort / impact : l'interface utilisateur.

L'UX ne fait pas que présenter la réponse. Bien conçue, elle devient un capteur qui collecte de la donnée d'amélioration en continu. C'est exactement le type de donnée qui manque à 80 % des projets que j'audite, et sans laquelle aucune optimisation pipeline ne fonctionne vraiment.

Dans cet article, je détaille 5 patterns UX que j'applique systématiquement sur mes projets, avec les chiffres derrière chacun.

Long context vs RAG en 2026 : quand utiliser quoi ?

Introduction

À chaque sortie d'un modèle avec une fenêtre contextuelle plus grande, le débat revient : « le RAG, c'est fini, on met tout dans le contexte ». En 2026, Gemini 3.1 Pro pousse jusqu'à 2 millions de tokens, Claude et GPT tiennent le 1M. La question est légitime.

Mais sur le terrain, ce n'est pas si simple. J'ai vu des équipes brûler des milliers d'euros en API en pensant qu'elles « simplifiaient » leur stack en virant le RAG. J'ai vu aussi des équipes monter un RAG pour répondre à des questions sur 3 pages de doc. Dans les deux cas, on utilise le mauvais outil pour le problème.

Mémoire des agents IA : principes et implémentation

Sans mémoire, un agent IA est juste un meilleur chatbot.

Avec une mémoire mal conçue, c'est un agent qui invente des souvenirs, contredit ce qu'il a dit la semaine dernière, et vous coûte une fortune en tokens. La mémoire est la fonctionnalité la plus sous-estimée des agents IA en 2026. Et c'est aussi celle qui fait la différence entre un prototype sympa et un produit qui crée vraiment de la valeur.

Dans cet article, je vais vous expliquer la taxonomie réelle de la mémoire dans les agents IA, le pattern technique central que très peu de gens expliquent clairement (un petit LLM dédié qui filtre ce qui mérite d'être retenu), les outils du marché avec leurs vrais chiffres de benchmark, et comment choisir selon votre cas.

Parsing PDF pour RAG : extraire vraiment la donnée

Le parsing, première cause d'échec des RAG en entreprise

Sur 10 RAG qui ne fonctionnent pas en entreprise, 8 ont un problème de parsing en amont. Pas de modèle, pas de prompt, pas de retriever. Juste un PDF mal lu au départ.

C'est le constat que je fais sur presque tous les projets que j'accompagne. Une entreprise investit des semaines à choisir son modèle de langage, à configurer sa base vectorielle, à affiner ses prompts... et le système répond à côté. Parce que le document source a été mal lu dès le début.

Le parsing (l'extraction structurée des données depuis un document) est l'étape la plus sous-estimée du RAG. Si la récupération d'informations depuis vos fichiers est approximative, peu importe la sophistication du reste du pipeline : vous construisez sur du sable. Un tableau mal extrait, des colonnes confondues, un schéma technique ignoré... et votre LLM génère des réponses fausses avec une confiance absolue.

Dans cet article, je vais vous montrer pourquoi cette structuration des documents est si difficile, comment les 4 grands outils du marché se comparent vraiment, et ce que j'ai appris sur deux projets très différents : des documentations d'usine chez Continental, et un site e-commerce avec des milliers de fiches produit.

Agent IA vs n8n, Make, Zapier : Quel Choix pour votre PME ?

6 PME sur 10 qui demandent un agent IA n'en ont pas besoin

Sur 10 PME qui me contactent en disant "on veut un agent IA", 6 n'ont en réalité pas besoin d'un agent IA.

Elles ont besoin d'un bon workflow n8n avec un nœud OpenAI bien configuré. Et personne ne le leur dit. Parce que les agences custom préfèrent vendre des agents IA à 30K€ qu'un workflow n8n à 3K€. C'est humain. Mais ce n'est pas honnête.

Alors dans cet article, je vais vous donner la grille de décision que j'utilise avec mes propres clients. Pas de discours commercial. Juste les critères qui permettent de trancher entre agent IA vs n8n (ou Make, ou Zapier) selon votre cas réel.

Position claire dès le départ : dans la majorité des cas PME, un n8n bien fait avec un nœud LLM suffit. L'agent IA custom n'est nécessaire que dans des cas précis. Je vais vous montrer exactement lesquels.

Évaluer un RAG en production : métriques et RAGAS

80% des RAG que j'audite n'ont pas de système d'évaluation

C'est un chiffre que j'aurais aimé pouvoir citer avec une source académique. Mais il vient directement du terrain : sur les projets RAG en production que j'ai eu à auditer ces deux dernières années, environ 8 sur 10 n'ont aucun système d'évaluation structuré en place.

Le scénario est toujours le même. Le projet a été livré. L'équipe a "vérifié à la main" sur 10 ou 15 questions pendant la recette. Les retours utilisateurs semblent corrects. Et plus personne ne mesure rien.

Le coût caché de cette absence est massif. Vous ne savez pas si le RAG dérive après une mise à jour des documents. Vous ne savez pas si un changement de modèle d'embeddings a cassé quelque chose. Vous ne savez pas si les améliorations que vous apportez apportent vraiment un gain, ou si elles compensent juste une régression ailleurs. Vous optimisez à l'aveugle.

C'est le sujet numéro un qui sépare un RAG POC d'un RAG production mature. Un POC, ça "marche". Un système production, ça se mesure, ça se surveille, et ça s'améliore de façon contrôlée. Cet article couvre les métriques RAG qui comptent, les frameworks d'évaluation (RAGAS, DeepEval, TruLens), comment construire un dataset d'évaluation solide, et comment mettre en place une évaluation continue en production.

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).