Le problème du « prenez GPT-4 et n'en parlons plus »
La plupart des plateformes d'IA prennent une décision silencieuse à votre place : elles choisissent un modèle qui leur convient, branchent tout dessus et passent à autre chose. Cela marche jusqu'au moment où cela ne marche plus — jusqu'à la panne du modèle, jusqu'à ce qu'un concurrent sorte mieux sur une tâche précise, jusqu'à ce que vous vouliez apporter votre propre clé d'API et garder les coûts sur votre compte, jusqu'à ce que vous ayez besoin de générer des images et que votre modèle par défaut en soit incapable.
Le remède habituel est une liste déroulante. Choisissez un modèle, utilisez-le partout, débrouillez-vous avec les compromis. Ce n'est pas de l'acheminement, c'est de la délégation. ToRun fait quelque chose de structurellement différent.
Le pipeline axé capacités
Chaque requête dans ToRun traverse quatre étapes avant d'atteindre un modèle.
1. Le mode identifie la surface produit. Quand vous ouvrez une session Chat ou lancez une tâche de Recherche, vous choisissez un Mode. Le mode n'est pas qu'une étiquette d'interface : il porte un ensemble défini de capacités requises et optionnelles. Une tâche de Recherche a besoin d'outils (recherche web), de contexte long et de sortie structurée. Une session de chat de base n'a besoin que de génération de texte par défaut.
2. L'ensemble de capacités devient un filtre. ToRun tient un catalogue de modèles de nombreux fournisseurs — OpenAI, Anthropic/Claude, Google/Gemini, DeepSeek, xAI/Grok, Mistral et d'autres. Chaque entrée porte l'union des capacités réellement prises en charge : vision, outils, exécution de code, génération d'images, audio en entrée, audio en sortie, génération vidéo, embeddings, réordonnancement, diffusion temps réel, raisonnement, et plus. L'ensemble issu de l'étape un est confronté à ce catalogue. Les modèles qui ne satisfont pas toutes les capacités requises sont écartés.
3. Le classement prix-qualité désigne le gagnant. Parmi les modèles ayant passé le filtre, ToRun classe selon ce qu'est réellement la requête. Une question courte et simple est classée sur le coût, vous obtenez donc une réponse rapide et bon marché. Une question plus longue ou plus difficile est classée sur la capacité par unité de coût, avec un plancher de qualité. Un tour qui porte une image est classé sur la qualité de vision du modèle, pas sur le raisonnement par euro. Les exécuteurs de flux basculent en priorité qualité, car un pipeline automatisé qui tourne sans surveillance doit viser le meilleur résultat, pas le raccourci le moins cher. Les utilisateurs BYOK entrent différemment dans la tarification, puisque la requête passe par leur propre compte fournisseur.
4. Les chaînes de repli absorbent les défaillances fournisseur. Si le modèle retenu renvoie une erreur de service, le même pipeline est réexécuté en excluant ce modèle. Le deuxième meilleur modèle capable répond. Vous ne voyez aucune erreur, sauf si tous les candidats viables sont hors service.
Un exemple concret : vision plus outils
Supposons que vous colliez une capture d'écran et demandiez à ToRun de chercher sur le web du contexte sur ce qu'elle montre. Cette requête touche deux capacités à la fois : la vision (le modèle doit accepter une image en entrée) et les outils (le modèle doit pouvoir invoquer une fonction de recherche web).
Avec une approche mono-modèle, vous êtes coincé : votre plateforme prend en charge cette combinaison ou non. Avec l'acheminement par capacités, ToRun croise les deux exigences. Seuls les modèles dont la prise en charge de la vision ET de l'appel d'outils est confirmée survivent au filtre. Dans cette liste courte, le classement prix-qualité choisit le meilleur pour votre mode courant. Si le candidat principal est limité ou en panne, le suivant traite la requête sans que vous fassiez quoi que ce soit.
Cela compte en pratique : l'ensemble des modèles dotés de vision a beaucoup changé en un an et continuera de changer. L'acheminement par capacités fait que ToRun prend automatiquement en compte les modèles nouvellement ajoutés dès leur catalogage, sans aucune mise à jour de votre part.
Pourquoi cela l'emporte sur l'enfermement
Une plateforme mono-modèle n'a qu'une stratégie de repli : attendre que le fournisseur répare sa panne. Une plateforme axée capacités dispose d'un catalogue. Quand OpenAI a un incident, les requêtes qu'Anthropic ou Gemini peuvent servir y sont servies. Quand un nouveau modèle Mistral offre un meilleur rapport prix-qualité en sortie structurée, il entre dans le classement des modes concernés sans migration forcée.
La même logique vaut pour BYOK. Quand vous ajoutez votre propre clé d'API pour un fournisseur, cette identifiant est cantonné à l'intérieur de la couche d'acheminement. Les requêtes correspondant aux modèles capables de ce fournisseur peuvent tirer sur votre clé plutôt que sur le compte ToRun, déplaçant le coût vers votre relation fournisseur au palier de facturation approprié. Le pipeline d'acheminement ne change pas : seule change l'identifiant utilisé au moment de l'exécution.
Le compromis, c'est l'honnêteté : ToRun ne peut pas garantir que le modèle le moins cher est le plus intelligent pour votre tâche. Le classement est explicite — vous pouvez voir ce qui a été choisi et pourquoi, et vous pouvez passer outre. Cette transparence est le but. Chaque requête écrit un enregistrement de facturation avec le modèle utilisé, l'unité de tarification active à l'exécution et la ventilation du coût. Vous pouvez auditer n'importe quel appel des mois plus tard, même après un changement de tarif fournisseur, car l'instantané est figé au moment où la requête a tourné.
Un modèle qui fait tout est une fiction confortable. Ce que vous voulez vraiment, c'est une plateforme qui trouve le bon modèle pour chaque tâche et rend ce choix lisible.