Demandez à quelqu'un de Tunis où il habite. Il répondra La Marsa, Ennasr ou Lac 2, jamais « délégation de La Marsa, secteur untel ». Et pourtant, dès qu'un produit doit facturer une livraison, sortir une statistique par région ou affecter un dossier à la bonne agence, c'est le découpage administratif qui fait foi. Mieux vaut le comprendre avant de l'écrire dans une base de données.
Trois niveaux, du gouvernorat au secteur
La Tunisie compte 24 gouvernorats. C'est le niveau que tout le monde connaît : Tunis, Ariana, Ben Arous et La Manouba pour le Grand Tunis, puis Bizerte, Nabeul, Sousse, Monastir, Sfax, Kairouan, Gabès, Médenine, Tozeur et les autres. Chaque gouvernorat a son gouverneur, et c'est à ce niveau que la plupart des administrations, des banques et des transporteurs organisent leurs antennes régionales.
En dessous viennent les délégations, 264 au total. Le gouvernorat de Tunis en compte une vingtaine (Bab Bhar, El Menzah, El Omrane, Le Bardo, La Marsa, Carthage, etc.), alors qu'un gouvernorat comme Tozeur se contente de quelques-unes. C'est le bon niveau pour découper une grande ville sans descendre au détail de la rue.
Le troisième niveau, ce sont les secteurs, les imadas. On en dépasse les deux mille à l'échelle du pays. Chaque secteur a son omda, et c'est l'échelon que l'on retrouve sur pas mal de documents administratifs. Pour un produit numérique, on s'en sert rarement au quotidien, sauf en milieu rural où la délégation reste trop large pour être utile.
Ce qui gêne souvent au début, c'est que le même nom se retrouve à plusieurs niveaux. Sousse est un gouvernorat, une commune, et le nom de plusieurs délégations (Sousse Médina, Sousse Riadh, Sousse Jawhara). Ben Arous, même chose. Si votre formulaire propose un simple champ « ville », vous ne saurez jamais de quel Sousse on parle.
Pourquoi ce découpage compte pour votre produit
Prenez la tarification des livraisons. La plupart des e-commerçants tunisiens fonctionnent avec deux ou trois zones : Grand Tunis, grandes villes, reste du pays. Sur le papier c'est simple. Dans la pratique, la zone est souvent déduite d'un texte libre saisi par le client, et c'est là que ça se gâte. On l'a vu chez un vendeur en ligne basé à Mégrine : « Lac 2 », « Les Berges du Lac » et « Lac II » sortaient dans trois lignes différentes de son tableau de bord, avec trois tarifs différents selon l'opérateur qui avait créé la zone.
Même logique pour les statistiques. Comparer le chiffre d'affaires par gouvernorat, mesurer le délai moyen de livraison par délégation, repérer que Sfax pèse de plus en plus dans les commandes : tout cela suppose que chaque adresse soit rattachée une fois pour toutes à un code de gouvernorat et de délégation, et pas à une chaîne de caractères qu'on regroupe à la main dans un tableur.
Le ciblage, enfin. Une banque qui ouvre une agence à Sousse Riadh, une pharmacie en ligne qui n'a pas encore de livreur à Kairouan, une campagne limitée à l'Ariana : dans chaque cas, on filtre des utilisateurs par zone administrative. Si ce rattachement n'existe pas dans votre base, vous ferez du ciblage à la ville, et ce sera flou.
Les pièges : communes, quartiers et noms d'usage
Premier piège : la commune. Les municipalités ne suivent pas les mêmes frontières que les délégations. Une commune peut s'étendre sur plusieurs délégations, et une délégation peut être partagée entre plusieurs communes. Pour un produit, il faut choisir une hiérarchie de référence et s'y tenir. Gouvernorat, délégation, secteur : c'est l'arbre le plus propre parce que les trois niveaux s'emboîtent. Les communes, on les garde comme attribut à part si on en a besoin (taxe municipale, autorisations).
Deuxième piège : les quartiers qui n'existent pas administrativement. Ennasr est un quartier de l'Ariana que tout le monde connaît, mais ce n'est ni une délégation ni une commune. Lac 2, idem : les agents immobiliers, les livreurs et les restaurants l'utilisent tous les jours, vous ne le trouverez pourtant sur aucune liste officielle. Menzah 6, Cité Olympique, El Aouina, Mourouj 3, la liste est longue. Si vous demandez à l'utilisateur de choisir sa délégation dans un menu déroulant, une bonne partie répondra à côté ou abandonnera. Mieux vaut le laisser taper ce qu'il connaît et faire la traduction vous-même.
Troisième piège, plus discret : l'orthographe. Manouba ou La Manouba, Béja ou Beja, Kébili ou Kebili, Gabès ou Gabes. En arabe, les variantes de translittération sont encore plus nombreuses. Une jointure sur le nom finit toujours par casser. Il faut un identifiant stable par zone, et le nom n'est qu'une étiquette.
Afficher les limites sur une carte géographique
Un découpage administratif ne devient vraiment lisible que sur une carte. Les limites de gouvernorats et de délégations se stockent comme des polygones (au format GeoJSON, généralement) que l'on superpose au fond de carte. Sur les fonds TMaps, on ajoute une couche de polygones avec un remplissage semi-transparent et un contour plus marqué, puis on colore chaque zone selon la donnée qu'on veut montrer : nombre de commandes, délai moyen, présence ou non d'un livreur.
Un détail qui change tout : adapter le niveau au zoom. À l'échelle du pays, afficher les 264 délégations donne une bouillie de traits. On montre les gouvernorats, et on bascule vers les délégations quand l'utilisateur zoome sur Tunis ou Sfax. Les secteurs, on ne les affiche que sur demande, ou dans un outil interne.
Pour le fond lui-même, l'idée est d'utiliser un style neutre qui laisse ressortir vos polygones. Nos fonds sont disponibles en français et en arabe sur l'ensemble du territoire, vous pouvez vérifier la couverture cartographique zone par zone. Si vous cherchez plutôt un aperçu général du pays (relief, littoral, grands axes), l'article sur la carte géographique de la Tunisie fait le tour du sujet.
Rattacher une adresse à sa zone
Reste la partie qui fait la différence entre un produit propre et un tableau Excel : rattacher chaque adresse à son gouvernorat, sa délégation et, si besoin, son secteur.
La méthode qui marche est toujours la même. On géocode l'adresse au moment où l'utilisateur la saisit, pour obtenir un point (latitude, longitude). Puis on cherche dans quel polygone ce point tombe, du plus grand au plus petit. Le résultat, on l'enregistre avec l'adresse : code de gouvernorat, code de délégation, éventuellement code de secteur. Ensuite, toutes les requêtes de tarification, de statistiques ou de ciblage travaillent sur ces codes, jamais sur le texte.
L'autocomplétion aide énormément ici. Quand l'utilisateur tape « Ennasr » et choisit une suggestion, vous récupérez un point précis, et le rattachement à l'Ariana se fait sans qu'il ait à connaître le nom de sa délégation. Le jour où il déménage à Mourouj, même chose, et cette fois la zone tombe dans Ben Arous. Le client n'a rien eu à apprendre du découpage administratif, et votre base est juste.
Faut-il refaire ce rattachement quand les limites changent ? Oui, mais cela arrive rarement, et comme vous avez gardé le point, il suffit de relancer le calcul sur toute la base.
Si vous voulez tester tout cela sur vos propres données, la carte de la Tunisie interactive, les fonds de carte TMaps et le géocodage se combinent en quelques lignes de code. Le plus long, en général, c'est de convaincre l'équipe d'abandonner le champ « ville » en texte libre.
