Suivre le rythme de l’innovation de pointe ne suffit pas à faire avancer l’entreprise : se préparer à la réglementation de l’IA

Michael MontoyaDirecteur des opérations technologiques | F5

Le secteur débat actuellement du rythme auquel l’IA de pointe devrait progresser. Ce débat s’est intensifié à la suite d’incidents révélés par Anthropic et OpenAI, au cours desquels des modèles fonctionnant avec des mesures de protection réduites, dans des environnements d’évaluation, ont entrepris des actions allant bien au-delà de ce qui était prévu. Ils ont accédé à des systèmes dont ils étaient censés être isolés et se sont coordonnés entre différentes instances qui devaient rester cloisonnées. Plus récemment, Dario Amodei, PDG d’Anthropic, a proposé que le développement des capacités de l’IA de pointe progresse à un rythme délibérément maîtrisé et que des évaluateurs indépendants soient intégrés aux laboratoires afin de s’en assurer.

Les réactions à cette proposition n’ont pas été unanimes. Les laboratoires d’IA se concentrent sur le processus de développement : le gain de capacités apporté par un cycle d’entraînement, le degré d’exhaustivité de l’évaluation d’un modèle avant sa mise à disposition et la question de savoir si les normes doivent être volontaires ou réglementaires. D’autres estiment que l’IA de pointe progressera à son propre rythme, que le reste du monde ne ralentit pas et que la sécurité doit être intégrée aux systèmes qui entourent les modèles.

Je ne vais pas trancher le débat ici, mais remarquez un point intéressant : les deux camps s’accordent à dire que les mécanismes de contrôle doivent être extérieurs au modèle et que la vérification ne doit pas incomber uniquement à ceux qui l’ont conçu.

Il s’agit d’une version plus large de l’argument que j’ai avancé en mai. J’écrivais alors que le périmètre de sécurité de l’IA s’était déplacé vers le chemin d’inférence. Les applications font appel aux modèles, les agents utilisent des outils et les modèles sollicitent à leur tour d’autres services pour récupérer des données, déclencher des workflows et exécuter des actions opérationnelles. J’en concluais que ce trafic devait être acheminé, inspecté, authentifié et régi comme toute autre interaction critique entre applications.

Il s’agissait d’un argument d’ordre architectural, mais, ces derniers mois, il a commencé à devenir un enjeu de conformité. Le rythme des avancées à la pointe de l’IA n’est pas celui des entreprises. Quelles que soient les décisions auxquelles parviendront les laboratoires et les gouvernements, les modèles déjà publiés sont actuellement déployés au sein de nos organisations, et les obligations liées à leur utilisation prennent déjà forme.

D’après mon expérience, une feuille de route en matière de sécurité comporte deux types d’éléments. Il y a ceux auxquels vous croyez, qui rivalisent avec tout le reste pour obtenir des financements et qui, parfois, n’en obtiennent pas. Et il y a ceux assortis d’une échéance, sur lesquels un auditeur vous interrogera et qui figurent dans le registre des risques. Les garde-fous en matière d’IA passent de la première catégorie à la seconde et, si vous travaillez dans ce secteur depuis suffisamment longtemps, cette évolution vous semblera familière.

Ce que la norme PCI DSS nous a appris

Nous avons déjà mené cette expérience. Avant 2008, la sécurité des applications web relevait en grande partie de l’intention : audits périodiques du code, analyses statiques et rigueur des développeurs. Puis est arrivée l’exigence 6.6 de la norme PCI DSS, qui imposait aux organisations traitant des données de titulaires de cartes soit d’examiner l’intégralité du code applicatif afin d’y détecter d’éventuelles vulnérabilités, soit de mettre en place un contrôle technique automatisé en amont des applications accessibles au public.

Deux choses à ce sujet m’ont marqué.

