Les entreprises déploient leurs premiers agents et découvrent aussi comment gouverner les interactions entre les modèles, les applications et les données ?

Une nouvelle catégorie de logiciels, les AI Gateways, ambitionne de devenir le point de contrôle de ces architectures. À l’image des API Gateways il y a vingt ans, cette couche pourrait redéfinir la manière dont les DSI construiront leurs infrastructures d’intelligence artificielle. A condition qu’elle tienne ses promesses.

L’histoire des systèmes d’information est jalonnée de ruptures technologiques qui ont progressivement fait apparaître de nouvelles couches d’infrastructure.

Au début des années 1990, la priorité était de connecter les réseaux tout en les protégeant : les pare-feu sont devenus le point de passage obligé entre l’entreprise et Internet.

Au début des années 2000, la généralisation des architectures orientées services puis des microservices a fait émerger une autre nécessité : contrôler les échanges entre applications. Les API Gateway se sont imposées pour authentifier les appels, appliquer des politiques de sécurité et fournir une visibilité centralisée.

Une décennie plus tard, l’explosion du cloud a donné naissance aux plateformes IAM modernes, aux CASB (Cloud Access Security Broker) aux solutions SASE et aux plateformes CNAPP (Cloud-Native Application Protection Platform, des outils de sécurisation des applications cloud) pour répondre à de nouveaux besoins de gouvernance.

L’IA générative semble suivre le même chemin. Après une première phase centrée sur le choix d’un modèle de langage performant, les entreprises découvrent qu’elles doivent désormais administrer un écosystème où plusieurs modèles coexistent, où des agents IA prennent des décisions, et où les interactions avec le système d’information deviennent plus nombreuses et plus dynamiques.

Du mono-modèle au multi-modèle

Entre 2023 et 2024, la plupart des expérimentations reposaient sur un seul fournisseur : une application appelait un modèle via une API, point final. Cette architecture reste simple.

En 2026, le changement d’échelle est net. Selon une analyse de Vercel portant sur les usages en production, la part des équipes exploitant cinq modèles ou plus est passée de 29 % à 37 % en un an. Un basculement structurel plutôt qu’un ajustement marginal.

Un assistant bureautique peut désormais mobiliser un modèle propriétaire pour la génération de texte, un modèle open source exécuté localement pour des traitements confidentiels, un modèle spécialisé pour l’analyse documentaire et un moteur multimodal pour l’image ou la vidéo.

Cette diversification répond à trois logiques :

• Économique : les tarifs varient fortement d’un fournisseur à l’autre, et le « race to the bottom » sur le prix au token pousse les DSI à arbitrer plutôt qu’à dépendre d’un seul acteur. Plusieurs gateways commerciales (Vercel, OpenRouter, Cloudflare, LiteLLM) ont d’ailleurs supprimé toute marge sur les tokens en 2026, déplaçant la concurrence vers la fiabilité et la gouvernance.
• Réglementaire : avec l’entrée en application progressive de l’AI Act, certaines entreprises veulent conserver la maîtrise de traitements sensibles ou privilégier des fournisseurs offrant davantage de garanties sur la localisation des données.
• Fiabilité opérationnelle : les incidents chez les grands fournisseurs de modèles ne sont plus anecdotiques. Selon des données citées par Vercel, les principaux fournisseurs de LLM ont chacun cumulé une vingtaine d’incidents et près de 180 heures d’indisponibilité sur le seul mois de décembre 2025. Un argument concret en faveur du multi-fournisseur et du failover automatique.

Cette évolution fait apparaître une difficulté nouvelle : comment administrer un environnement où plusieurs modèles sont utilisés simultanément par des centaines d’applications, sans multiplier les clés d’API et les intégrations ad hoc ?

Les agents IA changent la nature du système d’information

La généralisation des agents constitue un second facteur de rupture.

Un chatbot traditionnel répond à une question. Un agent peut planifier une série d’actions : consulter une base documentaire, interroger un ERP, créer un ticket dans un outil ITSM, envoyer un courriel, puis transmettre le résultat à un autre agent. Il ne produit plus seulement une réponse : il agit.

Pour les équipes d’architecture, cela change la nature des flux. Les échanges ne s’effectuent plus uniquement entre applications connues : ils impliquent des composants capables de choisir eux-mêmes quels outils utiliser selon le contexte.

Le protocole MCP (Model Context Protocol), qui standardise la façon dont un modèle accède à des outils externes et structure une bonne partie de ces échanges. Cependant, son adoption rapide crée aussi une nouvelle surface d’exposition, puisque chaque connecteur MCP est potentiellement une porte d’entrée vers un système interne.

