QField vs Mergin Maps : différences et choix sur le terrain

QField vs Mergin Maps: différences et choix sur le terrain

Le problème ne vient alors pas forcément du récepteur GNSS ou de la tablette. Il vient souvent d'un choix d'architecture et d'ergonomie qui ne correspond pas à la réalité du chantier.

QField et Mergin Maps comptent parmi les applications open source les plus utilisées pour la collecte de données SIG sur mobile. Toutes deux s'inscrivent dans l'écosystème QGIS, prennent en charge le travail hors connexion et peuvent être associées à un récepteur GNSS externe. Pourtant, elles ne proposent pas la même manière de préparer un projet, de le distribuer, de saisir les données et de récupérer les modifications.

La question « qfield ou mergin maps sur le terrain » ne se résume donc pas à une comparaison de fonctionnalités. Elle concerne surtout l'organisation de l'équipe: qui prépare les projets, comment les appareils sont déployés, où les données sont stockées et quel niveau d'autonomie on attend des opérateurs.

Philosophie de synchronisation: approche cloud contre transfert local

C'est le point de séparation le plus visible entre les deux solutions, et souvent celui qui influence le plus le quotidien.

Mergin Maps s'appuie principalement sur son service cloud ou sur une instance serveur auto-hébergée pour distribuer les projets et synchroniser les données. L'application mobile récupère le projet avant le départ, permet de travailler hors connexion, puis envoie les modifications lorsque la connexion est disponible. Cette logique évite de brancher chaque téléphone à un ordinateur pour copier manuellement les fichiers.

Le fonctionnement est particulièrement cohérent lorsqu'une équipe travaille sur plusieurs sites, avec des opérateurs qui ne repassent pas systématiquement au bureau. Le responsable du projet peut préparer une version de référence, la rendre accessible aux utilisateurs concernés et centraliser les remontées dans un même espace. Il faut en revanche prévoir les comptes, les droits d'accès et l'infrastructure de synchronisation adaptée au contexte.

QField propose historiquement une approche plus locale. Les projets QGIS et leurs données peuvent être transférés directement entre l'ordinateur et le mobile, notamment par câble USB. QField dispose également d'une voie de synchronisation cloud avec QFieldCloud, mais elle n'est pas indispensable pour les usages où le transfert local suffit. On peut donc préparer un projet dans QGIS, connecter l'appareil, copier les données et partir sur le terrain sans mettre en place de serveur distant.

Cette méthode est moins confortable dès que le nombre d'appareils augmente, mais elle reste très lisible. Dans une petite structure, sur une mission ponctuelle ou dans un environnement informatique fermé, le transfert local peut être préférable à l'ajout d'un service en ligne. Il fonctionne aussi dans un bureau dépourvu de Wi-Fi opérationnel ou lorsque la politique de sécurité du client limite les échanges avec des plateformes externes.

Le choix entre cloud et transfert local n'est pas seulement technique: il détermine la façon dont l'équipe prépare, distribue et récupère ses données.

La comparaison entre Mergin Maps et QField doit donc tenir compte du moment où la connexion intervient. Les deux applications savent travailler hors ligne, mais elles ne demandent pas la même discipline:

• avec Mergin Maps, la synchronisation est pensée comme une étape naturelle du cycle de vie du projet;
• avec QField en transfert local, il faut davantage contrôler les copies, les versions et le retour des appareils;
• avec QFieldCloud, une partie de cette gestion est centralisée, mais l'équipe ajoute alors une infrastructure cloud à son environnement de travail;
• dans les deux cas, le projet doit être préparé correctement avant le départ: couches éditables, formulaires, droits, fonds de plan et système de coordonnées.

Le cloud ne supprime pas les contraintes de terrain. Une équipe peut toujours perdre du temps si les utilisateurs n'ont pas téléchargé le bon projet, si les droits sont mal configurés ou si la synchronisation est lancée au mauvais moment. De son côté, le transfert USB n'est pas nécessairement archaïque: il peut être une solution robuste lorsqu'un référent maîtrise le projet et que les opérateurs travaillent sur des périmètres bien définis.

