Un MCD de système d’information géographique qui n’existe que dans la tête de son concepteur initial devient un risque opérationnel dès le premier changement de prestataire. Documenter un SIG MCD ne se limite pas à produire un schéma entité-association lisible. Il s’agit de fixer les règles de lecture, les choix de modélisation et les écarts assumés par rapport aux standards, pour que toute personne intervenant sur le système puisse le faire évoluer sans le casser.
Conformité aux standards CNIG : documenter les écarts, pas seulement les choix
Les modèles de données SIG en France sont désormais fortement contraints par des standards nationaux. Les modèles « SIG Eau & Assainissement » du CNIG, dont la structure des classes, attributs et relations a fait l’objet d’une présentation d’avancement en octobre 2023, imposent un cadre précis. Un MCD maintenable ne peut pas se contenter de respecter ces standards : il doit documenter explicitement sa conformité et ses écarts à ces référentiels.
A lire également : La conversion de 250 Go en Mo simplifiée pour tous
Concrètement, cela signifie qu’un tableau de correspondance entre les entités du MCD et les classes du standard CNIG concerné devrait accompagner chaque livrable de modélisation. Ce tableau mentionne, pour chaque écart, la raison technique ou métier qui le justifie.
Sans ce travail, le risque est double. D’abord, lors d’une mise à jour du standard, personne ne sait quelles entités doivent évoluer. Ensuite, lors d’un échange de données avec un partenaire qui respecte le standard à la lettre, les incompatibilités deviennent invisibles jusqu’à ce qu’elles provoquent des erreurs en production.
A voir aussi : Intranet Lyon 3 pour les nouveaux inscrits : les réflexes à adopter
Granularité spatio-temporelle du MCD SIG : ce que les schémas classiques ne montrent pas
Un MCD classique représente des entités, des attributs et des relations. Dans un SIG, une dimension supplémentaire s’ajoute : la granularité spatio-temporelle des objets géographiques. Cette notion couvre le niveau de détail géométrique (parcelle, bâtiment, point d’adresse) et la fréquence de mise à jour attendue.
Les guides modernes de modélisation préconisent de documenter cette granularité directement dans le modèle ou dans un document annexe structuré. Quel est le niveau de généralisation géométrique retenu pour chaque entité ? À quelle fréquence les données sont-elles rafraîchies ? Sur quelle fenêtre temporelle les historiques sont-ils conservés ?
Horodatages et métadonnées d’acquisition
Les retours de terrain en cartographie SIG insistent sur la multiplicité des horodatages à gérer : heure de mesure, d’émission, de réception, d’affichage. S’y ajoutent la méthode de positionnement, le référentiel de coordonnées et la précision estimée. Chaque métadonnée d’acquisition doit figurer comme attribut explicite dans le MCD ou dans une entité dédiée de métadonnées.
Omettre ces attributs dans la documentation condamne les équipes de maintenance à deviner comment une donnée a été produite. Lors d’une correction ultérieure ou d’un changement de capteur, cette absence rend impossible toute traçabilité fiable.
Documentation alignée sur le cycle de vie du code : l’approche docs-as-code
La pratique la plus structurante pour la maintenance d’un MCD SIG est de traiter sa documentation exactement comme du code source. Cette approche, appelée « docs-as-code », repose sur plusieurs principes concrets :
- Le schéma du MCD et sa documentation textuelle sont versionnés dans un dépôt Git, au même titre que le code applicatif du SIG.
- Toute modification du modèle passe par une pull request avec revue par au moins un autre membre de l’équipe, ce qui crée un historique de décisions consultable.
- Un journal des changements (changelog) liste chaque évolution du modèle avec sa date, sa justification et ses impacts sur les couches applicatives et d’analyse.
- Les schémas visuels (diagrammes entité-association) sont générés à partir de fichiers texte (PlantUML, dbdiagram.io) plutôt que dessinés manuellement, ce qui garantit leur cohérence avec le modèle réel.
Cette méthode résout un problème fréquent : la documentation PDF ou Word qui diverge silencieusement du modèle réellement en production. Quand le schéma et le code vivent dans le même dépôt, toute modification de l’un oblige à mettre à jour l’autre.
Contenu minimal d’une fiche de documentation par entité SIG
La question pratique reste : que doit contenir la documentation d’une entité dans un MCD SIG pour être réellement utile à la maintenance ? Les retours terrain convergent vers un socle minimal, au-delà du simple nom et de la liste d’attributs.
- La définition métier de l’entité, rédigée dans le vocabulaire du domaine (urbanisme, réseau d’eau, transport) et non dans un jargon technique pur.
- La correspondance avec le standard applicable (CNIG, INSPIRE) et les écarts documentés.
- Les contraintes d’intégrité spatiale : topologie attendue (connexité, non-chevauchement), système de projection, précision géométrique minimale.
- Les règles de gestion temporelle : fréquence de mise à jour, durée de rétention des versions antérieures, politique d’archivage.
- Les dépendances applicatives : quelles couches cartographiques, quels traitements ETL, quels services web consomment cette entité.
Ce dernier point est souvent négligé. Documenter les dépendances en aval d’une entité permet d’évaluer l’impact d’une modification avant de la réaliser. Sans cette information, chaque évolution du modèle devient un pari sur ses effets de bord.
Quand la documentation doit-elle être mise à jour ?
La règle la plus simple à appliquer : toute modification du MCD qui touche une entité, un attribut ou une relation déclenche obligatoirement la mise à jour de la fiche correspondante dans le même commit ou la même pull request. Si la documentation peut être modifiée indépendamment du modèle, elle finira par diverger.
Les données disponibles ne permettent pas de conclure sur un format unique de documentation qui conviendrait à tous les contextes SIG. Les équipes qui travaillent avec des outils bureautiques (QGIS, ArcGIS Desktop) n’ont pas les mêmes contraintes que celles qui opèrent des plateformes cloud avec des pipelines automatisés. L’approche docs-as-code s’adapte mieux aux secondes, mais elle suppose une culture Git que toutes les équipes SIG ne partagent pas encore.
Le point commun reste la discipline : un MCD non documenté au moment de sa création ne sera jamais documenté après. Intégrer la rédaction de la documentation dans le processus de conception, et non comme une tâche annexe à faire « quand on aura le temps », reste la seule garantie réaliste de disposer d’un modèle maintenable sur la durée.
