La demande de l’Arcep
L’Arcep collecte chaque trimestre les cartes de couverture mobile produites par les opérateurs et les publie en données ouvertes (Arcep 2026a, 2026c). Ces cartes ne sont pas des mesures : ce sont des simulations numériques, qui tiennent compte de la position des antennes, de leur puissance, des fréquences utilisées et du relief (Arcep 2026b). L’Arcep impose un niveau de fiabilité minimal, relevé de 95 % à 98 % en 2020, et le vérifie par des campagnes de mesures sur le terrain (Arcep 2024).
Les fichiers transmis ne sont pas toujours cohérents. Certaines zones présentent des formes qui ne correspondent à aucune situation radio plausible, et aujourd’hui elles sont repérées à l’œil par les équipes métier. La demande, telle qu’elle a été formulée lors de la réunion de lancement du 21 septembre, tient en une phrase : automatiser au moins en partie cette détection, sans disposer d’exemples d’anomalies étiquetés, et rendre le résultat exploitable par les équipes.
La problématique qu’on a retenue est donc la suivante : comment attribuer à chaque zone d’une carte de couverture un score d’anomalie compréhensible, par apprentissage non supervisé, et comment s’assurer que ce score a un sens alors qu’aucune vérité terrain n’est disponible ?
Ce qu’on livre
Le cahier des charges demandait un package Python, des rapports d’expérimentation et une étude bibliographique. On livre :
un package Python qui lit un fichier de l’Arcep, le découpe en mailles, calcule les critères, produit le score et extrait les objets d’anomalie, utilisable en ligne de commande et rejouable à chaque publication ;
un outil web qui permet de charger une carte, de sélectionner une région, de parcourir les anomalies et de voir, pour chacune, la justification et la photo aérienne du terrain ;
ce dossier, qui tient lieu d’étude bibliographique et de rapport d’expérimentation ;
les expériences de validation, rejouables par une commande.
Contraintes
Les contraintes fixées avec le client et le tuteur sont les suivantes : un développement en Python, en s’appuyant sur pandas, geopandas et scikit-learn ; une exécution possible sur un poste individuel, sans matériel particulier ; un code versionné avec Git et documenté ; un traitement rejouable à chaque publication trimestrielle sans réécriture. On a ajouté nous-mêmes deux exigences : chaque score doit pouvoir être expliqué, et chaque choix de méthode doit pouvoir être justifié par une mesure ou une référence.
Organisation
L’équipe compte sept élèves de spécialités différentes. Le travail a été découpé en lots suivis dans un diagramme de Gantt, avec une réunion de coordination hebdomadaire et un point avec le client toutes les deux semaines. Les jalons fixés par l’école sont la synthèse de lancement (2 octobre), la revue de projet (22 octobre), le plan d’actions (5 novembre), la recette avec le client et le tuteur (14 décembre), le retour d’expérience (4 janvier) et le forum des projets (22 janvier).