Le déchargement de modèle est une chaîne de confiance, pas un choix de modèle

Équipe de recherche CyberShell

Contexte des contributeurs

Cet article a été rédigé collectivement par l'équipe de recherche CyberShell, avec des contributions notables des membres suivants.

Alexandre Cormier

Expert en la matière

Deirdre Hennigar

Experte en la matière

Aperçu

Il y a une question à laquelle tout responsable de l'ingénierie se heurte dès que quelqu'un propose de remplacer un modèle d'IA de pointe par un modèle moins cher : à quoi, exactement, est-ce que je fais confiance, et où?

Il est tentant de répondre à cette question au niveau du modèle — « DeepSeek est-il aussi bon que GPT? » — mais cette approche passe à côté de l'endroit où se trouve le véritable risque.

Lorsque vous branchez un agent de codage sur un modèle moins coûteux, vous ne faites pas seulement confiance à un modèle. Vous faites confiance à une chaîne : le harnais qui l'appelle, le proxy qui achemine la requête, le fournisseur qui l'héberge, l'infrastructure sur laquelle ce fournisseur fonctionne et les garde-fous que chacun dans cette chaîne prétend appliquer.

Si un seul maillon de la chaîne cède, le score du modèle aux évaluations n'a plus d'importance.

Nous avons mené une petite expérience pour mettre cette chaîne à l'épreuve — non pas pour couronner un gagnant parmi les modèles, mais pour voir ce qu'il faut réellement pour rendre utilisable, dans un vrai travail d'ingénierie, un modèle moins coûteux hébergé par un tiers.

Le problème de confiance, en termes simples

Les agents de codage voient tout : le code source, les noms d'hôte internes, les clés d'API oubliées par accident dans des jeux de test, les décisions d'architecture consignées dans des commentaires.

Faire passer tout cela par un modèle externe est une décision de traitement des données autant qu'une décision technique. Alors, avant de se demander « le modèle bon marché fonctionne-t-il? », la question plus difficile est : pouvons-nous rendre l'environnement du modèle bon marché assez fiable pour même le tester?

Notre réponse a été d'empiler les contrôles plutôt que de miser sur un seul :

Aucun de ces contrôles ne vient du fait que nous avons lu la page marketing d'un fournisseur et décidé de la croire. Ce sont des paramètres documentés et vérifiables, qui nous permettaient de désigner une requête précise et de dire : ce contrôle était actif pour cet appel.

C'est toute la différence entre « nous faisons confiance à ce fournisseur » et « nous pouvons vérifier que cette configuration a été observée et était en vigueur ».

Pourquoi le harnais compte autant que le modèle

Voici la partie qu'on a tendance à survoler : rien de tout cela n'a été fait en rédigeant des requêtes à la main. Tout s'est passé dans Codex — le même harnais d'agent, la même boucle d'appel d'outils, la même suite d'évaluation — seul le modèle sous-jacent changeait.

Si votre flux de travail traite le modèle comme un composant interchangeable derrière un harnais stable — même interface d'outils, même étape de vérification, même configuration de garde-fous — alors tester un modèle moins coûteux devient une expérience contrôlée, et non un acte de foi.

Vous pouvez changer de LLM sans changer de flux de travail, et c'est ce qui permet d' échouer sans danger lorsqu'un modèle moins cher ne tient pas la route.

Ce qui, dans notre expérience, a été le cas d'une configuration.

Faire confiance, c'est accepter de voir quelque chose échouer

Nous avons soumis trois tâches d'évaluation à trois configurations : le modèle moins coûteux avec un niveau de raisonnement standard, le même modèle poussé à son niveau de raisonnement le plus élevé en mode multi-agents, et un modèle de pointe à son niveau le plus élevé, à titre de comparaison.

Deux des trois ont tout réussi. La troisième, non — et la façon dont elle a échoué est la partie la plus instructive de tout l'exercice.

Dans sa configuration la plus poussée, le modèle moins coûteux ne s'est pas tant trompé sur une tâche qu'il a cessé de se comporter de façon prévisible. Au lieu de soumettre une réponse, il s'est mis à générer d'énormes commandes d'outils répétitives — des dizaines de kilo-octets de shell et de Python là où quelques kilo-octets auraient suffi — jusqu'à atteindre un plafond de sortie en pleine réponse, laissant derrière lui un appel d'outil incomplet et mal formé.

Le harnais a fait ce qu'un harnais bien conçu doit faire à ce moment-là : il a rejeté la sortie défectueuse plutôt que d'essayer de la récupérer ou de l'exécuter, et la tâche a été correctement notée comme un échec au lieu de passer discrètement avec un résultat inutilisable.

C'est tout l'intérêt de faire passer chaque résultat par un vérificateur déterministe et indépendant plutôt que de se fier au compte rendu du modèle sur ce qu'il a fait.

Nous ne nous sommes pas arrêtés non plus au constat « ça a échoué ». Nous avons cherché à déterminer à quel endroit de la chaîne l'échec avait le plus probablement pris naissance — la génération de la réponse par le modèle, le traitement de l'appel d'outil par le harnais ou la couche proxy entre les deux — parce qu'attribuer correctement la responsabilité fait aussi partie de l'ingénierie de la confiance.

Blâmer la mauvaise couche, c'est corriger la mauvaise chose et voir le problème revenir.

Ce que cela signifie pour les équipes qui évaluent des modèles moins coûteux ou ouverts

Si vous faites partie d'une organisation d'ingénierie soucieuse de la sécurité qui envisage des modèles moins chers ou hébergés à l'externe, quelques leçons tirées de cet exercice s'appliquent bien au-delà de notre configuration précise.

Utiliser l'IA de façon économique sans une solide couche de vérification n'a rien d'économique : c'est simplement du risque reporté.

Le travail sensible à la latence, ou tout ce dont un premier essai raté coûte cher à défaire, mérite le niveau d'assurance et le coût de votre modèle de pointe de référence.

L'échec que nous avons observé n'est apparu que dans la configuration la plus poussée — plus de raisonnement, plus d'autonomie des agents — et non dans la configuration prudente. Testez délibérément la configuration la plus poussée; ne présumez pas qu'elle hérite des propriétés de sécurité de la configuration prudente.

Le changement de fond : la confiance comme propriété d'ingénierie, et non comme promesse d'un fournisseur

L'ancien modèle de confiance envers les fournisseurs reposait surtout sur la réputation : on choisissait un grand nom et on faisait confiance à sa marque.

Cela ne tient plus dans un monde où l'économie favorise de plus en plus l'acheminement du travail vers le modèle le moins cher pour une tâche donnée, peut-être par l'intermédiaire d'une chaîne de fournisseurs que vous n'avez pas choisis directement.

L'autre option est de faire de la confiance quelque chose que l'on construit plutôt que quelque chose que l'on accorde de bonne foi : restreindre ce qu'une requête a le droit de toucher, vérifier ce qui s'est réellement passé plutôt que ce que le modèle rapporte, garder son flux de travail indépendant de tout modèle unique et prévoir un comportement par défaut à sécurité intégrée.

Ainsi, quand quelque chose tourne mal, cela se produit de façon visible et sûre, plutôt que discrète et coûteuse.

Sources

• Recherche CyberShellAgents de codage soucieux des coûts : une expérience de délestage sur trois tâches
• OpenRouterProvider routing
• OpenRouterGuardrails
• OpenRouterZero Data Retention
• Together AIPrivacy and security