Quand l'inférence devient moins chère : concevoir des agents qui vérifient davantage
Le prix d’une requête n’est pas un détail d’achat. Il influence directement les comportements qu’une équipe peut se permettre dans un système agentique : une seconde passe, une vérification indépendante, plusieurs hypothèses ou une demande d’aide humaine pour les cas ambigus.
Cette observation vaut pour tout fournisseur et tout modèle. Une annonce commerciale peut signaler un nouveau candidat à tester, mais elle ne suffit pas à établir que ce candidat est meilleur, moins coûteux pour une charge précise ou adapté à une politique de données donnée. Les pages officielles et les cartes de modèles sont un point de départ ; les conclusions exigent un protocole public ou reproductible.
Les benchmarks sont des instruments
SWE-bench présente des tâches issues de problèmes logiciels réels et publie des classements avec des définitions précises de ses mesures. C’est utile parce que la mesure est encadrée. Ce n’est pas une note générale d’intelligence, ni une garantie sur un dépôt, un langage ou une chaîne d’outils différente.
Les résultats peuvent varier selon le harnais, les outils autorisés, les limites de temps, les modèles de messages et la méthode de validation. Lire un score sérieusement consiste à lire sa configuration, pas seulement sa position dans un tableau.
Réinvestir la marge
Quand l’inférence devient plus accessible, la réponse saine n’est pas nécessairement de lancer plus d’agents. C’est d’allouer une partie de la marge à la qualité : vérification des sources, tests de sortie structurée, comparaison de solutions et journalisation des décisions. Un système qui produit deux réponses indépendantes puis explique leur désaccord peut être plus utile qu’un système qui répond une fois avec une confiance excessive.
La vitesse compte aussi, mais elle n’est pas seule. Une boucle rapide qui appelle un outil de façon incorrecte ou transforme une donnée ambiguë en décision sûre peut coûter plus cher qu’une boucle plus lente avec des contrôles explicites.
Choisir avec des contraintes déclarées
Avant de sélectionner un modèle, il faut formuler les exigences : données autorisées, budget, latence, disponibilité, tâches, format de sortie et niveau de supervision humaine. Les poids accessibles publiquement et les API répondent à des contraintes différentes ; aucun mode de distribution n’est supérieur par défaut.
Le vrai progrès n’est pas de prétendre qu’un modèle rend l’autonomie gratuite. C’est de rendre abordables des pratiques qui augmentent la fiabilité : vérifier, comparer, corriger et savoir s’arrêter.