Le dilemme des équipes IT : une extension .ai transporte-t-elle vraiment du trafic IA ?

La présence de .ai dans l’adresse du package ne prouve pas que celui-ci envoie une requête à un modèle d’intelligence artificielle sur le réseau ; seuls le journal des requêtes, le point de terminaison cible et les données transportées peuvent le démontrer.

Cette distinction paraît mineure, mais elle a des conséquences considérables pour l’IT d’entreprise. Le nom de domaine d’une plateforme de formation peut contenir « ai », sa présentation peut mentionner l’intelligence artificielle, et la plateforme peut même utiliser l’IA dans certains flux de travail. Rien de cela ne signifie que la formation SCORM examinée à cet instant communique avec un service d’IA.

Le package SCORM chargé par une organisation pour une formation SST ou RGPD peut ne contenir que du HTML, du JavaScript, des visuels, des vidéos, des questions et une communication SCORM standard. Dans ce cas, le package écrit simplement dans le LMS la progression, le score, la réalisation et parfois le temps passé. C’est le comportement réel sur le réseau. Pas ce que suggère le nom de domaine.

La véritable question pour les équipes IT devrait être :

Non pas « Comment ce contenu est-il nommé ? », mais « Vers quelle cible le navigateur envoie-t-il quelles données, et dans quel but ? »

Cette approche peut parfois sembler plus laborieuse. Mais la sécurité, c’est aussi un peu cela : examiner le comportement plutôt que les étiquettes. On ne peut pas savoir ce qu’une boîte contient parce qu’il est écrit « coffret de chimie » dessus. Les gens aiment faire confiance aux étiquettes des boîtes ; les paquets réseau respectent assez peu cette habitude.

Un nom de domaine n’est pas une classification technologique

L’extension d’un nom de domaine n’est pas une déclaration technique. .ai, .com, .org ou toute autre extension n’explique ni les services avec lesquels l’application communique, ni où les données sont traitées, ni quelles informations sont extraites du client.

De même, la présence du mot « IA » dans la brochure d’un produit ne constitue pas à elle seule un constat de sécurité. La brochure peut expliquer les problèmes pour lesquels le produit utilise l’intelligence artificielle. Le journal réseau, lui, montre ce que fait réellement le composant exécuté à cet instant. Confondre les deux revient à transformer une revue d’architecture en lecture de texte marketing.

Avec Nextrain, l’intelligence artificielle peut être utilisée pour la production de formations, la structuration de contenus, la génération de questions, la conception de parcours d’apprentissage et la production de rapports. En parallèle, des packages SCORM 1.2 et SCORM 2004 peuvent être importés ; les contenus déjà produits par l’organisation ou obtenus ailleurs peuvent donc être gérés sous un même toit.

Ces deux situations sont distinctes :

Situation examinée	Question de l’équipe IT	Preuve attendue
Formation SCORM statique	Le package appelle-t-il un service en dehors du LMS ?	Journaux réseau du navigateur, journaux DNS, logs proxy
Communication SCORM-LMS	Quelles données d’apprentissage le package écrit-il dans le LMS ?	Appels d’API SCORM, enregistrements de réalisation et de score
Interaction assistée par IA	Une fonction d’IA est-elle réellement appelée ?	URL de requête, corps de requête, flux de réponse
Utilisation de contenu externe	D’où proviennent la vidéo, les polices, les analyses ou les médias ?	Domaines tiers, appels CDN et médias
Revue de protection des données	La requête contient-elle des données personnelles ou du contenu sensible ?	Analyse des payloads, masquage et journaux d’accès

La ligne la plus importante du tableau est peut-être la troisième : Une fonction d’IA est-elle réellement appelée ? Le fait qu’une fonctionnalité d’IA existe dans le produit ne signifie pas que chaque cours, chaque utilisateur et chaque session l’utilise.

C’est comme supposer que, dans un bâtiment électrifié, le four fonctionne simultanément dans chaque pièce. Le câble peut être là ; la charge apparaît lorsque l’interrupteur est activé.

