Les bénéfices de l'IA se reflètent rarement dans le compte de résultat, et cela relève généralement d'un problème d'architecture plutôt que d'un problème de modèle. Les équipes déploient un prototype fonctionnel, mais constatent ensuite que les gains escomptés sont absorbés par la latence, par des coûts de calcul excessifs et par des incidents de sécurité qui n'étaient pas prévus dans le budget. Le modèle fonctionne correctement. Mais l'infrastructure sous-jacente n'a jamais été conçue pour supporter la charge de travail jusqu'à la mise en production.
Akamai a fait réaliser deux études pour identifier précisément le point où se produit cette rupture. Le rapport sur l'état de l'inférence d'IA 2026 s'appuie sur les réponses de 200 professionnels qui exécutent des charges d'inférence en production. Parmi eux, les trois quarts sont des ingénieurs ou des architectes, et la plupart participaient aux décisions de déploiement. L'Étude 2026 des impacts sur la sécurité des API, quant à elle, a été menée auprès de 1 840 professionnels de la sécurité issus de six secteurs d'activité et de dix pays différents.
Ces deux rapports conduisent à la même conclusion : la plupart des équipes cherchent à monter en charge sur des infrastructures conçues pour l'entraînement des modèles, et adaptées tant bien que mal à l'inférence. Les lacunes qui en résultent se traduisent par des coûts élevés, de la latence et une exposition accrue aux risques.
Ces lacunes disparaissent lorsque trois éléments sont réunis :
Une architecture qui s'adapte aux conditions réelles
Une sécurité intégrée à cette architecture, plutôt qu'ajoutée après coup
Des moteurs d'inférence suffisamment proches des utilisateurs pour répondre aux exigences de réactivité en temps réel
Individuellement, aucun de ces éléments n'est nouveau. Le problème survient lorsqu'ils sont traités comme des projets distincts, gérés par des équipes différentes.
Commençons par les fondamentaux. L'inférence est l'étape opérationnelle au cours de laquelle un modèle entraîné reçoit de nouvelles données et produit un résultat. Chaque requête d'inférence transite sous forme d'appel d'API. Le modèle et l'API ne constituent donc pas deux préoccupations distinctes. Ils partagent le même chemin de requête, les mêmes modes de défaillance et la même surface d'attaque. C'est un constat qui ressort clairement des deux enquêtes.
Là où la centralisation atteint réellement ses limites
L'inférence centralisée n'est pas vouée à disparaître. Pour l'entraînement, les traitements par lots et les charges de travail tolérantes à la latence, concentrer les ressources de calcul dans quelques grandes régions reste souvent la meilleure approche. De nombreuses charges de travail d'Akamai reposent d'ailleurs déjà sur ce modèle. Les données racontent une histoire plus concise et plus utile : la centralisation atteint ses limites pour une catégorie spécifique de charges de travail en pleine croissance, et de nombreuses équipes n'ont pas encore adapté leur architecture à cette réalité.
Le rapport sur l'état de l'inférence d'IA révèle que 75 % des entreprises ont déjà mis l'IA générative en production, mais que leur infrastructure n'a pas suivi cette évolution. Une part grandissante de ces charges de travail s'accompagne désormais d'exigences strictes en matière de latence en temps réel, qu'un aller-retour vers une région éloignée ne peut satisfaire. Par ailleurs, 60 % des personnes interrogées considèrent la proximité avec les utilisateurs et les données comme étant « importante » ou « critique ».
Pourtant, 46 % d'entre elles continuent d'exécuter l'inférence depuis une seule région centralisée. Le problème réside dans ce décalage : la centralisation n'échoue pas partout, mais une proportion croissante des charges de travail d'inférence en production doit tourner plus près de l'utilisateur que ne le permet une infrastructure centralisée.
Les premières charges de travail concernées sont prévisibles : détection de la fraude au sein d'une transaction en cours, agents vocaux, personnalisation en temps réel et tout pipeline agentique qui enchaîne plusieurs appels à des modèles avant de produire une réponse. Chaque étape hérite de la latence de la précédente. Lorsque tout est concentré dans une même région, plus l'utilisation augmente, plus les délais d'attente s'accumulent, ajoutant des centaines de millisecondes précisément lorsque la charge de travail ne peut pas se le permettre.
Le débat n'est donc pas de savoir s'il faut centraliser ou distribuer les traitements à tout prix. Il s'agit de déterminer quelles charges de travail nécessitent la proximité et lesquelles peuvent s'en passer. Les équipes qui réussissent cette transition répondent à cette question de manière délibérée, en analysant chaque charge de travail individuellement, plutôt que d'affecter systématiquement tous les traitements à une seule région et d'en subir le coût en latence.
Une architecture adaptable et des coûts invisibles
Un faible retour sur investissement est souvent le signe qu'une équipe compense des limites architecturales par des efforts opérationnels. L'indicateur révélateur est l'économie unitaire : le coût d'une requête d'inférence individuelle, mesuré par jeton ou par demande. Si vous n'avez pas de vision sur cette métrique, vous ne pouvez ni l'optimiser ni identifier le moment où les coûts commencent à déraper.
Or, la plupart des équipes manquent précisément de cette visibilité : 77 % des entreprises ne disposent pas d'un suivi cohérent de l'économie unitaire de l'inférence. Par conséquent, la majorité est incapable de déterminer si une charge de travail devient plus ou moins coûteuse à mesure qu'elle prend de l'ampleur. Ce manque de visibilité engendre également des lacunes en matière de sécurité. Une hausse inexpliquée de la consommation de jetons est souvent le premier signe d'une attaque de type Denial of Wallet (DoW), qui consiste à augmenter volontairement le volume d'inférence afin de faire exploser les coûts.
Lorsque l'architecture ne peut pas s'adapter par elle-même, les ingénieurs doivent intervenir manuellement. Ils redirigent le trafic à la main lorsqu'une région connaît un pic d'activité. Ils dégradent la qualité des réponses pour maintenir à flot un serveur sous pression. Lorsque l'inférence ralentit, 51 % des équipes relancent la requête sur le même modèle, ce qui aggrave généralement la congestion au lieu de la résorber. C'est une approche de gestion de crise qui ne résiste pas à la montée en charge. Plus un système rigide monte en charge, plus ses pertes augmentent.
La solution réside dans l'automatisation :
Associer à chaque requête d'inférence des métadonnées sur le modèle et la consommation de jetons, transmises à des outils de supervision en temps réel. Cela permet d'identifier un modèle dont les coûts s'emballent avant qu'il ne compromette le budge.
Définir dans le code des comportements de type « fail-open » et « fail-closed », afin que le système puisse automatiquement basculer vers un résultat mis en cache ou vers un modèle local plus léger lorsque le modèle principal ne répond plus, sans nécessiter l'intervention d'un ingénieur à deux heures du matin.
64 % des professionnels interrogés considèrent déjà l'orientation automatisée du trafic comme un impératif, ce qui indique clairement la direction que prend le marché.
La distribution comme moteur de performance
Lorsque le faible retour sur investissement se manifeste par une latence élevée et un faible taux de conversion, l'emplacement géographique est souvent à l'origine du problème. L'inférence en temps réel se caractérise par des pics d'activité imprévisibles et une forte sensibilité à la latence. Elle ne peut pas être gérée de manière fiable via l'Internet public et un centre de données éloigné.
Les chiffres sont implacables. Si votre budget de latence de bout en bout est de 250 millisecondes, qu'un traitement prend 100 ms et que le handshake API en prend 50, il ne reste plus que 100 millisecondes pour le transit des données. Lorsqu'il faut traverser un continent, ce budget est consommé avant même que le modèle n'ait commencé à travailler.
Déployer l'inférence sur des points de présence distribués permet d'exécuter les traitements les plus lourds dans la même région que l'utilisateur, d'éviter les congestions de l'Internet public et d'éliminer les limitations imposées par une infrastructure centralisée. La réponse semble provenir du système local car, du point de vue du réseau, c'est effectivement le cas.
Lorsqu'il est question d'agents d'IA, on estime qu'il faut environ six interactions pour qu'une tâche soit réellement accomplie. Si l'utilisateur est suffisamment éloigné pour qu'une interaction prenne 100 millisecondes, cela représente déjà 600 millisecondes. Cela peut être acceptable pour certaines applications, mais de nos jours, de nombreuses applications déployées en bordure de l'Internet sont sensibles à la latence. Dans le cas d'un système d'IA intégré à un véhicule, par exemple, il est absolument essentiel que les données et les informations soient transmises dans des délais beaucoup plus courts.
La distribution apporte aussi un avantage majeur en matière de sécurité. Lorsque l'inférence et les mécanismes de contrôle sont exécutés au même endroit, le réseau peut authentifier l'utilisateur, inspecter l'appel d'API et exécuter le modèle dans un environnement unique. Vous fermez ainsi la boucle de traitement au lieu d'envoyer la requête d'une zone à une autre pour qu'elle soit vérifiée ailleurs.
La sécurité est une composante de l'architecture, et non une opération à part
Si vous ne sécurisez pas l'inférence, vous ne pouvez pas la déployer à grande échelle. Et si vous considérez la sécurité comme une opération à part, vous en paierez le prix en matière de performances. Les deux études montrent que le véritable problème ne réside pas dans la topologie de l'infrastructure, mais dans les API non sécurisées, insuffisamment testées et invisibles.
Les chiffres sont frappants : 87 % des entreprises ont été confrontées à un incident de sécurité lié aux API au cours de l'année écoulée, par rapport aux 76 % enregistrés en 2022. Parmi les équipes ayant été victimes d'un incident, les attaques liées aux API les plus citées (42 %) sont celles ciblant des API associées à des technologies d'IA.
En moyenne, le coût d'un incident s'élève désormais à 700 000 USD par an, tandis que le quartile supérieur des incidents dépasse 1,8 million de dollars. Les API associées à l'IA ne représentent pas un risque futur ; elles constituent déjà un risque bien réel.
Vous ne pouvez pas défendre ce que vous ne pouvez pas voir
Alors que les incidents se multiplient, la visibilité se dégrade. Seules 23 % des entreprises savent lesquelles de leurs API renvoient des données sensibles, contre 40 % en 2022. Il est impossible de protéger un patrimoine digital dont on ignore l'étendue, et l'IA l'élargit plus rapidement que les inventaires manuels ne peuvent le suivre. Les copilotes créent des points de terminaison qui ne font jamais l'objet d'une évaluation de sécurité. Les interfaces en langage naturel facilitent l'extraction de données par injection de prompts pour tout attaquant qui découvre une voie d'accès insuffisamment protégée.
Plus important encore, le point d'entrée ne représente qu'une partie du problème. Lorsqu'un attaquant compromet une API exposée, il cherche généralement à se déplacer latéralement vers les composants qui concentrent la véritable valeur : les systèmes de données qui alimentent les modèles d'IA (feature stores) et les dépôts contenant les poids des modèles et leur logique métier.
La microsegmentation, une bonne pratique de sécurité qui consiste à isoler individuellement les charges de travail, permet de contenir le rayon d'impact. La plupart des entreprises ne l'ont pas encore mise en œuvre, mais celles qui l'ont adoptée parviennent à contenir les attaques bien plus rapidement. Les approches traditionnelles de segmentation du réseau sont largement reconnues comme complexes, laborieuses et peu efficaces. Les solutions avancées de microsegmentation basées sur l'IA répondent à ces limites, tout en remettant en cause certaines habitudes profondément ancrées. Si vous intégrez cette segmentation au même réseau que celui qui assure la distribution de l'inférence, vous n'avez plus besoin de choisir entre protection et performances.
Le modèle de mise en œuvre repose sur l'identité. Les entreprises devraient :
définir les droits d'accès sur la base de l'identité des charges de travail plutôt que des adresses IP, afin qu'un service d'inférence donné puisse accéder uniquement au feature store qui lui est destiné, et à rien d'autre ; et
mettre en œuvre une détection continue des API pour identifier les points d'accès de test abandonnés qui sont encore connectés à des données de production.
La sécurité devient alors une propriété permanente de l'infrastructure, plutôt qu'un audit ponctuel que les équipes de développement finissent par contourner.
Deux trajectoires, un même problème
Le problème plus profond mis en lumière par les deux études est organisationnel plutôt que technique. Les équipes traitent la gestion du trafic et la sécurité comme deux chantiers distincts, et c'est à leur point de jonction que les défaillances apparaissent.
Cette fracture se manifeste notamment par un décalage de perception : 40 % des dirigeants de haut niveau estiment que leur entreprise a atteint un niveau avancé de maturité en matière de tests d'API, alors que seules 28 % des équipes DevSecOps sur le terrain partagent cet avis. Les dirigeants pensent que le problème est résolu, si bien que les ressources allouées aux fondations restent insuffisantes tandis que les investissements sont concentrés dans des outils connexes. L'écart entre ce que la direction pense être protégé et ce qui l'est réellement continue donc de se creuser.
Pour le réduire, les équipes responsables de la gestion du trafic et celles responsables de le sécuriser doivent s'appuyer sur le même plan de contrôle, ou au moins sur un plan de contrôle convergent. Lorsque les mécanismes de détection et de confinement partagent le même plan, un schéma de requêtes anormal caractéristique d'une attaque par injection de prompts ou DoW peut déclencher automatiquement l'isolement du point d'inférence concerné, sans intervention humaine. Cette synchronisation n'est possible que lorsque la distribution et la sécurité ne reposent pas sur des systèmes distincts.
Les critères pour une montée en charge réussie
Deux conditions distinguent les équipes capables de monter en charge de celles qui atteignent leurs limites :
La portabilité. Les opérateurs les plus matures sont nettement moins dépendants d'un fournisseur unique, car ils peuvent déplacer leurs charges de travail entre GPU gérés, API hébergées et environnements d'exécution serverless en fonction des coûts et des capacités disponibles.
La gouvernance à l'exécution. Le contrôle de prompts malveillants en entrée et des réponses susceptibles de divulguer des données sensibles en sortie est appliqué au niveau du réseau, et non ajouté après coup à l'application.
Lorsque ces capacités sont réunies au sein d'une seule plateforme où distribution, sécurité et acheminement du trafic partagent un même plan de contrôle, le compromis entre protection et performances disparaît. Vous disposez alors d'une vision unifiée de ce qui s'exécute, de l'endroit où cela s'exécute et des attaques en cours.
C'est précisément l'enjeu auquel Akamai répond depuis longtemps pour la diffusion de contenu et la sécurité, et auquel elle répond aujourd'hui pour l'inférence en production. Le même réseau mondial qui rapproche les moteurs d'inférence des utilisateurs assure également la sécurité des API, la microsegmentation et la protection contre les attaques par déni de service distribué (DDoS) qui les entourent. C'est cette couverture qui permet à une seule infrastructure réseau d'accomplir simultanément ces deux missions.
Un retour sur investissement fragile de l'IA n'est qu'un symptôme
La véritable cause réside dans une infrastructure qui n'a pas encore rassemblé architecture adaptable, sécurité et distribution sur une base commune. L'écart entre performances et protection continue de se creuser, mais il n'est ni structurel ni irréversible. Cet écart se résorbe lorsque les équipes qui gèrent le trafic sont aussi celles qui le sécurisent, sur une infrastructure conçue pour prendre en charge l'inférence, et non adaptée après coup pour la tolérer.
En savoir plus
Pour approfondir le sujet, consultez le rapport sur l'état de l'inférence d'IA 2026 et l'Étude des impacts sur la sécurité des API.
Mots-clés
