QField sur le terrain : configuration pas à pas

QField sur le terrain: configuration pas à pas

Or, dans la majorité des missions topographiques que nous observons, le point de rupture se situe précisément à l'articulation entre QGIS Desktop et l'application mobile: couches mal empaquetées, formulaires trop permissifs, précision GNSS sous-exploitée, synchronisations qui s'éparpillent. La chaîne logicielle QGIS + QFieldSync + QField résout ce passage, à condition d'en maîtriser chaque maillon plutôt que de se contenter d'un export brut. Ce guide condense l'architecture d'un déploiement de collecte conforme aux usages professionnels: du paramétrage des couches jusqu'au choix d'une stratégie de synchronisation.

Préparation du projet dans QGIS: l'extension QFieldSync

Toute configuration QField démarre dans QGIS, et ce n'est pas une contrainte arbitraire: c'est précisément ce qui garantit la cohérence du modèle entre la phase de conception et la phase opérationnelle. L'extension QFieldSync, maintenue par OPENGIS.ch en partenariat avec Oslandia, constitue le point d'entrée unique. Elle s'installe comme n'importe quel plugin officiel et fait apparaître un nouveau panneau latéral dans QGIS qui récapitule la structure du paquetage mobile.

L'idée directrice est simple: on ne « pousse » pas un projet QGIS vers QField comme on copierait un fichier, on définit pour chaque couche un comportement de déploiement. QFieldSync expose à ce titre quatre actions, qu'il faut choisir explicitement par couche:

Cette granularité est ce qui distingue un déploiement raisonné d'un simple copier-coller. Une couche cadastrale de référence n'a aucune raison d'être éditable sur le terrain; un fond raster MBTiles non plus. En revanche, la couche d'auscultation des ouvrages doit impérativement basculer en Offline Editing pour permettre la saisie d'attributs, de photos et de géométries, puis redescendre vers la base source. Ce typage par couche est la première décision architecturale du projet, et c'est elle qui détermine la taille du paquetage, le volume de données à synchroniser, et in fine les performances de l'application sur le terminal.

Avant l'export, deux vérifications systématiques s'imposent: la projection du projet doit être définie explicitement (QField n'hérite pas toujours du SCR par défaut si le fichier est composé de couches hétérogènes), et les relations entre couches — notamment celles exploitant les formulaires) doivent être testées au bureau. Une relation mal résolue au desktop sera une relation invisible au terrain.

Gestion des couches et formulaires de saisie mobile

Le formulaire de saisie est l'interface contractuelle entre l'opérateur terrain et le modèle de données. Trop souvent, on transpose au mobile des formulaires QGIS standards, avec leurs champs libres et leurs valeurs par défaut absentes, et l'on découvre au moment de la collecte que les agents saisissent du texte approximatif là où l'on attendait un identifiant normalisé. QField applique tels quels les formulaires conçus dans QGIS, ce qui est à la fois une force et une responsabilité: tout ce qui est mal défini au bureau sera mal collecté au terrain.

Les widgets utilisables couvrent l'essentiel des besoins professionnels: listes de valeurs (idéalement chargées depuis une table de référence ou un domaine PostGIS), champs à valeurs par défaut, champs obligatoires validés à la soumission, champs date/heure avec incrustation automatique de la position et des coordonnées au moment de la saisie. Pour les relevés photographiques, l'application permet la capture photo directement liée à l'entité, avec géotag automatique: chaque photo hérite de la position courante, du cap GNSS lorsque le récepteur le fournit, et de l'horodatage. Ces métadonnées ne sont pas décoratives — elles sont ce qui rend la pièce jointe opposable dans une chaîne de contrôle qualité.

Pour les couches raster, QField gère nativement le GeoPackage (.gpkg), MBTiles, GeoTIFF, et les tuiles XYZ. Le choix n'est pas anodin: un MBTiles pré-tuilé pèse souvent dix fois moins que l'assemblage équivalent en GeoTIFF, et c'est ce format qui permet d'embarquer un fond cartographique complet sur un téléphone de terrain sans recourir au réseau mobile. À titre indicatif, le modèle numérique de terrain mondial Mapzen utilisé par défaut pour le rendu 3D dans QField offre une résolution de 30 mètres: suffisante pour la lecture topographique générale, insuffisante pour un calcul de pente. Depuis QField 4.1, il est désormais possible d'embarquer un MNT GeoTIFF local, ce qui ouvre la voie à un rendu de relief haute résolution entièrement hors ligne.

Connexion GNSS haute précision et configuration NTRIP

La précision géométrique d'un relevé dépend entièrement de la chaîne d'acquisition GNSS, et QField se positionne ici comme un intégrateur plutôt que comme un moteur de calcul. L'application prend en charge la connexion directe à des récepteurs externes via trois protocoles: Bluetooth classique, Bluetooth Low Energy (BLE), et TCP sur réseau IP. Cette couverture permet d'utiliser aussi bien un récepteur Bluetooth compact qu'une station totale GNSS IP ou un récepteur RTK connecté au Wi-Fi du véhicule d'intervention.

La précision centimétrique n'est jamais gratuite: elle exige un récepteur RTK externe et un flux de corrections NTRIP correctement configuré. Sans ces deux briques, l'application ne peut pas faire mieux qu'une position métrique.

Le panneau de positionnement intégré à QField permet de paramétrer un caster NTRIP, c'est-à-dire le point d'entrée vers le service de corrections différentielles (réseau GNSS permanent, base privée, ou service commercial). On renseigne l'URL du caster, le port, le point de montage (mountpoint), les identifiants et, le cas échéant, le mode d'authentification. Une fois la liaison établie, l'application affiche en temps réel la qualité de la position: nombre de satellites, HDOP, mode de fix (single, DGPS, RTK fixe, RTK flottant). Cette information est déterminante: un opérateur qui voit son indicateur basculer en float doit comprendre que sa position n'est plus centimétrique, et c'est précisément la lisibilité de cet état qui fait la différence entre un relevé fiable et un relevé à recaler au bureau.

Pour les cabinets qui internalisent une base GNSS, le caster NTRIP peut être auto-hébergé (par exemple via rtklib ou un service SNIP), ce qui élimine la dépendance à un opérateur tiers et garantit la confidentialité des coordonnées. La question n'est pas idéologique mais opérationnelle: un flux de corrections qui s'interrompt en plein milieu d'un linéaire de 800 mètres produit une chaîne de points hétérogènes qu'aucun traitement postérieur ne pourra homogénéiser.

Géofencing et outils COGO: les avancées topographiques

Les versions récentes de QField ont introduit des fonctionnalités qui rapprochent l'application d'un véritable poste de saisie topographique, et non plus d'un simple visualiseur enrichi. Deux évolutions méritent une attention particulière.

La première est le géofencing, introduit avec QField 3.4 (version « Ebo », publiée le 8 octobre 2024). Ce cadre paramétrable depuis QFieldSync permet de définir des zones polygonales et trois comportements possibles: alerte lorsque l'opérateur entre dans la zone, alerte lorsqu'il en sort, ou simple information au franchissement de limite. L'usage typique est d'interdire la création d'objets en dehors d'un périmètre d'étude, ou à l'inverse d'alerter l'opérateur qu'il s'approche d'une zone sensible (proximité d'ouvrage, zone de servitude, périmètre réglementaire). Ce mécanisme peut être implémenté comme une couche dédiée dans le paquetage, ce qui rend la règle lisible et modifiable sans recompilation.

