La philosophie du proxy transparent : Pourquoi votre gateway doit être un ‘Pass-Plat’

Dans l’écosystème naissant des passerelles d’IA (LLM Gateways), il existe deux visions architecturales radicalement opposées.

La première vision, très répandue chez les éditeurs SaaS grand public, considère la gateway comme un “cerveau magique” qui réécrit silencieusement les requêtes des développeurs (injection de prompts système cachés, résumés automatiques invisibles de l’historique, reformulations sémantiques) pour optimiser les réponses des modèles.

La seconde vision, que nous défendons fermement chez LLMBastion, est celle du Proxy Transparent (ou philosophie “Pass-Plat”). Pourquoi cette approche est-elle la seule viable pour les architectures d’entreprise ? Explications.

1. Le Danger de l’Altération Sémantique Opaque

Réécrire silencieusement le prompt d’un utilisateur au niveau de l’infrastructure est une hérésie pour tout ingénieur logiciel. Cela pose trois problèmes fondamentaux :

• Perte de Reproductibilité : Si la gateway modifie les invites en arrière-plan, le même code client envoyé à deux moments différents ou à travers deux environnements produira des résultats divergents et impossibles à déboguer.
• Masquage du Comportement du Modèle : Les développeurs ont besoin de comprendre comment le modèle amont (GPT-4, Claude) réagit précisément à leurs instructions. Si l’invite est altérée en amont, les optimisations de prompt (Prompt Engineering) faites par le client deviennent inefficaces ou contre-productives.
• Risque de Sécurité accru : Une injection automatique de prompt peut introduire des conflits d’instructions sémantiques, rendant le modèle vulnérable à des attaques par injection de prompt (Prompt Injection) invisibles pour l’utilisateur final.

2. Les Principes de la Philosophie “Pass-Plat”

Une LLM Gateway robuste doit fonctionner comme un serveur de transit haute performance. Son rôle est de sécuriser, monitorer et optimiser la route, sans jamais dénaturer le message.

A. Intégrité Absolue du Message

Ce que le client envoie est exactement ce que le modèle reçoit. L’infrastructure n’applique aucune modification sémantique implicite. Les seules altérations autorisées sont celles explicitement configurées par les politiques de sécurité de l’organisation (comme le masquage des données sensibles PII et des secrets).

B. Transparence et Observabilité Totales

Si la gateway doit mener une action corrective pour sauver une requête (par exemple, parce que le prompt dépasse la capacité du modèle), cette action doit être explicitée de façon immédiate et transparente via des en-têtes HTTP de télémétrie :

• X-Bastion-Context-Warning : Injecté si la gateway a dû basculer dynamiquement la requête vers un modèle plus robuste.
• X-Bastion-Context-Truncated: true : Injecté si la gateway a dû élaguer l’historique de conversation pour respecter la fenêtre de tokens.

C. Souveraineté du Client (Arbre de Priorité)

Le comportement de la passerelle doit être entièrement surchargeable par l’émetteur de la requête. Si un développeur veut désactiver la troncation intelligente ou interdire la bascule automatique de modèle pour un appel spécifique, il doit pouvoir le faire directement dans le payload de sa requête JSON via des paramètres de routage dédiés.

3. Une Infrastructure Prévisible pour des Systèmes Déterministes

Construire des applications fiables au-dessus de modèles de langage probabilistes est déjà un défi complexe. Rajouter une couche d’imprévisibilité au niveau de votre infrastructure réseau ne fait que compliquer la tâche.

En adoptant une architecture “Pass-Plat” transparente, vous séparez clairement les responsabilités : la gateway gère la sécurité, la performance et le routage réseau, tandis que votre code applicatif gère la sémantique et l’interaction avec le modèle. C’est la seule façon de garantir des systèmes de production prévisibles, auditables et évolutifs.