Le piège du modèle unique
Tous les grands fournisseurs d'IA veulent vous faire croire que leur modèle phare est la bonne réponse à toute question. Cette croyance leur est commercialement commode et vous est techniquement fausse.
Un modèle qui excelle dans le raisonnement juridique à contexte long n'est pas le bon pour produire une légende de dix mots. Un modèle doté d'une vision de pointe est surdimensionné — et probablement trop cher — pour un traitement par lots qui reformate du JSON structuré. Un modèle dont le prix est optimisé pour le débit peut être le pire choix possible quand vous avez besoin d'une réponse en deux secondes.
Quand vous construisez sur un modèle unique, vous ne choisissez pas le meilleur outil. Vous choisissez le meilleur outil disponible à l'intérieur d'une contrainte artificielle. Avec le temps, cette contrainte s'accumule : vous payez trop pour les tâches simples, vous êtes en deçà sur les complexes, et quand ce fournisseur subit une panne ou une hausse de tarifs, tout votre produit s'arrête.
Des capacités, pas des noms
La bonne abstraction n'est pas « quel modèle », mais « de quelles capacités cette requête a-t-elle besoin ». Cette question a une réponse précise.
Un message de chat avec une capture d'écran a besoin de vision. Une étape de flux qui appelle une API externe a besoin d'outils. Un assistant de code censé vérifier sa propre sortie a besoin d'exécution de code. Un pipeline de résumé nocturne qui n'a pas besoin d'être rapide peut utiliser une tarification par lots ; un assistant intégré au produit, avec un utilisateur qui attend, non.
Quand vous énumérez d'abord les exigences de capacité, la sélection de modèle devient un problème de filtrage et de tri. Étant donné un ensemble requis — disons texte, vision et sortie structurée — vous trouvez tous les modèles qui prennent en charge les trois, puis vous les triez selon la qualité et le prix pour le contexte courant. Ce tri peut changer d'une requête à l'autre selon ce que fait l'utilisateur et l'état de ses fonds.
C'est exactement ce que fait le pipeline d'acheminement de ToRun. Le mode (Chat, Code, Image, Recherche et autres) correspond à un ensemble de capacités. L'ensemble filtre le catalogue de modèles. Le classement prix-qualité désigne le gagnant. Résultat : vous pouvez utiliser DeepSeek pour de l'extraction structurée à gros volume, Claude ou des modèles de classe GPT-4 pour du raisonnement nuancé, Google Gemini pour du travail documentaire à long contexte et un modèle d'image spécialisé pour la génération — le tout depuis la même surface produit, sans écrire vous-même la logique de répartition.
Le repli n'est pas un supplément agréable
Les pannes de fournisseur ne sont pas des cas rares. Elles surviennent plusieurs fois par mois à l'échelle du secteur. Si votre produit dépend d'un fournisseur unique et que son API se dégrade, votre produit se dégrade avec elle.
Une chaîne de repli est le minimum opérationnel : quand le modèle principal renvoie une erreur transitoire pour une requête, la plateforme la réessaie avec le meilleur modèle apte suivant. Cela suppose que la couche d'acheminement sache déjà quels modèles sont aptes — c'est précisément ce qu'apporte l'acheminement par capacités.
Le repli a un autre bénéfice moins évident : il garde votre comportement de facturation prévisible. Si le modèle de premier choix dépasse temporairement une limite d'usage, bifurquer vers le modèle apte suivant maintient le coût dans une plage sans montrer d'erreur à l'utilisateur.
La conclusion pratique
Quand vous évaluez des plateformes d'IA, posez deux questions : comment choisit-elle un modèle pour chaque requête, et que se passe-t-il quand ce modèle est indisponible ou trop cher ?
Si la réponse à l'une ou l'autre est « elle prend toujours le modèle X », c'est une odeur architecturale. Les modèles disponibles aujourd'hui ne sont pas les meilleurs modèles qui existeront dans six mois. De nouveaux fournisseurs apparaissent. Les prix bougent. Les frontières de capacité se déplacent. Une architecture qui traite le choix du modèle comme un problème d'acheminement — et non comme une décision de configuration — vieillit mieux, coûte moins cher dans la durée et se dégrade plus élégamment sous pression.
Un modèle est un point de départ. Une couche d'acheminement est la vraie fondation.