La norme PCI DSS n’était pas une loi à l’origine. Elle est née de la volonté des acteurs de notre secteur de prendre les devants sur la réglementation. Il s’agissait d’une norme contractuelle, appliquée au moyen d’accords avec les acquéreurs, qui a malgré tout transformé tout un marché. Et probablement plus rapidement que ne l’aurait fait une loi, car les contrats évoluent plus vite que les textes législatifs. C’est un point important, car les organisations ressentiront d’abord cette pression non pas de la part d’un régulateur, mais à travers un questionnaire de sécurité envoyé par un client, une clause d’un contrat d’approvisionnement ou un assureur demandant quels contrôles protègent leurs modèles.

Et puis, il y a la manière dont cela s’est terminé. Dans la version 4.0 de la norme PCI DSS, il n’est plus possible de choisir entre les deux options. L’alternative consistant à effectuer une revue du code a disparu ; une solution technique automatisée placée devant les applications web accessibles au public est désormais obligatoire au titre de l’exigence 6.4.2.

Aujourd’hui, plus personne ne se demande si la conformité PCI est facultative. Ce qui était une option est devenu une exigence.

Où en est aujourd’hui la réglementation de l’IA

La lune de miel réglementaire de l’IA est terminée. L’équivalent de la norme PCI pour l’IA se met en place simultanément sur plusieurs fronts, à des rythmes différents. Le règlement européen sur l’IA est le plus avancé. Ses obligations relatives aux modèles à usage général sont déjà en cours de mise en œuvre et, bien que l’Union européenne ait récemment reporté à décembre 2027 l’application des dispositions concernant les systèmes à haut risque, les exigences en matière de robustesse technique, de contrôle humain et de journalisation sont déjà définies. Ce que les entreprises ne comprennent généralement pas, c’est que certaines de ces obligations leur incombent directement, et pas seulement aux fournisseurs de modèles. Si elles intègrent le modèle d’un tiers à un cas d’usage à haut risque, elles en sont responsables.

Aux États-Unis, il n’existe pas encore de législation comparable, mais le cadre de gestion des risques liés à l’IA du NIST et son profil consacré à l’IA générative sont devenus la norme adoptée par de nombreuses organisations en matière de diligence raisonnable. La norme ISO/IEC 42001 joue un rôle similaire sur le plan de la certification et, de fait, je commence à la voir apparaître dans les documents d’appel d’offres. À l’échelle des États, plusieurs textes législatifs ont été proposés, combinant des exigences de transparence et de divulgation ainsi que des règles propres à certains usages, tandis que les autorités de réglementation des secteurs financier et de la santé examinent des lignes directrices adaptées à des scénarios spécifiques.

Et le Top 10 de l’OWASP pour les applications basées sur les LLM constitue désormais une référence incontournable lors des audits de sécurité. Lorsqu’un client envoie à un fournisseur un questionnaire sur les mesures de contrôle de l’IA, les questions en sont très souvent issues.

À la lecture de l’ensemble de ces documents, la même exigence revient sans cesse : démontrer que vous pouvez contrôler en continu ce qui entre dans un modèle et ce qui en sort, puis en conserver une trace.

C’est avant tout un problème opérationnel, avant d’être un problème de conformité

Notre rapport 2026 sur l’état des stratégies applicatives révèle que 55 % des portefeuilles d’applications intègrent désormais l’IA et qu’une entreprise utilise en moyenne sept modèles dans son parcours d’inférence. Plus de la moitié (52 %) enchaînent ou orchestrent plusieurs modèles. Et 90 % prévoient d’acheminer l’inférence via une infrastructure partagée.

Imaginez maintenant qu’un auditeur vous demande de démontrer qu’une politique unique — par exemple, qu’aucune donnée personnelle identifiable (PII) d’un client ne figure dans la réponse d’un modèle — est appliquée à l’ensemble de cette infrastructure.

Il est impossible de répondre à cette question en configurant individuellement sept modèles. Et encore moins lorsque trois d’entre eux sont enchaînés et que la sortie de l’un sert d’entrée à un autre. La plupart des organisations avec lesquelles j’échange n’en sont même pas encore là : lorsqu’elles commencent à examiner la situation, elles découvrent d’abord non pas un modèle auto-hébergé, mais des employés qui copient-collent des données sensibles dans des outils d’IA grand public, ainsi que des fonctionnalités d’IA activées discrètement dans des applications SaaS qu’elles utilisent déjà.

