L'IA souveraine pour les Télécommunications
Les opérateurs détiennent le réseau sur lequel repose la souveraineté de tous les autres, et les données d'abonnés que l'Europe protège le plus strictement. L'IA sur l'un ou l'autre doit rester chez l'opérateur. La plateforme est construite pour que ce soit possible.
Le réseau comme un graphe
Sites, éléments, liens et les services au-dessus, modélisés une fois. Les tempêtes d'alarmes se réduisent à l'élément qui les explique.
Les données d'abonnés restent à la maison
Les agents de service lisent les données de compte, de trafic et de localisation chez l'opérateur, sous des identités délimitées, et passent la main quand la politique le dit.
NIS2 avec des preuves
Incidents ouverts avec les services touchés identifiés, notifications rédigées à partir du dossier, relectures journalisées.
Un opérateur national voit des centaines de milliers d'alarmes par jour, sert des millions d'abonnés dont les données de trafic et de localisation ne peuvent pas quitter le pays, et est une entité essentielle au sens de NIS2 avec un régulateur qui attend des incidents déclarés et expliqués. L'IA peut raccourcir la résolution des pannes, traiter les cas clients courants et préparer le dossier NIS2, mais seulement si les données réseau et les données d'abonnés ne vont jamais vers un modèle tiers.
À lire si vous dirigez l'exploitation réseau, la relation client, la sécurité ou l'informatique d'un opérateur fixe, mobile ou de gros, ou répondez de ses obligations NIS2 et du droit des télécommunications.
Pour les opérateurs de télécommunications, Scrydon est la plateforme souveraine d'IA et de données qui modélise le réseau et ses services en un seul graphe, y corrèle les alarmes et y prédit les pannes, fait tourner des agents orientés abonnés à l'intérieur de l'infrastructure de l'opérateur, et produit les dossiers d'incident et d'audit que NIS2 exige.
Elle tourne sur l'infrastructure de l'opérateur, dans un cloud souverain national ou déconnectée pour les segments de réseau les plus sensibles, avec des modèles open-weight servis localement, si bien qu'aucune alarme, aucune topologie et aucun dossier d'abonné n'est jamais envoyé à l'extérieur.
Trop d'alarmes, trop peu de corrélation, et des données qui ne peuvent pas voyager
Un centre d'exploitation réseau est un exercice de triage. Des centaines de milliers d'alarmes par jour arrivent de la radio, du transport, du cœur et de l'accès fixe, et quand une fibre est coupée, chaque service qui l'emprunte lève la sienne. Le travail de l'ingénieur est de trouver la seule défaillance qui explique le mur rouge, et la vitesse à laquelle cela arrive dépend de qui est de garde. Les clients s'en aperçoivent généralement en premier.
De l'autre côté de l'entreprise, le centre de contact résout des cas de facturation, d'activation et de panne qui exigent qu'un conseiller lise les données de compte, de trafic et parfois de localisation d'un abonné, que les règles ePrivacy et le droit national des télécommunications protègent plus strictement que les données personnelles ordinaires. Les deux problèmes sont naturels pour l'IA, et les deux sont fermés à tout service d'IA qui sortirait les données de l'opérateur. Ajoutez les obligations d'entité essentielle de NIS2, et un réseau multi-fournisseurs qui exclut d'attacher la couche IA à un seul équipementier, et les exigences de la plateforme sont posées.
Avalanches d'alarmes — Une coupure de fibre lève une alarme pour chaque service qui l'emprunte. Trouver la cause dépend de qui est de garde.
Des cas clients qui exigent des données protégées — Résoudre un cas de facturation ou de panne, c'est lire des données qu'ePrivacy et le droit national protègent plus que les données personnelles ordinaires.
Obligations d'entité essentielle — Délais NIS2, règles de sécurité des réseaux et traitement des réquisitions exigent tous un dossier qui s'explique de lui-même.
Neutralité vis-à-vis des équipementiers, par nécessité — Des réseaux multi-fournisseurs et un mandat d'autonomie stratégique excluent d'attacher la couche IA à un seul fournisseur étranger.
Un seul modèle du réseau et du client, et des agents qui travaillent sur les deux
La plateforme modélise le réseau comme un graphe de sites, d'éléments, de liens et des services qui les empruntent, cartographié depuis l'inventaire et les systèmes de support d'exploitation, et elle modélise le client sur le même graphe depuis les systèmes de support d'affaires. Alarmes et compteurs de performance se déposent sur ce modèle en temps réel, si bien que la corrélation devient un parcours de graphe : les alarmes sont regroupées sous l'élément dont la défaillance les explique, avec les services et les clients touchés à côté. Des modèles entraînés sur l'historique propre de l'opérateur signalent les liens et les cellules dont les compteurs ressemblent aux jours précédant des pannes passées.
Côté client, des agents de service lisent les dossiers d'abonnés dans le périmètre, raisonnent sur le même modèle et agissent via les systèmes de facturation et de provisionnement existants sous une identité limitée à ce client et à ce dossier. Une demande hors politique est routée vers une personne avec le contexte joint. Quand un événement devient un incident NIS2, le dossier est déjà là : les services touchés issus du modèle du réseau, les preuves issues des alarmes, et une alerte précoce rédigée qu'une personne désignée relit.
- 1
Modéliser
Une ontologie des sites, éléments, liens, services, produits et abonnés, cartographiée depuis l'inventaire, l'OSS et le BSS.
- 2
Fusionner
Alarmes, compteurs de performance, tickets et changements se déposent sur le modèle en temps réel ; un élément défaillant liste les services et les clients qu'il touche.
- 3
Prédire et résoudre
Des modèles entraînés sur votre propre historique signalent les liens qui se dégradent ; des agents de service résolvent les cas courants via le BSS existant.
- 4
Déclarer
L'alerte précoce et la notification NIS2 sont rédigées à partir du dossier d'incident, relues par une personne désignée et envoyées.
L'opérateur est le périmètre
Pour un opérateur de télécommunications, le périmètre, c'est l'opérateur lui-même. Topologie, données de performance et dossiers d'abonnés décrivent soit une infrastructure critique, soit des données personnelles protégées, et un mandat d'autonomie stratégique exclut un fournisseur étranger dans la boucle. La plateforme tourne sur l'infrastructure de l'opérateur, dans un cloud souverain national ou déconnectée pour les segments qui l'exigent, avec des modèles open-weight servis localement.
Les agents portent des identités délimitées : un agent de service est limité à un client et un dossier, un agent réseau à la lecture de la télémesure plutôt qu'à l'écriture de configuration, et chaque lecture comme chaque modification est attribuée et journalisée. Cette attribution est ce qu'un régulateur, un auditeur des réquisitions ou un client demandera à voir, et c'est ce que l'observabilité et la gouvernance de la plateforme produisent naturellement.
Tourne là où est le réseau — Sur l'infrastructure de l'opérateur, dans un cloud souverain national, ou déconnectée pour les segments qui l'exigent.
Modèles open-weight servis localement — Aucun dossier d'abonné ni détail de topologie ne part dans un prompt. Le choix du modèle reste à l'opérateur.
Identité d'agent délimitée — Un agent de service est limité à un client et un dossier ; un agent réseau à la lecture de la télémesure, pas à l'écriture de configuration.
Attribution et audit — Chaque lecture et chaque modification par un agent est attribuée et journalisée, ce qu'un régulateur ou un client demandera à voir.
Gardez un œil sur ce sujet
Ce qui change pour votre secteur en matière de souveraineté numérique européenne, et ce que nous apprenons sur le terrain. Quelques fois par an, sans séquence automatisée.
Cas d'usage pour les télécommunications
L'exploitation réseau et la relation client sur une seule plateforme souveraine.
Découpage de réseau 5G
Télécommunications
Enjeu
L'allocation dynamique de bande passante entre les services d'urgence et le streaming grand public pendant une crise est manuelle et lente.
Solution
Des agents embarqués dans le réseau priorisent automatiquement le trafic de communication critique pendant les urgences déclarées, en appliquant les politiques de QoS au niveau du paquet.
En savoir plus
Une communication ininterrompue pour les premiers intervenants lors des événements à forte charge.
Socle de données capteurs et OT prêt pour l'IA
Ingénierie des données
Enjeu
Les opérateurs de réseaux électriques, d'eau et de transport disposent d'années d'historique SCADA et capteurs, mais celui-ci est trop fragmenté et mal étiqueté pour que les modèles IA l'exploitent de façon fiable.
Solution
Un pipeline de données prêtes pour l'IA nettoie, contextualise et ancre les données OT et capteurs dans l'ontologie avant qu'elles n'atteignent le moindre modèle : les agents raisonnent ainsi sur des données fiables et bien décrites plutôt que sur une soupe de tags bruts.
En savoir plus
Les modèles prédictifs et les agents atteignent plus vite la maturité de production, bâtis sur un socle de données auquel les opérateurs peuvent réellement se fier.
Identité d'agent cadrée pour les systèmes OT
Sécurité & contrôle d'accès
Enjeu
Donner à un agent IA l'accès aux systèmes SCADA ou historians est à haut risque lorsque tous les agents partagent un unique compte de service très large au lieu de disposer chacun de sa propre identité cadrée.
Solution
Chaque agent s'authentifie sous sa propre identité fédérée avec des permissions au moindre privilège et limitées dans le temps : un agent qui lit la télémétrie des capteurs ne peut jamais aussi écrire des consignes de commande, sauf autorisation explicite.
En savoir plus
Les agents opèrent en toute sécurité aux côtés des systèmes OT avec un modèle de permissions entièrement attribuable, éliminant une classe majeure de risque lié à l'IA agentique dans les environnements opérationnels.
Coordination humain-agent de la réponse aux pannes
Réponse aux incidents
Enjeu
Une réponse à une panne mobilise plusieurs équipes et traverse des changements d'équipe, et chaque passage de relais entre le triage d'un agent et la décision d'un opérateur repart de zéro, coûtant des minutes qui comptent pendant un incident en cours.
Solution
L'AI OS conduit la réponse aux pannes comme un processus coordonné unique : les agents trient la télémétrie et préparent les actions de réponse, les opérateurs approuvent ou passent outre à des points de contrôle définis, et l'état complet de l'incident se propage automatiquement d'une équipe à l'autre.
En savoir plus
Une réponse aux pannes plus rapide et mieux coordonnée, avec un enregistrement d'incident unique et continu au lieu de relais fragmentés entre équipes et vacations.
Modèle de moyens et de réseau basé sur l'ontologie
Gestion des actifs
Enjeu
Un même poste électrique ou tronçon de pipeline est représenté différemment dans le SIG, le système de gestion des actifs et l'historian SCADA : répondre à « que savons-nous de cet actif » suppose de recouper manuellement des systèmes qui n'ont jamais été conçus pour concorder.
Solution
Une ontologie modélise chaque actif et chaque connexion réseau comme une entité unique, mappée depuis les données SIG, EAM et historian : agents et opérateurs raisonnent ainsi sur un modèle d'actifs unique et cohérent.
En savoir plus
Un modèle d'actifs et de réseau unifié et interrogeable, qui remplace le recoupement manuel entre systèmes déconnectés.
Détection d'incidents NIS2 et notification sous 24 heures
Opérations de sécurité
Enjeu
NIS2 accorde aux entités essentielles 24 heures pour envoyer une alerte précoce et 72 heures pour déposer une notification d'incident, mais les preuves sont dispersées entre les alertes du SIEM, les alarmes OT, la gestion des tickets et les journaux de changements. La première journée passe à les rassembler à la main.
Solution
Des agents corrèlent les signaux de sécurité et d'exploitation avec un modèle des services et des actifs de l'opérateur, ouvrent l'incident avec les services touchés déjà identifiés, et rédigent l'alerte précoce et la notification à partir du dossier, pour relecture et envoi par une personne.
En savoir plus
Le compte à rebours de 24 heures démarre avec un projet en main plutôt qu'un gabarit vide, et chaque notification est traçable jusqu'aux événements qui la fondent.
À quoi Télécommunications doit se conformer
Les réglementations qui décident si l'IA peut seulement tourner sur ces données. Chaque page indique ce que le cadre exige et quels contrôles de la plateforme y répondent : des propriétés et des refus, pas une checklist.
NIS2 · Directive NIS2
S'applique à: Les entités essentielles et importantes des secteurs critiques — énergie, transports, eau, santé, infrastructure numérique, administration publique, industrie manufacturière et d'autres — ainsi que leurs chaînes d'approvisionnement.
Comment la plateforme le prend en chargeRGPD · Règlement général sur la protection des données
S'applique à: Toute organisation qui traite les données à caractère personnel de personnes situées dans l'UE/EEE, qu'elle soit établie dans l'Union ou qu'elle propose depuis l'extérieur des biens ou des services, ou suive leur comportement.
Comment la plateforme le prend en chargeCRA · Règlement sur la cyberrésilience
S'applique à: Fabricants, importateurs et distributeurs de produits comportant des éléments numériques — matériels et logiciels — mis sur le marché de l'UE, y compris les éditeurs de logiciels et les organisations qui bâtissent des produits connectés par-dessus.
Comment la plateforme le prend en chargerèglement IA · Règlement européen sur l'intelligence artificielle
S'applique à: Les fournisseurs, déployeurs, importateurs et distributeurs qui mettent des systèmes d'IA sur le marché de l'UE, ou dont les résultats produits par l'IA sont utilisés dans l'UE.
Comment la plateforme le prend en charge
Ce sur quoi reposent réellement ces résultats
Un architecte télécom demande comment le réseau est modélisé, comment les agents sont délimités et observés, et où tourne la plateforme. Ces pages répondent à ces questions.
Fondations souveraines
La fondation zero-trust sur laquelle repose toute la plateforme — la même pile, du réseau isolé au cloud.
AI OS
Le runtime qui décompose un processus en étapes, confie chaque étape à un système, un agent ou une personne, et lui donne le contexte nécessaire pour agir.
Plateforme de données basée sur l'ontologie
La couche sémantique qui transforme des tables en entités dont votre métier parle vraiment.
Observabilité de l'IA
Supervision, traçage et évaluation des agents et des workflows IA, pour rendre les défaillances diagnosticables.
Identité
Identité fédérée et accès zero-trust — pour les personnes comme pour les agents, sous la même politique.
On-Premise
La plateforme dans votre propre centre de données, sur votre propre matériel.
Questions fréquentes
Comment la plateforme réduit-elle le bruit d'alarmes au centre d'exploitation réseau ?+
Des agents IA peuvent-ils traiter les cas clients sans que les données d'abonnés quittent l'opérateur ?+
Comment cela soutient-il NIS2 pour un opérateur de télécommunications ?+
Nous exploitons un réseau multi-fournisseurs. La plateforme est-elle liée aux équipements ou au cloud d'un fournisseur ?+
Les segments de réseau les plus sensibles peuvent-ils rester déconnectés ?+
En quoi est-ce différent des fonctions d'IA que nos équipementiers vendent déjà ?+
Êtes-vous partenaires sur des appels d'offres et des accords-cadres ?+
Vous préférez écrire ? Envoyez un e-mail à hello [at] scrydon.com et nous vous répondrons.
Poursuivre
Trois pistes à partir d'ici : les règles auxquelles vous serez mesuré, la plateforme sur laquelle ces résultats tournent, et les sessions où nous les parcourons.
Les règles applicables
Chaque réglementation, ce qu'elle exige, et les contrôles que la plateforme fournit.
La plateforme derrière
L'AI Operating System, Analytics et Sovereign Foundations, page par page.
Tous les cas d'usage
Tous au même endroit, regroupés par le secteur qui les connaît le mieux.
How – Inside the AI OS: running governed agents on your own cluster, live(en anglais)
17 sept. 2026, 09:00
Part 2 of the Sovereign AI series, for engineers and architects. No slides after minute five: an agent gets an identity and scoped permissions, calls tools over governed MCP, retrieves from the ontology rather than raw tables, runs inside the sandbox and is stopped when it steps outside policy, and everything lands in the audit trail — then the same stack brought up on a disconnected network. Properties and refusals, shown rather than claimed.
Les autres volets de Infrastructures critiques
Les autres pages dédiées sous Infrastructures critiques, et la vue d'ensemble du secteur dont elles dépendent.
Énergie et eau
Gestionnaires d'électricité, d'eau et de gaz : prévision au niveau du départ, notification d'incidents NIS2 et données OT qui restent dans le périmètre.
Lire la pageTransports
Rail, ports, aéroports, routes et transports publics : un seul modèle du réseau, maintenance prédictive, optimisation des flux et gestion d'incidents sur des données OT qui restent chez l'exploitant.
Lire la page
Partenaires
