Comment une démo ratée nous a forcés à repenser notre stratégie d'embeddings

Note : toutes les données qui suivent sont extraites d’un benchmark opéré par la plateforme Ask This Guy, et concernent la période du 5 au 25 janvier 2026. Les requêtes sont envoyées de façon régulière depuis un serveur ATG situé en France, qui mesure les temps de réponse.

Un moment compliqué

Call avec un prospect. Nous sommes là pour présenter Ask This Guy, notre solution d'IA qui (notamment) s'appuie sur les documents internes de l'entreprise. Tout est prêt, la démo est rodée.

Je tape une requête simple dans l'interface. Et là... silence.

Trois secondes. Dix secondes. On essaie d’enchainer sur un autre sujet, on bredouille un peu, mais on devine ce qui se passe dans la tête du client et la question non posée : "Votre solution, elle marche vraiment ?"

La réunion terminée, on jette un coup d'oeil aux logs, le verdict tombe tout de suite : nous étions tombés au mauvais moment. Ce jour-là, l'API de Mistral a mis près d'une minute à répondre. Était-ce une simple anomalie ? Pas vraiment : comme nous allons le voir, c'est un problème structurel.

Cet épisode embarrassant nous a forcés à nous poser une question simple mais cruciale : comment garantir des performances fiables en production quand on dépend de providers d’IA externes ?

Ce que nous avons appris depuis, nous allons le partager avec vous.

Retour sur les fondamentaux

Avant de plonger dans le sujet, petit rappel. Si vous déployez une IA dans votre entreprise s'appuyant sur vos documents internes via une architecture RAG (Retrieval-Augmented Generation), vous aurez besoin d'embeddings pour la recherche sémantique.

Qu'est-ce qu'un embedding ?

Imaginez que la signification de chaque phrase de vos documents soit transformée en un vecteur numérique, c'est-à-dire une représentation mathématique de sa signification. C'est ça, un embedding. Cela permet de trouver très vite une information qui répond au besoin d’un utilisateur.

Le mécanisme est simple en théorie :

1. Un utilisateur envoie un message
2. Le système formule une ou plusieurs requêtes de recherche
3. Ces requêtes sont converties en embeddings (vecteurs)
4. Ces vecteurs sont comparés à ceux de vos documents
5. Les extraits les plus proches sont récupérés
6. La réponse est générée à partir de ces extraits

Vous voyez où je veux en venir ? Chaque fois qu'un utilisateur envoie une requête, il faut calculer un embedding. Si ce calcul prend du temps, l'utilisateur attend. Si l'embedding échoue, il n'y a pas de réponse du tout.

C'est pourquoi la performance des embeddings n'est pas un détail technique : c'est l'expérience utilisateur.

On peut par exemple définir une performance acceptable ainsi :

• Objectif : un délai inférieur à 300 ms dans la grande majorité des cas
• Limite critique : ne jamais dépasser la seconde

Et il ne faut pas oublier un autre point crucial : tous les modèles d'embedding ne se valent pas. Les écarts de pertinence des réponses sont énormes, nous l'avons expérimenté lorsque nous avons voulu tester des modèles "moyens". Si vous voulez comparer les modèles, le MTEB leaderboard de HuggingFace est une très bonne base.

Notre parcours initial : les “grands” du marché

Quand nous avons commencé à développer Ask This Guy, le choix semblait évident : les grands acteurs du marché : Mistral, OpenAI. C'est plus ou moins ce que tout le monde fait, non ?

C'est effectivement par là que nous avons commencé.

La pertinence de cette approche est… mitigée. Les performances d'OpenAI se situent en moyenne autour de la seconde pour le modèle large (et environ une demi-seconde pour le modèle small). Ce n'est pas catastrophique, mais c'est loin de notre cible.

Mistral, de son côté, affiche une meilleure performance médiane autour de 300 ms, mais un taux d’échec important :

Performances Mistral & OpenAI

Regardons de plus près l'irrégularité, jour par jour, notamment chez Mistral :

Performances Mistral & OpenAI

La plupart du temps, plus de 95% des requêtes sont traitées en moins d'une seconde. Sur le papier, c'est correct. Mais certaines journées sont tout simplement catastrophiques. C'est ce que nous avons vécu lors de notre démo. Et c'est ce que nos données mettent en évidence de manière implacable.

