Chasser le bon modèle : un tableau plutôt qu'une intuition

TL;DR — Pour choisir un modèle selon la tâche, on a construit un comparateur : une sonde qui mesure latence et débit sur chaque modèle, un catalogue qui sert de source de vérité, et un tableau interactif régénérable. Le plus instructif n'est pas le classement — c'est que les modèles inventent leur propre identité quand on la leur demande, et que deux bugs classiques de remplacement de chaînes ($ interprété, variables insensibles à la casse) peuvent produire un fichier qui a l'air correct mais ne l'est pas.

Le problème : trop de modèles, aucun critère

Quand on branche un catalogue de modèles à un agent, la première question revient toujours : lequel lancer ? Le rapide, le malin, le pas cher ? Sur le papier, chaque modèle a une fiche — mais les fiches sont écrites par ceux qui les vendent. Et une fois qu'on en a une quinzaine disponibles, on choisit à l'intuition, c'est-à-dire mal.

La règle de la maison est simple : mesurer avant de déduire. On a donc transformé « lequel est le meilleur ? » en un travail de mesure.

Le geste : une sonde, pas une croyance

On a écrit une sonde qui, pour chaque modèle, envoie un prompt identique et enregistre :

• le débit de sortie (tokens par seconde),
• la latence murale de la réponse,
• la présence (ou non) d'un mode « réflexion »,
• la réponse brute, pour mémoire.

Point de méthode : certains fournisseurs cloud ne renvoient pas la durée d'évaluation interne dans la réponse. On ne l'invente pas — on calcule le débit au temps mural, moins précis mais honnête, et on l'écrit noir sur blanc dans la note du tableau.

Une fois les mesures en main, on complète avec des données publiques et datées : un indice d'intelligence agrégé (Artificial Analysis), le contexte maximal et les tarifs (fiches Ollama). Le tableau final croise donc deux natures de faits : ce qu'on a mesuré sur la machine, et ce que des tiers ont publié — chaque cellule disant d'où elle vient.

Le piège : les modèles mentent sur leur identité

La sonde demandait à chaque modèle de s'auto-identifier en JSON. Résultat : treize réponses parsables sur seize, et presque toutes fausses sur l'auteur.

Un modèle de DeepSeek s'est présenté comme « Claude, d'Anthropic ». Un modèle d'OpenAI s'est dit « GPT-4o ». Un modèle de Google s'est dit « GPT-4o » aussi. Un modèle de Mistral s'est décrit comme « Llama-3.1-8B, de Meta ». Bref : interrogés sur eux-mêmes, les modèles hallucinent avec assurance.

La conséquence est directe : l'identité ne se demande pas au modèle. On l'a prise du catalogue (la fiche officielle), et on a conservé les réponses de la sonde uniquement pour ce qu'elles prouvent vraiment — la latence et le débit. C'est un renversement utile : la même requête peut être fiable pour une dimension et trompeuse pour une autre.

Ce que la mesure a montré

Quelques ordres de grandeur, à la date du relevé :

• Le plus rapide est un modèle « flash » qui approche les deux cents tokens par seconde tout en gardant un contexte d'un million de tokens — le profil idéal pour un agent qui traite beaucoup d'entrée.
• Le plus intelligent (selon l'indice public) est un flagship qui, lui, tourne deux à trois fois plus lentement — et coûte beaucoup plus cher en sortie.
• Le meilleur rapport qualité/prix arrive juste derrière en intelligence pour une fraction du prix — la vraie surprise du relevé, et le genre de chose qu'on ne voit pas sans chiffres côte à côte.
• Le local (sur une carte 16 Go) reste le plus lent, mais il est gratuit et hors ligne : un point qu'aucune fiche cloud ne montre.

La conclusion pratique n'est pas « tel modèle gagne ». C'est une table de routage : un modèle pour coder un projet entier, un autre pour la vitesse pure, un autre pour les cas les plus durs, un dernier quand il faut économiser. Le bon modèle dépend du besoin — encore faut-il l'avoir écrit.

Rendre le tout rejouable

Un tableau figé dans un fichier devient faux en une semaine. On a donc séparé trois choses :

1. un catalogue versionné — la liste des modèles et leurs caractéristiques, la source de vérité ;
2. un gabarit de tableau interactif (triable, filtrable, avec des graphiques dessinés à la main, sans bibliothèque externe) ;
3. un constructeur qui fusionne la sonde du jour dans le catalogue et produit une page autonome.

Le résultat n'est pas un document, c'est un geste : on relance la sonde, on relance le constructeur, et le tableau reflète l'état réel. Le fichier produit vit à part, comme brouillon local — c'est la procédure qui est versionnée, pas l'instantané.

Les deux bugs qui ont failli corrompre le travail

Deux erreurs classiques, qui valent d'être notées parce qu'elles mentent sur leur résultat :

• Le $ interprété. Injecter un catalogue JSON dans un gabarit en le passant comme chaîne de remplacement fait interpréter les $ : une séquence comme $' ou $1 devient un rétro-référence, et le fichier généré est silencieusement corrompu. Ce n'est pas le code qui échoue bruyamment — c'est la sortie qui est mal formée. La parade : un remplacement littéral (ou une fonction de remplacement), jamais une chaîne construite par concaténation.
• La variable fantôme. En PowerShell, les variables sont insensibles à la casse : $Catalog (le chemin d'entrée) et $catalog (l'objet désiré) sont le même nom. La ligne de lecture était juste ; c'est une ligne ultérieure qui écrasait la variable. Le symptôme trompeur : un type qui repasse en « String » sans prévenir. La parade : des noms distincts.

Les deux ont été trouvés, corrigés, et transformés en règles durables — avec leur provenance.

La leçon

Choisir un modèle ne devrait pas être une affaire d'impression. On a remplacé « je crois que celui-ci est mieux » par un tableau qu'on peut rejouer : des faits mesurés, des sources datées, une frontière claire entre le mesuré et le publié. Et un rappel de plus, qui n'a rien d'informatif : ne jamais demander à un outil de se décrire lui-même. Mesurer, oui ; croire sa déclaration, non.