Collecte de données SIG : 5 fonctions terrain indispensables

Sur le terrain, la promesse d'un SIG se joue rarement au bureau. Elle se joue dans la poche de l'opérateur, au moment où la cellule 4G décroche au fond d'une vallée, où l'antenne RTK se désappaire du smartphone en plein levé, où un agent saisit « regard » au lieu de « REGARD_EU » parce que la liste conditionnelle n'apparaît pas. Les architectes de bases de données spatiales connaissent ces scénarios par cœur: c'est précisément à ce point de capture que se déterminent la topologie, la sémantique et la précision géométrique de chaque entité — et donc la fiabilité de toutes les requêtes spatiales qui seront exécutées en aval.

Choisir un logiciel de collecte de données SIG pour le terrain ne revient pas à comparer des fiches produit. Il s'agit d'arbitrer cinq fonctions systémiques qui conditionnent la fluidité du flux de données, depuis le point GNSS jusqu'à la jointure SQL qui croisera l'entité avec le référentiel cadastral ou le réseau technique. Voici les cinq piliers qu'aucune architecture de données géospatiales ne peut aujourd'hui négliger.

« Une application terrain n'est pas un formulaire mobile: c'est le premier maillon d'un pipeline dont chaque maillon suivant hérite des défauts de saisie. »

Mode hors ligne: la résilience comme prérequis du flux

La première caractéristique d'une application de collecte digne de ce nom est son mode offline-first. Toute autre considération perd son sens si l'opérateur ne peut pas continuer à travailler lorsque la couverture réseau fait défaut — ce qui reste la norme sur la majorité des chantiers de topographie, des zones forestières, des périmètres miniers ou des opérations de levé de réseaux en milieu urbain dense.

Concrètement, cela signifie que l'application embarque sa propre base de données locale (généralement SQLite ou GeoPackage) et y stocke chaque entité avec ses attributs, ses pièces jointes et sa géométrie. La synchronisation vers le serveur central n'intervient qu'au retour de connexion, qu'elle soit déclenchée manuellement ou automatisée selon des règles de connectivité. QField, Mergin Maps, Locus GIS et ArcGIS Field Maps reposent toutes sur ce paradigme, ce qui les distingue des simples webapp incapables de fonctionner sans serveur accessible.

Du point de vue architectural, cette approche transforme le terminal mobile en nœud de base de données distribué. Chaque opérateur porte ainsi sa propre version cohérente du projet, et la phase de synchronisation implémente une logique de fusion — résolution de conflits, gestion des versions, horodatage — qui n'a rien d'anodin dès que plusieurs agents travaillent sur la même zone. C'est pourquoi le choix d'une solution doit intégrer non seulement la capacité hors ligne, mais la robustesse de son algorithme de merge.

Précision centimétrique: coupler l'application au récepteur GNSS externe

Le GPS intégré d'un smartphone grand public délivre une précision horizontale de l'ordre de 3 à 10 mètres. Inacceptable pour un levé topographique, un référencement de réseau enterré ou une opération de bornage. La deuxième fonction indispensable est donc la capacité de l'application à se coupler, via Bluetooth ou USB, à un récepteur GNSS externe délivrant une précision centimétrique en mode RTK ou PPK.

Les solutions matures du marché exposent cette intégration comme un service de positionnement interne: l'application dialogue avec le récepteur, récupère le flux NMEA ou la position corrigée, et associe la géométrie à chaque entité saisie. QField et Mergin Maps supportent nativement les protocoles NTRIP et les principaux fabricants (Trimble, EMLID, CHCNAV, Sokkia). LandStar 8 de CHCNAV, dont la version 8.1 publiée le 29 mai 2024 ajoute le guidage 3D et le support natif des fichiers CAO pour terminaux Android, pousse plus loin l'intégration en proposant une chaîne complète de collecte, de guidage et d'export DAO directement embarquée sur le contrôleur de terrain.

Cette fonction n'est pas un confort: elle inscrit la précision géométrique dans un contrat de qualité opposable. Une couche d'objets ponctuels saisie à 5 mètres de tolérance ne pourra jamais être croisée avec un référentiel cadastral au centimètre près, et c'est la base de données entière qui en héritera la dégradation.

« Sans couplage GNSS externe, le SIG mobile n'est qu'un tableur géolocalisé — utile pour de l'inventaire, insuffisant pour de la topographie. »

Formulaires intelligents: structurer la saisie pour fiabiliser la base

Troisième pilier, et sans doute le plus sous-estimé: la capacité de l'application à imposer une structure de saisie cohérente avec le modèle de données cible. Un formulaire « intelligent » ne se limite pas à proposer des champs à remplir; il contraint la sémantique de la donnée dès le point de capture.

Les fonctionnalités clés incluent:

• listes déroulantes liées à des nomenclatures de référence (métiers, matériaux, états) pour éliminer les saisies libres divergentes;
• visibilité conditionnelle, qui n'affiche un champ que si la réponse précédente le justifie (type de regard → diamètre → matériau);
• calculs automatiques entre champs (surface = longueur × largeur, conversion d'unités), supprimant les erreurs arithmétiques;
• lecture de codes QR ou codes-barres, précieuse pour référencer des équipements pré-identifiés ou suivre des actifs de chantier.

QGIS permet de concevoir ces formulaires directement depuis la couche de saisie; ArcGIS Field Maps Designer offre l'équivalent côté Esri. L'ensemble de l'écosystème mature — Mergin Maps, QField, Locus GIS — applique la même philosophie: structurer la saisie en amont revient à intégrer la validation au plus près de la source, un principe fondamental en gouvernance de données qui évite l'empilement de scripts de nettoyage côté serveur. La sophistication se joue ensuite dans les détails: ergonomie du clavier contextuel, gestion des valeurs par défaut, déclenchement d'alertes sur seuils critiques, conservation des géométries provisoires en mode brouillon. Ce sont ces détails qui distinguent une simple application de formulaires d'un véritable outil de production SIG.

Capture multimédia: enrichir l'entité pour réduire l'ambiguïté

Une entité géographique n'est presque jamais pleinement décrite par ses seules coordonnées et ses attributs tabulaires. Le quatrième pilier fonctionnel est la capture de pièces jointes multimédias directement attachées à la géométrie: photos géoréférencées, enregistrements audio, vidéos de contexte, croquis manuscrits sur fond de carte.

Locus GIS, Mergin Maps et QField intègrent nativement cette capacité. L'intérêt architectural est double. D'une part, la pièce jointe constitue une preuve documentaire qui documente la décision de terrain et résout les ambiguïtés lors d'un audit ultérieur. D'autre part, elle enrichit le modèle relationnel de la base en autorisant des requêtes multimédias (« tous les regards dont la photo montre une fissure ») qui dépassent la simple jointure attributaire.

La profondeur de l'intégration varie selon les solutions: certaines stockent les pièces jointes en chemin relatif dans le GeoPackage, d'autres s'appuient sur un stockage objet externe avec lien synchrone. Cette dernière option pèse sur le budget de synchronisation, mais garantit l'intégrité des pièces jointes lourdes — critère non négligeable pour les campagnes de levé photographique systématique, où chaque entité peut être accompagnée de plusieurs clichés contextuels et où la rupture d'un lien suffit à transformer une archive de référence en donnée inutilisable.

Une organisation qui néglige cette fonction se condamne à revenir sur site dès qu'un doute surgit — un surcoût opérationnel considérable, là où une photo correctement horodatée et géolocalisée aurait suffi à clore la question.

Synchronisation cloud: gouvernance et distribution des versions

Le cinquième pilier articule les quatre précédents dans une logique collaborative. La synchronisation cloud n'est pas un confort de sauvegarde: elle est l'implémentation d'une politique de gouvernance des données géographiques, qui contrôle qui saisit quoi, qui relit les modifications, et comment les versions se propagent entre les nœuds du système.

Les plateformes de référence — QFieldCloud, Mergin Cloud, ArcGIS Online — proposent:

• une gestion fine des droits (lecture seule pour le prestataire, écriture pour l'opérateur interne, administration pour le chef de projet);
• une distribution de tâches par zone ou par type d'objet, ce qui permet d'orchestrer des campagnes multi-équipes;
• un historique de versions comparable à un version control logiciel, avec possibilité de retour arrière.

QFieldCloud offre une base gratuite limitée à 100 Mo de stockage par projet, ce qui convient aux opérations ponctuelles mais oblige les structures récurrentes à basculer vers un forfait adapté. Mergin Maps revendique plus de 100 000 utilisateurs collaboratifs sur sa plateforme, et Fulcrum démarre à 15 USD par mois et par utilisateur pour son plan de base. L'enjeu économique n'est donc pas neutre, et il doit être intégré à l'arbitrage dès la phase de cadrage.

Synthèse comparative des solutions

Le tableau ci-dessous résume les fonctions clés des principales applications étudiées. Il n'a pas vocation à être exhaustif — chaque éditeur enrichit sa matrice trimestre après trimestre — mais à fournir un repère d'arbitrage structuré.

Une remarque s'impose: l'écosystème iOS est incomplètement couvert. Locus GIS, par exemple, n'a pas d'application native iOS, ce qui exclut sa candidature pour les flottes de terrain équipées d'iPhone. Tout cahier des charges doit donc croiser la compatibilité terminale avec le périmètre fonctionnel attendu — sous peine de découvrir l'incompatibilité au moment du déploiement, lorsque les terminaux sont déjà commandés.

Recommandations d'architecture

Pour rationaliser le choix, trois critères systémiques méritent d'être hiérarchisés en amont du benchmark fournisseur.

D'abord, la cohérence du modèle de données. L'application terrain doit pouvoir consommer directement le schéma de couches défini dans le SIG de référence — sinon, chaque synchronisation introduit une transformation susceptible de briser la topologie ou de renormaliser les nomenclatures. Les outils open source (QGIS/QField, Mergin Maps sur PostGIS) facilitent cette continuité; les suites propriétaires (Esri) l'optimisent au prix d'une dépendance éditeur.

Ensuite, la gouvernance des versions et des conflits. Une équipe de cinq opérateurs travaillant en parallèle sur la même zone génère généralement des conflits de saisie. L'algorithme de merge de la plateforme cloud retenue doit être documenté, testé, et — idéalement — scriptable pour les cas particuliers.

Enfin, la traçabilité des modifications. Chaque géométrie, chaque attribut, chaque pièce jointe doit porter sa signature temporelle et son auteur, archivés de manière immuable. C'est la condition d'un audit trail conforme aux exigences métiers les plus strictes — on pense aux relevés d'infrastructures critiques, aux opérations de bornage foncier ou aux campagnes de géolocalisation d'ouvrages sensibles.

« Le bon logiciel de collecte n'est pas celui qui coche le plus de cases: c'est celui dont le modèle de données s'aligne sans couture avec celui de votre SIG maître. »

Une fois ces trois critères stabilisés, la sélection entre QField, Mergin Maps, Locus GIS, ArcGIS Field Maps ou Fulcrum devient un arbitrage de contexte — taille de l'équipe, couverture offline dominante, contraintes budgétaires, intégration à un existant Esri ou PostGIS. À structure comparable, l'open source (QField, Mergin Maps) offre la meilleure interopérabilité à long terme, tandis que les solutions propriétaires maximisent l'ergonomie au prix d'une dépendance contractuelle.

L'essentiel reste de ne jamais dissocier la décision logicielle de l'architecture de données sous-jacente: un outil de collecte superbe sur un modèle relationnel mal conçu restera un puits à données incohérentes, et c'est précisément ce défaut que toute équipe SIG cherche à éliminer en rationalisant ses flux terrain.