Interopérabilité DAO-SIG : pourquoi la fin des silos change tout

Interopérabilité DAO-SIG: pourquoi la fin des silos change tout

Quarante ans de divergence: comprendre le fossé entre DAO et SIG

La DAO et le SIG n'ont jamais parlé exactement le même langage. Depuis les années 1980, les deux disciplines ont évolué en parallèle: d'un côté, le dessin assisté par ordinateur, optimisé pour la précision géométrique du trait — cotes au millimètre, accrochage aux objets, calques de présentation; de l'autre, le système d'information géographique, conçu pour gérer, analyser et interroger des couches de données spatiales géoréférencées, structurées par des attributs sémantiques.

Leurs usages se sont pourtant rapprochés. Un plan de voirie, un projet d'aménagement, un réseau enterré ou un relevé topographique doivent aujourd'hui circuler entre les bureaux d'études, les équipes de terrain, les collectivités et les exploitants. Le géomètre produit dans un environnement DAO, le chargé d'études analyse dans un SIG, le maître d'ouvrage consulte une plateforme web, puis le projet retourne parfois dans la DAO pour être détaillé ou exécuté. Entre chaque étape, la donnée change de logiciel, de format et parfois de système de coordonnées.

C'est là que le cloisonnement devient coûteux. Chaque transfert entre un environnement DAO et un SIG peut impliquer une conversion, une perte de métadonnées, une interprétation différente des objets ou une reprojection mal maîtrisée. L'opérateur topographe qui récupère un DWG pour l'intégrer dans QGIS connaît la routine: blocs AutoCAD interprétés comme entités génériques, texte explosé, système de coordonnées absent ou ambigu, attributs non transmis, polylignes qui ne ferment pas correctement. Le fichier passe. L'information, non.

Le DWG transporte des géométries de précision. Le SIG exige des géométries contextualisées. Sans couche d'interopérabilité, le passage de l'un à l'autre est une opération de perte contrôlée.

Ce n'est pas nécessairement un défaut du logiciel utilisé. C'est une conséquence architecturale. La DAO encode d'abord la forme et la logique de représentation du dessin; le SIG encode la relation entre une géométrie, un objet du territoire et une série d'attributs. Dans un plan DAO, une ligne placée sur un calque nommé VOIRIE peut représenter une bordure, un axe, une limite de travaux ou un simple élément graphique. Dans un SIG, une entité doit idéalement porter une nature, une identifiant, une date, un statut, voire une relation avec d'autres objets.

Quarante ans de divergence ont donc produit deux écosystèmes logiciels, deux cultures professionnelles et deux manières de décrire le même espace. La question n'est plus de savoir quel environnement doit remplacer l'autre. Elle consiste à organiser leur dialogue sans transformer chaque échange en chantier de reprise manuelle.

La géométrie ne suffit pas

La difficulté apparaît dès que l'on confond dessin et donnée géographique. Un plan peut être visuellement impeccable et pourtant peu exploitable dans un SIG. Les éléments sont parfois regroupés par fonction graphique plutôt que par objet métier. Les textes sont placés à proximité des géométries sans leur être réellement associés. Les blocs peuvent contenir une information utile, mais cette information n'est pas toujours récupérable comme attribut. Les hachures suggèrent une emprise sans constituer un polygone utilisable pour une analyse spatiale.

Le problème ne se limite donc pas au choix du format d'échange DAO-SIG. Un fichier DXF, DWG ou Shapefile ne devient pas automatiquement interopérable parce qu'il est lisible par deux applications. La lecture technique du fichier est une première étape; la conservation du sens métier en est une autre.

Une conversion réussie doit au minimum répondre à plusieurs questions:

• Quelle entité DAO correspond à quelle classe d'objets dans le SIG?
• Le calque porte-t-il une information sémantique fiable ou seulement une convention graphique?
• Les objets sont-ils correctement géoréférencés?
• Les polylignes sont-elles fermées lorsque le modèle SIG attend des surfaces?
• Les unités, l'altitude et la précision sont-elles cohérentes entre les deux environnements?
• Les attributs doivent-ils être déduits de blocs, de textes, de couleurs ou de propriétés d'objets?
• Comment vérifier que la conversion pourra être rejouée après la prochaine modification du plan?

