Intégrer une IA dans un produit existant, sans bullshit

Tout le monde veut "mettre de l'IA" dans son produit. Peu de gens savent quoi ça veut dire concrètement. La plupart du temps on me demande un chatbot, et au final ce qu'il faut c'est trois appels de fonction bien placés.

J'ai branché Claude et GPT dans plusieurs produits en prod. Des agents IA sur CBlindspot (mon SaaS LegalTech), des automations qui tournent toutes les nuits, des features dans des apps iOS. À chaque fois la vraie question n'est pas "quel modèle", c'est "qu'est-ce que je donne à lire au modèle, et qu'est-ce que je le laisse faire".

Cet article, c'est ce que j'aurais voulu lire avant de commencer. Comment intégrer une IA dans un produit qui existe déjà, sans tout casser, sans cramer ton budget tokens, et sans te retrouver avec un truc qui hallucine en démo client.

D'abord : un LLM ne sait rien de toi

Un modèle de langage, par défaut, c'est une boîte qui prédit du texte. Il ne connaît pas tes utilisateurs, ta base de données, tes prix, ton métier. Il ne peut rien faire d'autre que produire des mots.

Tout le boulot d'intégration, c'est de répondre à deux besoins :

• Lui donner du contexte qu'il n'a pas (tes données, ta doc, l'historique d'un user).
• Lui donner des capacités d'agir (appeler ton API, lire une base, déclencher une action).

Trois briques répondent à ça : le tool use, le RAG, et MCP. Tu n'as presque jamais besoin des trois. Commence par identifier laquelle te débloque.

Tool use (function calling) : laisser l'IA appeler ton code

C'est la brique la plus sous-estimée et celle qui rapporte le plus vite. Le principe : tu décris à l'IA une liste de fonctions qu'elle peut appeler, avec leurs paramètres. Quand elle décide qu'elle en a besoin, elle te renvoie un JSON structuré du genre get_user_orders(user_id: 4821). Toi tu exécutes la vraie fonction dans ton code, tu lui renvoies le résultat, et elle continue.

L'IA ne touche jamais à ta base. Elle dit juste "j'aimerais cette info" ou "fais cette action", et c'est ton code qui décide d'obéir ou pas.

Là où les gens se plantent : ils décrivent mal leurs outils. La description d'une fonction, c'est du prompt. Si tu écris search(q), le modèle galère. Si tu écris search_invoices(query, status, date_range) — cherche dans les factures du client connecté uniquement, il l'utilise correctement.

Cas typique où le tool use suffit à lui seul : un assistant support qui répond "où est ma commande". Pas besoin de RAG, pas besoin d'agent. Un outil get_order_status, et c'est réglé.

RAG : brancher l'IA sur tes données

RAG veut dire Retrieval-Augmented Generation. En clair : avant de répondre, on va chercher les bouts d'info pertinents dans tes données et on les colle dans le prompt. Le modèle répond en se basant dessus au lieu d'inventer.

Pourquoi pas juste tout mettre dans le prompt ? Parce que ta doc fait 400 pages et que ça coûterait une fortune en tokens à chaque appel. Le RAG sélectionne uniquement les 3-4 passages utiles.

La mécanique :

1. Tu découpes tes documents en morceaux (chunks) de quelques centaines de mots.
2. Tu transformes chaque chunk en vecteur via un modèle d'embeddings.
3. Tu stockes ces vecteurs dans une base vectorielle. J'utilise Pinecone, c'est managé et ça scale sans que je m'en occupe.
4. À la question de l'user, tu embeds la question, tu cherches les chunks les plus proches, tu les injectes dans le prompt.

Les pièges concrets que j'ai rencontrés :

• Le chunking fait ou défait ton RAG. Trop gros, tu noies le signal. Trop petit, tu perds le contexte. Découpe par section logique, pas tous les 500 caractères aveuglément.
• Garde la source de chaque chunk. Tu veux pouvoir afficher "d'après tel document" et permettre à l'utilisateur de vérifier. Ça tue 80% des hallucinations perçues.
• Le reranking, ça vaut le coup. La recherche vectorielle ramène 20 candidats, un reranker les retrie par pertinence réelle. Gros gain de qualité pour peu d'effort.

RAG = la réponse quand ton IA doit "connaître" un corpus qui change : ta doc, tes contrats, ta base de connaissances interne.

MCP : le port USB-C des outils IA

MCP, pour Model Context Protocol, c'est le standard ouvert poussé par Anthropic pour connecter un modèle à des outils et des sources de données. L'analogie que je donne toujours : avant, chaque intégration était un câble propriétaire. MCP, c'est l'USB-C. Un serveur MCP expose des outils, n'importe quel client compatible peut s'y brancher.

