Votre agent IA ne dépend pas du modèle

On vous a vendu le débat ChatGPT contre Claude contre Mistral comme s'il scellait le sort de votre produit IA. C'est faux. La démo qui a impressionné votre board ne dit rien de ce qui vous attend en production. Entre les deux, ce qui change n'est pas le modèle. C'est une discipline d'ingénierie que personne ne met sur une slide. Et c'est elle qui décide si votre agent crée de la valeur ou détruit la confiance.

Je construis des agents IA en production, pas en présentation. Sur Capston, l'IA n'est pas un gadget posé sur le produit. C'est le cœur de la valeur. J'y ai passé bien plus de temps sur l'évaluation et la récupération de contexte que sur le choix du fournisseur. En audit, je vois toujours le même scénario : une démo bluffante, un budget qui fond, et plus personne capable de dire si la dernière mise à jour a amélioré ou cassé le produit.

Pourquoi la démo tient et la production casse

Une démo, c'est un seul chemin heureux. Vous tapez la question pour laquelle l'agent a été réglé, devant des gens bienveillants. Ça marche. La production, c'est l'inverse. Des milliers d'utilisateurs posent la question de travers, dans un ordre imprévu, avec des données que vous n'aviez pas anticipées. C'est cette longue traîne qui fait gagner ou perdre.

Un repère utile vient du MIT. Son rapport State of AI in Business 2025, mené par l'initiative NANDA, donne un chiffre brutal. 95 % des organisations n'obtiennent aucun retour mesurable de leurs pilotes d'IA générative, malgré 30 à 40 milliards de dollars investis. La cause n'est pas celle qu'on accuse en réunion. Les dirigeants pointent la réglementation ou la performance des modèles. L'étude, elle, pointe l'approche d'intégration. Si des pilotes simples échouent déjà à ce point, et pas à cause du modèle, imaginez un agent construit sur les mêmes raccourcis. Un agent, lui, est un système autonome, bien plus dur à fiabiliser qu'un simple pilote.

C'est logique quand on prend du recul. Le modèle est un composant interchangeable. Il change tous les trois mois. Vos concurrents peuvent le brancher aussi vite que vous. Ce n'est pas votre avantage. Votre avantage, c'est le cadre que vous bâtissez autour : comment vous mesurez la qualité, comment vous nourrissez le modèle en contexte, comment vous encadrez ses erreurs. Ça, un concurrent ne le copie pas en une après-midi.

Ce que l'absence de cadre vous coûte vraiment

Le danger d'un agent non cadré n'est pas technique. Il est commercial. Et il se paie de trois manières.

D'abord la confiance. Un agent qui se trompe en hésitant, on le pardonne. Un agent qui se trompe avec aplomb devant un client, c'est fini. On ne lui fait plus confiance, et souvent on ne fait plus confiance à votre produit non plus. Une seule réponse fausse assénée avec assurance peut annuler cent réponses justes. Je me souviens d'un assistant qui passait toutes les démos. En production, il citait des montants erronés à des clients. Le problème n'était pas le modèle : on récupérait le mauvais document avant de l'interroger.

Ensuite le budget. Un agent qu'on ne mesure pas dérive en silence. Les appels se multiplient. Les coûts par requête grimpent. Vous le découvrez sur la facture trois mois plus tard. Sans visibilité sur ce que fait votre IA, vous payez le double pour une qualité que vous ne savez même pas évaluer.

Enfin la dépendance. Construire tout son produit sur un seul fournisseur, c'est lui confier votre marge et votre disponibilité. Le jour où il augmente ses prix, dégrade un modèle ou tombe en panne, vous n'avez pas de plan B. Votre produit s'arrête avec lui. C'est un risque stratégique qu'on évalue rarement, parce qu'il ne se voit pas en démo.

Les quatre piliers qui font tenir un agent

Quand on me demande de fiabiliser un agent, je ne commence jamais par changer de modèle. Je regarde quatre choses, dans un ordre précis.

Les évaluations d'abord, les evals. C'est le pilier que tout le monde saute, et celui qui change tout. Une eval, c'est un jeu de tests réels. Vous y mesurez la qualité des réponses, objectivement, à chaque modification. Sur Capston, nous gardons une centaine de requêtes réelles représentatives. À chaque changement de prompt, de modèle ou de récupération, nous les rejouons. On vérifie que la qualité monte au lieu de baisser. Sans ce filet, vous pilotez à l'aveugle. Vous changez un mot dans une instruction, vous croyez améliorer, et vous cassez dix cas sans le savoir.

