Routing intelligent des LLM en PHP : pourquoi votre modèle le plus cher n'est pas toujours la bonne réponse

Introduction

Quand une PME intègre un LLM dans son application métier, le réflexe le plus naturel consiste à envoyer toutes les requêtes vers le modèle le plus puissant — donc le plus coûteux — disponible sur le marché. C'est confortable sur le plan technique, mais c'est aussi le meilleur moyen de voir sa facture API grimper inutilement, alors qu'une bonne partie des prompts envoyés ne nécessitent pas une telle puissance de calcul.

C'est exactement la question que Valerio, créateur du package Neuron AI, a reçue à de très nombreuses reprises après la sortie de son routeur LLM officiel : « peut-on envoyer les requêtes difficiles au modèle puissant, et les requêtes simples au modèle bon marché ? » Une demande logique, presque évidente. Et pourtant, comme il l'explique dans son article original sur dev.to, c'est aussi la seule règle qu'il n'a jamais réussi à écrire proprement en code.

Ce billet revient sur ce constat, et sur la philosophie que nous défendons chez MulerTech : l'ère de l'IA « brute », où l'on jette un prompt vers le modèle le plus chic disponible, est en train de s'achever. Place à une IA architecturée, pensée et orchestrée directement dans le code PHP.

Le problème : qu'est-ce qu'un prompt « difficile » ?

Un routeur de LLM, dans son principe, est simple : on enregistre plusieurs fournisseurs (OpenAI, Anthropic, un modèle open-source auto-hébergé...), on définit une règle, et l'agent applicatif n'a même pas conscience qu'il parle à un proxy plutôt qu'à un modèle unique.

Le souci, c'est que cette règle doit retourner un nom de fournisseur, et pour cela, elle doit juger la difficulté du prompt. Or « difficile » est un mot qui fonctionne très bien à l'oral, dans une conversation entre développeurs, mais qui n'a aucune définition exécutable. C'est un concept qui fait beaucoup de travail dans la discussion, et absolument aucun dans l'éditeur de code.

Les fausses bonnes idées pour mesurer la difficulté

Lorsqu'on cherche des solutions existantes, on retrouve toujours les mêmes approximations, et toutes souffrent des mêmes limites.

La première consiste à router selon la longueur du prompt, en partant du principe que plus c'est long, plus c'est complexe. En pratique, c'est faux : une question d'une seule ligne sur un point précis de droit des contrats italien est courte, mais redoutablement difficile, tandis qu'un long log technique collé tel quel à résumer est trivial. La longueur mesure la frappe au clavier, pas la complexité intellectuelle de la tâche.

La seconde approche repose sur une liste de mots-clés : tout prompt contenant « juridique », « code » ou « calculer » est envoyé vers le modèle premium. Cette solution fonctionne... pendant une semaine. Ensuite, il faut maintenir un dictionnaire sans fin, elle passe à côté de toute formulation non anticipée, et elle n'a strictement aucun avis sur les prompts qui ne contiennent aucun des mots surveillés mais qui sont pourtant complexes.

Dans les deux cas, le symptôme est le même : on essaie de remplacer un jugement par une heuristique de surface, et l'heuristique finit toujours par trahir l'intention initiale.

L'approche MulerTech : architecturer l'intelligence plutôt que la subir

La vraie solution n'est pas de chercher une meilleure heuristique, mais de déplacer la décision dans le code lui-même, sous forme d'une étape explicite et testable : un classifieur.

L'idée est simple à exprimer mais puissante dans ses effets : avant d'envoyer le prompt au modèle final, on le fait passer par un petit modèle (rapide, bon marché, voire local) dont le seul rôle est de répondre par une étiquette — « facile » ou « difficile » — et c'est cette étiquette qui pilote ensuite le choix réel du fournisseur.

$router = new Router([
    'premium' => new OpenAIProvider('gpt-4'),
    'standard' => new OpenAIProvider('gpt-3.5-turbo'),
]);

$router->classifyWith(function (string $prompt) use ($classifier) {
    $label = $classifier->classify($prompt); // appel rapide à un modèle léger

    return $label === 'hard' ? 'premium' : 'standard';
});

$response = $router->chat($prompt);

Ce schéma a trois avantages immédiats que ni la longueur ni les mots-clés ne peuvent offrir. D'abord, il est explicite : la logique de classification est un composant à part entière, que l'on peut tester unitairement comme n'importe quelle autre brique métier. Ensuite, il est évolutif : on peut affiner le classifieur, l'entraîner sur des exemples réels, ou le remplacer sans toucher au reste de l'architecture applicative. Enfin, il isole le coût : le classifieur lui-même utilise un modèle très bon marché, et seul le second appel — le vrai traitement — bascule éventuellement vers le modèle onéreux, et uniquement quand c'est justifié.

Pourquoi cette logique compte particulièrement pour une PME

C'est précisément ce type d'architecture que nous défendons chez MulerTech pour nos clients PHP/Symfony. Une PME n'a généralement pas vocation à payer le tarif du modèle le plus avancé pour résumer un email ou reformuler une phrase. En revanche, elle ne peut pas non plus se permettre de dégrader systématiquement la qualité des réponses sur des cas réellement complexes, sous peine de perdre la confiance de ses utilisateurs.

Intégrer un classifieur directement dans le code PHP, plutôt que de s'appuyer sur des règles fragiles et non maintenables, permet de concilier les deux : un outil performant quand il le faut, scalable à mesure que le volume de requêtes augmente, et économiquement viable sur la durée, parce que chaque appel coûteux est justifié et traçable.

C'est toute la différence entre une IA « brute », qui consiste à brancher une API sur une application et à espérer que ça suffise, et une IA architecturée, où l'intelligence du modèle est encadrée par une logique métier réfléchie, écrite et maintenue comme le reste du code.

Conclusion

La question posée à Valerio — « pouvez-vous router les prompts difficiles vers le modèle puissant ? » — n'avait pas de réponse simple parce qu'elle posait en réalité une question d'architecture, pas une question d'API. La longueur et les mots-clés sont des raccourcis qui masquent ce problème sans le résoudre. Un classifieur explicite, lui, transforme une intuition floue en composant logiciel testable et évolutif.

Chez MulerTech, c'est cette approche que nous privilégions : faire entrer l'intelligence artificielle dans une discipline d'ingénierie logicielle classique, plutôt que de la traiter comme une boîte noire magique. Pour aller plus loin sur le sujet et découvrir l'implémentation complète proposée par Neuron AI, nous vous invitons à consulter l'article original de Valerio sur dev.to.