Quatre idées reçues des dirigeants sur l’IA

Kunal AnandDirecteur des produits | F5

Notre rapport 2026 sur l’état de la stratégie applicative révèle que 78 % des organisations exécutent désormais elles-mêmes l’inférence d’IA, sur sept modèles en moyenne. Un an auparavant, notre indice de préparation à l’IA estimait à 2 % la part des organisations véritablement prêtes à déployer l’IA à grande échelle.

L’écart entre ces deux chiffres est actuellement ce qu’il y a de plus intéressant dans les technologies d’entreprise. Les entreprises n’ont pas attendu d’être prêtes. Elles ont internalisé l’inférence afin de garder le contrôle de leurs données, de leurs coûts et de leur sécurité. Elles découvrent maintenant ce qu’implique ce contrôle. Appelons cela le parcours d’inférence : tout ce qui se passe entre l’intention d’un utilisateur et la sortie d’un modèle. Récupération, routage, appels d’outils, identité, assemblage du contexte, application des politiques, trajet retour. Le modèle est un composant de ce parcours. Le parcours lui-même constitue le système, et c’est la partie dont vous êtes responsable.

Quatre idées reçues auxquelles je me heurte régulièrement découlent toutes de la même erreur : considérer le modèle comme le produit et le parcours d’inférence comme une simple infrastructure technique.

Idée reçue n° 1 : « Tout repose sur le modèle. »

Quel modèle, quel fournisseur et quel cas d’usage dois-je mettre en avant ? C’est la première question posée dans presque toutes les discussions avec des dirigeants, et c’est celle qui résiste le moins à l’épreuve du temps.

Les modèles sont le composant interchangeable. Seules 8 % des organisations s’appuient exclusivement sur des services d’IA publics. Les autres utilisent des portefeuilles diversifiés, précisément parce qu’elles prévoient de changer de modèle, d’acheminer les requêtes différemment et de recourir à des solutions de repli en fonction du coût, de la précision et de la sécurité. Si votre architecture fait d’un changement de modèle un projet plutôt qu’une simple modification de configuration, vous avez déjà fait le mauvais pari.

Ce qui ne se remplace pas, c’est le parcours d’inférence. La couche de récupération qui détermine le contexte auquel le modèle a accès. La logique de routage qui choisit le modèle chargé de traiter chaque requête. L’identité associée à l’appel. La politique qui définit ce que le modèle peut faire de la réponse. C’est de là que viennent la précision, la maîtrise des coûts et votre avantage concurrentiel exclusif. Un concurrent peut acheter le même modèle dès demain. Mais il ne peut pas acheter votre parcours.

Idée reçue n° 2 : « Si le projet pilote a fonctionné, la mise en production sera facile. »

Le problème n’est pas que la mise en production est plus difficile, mais qu’elle est complexe et que chaque étape supplémentaire amplifie cette complexité. Selon une étude de F5, la grande majorité des entreprises (93 %) utilisent plusieurs clouds, tandis que 86 % répartissent leurs applications dans des environnements multicloud hybrides. Votre parcours d’inférence traverse l’ensemble de ces environnements, dont la complexité ne cesse de croître. À mesure que les organisations ajoutent des modèles, des applications et des agents, le nombre de parcours d’inférence possibles se multiplie.

Nos recherches ont également révélé que 52 % des organisations enchaînent ou orchestrent déjà plusieurs modèles. Prenons une chaîne et supposons que chaque étape soit fiable à 95 %, ce qui est une estimation généreuse dès lors qu’entrent en jeu la récupération d’informations, les appels d’outils et un modèle probabiliste. Une chaîne pilote en trois étapes réussit dans 86 % des cas. Une chaîne de production en 20 étapes ne réussit que dans 36 % des cas. Pourtant, le taux de fiabilité par étape n’a pas changé. Le système, qui fonctionnait plutôt bien, est devenu largement défaillant simplement parce que vous avez ajouté des étapes.

Appliquons maintenant le même calcul à la sécurité. Si chaque agent d’une chaîne présente un risque de 5 % d’être manipulé, de se voir attribuer un périmètre inadapté ou de recevoir un identifiant auquel il ne devrait pas avoir accès, un workflow composé de 20 agents offre à un attaquant une très forte probabilité qu’au moins un maillon soit exploitable. C’est pourquoi plus de neuf répondants sur dix signalent de nouvelles catégories de problèmes lorsque l’IA agentique passe en production : gestion des identifiants, audit des actions et question fondamentale de savoir ce qu’un agent a fait et sous l’autorité de qui.

Idée reçue n° 3 : « Les performances, la sécurité et la gouvernance sont des priorités distinctes. »

Dans une architecture applicative traditionnelle, cette séparation pouvait se justifier. La sécurité était gérée en parallèle. La gouvernance était examinée chaque trimestre. Les performances relevaient d’une autre équipe, dotée d’un budget distinct.

L’IA regroupe ces trois dimensions au sein d’un même budget, mesuré en millisecondes et en jetons. Chaque garde-fou ajouté au processus d’inférence augmente la latence. Chaque exigence de gouvernance mobilise une partie de la fenêtre de contexte, ce qui engendre un coût à chaque appel. Inspection des prompts, filtrage des résultats, masquage des données à caractère personnel, routage des modèles, logique de nouvelle tentative : chacun de ces éléments constitue à la fois un contrôle de sécurité, un coût en matière de performances et un poste budgétaire. Vous ne pouvez pas financer l’un sans puiser dans les ressources des autres, ni réduire l’un sans exposer le reste.