Tant que ces questions restent implicites, la chaîne dépend de la mémoire de l'opérateur. C'est précisément ce que l'interopérabilité cherche à réduire.

Le rôle des standards OGC et ISO dans la convergence des formats

La convergence n'est pas venue d'un format miracle ni d'un éditeur unique. Elle s'est construite à travers des organismes de normalisation et des spécifications destinées à rendre les données et les services géospatiaux compréhensibles d'une application à l'autre.

L'Open Geospatial Consortium, fondé en 1994, a développé plus de 80 standards ouverts libres de droits, parmi lesquels WMS, WFS, GeoPackage, CityGML et OGC API - Features. Ces standards ne décrivent pas tous la même chose. Certains encadrent le stockage, d'autres la diffusion d'une carte, l'accès à des entités ou la modélisation d'objets urbains.

Depuis 1995, l'OGC collabore avec le comité ISO/TC 211 pour formaliser des normes complémentaires: modélisation sémantique en UML, spécifications de services web spatialisés, schémas de métadonnées normalisés et règles relatives à la description des données géographiques. Il ne s'agit donc pas d'une liste de normes produites par l'ISO/TC 211 seul: plus de 60 normes ont été élaborées conjointement par l'ISO/TC 211 et l'OGC depuis 1995.

L'objectif est moins de forcer tous les logiciels à utiliser un format identique que de créer des règles de compréhension communes. Un jeu de données produit dans un environnement doit pouvoir être consommé, analysé et exploité dans un autre, avec une perte sémantique et une dégradation géométrique aussi limitées que possible.

Trois niveaux d'interopérabilité

Les standards se répartissent en pratique dans plusieurs familles. Les distinguer permet d'éviter une confusion fréquente: un format de fichier, un service web et un modèle de métadonnées ne répondent pas au même besoin.

GeoPackage illustre bien cette logique. Ce conteneur fondé sur SQLite peut stocker des géométries vectorielles, des tuiles raster et des métadonnées dans un fichier portable. Il ne nécessite pas de serveur pour être utilisé et ne dépend pas d'un format propriétaire particulier. Sa portabilité le rend pratique pour un échange de projet, une livraison de données ou un transfert vers un environnement de terrain. Sa présence dans plusieurs logiciels SIG réduit le nombre d'étapes intermédiaires, sans supprimer la nécessité de contrôler le modèle de données.

GeoJSON répond à une autre logique. Il est lisible, adapté aux échanges web et largement pris en charge par les applications modernes. Son usage courant repose sur le WGS84 comme système de coordonnées par défaut. Ce choix simplifie la circulation des données, mais oblige à une attention particulière pour les travaux en projection locale, comme ceux menés en Lambert-93, en RGF93 ou en UTM. Une donnée peut être correctement convertie sur le plan informatique tout en devenant impropre à l'usage si son système de référence est mal interprété.

C'est l'un des points les plus sous-estimés dans la conversion DWG en SHP ou dans le passage de données DAO vers QGIS: les coordonnées ne sont pas une simple propriété technique. Elles déterminent la position réelle de l'objet, sa compatibilité avec les autres couches et la validité des mesures produites ensuite.

Les limites des standards ouverts

Un standard ouvert ne garantit pas à lui seul une interopérabilité parfaite. Il garantit surtout que les règles d'échange sont documentées et accessibles. La qualité du résultat dépend encore de la manière dont chaque logiciel implémente ces règles, des extensions utilisées et de la structure des données de départ.

La présence d'un fichier GeoPackage dans un projet ne dit rien, par exemple, sur la cohérence de ses champs, la qualité de ses géométries ou la précision de son géoréférencement. De la même manière, la publication d'un service WFS ne garantit pas que les attributs exposés correspondent exactement aux besoins du projeteur DAO. Les standards rendent la conversation possible; ils ne rédigent pas le dictionnaire métier à la place des équipes.

