+150 XP

Faire tourner un operating model de data governance en télécoms

À 2h47 du matin, un analyste fraude chez un opérateur tier-1 reçoit une alerte automatique : une réquisition judiciaire porte sur les données de localisation en temps réel d'un abonné, mais la demande ne comporte pas de numéro de dossier. L'équipe réseau peut techniquement extraire la donnée en moins d'une minute. Le juridique estime que la demande ne satisfait pas le standard de conservation et de communication. L'IT détient le pipeline qui exécuterait la requête. Personne dans la pièce ne peut dire avec certitude qui a l'autorité de refuser. C'est ce vide, pas la technologie, qu'un operating model de data governance existe pour combler.

Pourquoi les télécoms sont un cas particulier en data governance

Les opérateurs télécoms détiennent certaines des données personnelles les plus sensibles de toutes les industries : les call detail records (CDR, les journaux indiquant qui a appelé qui, quand et pendant combien de temps), les données de localisation en temps réel et historiques issues de la triangulation des antennes, et de plus en plus des données comportementales provenant des applications et des objets IoT (Internet of Things) qui circulent sur leurs réseaux.

Cette donnée est précieuse pour trois populations très différentes à la fois :

  • Les opérations réseau, qui en ont besoin pour la planification de capacité et la détection de fraude.
  • Le marketing et l'analytics, qui la veulent pour la prédiction du churn et les offres ciblées.
  • Les autorités judiciaires et les régulateurs, qui peuvent en imposer l'accès dans le cadre des régimes d'interception légale.

Chaque population a une revendication légitime. Chacune crée aussi un risque de mésusage distinct. La governance est la structure qui décide, à l'avance, qui a le droit de dire oui.

La colonne vertébrale réglementaire : ce qui encadre la donnée télécom

Trois régimes réglementaires comptent le plus pour la planification 2026 :

Le RGPD (Règlement général sur la protection des données), appliqué par les autorités nationales de protection des données (DPA) dans toute l'UE, traite la donnée de localisation comme une donnée personnelle nécessitant une base légale de traitement (consentement, contrat ou intérêt légitime). La directive ePrivacy, parfois appelée « loi cookies », couvre spécifiquement les données de trafic et de localisation générées par les communications électroniques et exige en général le consentement ou l'anonymisation avant tout usage dépassant la facturation.

Aux États-Unis, la Federal Communications Commission (FCC) applique la Section 222 du Communications Act, qui classe les données de localisation et d'appel comme Customer Proprietary Network Information (CPNI) et restreint leur usage et leur partage. La FCC a infligé ces dernières années des amendes significatives à des opérateurs pour avoir vendu des données de localisation à des agrégateurs tiers sans consentement ; la page d'enforcement CPNI de la FCC est une source primaire utile pour suivre ces actions.

CALEA (Communications Assistance for Law Enforcement Act) aux États-Unis et les cadres d'interception légale équivalents dans l'UE (transposés pays par pays) obligent légalement les opérateurs à construire une capacité d'interception pour les réquisitions autorisées, ce qui crée une tension permanente : la même infrastructure qui permet la conformité constitue un risque de mésusage si les contrôles d'accès sont faibles.

Concevoir le conseil de governance

Un conseil de data governance télécom crédible n'est pas une case à cocher de conformité. C'est une instance permanente dotée d'un véritable droit de veto, structurée typiquement autour de trois sièges :

Réseau/Ingénierie. Détient la donnée au point de génération (antennes, éléments du réseau cœur). Ils comprennent la faisabilité technique : ce qui peut réellement être journalisé, anonymisé ou purgé.

IT/Plateforme data. Détient les pipelines, les entrepôts et les couches d'accès. Ils répondent de qui peut *techniquement* interroger quoi, et de la journalisation de chaque accès.

Juridique/Privacy (souvent rattaché à un Data Protection Officer, ou DPO, un rôle que le RGPD impose aux organisations traitant de gros volumes de données sensibles). Détient l'interprétation de la base légale et des exigences juridictionnelles, et a l'autorité de bloquer un cas d'usage même s'il est techniquement prêt à partir.

Un quatrième siège, souvent sous-pondéré, est celui du business/commercial (marketing, produit) car ce sont eux qui proposent les nouveaux usages comme la publicité géolocalisée ou les accords de monétisation de données auprès de tiers. Ils doivent être dans la pièce, mais sans droit de veto, précisément parce qu'ils ont l'incitation la plus forte à repousser les limites.

Construire un RACI qui tient en cas d'incident

Une matrice RACI (Responsible, Accountable, Consulted, Informed) n'est utile que si elle tient sous pression, c'est-à-dire pendant une vraie fuite de données ou une enquête du régulateur, pas seulement dans un slide.

Pour un cas d'usage du type « données de localisation partagées avec un prestataire analytics tiers pour des insights de fréquentation retail » :

ActivitéRéseauIT/DataJuridique/DPOBusiness
Définir la base légaleConsultedConsultedAccountableResponsible (rédige le cas d'usage)
Conception anonymisation/agrégationResponsibleResponsibleConsultedInformed
Provisionnement des accès au prestataireConsultedAccountableConsultedInformed
Audit continu de l'usage par le prestataireInformedResponsibleAccountableInformed
Réponse à incident si le prestataire détourne la donnéeConsultedResponsibleAccountableInformed

Le choix de conception décisif : le Juridique/DPO est Accountable sur la base légale et sur la réponse à incident, pas l'IT. Cela compte parce que lorsque les régulateurs enquêtent (comme l'ont fait des DPA européennes auprès de plusieurs opérateurs pour des violations de la directive ePrivacy), ils demandent « qui a approuvé ce cas d'usage », pas « qui a écrit la requête ». Si l'Accountability est portée par l'IT, l'opérateur n'a en pratique aucun récit de governance défendable.

