Pourquoi un assistant IA répond lentement : le modèle n'est pas toujours le problème

Un assistant peut produire une réponse exacte et rester inutilisable. Dans un outil de support, une équipe ne juge pas la qualité d'un modèle sur une démonstration préparée ; elle la juge au moment où un client attend, où un collaborateur cherche une procédure, ou lorsqu'un agent doit obtenir une information avant de poursuivre un dossier. À ce moment-là, « c'est lent » devient un problème métier. Encore faut-il savoir de quoi l'on parle.

Cette phrase désigne souvent cinq délais différents : la préparation de la demande, la recherche dans une base documentaire, l'appel au modèle, un appel à un logiciel tiers, puis l'affichage de la réponse. Les confondre conduit à acheter un modèle plus puissant pour compenser un connecteur lent, ou à raccourcir un prompt alors que le temps part dans une file d'attente. Le premier travail consiste donc à rendre visible la chaîne, pas à lancer une course aux benchmarks.

La documentation d'OpenAI sur l'optimisation de la latence propose une distinction utile : temps réel du système et temps ressenti par l'utilisateur ne se recouvrent pas toujours. Le streaming peut faire apparaître les premiers mots plus tôt, sans accélérer tout le traitement. Il améliore l'expérience, mais ne répare ni une recherche documentaire mal réglée ni une dépendance indisponible.

Une réponse lente est souvent une succession de petits délais

Prenons un assistant interne qui répond à partir d'un référentiel de procédures. Avant que le modèle ne rédige, l'application peut identifier l'utilisateur, vérifier ses droits, transformer sa question en requête de recherche, récupérer des passages, éventuellement les reclasser, assembler l'instruction et appeler le modèle. Si l'assistant peut ensuite ouvrir un ticket ou consulter le CRM, chaque outil ajoute sa propre attente. La réponse finale masque cette mécanique.

Le modèle compte, bien sûr. La taille du modèle, le nombre de tokens qu'il doit générer et la charge de l'infrastructure influent sur le délai. Mais une réponse longue pèse généralement davantage que quelques lignes supplémentaires dans l'instruction. La même documentation recommande de réduire d'abord la génération inutile, puis de limiter les requêtes séquentielles. Un assistant qui reformule trois fois une réponse avant de l'afficher est lent par conception, même si chacune de ses étapes est correcte.

Le contexte mérite un traitement moins instinctif. Mettre toute la base documentaire ou l'historique complet d'un échange dans chaque demande paraît rassurant : l'information sera bien quelque part. En pratique, cela augmente le volume traité et rend plus difficile la sélection de ce qui est pertinent. Les conseils d'Anthropic sur les contextes longs insistent sur l'organisation et le placement des documents dans une demande longue. La fenêtre de contexte n'est pas une autorisation à tout verser dans le modèle.

C'est un point particulièrement important pour un projet de développement IA sur mesure. Une base documentaire utile ne consiste pas à donner plus de texte au système. Elle impose de choisir les sources consultables, de découper les contenus de manière cohérente, de filtrer selon les droits et de conserver les passages réellement utilisés. Cette discipline améliore la vitesse, mais aussi la capacité à expliquer d'où vient une réponse.

Mesurer avant de corriger évite les fausses économies

Pour comprendre un ralentissement, il faut enregistrer des temps séparés : réception de la demande, recherche, reclassification éventuelle, construction du contexte, premier token, fin de génération, appels d'outils et réponse finale. Il faut les observer sur des cas fréquents comme sur les cas difficiles. Une moyenne flatteuse ne dit rien d'un pic qui immobilise les utilisateurs ; les percentiles, notamment le p95, donnent une image plus honnête de l'expérience.

La mesure doit être rapprochée du type de demande. Une question simple sur une règle stable peut être résolue par une réponse préparée ou une recherche directe. Une demande qui exige de croiser une procédure, un dossier et un statut dans l'ERP suit un autre chemin. Traiter les deux avec le même modèle, le même contexte et le même nombre d'appels est confortable pour l'architecture, rarement pour l'utilisateur.

Réduire le nombre d'étapes peut être plus efficace que d'optimiser chacune d'elles. Lorsque deux classifications sont indépendantes, elles peuvent être exécutées en parallèle. Lorsqu'une vérification n'est nécessaire que pour une minorité de cas, elle ne devrait pas bloquer toutes les demandes. À l'inverse, une action à conséquence ne doit pas être accélérée en supprimant le contrôle qui la rend sûre. La vitesse utile est celle qui respecte le parcours de travail, pas celle qui produit le premier texte le plus vite.

Le cadre de gestion des risques du NIST rappelle que l'évaluation d'un système ne se réduit pas à son modèle. Dans un assistant, cela vaut aussi pour la disponibilité des sources, les droits d'accès, les erreurs d'outil et la possibilité de basculer vers une réponse dégradée. Si le CRM ne répond pas, l'interface doit pouvoir dire qu'elle ne peut pas vérifier une information, plutôt que laisser croire que le modèle réfléchit encore.

Concevoir un délai acceptable pour chaque usage

La bonne cible dépend du travail. Pour un collaborateur qui prépare une synthèse, une réponse plus lente mais sourcée peut être acceptable. Pour un agent de relation client qui cherche une procédure pendant un appel, l'attente n'a pas le même coût. Pour un système qui déclenche une action, la rapidité passe après la possibilité de vérifier et d'arrêter le flux.

Cette distinction change la manière de concevoir des agents d'IA et d'automatisation. Un agent peut préparer en arrière-plan les informations nécessaires à un dossier, puis présenter une proposition à valider. Il n'a pas forcément besoin de répondre à tout instant ni d'agir dès le premier résultat. On gagne alors du temps là où il compte, sans transformer chaque attente en prise de risque.

Avant de remplacer un modèle, une entreprise peut donc poser trois questions simples : à quelle étape se forme l'attente, quels cas en souffrent réellement, et quelle réponse de secours reste honnête lorsque le système ne peut pas répondre vite ? Un cadrage IA sert précisément à relier ces mesures à un usage et à un niveau de service crédible. Le résultat n'est pas un assistant qui affiche une promesse de rapidité. C'est un outil dont l'équipe sait pourquoi il attend, quand il doit attendre, et quand il faut lui demander de s'arrêter.