Résumé

  • La RFC 9315 définit l’intention comme un ensemble déclaratif d’objectifs et de résultats souhaités, sans imposer la manière de les produire. L’acceptation de la demande, sa traduction et l’accusé de réception des équipements ne constituent donc pas une preuve de résultat.
  • Un système crédible doit conserver séparément l’intention validée et l’état opérationnel observé. L’assurance les compare dans le temps, mesure la dérive, montre les limites de la preuve et choisit entre correction autorisée, retour à un état sûr et nouvelle décision humaine.

Analyse

Une case verte peut décrire le passé

Imaginons un cas de mécanisme, et non un incident documenté. Une personne habilitée demande qu’un service conserve une protection de chemin. Le système précise la demande, la juge cohérente, choisit des actions et les fait appliquer. Tous les composants répondent favorablement. Plus tard, un changement retire le chemin alternatif. La demande initiale n’a pas bougé ; la propriété recherchée, elle, n’existe plus.

Une interface peut continuer d’afficher le succès de la première opération. Elle dit alors quelque chose de vrai mais d’insuffisant : l’intention a été reçue ou une configuration a été acceptée. Elle ne dit rien de décisif sur le trafic actuel. Pour le savoir, il faut vérifier le chemin, le temps d’observation, les conditions de panne et l’étendue réelle de la mesure.

Cette différence organise la RFC 9315. L’intention décrit ce que le réseau doit accomplir, pas comment le faire. Le document sépare ensuite deux familles de fonctions. La réalisation conduit l’intention vers des actions. L’assurance observe si le comportement obtenu respecte encore le résultat demandé.

Le statut du texte impose de la prudence. Publié en octobre 2022, il s’agit d’un document informatif de l’Internet Research Task Force, issu du consensus du Network Management Research Group. Ce n’est pas une spécification de l’Internet Standards Track. Il clarifie des concepts et un programme de recherche ; il ne certifie ni produit ni déploiement.

Alexander Clemm, Laurent Ciavaglia, Lisandro Zambenedetti Granville et Jeff Tantsura en sont les quatre auteurs. Le profil Datatracker de Jeff Tantsura atteste cette participation publique. Il ne l’établit ni comme inventeur unique, ni comme exploitant des systèmes décrits, ni comme responsable d’un résultat commercial.

Le mot « intention » ne doit pas absorber tous les autres

Une grande part du travail conceptuel consiste à distinguer quatre objets. Un modèle de service représente un service et ses paramètres. Une politique énonce des règles de comportement. Une configuration fixe un état concret sur un composant. Une intention exprime un résultat souhaité sans détailler le procédé.

Ces objets ne donnent pas le même pouvoir à ceux qui les manipulent. Le responsable d’un service peut être habilité à demander une disponibilité protégée sans connaître chaque commande d’interface. Le moteur de règles peut choisir une action dans un périmètre donné sans être autorisé à changer la finalité. L’équipement peut exécuter une commande sans connaître la promesse faite au client.

Les réunir sous une seule étiquette efface les étapes où le sens peut se perdre. Une API de haut niveau peut être pratique sans gérer le cycle complet d’une intention. Une orchestration peut réussir techniquement sans produire le comportement attendu. Un objet de service peut demeurer présent alors que la qualité qu’il devait garantir s’est dégradée.

La RFC parle d’« intent-washing » lorsque le vocabulaire de l’intention sert à repeindre des fonctions antérieures. La faute n’est pas seulement marketing. Elle fait croire qu’une abstraction a acquis une preuve, une capacité de correction ou un mandat qu’elle ne possède pas. Le nom de l’interface ne remplace pas la chaîne entre choix, action et observation.

La vérité souhaitée et la vérité observée

La Single Source of Truth, ou SSoT, désigne dans la RFC l’ensemble des expressions d’intention validées. Elle répond à une question précise : quel état le système a-t-il accepté comme souhaité ? Elle ne répond pas automatiquement à l’autre question : que fait le réseau à cet instant ?

Les données opérationnelles demeurent donc à côté de la SSoT. La comparaison entre les deux permet de détecter la dérive. Si l’enregistrement du souhait était aussi la preuve de sa réalisation, aucune dérive ne pourrait être visible : le système certifierait sa propre affirmation par définition.

La provenance de l’intention devient essentielle. Qui l’a formulée ? Avec quelle habilitation ? Sur quels services, domaines et périodes porte-t-elle ? Quelles contraintes ont été explicitées ? Quelle ambiguïté a été levée, et quel conflit a exigé un arbitrage ? La réponse doit rester versionnée, attribuable, modifiable et révocable.

La provenance de l’observation est différente. Un échantillon de latence ne vaut que pour un lieu, un chemin et une fenêtre temporelle. Un état d’équipement peut être frais mais insuffisant pour conclure au niveau du service. Une appréciation d’assurance devrait donc indiquer le prédicat testé, les données manquantes, la couverture et le degré de confiance.

Sofia Ren applique ici la discipline du code en fonctionnement de Heng Lu comme grille d’analyse. Running-Code Betrayal et son plaidoyer public pour la réalité plutôt que la défense d’une cause conduisent à un critère étroit : une déclaration oriente l’action, mais ne remplace pas l’observation. Ce rapprochement relève de Ren ; il ne prétend pas révéler l’intention privée des auteurs de la RFC.

Un seul geste ne signifie pas une seule tentative