C’est véritablement nouveau. Auparavant, le surcoût lié à la sécurité était amorti de manière invisible. Sur le chemin d’inférence, il se répercute sur le p95 et sur la facture, ce qui rend désormais le compromis explicite et impose que quelqu’un en assume la responsabilité. Aujourd’hui, le contrôle le plus couramment mis en place est l’authentification pour les services d’IA et l’accès aux API, utilisée par 55 % des organisations, tandis que 47 % prévoient d’adopter une infrastructure sensible à l’identité pour les agents. Dans les deux cas, l’intention est bonne. Mais ces mesures augmentent également la latence du chemin d’inférence. Prévoyez délibérément un budget pour les mettre en œuvre, faute de quoi vos équipes finiront discrètement par les abandonner afin d’atteindre un objectif de performance.

Idée reçue n° 4 : « Les solutions ponctuelles ajoutent de la complexité, mais nous pouvons nous en accommoder. »

Prenons l’entreprise médiane de notre échantillon : elle utilise sept modèles, opère dans plusieurs clouds et dispose d’applications réparties entre des environnements sur site, de cloud public et de colocation. Ajoutez un outil distinct pour la sécurité des API, un autre pour les fonctions de passerelle d’IA et un autre encore pour la gouvernance des résultats. Chaque politique que vous définissez doit désormais être correctement formulée dans chaque langage, pour chaque environnement et chaque modèle, puis vérifiée à nouveau dès que l’un de ces éléments change. Le nombre d’endroits où une politique peut dériver sans que cela soit détecté correspond au produit de toutes ces variations.

Lorsqu’un problème survient à 2 heures du matin, personne n’est seul responsable de répondre à la question « quel contrôle était censé détecter cela ? ». La solution n’est pas de réduire les capacités, mais de disposer d’un point de contrôle unique sur le parcours, quels que soient le modèle, l’environnement ou le protocole utilisé de l’autre côté.

La cohérence des politiques et la liberté de choix des modèles ne sont pas incompatibles. Elles ne le deviennent que lorsque les politiques sont intégrées au modèle plutôt que placées en amont. La convergence de la mise à disposition des applications et de la sécurité sur une plateforme unique permet de changer de modèle chaque semaine tout en continuant à répondre aux questions d’un auditeur depuis un seul et même endroit.

Les questions qu’il convient de se poser maintenant

Voici quatre questions à poser à votre équipe de direction tandis que votre organisation s’efforce de gérer le parcours d’inférence :

1. Combien de modèles sont actuellement en production, et combien de temps faut-il pour en ajouter ou en remplacer un ?
2. Quelle est la plus longue chaîne d’agents actuellement en production, et quel est son taux de réussite de bout en bout mesuré ?
3. Où la politique en matière d’IA est-elle appliquée, et combien d’emplacements distincts faudrait-il modifier pour la mettre à jour ?
4. Quel pourcentage de votre latence d’inférence au 95e centile est imputable aux mesures de sécurité et de gouvernance, et qui est responsable de cet indicateur ?

Si ces questions donnent lieu à des estimations plutôt qu’à des réponses, c’est une information utile, qu’il vaut bien mieux obtenir maintenant que lors d’un incident. Je recommande à chacun d’auditer le parcours d’inférence ce trimestre. Les organisations qui seront à la pointe de cette nouvelle ère ne seront pas celles qui utiliseront le plus l’IA. Ce seront celles qui pourront expliquer précisément ce qui se passe entre la requête et la réponse, partout où l’IA est déployée.

Pour approfondir les données, téléchargez le Rapport 2026 sur l’état de la stratégie applicative. Pour découvrir comment F5 étend sa stratégie de plateforme de distribution et de sécurité des applications à l’IA d’entreprise, consultez la page Web de la F5 AI Security Platform. N’oubliez pas non plus de consulter le communiqué de presse publié aujourd’hui.

À propos de l’auteur

Kunal AnandDirecteur des produits | F5

Kunal Anand dirige l’organisation produit de F5 en tant que directeur des produits. Responsable de la vision, de la stratégie et de l’exécution des produits, il veille au développement de solutions révolutionnaires qui répondent à des enjeux critiques et offrent aux clients des expériences exceptionnelles. Dans ses précédentes fonctions de directeur de la technologie et de l’IA, Kunal a défini la stratégie et la vision de l’entreprise en matière de technologie et d’intelligence artificielle. Avant de rejoindre F5, Kunal a occupé le double poste de directeur de la technologie et de directeur de la sécurité des systèmes d’information chez Imperva. Son parcours chez Imperva a débuté en 2018 avec l’acquisition de Prevoty, une start-up spécialisée dans la sécurité des applications qu’il avait cofondée en 2013. Avant de rejoindre Prevoty, il était directeur de la technologie chez BBC Worldwide. Fort d’une longue expérience en matière d’innovation et d’une solide expertise technique, Kunal a dirigé des équipes chargées de la sécurité, des données, de la technologie et de l’ingénierie chez Gravity, MySpace et au Jet Propulsion Laboratory de la NASA. Kunal possède plus de 15 ans d’expérience dans les domaines de l’IA et de l’apprentissage automatique, notamment dans l’entraînement de modèles, l’utilisation d’algorithmes fondés sur l’IA pour améliorer les produits, ainsi que la conception et la mise en œuvre d’architectures d’IA. Kunal est titulaire d’une licence en informatique du Babson College.

Autres articles de Kunal Anand