Nous continuons à faire comme si les modèles n’étaient que des points de terminaison. Comme si les serveurs hébergeant les moteurs qui encodent les données d’entrée en une série de nombres incompréhensibles n’existaient pas.
Ah, mon ami, ils existent bel et bien et vont devenir aussi importants pour la mise à disposition des applications que l’ont été les serveurs web et applicatifs. Ils vont également, une fois de plus, vous obliger à repenser l’architecture de votre infrastructure.
Voyez-vous, dès que vous placez un modèle derrière un point de terminaison (autrement dit, que vous déployez un serveur d’inférence), il emprunte les mêmes autoroutes des couches 4 à 7 (L4–L7) sur lesquelles repose votre activité. Nos dernières recherches sur la sécurité de l’IA montrent que 80 % des organisations exécutent déjà des tâches d’inférence dans le cloud ou sur site. Votre modèle constitue donc désormais une charge de travail de production supplémentaire qui transite par des répartiteurs de charge, des passerelles, des WAF et des courtiers d’API.
Nous avons également découvert plusieurs vérités potentiellement dérangeantes.
L’inférence multiplie les API
Tout d’abord, l’exploitation de l’inférence multiplie les API. Chaque nouvel assistant, service de scoring et indicateur de fonctionnalité associé à un modèle devient un nouveau point d’entrée. Cela multiplie les voies par lesquelles peuvent s’introduire les injections de prompts, les fuites et les manipulations de résultats, ainsi que les flux est-ouest par lesquels le contexte peut circuler de manière incontrôlée. Le déploiement de l’inférence va de pair avec une meilleure hygiène d’exécution, mais l’écart reste problématique. Parmi les équipes qui exploitent l’inférence, 14 % laissent encore passer les prompts sans les inspecter. Chez les utilisateurs qui recourent exclusivement au SaaS, ce chiffre grimpe à 40 %. Faire l’impasse sur l’inspection, ce n’est pas « faire simple ». C’est laisser grande ouverte la porte de l’écurie tout en félicitant le cheval pour son endurance lorsqu’il prend la fuite.
C’est pourquoi le point de contrôle est essentiel. L’inférence emprunte les mêmes canaux que vos API : les politiques doivent donc être appliquées directement sur le chemin des flux. Les équipes qui déploient l’inférence semblent l’avoir compris. Soixante et un pour cent utilisent une passerelle d’IA pour inspecter les entrées et les sorties, 39 % ajoutent des pare-feu et 35 % recourent à des proxys personnalisés. Les utilisateurs qui s’appuient uniquement sur des solutions SaaS se reposent sur les paramètres par défaut des fournisseurs, et cela se voit. Ils sont trois fois plus susceptibles de faire totalement l’impasse sur les tests ou la surveillance, et 30 % ne consignent ni les prompts ni les réponses à des fins d’audit, contre seulement 8 % des équipes qui déploient l’inférence. Cet écart témoigne d’une différence de maturité, mais représente aussi une opportunité. Si vos applications utilisent des services d’IA tiers, une passerelle d’IA devient le point d’intégration des tests continus, du filtrage et des politiques. Ne vous contentez pas d’un prompt bien tourné et d’une prière.
L’inférence renforce l’importance des DPU
Deuxièmement, l’inférence fait passer les DPU du statut d’éléments appréciables à celui d’éléments indispensables. Parmi les équipes qui exécutent des charges d’inférence, 71 % envisagent ou adoptent des DPU lors de l’achat de matériel ou du choix d’instances. Dans le groupe qui ne déploie pas de charges d’inférence, ce chiffre s’établit à 43 %. Lorsque le trafic chiffré, l’inspection en ligne et l’évaluation des politiques transitent par les mêmes machines qui assurent le fonctionnement de vos applications, le déchargement des traitements n’est pas un simple artifice destiné à améliorer les performances. C’est ce qui permet de maintenir une latence acceptable tout en déchiffrant, classant, inspectant et appliquant les règles à grande échelle. Les DPU accélèrent précisément les tâches dont l’inférence a le plus besoin : la sécurité de la couche de transport (TLS), la télémétrie, les politiques granulaires et les contrôles pour chaque requête. En bref, plus il y a d’inférence, plus la charge sur le réseau augmente, et les DPU l’absorbent.
L’inférence implique de prêter attention au contexte
Enfin, le contexte est le deuxième garde-fou que la plupart des équipes oublient de respecter. L’inférence ne se résume pas aux entrées et aux sorties. Elle englobe l’historique, les informations récupérées, les outils et les échanges entre agents. Alors que les organisations envisagent d’adopter le Model Context Protocol (MCP), nous observons déjà la même tendance. Les entreprises qui déploient des modèles prévoient de se standardiser sur ce protocole : 58 % d’entre elles indiquent vouloir adopter le MCP, contre 21 % dans le groupe qui n’en déploie pas. Son attrait est évident : le MCP promet de structurer les flux de contexte.
Le risque est tout aussi évident. Un contexte opaque peut devenir un canal auxiliaire qui contourne vos belles politiques. Il faut donc mettre en place un contrôle capable de comprendre les prompts et les réponses générées, mais aussi la provenance du contexte lui-même et les politiques qui lui sont appliquées. Si vous ne laisseriez pas des données non auditées alimenter votre moteur de trading, ne laissez pas non plus un contexte non audité entrer dans votre modèle.
L’impact sur l’architecture de l’infrastructure
Alors, qu’est-ce que tout cela implique pour votre architecture ? Car vous savez bien que cela a forcément des conséquences.
Points clés à retenir
- Intégrez les règles au flux. Les passerelles et les proxys L7 sont déjà intégrés au flux. Rendez-les sensibles à l’inférence. Inspectez les prompts, filtrez les sorties, étiquetez les données et appliquez, par application et par utilisateur, des limites réellement pertinentes pour les modèles.
- Utilisez des DPU pour maîtriser la latence. Si vous comptez déchiffrer, classifier, inspecter et appliquer les règles à l’exécution sans déchargement matériel, vous finirez par sacrifier la sécurité au profit des performances un vendredi soir, avant de prétendre le lundi qu’il s’agissait d’une décision mûrement réfléchie.
- Traitez le contexte comme une chaîne d’approvisionnement. Standardisez son mode d’assemblage, étiquetez-le, validez-le avant utilisation et consignez sa traçabilité. MCP est utile, mais seulement si vous l’associez à des outils d’observabilité et de contrôle capables de détecter et d’empêcher les utilisations abusives du contexte.
La conclusion la plus marquante de notre dernière étude est tout simplement que l’inférence est désormais une charge de travail de premier plan. Elle repose sur les mêmes infrastructures que tout le reste, mais elle introduit de nouveaux risques que vos « réflexes en matière d’API » ne permettent pas de couvrir entièrement.
Rendez l’infrastructure plus intelligente, confiez les tâches les plus lourdes aux DPU et gouvernez le contexte, pas seulement l’appel. Les équipes qui le feront déploieront plus vite et dormiront sur leurs deux oreilles. Les autres apprendront la résilience à leurs dépens.
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
Les paquets empoisonnés sont en train de tuer notre industrie
L’open source ne dispose pas d’un registre central recensant les paquets malveillants, alors même que l’IA et l’automatisation accélèrent les attaques contre la chaîne d’approvisionnement. L’écosystème a besoin d’un moyen fiable de signaler et de suivre les compromissions.
Top 10 des risques liés à la mise en production d’applications d’IA : manque de sécurité et de conformité réglementaire
L’IA étend la conformité au-delà de la sécurisation des chemins d’accès et des espaces de stockage pour englober la gouvernance du comportement à l’exécution — accès aux modèles, contexte de récupération, résultats et actions des agents —, de sorte que les contrôles doivent être rapprochés de l’inférence.
Top 10 de la livraison d’applications d’IA : politiques de livraison incompatibles
Les divergences de politiques deviennent des sources de pannes pour l’IA : des mécanismes de basculement, des délais d’expiration, des limites et des contrôles de sécurité incohérents entraînent des défaillances silencieuses, des résultats partiels et des résultats différents selon le point de terminaison.
Top 10 de la mise à disposition d’applications d’IA : orientation du trafic non optimisée
L’IA remet en cause les principes traditionnels de répartition du trafic : les backends ne sont pas interchangeables, les coûts varient et les agents multiplient les requêtes de manière imprévisible. Le routage doit donc tenir compte du modèle, de l’état des GPU et de la localisation des données.
Top 10 de la livraison d’applications d’IA : contrôles du trafic insuffisants
Les limites de débit et les mécanismes de régulation traditionnels ne tiennent pas compte de l’étendue réelle des répercussions. Les charges de travail d’IA se répartissent entre les modèles, les bases de données vectorielles et les services, provoquant des pics de latence, des défaillances en cascade et des nouvelles tentatives.
La gestion des fenêtres de contexte en IA n’a rien de magique. C’est une question d’architecture.
Découvrez pourquoi les créateurs d’applications d’IA doivent gérer le contexte, la mémoire et l’infrastructure, tout en faisant évoluer les processus de livraison et la sécurité afin d’éviter la dérive, la latence et les attaques par injection de prompts.