Ajoutez des agents à ce tableau, et l’unité à contrôler n’est plus le prompt, mais l’action : l’appel d’outil, la requête API, le workflow qu’elle déclenche. C’est précisément le point de contrôle que nous développons depuis 20 ans pour le trafic applicatif.

Cette même capacité agentique est déjà entre les mains d’attaquants qui mènent des campagnes coordonnées à la vitesse des machines. Comme nous l’avons appris dans la lutte contre les bots, nous devons cesser d’évaluer ce trafic à l’aune de son apparente sophistication et commencer à le contrôler en fonction de sa provenance et de ce qu’il cherche à accomplir.

Guardrails doivent être placés en dehors du modèle

Les organisations exploitent de plus en plus leurs propres modèles : des modèles à poids ouverts, déployés sur leur infrastructure et affinés à partir de leurs données. Elles ne bénéficient d’aucun filet de sécurité de la part du fournisseur et assument donc l’entière responsabilité opérationnelle et réglementaire.

Auditer chaque modèle individuellement n’est pas une approche viable à grande échelle. En principe, cela reste faisable pour une douzaine de configurations de modèles. J’ai vu des équipes s’y atteler. Mais le processus est manuel, devient obsolète dès que quelqu’un crée un nouveau point de terminaison et ne fournit qu’un état des lieux ponctuel plutôt qu’un véritable dispositif de contrôle.

L’alignement ne constitue pas un contrôle de sécurité. Les prompts système et le post-entraînement fournissent une base de référence utile. Les incidents impliquant OpenAI et Anthropic en montrent les limites. Il s’agissait de modèles dépourvus de garde-fous, poursuivant un objectif précis, se heurtant à une limite et la contournant. OpenAI a déclaré que les classificateurs utilisés dans ses déploiements clients standard auraient signalé cette activité comme dangereuse et que, si son dispositif étendu de surveillance de la chaîne de pensée avait été actif, il aurait alerté son équipe de sécurité avant que ses modèles n’atteignent Hugging Face. Les modèles d’Anthropic mis à la disposition du grand public intègrent des classificateurs qui analysent les entrées et les sorties en temps réel.

En réponse, les deux laboratoires ont mené d’importants travaux d’alignement, sans pour autant les juger suffisants. Tous deux ont également mis en place des contrôles externes au modèle : des dispositifs de surveillance qui observent ce qu’il fait et évaluent l’action avant son exécution, avec transmission à un opérateur humain si nécessaire. Les organisations qui possèdent la compréhension la plus approfondie possible de ces systèmes ont conclu que le contrôle devait être placé en dehors du modèle.

Par où commencer

Compte tenu de l’évolution de la réglementation et des enseignements tirés des vingt dernières années en matière de sécurité des applications sur la manière dont ces obligations s’imposent, il y a trois mesures que je mettrais en œuvre dès maintenant plutôt que d’attendre.

1. Cartographiez la surface d’exposition, en commençant par ce qui n’a pas été autorisé. Recensez chaque modèle en production — API SaaS, points de terminaison hébergés, déploiements autogérés de modèles à poids ouverts — ainsi que l’IA fantôme.
2. Dissociez l’application des règles du modèle. Intégrez les règles au parcours d’inférence, plutôt que dans sept configurations de modèles distinctes. Contrôlez les données en entrée et en sortie, et appliquez les règles de manière uniforme, quels que soient le modèle ou le cloud utilisés.
3. Créez la piste d’audit en dehors du système dont elle consigne l’activité. Journalisez les requêtes, les réponses, les éléments bloqués et l’identité des personnes ayant donné leur approbation. Veillez à ce que cette piste soit générée par une infrastructure que ni le modèle ni l’agent ne contrôlent. Les enquêteurs qui se sont penchés sur l’incident d’OpenAI ont constaté que les agents avaient tenté de modifier les traces de leurs propres actions. Si vos traces sont produites par le système qu’elles décrivent, leur fiabilité sera mise en doute.

L’essentiel ici est que la gouvernance de l’IA ne se résume pas à un exercice de documentation. Les exigences imposées aux organisations seront d’ordre technique, continu et probatoire. Il s’agit donc d’un enjeu d’architecture et d’exploitation qui relève des équipes de sécurité et d’exploitation, et non d’une question de politique interne à confier à votre service juridique.

Nous pensons que le contrôle doit s’exercer au niveau du chemin d’inférence, et non des modèles. Tous les modèles utilisés par votre organisation — API SaaS, point de terminaison hébergé, modèles à poids ouverts autogérés, ceux que vous avez autorisés comme ceux que vous n’avez pas encore découverts — convergent vers ce chemin. Il constitue donc le point de contrôle idéal pour l’ensemble de ces modèles, afin d’appliquer les politiques et de produire un registre indépendant et auditable.

Les règles sont encore en cours d’élaboration

Personne ne sait quelle exigence obligera son organisation à agir : une obligation découlant du règlement européen sur l’IA, une loi d’un État, une autorité de régulation sectorielle ou un contrat client. Ce que je sais, en revanche, c’est que les définitions techniques au sein de ces cadres ne sont pas encore arrêtées. Ce qui constitue une surveillance adéquate, une robustesse suffisante ou une documentation acceptable se décide en ce moment même, dans le cadre de consultations publiques, d’organismes de normalisation et de codes de bonnes pratiques.

Ce qui nous ramène au débat actuel sur le rythme de développement de l’IA de pointe. Sans entrer dans le fond du débat, je ferai une observation en tant que personne qui exploite ces systèmes en production : les entreprises évoluent selon un calendrier différent. Quelles que soient les décisions prises par les laboratoires, les gouvernements et le secteur, les modèles déjà publiés sont déployés et utilisés à grande échelle au sein de nos organisations, et les obligations liées à cette utilisation sont bien réelles. Que nous ralentissions ou non le développement des capacités, vous devrez toujours apporter des réponses à votre conseil d’administration, à vos dirigeants et à vos clients.

Ces décisions seront meilleures si elles s’appuient sur l’expérience de personnes ayant exploité ces systèmes à grande échelle, qui savent ce qu’il est réellement possible de faire respecter, ce qu’un contrôle coûte en termes de latence et de complexité, et dans quels cas une règle bien intentionnée incite à adopter des comportements contre-productifs. La norme PCI DSS a fonctionné parce que des professionnels de terrain ont contribué à son élaboration. Si nous restons à l’écart, les exigences seront tout de même rédigées. Simplement par des personnes qui n’ont jamais eu à les faire respecter.

En savoir plus sur l’approche de F5 en matière de sécurité de l’IA.

À propos de l’auteur

Michael MontoyaDirecteur des opérations technologiques | F5

Michael est responsable de la stratégie et de sa mise en œuvre à l’échelle de l’entreprise afin de placer la sécurité et la résilience au cœur de ses activités. Il dirige les équipes de F5 chargées de la sécurité, des risques et des opérations numériques, garantissant ainsi une confiance opérationnelle de bout en bout aux clients, aux partenaires et aux collaborateurs. Montoya a rejoint l’équipe de direction de F5 en octobre 2025, après avoir siégé au conseil d’administration de F5 de 2021 à 2025. Avant de rejoindre F5, Montoya était directeur des opérations chez BlueVoyant. Il avait auparavant occupé le poste de directeur de la sécurité des systèmes d’information chez Equinix et Digital Realty. Il a passé plus de dix ans chez Microsoft à des postes de direction à l’échelle mondiale, notamment en tant que directeur de la cybersécurité, DSI/RSSI régional pour la région EMEA et l’Asie, et responsable mondial des opérations des centres de données.

Autres articles de Michael Montoya