La seconde est la panoplie COGO (Coordinate Geometry) intégrée depuis QField 4.1 (déploiement du 18 juin 2026). Ces outils, longtemps réservés aux stations totales et aux logiciels de DAO topographique, couvrent les opérations classiques: calcul de distances entre sommets, génération de points par abscisse curviligne, implantation selon un angle et une distance, calculs d'azimut et de cheminement. Pour un géomètre-topographe qui souhaite implanter un point depuis un axe défini, ou pour un technicien qui doit vérifier la conformité d'un linéaire existant, cette intégration évite le retour systématique au bureau et l'usage d'un second logiciel. Combinée à la disponibilité d'un MNT local haute résolution, elle fait de QField un véritable outil de saisie topographique sur terminal mobile, et plus seulement un collecteur d'attributs géographiques.

Stratégies de synchronisation: QFieldCloud vs transfert manuel

Le dernier choix structurant concerne la chaîne de retour des données vers le système d'information source. Deux architectures coexistent, et le bon choix dépend du contexte opérationnel, pas d'une préférence par défaut.

Le transfert manuel par câble USB reste pertinent dans les configurations où le réseau mobile n'est pas fiable sur la zone d'étude — zones blanches, chantier souterrain, mission à l'étranger avec roaming coûteux. Le flux consiste à exporter un dossier de paquetage (.qgs ou.qgz) accompagné du GeoPackage modifié, puis à réintégrer les géométries et les attributs au projet QGIS source via l'extension QFieldSync côté bureau. Cette méthode est simple, auditable, et ne dépend d'aucune infrastructure tierce. Elle devient cependant laborieuse dès que plusieurs opérateurs interviennent en parallèle, car la consolidation suppose de fusionner manuellement les paquets.

La synchronisation cloud via QFieldCloud répond précisément à ce cas multi-opérateur. La plateforme, éditée par OPENGIS.ch, permet de pousser le projet depuis QGIS vers un espace partagé, puis de voir chaque terminal mobile se synchroniser à la demande sur ce même espace. Les conflits — deux opérateurs qui modifient la même entité — sont détectés et présentés à l'arbitrage. Pour les organisations qui disposent d'une couverture réseau suffisante, c'est l'option qui réduit le plus le risque de perte de données et qui accélère le cycle « relevé terrain / exploitation bureau ».

Le choix n'est pas exclusif. Une architecture hybride, projet partagé sur QFieldCloud en temps normal et bascule vers un export USB lors des missions en zone isolée, est tout à fait soutenable et c'est même la configuration que nous recommandons aux structures qui opèrent sur des territoires variés.

Recommandations d'architecture

Trois principes de structuration permettent de fiabiliser durablement un déploiement QField sur le terrain. D'abord, traiter la configuration QFieldSync comme une étape d'architecture de données, pas comme une simple formalité d'export: le typage des couches, la définition des formulaires et le choix des fonds embarqués conditionnent toute la qualité de la collecte. Ensuite, assumer la chaîne GNSS comme une brique externe intégrée, et non comme une fonctionnalité native: la précision centimétrique est un choix d'équipement et de service, et sa lisibilité doit être affichée en temps réel à l'opérateur. Enfin, sélectionner la stratégie de synchronisation en fonction du contexte opérationnel, plutôt qu'en fonction des habitudes de l'équipe au bureau: la fiabilité du réseau, le nombre d'opérateurs simultanés et la sensibilité des données déterminent le bon arbitrage entre QFieldCloud et le transfert manuel.

Un projet QField bien configuré se reconnaît à un critère simple: l'opérateur terrain n'a plus besoin de revenir au bureau pour produire une donnée exploitable, et le bureau n'a plus besoin de reconstituer ce qui s'est réellement passé sur le terrain. C'est cette boucle fermée, plus que la sophistication d'un paramètre isolé, qui signe un déploiement maîtrisé.