Résumé

  • L’ordre du jour IESG du 24 septembre inclut, au titre de la procédure RFC 5742, l’examen de conflit de draft-irtf-nmrg-ai-challenges-06, projet de recherche du NMRG destiné à la catégorie Informational.
  • La réponse -00 proposait « pas de conflit » avec une note sur l’IA attaquée et les sorties dangereuses. La version -01 du 24 septembre garde la conclusion proposée, mais retire cette note. Le dossier reste en « IESG Evaluation », avec un DISCUSS non résolu.
  • L’examen de conflit n’atteste ni la sécurité d’un outil, ni son déploiement. Les sections 9.2 et 9.3 du projet invitent à contrôler séparément l’intégrité des entrées et les effets des décisions.

Une machine de gestion peut se tromper pour deux raisons qui ne se ressemblent pas. Un attaquant peut fausser les données d’apprentissage et orienter la classification du trafic. Mais un système dont les données n’ont pas été manipulées peut aussi recommander un réglage incompatible avec la capacité physique d’un lien. Le premier cas exige une enquête sur la provenance et la résistance du modèle ; le second, une barrière indépendante devant la configuration proposée. Un certificat de bonne santé du modèle ne vaut pas autorisation de modifier le réseau.

C’est précisément au passage entre publication et utilisation que le dossier du NMRG mérite lecture. La version -00 de la réponse proposait « pas de conflit » et demandait de considérer une remarque de l’IRSG sur les sections 9.2 et 9.3. L’historique montre que Mohamed Boucadair approuvait la conclusion principale, mais contestait la demande de traiter les commentaires de l’IRSG dans cette procédure ; Tommy Jensen soutenait cette objection. La version -01, datée du 24 septembre, conserve la conclusion proposée tout en supprimant la note. Cette succession ne prouve pas à elle seule la motivation complète du changement, ni une décision finale : la page reste en évaluation avec un DISCUSS. La distinction technique reste dans le texte de recherche, non dans la réponse actuellement proposée.

Les exemples du projet expliquent pourquoi la nuance compte. La section 9.2 traite de l’empoisonnement des données, de l’évasion d’une classification et de l’inférence d’informations sur l’apprentissage : la cible est l’IA elle-même. La section 9.3 envisage des sorties qui compromettent une politique d’accès par modification des tables de filtrage ou promettent plus de bande passante que le support ne peut fournir. Dans ce second scénario, l’absence d’adversaire visible ne rend pas la décision acceptable. Les limites techniques et la procédure d’arrêt doivent exister en dehors du modèle.

RFC 5742 borne le rôle de l’IESG pour les textes venant de l’IRTF : vérifier les conflits avec les travaux IETF, non juger si une solution est bonne à déployer. Le projet est issu d’un groupe de recherche et vise une publication Informational, pas une norme Internet. Même si l’IESG retenait finalement « pas de conflit », cela ne validerait ni un produit, ni les protections décrites, ni une mise en service que les sources ne documentent pas.

Une fiche de décision à deux volets serait donc utile aux exploitants. Le premier volet garderait la trace des sources de données, des accès capables de les altérer et des essais face aux attaques contre le modèle. Le second décrirait les commandes autorisées, les seuils vérifiés hors du modèle, le déploiement progressif, les conditions d’arrêt et l’état restauré après retour arrière. Cette méthode est une proposition éditoriale de Daniel Kade, non une prescription de l’IESG ; elle prolonge l’attention du projet aux actions graduelles et au retour arrière.

Sources