Pourquoi la latence détermine l’architecture des systèmes d’AI plus que la précision du modèle

La latence est l'une des forces les plus sous-estimées dans la conception des systèmes d'IA. Alors que les ingénieurs rivalisent sur la précision et l'intégrité des données d'entraînement, la réalité de la production établit des priorités différentes : une réponse lente tue le produit plus vite qu'une rare erreur du modèle.

Les métriques d'entraînement ne sont pas égales aux métriques de produit

Pendant le développement, la principale mesure de la qualité est l'accuracy, la precision, le recall et le F1-score. Ce sont les bonnes métriques pour évaluer l'intelligence du système — mais elles ne disent rien sur la façon dont l'utilisateur perçoit le produit dans des conditions réelles. Les équipes le remarquent souvent seulement après le lancement : un test A/B montre une haute accuracy, mais les utilisateurs se plaignent de "ralentissement" — et la rétention baisse.

Les recherches UX montrent : les utilisateurs sont prêts à attendre au maximum 200–300 millisecondes avant de commencer à ressentir du "lag". À un délai d'une seconde, l'attention se détourne. À un délai de plus de trois secondes, une partie importante de l'audience ferme simplement l'onglet.

Cette asymétrie est de nature commerciale : la précision du modèle affecte la rétention du public lentement et indirectement, tandis que la latence frappe les métriques instantanément.

"Même le système d'IA le plus intelligent devient très ennuyeux si la

réponse arrive trop tard" — c'est pourquoi la latence détermine souvent l'architecture dans une plus grande mesure que toute autre décision de conception.

Comment la latence change les décisions architecturales

L'exigence de latence affecte chaque niveau du système — du choix du modèle de base à l'infrastructure de déploiement. Un architecte qui conçoit un produit d'IA avec un SLA de 200 ms prend des décisions fondamentalement différentes de celui qui travaille avec un SLA de 5 secondes.

Les compromis typiques dictés par la latence :

• Taille du modèle — les plus grands modèles sont plus intelligents mais plus lents ; il faut souvent choisir une version distillée ou quantifiée
• Streaming de tokens — au lieu d'attendre une réponse complète, l'utilisateur voit le texte au fur et à mesure de sa génération, la vitesse perçue est beaucoup plus élevée
• Mise en cache — les requêtes répétées sont servies depuis le cache sans inférence, la latence tombe à quelques millisecondes
• Architectures en cascade — les requêtes simples sont traitées par un modèle léger, les complexes par un grand ; un routeur décide à la volée
• Positionnement géographique — les serveurs plus proches des utilisateurs réduisent la latence réseau, qui consomme des centaines de millisecondes même pour un modèle rapide

Outils pour réduire la latence

La quantification réduit la précision du stockage des poids de 32-bit à 8-bit ou 4-bit — le modèle fonctionne plus vite, avec une perte mineure de qualité de réponse. L'élagage supprime les connexions non significatives, réduisant le modèle sans réentraînement. La combinaison de ces techniques permet de déployer des modèles plus puissants sous des exigences strictes de latence.

Au niveau de l'inférence, le batching permet de traiter plusieurs demandes simultanément, réduisant le coût moyen de chacune. Les accélérateurs spécialisés — GPU, TPU, NPU — réduisent le temps des opérations matricielles des dizaines de fois par rapport au CPU.

Une classe de solutions séparée et puissante est l'optimisation du prefill : si tous les utilisateurs ont le même prompt système, ses activations peuvent être calculées à l'avance et réutilisées pour chaque demande. C'est le principe derrière le prompt caching dans les APIs LLM modernes — cela économise non seulement de l'argent mais aussi des centaines de millisecondes de latence.

Ce que cela signifie

La latence n'est pas un détail technique mais une décision de produit de premier niveau. Avant de choisir l'architecture et le modèle, l'équipe doit fixer le SLA de latence pour chaque cas d'usage. Cette exigence imprègne ensuite tous les niveaux : de la taille du modèle et de la méthode d'inférence à l'infrastructure et aux modèles UX.

Les systèmes conçus "à partir de la précision" doivent souvent être réécrits lorsqu'on découvre que les utilisateurs ne vont simplement pas attendre la réponse.