Résumé
- La keynote d’Amajit Gupta à APNIC 62 propose une « grille autonome » fondée sur la télémétrie en temps réel, le contrôle des chemins et l’autocorrection, tout en conservant des garde-fous définis par des humains.
- La présentation de Yukako Uchida, de JPCERT/CC, décrit une autre condition de fonctionnement : les équipes de réponse ont besoin d’une confiance construite par des échanges répétés avant de pouvoir coordonner leurs actions sous pression.
Une route réseau dégradée peut exiger une réaction en quelques millisecondes. La première conversation fiable entre deux équipes de réponse à incident a peut-être commencé des années plus tôt. APNIC 62 a placé ces deux temporalités dans la même session de keynote, sans les confondre ni proposer une règle opérationnelle commune.
Amajit Gupta, directeur général et PDG de Lightstorm, a présenté la latence comme la ressource devenue rare pour des charges de travail réparties entre nuages, centres de données et systèmes en périphérie. Son exposé du 8 septembre, intitulé « The Autonomous Grid », décrit quatre capacités : télémétrie en temps réel, orchestration fondée sur l’intention, contrôle programmable des chemins et architectures résilientes capables de s’autocorriger. Il plaide pour des opérations qui réagissent aux conditions plutôt que d’attendre une intervention manuelle.
Son support reconnaît aussi le travail nécessaire : adapter les infrastructures anciennes, les procédures et les compétences des équipes.
Gupta n’a pas présenté de déploiement mesuré ni de gain de performance vérifié. Il expose une proposition sur la façon dont les réseaux pourraient fonctionner. L’automatisation ne rend pas le jugement humain superflu : il préconise des boucles de contrôle encadrées par des garde-fous définis par les humains et laisse aux ingénieurs l’architecture, la planification de la résilience, la gouvernance et le contrôle. Cette limite est essentielle. Un système qui détecte une dégradation et modifie un chemin n’est pas automatiquement autorisé à changer le service d’une autre organisation ou à lui transmettre des informations sensibles.
Yukako Uchida, responsable de la division de coordination mondiale de JPCERT/CC, a parlé du travail humain derrière la coopération en cybersécurité. Sa présentation indique que JPCERT/CC a traité environ 20 000 incidents en 2025. Elle recense également des contacts de signalement dans 102 économies et des notifications envoyées dans 167 économies sur vingt ans ; la note de la diapositive limite ces chiffres aux ccTLD avec lesquels l’équipe a interagi pour la réponse aux incidents. Ces nombres décrivent l’échelle de coordination, pas une hausse des attaques ni le taux de réussite des réponses.
Le propos d’Uchida n’est pas que les règles formelles ou les outils techniques seraient inutiles. Ses diapositives soulignent que les équipes doivent pouvoir compter sur un interlocuteur qui traitera l’information partagée de façon responsable et agira correctement. Cette assurance se construit par l’expérience directe et des interactions répétées. Les communautés et les exercices facilitent ces contacts, mais une présence à une conférence ne prouve pas qu’une personne peut engager son organisation par une décision contraignante.
Les deux interventions se rejoignent ici. La télémétrie peut signaler une dégradation ; l’orchestration peut choisir un itinéraire de remplacement. Un signalement d’incident peut malgré tout exiger qu’une personne décide ce qui peut être partagé, si l’émetteur est digne de confiance et quelle organisation peut autoriser une mesure de confinement. Ce sont deux surfaces de contrôle différentes. La première reste dans le réseau configuré par un opérateur ; la seconde traverse des frontières institutionnelles.
Une automatisation plus rapide réduit le délai disponible pour la seconde décision, mais ne fournit à elle seule ni mandat ni relation de confiance.
Le compte rendu d’APNIC rapproche les deux exposés autour de l’innovation technique et de communautés plus solides. C’est une mise en perspective, pas la preuve d’une proposition commune, d’un pilote ou d’un réseau autonome déjà déployé. Le test pratique consiste à demander aux opérateurs d’expliquer ce qu’un système peut faire seul, ce qu’il doit escalader, comment il consigne une action et comment il annule un changement erroné au-delà du réseau local. Les publications d’APNIC ne montrent pas que ces garde-fous sont déjà appliqués partout.
L’enjeu est donc précis : un réseau peut réagir plus vite qu’un ingénieur ne lit une alerte, tandis qu’une équipe d’intervention doit parfois établir la confiance avant d’agir sur le signalement d’un tiers. Assimiler ces deux tâches brouillerait la responsabilité. Les traiter comme des processus distincts mais reliés rend le passage visible : la vitesse des machines dans une frontière de contrôle, et une autorisation humaine vérifiable lorsque l’action d’une organisation touche une autre.
Sources : le compte rendu des keynotes d’APNIC ; la présentation d’Amajit Gupta sur la grille autonome ; la présentation de Yukako Uchida sur la coopération en cybersécurité.
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance

