Interopérabilité SIG : pourquoi le cloud change la donne

Interopérabilité SIG: pourquoi le cloud change la donne

Un DWG transmis par courriel, un export Shapefile copié sur un serveur ou une archive de points GNSS déposée sur une clé USB restent des instantanés. Ils vieillissent dès la première modification.

Le cloud ne supprime pas cette contrainte par magie. Il la déplace. La donnée n’est plus seulement copiée entre le contrôleur terrain, le poste DAO et le SIG de bureau: elle devient interrogeable à distance, partiellement lisible et synchronisée selon des règles communes. C’est le principe des formats dits cloud-native. La différence est matérielle: moins de volumes transférés, moins de versions concurrentes, moins de géométries compensées deux fois.

Le gain n’est réel que si la chaîne tient de bout en bout: récepteur GNSS, application de collecte, référentiel spatial, logiciel SIG, DAO et stockage. Un maillon qui reconvertit mal une géométrie, écrase une altitude ou ignore un système de coordonnées suffit à dégrader le résultat.

Le cloud accélère les flux. Il ne corrige ni un mauvais rattachement GNSS, ni une géométrie DAO mal structurée.

Les formats cloud-native ne déplacent pas le fichier entier

Le fonctionnement historique est brutal: un utilisateur télécharge un raster de plusieurs gigaoctets pour consulter une zone de quelques hectares. Même logique pour un nuage de points LiDAR ou une orthophotographie départementale. Le poste local doit recevoir, stocker et indexer l’ensemble avant toute analyse utile.

Les formats cloud-native inversent cette mécanique. Ils organisent les données afin qu’un logiciel SIG puisse ne demander que les blocs nécessaires à l’affichage ou au calcul. Les requêtes de plage HTTP permettent alors de lire une partie ciblée d’un fichier distant, sans rapatrier son volume complet.

Ce mécanisme est central pour l’interopérabilité des données géographiques. Il réduit le rôle du fichier comme conteneur fermé et renforce celui du stockage comme service consultable.

COG: le raster devient accessible par portions

Le Cloud Optimized GeoTIFF, ou COG, reste un GeoTIFF. Sa compatibilité avec les outils existants est donc un atout, pas un détail. Mais son organisation interne est adaptée à une lecture distante: pyramides d’images, tuilage et index positionné de manière à permettre un accès rapide aux blocs demandés.

Dans QGIS, ArcGIS ou une application web correctement configurée, un COG peut afficher une emprise de chantier, une orthophoto ou un modèle numérique de terrain sans exiger le téléchargement préalable de l’intégralité du raster.

Cela change la manière d’exploiter les fonds de plan:

• une orthophoto peut être consultée à l’échelle d’une implantation sans mobiliser le stockage du contrôleur;
• un MNT peut être utilisé pour vérifier une rupture de pente sur une zone limitée;
• plusieurs opérateurs peuvent lire la même source sans créer autant de copies locales;
• les mises à jour du référentiel sont centralisées, à condition que les droits d’accès et le cache soient maîtrisés.

Le COG ne rend toutefois pas le réseau plus stable. En zone blanche, dans un vallon encaissé ou derrière un front bâti dense, un raster distant devient un raster indisponible. Un logiciel terrain de topographie cloud doit donc conserver un mécanisme de mise en cache local, calibré sur l’emprise réelle de l’intervention. Télécharger toute la base « au cas où » recrée le problème initial.

GeoParquet: une table attributaire enfin exploitable à grande échelle

Le GeoParquet répond à un autre besoin: lire rapidement des tables géospatiales massives sans forcer le logiciel à balayer chaque entité. Le format repose sur une organisation colonnaire. Une requête qui ne porte que sur quelques attributs et une emprise définie ne doit pas charger toutes les colonnes, ni toutes les géométries.

Pour une collectivité ou un gestionnaire de réseau, l’intérêt est immédiat. Une base de milliers ou de millions d’objets — regards, mobiliers, arbres, branchements, tronçons — peut être filtrée sur un secteur et sur les seuls champs nécessaires à l’opération. L’opérateur terrain n’a pas besoin de recevoir l’historique complet de la base patrimoniale pour lever trois anomalies.

Le risque est ailleurs: GeoParquet améliore la lecture et la circulation, mais il ne remplace pas un modèle de données cohérent. Si un même objet est nommé différemment selon les services, si les domaines de valeurs ne sont pas verrouillés ou si la topologie est absente, le format performant ne fait qu’accélérer une donnée incohérente.

COPC: le test de charge pour la 3D

Le Cloud Optimized Point Cloud applique la même logique aux nuages de points. Un COPC permet de visualiser et d’analyser une partie d’un relevé LiDAR massif depuis un navigateur ou un SIG, sans transfert physique complet du fichier.

C’est une rupture opérationnelle pour les levés de corridor, les carrières, les façades, les réseaux aériens ou les relevés d’ouvrages. Un conducteur de travaux peut isoler une zone. Un technicien SIG peut contrôler une classification. Un topographe peut comparer des profils. Tous ne manipulent pas nécessairement le nuage entier.

Le COPC ne dispense pas de contrôler la précision du relevé. Une visualisation fluide peut masquer une densité insuffisante, une erreur de classification sol-végétation ou un décalage de calage entre passages. Le format règle l’accès. Il ne compense pas la trajectographie, le boresight, le multipath GNSS ou une mauvaise compensation inertielle.

Terrain et bureau: le transfert GNSS devient une synchronisation

Le transfert des données GNSS vers le SIG est encore trop souvent traité comme une phase administrative: lever, exporter, envoyer, importer, corriger. Cette succession crée des ruptures. Chaque rupture introduit une copie, un risque de conversion et une incertitude sur la version de référence.

Les plateformes de terrain connectées, telles que celles proposées autour de QFieldCloud, Trimble Connect ou Leica GeoCloud, cherchent à établir une synchronisation bidirectionnelle. Les objets créés sur le terrain remontent vers le projet central. Les couches, formulaires, listes de codes et zones de travail préparés au bureau redescendent vers le contrôleur.

La condition est stricte: le projet doit avoir été conçu pour cela.

Un point levé au récepteur GNSS n’est pas seulement une coordonnée. Il porte une méthode de positionnement, une époque, une solution de correction, une hauteur d’antenne, parfois une précision estimée, un code métier, une photographie, une date et l’identité de l’opérateur. Si le modèle de collecte ne prévoit pas ces attributs, la synchronisation transporte une géométrie amputée.

Ce que le logiciel terrain doit préserver

Pour qu’un flux soit exploitable en topographie, l’application de collecte doit conserver au minimum les éléments qui permettent d’évaluer la qualité de la mesure et de la reconstituer si nécessaire:

• le système de coordonnées du projet et, le cas échéant, le modèle géoïdal appliqué à l’altimétrie;
• la nature de la solution GNSS: autonome, différentielle, réseau RTK ou post-traitée;
• les indicateurs de qualité disponibles: nombre de satellites, constellation, âge des corrections, rapport de validation, précision horizontale et verticale estimée;
• la hauteur de canne et le mode de centrage, notamment lorsque l’inclinaison inertielle est utilisée;
• la codification métier imposée par la couche SIG ou le plan DAO;
• l’identifiant stable de l’objet, indispensable pour éviter la création de doublons lors des synchronisations successives.

Le point critique est le conflit de modification. Un agent SIG modifie un attribut au bureau pendant qu’un opérateur modifie le même objet sur le terrain. Une plateforme collaborative doit identifier les deux écritures, les comparer et imposer une règle de résolution. L’écrasement silencieux est inacceptable sur une base patrimoniale.

Une synchronisation bidirectionnelle sans stratégie de conflit n’est pas collaborative. C’est une duplication accélérée.

La précision GNSS ne survit pas automatiquement au passage SIG

Le passage d’un contrôleur GNSS vers un logiciel SIG collaboratif donne souvent une impression de continuité parfaite. Elle est trompeuse si la précision est réduite à un symbole de point sur une carte.

Sur le terrain, la machine travaille avec un environnement physique: masque d’horizon, canopée, réflexions sur façade, multipath sur véhicule, corrections réseau variables, inclinaison de la canne. La précision annoncée par le récepteur dépend de ces conditions. Elle doit être qualifiée avant la synchronisation.

Le SIG, lui, manipule ensuite une géométrie. Il peut bufferiser, intersecter, joindre et styliser cette géométrie sans savoir que la position provient d’une solution dégradée sous couvert arboré. La donnée doit donc emporter un statut de qualité utilisable dans les règles métier.

Une canalisation relevée avec une précision verticale insuffisante ne doit pas être confondue avec un point d’implantation contrôlé. Une application de collecte sérieuse peut empêcher la validation en dessous d’un seuil paramétré, signaler une correction trop ancienne ou exiger une nouvelle occupation. C’est là que le logiciel terrain topographie cloud cesse d’être un simple formulaire cartographique.

La CAO et le SIG ne fusionnent pas: ils doivent se raccorder proprement

L’interopérabilité entre CAO et SIG est souvent présentée comme une fusion naturelle. C’est faux. Les deux environnements ne servent pas le même objectif.

La CAO produit et ajuste une géométrie de conception. Elle exige des accrochages, des contraintes, des profils, des axes, des habillages, des calculs de cubatures et une précision graphique contrôlée. Le SIG structure des objets géolocalisés, des attributs, des relations, des règles topologiques et des analyses territoriales.

Un fichier DWG ou DXF peut contenir une information spatiale utile. Il ne devient pas automatiquement une base SIG propre. Une polyligne de calque DAO ne porte pas toujours un identifiant métier, une date de mise à jour, une règle de validité ou une relation avec le réseau qu’elle représente.

Les connecteurs cloud, notamment entre ArcGIS GeoBIM et Autodesk Construction Cloud, cherchent à établir un lien direct entre les modèles de conception et les entités géographiques. Le bénéfice est réel: une emprise de projet, une zone de travaux, une parcelle ou un ouvrage peut renvoyer vers la documentation et les modèles concernés sans conversion manuelle systématique.

Mais le raccordement ne vaut que si trois niveaux sont contrôlés.

1. Le géoréférencement

Un dessin CAO doit être positionné dans le bon système de référence. Cette phrase paraît élémentaire. Elle ne l’est pas dans les projets où coexistent coordonnées locales, Lambert, projection chantier et fonds externes.

Une translation arbitraire de quelques mètres ne se corrige pas avec un simple déplacement visuel dans le SIG. Il faut identifier l’origine de l’écart: unité, projection, faux point d’origine, rotation, système vertical ou erreur de transformation.

2. La sémantique des objets

Le calque « EU_PROJET » ne constitue pas un modèle de données. Il donne une indication. Pour intégrer une conduite projetée dans un SIG, il faut définir ses attributs: matériau, diamètre, gestionnaire, statut, profondeur éventuelle, date, source, précision et relation avec les ouvrages associés.

Sans cette structuration, le flux CAO-SIG produit une représentation lisible mais non exploitable pour la maintenance, l’analyse ou la diffusion réglementaire.

3. La responsabilité de la modification

Le lien entre un modèle Civil 3D et une couche SIG ne doit pas autoriser des écritures ambiguës. Qui corrige la géométrie de l’axe? Qui modifie le diamètre? Quelle version fait foi pour l’exécution? Quel état est seulement provisoire?

Le cloud facilite le partage. Il ne tranche pas la gouvernance. Sur un projet de topographie ou de VRD, cette distinction est non négociable: le modèle de conception, le récolement et le référentiel patrimonial ne sont pas le même objet, même lorsqu’ils occupent la même position planimétrique.

Les API OGC remplacent progressivement la logique du portail fermé

Le format ne suffit pas. Pour que les logiciels communiquent réellement, ils doivent aussi disposer d’interfaces d’accès stables. C’est le rôle des standards de l’Open Geospatial Consortium.

L’OGC a développé plus de 80 standards ouverts. La famille OGC API modernise les échanges web en s’appuyant sur des architectures REST, des descriptions OpenAPI et des formats légers comme JSON ou GeoJSON. Le principe est moins rigide que celui des anciens services souvent enfermés dans des paramétrages lourds et des réponses difficiles à intégrer hors d’un SIG spécialisé.

OGC API - Features permet d’exposer des objets géographiques de manière plus directement exploitable par une application métier, un portail cartographique ou un logiciel terrain. L’intérêt n’est pas esthétique. Il porte sur l’intégration.

Un outil de gestion de chantier peut consulter les emprises concernées. Une application de contrôle peut récupérer les équipements à inspecter. Un SIG peut publier une collection filtrable. Chaque système accède à la même donnée sans imposer un export manuel à chaque usage.

La publication en 2025 de la norme OGC API - Connected Systems étend cette logique aux systèmes connectés. Dans le domaine de la topographie, le potentiel concerne les capteurs, les flux de mesures et les observations liées à un contexte spatial. Il faut rester précis: une API ne transforme pas un récepteur GNSS en source métrologiquement fiable. Elle organise la diffusion de ses informations.

L’API ne dispense pas du contrôle de structure

Un service ouvert peut diffuser rapidement une erreur. C’est sa force et son danger.

Avant d’exposer une couche par API, il faut fixer:

1. les identifiants pérennes des entités;

2. les attributs obligatoires et leurs domaines de valeurs;

3. les règles de mise à jour, de suppression et d’archivage;

4. les systèmes de coordonnées autorisés;

5. les niveaux d’accès selon les utilisateurs;

6. la traçabilité des modifications.

Sans cela, l’interopérabilité devient une circulation sans contrôle. Un objet est visible partout, mais personne ne sait quelle version utiliser ni comment interpréter son niveau de précision.

EDIGéO, GeoPackage, DWG: la coexistence est la réalité

La modernisation des flux ne fait pas disparaître les formats historiques. En France, EDIGéO, homologuée par l’AFNOR sous la référence Z 52 000 en 1992, reste présente dans les échanges cadastraux et dans de nombreux systèmes institutionnels. Le Shapefile conserve également une place considérable. Le DWG et le DXF restent indispensables dans les environnements de conception et de production topographique.

Les déclarer obsolètes serait techniquement faux. Le problème n’est pas leur âge. Le problème est leur usage exclusif dans un contexte où les données doivent être consultées par plusieurs outils, plusieurs services et parfois plusieurs organisations simultanément.

Le GeoPackage occupe ici une position pragmatique. Il permet de livrer un ensemble géographique structuré dans un fichier unique, sans dépendre de plusieurs fichiers associés comme le Shapefile. Il reste adapté au travail déconnecté, aux échanges formels et aux projets dont la volumétrie ne justifie pas une architecture de services.

La stratégie efficace n’est donc pas de choisir un format universel. Il n’existe pas. Elle consiste à répartir les rôles:

Cette coexistence impose une discipline de transformation. Un export ne doit jamais être considéré comme neutre. Lorsqu’un levé GNSS passe dans un logiciel SIG, puis dans une DAO topographie, puis dans une base patrimoniale, chaque conversion doit préserver ou documenter:

• les coordonnées et l’altitude;
• les unités;
• les attributs métier;
• les identifiants;
• la date et la source du relevé;
• le niveau de précision ou de confiance;
• les règles topologiques appliquées.

La donnée qui ne transporte plus son contexte devient une simple géométrie. Pour un topographe, c’est insuffisant.

Le verdict: viable, mais sous conditions

Le cloud change réellement l’interopérabilité des logiciels SIG et de topographie. Les COG, GeoParquet et COPC réduisent le coût du déplacement de données massives. Les plateformes synchronisées raccourcissent le trajet entre le terrain GNSS et le bureau. Les API OGC rendent les services géographiques plus intégrables. Les connecteurs CAO-SIG réduisent les ressaisies.

Le verdict reste binaire.

Une architecture cloud est viable si elle conserve le système de référence, la précision de mesure, les identifiants et la responsabilité de chaque modification. Elle doit fonctionner en mode déconnecté là où le terrain l’impose. Elle doit distinguer le référentiel validé, la conception et le levé brut. Elle doit aussi accepter la coexistence d’EDIGéO, de GeoPackage, de DWG et des formats cloud-native.

Si le projet se limite à déposer des fichiers dans un espace partagé, le cloud ne change rien de fondamental. Il accélère seulement la diffusion des incohérences.