Dans de nombreuses entreprises, chaque application dialogue encore directement avec le modèle retenu par son équipe de développement. Cette approche fonctionne tant que les projets restent peu nombreux mais elle devient difficile à maintenir dès que plusieurs dizaines d’applications utilisent plusieurs fournisseurs. Chaque équipe doit alors gérer séparément les clés d’API, les politiques de sécurité, les limites de consommation, la journalisation, les changements de version des modèles et les règles de conformité propres à chaque fournisseur.

Plus le nombre d’agents augmente, plus le nombre d’interactions explose, avec un risque bien connu : la multiplication incontrôlée de connexions point à point, que l’histoire des systèmes d’information a déjà vu se reproduire à chaque rupture technologique.

Une nouvelle couche apparaît : l’AI Gateway

Concrètement, une AI Gateway se place comme un proxy entre les applications et les fournisseurs de modèles (OpenAI, Anthropic, Google, Azure, modèles open source auto-hébergés).

Elle expose un point d’entrée unique et ajoute, selon les offres, du routage multi-modèle, du failover automatique en cas de panne d’un fournisseur, du cache sémantique pour réduire coûts et latence sur des requêtes similaires, des quotas et budgets par équipe ou par utilisateur, de la journalisation au niveau du token, ainsi que des fonctions de sécurité comme le masquage de données personnelles ou la détection de tentatives d’injection de prompt.

Le marché s’est structuré très vite en 2026, avec des positionnements différenciés :

Cette diversité montre que le terme « AI Gateway » recouvre encore des réalités différentes selon l’éditeur : certains sont d’abord des routeurs de coûts, d’autres des plateformes de gouvernance, d’autres des extensions d’API Gateway existantes.

Ce qu’en disent les analystes

Gartner a publié en 2025 et 2026 plusieurs travaux dédiés (Market Guide for AI Gateways et  Market Overview actualisé en 2026) qui positionnent cette couche comme un composant des futures architectures d’IA d’entreprise, chargé de gérer les connexions vers les services d’IA, d’appliquer des politiques de sécurité, de répartir les requêtes entre plusieurs modèles et d’améliorer la visibilité sur les coûts.

Le cabinet inscrit plus largement l’AI Gateway dans son cadre AI TRiSM (Trust, Risk and Security Management), dont il estimait le marché à environ 3,1 milliards $en 2025, avec une croissance annuelle projetée de l’ordre de 35 % jusqu’en 2030. Un chiffre à prendre comme un ordre de grandeur d’analyste plutôt qu’une certitude, la firme elle-même révisant régulièrement ses prévisions à mesure que le marché se consolide.

Le NIST AI Risk Management Framework converge sur le fond. Sans employer le terme « AI Gateway », il insiste sur la nécessité de mécanismes de gouvernance, de traçabilité et de surveillance continue tout au long du cycle de vie des systèmes d’IA. Des fonctions qu’une gateway peut techniquement porter, sans que le référentiel ne prescrive cette architecture en particulier.

La Cloud Security Alliance défend une lecture proche, estimant que la gouvernance de l’IA ne peut plus être traitée uniquement au niveau applicatif.

Ce que l’AI Act rend concrètement nécessaire

L’argument réglementaire mérite d’être précisé, car le calendrier a changé courant 2026.

Le paquet Digital Omnibus, adopté définitivement fin juin 2026, a reporté au 2 décembre 2027 la plupart des obligations pesant sur les systèmes à haut risque de l’annexe III (recrutement, crédit, éducation, justice, biométrie). Reste en vigueur au 2 août 2026 l’essentiel des obligations de transparence de l’article 50 : informer les utilisateurs qu’ils interagissent avec une IA, et identifier les contenus générés ou modifiés par IA.

Pour les systèmes qui resteront soumis au régime haut risque, l’article 12 impose une journalisation automatique et infalsifiable des événements, avec une conservation minimale de six mois (vingt-quatre mois pour la biométrie), et l’article 14 exige une supervision humaine effective.

Ce sont précisément les fonctions ( journalisation centralisée, traçabilité au niveau de chaque appel et points de contrôle humain ) qu’une AI Gateway peut industrialiser à l’échelle de dizaines d’applications, plutôt que de les faire reconstruire par chaque équipe projet. Le règlement précise aussi, dans ses considérants 99 et 100, que dans une chaîne d’agents IA, l’obligation de conformité s’étend à chaque agent exécutant une fonction à haut risque. Un argument de poids pour centraliser la gouvernance plutôt que de la disperser.

Le report ne change donc pas la logique de fond : il retire simplement l’urgence à très court terme, sans annuler la nécessité d’anticiper une architecture capable de produire ces preuves de conformité.

Les limites du concept

Cette convergence d’analyses ne doit pas masquer les zones d’incertitude.