Interface utilisateur et gestion des modes de saisie

L'interface est le point de contact entre la logique du projet QGIS et l'opérateur qui doit saisir une information rapidement. Sur le terrain, une fonction supplémentaire n'a de valeur que si elle reste compréhensible dans des conditions peu favorables: écran réduit, gants, pluie, soleil direct ou attention concentrée sur l'environnement.

QField conserve une relation étroite avec la logique de QGIS. L'utilisateur navigue dans les couches, consulte les objets et bascule dans un mode d'édition pour créer ou modifier des entités. Cette séparation protège contre certaines erreurs: le simple fait de déplacer la carte ou d'ouvrir une fiche ne déclenche pas automatiquement une modification.

En contrepartie, l'opérateur doit comprendre dans quel mode il se trouve. Un utilisateur habitué à QGIS appréciera cette continuité. Un agent qui découvre la cartographie mobile peut, lui, chercher pourquoi un bouton est inactif ou pourquoi aucune nouvelle entité ne peut être créée. La difficulté n'est pas insurmontable, mais elle doit être prise en compte dans la formation et dans la conception du projet.

Mergin Maps adopte une interaction plus directe. L'application cherche à réduire la distance entre la carte et le formulaire: sélectionner un objet conduit rapidement à sa fiche, tandis qu'une action sur la carte permet de créer une nouvelle entité lorsque la couche est configurée pour cela. Cette approche est souvent plus accessible pour des équipes mixtes, dont les membres n'utilisent pas QGIS au quotidien.

Cette simplicité ne signifie pas que Mergin Maps dispense de préparer les formulaires. Au contraire, plus l'interface est dépouillée, plus le projet doit guider correctement l'opérateur. Les champs obligatoires, les listes de valeurs, les valeurs par défaut, les contrôles de cohérence et l'ordre des questions ont une influence directe sur la qualité de la donnée produite.

Dans un projet de relevé, la différence se manifeste souvent dans les premières heures de formation. Une équipe qui maîtrise déjà QGIS n'aura pas forcément besoin de réapprendre la logique de QField. À l'inverse, des techniciens réseau, des agents communaux ou des opérateurs de maintenance peuvent entrer plus rapidement dans Mergin Maps si le formulaire est bien conçu.

Il faut aussi regarder la nature des tâches. Pour une collecte ponctuelle avec peu de champs, une interface directe est généralement un avantage. Pour un projet où l'opérateur doit alterner entre consultation de nombreuses couches, modification contrôlée et vérification de géométries, les modes de QField peuvent apporter une sécurité supplémentaire.

L'ergonomie ne se résume donc pas à l'apparence de l'écran. Elle comprend la façon dont l'application empêche les erreurs, signale les données manquantes et accompagne l'utilisateur jusqu'à l'enregistrement définitif.

Architecture technique: le moteur geodiff face à la flexibilité de QGIS

Sous le capot, les deux outils ne traitent pas les modifications de la même manière. Cette différence devient importante lorsque les projets contiennent beaucoup de données ou que plusieurs opérateurs interviennent sur un même ensemble de couches.

Mergin Maps utilise geodiff, un moteur open source destiné à comparer et fusionner des modifications apportées à des données géographiques. Au lieu de considérer le fichier comme un bloc indivisible à recopier, le système identifie les changements intervenus et peut transmettre des différences, ou deltas. La synchronisation est ainsi plus ciblée qu'un remplacement systématique de l'ensemble du fichier.

Cette architecture facilite le travail collaboratif. Elle permet notamment de mieux repérer les modifications réalisées depuis la dernière synchronisation et de traiter les situations dans lesquelles deux versions ont évolué en parallèle. Elle ne rend toutefois pas les conflits impossibles. Deux opérateurs qui modifient le même objet, les mêmes attributs ou une géométrie commune peuvent toujours produire une situation nécessitant une vérification ou un arbitrage.

Geodiff rapproche la synchronisation des données géographiques d'une logique de versions: on suit les changements au lieu de remplacer systématiquement tout le fichier.