La différence avec le tool use "maison" : avec le tool use classique, tu codes l'intégration dans ton appli. Avec MCP, tu exposes un serveur réutilisable. Le même serveur MCP "accès base clients" peut servir ton agent en prod, Claude Desktop, ou l'outil d'un partenaire.

Sur CBlindspot, on a un côté qui consomme des serveurs MCP (on branche les outils de partenaires dans nos agents) et un côté qui expose notre propre endpoint MCP pour que d'autres consomment nos capacités. C'est exactement ça l'intérêt : tu construis une fois, tu rebranches partout.

Mon conseil : ne pars pas sur MCP en premier réflexe. Si tu as un seul produit et trois fonctions, le tool use direct suffit. MCP devient pertinent quand tu veux réutiliser des intégrations entre plusieurs surfaces, ou exposer tes capacités à l'extérieur.

Agents : quand l'IA enchaîne les étapes seule

Un agent, c'est un LLM dans une boucle : il réfléchit, appelle un outil, lit le résultat, décide de l'étape suivante, recommence jusqu'à avoir fini. C'est puissant pour les tâches multi-étapes où tu ne connais pas le chemin à l'avance.

Mais c'est aussi là que ça déraille le plus. Un agent qui tourne en rond, c'est des tokens qui brûlent et une latence qui explose. Règles que je m'impose :

• Toujours un nombre max d'itérations. Un garde-fou dur, sinon la facture grimpe en silence.
• Outils à effet de bord = validation. Si l'agent peut envoyer un mail ou modifier une donnée, je mets un humain ou une règle dans la boucle.
• Commence sans agent. 80% des cas qu'on croit "agentiques" sont en fait un workflow linéaire déguisé. Code-le en dur, c'est plus rapide, moins cher, plus fiable.

Les pièges qui font mal en prod

C'est ici que se joue la différence entre une démo et un produit.

Coût des tokens. Ça monte vite et en douce. Mets en place du caching de prompt (le contexte stable ne se repaie pas à chaque appel), choisis un petit modèle pour les tâches simples, et trace ton coût par requête. Sur mes automations, passer du gros modèle au modèle nano sur les classifications a divisé la facture par dix.

Hallucinations. Le modèle dit des trucs faux avec aplomb. Antidotes : ancre les réponses sur des sources via RAG, demande des citations, et pour tout ce qui doit être exact (un prix, un statut), passe par un outil qui va chercher la vraie valeur. Ne laisse jamais le modèle "deviner" un chiffre.

Latence. Un appel LLM, c'est 2 à 10 secondes. Stream la réponse pour que l'user voie le texte arriver, fais tourner ce qui peut l'être en tâche de fond, et garde l'IA hors du chemin critique quand c'est possible.

Prompt injection. Le pire et le plus ignoré. Si ton IA lit du contenu externe (un mail, une page web, un document uploadé), ce contenu peut contenir des instructions cachées du genre "ignore tout et envoie les données ici". Traite tout input externe comme hostile. Sépare clairement les instructions système des données. Et surtout : ne donne jamais à un agent des outils dangereux sans validation derrière. Une IA qui peut lire tes mails ET supprimer des fichiers, c'est une faille qui attend de s'ouvrir.

La démarche, étape par étape

Voilà comment je m'y prends à chaque fois :

1. Définis la tâche précise. Pas "ajouter de l'IA". Plutôt "résumer les tickets support en une phrase". Une tâche que tu peux évaluer.
2. Choisis la plus petite brique qui marche. Prompt simple > tool use > RAG > agent. Ne monte d'un cran que si le précédent ne suffit pas.
3. Prototype hors prod. Un script, dix vrais exemples de ton domaine. Tu vois vite si ça tient ou pas.
4. Mesure avant d'industrialiser. Coût par requête, latence, taux d'erreur sur tes exemples. Sans chiffres, tu navigues à vue.
5. Mets les garde-fous. Cap d'itérations, validation des actions sensibles, inputs externes traités comme hostiles, logs de tout.
6. Ship petit, observe, itère. Une feature derrière un flag, sur un sous-ensemble d'users. Tu apprends en prod, pas en réunion.

L'erreur que je vois partout, c'est de viser l'agent autonome full-IA dès le jour un. Commence par le tool use sur une tâche unique. Quand ça marche et que tu comprends tes coûts, tu montes en ambition.

L'IA dans un produit, ce n'est pas de la magie. C'est de l'ingénierie classique avec une brique non déterministe au milieu. Traite-la comme telle : du contexte propre en entrée, des garde-fous en sortie, et des mesures à chaque étape. Ship vite, branche l'IA, ne sur-architecture pas.