Un marché encore jeune et instable. Le rachat de Portkey par Palo Alto Networks, l’incident de sécurité touchant LiteLLM et le nombre élevé d’éditeurs recensés (plus de 160 selon certains annuaires spécialisés) suggèrent une consolidation rapide plutôt qu’un marché mature. Une DSI qui adopte aujourd’hui une gateway prend un pari sur la pérennité de son éditeur.

Un nouveau point de défaillance unique. Concentrer tout le trafic IA sur une seule couche crée mécaniquement un single point of failure : si la gateway tombe, c’est l’ensemble des applications IA de l’entreprise qui s’arrête, même si les modèles sous-jacents fonctionnent normalement.

Une latence ajoutée, mais généralement marginale. Plusieurs comparatifs indépendants estiment le surcoût d’une gateway bien opérée à quelques millisecondes à quelques dizaines de millisecondes. Ceci est négligeable face à un appel de modèle qui dure plusieurs secondes, sauf en cas de mauvaise implémentation.

Une frontière floue avec l’existant. Une partie des fonctions revendiquées (authentification, quotas, logs) peut aussi être portée par une API Gateway classique déjà en place, ce qui pose la question : faut-il une brique dédiée ou une extension de l’infrastructure API existante ? Les offres de type Kong ou Zuplo, qui fusionnent les deux mondes, illustrent que la frontière entre « API Gateway » et « AI Gateway » n’est pas encore stabilisée.

Le risque de gouvernance en façade. Une gateway journalise et contrôle les flux, mais elle ne résout pas à elle seule les causes profondes des incidents d’IA en entreprise. Gartner estime qu’une large majorité des transactions IA non autorisées proviennent de mauvais usages internes plutôt que d’attaques malveillantes. Un problème davantage organisationnel que technique, qu’un outil ne suffit pas à traiter.

Ce que cela signifie pour les DSI

L’histoire des pare-feu, des API Gateway puis des CASB montre que ces couches d’infrastructure, une fois qu’elles s’imposent, deviennent difficiles à retirer.

Pour une DSI qui déploie aujourd’hui plusieurs modèles et commence à expérimenter des agents, la question n’est plus de savoir si une gouvernance centralisée sera nécessaire, mais quand l’introduire et avec quel degré de couplage à l’infrastructure existante.

Un point de départ raisonnable consiste à cartographier les usages IA actuels et à venir, à évaluer si une extension de l’API Gateway déjà en place suffit à court terme, et à ne s’engager sur un éditeur dédié qu’après avoir mesuré son modèle de sécurité, sa pérennité financière et le degré de lock-in qu’il introduit.

Dans un marché qui se consolide aussi vite qu’il grossit, la prudence sur le choix du fournisseur compte au moins autant que la décision d’adopter la brique elle-même.