QField, utilisé avec un transfert local classique, repose sur une logique plus simple à expliquer: le projet est copié sur l'appareil, puis récupéré après la mission. Cette méthode peut très bien convenir à un usage individuel ou à une organisation dans laquelle chaque opérateur travaille sur un secteur distinct. Elle devient plus exigeante lorsque plusieurs copies d'un même projet circulent en parallèle.

Dans ce cas, la question n'est pas seulement celle du volume de données. Même un projet relativement léger peut devenir difficile à consolider si plusieurs personnes modifient la même couche sans règle de nommage, sans journal de versions et sans procédure de retour. Inversement, un projet lourd peut rester gérable si les rôles sont clairement définis et si les fonds de plan ne sont pas inutilement dupliqués.

La gestion des deltas de Mergin Maps peut réduire les transferts et faciliter la fusion des modifications, mais elle ne remplace pas une organisation de projet. Sur une mission avec de nombreux opérateurs qui saisissent dans les mêmes couches, elle peut rendre les conflits plus visibles et leur traitement plus structuré. Elle ne garantit pas l'absence d'écrasement ou de doublon: la structure des données et les habitudes de l'équipe restent déterminantes.

Les formats pris en charge ne départagent pas toujours les deux applications. Les projets peuvent s'appuyer sur des formats courants comme GeoPackage, PostGIS, ESRI Shapefile, DXF, CSV ou KML, selon la configuration retenue et les besoins du projet. Le véritable sujet est plutôt la manière dont ces données sont préparées et éditées.

Le GeoPackage constitue souvent un choix pratique pour un projet mobile, mais il ne suffit pas de déposer une base sur le téléphone. Il faut également vérifier les noms de champs, les types d'attributs, les valeurs nulles, les relations entre tables, les règles de saisie et les pièces jointes. Une base bien structurée réduit davantage les reprises de bureau qu'une application choisie uniquement pour son interface.

Les couches lourdes et les pièces jointes

Les orthophotographies, les modèles numériques de terrain, les photographies et les documents associés modifient également le comportement du projet. Une synchronisation par différences est particulièrement intéressante lorsque les opérateurs ne modifient qu'une petite partie d'une base volumineuse. Elle ne transforme pas pour autant une connexion instable en connexion fiable: la première récupération du projet et l'envoi de fichiers lourds peuvent rester longs.

Dans QField comme dans Mergin Maps, il est utile de séparer ce qui doit être consulté de ce qui doit être modifié. Les fonds de plan peuvent être préparés en amont, tandis que les couches de collecte restent limitées aux objets et attributs réellement nécessaires. Cette préparation améliore la réactivité de l'application et réduit les risques de manipulation inutile sur le terrain.

Intégration GNSS et précision des relevés sur le terrain

Pour un logiciel terrain de topographie, la connexion à l'antenne GNSS est un point essentiel, mais elle ne suffit pas à garantir la qualité du relevé. La précision finale dépend du récepteur, des corrections disponibles, de la méthode de levé, de l'environnement et du paramétrage du projet.

QField et Mergin Maps peuvent être associés à des récepteurs GNSS externes via Bluetooth. Des équipements de fabricants comme Emlid, Trimble, Leica ou Septentrio peuvent transmettre leur position à l'application, généralement au moyen de trames NMEA ou d'une configuration équivalente. La compatibilité concrète dépend toutefois du modèle, du profil Bluetooth, du flux de données et des paramètres choisis.

Il faut distinguer trois éléments:

1. La réception de la position. L'application doit recevoir correctement les données envoyées par le récepteur et afficher un état compréhensible pour l'opérateur.

2. Le système de coordonnées. Le projet doit utiliser le bon SCR, avec les paramètres adaptés au territoire et au mode de correction employé.

3. La règle d'acceptation du point. L'équipe doit savoir dans quelles conditions un point peut être enregistré: qualité du fix, indicateurs DOP, précision annoncée, stabilité de la mesure ou nombre d'observations.

QField, dans la continuité de QGIS, expose un ensemble de paramètres qui peut convenir à des utilisateurs souhaitant contrôler finement leur environnement de mesure. Le choix du système de coordonnées, les informations liées aux satellites, certains indicateurs de qualité et les conditions d'enregistrement peuvent être intégrés au flux de travail selon la configuration du projet.