Que fait réellement un package SCORM ?

SCORM est une norme permettant à une formation de communiquer avec un LMS. Un package contient généralement des fichiers de contenu, un manifeste de contenu et du JavaScript qui gère la progression de la formation. Lorsque le package est ouvert dans le LMS, le contenu peut transmettre via le navigateur, à l’API SCORM standard, des informations telles que :

Le démarrage ou non de la formation,
L’état de réalisation,
L’état de réussite ou de validation,
Le score du test,
Le temps passé dans la formation,
Dans certaines conceptions, des données de réponse ou d’interaction.

Les différences entre SCORM 1.2 et SCORM 2004 peuvent être importantes ; mais, dans l’examen du trafic IA, la question fondamentale ne change pas : À qui le package parle-t-il en dehors des enregistrements d’apprentissage standard du LMS ?

Un package SCORM est techniquement du contenu web exécuté dans le navigateur. Le code JavaScript personnalisé ajouté au package peut donc tenter de générer différentes requêtes réseau, dans la mesure où il y est autorisé. Un package peut charger une image externe, appeler une vidéo, envoyer des données d’analyse ou adresser une requête à une API. Si le concepteur le souhaite, il peut même se connecter au point de terminaison d’un service d’IA.

Mais entre « peut le faire » et « le fait », il y a autant de différence qu’une passerelle réseau.

La norme SCORM elle-même n’exige aucun appel à l’intelligence artificielle. La norme concerne l’enregistrement de l’état d’apprentissage [SCORM 1.2, 2001; SCORM 2004, 2004]. Coller automatiquement une étiquette « risque IA » sur un package SCORM n’est donc pas une classification technique, mais le cousin pressé de la prudence.

Où l’équipe IT doit-elle regarder en premier ?

Une évaluation de sécurité doit cartographier le flux de données plutôt que classer le produit en un seul mot. À mon avis, le bon point de départ consiste à diviser la question « Y a-t-il de l’IA ? » en éléments plus observables.

1. Ouvrez le contenu du package et lisez le manifeste

Un package SCORM est généralement une archive compressée. L’examen peut commencer par les fichiers suivants :

imsmanifest.xml
Pages HTML
Fichiers JavaScript
Fichiers de configuration
Adresses de ressources externes
Liens vers des vidéos, visuels et PDF

Le manifeste montre le point d’entrée et les ressources du package. Il ne décrit pas forcément tout le comportement réseau à lui seul ; mais il constitue un bon point de départ pour comprendre la structure du package.

Dans les fichiers JavaScript, il convient notamment de rechercher les expressions suivantes :