Sources :
> Gartner (Market Guide for AI Gateways, 2025 ; Market Overview for AI Gateways, 2026 ; Market Guide for AI Trust, Risk and Security Management, 2025
> NIST AI Risk Management Framework 1.0
> Cloud Security Alliance
> Règlement (UE) 2024/1689 (AI Act)
> Paquet Digital Omnibus adopté fin juin 2026 

The post AI Gateway : la prochaine bataille des infrastructures IA appeared first on Silicon.fr.

Le « tout au cloud » atteint ses limites

Pendant une décennie, la centralisation dans le cloud a été le réflexe dominant. Mais un déluge de données générées sur le terrain – capteurs, machines, caméras, objets connectés – met ce modèle à l’épreuve. Selon Gartner, environ 75 % des données générées par les entreprises sont désormais produites et traitées en dehors d’un data center centralisé.

La cause est physique autant qu’économique. Le nombre d’objets connectés a dépassé 15 milliards d’unités dans le monde en 2024 et pourrait atteindre près de 30 milliards d’ici 2030. Faire transiter toutes ces données vers un cloud central engendre des coûts de bande passante, des délais et une dépendance à la connexion réseau que de nombreux usages ne tolèrent pas.

Trois limites apparaissent clairement. La latence : certaines applications (robot industriel, véhicule autonome, contrôle qualité par vision) exigent des réponses en quelques millisecondes, incompatibles avec un aller-retour vers un data center lointain. Les coûts : transférer et stocker des volumes massifs au loin coûte cher. La résilience : une activité critique ne peut s’arrêter à chaque coupure réseau.

À ces limites s’ajoute la souveraineté. Certaines données sensibles – santé, défense, secrets industriels – ne peuvent ou ne doivent pas quitter un site ou un territoire donné, pour des raisons réglementaires ou stratégiques. Les traiter localement, en périphérie, plutôt que de les exporter vers un cloud central potentiellement soumis à des lois extraterritoriales, devient un argument de plus en faveur d’une architecture distribuée. Latence, coût, résilience et souveraineté convergent ainsi pour remettre en cause le réflexe du « tout au cloud ».

L’edge computing, une réponse de proximité

L’edge computing (informatique en périphérie) consiste à traiter la donnée au plus près de sa source, plutôt que de tout envoyer vers un cloud central. Un serveur local, une passerelle IoT ou un équipement durci analyse les données sur place, ne remontant vers le cloud que l’essentiel – résultats, agrégats, alertes.

Les bénéfices sont directs. La latence chute, permettant des réponses en temps réel ; les besoins en bande passante diminuent, puisque seules les données utiles remontent ; et l’activité continue de fonctionner même en cas de coupure réseau, gage de résilience. Dans l’industrie, des passerelles en périphérie peuvent réduire la latence de plus de moitié et diminuer fortement la dépendance au cloud.

L’edge n’est pas une mode mais une lame de fond, portée par l’industrie 4.0, l’IoT et l’IA. Les dépenses mondiales liées à l’edge computing croissent d’environ 13 % par an et pourraient atteindre 317 milliards de dollars en 2026. La maintenance prédictive, la supervision locale, l’analyse vidéo ou les systèmes autonomes en sont les cas d’usage emblématiques.

L’usine est l’illustration la plus parlante de cette bascule. Une ligne de production moderne génère un déluge de données – capteurs sur les machines, caméras de contrôle qualité, robots collaboratifs – qu’il serait absurde et risqué de faire transiter intégralement vers un cloud distant. Traiter ces flux sur place permet de détecter un défaut en temps réel, d’arrêter une machine avant la casse ou de guider un robot, sans dépendre d’une connexion. C’est dans ces environnements physiques et critiques que l’edge démontre le plus clairement sa valeur.

Hybride : la fin du choix binaire

L’edge ne remplace pas le cloud : les deux se complètent. Le cloud excelle pour le stockage à grande échelle, l’analytique avancée et l’entraînement des modèles d’IA ; l’edge pour le traitement local, rapide et résilient. La bonne architecture n’est ni « tout cloud » ni « tout edge », mais un continuum où chaque donnée est traitée à l’endroit le plus pertinent.

C’est la définition même de l’environnement hybride : une infrastructure combinant cloud public, ressources privées ou sur site, et edge, orchestrés ensemble. Pour l’industrie comme pour les services, l’enjeu de 2026 n’est plus de choisir un camp, mais de concevoir cette architecture distribuée et de l’orchestrer intelligemment.

Cet arbitrage dépasse la seule technique. Il touche aux coûts (l’edge demande un investissement matériel initial mais réduit les coûts récurrents), à la résilience (continuité d’activité), et à la souveraineté (traiter localement des données sensibles plutôt que de les exporter). Il devient un levier de compétitivité et un sujet de direction, pas seulement de DSI.

Par où commencer

Aborder les environnements hybrides et l’edge ne suppose pas de tout transformer d’emblée. L’approche éprouvée est progressive :

• Partir des cas d’usage: identifier les applications réellement contraintes par la latence, la bande passante ou la résilience – ce sont les premières candidates à l’edge.
• Raisonner placement de la donnée: décider, pour chaque flux, où il est le plus pertinent de le traiter (cloud, sur site, edge).
• Démarrer par un pilote: tester sur un site ou une ligne de production avant de généraliser.
• Anticiper l’orchestration et la sécurité: gérer une infrastructure distribuée à l’échelle suppose des outils et des pratiques dédiés.

L’enjeu pour un dirigeant n’est pas d’opposer cloud et terrain, mais d’orchestrer le continuum entre les deux. À mesure que les données naissent en périphérie et que l’IA s’invite jusque dans les ateliers, la capacité à traiter chaque flux au bon endroit devient déterminante pour la performance, la résilience et la souveraineté. Les environnements hybrides ne sont pas une complexité subie de plus : bien conçus, ils sont la réponse architecturale à un monde où la donnée ne vit plus seulement dans le nuage.

Un dernier point mérite l’attention : l’edge est aussi un facilitateur de l’IA sur le terrain. Faire tourner un modèle d’IA directement en périphérie – pour analyser un flux vidéo, détecter une anomalie sur une machine ou guider un robot – suppose une capacité de calcul locale que seul l’edge procure. À mesure que l’IA se diffuse dans les opérations physiques, la maîtrise de l’edge conditionne la capacité à en tirer parti. Cloud et edge ne sont donc pas concurrents mais les deux faces d’une même infrastructure moderne, où l’intelligence se déploie du centre jusqu’à la périphérie.

Ce contenu est publié par Mentioned

The post Gérer son infrastructure entre cloud et terrain : l’enjeu des environnements hybrides et de l’edge appeared first on Silicon.fr.