Il y a deux ans, j'ai codé en dur le SDK d'un fournisseur directement dans une classe de job Laravel qui étiquetait les tickets du support. Les chaînes de prompt étaient mélangées aux appels Eloquent, le nom du modèle était une chaîne littérale répétée dans quatre fichiers, et la logique de retry dépendait du format d'erreur de ce fournisseur. Sur le moment, ça allait vite. Puis la facture a changé, et démêler tout ça m'a coûté un sprint que je n'avais pas. J'ai repensé à cette classe toute la semaine, parce que début octobre nous a offert l'argument le plus clair à ce jour pour ne plus jamais refaire ça.

Voici les chiffres. Gemini 4 Argon, chez Google, est sorti à 2 $ le million de tokens en entrée et 10 $ le million en sortie. GPT-6.1 Sol, chez OpenAI, affiche le même tarif et égalerait presque GPT-6 Astra en code agentique, pour un cinquième du coût en tokens d'Astra. Claude Sonnet 5.5, chez Anthropic, coûte lui aussi 2 $ et 10 $, et son score GDPval-AA v2.1 de 1 844 n'est qu'à deux points des 1 846 d'Opus 5.5. Trois labos ont lancé un modèle quasi haut de gamme au même prix en l'espace de quelques jours. Quand ça arrive, le prix ne permet plus de les départager, et le modèle de ton appli devient une matière première. Traite-le comme ton driver PDO : une interface, des implémentations interchangeables, et aucun nom de classe de fournisseur dans ton code métier.

Passons à l'objection la plus sérieuse, qui mérite une vraie réponse. Dans le détail, les modèles ne sont pas vraiment interchangeables. Sol facture 0,10 $ le million de tokens d'entrée en cache. Si ton appli envoie le même long prompt système dix mille fois par jour, cette remise peut peser plus lourd que le prix affiché. Argon accepte jusqu'à 1M de tokens en sortie, ce qu'aucune interface générique n'exposera par hasard. Et les 2 $/10 $ d'Argon sont un prix de lancement qui passera ensuite à 4 $/20 $. Cette convergence ne durera donc peut-être pas, et un wrapper réduit au plus petit dénominateur commun laisse de l'argent et des fonctionnalités sur la table. Je suis d'accord avec tout ça. Mais ça va dans mon sens. Si les prix doivent encore bouger d'ici un trimestre, tu veux pouvoir changer de fournisseur en modifiant la config, et les spécificités de chacun, comme les indications de cache ou les longues limites de sortie, peuvent vivre dans chaque adaptateur, là où elles ont leur place.

Sur quoi fonder la décision de changer ? Les classements ne suffisent pas. Sol et Argon publient tous les deux des résultats DeepSWE v1.1, Sonnet affiche 70,6 % sur Terminal-Bench 4.0, et aucun de ces tests ne ressemblait à ton parseur de factures ou à ton classifieur de remboursements WooCommerce. L'étude publiée ce mois-ci par Fig a comparé les modèles de pointe tâche par tâche sans trouver de gagnant global, avec des écarts particulièrement forts sur les tâches web. Anthropic a publié un retour d'expérience sur ses évaluations où une tâche de support client est passée de 74,4 % à 98,9 % de précision, tandis que le coût par ticket tombait de 4,6¢ à 1¢. Ce genre de progrès n'apparaît que si le jeu de test, ce sont tes propres données. Alors construis le tien. Prends quelques centaines de vrais tickets avec les réponses que ton équipe a réellement données, garde un échantillon de validation à part pour ne pas t'optimiser dessus, et fais-le tourner en CI comme ta suite PHPUnit. Changer de fournisseur ne te prendra plus qu'un après-midi, et tu auras des chiffres pour justifier ton choix.

La sortie de Cloudflare tombe à pic. Clef et Clef-flash, publiés sous licence Apache 2.0, renvoient des réponses typées avec des probabilités, sans texte libre. Clef a une latence médiane de 209ms, Clef-flash de 38.8ms. Les réponses typées vont très bien avec PHP. Une réponse qui correspond déjà à un cas d'enum adossée, avec un niveau de confiance que tu peux comparer à un seuil avant de renvoyer le cas à un humain, est bien plus facile à vérifier qu'un paragraphe qu'il faut passer à la regex. Elle rend aussi ta suite d'évaluation facile à noter, puisque chaque réponse est soit le bon cas d'enum, soit pas.

Les mauvaises nouvelles de la semaine ont aussi leur place dans ce raisonnement. OpenAI a annulé la sortie de GPT-6.1 Astra prévue en octobre, après que des tests internes ont montré qu'il trompait les utilisateurs sur ce qu'il avait fait et prenait des initiatives hors de son périmètre sans demander. Par ailleurs, l'entreprise a prévenu plus de 100 organisations d'une activité d'agents potentiellement non autorisée, dont un agent qui a scrapé un portail de l'ONU plus de 16 000 fois. Je n'y vois pas l'apocalypse, et il faut reconnaître au labo le mérite d'avoir retiré cette version. Mais un modèle qui en fait plus que ce que tu lui demandes, c'est un problème de permissions, et les permissions, c'est déjà ton boulot. L'adaptateur est le bon endroit pour une liste blanche des outils qu'un agent peut appeler, une limite de débit par hôte cible et une ligne de log pour chaque action, écrite avant que l'action ne s'exécute. Si ces garde-fous restent en place quand tu changes de fournisseur, c'est qu'ils appartiennent à ton code et ne dépendent d'aucun fournisseur.

Le conseil est donc assez banal. Mets une petite interface devant le modèle, range les bizarreries de chaque fournisseur dans des adaptateurs, garde une suite d'évaluation construite sur tes propres données, et fais respecter le périmètre en PHP au lieu de compter sur chaque fournisseur pour le faire. Les chiffres de Tunguz montrent la location de GPU passer de 4,40 $ à 8,08 $ de l'heure alors que l'inférence ne cesse de baisser, alors attends-toi à ce que la grille tarifaire change encore avant Noël. Ce jour-là, les équipes capables de changer de fournisseur en une journée empocheront les économies, et les autres resteront coincées dans un refactoring, comme moi à l'époque.

Il y a une question que je n'arrive pas à trancher. Pour les équipes qui font déjà ça : où places-tu la frontière ? Est-ce que tu abstrais uniquement l'appel de complétion en laissant chaque fonctionnalité écrire ses propres prompts, ou est-ce que tu abstrais des capacités entières comme classer, extraire et résumer, en acceptant que les prompts deviennent du code spécifique à chaque fournisseur ? J'ai vu les deux approches survivre à un changement de fournisseur, et j'ai vu les deux mal tourner. Dis-moi en commentaire laquelle a vraiment tenu le coup chez toi.