fetch(
XMLHttpRequest
WebSocket
EventSource
sendBeacon
axios
https://
wss://

La présence de ces mots n’est pas automatiquement un constat de risque. Le contenu web moderne peut effectuer des requêtes réseau. L’examen ne s’arrête pas là ; il faut analyser vers quel nom de domaine, avec quelles données et à quels moments cet appel est effectué.

Qu’un cours accède à une adresse média pour charger une vidéo et qu’il envoie la question libre d’un utilisateur au point de terminaison d’un modèle génératif ne sont pas la même chose. Tous deux sont du « trafic » ; mais leurs profils de risque, catégories de données et exigences de contrôle sont différents.

2. Observez le véritable journal réseau dans le navigateur

Un package SCORM doit être exécuté dans un environnement de test selon un parcours utilisateur normal. Ouvrir seulement l’écran principal ne suffit pas. Il faut répondre au quiz, parcourir les sections, lancer la vidéo, remplir les champs de texte libre éventuels et achever le processus de réalisation.

Ensuite, les questions suivantes doivent être posées dans les journaux réseau du navigateur :

Vers quels noms de domaine les requêtes sont-elles envoyées ?
Quelle est la méthode de requête : GET, POST, PUT ?
Que contient le corps de la requête ?
La réponse arrive-t-elle sous forme de flux ?
La requête est-elle générée lorsqu’un utilisateur effectue une action ?
La même requête apparaît-elle dans chaque session ou uniquement lors d’une interaction donnée ?
Le trafic est-il limité au domaine du LMS, ou existe-t-il de nouvelles cibles externes ?

Les requêtes POST requièrent une attention particulière. Elles peuvent indiquer que des données sont envoyées depuis le client. Cependant, chaque POST n’est pas un appel IA : il peut aussi s’agir de l’enregistrement d’un score, de l’envoi d’un formulaire, de la gestion de session ou d’un journal d’événements. Conclure « nous avons vu un POST, donc il y a de l’IA » sans faire cette distinction revient à prendre chaque nuage pour un incendie dès qu’il pleut.

3. Lisez ensemble les journaux DNS, proxy et pare-feu

Les outils de développement du navigateur sont utiles ; mais la visibilité du réseau d’entreprise est plus large. Si possible, l’équipe IT doit comparer les enregistrements suivants sur la même période :

Requêtes DNS,
Journaux de passerelle web sécurisée ou de proxy,
Journaux de sortie du pare-feu,
Journaux d’accès à l’application,
Requêtes CDN et médias,
Événements d’authentification.

Qu’un contenu accède uniquement à des noms de domaine approuvés constitue un comportement réseau explicable et limité. En revanche, les appels vers des points de terminaison nouveaux ou inconnus doivent être étudiés. Le critère ne doit pas être « Son nom ressemble-t-il à de l’IA ? ». Certains services d’IA peuvent utiliser des domaines ordinaires ; certaines plateformes sans aucune IA peuvent avoir une extension .ai.

Du point de vue du réseau, les extensions sont du décor, les enregistrements de routage sont des preuves.

Quels signaux comptent pour distinguer le trafic IA ?

Le trafic IA n’a pas une signature technique unique. Certains signaux peuvent toutefois orienter l’examen au bon endroit.

Dans une interaction d’IA générative, on observe souvent :

Le texte libre saisi par l’utilisateur dans le corps de requête,
L’envoi de longs fragments de texte ou de contenu de documents,
Une progression de la requête et de la réponse sous forme de conversation,
La réception d’une réponse en flux,
La production de texte dynamique qui varie selon la question de l’utilisateur,
Une structure d’appel vers un modèle ou un service d’inférence.

En revanche, les comportements suivants ne constituent pas à eux seuls un appel IA :

L’enregistrement de l’état de réalisation SCORM,
L’envoi d’un score de quiz,
L’enregistrement d’un événement de lecture vidéo,
La vérification d’une condition de certificat,
Le reporting de la progression de formation,
Le chargement d’un fichier visuel, d’une police ou d’une vidéo.

Dans Nextrain, des interactions telles qu’une aide assistée par IA peuvent être conçues au sein de la formation. Si une telle interaction est utilisée, l’équipe IT doit l’évaluer comme un flux distinct. En revanche, le comportement d’un package SCORM classique ne contenant pas d’interaction IA doit être évalué à partir du contenu du package et des traces réseau. Le fait qu’ils se trouvent sur la même plateforme ne montre pas qu’ils ont le même comportement réseau.

À ce stade, je pense à cette distinction insistante que Kalde fait en écrivant des scénarios : ce qui change le résultat dans une histoire n’est pas la porte devant laquelle se tient le personnage, mais le choix qu’il fait. Dans l’examen réseau aussi, le nom de domaine est la porte ; la requête est le choix. La décision de sécurité doit reposer sur le second.

Pourquoi « tout bloquer » n’est-il pas une politique suffisante ?

Il est compréhensible que les organisations soient prudentes face à l’intelligence artificielle. Lorsque des données couvertes par le RGPD, des informations clients, des secrets commerciaux, des données de santé ou des données de performance des employés sont en jeu, la prudence n’est pas un excès, mais une exigence de conception.

Mais bloquer tout dans une catégorie unique peut rendre invisibles deux coûts différents :

De vrais risques peuvent passer inaperçus.
Un service sans extension .ai peut aussi faire sortir des données. Le filtrage des noms de domaine ne remplace pas le contrôle des flux de données.
Des flux de formation inoffensifs ou nécessaires peuvent être interrompus.
Si un contenu SCORM qui n’effectue aucun appel IA est bloqué uniquement à cause de la suggestion créée par son nom de domaine, les employés ne peuvent plus accéder à leur formation ; l’IT ne peut pas non plus expliquer clairement quel comportement technique elle bloque.

La situation la plus intéressante que j’ai rencontrée est la suivante : la même organisation peut dire d’un côté « bloquons tout ce qui contient de l’IA » et, de l’autre, demander pourquoi le rapport de formation n’est pas à jour. Cette contradiction n’est pas malveillante. Les gens réfléchissent souvent, sur des écrans séparés, à la protection contre le risque et à la continuité des opérations. Les systèmes, eux, doivent vivre les deux en même temps.

Une meilleure politique établit les distinctions suivantes avant toute interdiction catégorique :

Une fonction d’IA est-elle utilisée ?
Si elle est utilisée, quelles données sont envoyées ?
Ces données contiennent-elles des données personnelles, des données sensibles ou des informations internes confidentielles ?
Vers quel point de terminaison approuvé la requête est-elle envoyée ?
Les conditions de transfert et de conservation des données sont-elles conformes à la politique de l’organisation ?
Si la fonction d’IA n’est pas utilisée, le contenu fonctionne-t-il selon un flux SCORM standard ?

Il ne s’agit pas d’assouplir la sécurité. Au contraire, il s’agit de rendre le contrôle plus précis.

Liste de contrôle applicable pour l’examen SCORM et IA

Les équipes IT, sécurité de l’information, juridique et formation examinent le même fichier avec des questions différentes. La solution la plus saine est de ne pas laisser l’évaluation à une seule équipe, sans pour autant rendre les responsabilités floues.

La liste de contrôle suivante peut être utilisée pour une première évaluation :

Cette liste n’est pas un rituel bureaucratique. Un dossier d’examen bien tenu est plus fiable que la mémoire lorsqu’on demande, six mois plus tard : « Pourquoi avions-nous autorisé cet accès ? » La mémoire humaine est étonnamment créative ; les logs le sont beaucoup moins.

Conclusion : la brochure exprime une intention, le comportement réseau constitue une preuve

Une organisation peut fixer des limites à l’utilisation de l’intelligence artificielle. Elle peut même fixer des limites très strictes. C’est un choix de gouvernance tout à fait légitime. Mais la traduction technique de cette limite ne doit pas être une extension de nom de domaine, une catégorie de produit ou un seul mot dans une brochure.

L’examen de l’équipe IT doit progresser sur trois niveaux :

Que contient le package ?
Manifeste, JavaScript, ressources externes et configurations.
Que fait le navigateur ?
Requêtes réseau, cibles et corps de données dans un parcours utilisateur réel.
Quelle est la signification pour l’organisation ?
RGPD, classification des données, points de terminaison autorisés, contrôle d’accès et impact opérationnel.

Un système qui possède une fonctionnalité d’IA et un système qui génère du trafic IA à chaque session ne sont pas la même chose. Un nom de domaine .ai n’est pas non plus la preuve d’un appel IA. La preuve est la requête qui vit sur le réseau, qui porte un horodatage et dont la cible ainsi que la charge utile sont visibles.

Pour les équipes IT, le réflexe le plus sûr ne doit pas être « tout bloquer », mais voir quelle porte s’ouvre réellement. Cette approche prend la sécurité plus au sérieux tout en évitant de laisser inutilement les processus de formation, de conformité et de SST dans l’obscurité.

Notes

SCORM 1.2, 2001. Modèle technique standard permettant la communication entre le contenu d’apprentissage et le LMS.
SCORM 2004, 2004. Norme SCORM étendue incluant notamment les règles de séquencement et de navigation.