La récupération de contexte ensuite, le RAG, mais bien fait. Le piège, c'est de le traiter comme une case à cocher : « on a branché du RAG, c'est bon ». Or un agent ne vaut que ce qu'on lui donne à lire. S'il récupère le mauvais document, il répond faux avec une confiance parfaite. Dans la plupart des cas que j'ai vus, la qualité se joue là : sur la pertinence du contexte, bien avant le modèle qui le lit.

Les garde-fous et l'observabilité. Un agent en production doit être tracé. Chaque appel, sa latence, son coût, sa qualité : visibles, et sous alerte. Il lui faut aussi des filets : un comportement prévu quand il ne sait pas, des limites claires, un humain dans la boucle là où l'enjeu l'exige. C'est ce qui vous évite de découvrir une dérive par une plainte client plutôt que par une alerte.

L'orchestration multi-modèles enfin. Une fois les trois premiers piliers en place, c'est le levier qui rend votre agent rentable. Un agent n'a pas besoin du modèle le plus puissant à chaque étape. Classer une demande et rédiger une réponse nuancée, ce sont deux tâches distinctes, qui méritent deux outils différents. Routez chaque tâche vers le bon modèle : un petit et bon marché là où il suffit, un gros là où la nuance compte. Vous réduisez vos coûts, vous accélérez vos réponses, vous sortez de la dépendance à un seul fournisseur. Personne ne le remarque en démo. Et c'est pourtant ce qui sépare un prototype d'un produit qui tient à l'échelle.

Par où commencer, et dans quel ordre

Si vous lancez un projet d'agent, inversez l'ordre habituel. Ne commencez pas par choisir le modèle. Commencez par définir ce qu'« une bonne réponse » veut dire pour vous. Puis construisez l'eval qui le mesure. Tant que vous ne mesurez pas la qualité, changer de modèle revient à régler un moteur les yeux bandés.

Ensuite, soignez le contexte avant la puissance. Un modèle moyen bien nourri bat un modèle excellent mal nourri. À chaque fois. Investissez dans la récupération avant d'investir dans le fournisseur le plus cher. Le multi-modèles vient en dernier. Pas parce qu'il est secondaire, mais parce qu'il n'a de sens qu'une fois que vous savez mesurer ce que vous optimisez.

Et quand vous recrutez quelqu'un pour construire ça, la bonne question n'est pas « quel modèle utilisez-vous ? ». C'est « comment mesurez-vous que ça marche, et que se passe-t-il quand ça ne marche pas ? ». La plupart des entreprises n'échouent pas pour avoir choisi le mauvais modèle. Elles échouent parce que personne, chez elles, n'est responsable de mesurer, surveiller et améliorer le système. Cette fonction n'a souvent pas de propriétaire. C'est elle qu'il faut installer avant d'écrire la première ligne.

Ce qu'il faut retenir

• Le modèle est interchangeable, pas un avantage. Ce qui vous appartient, c'est le cadre autour.
• Une démo réussie ne prédit rien. La valeur se joue sur les cas réels, là où la plupart des projets d'IA échouent faute d'intégration, pas faute de modèle.
• Quatre leviers font la différence : evals, qualité de récupération, garde-fous, orchestration multi-modèles. Dans cet ordre, en commençant par savoir mesurer.

Questions fréquentes

Faut-il choisir le meilleur modèle du marché pour son agent IA ?

Non, et c'est rarement la bonne question. Le modèle est interchangeable, et le marché en change tous les trois mois. La fiabilité d'un agent vient du cadre autour : la mesure de la qualité, la pertinence du contexte, l'encadrement des erreurs. Un modèle moyen bien intégré bat un modèle de pointe mal intégré.

Pourquoi mon agent IA fonctionne en démo mais pas en production ?

Parce qu'une démo teste un seul chemin idéal. La production, elle, expose l'agent à tous les usages réels, imprévus et mal formulés. L'écart ne se comble pas en changeant de modèle. Il se comble avec des évaluations systématiques, une récupération de contexte fiable et des garde-fous pour les cas d'échec.

Qu'est-ce qu'une eval et pourquoi est-ce indispensable ?

Une eval est un jeu de tests réels. Elle mesure objectivement la qualité des réponses de votre agent à chaque modification. Sans elle, vous ne savez pas si un changement améliore ou dégrade votre produit. Vous avancez à l'aveugle. C'est le premier investissement à faire, avant même de choisir un modèle.

Conclusion

Le débat sur le meilleur modèle est confortable, parce qu'il a une réponse simple. La vraie question est plus exigeante : comment savez-vous que votre agent tient, et que se passe-t-il quand il déraille ? C'est la seule qui sépare un gadget d'un produit.

Si vous construisez un agent et que vous voulez qu'il survive à vos vrais utilisateurs, parlons-en : 30 minutes pour cadrer ce qui compte vraiment dans votre cas.