Contrôles et audits concrets à mener

Les conseils de governance échouent quand ils n'existent que sur le papier. Les contrôles qui les rendent réels :

  1. Recertification des accès, trimestrielle. Chaque personne et chaque système ayant un accès en requête aux tables CDR ou de localisation est revu. Les accès dormants (un salarié qui a changé de poste il y a six mois) sont le constat le plus fréquent dans les audits de données télécom.
  1. Audits de limitation de finalité. Échantillonnez chaque mois un ensemble de requêtes exécutées sur les données abonnés et confrontez-les à la finalité business déclarée au dossier. Cela teste directement le principe de limitation des finalités du RGPD.
  1. Balayages de conservation. Les CDR et journaux de localisation doivent avoir des durées de conservation définies (la pratique de marché couramment citée conserve les CDR détaillés sur la fenêtre des litiges de facturation, souvent autour de 12 à 24 mois, même si les durées exactes dépendent de l'opérateur et de la juridiction et doivent être vérifiées dans la politique de conservation publiée par chaque opérateur). Des jobs automatisés doivent confirmer que la suppression a bien lieu, pas seulement qu'une politique existe.
  1. Revues des contrats de partage de données avec les tiers. Tout prestataire recevant ne serait-ce que des données de localisation agrégées doit être réaudité annuellement au regard de son accord de traitement des données (DPA dans la terminologie RGPD, un contrat encadrant la façon dont un sous-traitant traite la donnée pour le compte d'un responsable de traitement).
  1. Journalisation des réquisitions d'interception légale. Chaque demande des autorités, acceptée ou rejetée, est journalisée avec un horodatage, l'identifiant du demandeur et la base légale invoquée. Ce journal devient lui-même une preuve dans les litiges ou revues réglementaires futurs.

Un schéma de requête d'audit que les équipes IT exécutent couramment pour repérer les violations de limitation de finalité ressemble à ceci :

sql
SELECT query_id, user_id, table_accessed, stated_purpose, query_timestamp
FROM data_access_log
WHERE table_accessed IN ('cdr_records', 'location_pings')
  AND stated_purpose NOT IN (
    SELECT approved_purpose FROM governance_use_case_registry
  );

Toute ligne retournée est une exception de governance nécessitant une escalade au conseil, pas un correctif discret par l'IT.

Vérification des acquis

1. Dans le scénario d'ouverture, un analyste fraude, le juridique et l'IT n'arrivent pas à s'accorder sur qui peut refuser une réquisition judiciaire dépourvue de numéro de dossier. Quel vide de governance fondamental cela illustre-t-il ?

2. Pourquoi la data governance télécom exige-t-elle de concilier les intérêts des opérations réseau, du marketing/analytics et des autorités judiciaires plutôt que de simplement retenir les priorités d'un seul groupe ?

3. Une équipe marketing veut utiliser des données de localisation pour une campagne ciblée de prédiction du churn. Dans un modèle de governance conforme au RGPD, que faut-il établir avant que cet usage soit admissible ?

CHOIX MULTIPLES

4. Sélectionnez TOUTES les bonnes réponses : parmi les éléments suivants, lesquels sont des exemples de données sensibles que les opérateurs télécoms détiennent de façon unique, ce qui élève les enjeux de governance ?

Sélectionnez toutes les réponses correctes.

CHOIX MULTIPLES

5. Sélectionnez TOUTES les bonnes réponses : pourquoi un operating model formel de data governance est-il nécessaire dans les télécoms, selon le raisonnement de la leçon ?

Sélectionnez toutes les réponses correctes.

Quand le modèle est mis à l'épreuve : le scénario d'incident

Revenons à la demande de 2h47. Un modèle de governance qui fonctionne signifie que l'analyste dispose d'un chemin d'escalade documenté : rejeter par défaut les demandes sans numéro de dossier, escalader les cas ambigus à un contact Juridique/DPO d'astreinte, et journaliser la décision quelle qu'en soit l'issue. Sans cela, le comportement par défaut sous pression temporelle consiste généralement à obtempérer d'abord et à s'interroger ensuite, ce qui est exactement le schéma qui a conduit à des amendes réglementaires aux États-Unis comme dans l'UE ces dernières années.

Pour une référence de source primaire plus approfondie sur la manière dont les régulateurs européens envisagent les obligations de privacy propres aux télécoms, les lignes directrices du Comité européen de la protection des données (EDPB) publient des orientations sectorielles mises à jour périodiquement.

Points clés

  • Les conseils de governance télécom ont besoin de trois sièges dotés d'une autorité réelle : Réseau, IT/Plateforme data et Juridique/DPO, le Juridique portant l'Accountability sur la base légale et la réponse à incident, pas seulement les équipes techniques.
  • Les données de localisation et les CDR sont encadrés concrètement par le RGPD et la directive ePrivacy en Europe, et par la Section 222 (CPNI) appliquée par la FCC aux États-Unis, auxquels s'ajoutent les obligations d'interception légale des régimes de type CALEA.
  • Une matrice RACI n'est crédible que si elle attribue l'Accountability au rôle qui peut réellement en répondre devant un régulateur ; testez-la contre une fuite hypothétique, pas seulement contre les opérations de routine.
  • Menez des contrôles récurrents et automatisables : recertification trimestrielle des accès, audits de requêtes sur la limitation de finalité, balayages de conservation et revues des DPA tiers. Journalisez chaque réquisition d'interception légale et son traitement.
  • Concevez pour le cas limite de 2h du matin, pas pour le régime stable. Les modèles de governance qui ne fonctionnent que pendant les revues calmes et planifiées échoueront précisément quand les régulateurs y prêtent le plus attention : pendant un incident.