DéfinitionCouche d’exploitation de l’IA · passerelle IAVersion 1.025 octobre 2026
Couche d’exploitation de l’IA ou passerelle IA
Une passerelle IA est un proxy qui achemine les requêtes vers les fournisseurs de modèles et applique clés, quotas, cache, journaux et filtres à la frontière de l’API ; une couche d’exploitation de l’IA inclut ce routage, puis rattache chaque action à un responsable nommé, une règle, un enregistrement en ajout seul et un arrêt qui atteint agents et outils. Cette page applique les 4 tests de la couche d’exploitation de l’IA à une passerelle seule, à la lumière de la documentation publique de 2 passerelles, lue le 25 octobre 2026.
Sur cette page
- Définition et conventions
- 1. Ce que couvre une passerelle IA
- 2. Ce qu’elle laisse ouvert
- 3. Les 4 tests appliqués à une passerelle
- 4. Quand une passerelle suffit
- 5. La passerelle dans le plan de routage et d’exécution
- 6. Les questions des acheteurs
- 7. Références et sources
- 8. Comment citer cette entrée
Une passerelle achemine l’appel. Une couche d’exploitation répond de l’action.
Dans cette page, « nous » désigne Hikari Blue, qui conçoit et exploite la couche d’exploitation de l’IA. La frontière de la catégorie et ses 4 tests sont ceux que sert notre page de définition au 25 octobre 2026 ; leur formulation est reprise ici sans changement.
Les tests s’appliquent à une passerelle seule, en tant que catégorie, jamais à un produit nommé. Chaque verdict est notre lecture de ce que fait la catégorie par conception, pas la mesure du système d’un éditeur.
- Qu’est-ce qu’une couche d’exploitation de l’IA ? · Où la catégorie s’arrête La définition de la catégorie et les 8 catégories voisines, chacune avec son critère de distinction.
- Glossaire de la couche d’exploitation de l’IA Chaque terme de la catégorie, chacun en une phrase autonome avec ses sources.
Un proxy à la frontière de l’API, entre les applications et les fournisseurs de modèles.
La ligne ci-dessous est celle que notre page de définition sert pour cette catégorie, mot pour mot.
| Catégorie | Ce qu’elle couvre | Ce qu’elle ne couvre pas | Le critère qui tranche |
|---|---|---|---|
| Passerelle IA et routage de modèles | Un proxy qui achemine les requêtes vers les fournisseurs de modèles et applique clés, quotas, cache, journaux et filtres à la frontière de l’API. | La décision humaine, les appels d’outils hors de l’API et une preuve opposable à un régulateur. | Une couche d’exploitation de l’IA inclut ce routage, puis rattache chaque action à un responsable nommé, une règle, un enregistrement en ajout seul et un arrêt qui atteint agents et outils. |
Ce que liste la documentation publique de 2 passerelles.
Toutes deux ont été lues le 25 octobre 2026 et sont citées comme exemples de ce que couvre la catégorie, telle que chaque éditeur la documente. Nous n’évaluons aucun des 2 produits ; les tests ci-dessous s’appliquent à la catégorie.
Cloudflare AI Gateway
Sa documentation décrit un moyen d’observer et de contrôler des applications d’IA, avec analyses, journaux, cache, limitation de débit, nouvelle tentative et repli vers un autre modèle entre fournisseurs. Page mise à jour le 20 avril 2026.
AI gateway in Azure API Management
Sa documentation liste limites et quotas de jetons, cache sémantique, répartition de charge et disjoncteurs entre modèles, règles de sécurité du contenu, authentification par identité managée, et journalisation des prompts et des réponses. Elle sert aussi d’intermédiaire vers des serveurs MCP et des API d’agents. Page datée du 29 mai 2026.
Traces. Les conventions sémantiques d’OpenTelemetry pour l’IA générative nomment les spans, métriques et événements des appels de modèles, des agents, de l’exécution d’outils et de MCP. Au 25 octobre 2026, elles portent le statut Development et sont tenues dans leur propre dépôt. Une passerelle qui les émet donne aux ingénieurs des traces comparables ; la trace sert l’ingénieur, l’enregistrement sert l’auditeur.
3 choses qu’une passerelle ne porte pas seule.
La frontière les nomme : la décision humaine, les appels d’outils hors de l’API et une preuve opposable à un régulateur. Chacune relève du processus, pas de l’appel.
La décision humaine
Une passerelle voit un prompt et une réponse. Elle ne voit ni qui a approuvé, rejeté ou corrigé la sortie, ni quelle décision métier cette sortie a nourrie. Notre cadre de gouvernance confie cette décision à un vérificateur humain nommé et l’inscrit dans l’enregistrement.
Les appels d’outils hors de l’API
Un agent agit par des outils : une base de données, un ERP, une session de navigateur, un fichier de paiement. Un appel qui ne traverse pas la passerelle échappe à sa vue, donc à son arrêt.
Une preuve opposable à un régulateur
Un journal de requêtes enregistre du trafic. Une piste d’audit de l’IA rattache chaque action à un acteur, une version de règle, une vérification humaine et l’empreinte de l’enregistrement précédent, écrits au moment de l’action.
Les 9 champs de cet enregistrement, rattachés à l’AI Act : Piste d’audit de l’IA
Seule, une passerelle réussit 1 test, peut en réussir 1 pour le trafic qu’elle porte, et échoue à 2.
Chaque test est repris de notre page de définition : son nom, la question à poser, la condition de réussite et le signal d’échec. Le dernier paragraphe de chacun donne notre lecture pour une passerelle seule.
- Aucun fournisseur captif
Multi-modèles par architecture
Question à poser. Retirez le fournisseur de modèle principal pour une classe de tâches en production et orientez la tâche vers le modèle de repli déclaré.
Condition de réussite. La bascule est un changement de configuration, pas une réécriture de code, et la piste montre la bascule avec son auteur et son horodatage.
Signal d’échec. La bascule exige une reconstruction ou une mise en production de code, ou la piste ne l’enregistre pas.
Une passerelle seule. Réussi, selon notre lecture. Orienter une tâche vers un autre fournisseur et basculer sur un repli en cas d’erreur sont la raison d’être de la catégorie, et la documentation des 2 passerelles citées sur cette page les décrit. La bascule doit encore être enregistrée avec son auteur et son horodatage : si la passerelle ne journalise pas ses propres changements de configuration, la seconde moitié du test échoue.
- La preuve au moment de l’action
Audit par architecture
Question à poser. Choisissez au hasard une décision passée et demandez son enregistrement, exporté depuis la piste.
Condition de réussite. L’enregistrement nomme l’acteur, le modèle et sa version, la règle, le vérificateur humain et l’horodatage sans assemblage manuel, et toute modification est détectable.
Signal d’échec. L’enregistrement est assemblé à la main à partir de plusieurs journaux, il manque un champ, ou il peut être modifié sans trace.
Une passerelle seule. Échoué, selon notre lecture. Une passerelle journalise l’appel à la frontière de l’API : la clé de l’appelant, le modèle, les jetons, et le prompt et la réponse quand la journalisation est active. Elle n’enregistre ni le vérificateur humain ni la règle du processus métier : il manque des champs à son journal. C’est une source de la piste d’audit, pas la piste.
- Vos données, votre juridiction
Souveraine par construction
Question à poser. Faites passer une charge étiquetée par la couche, tracez où se trouvent calcul, stockage, inférence et clés, puis tentez de l’orienter vers un modèle hors de son corridor déclaré.
Condition de réussite. Chaque étape reste dans le corridor déclaré, les clés restent sous la garde du client, et la tentative hors corridor est refusée et journalisée.
Signal d’échec. La résidence est écrite dans un contrat ou une note de politique mais n’est pas appliquée à l’exécution, ou l’appel hors corridor passe.
Une passerelle seule. Réussite possible pour le trafic qu’elle porte, selon notre lecture. Une passerelle peut refuser d’orienter une requête vers un fournisseur hors d’une région déclarée. Un appel qui la contourne échappe à son contrôle, et la garde des clés dépend de l’endroit où tourne la passerelle elle-même : le test doit couvrir toute la charge, pas la seule passerelle.
- Chaque agent peut être arrêté
Contrôle d’agent par architecture
Question à poser. Demandez à un agent d’appeler un outil hors de son périmètre, puis déclenchez le kill switch sur cet agent.
Condition de réussite. L’appel hors périmètre est refusé et journalisé, l’arrêt intervient avec la révocation de ses permissions d’outils, et les autres agents du processus continuent de tourner.
Signal d’échec. Plusieurs agents partagent un même compte de service, l’appel hors périmètre passe, ou arrêter un agent impose d’arrêter tout le processus.
Une passerelle seule. Échoué, selon notre lecture. Une passerelle peut bloquer ou brider les appels de modèles faits sous une clé. Les appels d’outils d’un agent qui ne la traversent pas échappent à son arrêt, et la révocation des permissions d’outils de l’agent relève du plan d’identité et de contrôle. Son arrêt atteint des appels, pas l’agent.
Un produit qui échoue à l’un des 4 tests n’est pas une couche d’exploitation de l’IA au sens de cette définition ; il peut en être un composant. Chaque test est un contrôle de la Reference Architecture v1.0, C1 à C4, avec la défaillance qu’il prévient et son ancrage réglementaire : contrôles C1 à C4
Les 4 tests tels qu’ils sont servis, avec leurs conditions de reprise : 4 tests pour l’acheteur
Quand la sortie est lue, pas exécutée.
Selon notre lecture, une passerelle seule suffit quand un usage d’IA produit un texte qu’une personne lit avant de décider, sans appel d’outil, sans écriture dans un autre système et sans décision sur une personne. Un assistant interne de rédaction ou de recherche en est le cas type.
Le jour où la sortie déclenche une action dans un autre système, cette action exige un responsable nommé, un enregistrement écrit au moment de l’action et un chemin d’arrêt. Ils se situent au-dessus de la passerelle, pas en elle.
La sortie déclenche-t-elle une action ?
Une écriture, un paiement, un message envoyé, un ticket clos. Si oui, l’action exige son propre responsable et son arrêt.
Nourrit-elle une décision sur une personne ?
Crédit, recrutement, sinistre, soin. Si oui, il faudra montrer plus tard qui a vérifié la sortie, et quand.
Un agent appelle-t-il des outils ?
Si oui, son identité, son périmètre et son arrêt ne peuvent dépendre des seuls appels qui traversent la passerelle.
Un seul oui, et la passerelle devient un composant d’une couche d’exploitation de l’IA.
Une passerelle est un composant du plan de routage et d’exécution.
Dans notre architecture de référence v1.0, le plan de routage et d’exécution exécute le travail : il oriente chaque tâche vers un modèle selon le profil de risque, le coût et la juridiction, et fait tourner les agents avec des permissions d’outils bornées. Le contrôle C1, multi-modèles par architecture, se teste dans ce plan.
Une passerelle y trouve sa place. Elle ne remplace pas les 3 autres plans : règles et gouvernance, preuve et audit, et le plan de contrôle qui porte l’identité, le périmètre et le chemin d’arrêt.
- Anti-modèle de l’architecture de référence
La surcouche (wrapper)
Une interface fine autour de l’API d’un seul modèle. Retirer le fournisseur casse le système : elle échoue à C1 et au test de changement de fournisseur.
Selon notre lecture, une passerelle placée devant un seul fournisseur, sans repli déclaré, est cette surcouche.
- Anti-modèle de l’architecture de référence
Le tableau de bord sans chemin d’arrêt
Un tableau de bord de gouvernance qui montre l’activité sans pouvoir l’arrêter. L’activité n’est pas la responsabilité ; sans kill switch câblé, il échoue à C4 et au test de délai d’arrêt.
Selon notre lecture, la vue analytique d’une passerelle, sans arrêt qui atteigne l’agent, est ce tableau de bord.
Les 4 plans, chacun avec une responsabilité et un artefact : modèle de référence de l’architecture
La pile par défaut, ses intégrations et la politique de pile, y compris ce que nous refusons de livrer : Ingénierie
Les questions posées sur les passerelles IA et la couche d’exploitation.
Une passerelle IA est-elle une couche d’exploitation de l’IA ?
Non. Une passerelle IA est un proxy qui achemine les requêtes vers les fournisseurs de modèles et applique clés, quotas, cache, journaux et filtres à la frontière de l’API. Une couche d’exploitation de l’IA inclut ce routage, puis rattache chaque action à un responsable nommé, une règle appliquée, un enregistrement en ajout seul et un chemin d’arrêt qui atteint les agents et leurs outils au-delà de l’appel d’API.
À quels tests une passerelle IA seule échoue-t-elle ?
Selon notre lecture, une passerelle seule passe le test multi-modèles, peut passer le test de souveraineté pour le trafic qu’elle porte, et échoue aux tests d’audit et de contrôle des agents. Son journal ne contient ni le vérificateur humain ni la règle du processus, et son arrêt atteint les appels qui la traversent, pas l’agent et ses outils.
Quand une passerelle IA suffit-elle ?
Selon notre lecture, quand un usage d’IA produit un texte qu’une personne lit avant de décider, sans appel d’outil, sans écriture dans un autre système et sans décision sur une personne. Dès que la sortie déclenche une action, cette action exige un responsable nommé, un enregistrement et un chemin d’arrêt, qui se situent au-dessus de la passerelle.
Les journaux d’une passerelle IA forment-ils une piste d’audit de l’IA ?
Pas à eux seuls. Ils enregistrent l’appel à la frontière de l’API. Une piste d’audit de l’IA enregistre chaque action avec l’identité de son acteur, le modèle et sa version, la règle appliquée, la vérification humaine, l’horodatage et la chaîne d’empreintes, écrits au moment de l’action. Les journaux de la passerelle sont l’une de ses sources.
Où se situe une passerelle IA dans une couche d’exploitation de l’IA ?
Dans le plan de routage et d’exécution de notre architecture de référence v1.0, où se teste le contrôle C1, multi-modèles par architecture. Le plan des règles et de la gouvernance, le plan de la preuve et de l’audit et le plan de contrôle l’entourent.
Documents de référence et sources primaires.
Chaque test, nom et statut cité sur cette page provient des sources ci-dessous, consultées le 25 octobre 2026.
Documents de référence
- Qu’est-ce qu’une couche d’exploitation de l’IA ? · 4 tests pour l’acheteur Les 4 tests, chacun avec sa question, sa condition de réussite et son signal d’échec. CC BY 4.0.
- Architecture de référence de la couche d’exploitation de l’IA v1.0 4 plans, contrôles C1 à C4 et 5 anti-modèles, à commencer par la surcouche.
- Ingénierie Disposition par défaut, intégrations et standard d’observabilité de la couche.
- Vérifier Hikari Blue · Q03 Une couche d’exploitation de l’IA n’est-elle qu’une surcouche autour de l’API d’un modèle ? Posez la question à un modèle que nous ne contrôlons pas.
- Glossaire de la couche d’exploitation de l’IA L’index des entrées, avec leur statut et leur citation.
Sources primaires, consultées le 25 octobre 2026
- OpenTelemetry · Semantic conventions for generative AI (ouvre dans un nouvel onglet) Statut Development. Spans, métriques et événements des appels de modèles, des agents, de l’exécution d’outils et de MCP, tenus dans ce dépôt depuis leur départ d’opentelemetry.io.
- Cloudflare Docs · AI Gateway (ouvre dans un nouvel onglet) Documentation produit, mise à jour le 20 avril 2026. Citée comme exemple de la catégorie.
- Microsoft Learn · AI gateway capabilities in Azure API Management (ouvre dans un nouvel onglet) Documentation produit datée du 29 mai 2026. Citée comme exemple de la catégorie.
Comment citer ce document.
Cette URL est permanente et sert toujours la version en vigueur. Chaque modification de fond incrémente la version et figure dans l’historique ci-dessous, afin qu’une citation reste rattachable au texte qu’elle cite.
Citation recommandée
Hikari Blue, « AI operating layer vs AI gateway », Glossary of the AI operating layer, v1.0, 25 octobre 2026, https://hikariblue.com/glossary/ai-operating-layer-vs-ai-gateway (édition française : /fr/glossary/ai-operating-layer-vs-ai-gateway)
Les ancres de section sont stables : #status, #covers, #leaves-open, #tests, #enough, #routing-plane, #faq, #references, #cite.
Historique des versions
v1.0 · 25 octobre 2026. Première version publique.
Licence. Publié sous licence CC BY 4.0 : citation, reprise et réutilisation libres, avec attribution à Hikari Blue et lien vers cette page. La licence couvre les textes, tableaux et schémas de Hikari Blue sur cette page ; elle ne couvre ni les données, citations et textes juridiques de tiers, qui gardent leurs propres conditions, ni le nom et le logo Hikari Blue, marques de UNITED4 LLC.
Apportez votre passerelle. Voyez ce qu’elle laisse ouvert.
30 minutes avec un associé désigné. Nous prenons un processus qui passe par votre passerelle et lui appliquons les 4 tests : ce que la passerelle couvre déjà, ce qui lui échappe, et quel plan doit porter chaque écart. Vous repartez avec la liste, que nous travaillions ensemble ou non.
- Un processus, passé aux 4 tests
- Ce que la passerelle couvre et ce qu’elle laisse ouvert
- Quel plan doit porter chaque écart