Au-delà de la conversion: l'intégration native et les connecteurs applicatifs

La première réponse de l'industrie au cloisonnement DAO-SIG a été la conversion de fichiers. Ouvrir un DXF dans QGIS, exporter un Shapefile vers AutoCAD, transformer un DWG en GeoJSON via un outil intermédiaire: ces opérations font partie du quotidien de nombreux bureaux d'études.

Elles sont utiles lorsqu'un livrable doit être transmis, archivé ou consommé par une application qui ne dispose pas d'un accès direct à la source. Mais elles ont une limite structurelle: elles créent généralement une copie.

Le format DWG ou DXF d'Autodesk encode des primitives géométriques — lignes, polylignes, arcs, blocs, hachures — sans imposer une structure attributaire comparable à celle d'une base SIG. Un polygone DWG n'est pas automatiquement un îlot cadastral, une emprise de chantier ou une zone de servitude. C'est une suite de sommets placée sur un calque et éventuellement associée à d'autres éléments graphiques. La sémantique est souvent portée par convention, par le nom du calque ou par la manière dont le dessinateur a organisé son fichier.

Toute conversion vers un SIG impose donc une phase de requalification. Il faut associer les entités DAO à des couches thématiques, créer ou alimenter des attributs, corriger les géométries et décider du traitement des objets ambigus. Ce travail peut être manuel, scripté ou pris en charge par un outil ETL, mais il ne disparaît pas parce que l'import est techniquement direct.

Les logiciels SIG libres comme QGIS permettent de lire et de convertir de nombreux formats vectoriels et rasters, notamment AutoCAD DXF, ESRI Shapefile, PostGIS, SpatiaLite ou Oracle Spatial. L'import est accessible et souvent rapide. Pourtant, le fichier SIG obtenu reste fréquemment une photographie de l'état du plan au moment du transfert. Dès que le dessin DAO évolue, il faut comparer, réimporter, corriger les divergences et vérifier que les modifications n'ont pas écrasé des enrichissements réalisés dans le SIG.

Convertir un fichier DAO en SIG, c'est photographier un chantier. L'intégration native, c'est brancher une caméra en continu.

La conversion comme processus, pas comme bouton

Parler de conversion donne parfois l'impression qu'il s'agit d'une opération unique: sélectionner un fichier source, choisir un format cible, lancer l'export. Dans un projet professionnel, la chaîne est plus longue.

Elle comprend généralement:

1. La qualification de la source, avec l'identification des unités, du système de coordonnées, des calques utiles, des objets de construction et des éléments purement graphiques.

2. La définition de la correspondance, qui associe les calques, blocs ou propriétés DAO aux classes d'objets et aux champs attendus dans le SIG.

3. La transformation géométrique, notamment la reprojection, la fermeture des polylignes, la correction des doublons et le traitement des objets qui ne correspondent pas directement au modèle cible.

4. La reconstruction sémantique, lorsque les informations utiles sont dispersées dans des textes, des noms de calques, des attributs de blocs ou des conventions de dessin.

5. Le contrôle du résultat, à la fois visuel, géométrique et attributaire.

6. La traçabilité, pour savoir quelles règles ont été appliquées et pouvoir reproduire l'opération sur une nouvelle version du plan.

Cette distinction est importante pour les équipes qui cherchent un format échange DAO-SIG fiable. La performance d'un outil ne se mesure pas seulement à la quantité de formats qu'il ouvre. Elle se mesure aussi à sa capacité à conserver les règles de transformation, à signaler les objets non interprétés et à produire un résultat vérifiable.

Les connecteurs applicatifs et les pipelines ETL

Au-delà des modules d'intégration proposés par les éditeurs, une couche intermédiaire s'est développée: les connecteurs applicatifs et les pipelines ETL spécialisés dans les données géospatiales.

Ces outils automatisent le flux entre DAO et SIG selon des règles définies par l'organisation:

• Extraction: lecture des fichiers DAO — DWG, DXF, DGN — avec récupération des calques, blocs, propriétés et attributs disponibles;
• Transformation: reprojection des coordonnées, nettoyage topologique, filtrage des objets inutiles et requalification sémantique;
• Chargement: injection dans une base SIG comme PostGIS, une géodatabase, un GeoPackage, ou publication dans un service web;
• Contrôle: vérification des géométries invalides, des champs manquants, des objets hors emprise et des écarts de version.

Un calque nommé VOIRIE peut ainsi être orienté vers une couche SIG dédiée, à condition que la convention de dessin permette de distinguer les axes, les bordures, les revêtements et les emprises. Un bloc de mobilier urbain peut alimenter une table d'objets ponctuels si ses attributs sont réellement structurés. À l'inverse, une couleur ou une épaisseur de ligne ne devrait pas être considérée comme une donnée métier fiable sans règle explicite.

Des solutions comme FME, les modules d'import avancé de QGIS ou les scripts Python exploitant GDAL/OGR permettent de chaîner ces étapes de manière reproductible. Le gain n'est pas la suppression de la conversion: c'est son automatisation, sa répétabilité et sa traçabilité.

L'interopérabilité moderne ne repose donc pas sur un format universel unique. Elle repose sur une architecture de connecteurs qui maintient le lien entre les systèmes source et cible, avec des règles de transformation documentées. Dans cette architecture, le format n'est qu'un composant. Le modèle de données, les contrôles et le suivi des versions comptent tout autant.

Vers une continuité numérique: l'accès direct aux services web SIG depuis la DAO

La conversion reste pertinente lorsqu'il faut produire un livrable indépendant. Mais elle devient moins adaptée lorsque plusieurs équipes doivent travailler sur une information qui évolue continuellement. Dans ce cas, l'enjeu n'est plus de transférer une copie à intervalles réguliers. Il consiste à donner à chaque métier un accès au même référentiel, dans son environnement de travail habituel.

L'intégration native répond à cette logique. Des modules comme ArcGIS for AutoCAD permettent aux projeteurs DAO d'accéder directement à des services web SIG d'entreprise, notamment WMS et WFS, sans quitter leur environnement de dessin. Un fond SIG peut s'afficher en arrière-plan du plan AutoCAD; les données disponibles peuvent être consultées ou interrogées selon les capacités du connecteur et les droits associés au service.

La différence est importante. Avec une conversion, l'information est extraite puis copiée dans un nouveau fichier. Avec un accès à un service, le logiciel consomme une source qui reste administrée dans son environnement d'origine. Le projeteur peut travailler avec un contexte géographique actualisé sans importer manuellement chaque couche. Le SIG, de son côté, conserve son rôle de référentiel, d'analyse et de diffusion.

C'est la différence entre importer une carte scannée et accéder à un fond de plan géoréférencé en temps réel. L'un fige l'information. L'autre la maintient vivante.

WMS, WFS et OGC API: même famille, usages différents

Les services web ne sont pas interchangeables. Un service WMS fournit principalement une représentation cartographique rendue par le serveur. Il est adapté à l'affichage d'un fond de plan, à la consultation d'une information de contexte ou à la superposition d'une couche de référence dans une interface DAO.

WFS fournit, lui, un accès à des entités géographiques et à leurs attributs. Il est donc plus proche d'un besoin d'interrogation ou de récupération de données vectorielles. Cette différence conditionne le niveau d'interaction possible. Afficher une couche n'implique pas nécessairement pouvoir sélectionner ses objets, lire tous leurs champs ou les modifier.

Les API plus récentes de l'OGC prolongent cette logique avec des interfaces web orientées vers les entités et les usages applicatifs modernes. Elles facilitent l'accès à des données filtrées et intégrables dans différents clients, mais leur intérêt dépend de la manière dont le service a été configuré et documenté.

Pour un projet DAO-SIG, plusieurs points méritent d'être clarifiés avant de parler d'intégration:

• le service fournit-il une image, des objets vectoriels ou les deux?
• le système de coordonnées attendu par la DAO est-il disponible?
• les données sont-elles consultables seulement ou également modifiables?
• les droits d'accès et l'authentification sont-ils compatibles avec le contexte de production?
• la fréquence de mise à jour est-elle cohérente avec le rythme du projet?
• que se passe-t-il lorsque le service est indisponible ou que le plan doit être utilisé hors connexion?
• les objets récupérés conservent-ils les attributs et la précision nécessaires au travail demandé?

Cette approche ne supprime pas toutes les copies. Un livrable de chantier, un dossier réglementaire ou une archive projet doit souvent être figé à une date donnée. Elle évite cependant de multiplier les copies de travail qui finissent par diverger sans que personne ne sache laquelle fait référence.

Le changement organisationnel derrière la technique

L'accès direct aux services SIG depuis la DAO modifie aussi les responsabilités. Dans un fonctionnement fondé sur des fichiers échangés, chacun possède une version locale et corrige parfois les erreurs dans son périmètre. Dans une architecture connectée, la qualité du référentiel devient une responsabilité partagée mais gouvernée: qui publie la couche, qui valide les mises à jour, qui définit les règles de nommage, qui conserve l'historique?

La continuité numérique suppose donc quelques décisions simples, mais explicites:

• identifier les données qui font autorité pour chaque thème;
• distinguer les données de référence, les données de travail et les livrables figés;
• documenter les systèmes de coordonnées et les unités;
• définir les règles de nommage des calques, des champs et des objets;
• organiser les droits de lecture et d'écriture;
• prévoir un mécanisme de contrôle lorsque les données reviennent de la DAO vers le SIG;
• conserver une trace des transformations et des versions diffusées.

Sans cette gouvernance, un connecteur peut seulement accélérer la circulation d'une donnée mal structurée. Il ne la rend pas plus fiable.

Bilan: viabilité technique, maturité opérationnelle

L'interopérabilité entre données géographiques DAO et SIG est techniquement viable. Les standards existent, les outils sont disponibles et les principaux environnements savent aujourd'hui lire ou exposer une grande variété de formats. Les formats ouverts comme GeoPackage, CityGML et GeoJSON fournissent des conteneurs ou des structures d'échange neutres. Les services web OGC, de WMS à WFS et aux API orientées entités, permettent un accès distant sans conversion préalable dans de nombreux scénarios. Les connecteurs et les chaînes ETL automatisent les flux récurrents.

Mais la maturité opérationnelle reste inégale.

Le goulot d'étranglement n'est donc plus le format seul. C'est la donnée source et la discipline avec laquelle elle est produite. Un DWG proprement structuré — calques nommés selon une convention, blocs attribués, unités explicites, système de coordonnées documenté — peut être intégré dans un SIG avec un minimum de friction. Un DWG construit au fil des besoins, sans convention de nommage, avec des entités en coordonnées locales non géoréférencées et des informations réparties dans des textes, nécessite une requalification qui annule une partie du gain d'automatisation.

La perte de données DAO-SIG n'est pas une fatalité du passage d'un logiciel à l'autre. Elle est souvent le résultat d'une information qui n'a jamais été structurée pour être échangée. La distinction est essentielle: on ne corrige pas un défaut de sémantique avec un convertisseur plus rapide.

L'interopérabilité ne supprime pas le travail de structuration. Elle le déplace en amont, là où il peut être défini une fois, partagé par les équipes et contrôlé dans le temps. C'est ce déplacement qui change réellement les pratiques. Passer d'AutoCAD à QGIS, convertir un DWG en SHP ou publier un fond SIG dans une interface DAO ne sont plus des opérations isolées: ce sont des étapes d'une chaîne numérique continue.

La fin des silos ne signifie pas que la DAO et le SIG doivent devenir le même outil. Elle signifie que chacun peut rester performant dans son domaine tout en partageant une donnée compréhensible, localisée et traçable. L'interopérabilité des données géographiques DAO-SIG ne promet pas l'absence de friction. Elle donne enfin les moyens de savoir où elle se trouve, pourquoi elle apparaît et comment la réduire.