Passerelle IA : ce que PayPal fait avec 100 modèles

PayPal fait travailler plus de 100 modèles d'IA derrière une seule porte d'entrée, selon ses propres chiffres [1]. L'avantage n'est pas de choisir un seul excellent modèle. C'est de construire une couche de contrôle commune entre les besoins métier, les agents et les fournisseurs d'IA. Voici ce que cette architecture raconte, ce qu'elle ne prouve pas, et ce qu'une PME peut en garder.

En bref05 points

Le 26 octobre 2026, six auteurs de PayPal décrivent Cosmos, la passerelle par laquelle passe leur trafic vers les modèles d'IA [1].
Chiffres déclarés par PayPal pour septembre 2026 : plus de 12 000 développeurs, environ 200 milliards de tokens par jour, plus de 100 modèles [1]. Aucun audit indépendant.
L'idée tient en une phrase : les contrôles (accès, budget, données) sortent des applications et vivent dans une couche commune [1].
Une PME n'a pas besoin des mêmes composants. Elle peut garder les principes : une porte d'entrée, un modèle remplaçable, des permissions, un coût suivi, des données protégées, des règles testées avant d'être imposées.
Le texte ne démontre ni baisse de coût ni gain de qualité [1]. C'est un retour d'expérience sur la gouvernance et l'exploitation, pas une preuve de rentabilité.

Qu'a publié PayPal, et que prouve ce texte ?

Le 26 octobre 2026, six auteurs de PayPal ont publié sur arXiv Governing Enterprise AI Traffic at Scale: Design and Operation of a Policy-Driven, Multi-Vendor LLM Gateway on Envoy [1]. Ils décrivent Cosmos, leur passerelle centralisée vers plusieurs fournisseurs et modèles d'IA.

Les chiffres que les auteurs donnent pour septembre 2026 [1] :

plus de 12 000 développeurs et des centaines de cas d'usage ;
environ 200 milliards de tokens par jour ;
plus de 100 modèles ;
99,999 % de disponibilité pour le métier.

Sur un benchmark avec un fournisseur simulé, la passerelle ajoute 4 ms de latence médiane et 11 ms au p99, à plus de 2 200 requêtes par seconde sur deux instances de 4 vCPU [1]. Ces mesures ne prouvent pas la même performance pour tous les flux réels.

Ce n'est pas une étude prouvant que les agents sont plus intelligents ou rentables. C'est un retour d'expérience sur la gouvernance et l'exploitation d'une infrastructure IA.

Quel problème une passerelle IA résout-elle ?

Quand chaque équipe connecte directement ChatGPT, Claude, Gemini ou des modèles internes, les problèmes se multiplient : clés API dispersées, formats différents, règles d'accès incohérentes, coûts difficiles à attribuer, données sensibles exposées, migration coûteuse d'un fournisseur à l'autre.

PayPal interpose une porte d'entrée unique. Les applications demandent une capacité IA ; cette couche décide si l'appel est autorisé, vers quel fournisseur le router, comment le traduire, le mesurer et l'enregistrer [1].

Sans couche commune	Ce que fait la couche commune chez PayPal [1]	Version PME légère
Des clés d'accès dispersées dans chaque outil	Authentification et gestion des clés dans un service de contrôle	Une liste des accès, tenue par une personne identifiée
Un format différent par fournisseur	Traduction des formats dans le proxy	Une consigne écrite une fois, indépendante du modèle
Un coût que personne ne sait attribuer	Budgets calculés sur des compteurs d'usage par modèle	Un relevé mensuel par usage, pas seulement la facture globale
Des données qui partent là où elles ne devraient pas	Couche DLP optionnelle : bloquer, masquer ou pseudonymiser avant l'envoi	Une règle écrite : ce qui ne sort jamais, ce qui sort masqué
Changer de fournisseur, c'est tout refaire	Modèles, fournisseurs et prix traités comme des données validées	Le modèle noté dans une fiche, pas recopié dans chaque consigne

Utilisateurs / applications / agents / workflows
                     |
              PASSERELLE IA
   Identité + autorisations + budgets + DLP
   Catalogue de modèles + traduction des API
   Mesure d'usage + journaux + politiques
                     |
      OpenAI | Anthropic | Gemini | modèles privés

Attention : cette architecture unifie l'accès aux modèles. Elle ne constitue pas, à elle seule, un second cerveau, une mémoire persistante, un orchestrateur de tâches ou un moteur d'évaluation des résultats.

Quels principes une PME peut-elle en garder ?

Un point d'entrée commun. Un workflow ne devrait pas avoir à gérer séparément chaque fournisseur. La passerelle expose une interface cohérente, tout en reconnaissant que certaines fonctionnalités propres aux modèles ne sont pas parfaitement interchangeables [1].

