Résumé

  • L’essai accueilli par LACNIC distingue utilement l’exécution automatique de la décision autonome et recommande de commencer par un domaine et un processus. Le niveau obtenu doit donc rester attaché à ce périmètre.
  • Un registre de scénarios rendrait la déclaration contrôlable : objet, cinq dimensions humain-système, niveau minimal, méthode, preuves, effets par rapport à une référence, pouvoir d’intervention et date de réévaluation.

Une équipe automatise la détection d’une panne, son diagnostic et la préparation d’un correctif. Une personne approuve encore le changement. Une autre équipe automatise l’activation d’un service, décision comprise, mais collecte manuellement une partie de l’inventaire. Elles peuvent toutes deux annoncer le même niveau d’autonomie. Le public entend une équivalence ; l’exploitation voit deux dépendances différentes.

Le 9 septembre 2026, le blog de LACNIC a publié un texte de Hernán Arcidiacono, présenté comme directeur technique d’Iplan Argentina et membre du Comité de révision de l’IANA. La page précise que les opinions sont celles de l’auteur. Celui-ci pose d’emblée une distinction éclairante : l’automatisation donne la capacité d’exécuter, tandis que l’autonomie donne la capacité de décider. La première applique des règles à des événements prévus ; la seconde tient compte de son état, de ses intentions et de son environnement.

L’auteur refuse également de réduire le sujet au routeur. Le modèle du TM Forum couvre une couche de ressources, une couche de services et une couche métier. Il transforme donc le modèle d’exploitation de l’entreprise. Pourtant, la méthode proposée pour avancer est délibérément circonscrite : choisir un domaine autonome — accès ou IP, par exemple — puis un processus tel que la gestion des incidents, et progresser par étapes en maintenant d’abord l’humain dans la décision.

Ces limites ne sont pas seulement prudentes. Elles indiquent ce que l’on peut honnêtement mesurer. Une boucle réussie dans l’accès ne qualifie ni la facturation, ni le cœur, ni la sécurité, ni l’assistance. Le niveau est une propriété d’un travail observé, pas une décoration attachée à la raison sociale.

Une note sans objet n’a pas de sens stable

La fiche publique du TM Forum consacrée à IG1252 décrit une évaluation d’un réseau ou d’une partie de réseau, fondée sur des processus, sous-processus, tâches et critères. Elle ne commence pas par l’entreprise : elle commence par l’objet opérationnel.

La Recommandation ITU-T Y.3173 développe cette logique. Elle examine les workflows du cycle de vie et les sous-systèmes. Le niveau d’un réseau entier est le reflet combiné de ces éléments. Il ne peut atteindre un palier que si les workflows et sous-systèmes pertinents atteignent ou dépassent eux-mêmes ce palier. Or ces éléments varient selon le cas d’usage. Une infrastructure n’a donc pas nécessairement une seule réponse valable pour tous ses usages.

Y.3173 décompose l’évaluation en cinq dimensions :

  1. la traduction de la demande en instructions exploitables ;
  2. la collecte des données nécessaires ;
  3. l’analyse de l’état, y compris la prévision éventuelle ;
  4. la décision qui sélectionne une action ou une configuration ;
  5. la mise en œuvre de cette décision.

Pour chaque dimension, on identifie le rôle de l’humain, du système ou des deux. Le résultat du cas d’usage est limité par le niveau minimal obtenu dans les dimensions. Cette règle empêche le meilleur composant de prêter son prestige à l’ensemble. Un modèle brillant d’analyse ne rend pas autonome une décision humaine. Une exécution sans intervention ne compense pas une intention mal définie. Une collecte automatique ne prouve pas la qualité des données.

La Recommandation maintient en outre la prééminence des décisions et instructions humaines à tous les niveaux. Un L4 ne distribue donc pas automatiquement les responsabilités juridiques ou contractuelles. Il ne dit pas qui peut arrêter le système, accepter une exception ou supporter une perte. Ces pouvoirs doivent être décrits séparément.

La capacité ne garantit pas le bénéfice

Un deuxième glissement consiste à présenter un niveau plus élevé comme la preuve d’un meilleur service. ITU-T Y.3063, approuvée en décembre 2025, traite l’efficacité dans un cadre distinct. Elle relie quatre couches : objectifs de valeur, résultats de scénarios de bout en bout, métriques de capacité propres aux domaines et données des systèmes.

Cette architecture interdit le raccourci entre « davantage automatique » et « davantage utile ». Une proportion élevée de tâches automatiques peut coexister avec une disponibilité inchangée. Un traitement plus rapide peut déplacer le coût vers les exceptions. Une optimisation énergétique peut réduire la couverture. Une baisse des interventions manuelles peut compliquer l’explication d’une mauvaise action.

Y.3063 classe les objectifs selon l’expérience client, l’efficacité opérationnelle et l’efficacité des ressources. Ses indicateurs comprennent notamment le délai de livraison ou d’activation, la disponibilité, la durée d’interruption, le temps moyen de rétablissement, le déploiement, le taux d’automatisation, l’énergie et l’utilisation des ressources. Tous ne conviennent pas à tous les scénarios. Il faut déclarer la référence, la période et la relation entre données de domaine et résultat de bout en bout.

Son appendice pratique propose d’abord un inventaire des scénarios dans les domaines concernés. Il faut ensuite choisir les métriques, mesurer la contribution de chaque scénario, les classer et passer du pilote à l’échelle. Une entreprise ne choisit donc pas d’abord le niveau qu’elle souhaite afficher. Elle décrit le travail, mesure sa valeur, puis élargit ce qui a fait ses preuves.

Cette approche est particulièrement adaptée aux fournisseurs petits et moyens évoqués dans l’essai de LACNIC. Un ISP régional n’a pas besoin de reproduire un programme mondial. Il peut sélectionner un processus répétitif ou fragile, consigner la répartition actuelle entre personnes et systèmes, automatiser une partie, observer le résultat et ne généraliser qu’après vérification. Le registre rend comparables des démarches de tailles différentes sans les confondre.

Le contenu d’un registre de scénarios

Le registre proposé ici est une synthèse éditoriale, non une prescription attribuée à LACNIC, au TM Forum, à l’UIT ou à l’ETSI. Son utilité tient aux liaisons qu’il préserve.

La première liaison concerne le périmètre : opérateur, responsable, domaine ou partie de réseau, cas d’usage, workflow, déclencheur, période et version de méthode. « Gestion des pannes » doit être précisé : panne de cellule, incident de transport, dérive de configuration ou autre scénario.

La deuxième porte sur le vecteur de travail. Pour la demande, les données, l’analyse, la décision et l’exécution, le registre indique qui agit et quelle trace l’atteste : version d’intention, référence de jeu de données, modèle ou règle, décision, changement et contrôle du résultat. Le niveau synthétique est le minimum applicable, jamais une moyenne flatteuse, et reste accompagné de ses cinq composantes.

La troisième liaison unit capacité et résultat sans les fusionner. Le registre conserve la référence, l’indicateur, la fenêtre d’observation et la valeur constatée. Temps de rétablissement, disponibilité, réclamations et taux d’automatisation répondent à des questions différentes. Le projet ne doit pas pouvoir choisir rétrospectivement le seul chiffre favorable.

La quatrième décrit le contrôle : pouvoir humain d’intervention, rayon d’action, exceptions, responsable du retour arrière et vérification de l’état final. Une fonction de rollback dans la documentation n’est pas une preuve. L’épisode doit relier déclencheur, décision, action, effet et restauration.

La dernière liaison est temporelle. Modèle, intention, topologie, données, fournisseur, version logicielle ou permission peuvent changer. Le niveau doit expirer ou être réévalué à la suite d’une modification significative. Sans cette règle, une note obtenue par une ancienne architecture survit artificiellement.

Les agents multiplient les frontières

L’architecture ETSI GS ZSM 002 distingue la gestion interne à un domaine de la gestion de bout en bout. Plusieurs boucles peuvent agir à des granularités différentes et communiquer latéralement ou selon une hiérarchie. Le document ETSI GR ZSM 020 de janvier 2026 distingue, pour sa part, copilotes laissant la décision à l’humain, agents autonomes supervisés et agents entièrement autonomes. Les agents sont aussi classés par fonction et type d’action.

Dans son scénario de résolution inter-domaines, un agent détecte une panne locale, recherche des capacités, transmet le contexte à un coordinateur, forme une équipe et recueille le retour après résolution. L’ensemble peut être très sophistiqué tout en conservant une décision humaine décisive. À l’inverse, une boucle locale simple peut être fiable sans décrire le reste de l’opérateur.

Plus il existe d’agents, moins un badge global renseigne. Il faut savoir quelle capacité a été découverte, quel agent a reçu la tâche, quelle autorité a validé l’action et quel état final a été mesuré.

Un niveau est daté

Cinq promotions abusives transforment une mesure en réputation. La tâche la plus avancée représente la boucle ; la boucle représente le domaine ; le domaine représente l’entreprise ; la capacité représente l’effet ; enfin, l’ancienne évaluation représente un système modifié.

Le texte publié par LACNIC aide à éviter ces raccourcis parce qu’il part d’un domaine et d’un processus précis. Il serait paradoxal de convertir cette discipline en slogan général. La maturité peut rester lisible à condition que le niveau pointe toujours vers son scénario, ses dimensions, ses preuves et sa date.

L’autonomie n’a pas besoin d’un badge permanent. Elle a besoin d’une assertion que l’on peut refaire.

Sources