Les normes d'un projet SIG : le guide que personne n'écrit | Kharita
Guides & tutorielsFrançais··29 min de lecture·Par SIGina
Les normes d'un projet SIG : le guide que personne n'écrit
Référentiel spatial, modèle de données, formats, services OGC, métadonnées, qualité — et les pièges propres aux données marocaines.
›Sommaire20 sections20 sections
Un lot de parcelles arrive d'un bureau d'études. Le fichier est propre : géométries valides, attributs complets, aucune erreur à l'import. Pourtant, à l'écran, les polygones s'affichent au nord de Séville, à quatre cents kilomètres de leur emplacement réel.
Le réflexe est universel et il est presque toujours faux : mettre en cause la livraison. La donnée est correcte. Ce qui ne l'est pas, c'est une seule ligne décrivant son système de coordonnées, dans un fichier .prj que personne n'ouvre jamais.
Cet incident n'a rien d'exceptionnel. Tout professionnel de la géomatique en a rencontré une variante, et il illustre une réalité que les projets SIG découvrent généralement trop tard : leur robustesse ne dépend pas de la puissance des outils, mais du respect d'un ensemble de conventions que personne ne prend le temps d'écrire.
Les zones Lambert marocaines sont définies avec des paramètres exprimés en grades, une unité qui découpe le tour complet en 400 parts au lieu de 360. La latitude d'origine de la zone Nord vaut 37 grades, soit 33,3 degrés. Relue comme 37 degrés, elle projette tout le territoire quatre cents kilomètres trop au nord.Carte Kharita, contours d'après Natural Earth (1:50 M)
Selon le moment où il est détecté, un tel défaut coûte une demi-journée de perplexité ou six mois de données inexploitables. C'est le sujet de cet article, et c'est probablement le moins glamour de toute la géomatique. Personne n'a jamais posté une capture d'écran enthousiaste d'un catalogue d'objets. Aucun client ne s'est extasié devant une fiche de métadonnées bien remplie. Les normes n'ont pas de démo.
Elles n'ont que des conséquences.
Pourquoi ce sujet est systématiquement repoussé
Il y a une raison structurelle à cette négligence, et elle mérite d'être nommée avant d'entrer dans le détail technique.
Une norme ne produit aucun bénéfice visible le jour où on l'applique. Choisir un système de coordonnées unique pour un projet, écrire une convention de nommage des champs, remplir une fiche de métadonnées : rien de tout cela n'avance la carte que le chef de projet attend pour vendredi. Le bénéfice arrive dix-huit mois plus tard, quand un autre service veut croiser vos données avec les siennes, quand un prestataire part et qu'un autre reprend, quand il faut rejouer un traitement sur les données de l'an dernier.
Discussion
Commentaires
Le coût, lui, est parfaitement visible : c'est du temps passé aujourd'hui. Cette asymétrie explique presque tout. Elle explique pourquoi les projets SIG accumulent silencieusement une dette dont personne ne voit le compteur tourner, jusqu'au jour où la migration devient plus chère que le projet initial.
L'objectif de ce qui suit n'est pas de dresser un catalogue de normes, ce qui serait illisible et inutile. C'est de montrer à quel moment chaque famille de normes intervient, ce qu'on gagne à s'y tenir, et le minimum vital pour un projet qui n'a ni le budget ni l'ambition d'une infrastructure nationale.
La pile se lit du bas vers le haut. Les trois premières couches se décident au démarrage du projet et conditionnent tout le reste ; les suivantes peuvent se rattraper, à un coût croissant.Schéma Kharita
Couche 1 : Le référentiel spatial, là où tout se joue
C'est la couche fondamentale, celle dont l'erreur ne se rattrape jamais complètement, et c'est aussi celle qui provoque l'incident du lundi matin.
Un système de coordonnées de référence, au sens de la norme ISO 19111, n'est pas un simple choix d'unités. C'est un ensemble cohérent : un ellipsoïde qui approxime la forme de la Terre, un datum qui le positionne par rapport au sol réel, et éventuellement une projection qui aplatit le tout sur un plan. Changer un seul de ces éléments déplace physiquement vos objets.
Le registre EPSG, maintenu par l'association internationale des producteurs de pétrole et de gaz, attribue à chacune de ces combinaisons un identifiant numérique. C'est l'invention la plus utile de toute la géodésie appliquée : elle permet de désigner sans ambiguïté, en cinq chiffres, ce qu'il faudrait autrement décrire en une demi-page de paramètres.
Le cas marocain
Le Maroc travaille historiquement dans le système Merchich, fondé sur l'ellipsoïde Clarke 1880 (IGN), avec un découpage du territoire en quatre zones de projection conique conforme de Lambert.
Quatre zones, quatre codes EPSG distincts. Un ancien code unique pour le Sahara subsiste dans de vieux fichiers : il a été remplacé et ne doit plus être utilisé pour de nouvelles productions.Carte Kharita, contours d'après Natural Earth ; limites de zones indicatives
Trois pièges reviennent constamment sur les données marocaines, et ils méritent d'être connus par cœur.
Le piège des grades. Les paramètres officiels des zones Lambert marocaines sont exprimés en grades. Une latitude d'origine de 37 grades correspond à 33,3 degrés. Un logiciel, ou un développeur, qui interprète ce 37 comme des degrés projette tout le pays en Andalousie. C'est exactement le scénario de l'ouverture. La parade est simple et absolue : ne jamais ressaisir des paramètres de projection à la main. On appelle le système par son code, EPSG:26191, et la bibliothèque de projection s'occupe du reste.
Le piège de la transformation. Passer de Merchich à WGS 84 exige une transformation de datum. Les paramètres usuels sont un décalage de 31, 146 et 47 mètres sur les trois axes. Omise, cette transformation ne projette pas vos données en Espagne : elle les décale de cent à deux cents mètres. C'est beaucoup plus insidieux : à l'échelle d'une carte régionale, personne ne voit rien. À l'échelle d'un plan parcellaire, c'est une limite de propriété qui traverse une maison.
Le piège de l'ordre des axes. Le code EPSG:4326 définit officiellement l'ordre latitude, longitude. Une bonne partie des outils du web, et le format GeoJSON lui-même, utilisent l'ordre inverse. Les services WMS en version 1.1.1 et 1.3.0 ne se comportent d'ailleurs pas de la même façon sur ce point. Quand une couche apparaît transposée dans l'océan Indien, c'est presque toujours de là que ça vient.
Les deux règles à retenir
Pour un projet neuf, la règle qui évite quatre-vingt-dix pour cent des problèmes tient en deux phrases.
Stockez vos données dans un système unique, décidé une fois pour toutes et écrit dans la documentation du projet. Projeté si vous faites des calculs de surface et de distance, géographique si vos données ont vocation à circuler. Et exportez toujours en indiquant explicitement le code EPSG, jamais en laissant le logiciel deviner.
Quant à la question « faut-il stocker en 4326 ou en projeté », elle n'a pas de réponse universelle. Une base qui alimente une application web gagne à rester en 4326, parce que c'est ce qu'attendent les bibliothèques cartographiques. Une base qui sert à calculer des surfaces forestières gagne à être projetée, parce que calculer une aire en degrés n'a aucun sens. Beaucoup d'équipes maintiennent les deux : une colonne de stockage projetée et une vue en 4326 pour la diffusion.
Couche 2 : Le modèle de données, la norme qu'on écrit soi-même
Les normes internationales ne vous diront jamais comment nommer vos champs. Elles vous disent en revanche comment formaliser ce choix pour qu'il survive à votre départ.
ISO 19109 définit les règles de construction d'un schéma applicatif : comment passer d'une réalité de terrain à des types d'objets, des attributs et des relations. ISO 19110 définit le catalogue d'objets : le document qui énumère, pour chaque type d'objet, sa définition, ses attributs, leurs types, leurs unités et leurs valeurs admissibles. Simple Features, norme conjointe de l'OGC et de l'ISO, définit ce qu'est un point, une ligne, un polygone, et ce que signifie « toucher », « contenir » ou « intersecter ».
Cette couche est celle où les projets marocains, et pas seulement marocains, perdent le plus de valeur, pour une raison banale : le catalogue d'objets n'existe pas. Les codes de strate, les nomenclatures d'essences, les statuts administratifs vivent dans la tête de deux personnes et dans un onglet Excel que chacun a copié dans sa version.
Les symptômes sont reconnaissables entre tous.
Un champ type qui contient tantôt Futaie, tantôt futaie, tantôt FUT. Une date stockée en texte, parce que le format d'export ne gérait pas les dates. Un champ observation qui accueille tout ce qui n'entrait nulle part ailleurs, et qui devient au bout de deux ans la donnée la plus riche et la plus inexploitable du projet. Des identifiants qui changent à chaque export, ce qui rend impossible tout suivi dans le temps.
Ce qu'il faut produire, au minimum, tient en un tableau de cinq colonnes : nom du champ, libellé métier, type, unité, valeurs autorisées. Écrit une fois, il sert de contrat avec les prestataires, de source pour les listes déroulantes des formulaires de terrain, de base pour les contraintes en base de données et de référence pour les métadonnées. C'est probablement le meilleur retour sur investissement de tout ce qui est décrit dans cet article.
Trois principes techniques complètent ce tableau. Un identifiant stable, jamais recalculé, jamais réattribué. Un typage strict, avec des dates en type date et des nombres en type numérique. Et des domaines de valeurs contraints en base, pas seulement documentés, parce qu'une règle qui n'est pas appliquée par la machine finit toujours par être contournée.
Couche 3 : Les formats d'échange, ou le poids des habitudes
Vient ensuite la question du contenant. Et là, un constat s'impose : le format le plus utilisé au monde pour échanger des données géographiques est un format propriétaire conçu en 1993, dont les limites sont documentées depuis trente ans.
Le shapefile souffre de contraintes qui ne sont pas des détails. Les noms de champs sont tronqués à dix caractères. Le nombre de champs est plafonné. Chaque fichier est limité à deux gigaoctets. Les dates avec heure ne sont pas gérées. L'encodage des caractères dépend d'un fichier annexe souvent absent, d'où les accents en charabia. Et un jeu de données n'est pas un fichier mais une famille de fichiers qu'il faut déplacer ensemble.
Les limites structurelles du shapefile
caractères maximum par nom de champ
10
champs maximum par couche
255
taille maximale d'un fichier
NaN
Spécification technique du format shapefile
Ces limites ne sont pas théoriques. En préparant cet article, j'ai généré un jeu de cinquante mille parcelles forestières fictives avec douze attributs, puis je l'ai écrit dans quatre formats. Le passage au shapefile a produit, sans que rien ne s'interrompe, ce genre d'avertissements :
Normalized/laundered field name: 'diametre_moy_cm' to 'diametre_m'
Normalized/laundered field name: 'volume_m3_ha' to 'volume_m3_'
Normalized/laundered field name: 'date_observation' to 'date_obser'
Field date_obser created as String field, though DateTime requested.
Quatre noms de champs mutilés et une date dégradée en texte, en silence. Si ce fichier repart chez un prestataire qui le renvoie tel quel, le schéma que vous aviez soigneusement conçu est perdu, et personne ne l'a décidé.
Le même jeu de données, écrit dans les formats concurrents, donne ceci.
Poids du même jeu de données selon le format
En Mo
Mesure Kharita, 50 000 polygones, 12 attributs, écriture via GDAL et pyarrow
▸ Voir les données
Shapefile
35,6
GeoJSON
33,1
GeoPackage
16,5
GeoParquet
3,5
Un facteur dix entre les extrêmes, pour un contenu strictement identique. Les temps de lecture suivent la même pente : 1,31 seconde pour le GeoJSON, 0,52 pour le shapefile, 0,39 pour le GeoPackage, 0,19 pour le GeoParquet. Et en ne lisant que trois colonnes sur treize, cas typique d'une analyse ciblée, le GeoParquet descend à 0,08 seconde, parce que son organisation en colonnes lui permet d'ignorer physiquement le reste du fichier.
Quel format pour quel usage
Il n'y a pas de vainqueur universel, mais il y a des choix raisonnables.
Le GeoPackage, normalisé par l'OGC, est le remplaçant naturel du shapefile pour l'échange et le terrain : un seul fichier, des noms de champs libres, plusieurs couches, des types respectés, du raster et du vecteur dans le même conteneur. C'est le format à écrire dans un cahier des charges quand on veut simplement que les choses fonctionnent.
Le GeoJSON, décrit par la RFC 7946, est le format du web. Attention à une contrainte que beaucoup ignorent : cette norme impose le WGS 84 en longitude-latitude. Un GeoJSON en coordonnées projetées est un fichier hors norme, même si votre outil l'a produit sans broncher. Pour les cas où l'on a besoin d'autre chose (coordonnées projetées, troisième dimension, temporalité), l'OGC a publié en 2026 la norme JSON-FG, conçue exactement pour combler ces manques sans casser la compatibilité.
Le COG, GeoTIFF réorganisé pour la lecture à distance, est norme OGC depuis 2023. Il permet de lire une fenêtre d'une image satellite de plusieurs gigaoctets sans la télécharger. Pour tout projet manipulant du raster hébergé, c'est devenu le défaut.
Le GeoParquet, dont la version 2.0 est publiée et en cours d'approbation formelle par l'OGC, est le format des gros volumes vecteur et de l'analyse. Ce n'est pas un format d'édition : on ne modifie pas un GeoParquet parcelle par parcelle. C'est un format de diffusion et de calcul, et sur ce terrain il n'a pas d'équivalent.
Couche 4 : Les services, de WxS aux OGC API
Quand la donnée cesse d'être un fichier pour devenir un service, une autre famille de normes prend le relais.
La génération historique (WMS pour les images de carte, WFS pour les objets, WMTS pour les tuiles, CSW pour les catalogues) a structuré l'interopérabilité géospatiale pendant vingt ans. Elle fonctionne, elle est massivement déployée, et rien n'impose de l'abandonner. Mais elle porte les habitudes de son époque : des URL chargées de paramètres, du XML, des spécifications que seul un serveur SIG sait servir.
La correspondance n'est pas un simple renommage : les OGC API réorganisent les mêmes fonctions autour de ressources adressables et de réponses JSON, décrites en OpenAPI.Schéma Kharita
Comme ces deux services constituent encore l'essentiel de ce qu'un géoportail expose aujourd'hui, ils méritent qu'on s'y arrête vraiment.
WMS : le serveur dessine, le client affiche
Un WMS renvoie une image. Pas des géométries, pas des attributs : des pixels. Le rendu est calculé côté serveur, selon un style que le serveur décide.
Il expose trois opérations. GetCapabilities décrit le service : couches disponibles, emprises, projections supportées, formats d'image, styles. C'est toujours la première requête à lancer quand quelque chose ne marche pas, parce qu'elle donne les noms de couches exacts à employer. GetMap demande l'image proprement dite.
GetFeatureInfo, enfin, rattrape partiellement la limite du procédé : on clique sur un pixel, le serveur renvoie les attributs de l'objet qui se trouve dessous.
Le piège des versions mérite d'être connu par cœur, parce qu'il produit des symptômes déroutants. Entre WMS 1.1.1 et 1.3.0, le paramètre de projection change de nom (SRS devient CRS), les coordonnées de clic passent de X,Y à I,J, et surtout l'ordre des axes s'inverse pour EPSG:4326 : longitude-latitude en 1.1.1, latitude-longitude en 1.3.0. Une carte qui s'affiche vide, ou dans l'océan Indien, vient presque toujours de là. La parade sûre consiste à demander CRS=CRS:84, qui impose sans ambiguïté l'ordre longitude-latitude.
Son parent WMTS applique la même logique en pré-calculant les tuiles selon une pyramide fixe. On perd la souplesse (une seule projection, des échelles figées), on gagne la vitesse.
WFS : le serveur livre, le client décide
Un WFS renvoie les objets eux-mêmes, en GML, en GeoJSON ou dans un autre encodage. Le client peut alors les styliser, les filtrer, les analyser, les exporter.
La même couche, la même emprise, deux réponses radicalement différentes. Le choix n'est pas seulement technique : il détermine si vos données quittent ou non le serveur.Schéma Kharita
Là aussi, trois opérations. GetCapabilities liste les types d'objets disponibles. DescribeFeatureType renvoie le schéma d'une couche (noms de champs, types, cardinalités), ce qui en fait l'équivalent d'un \d table en SQL. GetFeature livre les données.
Les paramètres COUNT et STARTINDEX gèrent la pagination, et ils ne sont pas facultatifs en pratique : un GetFeature sans limite sur une table volumineuse ramène tout et met le serveur à genoux.
L'extension transactionnelle, WFS-T, autorise l'écriture : insertion, mise à jour, suppression. C'est ce qui permet une saisie collaborative directe depuis un poste de travail sur une base distante. C'est aussi, si le contrôle d'accès est négligé, une base de données ouverte en écriture sur internet.
Le vrai apport du WFS reste le filtrage. La norme prévoit Filter Encoding, en XML, d'une verbosité décourageante : une simple condition sur deux attributs occupe une douzaine de lignes. La plupart des serveurs acceptent en parallèle un paramètre CQL_FILTER beaucoup plus lisible, mais c'est une extension, pas la norme. Ce besoin mal servi est précisément ce que les OGC API ont fini par normaliser.
Ce que change réellement la nouvelle génération
Les OGC API reposent sur des principes que tout développeur web reconnaît : une ressource, une URL, du JSON, une description OpenAPI explorable depuis un navigateur. La différence se voit mieux sur un exemple que dans un discours.
WFS 2.0 /wfs?SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature
&TYPENAMES=parcelles&COUNT=10&OUTPUTFORMAT=application/json
Features /collections/parcelles/items?limit=10
/collections/parcelles/items/P-000042
La seconde forme est lisible, testable dans la barre d'adresse, et surtout chaque objet possède sa propre URL stable, ce qui le rend citable, partageable et cacheable par n'importe quel proxy HTTP. OGC API — Tiles a d'ailleurs été repris comme norme ISO en 2026, ce qui donne la mesure de la maturité atteinte.
La famille est plus large que les six correspondances du tableau. OGC API — Common définit le socle partagé : la page d'accueil, la déclaration de conformité, la liste des collections. Environmental Data Retrieval interroge des données environnementales par position, trajectoire, corridor ou cube plutôt que par rectangle, soit le bon modèle pour extraire une série temporelle météo en un point. Moving Features gère les objets dont la géométrie change dans le temps, traces GPS comprises. openEO décrit des traitements d'imagerie sous forme de graphes exécutables sur n'importe quelle plateforme compatible, ce qui évite d'écrire son calcul NDVI pour un fournisseur unique.
Trois briques transverses méritent en outre d'être connues, parce qu'elles servent au quotidien sans jamais être citées.
CQL2 est le langage de filtre commun aux OGC API, disponible en texte et en JSON. Il remplace le Filter Encoding XML par une syntaxe qu'on peut écrire à la main, avec opérateurs de comparaison, spatiaux et temporels.
filter=essence='Cedrus atlantica' AND volume_m3_ha > 120
AND S_INTERSECTS(geom, POLYGON((...)))
filter-lang=cql2-text
Two Dimensional Tile Matrix Set formalise ce qu'est une pyramide de tuiles : projection, origine, taille des tuiles, échelle de chaque niveau. C'est elle qui rend possible un service de tuiles dans une projection nationale au lieu du Web Mercator imposé par défaut.
WKT-CRS, enfin, est la représentation textuelle d'un système de coordonnées, littéralement le contenu du fichier .prj de notre introduction. Sa version 2 attache explicitement une unité à chaque paramètre, ce qui clôt l'ambiguïté des grades :
PARAMETER["Latitude of natural origin", 37,
ANGLEUNIT["grad", 0.0157079632679489]]
En WKT version 1, cette unité n'était pas déclarée. Toute l'histoire de l'Andalousie tient dans cette ligne manquante.
Sur cette couche, la règle pratique est simple. Un projet neuf qui expose des données gagne à viser les OGC API. Un projet existant qui sert du WMS depuis huit ans n'a aucune raison urgente de migrer. Ce qui compte, dans les deux cas, c'est que le service soit décrit : un document de capacités à jour, des identifiants de couches stables, une version dans l'URL.
Le reste du catalogue
L'OGC publie plus de quatre-vingts normes. Personne n'en applique la moitié, et ce n'est pas le but : l'intérêt est de savoir laquelle existe déjà le jour où le besoin se présente, plutôt que de réinventer un modèle que cinquante organisations ont déjà éprouvé.
Le catalogue OGC vu par fonction plutôt que par ordre alphabétique. Chaque famille répond à une question de projet, pas à une catégorie théorique.Schéma Kharita, d'après la classification officielle de l'OGC
Quelques normes de ce catalogue méritent une mention particulière, parce qu'elles répondent à des besoins très concrets et restent largement méconnues.
Les modèles métier évitent de réinventer un vocabulaire. CityGML et CityJSON pour la ville en trois dimensions, avec une vraie sémantique : un mur est un mur, pas un triangle. MUDDI pour l'intégration des réseaux enterrés, tous opérateurs confondus, qui raisonne par contenance : un fourreau contient des conduits, qui contiennent des câbles. WaterML 2 et GroundWaterML 2 pour les séries hydrologiques et les eaux souterraines. LAS et LAZ pour les nuages de points, avec leurs classifications normalisées : sol, végétation basse, moyenne, haute, bâti.
Les normes de capteurs constituent la couche absente de la plupart des projets dits de jumeau numérique : le réseau est modélisé, mais pas le flux de mesures qui le rend vivant. SensorThings API organise cela autour de huit entités liées (objet, localisation, flux de données, capteur, propriété observée, observation), avec une extension de diffusion en flux, typiquement via MQTT. SensorML décrit le capteur lui-même, calibration comprise, et le modèle Observations, Measurements and Samples définit ce qu'est formellement une observation.
Les conteneurs de gros volumes vont au-delà du GeoPackage. Zarr, désormais norme OGC, découpe un tableau multidimensionnel en blocs indépendants, ce qui permet de lire une tranche temporelle d'un cube climatique sans toucher au reste. netCDF et HDF5 remplissent le même rôle en fichier classique.
Le style et la sécurité, enfin. SLD et Symbology Encoding décrivent règles et symboles ; le Symbology Conceptual Core Model cherche à rendre un style portable d'un outil à l'autre, problème réel que tout le monde a rencontré en exportant une symbologie soignée vers un autre logiciel. Et GeoXACML étend le contrôle d'accès avec des conditions géométriques : autoriser un utilisateur à consulter uniquement les objets contenus dans le périmètre de sa région. Pour une application déployée sur plusieurs directions régionales, c'est exactement le besoin.
Trois ressources valent mieux que la liste complète des normes. Le catalogue des building blocks rassemble les morceaux réutilisables des OGC API, schémas et exemples compris, c'est là qu'on va pour implémenter. La feuille de route indique ce qui arrive. Et le programme de conformité fournit les tests qui certifient qu'une implémentation respecte réellement la norme : c'est l'argument à opposer, dans un marché, au fournisseur qui se déclare « conforme OGC » sur parole.
Couche 5 : Les métadonnées, la couche qu'on sacrifie toujours
Si vous ne deviez appliquer qu'une seule chose de tout cet article et que la couche 1 était déjà réglée, ce serait celle-ci.
La norme ISO 19115-1 définit ce qu'une fiche de métadonnées doit contenir : identification, emprise, qualité, référentiel spatial, conditions d'accès et d'usage, contacts, généalogie. Son implémentation XML relève d'ISO 19139 puis d'ISO 19115-3. Dans le monde de la donnée ouverte, le vocabulaire DCAT joue un rôle comparable et s'intègre mieux aux portails génériques.
Côté catalogue interrogeable, deux évolutions récentes changent la donne. OGC API — Records modernise une fonction longtemps prisonnière du lourd protocole CSW : un catalogue devient une collection d'enregistrements comme une autre, avec les mêmes URL et les mêmes filtres que le reste des OGC API. Et STAC, né dans la communauté de l'observation de la Terre pour cataloguer des images satellites, a été publié par l'OGC comme norme communautaire en 2026. Son modèle est d'une simplicité désarmante : un catalogue contient des collections, qui contiennent des items, qui pointent vers des fichiers. C'est précisément ce qui en a fait le standard de fait de tout l'écosystème raster. Pour un projet qui produit régulièrement des images ou des séries temporelles, écrire un catalogue STAC coûte quelques heures et rend l'ensemble immédiatement exploitable par les outils existants.
La résistance à cette couche est toujours la même : remplir une fiche complète prend une heure, et le formalisme rebute. C'est vrai. Mais la version dégradée, celle qui tient en dix champs, prend cinq minutes et couvre l'essentiel des besoins réels.
Le titre du jeu de données. Un résumé de trois phrases écrit pour quelqu'un qui ne connaît pas le projet. Le producteur et un contact. La date de production et la date de dernière mise à jour. L'emprise géographique. Le système de coordonnées, par son code EPSG. L'échelle ou la résolution d'usage. La généalogie, c'est-à-dire d'où viennent les données et quels traitements elles ont subis. La licence. Et les limites d'usage connues.
Ce dernier point mérite qu'on s'y arrête. Une licence absente n'est pas une licence permissive. Un jeu de données diffusé sans mention de licence est juridiquement inutilisable par un tiers prudent, ce qui annule l'essentiel de l'intérêt de l'avoir diffusé. Écrire une ligne (licence ouverte, CC BY, ODbL, usage interne) coûte dix secondes et change entièrement la valeur de la donnée.
Couche 6 : La qualité, qui se mesure au lieu de se promettre
ISO 19157 apporte à la géomatique ce qui manque à la plupart des projets : un vocabulaire pour dire ce que vaut une donnée, plutôt que d'affirmer qu'elle est « fiable ».
La norme décompose la qualité en éléments distincts. La complétude : manque-t-il des objets, en existe-t-il en trop ? La cohérence logique : les géométries sont-elles valides, les topologies respectées, les valeurs conformes aux domaines ? L'exactitude de position : à quelle distance de la réalité se trouvent les objets ? L'exactitude temporelle : les dates sont-elles justes, la donnée est-elle à jour ? L'exactitude thématique : les attributs et les classifications sont-ils corrects ?
L'intérêt de ce découpage n'est pas académique. Il permet d'écrire une exigence vérifiable dans un marché, du type « exactitude planimétrique inférieure à un mètre pour quatre-vingt-quinze pour cent des points contrôlés », au lieu d'une formule creuse que personne ne pourra opposer à personne. Et ISO 19131, sur les spécifications de produit, fournit le cadre de ce document d'exigences.
Dans la pratique d'un projet modeste, cela se traduit par quelques contrôles automatisés qui tournent à chaque import : validité des géométries, absence de doublons d'identifiants, valeurs d'attributs dans les domaines autorisés, emprise cohérente, taux de champs vides par couche. Cinq requêtes SQL, un rapport, et la qualité cesse d'être une opinion.
Couche 7 : L'application, où les normes cessent d'être géographiques
Une application SIG est d'abord une application. Elle hérite donc de trois familles d'exigences que la culture géomatique traite trop souvent comme accessoires.
L'accessibilité. Les critères WCAG 2.2 s'appliquent aux interfaces cartographiques comme aux autres, avec des implications concrètes : un contraste suffisant entre les couleurs de la carte et les libellés, une navigation possible au clavier, et surtout une alternative à l'information portée uniquement par la couleur. Une carte choroplèthe où seule la teinte distingue les classes est illisible pour une partie non négligeable des utilisateurs. Ajouter une trame, un motif ou un libellé ne coûte rien au moment de la conception, et beaucoup après.
La sécurité. Une API cartographique publique est une API publique : elle expose une base de données. Les questions de limitation de débit, d'injection dans les paramètres de filtre, de contrôle d'accès par couche se posent exactement comme ailleurs. Un service qui accepte un filtre arbitraire sur une table PostGIS sans validation est une porte ouverte.
La vie privée. C'est le point aveugle le plus fréquent, et il est important au Maroc. Une position est une donnée à caractère personnel dès lors qu'elle se rapporte à une personne identifiable. Suivre en temps réel les équipes de terrain, horodater les points collectés par agent, conserver les traces GPS d'une flotte : tout cela entre dans le champ de la loi 09-08 et relève de la CNDP. Les obligations qui en découlent (déclaration préalable du traitement, information des personnes concernées, finalité déterminée, durée de conservation limitée) sont rarement anticipées dans les cahiers des charges des applications de collecte.
Ce n'est pas un avis juridique, et chaque situation mérite d'être examinée pour elle-même. Mais la question « combien de temps conservons-nous les traces de déplacement des agents, et pourquoi ? » doit être posée à la conception, pas au premier contrôle.
Le bon moment pour chaque décision
Les normes ne s'appliquent pas toutes au même moment. Celles du référentiel et du modèle se décident avant la première ligne de code ; celles de la diffusion et de l'usage peuvent s'ajouter ensuite.Schéma Kharita
Cette chronologie explique pourquoi certains arbitrages sont urgents et d'autres non. Une métadonnée manquante se rattrape : c'est un travail ingrat, mais la donnée est là. Un système de coordonnées mal défini au départ, propagé dans quarante couches, trois exports et une application mobile, ne se rattrape qu'au prix d'une reprise complète, pendant laquelle il faut décider, couche par couche, si le décalage observé est une erreur ou une réalité du terrain.
Ce qu'il faut écrire dans un cahier des charges
Voici, condensé, ce qui transforme un cahier des charges vague en document opposable. Ces clauses tiennent en une page et couvrent la majorité des litiges.
Système de coordonnées imposé par son code EPSG, pour la livraison comme pour le stockage.
Format de livraison imposé : GeoPackage pour le vecteur, GeoTIFF ou COG pour le raster. Le shapefile accepté uniquement en complément, jamais comme livrable de référence.
Catalogue d'objets fourni avec les données : champs, types, unités, domaines de valeurs.
Identifiants stables entre deux livraisons, avec règle explicite en cas de création, fusion ou suppression d'objet.
Fiche de métadonnées par lot, conforme à ISO 19115-1 ou, à défaut, comportant les dix champs minimaux.
Exigences de qualité chiffrées : exactitude planimétrique, taux de complétude, taux de champs renseignés, validité géométrique.
Licence et droits d'usage explicitement mentionnés, y compris pour les données dérivées.
Procédure de recette décrite : les contrôles automatiques que le maître d'ouvrage exécutera à la réception.
Encodage en UTF-8, sans exception.
Réversibilité : en fin de contrat, les données sont restituées dans un format ouvert, documenté et réimportable sans le logiciel du prestataire.
La clause 10 est celle qu'on oublie et qui coûte le plus cher. Elle est aussi celle qui donne tout son sens aux neuf précédentes.
Où en êtes-vous ?
La progression est cumulative. Viser directement le niveau supérieur sans avoir stabilisé les précédents produit une façade normative sans fondations.Schéma Kharita
Pour situer un projet sans se raconter d'histoires, dix questions suffisent. Chaque réponse négative est une dette identifiée.
Le système de coordonnées du projet est-il écrit quelque part, ailleurs que dans la mémoire de quelqu'un ? Un nouvel arrivant peut-il comprendre la signification de chaque champ sans demander ? Les identifiants d'objets sont-ils stables d'un export à l'autre ? Existe-t-il une fiche décrivant chaque jeu de données ? La licence de chaque lot est-elle explicite ? Un contrôle automatique tourne-t-il avant chaque intégration ? Les dates sont-elles stockées comme des dates ? L'encodage est-il homogène sur toute la chaîne ? Sauriez-vous dire, pour une couche donnée, d'où viennent les données et quand elles ont été mises à jour ? Et si votre prestataire principal disparaissait demain, pourriez-vous reprendre le projet avec les seuls fichiers en votre possession ?
Le vrai sujet
Les normes ont mauvaise réputation parce qu'on les présente comme des contraintes administratives. Elles sont l'inverse : ce sont des décisions déjà prises par des gens qui ont rencontré le problème avant vous, documentées pour que vous n'ayez pas à les reprendre.
Choisir EPSG:26191 plutôt que de retaper sept paramètres, c'est s'épargner l'après-midi passé à comprendre pourquoi les parcelles sont en Espagne. Écrire un catalogue d'objets, c'est s'épargner la réunion où trois personnes découvrent qu'elles ne parlaient pas de la même chose depuis six mois. Remplir dix champs de métadonnées, c'est s'épargner l'archéologie sur des données dont plus personne ne connaît l'origine.
Aucune de ces économies n'apparaîtra dans un rapport d'activité. C'est bien pour cela que si peu de gens s'en occupent, et c'est exactement pour cela qu'il faut le faire.
La comparaison de formats repose sur une mesure réalisée pour cet article : 50 000 polygones, 12 attributs, écriture et relecture via GDAL et pyarrow sur une même machine. Les ordres de grandeur varient selon la nature des géométries et le matériel. Les cartes sont schématiques et à visée pédagogique ; pour le découpage des zones Lambert, l'ANCFCC fait foi. Les éléments juridiques mentionnés ne constituent pas un avis juridique.
Prochainement sur Kharita : nous descendons d'un cran dans la couche 1, avec un tutoriel complet de reprojection des données marocaines, de Merchich vers WGS 84, dans QGIS, PostGIS et proj4js, avec les paramètres exacts à utiliser dans chaque environnement.