Des modèles déclarés comme des données. Catalogue des modèles, fournisseurs, tarifs : leur configuration est validée plutôt que codée en dur [1]. Pour vous : changer un modèle sans réécrire chaque consigne.

Des permissions qui précèdent l'exécution. Chaque demande est associée à une identité, des droits et des politiques [1]. Pour vous : distinguer lecture, rédaction, modification, envoi externe et suppression.

Des budgets mesurés par usage. PayPal conserve des compteurs d'usage et applique des limites selon des périmètres [1]. Pour vous : un coût par client, par workflow, par équipe et par résultat utile, pas uniquement une facture globale d'API.

Une protection des données avant transmission. Une couche DLP peut bloquer, masquer ou pseudonymiser certaines données sensibles [1]. Aucune détection automatique n'est parfaite : il faut aussi minimiser les données transmises, définir les durées de conservation et vérifier les contrats fournisseurs.

Des changements de règles testés avant activation. Les nouvelles politiques peuvent être évaluées en shadow mode : observer ce qu'elles auraient bloqué sans interrompre les usages. Les configurations sont versionnées et approuvées [1]. Pour vous : tester un nouveau garde-fou sur les journaux avant de le rendre bloquant.

Faut-il copier Envoy, Rust et OPA ?

PayPal utilise Envoy comme proxy, un service externe pour les décisions d'authentification et de politique, et un filtre Rust WebAssembly dans le proxy pour les conversions et la mesure des tokens. Open Policy Agent exprime les règles [1]. Cette séparation évite que la réponse en streaming attende un aller-retour vers un service externe.