Mergin Maps cherche davantage à simplifier l'accès aux réglages essentiels. Cette approche convient à un inventaire ou à une campagne de collecte où l'opérateur doit surtout confirmer que la position reçue est exploitable. Pour un levé qui impose une tolérance stricte, la question est moins celle de l'application que celle de la manière dont le protocole de mesure est traduit dans le formulaire et les consignes de terrain.

Une application peut recevoir une position très précise et enregistrer malgré tout un point mal contrôlé. Cela arrive si l'opérateur ne vérifie pas le statut de la correction, s'il prend le point trop près d'un obstacle ou si le projet applique une transformation incorrecte. À l'inverse, un inventaire de mobilier urbain n'a pas les mêmes exigences qu'un relevé destiné à alimenter un dossier de bornage.

La préparation dans QGIS reste donc déterminante. Avant de distribuer le projet, il faut vérifier:

• le système de coordonnées du projet et celui des couches;
• les paramètres de transformation nécessaires;
• les champs destinés à conserver les informations de qualité GNSS;
• la possibilité de distinguer une position autonome d'une position corrigée;
• le comportement de l'application lorsque la précision attendue n'est pas atteinte;
• la présence éventuelle d'une photo ou d'un commentaire justifiant une mesure particulière.

QField peut donner davantage de visibilité aux utilisateurs expérimentés. Mergin Maps peut réduire le nombre de réglages exposés à un opérateur qui n'a pas vocation à administrer la chaîne GNSS. Dans les deux cas, il serait imprudent de présenter l'application comme la source de la précision: elle enregistre et affiche une mesure produite par l'ensemble du dispositif.

Critères de sélection selon le profil des opérateurs

Il n'existe pas de vainqueur général dans le comparatif QField Mergin Maps. Les deux outils répondent à des organisations différentes, même si leurs fonctions se recouvrent largement.

Le premier critère est le niveau de familiarité avec QGIS. Une équipe de géomaticiens ou de topographes qui prépare déjà ses projets dans QGIS peut apprécier la continuité de QField. Les mêmes concepts, les mêmes couches et une partie des mêmes habitudes se retrouvent sur le mobile. Cela ne dispense pas d'une formation, mais réduit le décalage entre le bureau et le terrain.

Pour une équipe plus hétérogène, Mergin Maps peut offrir une entrée plus progressive. L'opérateur n'a pas besoin de connaître toute la logique de QGIS pour remplir un formulaire correctement. Cette facilité dépend néanmoins du travail réalisé en amont: un formulaire trop long, des champs mal nommés ou des valeurs mal configurées recréeront de la complexité dans l'application.

La synchronisation doit ensuite être évaluée selon le fonctionnement réel de la structure:

• Petite équipe, missions ponctuelles et environnement fermé: QField avec transfert local peut rester la solution la plus simple, à condition de contrôler les copies et les retours de terrain.
• Équipe répartie sur plusieurs sites: Mergin Maps apporte une organisation plus naturelle autour d'un espace partagé, sous réserve d'une connexion disponible au moment des échanges.
• Structure déjà équipée d'une solution cloud compatible: QFieldCloud ou un serveur Mergin Maps peuvent s'intégrer au système existant, mais il faut examiner les droits, les sauvegardes et les règles de sécurité.
• Travail fréquent en zone blanche: les deux applications permettent de collecter hors ligne; la différence se situe surtout dans la préparation et dans la procédure de synchronisation différée.
• Projet collaboratif sur des couches communes: les deltas de Mergin Maps peuvent faciliter le suivi et la fusion, sans supprimer la nécessité de répartir les responsabilités et de traiter les conflits.

Le nombre d'opérateurs n'est pas un critère suffisant à lui seul. Dix personnes travaillant chacune sur une zone séparée ne posent pas le même problème que trois personnes modifiant les mêmes objets. Dans le second cas, il faut documenter les règles de saisie, la fréquence de synchronisation et le traitement des doublons ou des modifications concurrentes.

Le budget et les compétences informatiques entrent également en ligne de compte. QField peut être déployé sans serveur lorsqu'un transfert local répond au besoin. Mergin Maps demande généralement un compte sur son service cloud ou une instance auto-hébergée. Cette dernière option donne davantage de contrôle, mais elle implique aussi l'administration du serveur, la gestion des utilisateurs, les sauvegardes et la surveillance du service.

Le type de données collectées complète le tableau. Des relevés composés principalement de points et de quelques attributs restent faciles à transférer dans les deux environnements. Des projets comportant beaucoup de photographies, des documents associés ou des fonds de plan volumineux demandent une préparation plus attentive. Le delta limite les changements à transmettre lorsqu'il s'applique, mais les pièces jointes doivent malgré tout être transférées. Une stratégie de compression, de nommage et de tri peut alors avoir autant d'impact que le choix de l'application.

Le bon outil n'est pas celui qui affiche le plus de fonctions: c'est celui dont le fonctionnement reste clair lorsque l'équipe est loin du bureau.

QField ou Mergin Maps: quel choix pour un projet de topographie?

Pour un projet de topographie ou de collecte SIG, le choix peut être résumé ainsi, sans transformer cette synthèse en classement définitif.

QField est souvent pertinent lorsque:

• le projet est conçu et maintenu par des utilisateurs réguliers de QGIS;
• le transfert local est acceptable pour l'organisation;
• l'équipe souhaite limiter la dépendance à un service distant;
• les opérateurs doivent disposer d'un contrôle détaillé sur l'affichage et les réglages;
• les missions sont individuelles ou réparties sur des secteurs clairement séparés;
• une procédure interne de copie, de sauvegarde et de retour des données existe déjà.

Mergin Maps est souvent pertinent lorsque:

• le projet doit être distribué à plusieurs opérateurs sans passer systématiquement par un ordinateur;
• la synchronisation centralisée correspond à l'organisation de l'équipe;
• les utilisateurs ont des niveaux différents en SIG;
• les modifications doivent être suivies et fusionnées entre plusieurs appareils;
• le responsable accepte de s'appuyer principalement sur un service cloud ou sur une instance serveur;
• les formulaires et les règles de saisie peuvent être préparés avec soin dans QGIS.

Il faut éviter de choisir sur la seule base de la présence d'un bouton ou d'un format. Le test le plus instructif consiste à reproduire le cycle complet: préparation du projet, téléchargement ou copie, travail sans réseau, ajout de photos, modification d'un même objet depuis plusieurs appareils, synchronisation, résolution d'un conflit et contrôle final dans QGIS.

Cette procédure révèle rapidement les difficultés réelles. Une application peut sembler très accessible jusqu'au moment où l'opérateur doit reprendre une modification interrompue. Un projet peut se synchroniser correctement avec une seule personne et devenir plus délicat lorsque plusieurs utilisateurs éditent la même couche. Le bon choix est celui qui reste maîtrisable dans ces situations, pas seulement celui qui fonctionne lors d'une démonstration.

QField et Mergin Maps continuent d'évoluer, et leurs périmètres tendent à se rapprocher. QField peut s'inscrire dans une organisation cloud grâce à QFieldCloud, tandis que Mergin Maps conserve une logique de collecte hors connexion une fois le projet téléchargé. La différence ne tient donc pas à une opposition simpliste entre une application en ligne et une application hors ligne. Elle tient à la façon dont chacune organise le projet avant, pendant et après la mission.

Pour trancher entre Mergin Maps et QField, il faut partir des opérateurs, du réseau disponible et du niveau de contrôle attendu. Une équipe autonome, très à l'aise avec QGIS et habituée à gérer ses fichiers, trouvera souvent dans QField une continuité efficace. Une équipe répartie, composée de profils variés et engagée dans des campagnes collaboratives, pourra préférer Mergin Maps pour sa synchronisation structurée et son interface plus directe.

Dans les deux cas, la qualité du résultat dépendra d'abord du projet QGIS, du protocole GNSS et de la discipline de l'équipe. L'application facilite le travail; elle ne remplace ni la préparation, ni la vérification des mesures, ni les règles de gestion des données.