Pivoa
L'essentiel à retenir
Comparer deux modèles dans deux environnements différents ne compare pas deux modèles. On mesure un mélange : moteur, outils, contexte, routage et habitudes de l’équipe.
Pour une PME belge de 10 à 50 personnes, le protocole utile tient sur une règle : faire varier le modèle et garder le reste aussi constant que possible. Même tâche représentative. Même contexte de départ. Mêmes outils autorisés. Même procédure de revue. Puis consigner le modèle, le fournisseur et le mode de routage réellement utilisés.
Clodex sert ici de banc d’essai. Le projet relie Claude Code à des modèles OpenAI, par clé API ou authentification OAuth ChatGPT/Codex, ainsi qu’à certains fournisseurs compatibles OpenAI. Les modèles routés peuvent intervenir comme moteur principal ou dans des sous-agents, des workflows et des équipes d’agents. Cette continuité facilite une comparaison dans le même atelier.
Elle ne garantit pas un test juste. Il faut encore cadrer les données envoyées, lire les coûts chez chaque fournisseur, organiser une revue humaine, fixer une règle d’arrêt et archiver la décision. Le bon résultat n’est pas un classement universel. C’est une décision que l’équipe peut expliquer et refaire.
Le problème que ça résout
Une démonstration peut faire gagner presque n’importe quel modèle. Il suffit de lui donner la tâche qui lui convient, un contexte mieux préparé ou davantage de reprises. Ce qui ressemble à une comparaison devient alors une mise en scène.
Le biais est plus discret dans un workflow agentique. Le modèle ne répond pas seul dans une fenêtre vide. Il reçoit des instructions, appelle des outils, délègue parfois à des sous-agents et produit un résultat que des humains relisent. Si l’équipe change plusieurs de ces éléments à la fois, elle ne sait plus ce qui explique l’écart observé.
Imaginez un premier essai avec un contexte propre, des droits complets et un développeur familier de l’environnement. Le second reçoit un historique encombré, rencontre un outil indisponible et passe entre les mains d’une autre personne. Même si le second résultat déçoit, le modèle n’est pas forcément en cause. Le protocole l’est.
Pour une petite structure, ce flou coûte cher. Quelques collègues mobilisés sur un mauvais test suffisent à produire une décision fragile : adopter le moteur le plus spectaculaire, écarter celui qui a été mal configuré ou garder toutes les options faute de conclusion. L’équipe paie alors plusieurs fournisseurs et entretient une complexité qu’elle n’a jamais choisie.
La question utile est donc précise : à conditions comparables, quel modèle aide le mieux l’équipe sur les tâches qui comptent, dans les limites de coût, de sécurité et de supervision qu’elle peut assumer ?
Cette formulation évite aussi le piège du palmarès général. Un modèle peut être convaincant pour analyser une base de code et moins adapté à une correction bornée. Un autre peut produire une sortie correcte, mais demander une reprise humaine trop lourde. La décision appartient au workflow réel, pas à une réputation abstraite.
Ce que c'est concrètement
Clodex est une couche de routage entre Claude Code et d’autres modèles. La documentation du projet décrit un proxy sélectif et un endpoint local. Dans le premier mode, elle indique que les requêtes Anthropic passent inchangées et que les modèles Clodex sont envoyés vers le fournisseur configuré. Dans le second, Claude Code utilise un endpoint local pour joindre les modèles routés.
Ce dispositif est intéressant pour une comparaison parce qu’il maintient un environnement d’exécution commun. Les outils, les instructions et l’organisation du travail peuvent rester identiques pendant que le moteur varie. Clodex permet aussi d’affecter des modèles routés au rôle principal, à des sous-agents, à des workflows ou à des équipes d’agents.
Cette souplesse crée cependant une obligation de traçabilité. Écrire seulement « modèle A » dans un compte rendu ne suffit pas. Une exécution doit être rattachée au modèle sélectionné, au fournisseur qui a traité la requête et au mode de routage actif. Si un sous-agent intervient, son rôle doit aussi apparaître. Sinon, une sortie apparemment produite par un moteur peut dépendre d’un autre à une étape décisive.
Le gestionnaire d’identifiants du système accueille les accès, selon la documentation du projet. C’est une information sur leur stockage local, pas une politique de données. L’entreprise reste responsable des dépôts autorisés, des informations qui peuvent quitter son environnement, des personnes habilitées à configurer les fournisseurs et de la révocation des accès.
Deux limites documentées influencent directement le protocole. L’affichage du coût dans Claude Code peut être inexact pour les modèles tiers routés. En mode endpoint local, la fenêtre de contexte affichée ne reflète pas forcément un changement de modèle. Une équipe qui ignore ces limites risque d’attribuer au moteur un coût ou un échec provenant de son dispositif de mesure.
Clodex fournit donc le banc. Le protocole fournit la comparaison.
Comment s'en servir
Une comparaison exploitable commence avant la première exécution. Elle se termine quand une décision est prise, documentée et assortie de conditions de réexamen.
Étape 1 : formuler une hypothèse décisionnelle
Écrivez la décision que le test doit éclairer. Par exemple : choisir le moteur principal pour préparer de petites modifications sous revue humaine, ou sélectionner un modèle pour un sous-agent chargé d’analyser une régression.
L’hypothèse doit désigner un usage, pas proclamer qu’un modèle est « meilleur ». Elle doit aussi préciser ce qui ferait préférer une option : une sortie plus juste, un meilleur respect des contraintes, une explication plus utile à la revue ou moins de reprises nécessaires. Aucun score inventé. Des critères observables, décrits avant le test.
Étape 2 : constituer des tâches représentatives
Prenez des tâches issues du travail courant, débarrassées des données qu’il ne faut pas transmettre. Le lot doit couvrir les situations qui influencent vraiment la décision : compréhension d’un composant, modification limitée, recherche de cause ou préparation d’une revue, selon le rôle évalué.
Évitez la tâche spectaculaire choisie après avoir vu les résultats. Évitez aussi le cas artificiel trop propre. Le test doit ressembler au travail que l’équipe confiera réellement à l’agent, avec ses contraintes et ses zones d’ambiguïté raisonnables.
Pour chaque tâche, préparez une fiche de départ : objectif, éléments fournis, outils permis, résultat attendu et motifs de rejet. La fiche devient le contrat commun des essais.
Étape 3 : geler les variables de comparaison
Gardez constants le prompt de départ, les instructions du projet, le contexte fourni, les outils accessibles, les permissions, le rôle des sous-agents et la procédure de validation. Lancez les essais depuis un état comparable afin qu’un historique précédent ne favorise pas une option.
Lorsque la capacité d’un modèle impose une adaptation, ne la cachez pas. Documentez-la comme une variante du protocole. L’équipe pourra alors distinguer la comparaison stricte, menée à cadre constant, de la comparaison optimisée, où chaque moteur reçoit une configuration adaptée. Mélanger les deux produit une conclusion illisible.
Étape 4 : tracer le chemin réel de chaque exécution
Attribuez un identifiant interne à chaque essai et consignez la tâche, le modèle, le fournisseur, le mode de routage et le rôle joué dans le workflow. Ajoutez la configuration active, la date, l’identité du réviseur et tout incident ayant perturbé l’exécution.
Cette trace doit permettre de répondre après coup à une question simple : quel système a réellement produit cette sortie ? Dans un workflow avec sous-agents, le nom visible du moteur principal ne raconte pas toujours toute l’histoire.
Ne laissez pas non plus le réviseur deviner quel résultat il préfère en regardant le nom du fournisseur. Lorsque le processus le permet, présentez les sorties avec des libellés neutres pendant la première lecture. La comparaison gagne en sérieux sans prétendre supprimer tout biais humain.
Étape 5 : évaluer avec une revue humaine commune
La revue doit examiner la justesse du résultat, le respect des contraintes, les omissions, la qualité des explications et le travail nécessaire avant acceptation. Pour du code, une sortie élégante mais incorrecte échoue. Une sortie correcte qui ignore une contrainte explicite échoue aussi.
Utilisez les mêmes questions pour chaque résultat. Demandez au réviseur de motiver son jugement avec des éléments observables : contrainte oubliée, hypothèse non vérifiée, modification inutile, explication exploitable. Les adjectifs seuls ne suffisent pas. « Meilleur » n’est pas une preuve. « Respecte la portée demandée et ne modifie pas les composants exclus » en est une.
Si plusieurs personnes révisent, faites examiner des sorties comparables par des profils comparables. Une différence de sévérité entre réviseurs peut sinon masquer la différence entre modèles.
Étape 6 : contrôler coûts, sécurité et données
Relevez la dépense auprès du fournisseur concerné. N’utilisez pas l’affichage local comme source unique, puisque le projet signale qu’il peut être inexact pour les modèles tiers routés. Rapprochez ensuite la dépense de l’essai tracé et du résultat obtenu. Le coût utile est celui d’un résultat accepté, reprises comprises, pas celui d’une sortie brute isolée.
Avant le test, classez les données admises, celles qui doivent être retirées et celles qui interdisent l’essai externe. Vérifiez quel fournisseur reçoit la requête dans le mode choisi. Le même écran peut masquer des chemins de données différents.
La revue humaine reste obligatoire pour toute sortie susceptible d’avoir un effet sur la production, un client ou une donnée sensible. Le test évalue une aide au travail. Il ne transfère pas la responsabilité au modèle.
Étape 7 : fixer la règle d’arrêt avant de commencer
Un test sans règle d’arrêt devient une collection d’impressions. Décidez à l’avance ce qui met fin à l’expérience : une option ne respecte pas une exigence de sécurité, le coût n’est pas traçable, les résultats ne permettent pas de départager les modèles, ou une option répond de façon suffisamment régulière aux critères pour prendre la décision visée.
La règle doit aussi prévoir le cas inconfortable : aucun modèle ne passe. La conclusion peut être de garder le workflow actuel, de réduire le périmètre confié à l’agent ou de revoir la tâche. Forcer un gagnant donne un joli tableau et une mauvaise décision.
Étape 8 : décider, puis archiver
Rédigez une note courte : hypothèse, périmètre, variables constantes, écarts au protocole, résultats de la revue, coûts constatés chez les fournisseurs, risques de données et décision. Ajoutez les conditions qui déclencheraient un nouveau test, comme un changement de tâche, de fournisseur ou de configuration.
Archivez les fiches de tâches, les sorties, les observations humaines et la configuration utile à la compréhension. Le but n’est pas de conserver chaque détail pour toujours. Il est de pouvoir expliquer pourquoi l’entreprise a choisi ce modèle pour ce rôle à cette date.
Une décision traçable vaut mieux qu’un benchmark permanent. Décider. Assumer. Revoir quand les conditions changent.
Ce que ça coûte vraiment
Le premier coût est celui des fournisseurs. La documentation de Clodex prévient que l’affichage dans Claude Code peut être inexact pour les modèles tiers routés. La référence budgétaire doit donc venir des relevés des fournisseurs, rapprochés des essais internes. Sans ce rapprochement, impossible de relier une dépense à une tâche et à une sortie acceptée.
Le deuxième coût est humain. Il faut préparer des tâches comparables, nettoyer les données, relire les résultats et documenter les écarts. Cette charge n’est pas un défaut du protocole. C’est le prix d’une décision qui résiste à la première objection. Une PME peut garder le dispositif léger en limitant le test aux rôles qui ont un effet réel sur son travail.
Le troisième coût est technique. Le routage doit être compris, surveillé et maintenu. Le projet indique notamment qu’un patch optionnel doit être refait après une mise à jour de Claude Code. Si l’équipe utilise ce mécanisme, elle doit intégrer sa vérification à la maintenance du banc d’essai. En mode endpoint local, l’affichage de la fenêtre de contexte peut également rester décalé après un changement de modèle. Ce détail peut transformer une limite de contexte en faux verdict sur la qualité.
Enfin vient le coût de l’indécision. Tester sans hypothèse, sans règle d’arrêt et sans archive entretient plusieurs configurations sans produire de choix. La comparaison devient alors une activité récurrente qui consomme du temps et brouille les responsabilités.
Le budget pertinent ne se résume donc ni au prix d’un appel ni à l’installation de la couche de routage. Il comprend le fournisseur, la préparation, la revue, la maintenance et le traitement des incidents. On peut accepter ce coût. On ne doit pas le découvrir après coup.
Pour qui ce n'est pas
Ce protocole n’est pas destiné à une équipe qui cherche une réponse universelle à la question « quel est le meilleur modèle ? ». Il produit une décision locale, liée à des tâches, des contraintes et un workflow précis. Dès que ces conditions changent, la conclusion peut changer aussi.
Clodex convient mal à une PME qui ne peut nommer personne pour comprendre le routage, contrôler les accès et enquêter sur une exécution ambiguë. Ajouter plusieurs fournisseurs dans un workflow agentique sans responsable technique multiplie les zones grises.
L’approche n’est pas adaptée non plus si les données nécessaires au test ne peuvent pas être envoyées aux fournisseurs envisagés. Le stockage local des identifiants ne répond pas à cette question. Il faut d’abord définir quelles données peuvent circuler et par quel chemin.
Une équipe qui ne dispose d’aucune procédure de revue humaine doit commencer par là. Sans critères d’acceptation, la comparaison récompense la sortie la plus convaincante à la lecture, pas forcément la plus correcte. Le modèle devient alors juge de sa propre démonstration.
Enfin, si un seul moteur satisfait déjà un usage limité et peu coûteux, le test peut ne rien apporter. Comparer a du sens lorsqu’une décision réelle est ouverte. Sinon, on construit un banc d’essai pour éviter de dire que le choix est déjà fait.
Source : https://github.com/bman654/clodex
FAQ
Faut-il utiliser exactement le même prompt pour chaque modèle ?
Pour une comparaison stricte, oui : le prompt, le contexte, les outils et les règles de validation doivent rester constants. Vous pouvez ensuite mener un second passage optimisé pour chaque modèle, à condition de séparer clairement les deux résultats.
Comment comparer sans inventer une note globale ?
Définissez des critères qualitatifs observables avant le test : exactitude, respect des contraintes, omissions, explication et reprises humaines nécessaires. Le réviseur motive chaque jugement avec un élément de la sortie. La décision s’appuie sur ces observations, pas sur une moyenne décorative.
Que faut-il tracer dans un workflow avec sous-agents ?
Consignez le modèle, le fournisseur, le mode de routage et le rôle de chaque agent intervenu. Ajoutez la tâche, la configuration active, le réviseur et les incidents. Le nom du modèle principal ne suffit pas si une étape importante a été déléguée.
Où vérifier le coût d’un essai avec Clodex ?
Auprès du fournisseur qui a traité la requête. Le projet indique que l’affichage dans Claude Code peut être inexact pour les modèles tiers routés. Reliez ensuite ce coût à l’identifiant interne de l’essai et à la décision de revue.
Quand faut-il arrêter la comparaison ?
Arrêtez selon la règle fixée avant le premier essai : exigence de sécurité non respectée, coût impossible à tracer, absence de différence utile ou option suffisamment régulière pour la décision visée. « Aucun gagnant » est une conclusion recevable.
Combien de temps faut-il conserver les résultats ?
Assez longtemps pour expliquer la décision et la réexaminer lorsque ses conditions changent. Conservez surtout l’hypothèse, les tâches, la configuration, les sorties examinées, les observations, les coûts fournisseurs et la décision. La durée exacte relève de la politique interne de l’entreprise.
Publié le 26 septembre 2026.
Cet article est un outil d'orientation, pas un avis juridique. Pour une analyse adaptée à votre situation, consultez un professionnel qualifié.
