Résumé

  • draft-smith-opsawg-ai-network-governance-01 précise que les contraintes communiquées au service d’IA ne remplacent jamais leur application indépendante par programme.
  • Une proposition conforme ne prouve ni la politique effectivement consultée, ni l’état du compteur, ni l’autorisation au moment de l’acte, ni le retour réel du service.

À 14 h 03, le prompt annonce qu’une interface est protégée. À 14 h 04, un opérateur recharge la configuration. À 14 h 05, le modèle propose une action apparemment autorisée. Le journal écrit : « garde-fou validé ».

Quelle version a décidé ?

La question paraît administrative jusqu’au jour où le changement touche un routeur. Elle devient alors la question d’autorité. Un résumé envoyé au modèle peut être exact au moment de la requête et déjà périmé au moment de l’exécution. Un verdict local peut être correct tout en restant impossible à rattacher au catalogue, à la liste d’autorisation et aux compteurs qui l’ont produit.

La révision 01 de draft-smith-opsawg-ai-network-governance, publiée le 27 septembre 2026, rend cette frontière visible. Il s’agit d’un Internet-Draft individuel actif. Il n’a ni flux RFC, ni statut formel dans le processus de normalisation, ni approbation de l’IETF. Son en-tête vise un document informatif. C’est une proposition structurée, pas une norme ni un rapport de déploiement.

Son périmètre exige quatre propriétés simultanées : un système placé sur un équipement ou ayant accès à son plan de gestion ; un service d’IA externe consulté pour analyser une anomalie et proposer une correction ; la capacité de modifier l’état sans validation humaine pour chaque action ; et une interface comme NETCONF, RESTCONF ou gNMI. L’IA purement consultative n’entre pas dans ce périmètre.

Le modèle distingue l’IA externe de l’agent autonome local. La première reçoit un contexte et propose. Le second collecte, détecte, contrôle et exécute. L’IA ne doit pas accéder directement à l’équipement. Cette séparation réduit une voie de risque, mais concentre le pouvoir dans l’agent local : c’est lui qui transforme une suggestion probabiliste en acte privilégié.

Deux objets encadrent ce pouvoir. L’Action Registry est un catalogue fixe, défini par le développeur, avec paramètres, niveau de risque et réversibilité. L’Operator Allow List sélectionne les actions admises dans un déploiement donné. Une proposition absente du catalogue est rejetée ; l’IA ne peut inventer un nouveau type d’action. Les paramètres restent soumis à des plages sûres, quel que soit le niveau de confiance annoncé.

Le projet demande aussi d’insérer dans chaque contexte envoyé à l’IA un résumé des actions permises et interdites, des cibles protégées, des limites de fréquence et du plafond de risque. Cette projection améliore l’efficacité : le modèle produit moins de suggestions vouées au rejet. Elle améliore aussi l’explication d’une escalade.

Mais le texte formule ensuite sa règle la plus importante : cette communication ne remplace pas l’application programmatique. Toute proposition doit être contrôlée indépendamment avant exécution. La défense doit intervenir au prompt, à l’analyse de la réponse, au garde-fou et de nouveau au point d’interaction avec l’équipement.

Cette dissociation interdit de prendre un prompt bien écrit pour une politique de sécurité. Elle exige aussi un reçu. Le journal d’une action devrait nommer l’instantané de politique approuvé par l’humain, les versions du registre et des listes, les règles de cible, les bornes de paramètres, le plafond de risque, l’état des compteurs, le niveau de dégradation, la révocation, la proposition, son interprétation, le verdict, le contrôle final, l’opération authentifiée, l’état antérieur et les observations suivantes.

Le simple hash du prompt ne suffit pas. Le prompt n’est qu’une projection destinée à un tiers. Il peut simplifier un motif de cible, omettre une information sensible ou présenter un budget valable quelques secondes plus tôt. La mention « autorisé » ne suffit pas davantage si elle ne révèle pas les données qui ont rendu le verdict vrai.

La dimension historique apparaît dans les limites proposées. Le projet fournit des valeurs par défaut et maximales pour le nombre d’actions par heure, d’actions par cible en vingt-quatre heures, d’actes irréversibles, de requêtes à l’IA et de tentatives. Cinq actions par heure, avec un maximum proposé de vingt, n’est pas une constante physique. Aucun élément gelé ne démontre que ces chiffres conviennent à toute topologie ou tout domaine de panne.

Surtout, « cinquième action de l’heure » est un fait d’histoire. Il suppose des événements complets, une horloge, une fenêtre définie et une continuité après redémarrage. Il en va de même pour le refroidissement, la révocation, les reprises et la dégradation.

La section 17.3 recommande des contrôles sans état lorsque c’est possible, mais calculés à partir d’une piste d’audit persistante plutôt que de mémoire volatile. Le principe est solide : un redémarrage ne doit pas remettre les compteurs à zéro. Il déplace toutefois l’autorité vers le journal et sa projection. Ordre, complétude, durée de conservation, activation de politique et convergence des répliques deviennent des propriétés de sûreté.

Les exemples d’échec sûr confirment cette lecture : si les données de fréquence sont inaccessibles, considérer la limite épuisée ; si la reconnaissance d’une cible protégée échoue, la considérer protégée ; si le catalogue est indisponible, considérer l’action absente. L’inconnu doit fermer le passage.

L’autre moitié du reçu concerne le monde physique. Le projet impose une capture de l’état antérieur, une télémétrie fraîche après l’action et un retour arrière si la situation ne s’améliore pas. Une donnée mise en cache ou masquée par un mécanisme anti-duplication ne peut prouver la reprise.

La capture ne garantit pourtant pas une restauration. Elle ne reconstitue pas un paquet perdu, une session cliente rompue, une file épuisée ou le temporisateur d’un pair distant. Le retour arrière est une nouvelle opération dans un système qui continue d’évoluer. Il lui faut son propre résultat, sa relecture et sa mesure de service.

La section consacrée à l’injection de prompt suit la même logique. Des journaux ou descriptions produits par l’équipement peuvent influencer l’IA. Nettoyer les chaînes aide ; la vraie barrière reste l’absence d’accès direct et la validation indépendante. Un test sérieux doit donc traverser analyseur, catalogue, cible, paramètres, historique, exécution et reprise, pas seulement observer que le modèle refuse une phrase hostile.

Le projet appelle la piste d’audit son principal mécanisme de responsabilité et recommande une protection d’intégrité, voire une conservation externe. C’est dans cette piste que doit vivre le reçu de politique par action. Le journal de configuration au démarrage ne suffit pas à expliquer un acte accompli après plusieurs rechargements.

Les auteurs déclarent que les concepts viennent d’une expérience opérationnelle sur des infrastructures de production. Cette phrase reste leur déclaration. Elle ne fournit ni étude indépendante, ni population, ni taux d’incident, ni résultat mesuré. Les seuils et les garde-fous doivent être testés localement.

La doctrine de spécification initiale minimale de Heng Lu suggère un noyau plus dur : l’IA n’élargit pas le vocabulaire d’action ; l’état politique inconnu échoue fermé ; l’agent ne réécrit pas ses règles ; chaque mutation nomme l’autorité exacte qui l’a admise. La distinction des couches de réalité rappelle qu’un verdict « autorisé » n’est pas l’état du réseau. La primauté du code en fonctionnement exige enfin la relecture et le service observé.

Sources