Ils distinguent les échecs critiques (refuser la requête si les contrôles d'accès ou de protection échouent) des problèmes de télémétrie (ne pas interrompre forcément le service si la collecte échoue). C'est un arbitrage d'architecture, pas une règle universelle : vos obligations de traçabilité peuvent exiger un comportement plus strict.

Ne reproduisez pas Envoy, Rust et OPA dès le premier jour. Pour une petite structure, cette complexité coûterait probablement plus qu'elle ne rapporterait. Copiez les principes avant les composants.

À quoi cela ressemble-t-il dans une PME ?

Un exemple : un commercial qui prépare une proposition.

Il dicte une note vocale après son rendez-vous.
La chaîne transcrit et classe les informations autorisées.
Le second cerveau récupère les procédures et références pertinentes.
Le routeur sélectionne le modèle selon le coût, les capacités requises et les règles de confidentialité.
L'agent prépare un brouillon de proposition.
Un contrôle vérifie les montants, les sources et les clauses.
Un humain valide avant tout envoi externe.
Le système conserve coût, durée, corrections et issue commerciale.

La passerelle n'occupe que l'étape 4. Le second cerveau conserve les connaissances, décisions, corrections et sources. Les skills décrivent comment effectuer des opérations. Les chaînes définissent leur ordre. Le routeur choisit le modèle et contrôle l'accès. L'évaluation vérifie si le travail est correct et utile. Ce sont cinq responsabilités différentes.

Une règle de conception en découle : une skill ne devrait pas contenir en dur une clé API, un fournisseur obligatoire, un budget illimité ou un accès à toutes les données. Elle exprime une capacité et ses exigences ; la plateforme décide comment l'exécuter selon le contexte et les droits.

À ne pas automatiser sans autorisation : l'envoi d'une proposition, la modification du CRM, le partage de données clients et les engagements financiers.

Pour améliorer ce qui sort d'un agent sans changer de modèle : améliorer un agent IA sans changer de modèle.

Que ne faut-il pas conclure ?

PayPal ne prouve pas que toutes les entreprises ont besoin d'une passerelle développée sur mesure.
Les chiffres de disponibilité et de trafic sont déclarés par les auteurs, sans audit indépendant présenté dans l'article [1].
Le benchmark de latence utilise un fournisseur simulé et ne mesure pas tous les scénarios de streaming.
L'article ne démontre pas une réduction chiffrée du coût global ni une amélioration mesurée de la qualité des réponses.
La traduction entre API n'assure pas la parité de toutes les fonctions propriétaires.
Une passerelle ne remplace ni l'évaluation des agents, ni les contrôles métier, ni une politique RGPD.

Comment démarrer en quatre semaines ?

Ce plan est un repère proposé par 360IA, pas un résultat de PayPal.

1. Semaine 1 : observer

Inventoriez les appels à l'IA existants et classez-les par tâche, fournisseur, données, coût et responsable. Identifiez les appels sans traçabilité.

2. Semaine 2 : centraliser

Faites passer un workflow pilote par une interface commune. Séparez la configuration du modèle et la logique métier. Prévoyez un repli contrôlé, sans fuite vers un fournisseur non autorisé.

3. Semaine 3 : gouverner

Ajoutez identité, liste de modèles autorisés, plafond de coût, approbation humaine pour les actions sensibles et politique de données.

4. Semaine 4 : évaluer

Comparez au système initial sur 30 à 50 tâches réelles, anonymisées si nécessaire. Mesurez coût, délai, exactitude, incidents, corrections et temps humain. Documentez aussi les cas où le routeur ajoute une latence ou dégrade une capacité propre à un modèle.

À quoi ressemble la grille à copier ?

Copiez-la dans une note ou une feuille de calcul. Ce sont des repères proposés, pas des résultats de PayPal.

GRILLE DE PILOTE : UNE COUCHE COMMUNE POUR MES IA

Workflow pilote : ______________________
Responsable : ______________________
Période : du ____________ au ____________

ACCÈS ET DROITS
Appels à l'IA reliés à un workflow et à un responsable : ____ sur ____
Actions sensibles lancées sans autorisation : ______
(lecture, rédaction, modification, envoi externe, suppression)

COÛT
Coût total de la période : ______ €
Nombre de résultats validés : ______
Coût par résultat validé : ______ €
Dépassements de budget non signalés : ______

QUALITÉ
Tâches comparées à l'ancien fonctionnement : ______
Résultats corrects, ancien / nouveau : ______ / ______
Temps humain de correction, ancien / nouveau : ______ / ______

DONNÉES
Données sensibles envoyées à un modèle sans règle : ______
Règles testées à blanc avant d'être imposées : ______

LIMITES CONSTATÉES
Cas où la couche commune ralentit ou dégrade un modèle : ______

DÉCISION
On garde / on ajuste / on arrête, parce que : ______________________

Questions fréquentes

Qu'est-ce qu'une passerelle IA ?

Une couche placée entre vos outils et les fournisseurs de modèles. Elle décide si un appel est permis, vers quel modèle l'envoyer, le mesure et en garde la trace. Chez PayPal, elle s'appelle Cosmos [1].

Les chiffres de PayPal sont-ils fiables ?

Ils sont déclarés par les auteurs pour septembre 2026, sans audit indépendant présenté [1]. Ils montrent l'échelle de l'architecture, pas un gain démontré.

Une PME doit-elle utiliser plusieurs modèles d'IA ?

Pas forcément. L'intérêt n'est pas le nombre de modèles, mais de pouvoir en changer sans tout refaire, et de savoir qui peut faire quoi avec chacun.

Faut-il construire sa propre passerelle ?

Le texte ne le démontre pas pour toutes les entreprises [1]. Pour une petite structure, un inventaire, des droits écrits et un coût suivi sont souvent un meilleur point de départ.

Une passerelle protège-t-elle de tout risque sur les données ?

Non. La couche DLP de PayPal peut bloquer, masquer ou pseudonymiser, mais elle est optionnelle [1], et une passerelle ne remplace pas une politique RGPD.

Conclusion

PayPal ne prouve pas qu'il faut une passerelle. Il montre ce qui devient possible quand les règles vivent à un endroit et que les modèles vont et viennent : changer de fournisseur, mesurer, interdire, essayer une règle avant de l'imposer.

La vraie opportunité, pour une PME, n'est pas d'installer un proxy IA. C'est de construire un système IA gouvernable, évolutif et mesurable. Cette semaine, listez vos appels à l'IA et leur responsable. Le mois prochain, faites passer un seul workflow par une porte unique, avec la grille ci-dessus.

Pour le faire avec nous, deux portes. Dans la communauté 360IA, l'Atelier réunit chaque semaine les membres avec les fondateurs, pour construire sur ses propres cas. Pour votre entreprise, tout commence par un audit de votre architecture IA, une à deux heures avec les fondateurs : on cartographie ce qui est en place et on fixe les priorités. C'est la première étape de l'Immersion 360IA, 30 jours d'accompagnement privé, sur candidature, audit avant tout paiement.

Sources

Chiffres déclarés par PayPal dans l'article arXiv:2610.35509, sans audit indépendant ; le benchmark utilise un fournisseur simulé. Le plan en 4 semaines et la grille sont des repères proposés par 360IA, pas des résultats de PayPal.

Mithun Sasidharan, Srinivasan Manoharan, Rupesh Thakur, Abhinav TK, Ashwin Hegde, Anand Gautam (26 octobre 2026), « Governing Enterprise AI Traffic at Scale: Design and Operation of a Policy-Driven, Multi-Vendor LLM Gateway on Envoy », arXiv:2610.35509