Second problème : le lock-in

Supposons que vous ayez trouvé le fournisseur parfait (même si ce n'est pas encore le cas à ce stade de l'article).

Parfait.

Mais que se passe-t-il demain si ses performances se dégradent ? Ou si ses prix augmentent ? Ou si l'entreprise disparaît ?

La réponse naturelle serait : "On change de fournisseur !"

Sauf que... ce n'est pas si simple.

Voici le problème technique fondamental : comparer des embeddings générés avec des modèles différents ne fonctionne pas. Les vecteurs ne sont pas compatibles. Une fois que vous avez utilisé un modèle pour indexer vos documents, vous êtes condamné à utiliser le même modèle pour les requêtes (ou à réindexer tous vos documents).

C'est là que le choix du modèle devient stratégique :

• Si vous utilisez un modèle propriétaire (comme ceux d'OpenAI, par exemple), vous êtes totalement dépendants de ce fournisseur. Pas de sortie possible.
• Si vous utilisez un modèle open weights, vous pouvez en revanche utiliser plusieurs fournisseurs pour le même modèle. Et c'est là que ça devient vraiment intéressant.

Les spécialistes de l’inférence

Revenons à nos résultats de benchmark. Une tendance se dégage : certains fournisseurs s'en sortent nettement mieux que les géants traditionnels. Ce sont des spécialistes de “l’inférence”, la capacité à appliquer un modèle d’IA vite et bien. Ils s'appuient sur des modèles open weights.

Comparaison des performances de fournisseurs d'embeddings

En l’occurrence, sur les embeddings, Scaleway et Nebius (deux européens !) émergent clairement du lot parmi les providers que nous avons testés.

Et leur régularité est meilleure, en particulier chez Scaleway où elle est remarquable :

Comparaison des performances de fournisseurs d'embeddings

Pourquoi ? Probablement parce que ce sont des spécialistes de l'infrastructure cloud et de l'inférence, là où OpenAI ou Mistral sont avant tout des créateurs de modèles. La spécialisation paie.

Est-ce suffisant ?

Pas encore tout à fait. Si bonnes soient les performances de certains acteurs, il reste des moments de contre-performance. Et un risque inhérent au vendor lock-in, si ses performances se dégradent ou ses prix augmentent.

Pour résoudre les deux problèmes, nous avons choisi un modèle d'embedding open weights particulièrement performant et disponible chez plusieurs fournisseurs eux-mêmes performants : Qwen 3 Embedding 8B.

À partir de là, deux stratégies sont possibles :

1. L'approche dynamique : on surveille les performances en temps réel et on envoie chaque requête chez le provider le plus performant du moment. Si une requête échoue chez l'un, on la renvoie chez l'autre.
2. L'approche "tous azimuts" : vu le faible coût économique et écologique des embeddings (on peut descendre en dessous du centime d'euro par million de tokens. Si cela ne vous parle pas, dites-vous que générer l’embedding coûte environ 200 fois moins cher qu’envoyer le même document à GPT 5.2 dans une requête), pourquoi se priver ? On envoie la requête chez plusieurs providers simultanément, et on prend la première réponse qui arrive.

C'est cette deuxième approche que nous avons retenue chez Ask This Guy.

Le résultat ? Des performances ultra-stables, aucune dépendance critique envers un seul fournisseur, et un coût qui reste très raisonnable.

Une leçon que chaque professionnel de l’IT connaît… mais qui est encore plus vraie avec l’IA

Faire un POC, c'est facile. La production, c'est une autre histoire.

Dans un POC, l'irrégularité ne se voit pas vraiment. Sur quelques requêtes, tout semble fonctionner. Mais en production, avec des utilisateurs réels, des volumes et des attentes élevées, chaque faiblesse devient évidente.

Mais la bonne nouvelle, c'est que avec de l'ingénierie et de la patience, on vient à bout de tous les sujets.

Notre démo ratée ? Elle nous a coûté un moment de gêne, mais elle nous a fait gagner une architecture beaucoup plus robuste. Et ça, ça n'a pas de prix.

---

Vous voulez en savoir plus sur notre approche RAG ou sur nos autres retours d'expérience en production IA ? N'hésitez pas à réserver une démo !