La promesse d’un système piloté par intention tient souvent en deux mots : « one touch ». La RFC ajoute aussitôt la réserve importante : pas « one shot ». Une demande initiale peut contenir des termes imprécis, des paramètres inconnus ou des objectifs incompatibles. L’échange avec l’utilisateur doit pouvoir les faire apparaître.

Prenons deux exigences : maximiser l’utilisation et préserver une protection indépendante. Lorsque la capacité manque, le système peut calculer plusieurs compromis. Il ne peut pas déduire de la topologie quelle perte l’organisation accepte légalement ou commercialement. La décision change la distribution du risque ; elle appartient à un acteur habilité.

L’historique de clarification devrait montrer ce que l’utilisateur a dit, ce que le système a inféré et ce qui a été confirmé. Il devrait conserver les alternatives refusées ainsi que leurs conséquences. Une conversation en langage naturel rend l’accès plus simple ; elle ne transforme pas le silence en consentement.

Cette étape protège également contre les conflits entre intentions. Deux équipes peuvent demander des résultats individuellement raisonnables mais impossibles à réunir. Un système qui résout l’opposition en silence acquiert une fonction de priorisation. Il lui faut soit une règle autorisée et visible, soit un retour vers ceux qui portent la décision.

La réalisation contient trois passages fragiles

La RFC présente l’ingestion, la traduction et l’orchestration comme les composantes de la réalisation. L’ingestion reconnaît et affine le résultat voulu. La traduction détermine des lignes d’action. L’orchestration coordonne leur exécution dans les systèmes de gestion et les équipements.

La traduction est une décision, même lorsqu’un algorithme l’effectue. Plusieurs chemins peuvent satisfaire la même demande. Le choix dépend d’une topologie, de ressources, de dépendances et d’hypothèses qui vieillissent. Pour être contestable, il doit laisser une trace reliant la version de l’intention aux données utilisées et à l’alternative retenue.

L’orchestration ne forme pas nécessairement une opération atomique. Un domaine peut accepter le changement tandis qu’un autre le refuse. Une commande peut être installée alors que le service dépendant n’est pas prêt. Le reçu d’un équipement prouve l’acceptation d’une action ; il ne prouve ni la cohérence globale ni l’effet sur les paquets.

Un dossier exploitable relie donc la demande validée, son interprétation, les hypothèses, les objets visés, l’ordre des actions et les échecs partiels. L’utilisateur n’a pas besoin de lire chaque réglage. Un auditeur habilité doit néanmoins pouvoir reconstruire pourquoi le système pensait que cette suite d’actions produirait le résultat.

L’automatisation agrandit aussi le rayon d’une mauvaise interprétation. L’abstraction réduit le travail manuel, mais permet de diffuser très vite une erreur de sens. La RFC demande des garde-fous, des points de contrôle et des moyens de contenir l’amplification. Plus le geste est haut placé, plus sa propagation doit être bornée.

L’assurance apporte la contradiction nécessaire

L’assurance commence par observer le réseau : événements, mesures de service, performances et télémétrie. Elle compare ensuite le comportement obtenu au comportement attendu. Ce n’est qu’à ce stade qu’une action de réalisation peut être jugée sur son effet.

Le mot « continu » ne doit pas masquer les angles morts. Toute mesure a un intervalle, un délai et une couverture. Un statut de conformité devrait expirer avec ses preuves ou afficher leur ancienneté. Sans fenêtre, sans périmètre et sans prédicat, la couleur verte devient un élément graphique plutôt qu’une conclusion technique.

La dérive peut survenir après une réussite initiale. Un changement de contrôle, une panne de ressource, une intervention locale ou une nouvelle intention modifie le comportement. L’enregistrement utile indique le premier moment observé, la gravité, les services exposés et la confiance disponible avant toute correction.

Corriger n’est pas un droit illimité. Restaurer un chemin dans une enveloppe déjà autorisée peut relever de la boucle automatique. Acheter de la capacité, relâcher une contrainte géographique, réduire un niveau de chiffrement ou sacrifier un autre service exige une nouvelle décision. L’assurance doit savoir s’arrêter lorsqu’une correction change le contrat initial.

Deux boucles empêchent l’autonomie de devenir souveraineté

Le schéma de la RFC comporte une boucle intérieure et une boucle extérieure. La première observe, évalue et ajuste sans solliciter un humain à chaque étape. La seconde rapporte les effets et les compromis à l’utilisateur, qui peut préciser, modifier ou retirer l’intention.

La boucle intérieure détient une autorité d’exécution bornée. Elle a besoin d’éléments suffisants pour savoir si son action a fonctionné. La boucle extérieure garde la décision que l’ingénierie ne peut trancher : faut-il changer l’objectif, le risque accepté ou la priorité entre deux groupes ?

Le retrait fait partie du cycle de vie. Un objectif naît, évolue puis peut cesser. Si le système sait accepter une instruction puissante mais ne sait pas en arrêter proprement l’application, une demande temporaire devient une règle permanente. L’identité du propriétaire, la version, la date d’effet et la révocation sont alors des propriétés opérationnelles.

La mission de l’IETF, RFC 3935, apporte une limite voisine : l’ingénierie se confronte à l’adoption volontaire et au code en fonctionnement. La RFC 9315 relève de l’IRTF, mais la prudence épistémique demeure. Publier une architecture de pensée permet d’organiser l’épreuve ; cela n’en annonce pas le résultat.