Edgee

Une passerelle pour un poste de dépense précis

Edgee est une société parisienne cofondée par Sacha Morard, ancien directeur technique et des systèmes d'information du groupe Le Monde, et Gilles Raymond, fondateur de News Republic puis de la Signal Network Foundation. Son financement vérifiable se limite à un tour de pré-amorçage de 2,9 millions de dollars — 2,66 millions d'euros — annoncé le 17 octobre 2024, mené par Serena et VentureFriends. Le produit était alors une plateforme d'informatique en périphérie ; le pivot vers la passerelle d'agents s'est fait sans nouveau tour annoncé.

Le produit s'intercale entre les agents de codage et les fournisseurs de modèles, et intercepte, route, compresse, mesure et sécurise chaque requête sans modification de code. L'accroche est une interface en ligne de commande écrite en Rust qui lance l'agent avec la passerelle déjà en place, pour Claude Code, Codex, Cursor, VS Code avec Copilot et d'autres. Le dépôt GitHub public ne contient que cette interface : la passerelle de production est opérée par Edgee, et l'auto-hébergement passe par une offre séparée.

Compresser sans casser le cache

La contrainte qui gouverne la conception tient en une phrase : le cache de préfixe est indexé sur le contenu, et le moindre octet modifié invalide le cache à partir de ce point. Un token servi depuis le cache coûtant environ le dixième du prix d'entrée, une compression qui toucherait au début du contexte détruirait plus de valeur qu'elle n'en crée. Les trois stratégies du compresseur de deuxième génération visent donc uniquement ce qui vient après le préfixe stable.

La concision agit sur les tokens de sortie. La réduction de surface d'outils attaque les catalogues MCP répétés dans le contexte à chaque tour. L'élagage des résultats d'outils tronque les sorties verbeuses de commandes. La première génération se limitait à cette dernière stratégie et apportait environ 10 % d'économie.

• Route : routage sous contrainte de budget, bascule sur erreur ou quota, redirection en cours de tâche vers des modèles open-weights.
• Compress : concision, réduction de la surface MCP, élagage des résultats d'outils.
• Observe : observabilité par développeur, par dépôt et par pull request, plafond de dépense par siège.

Lire les chiffres d'économie

L'écart entre la communication et la mesure est large, et Edgee le documente lui-même. Le marketing avance « jusqu'à 50 % » pour la compression seule et « jusqu'à 70 % » avec le routage ; la documentation qualifie ces valeurs d'illustratives et précise qu'il ne s'agit pas d'un résultat mesuré. Les benchmarks publiés — tous produits par l'éditeur — donnent 33 % de réduction de volume de tokens et environ 10 % de coût sur SWE-bench Lite, 26,5 % d'autonomie supplémentaire sur un plan Claude forfaitaire, et 35,6 % de coût de session en moins sur Codex avec un taux de succès du cache passant de 76,1 % à 85,4 %.

La fourchette défendable se situe donc entre 10 et 35 % selon le scénario, avec un maximum sur les flux les plus redondants. Un éditeur qui publie un protocole permettant de contredire son propre titre fait mieux que la moyenne du secteur ; cela ne dispense pas de lire les figures plutôt que le titre, ni de mesurer sur son propre trafic.

Hébergement, données et modèle économique

Une passerelle d'agents voit plus qu'un proxy d'inférence : elle voit les prompts, mais aussi les appels d'outils, donc des extraits de code et des chemins de fichiers. Trois niveaux d'hébergement sont proposés : cloud partagé multi-locataire, locataire dédié avec résidence de données en Europe ou aux États-Unis, et on-premise auto-hébergé par Docker Compose ou Helm, en mode connecté ou en mode isolé sans aucun appel sortant. L'engagement affiché sur ce dernier tier est explicite : aucun prompt, aucune complétion et aucune clé fournisseur n'est transmis à Edgee. Conformité affichée : SOC 2 et RGPD.

Le modèle économique suit une règle unique : les tokens déjà payés ne coûtent rien de plus en passant par Edgee, la facturation portant sur des sièges, sur des tokens fournis par Edgee, ou sur une part des économies produites. Cette dernière modalité est confortable et demande une vigilance : une facture indexée sur un contrefactuel se vérifie mal, là où un plan à siège fixe s'audite.

Chez Qonto, une couche de gouvernance plutôt qu'un proxy

Le 22 septembre 2026, Edgee publie sur son blog un entretien avec Kevin Prettre, directeur de l'infrastructure et du support aux ingénieurs de Qonto : le premier déploiement client documenté de la passerelle, raconté par l'éditeur lui-même, avec des chiffres mesurés et déclarés par Qonto. L'établissement financier voulait faire des modèles de langage une commodité, chaque équipe choisissant son modèle par tâche. L'inférence tourne sur Amazon Bedrock, qui porte la résidence des données et l'engagement de non-entraînement, mais Bedrock seul imposait une identité par employé et par fonctionnalité. Kevin Prettre a écarté LiteLLM : face à une douzaine de harnais d'agents et quatre à cinq surfaces desktop qui changent leur façon d'appeler les modèles presque chaque semaine, la couche de compatibilité aurait été à maintenir en interne ou à attendre de la communauté. Une couche minimale d'identité et d'attribution au-dessus de Bedrock représentait environ un mois de développement assisté par IA, avant maintenance. Il résume le choix ainsi : « ce dont nous avions besoin n'était pas un proxy mais un produit ».

Le test à l'aveugle a commencé mi-mai 2026 : pendant deux semaines, dix ingénieurs ont vu leur trafic vers un modèle frontier redirigé en silence vers un modèle open-weight, et aucun n'a remarqué la différence. La migration a débuté fin juillet ; l'adoption est passée de 10 à 350 ingénieurs en cinq semaines sans obligation, puis Qonto a fait d'Edgee le réglage par défaut en déployant l'alias de la CLI par Jamf. Au 10 septembre, 500 ingénieurs passaient par la passerelle. La première politique de routage, le 1er septembre, déplace le trafic d'exécution d'un modèle frontier vers un modèle frontier moins cher de même classe. Qonto mesure 17 % de réduction de coût en médiane par la compression seule (jusqu'à 20 % selon la période), et 37,7 % en combinant compression et reroutage : deux mesures distinctes, que l'éditeur demande de ne pas additionner. Les modèles concernés ne sont pas nommés, et l'entretien précise que l'expérience à dix ingénieurs ne démontre pas l'interchangeabilité des modèles : sans plateforme d'évaluation formelle, la confiance de Qonto repose sur les retours d'équipe et la vélocité de livraison.

L'analyse de conformité de Qonto donne la mesure de ce qu'une passerelle d'agents est devenue. Edgee traite les requêtes en transit et ne stocke pas les payloads sauf activation explicite ; Qonto a exigé la résidence européenne pour les identités d'employés et pour le débogage de session ; sous DORA, le prestataire est classé tiers TIC non critique, parce qu'une panne toucherait la productivité des développeurs et que les harnais peuvent retomber directement sur les fournisseurs de modèles. L'audit reste du côté de Qonto, avec des exporteurs OpenTelemetry posés sur les harnais ; Edgee relie chaque harnais, session et modèle à l'identité d'un employé. Le fournisseur de tokens devient ainsi remplaçable par une règle de routage, sans que les développeurs changent d'outil, et l'identité, les budgets et la politique de routage vivent chez l'entreprise. La difficulté que Kevin Prettre décrit comme restante se situe hors de la passerelle : dimensionner le modèle par tâche sans plateforme d'évaluation, face au marketing des laboratoires qui pousse vers les derniers modèles.