Synchro QField hors ligne : la méthode directe

Synchro QField hors ligne: la méthode directe

Elle consiste à préparer une copie opérationnelle du projet dans QGIS, à la transférer sur le terminal mobile, puis à réintégrer les modifications dans le projet source au moyen d’un journal de suivi. Le flux est donc local, mais il reste structuré: chaque couche doit posséder une logique d’édition cohérente et chaque transfert doit conserver la relation entre le projet de départ et sa copie terrain.

Cette méthode répond à un cas fréquent en topographie et en collecte SIG: le secteur d’intervention n’est pas couvert, les données sont trop sensibles pour être envoyées vers un service externe, ou le projet doit rester exploitable même lorsque le réseau disparaît. La difficulté ne se situe pas dans le simple déplacement de fichiers. Elle se situe dans la gestion des états successifs du projet: la version préparée au bureau, la version modifiée sur le terminal, puis la version consolidée dans QGIS.

En mode hors ligne, QField ne synchronise pas une carte isolée: il transporte un état de travail que QGIS devra ensuite réconcilier avec le projet source.

Préparer le projet avec QFieldSync

La préparation commence dans QGIS, avec l’extension QFieldSync. Celle-ci sert à transformer un projet de bureau en paquetage utilisable sur le terrain. Le paquetage contient la structure nécessaire au fonctionnement du projet mobile: couches, styles, paramètres et données destinées à l’édition ou à la consultation.

Cette étape évite de copier manuellement un ensemble disparate de fichiers dont les chemins, les dépendances et les droits d’écriture pourraient varier d’un environnement à l’autre. Dans un projet SIG, une couche visible dans QGIS n’est pas forcément autonome: elle peut dépendre d’un fichier externe, d’une base de données, d’un chemin relatif ou d’une organisation de dossiers que le terminal mobile ne retrouvera pas. Le paquetage QField sert précisément à reconstruire un environnement cohérent.

Un projet terrain doit être une version maîtrisée du projet de production

La version mobile n’a pas vocation à embarquer tout le contenu du projet de bureau. Une orthophotographie volumineuse, des couches de référence inutilisées ou des tables purement analytiques peuvent alourdir le transfert sans apporter de valeur pendant la collecte. À l’inverse, les couches réellement modifiées sur le terrain doivent être préparées avec une structure compatible avec le retour des données.

Le choix du format est ici déterminant. Pour les données vectorielles portables et éditables, l’écosystème QField préconise le GeoPackage, avec l’extension .gpkg. Ce format permet de regrouper plusieurs couches dans un même fichier tout en conservant une organisation adaptée aux échanges entre QGIS et QField. Il ne s’agit pas simplement d’un choix de stockage: le format influence la manière dont les modifications seront suivies, copiées et réappliquées au retour.

Dans QFieldSync, la préparation du projet s’appuie sur un paquetage dédié. Le projet source QGIS reste la référence de production; le paquetage constitue une copie de travail destinée au terminal. Cette distinction doit rester nette dans les dossiers comme dans les habitudes de l’équipe. Modifier par erreur le projet source au lieu du projet préparé peut rendre le suivi des changements difficile à interpréter, voire empêcher une réintégration propre.

Organiser les chemins et les dépendances

Avant l’export, il faut raisonner en termes de dépendances spatiales:

• les couches éditables doivent être présentes dans le paquetage et accessibles en écriture sur le terminal;
• les couches de référence doivent conserver leurs liens avec les styles et les fichiers associés;
• les ressources inutiles à la mission peuvent être exclues afin de réduire le volume manipulé;
• les noms de fichiers et l’arborescence doivent rester suffisamment lisibles pour identifier rapidement la version transférée;
• le dossier de travail local doit permettre de distinguer le paquetage exporté du dossier récupéré après la mission.

Cette organisation devient particulièrement utile lorsque plusieurs zones sont traitées successivement. Un paquetage par secteur, par équipe ou par opération permet de limiter les croisements entre journaux de modifications. Il faut toutefois conserver la même logique de nommage et une origine clairement identifiable pour chaque copie terrain.

Le paquetage n’est donc pas une archive quelconque. Il constitue une enveloppe fonctionnelle autour du projet. Son rôle est de transporter les données et la configuration qui permettent à QField de travailler hors connexion, puis de fournir à QGIS les éléments nécessaires à la synchronisation retour.

Configurer les actions de couche pour l’édition hors ligne

La synchronisation ne peut fonctionner correctement que si le comportement de chaque couche a été défini au moment de la préparation. QFieldSync propose plusieurs actions de couche, dont l’édition hors ligne, la copie, l’accès direct et la suppression. Ces actions ne produisent pas les mêmes effets sur le cycle de vie des données.

La différence essentielle concerne les couches qui seront modifiées et celles qui ne serviront que de contexte. Une couche de points d’intervention, de regards, de bornes ou de contrôles GNSS ne doit pas être traitée comme une couche de fond destinée uniquement à l’affichage. La première doit enregistrer les changements pour le retour dans QGIS; la seconde peut simplement être copiée dans le paquetage.

L’action d’édition hors ligne

L’action « édition hors ligne » crée une copie de travail de la couche dans le dossier du paquetage. Pendant la mission, QField modifie cette copie et enregistre les opérations dans un journal de modifications, souvent appelé journal de suivi ou changelog. Le journal conserve les changements qui devront être appliqués au projet source lors de la synchronisation retour.

Cette architecture sépare donc deux objets:

1. la donnée de référence présente dans le projet QGIS;

2. la copie de travail modifiée sur le terminal.

Le journal joue le rôle d’interface entre les deux. Il ne s’agit pas d’une simple sauvegarde de fichier, mais d’un historique des opérations nécessaires pour répercuter les modifications dans la source. Cette distinction explique pourquoi la structure du paquetage doit rester intacte jusqu’au retour: déplacer uniquement une couche modifiée sans conserver les éléments de suivi peut interrompre le flux de réintégration.

L’édition hors ligne est adaptée aux couches dont les entités doivent être créées, modifiées ou supprimées sur le terrain. Elle permet de conserver un projet fonctionnel sans connexion, tout en préparant le traitement ultérieur dans QGIS.

Les autres actions ne répondent pas au même besoin

Les actions de couche servent à exprimer l’intention fonctionnelle de chaque donnée. Une couche de contexte n’a pas nécessairement besoin d’un journal de modifications. Une couche qui doit être écrite sur le terrain, en revanche, doit être préparée pour cette logique de suivi.

Cette configuration doit être pensée à l’échelle du modèle relationnel du projet. Si plusieurs couches sont liées par des identifiants, des relations ou des règles de topologie, la version mobile doit conserver les éléments nécessaires à la cohérence des saisies. Une collecte n’est pas seulement une succession de géométries: elle peut aussi modifier des attributs, créer des enregistrements associés et alimenter des requêtes spatiales utilisées plus tard dans QGIS.

Le journal de modifications est une pièce du flux, pas un détail technique

Le journal de suivi sert à transporter l’écart entre l’état initial et l’état modifié. Il faut donc éviter de le considérer comme un fichier secondaire que l’on pourrait recréer ou remplacer après coup. Si le paquetage est copié, renommé ou déplacé, la logique de dossiers doit rester compréhensible et complète.

La méthode devient également plus fiable lorsque l’équipe définit un point de départ clair avant chaque mission. Une fois le paquetage préparé, il ne faut pas mélanger dans le même dossier des versions issues de plusieurs exports. Le risque n’est pas limité à une erreur de manipulation: il concerne la traçabilité du changement, la correspondance des identifiants et la possibilité de déterminer quelle version a réellement été utilisée sur le terrain.

Transférer manuellement les données vers Android et iOS

Une fois le paquetage préparé, son transfert peut s’effectuer sans internet, notamment par câble USB. Le principe est simple: copier le projet exporté dans l’emplacement local que QField utilise pour les projets importés, puis l’ouvrir depuis l’application.

Le transfert manuel n’est pas une synchronisation distante. Il ne met pas à jour automatiquement un projet central et ne transmet pas les modifications au fur et à mesure. Il déplace un paquetage complet entre deux environnements. Cette nuance permet de comprendre pourquoi le processus comporte un aller et un retour distincts.

Déploiement sur Android

Sur Android, un projet exporté manuellement par câble USB doit être placé dans le dossier dédié:

Android/data/ch.opengis.qfield/files/Imported Projects

L’emplacement peut être moins visible qu’un dossier utilisateur classique, car il se trouve dans l’arborescence propre à l’application. Le paquetage doit conserver sa structure lors de la copie. Il ne faut pas déplacer uniquement le fichier GeoPackage si le projet dépend également de styles, de formulaires, de ressources ou du journal de suivi.

Une fois le dossier importé, QField peut ouvrir le projet depuis son espace local. Le terminal dispose alors d’une version indépendante du projet QGIS, conçue pour la consultation et l’édition sans connexion. La disponibilité des données dépend naturellement de ce qui a été inclus dans le paquetage: une couche absente de l’export ne pourra pas être reconstituée par l’application pendant la mission.

Déploiement sur iOS

Sur iOS, le chemin local recommandé pour les projets QField est:

Sur mon iPhone/QField/Imported Projects

La logique reste identique: transférer le paquetage dans le dossier d’importation, conserver les fichiers associés et ouvrir ensuite le projet depuis QField. La différence porte principalement sur l’accès au système de fichiers et sur la manière dont le terminal présente les dossiers locaux.

Dans les deux environnements, une copie manuelle réussie se reconnaît moins à la présence d’un fichier qu’à l’ouverture correcte du projet dans son ensemble. Un fichier GeoPackage visible dans le stockage ne garantit pas que les couches, les styles et les paramètres du projet seront tous disponibles. Le projet doit être considéré comme une unité fonctionnelle.

Ce que le câble résout — et ce qu’il ne résout pas

Le câble USB supprime la dépendance au réseau pour le transport initial et le retour des données. Il ne résout pas les problèmes de structure du projet, de chemin de fichier ou de conflit entre plusieurs versions.

Le scénario est linéaire:

• QGIS prépare un paquetage;
• le paquetage est copié vers le terminal;
• QField l’utilise localement;
• le dossier modifié est copié vers l’ordinateur;
• QFieldSync réapplique les changements au projet source.

Si plusieurs personnes travaillent simultanément sur des copies différentes, la question n’est plus celle du transfert mais celle de la consolidation. La synchronisation par câble ne fournit pas, à elle seule, une résolution automatique des conflits entre utilisateurs simultanés. Il faut alors organiser les secteurs, les lots de données ou les séquences de collecte afin que les modifications ne se superposent pas sans contrôle.

Le transfert par câble est fiable lorsqu’il transporte un paquetage complet et identifié. Il devient fragile lorsqu’il est utilisé comme un simple copier-coller de fichiers isolés.

Réintégrer les modifications dans QGIS

Le retour de terrain constitue la deuxième moitié du processus. Les données modifiées doivent d’abord être copiées du terminal mobile vers l’ordinateur. Cette copie doit être conservée dans un dossier distinct du paquetage d’origine, afin de préserver la possibilité de comparer les états et de reprendre l’opération si la synchronisation doit être relancée.

Dans QGIS, l’extension QFieldSync fournit l’outil « Synchroniser depuis le dossier ». Celui-ci utilise le dossier récupéré pour réappliquer les modifications enregistrées pendant le travail hors ligne sur le projet source QGIS.

Une réintégration fondée sur le journal

Le journal de modifications décrit les opérations effectuées sur la copie terrain. Lors de la synchronisation retour, QFieldSync s’appuie sur ce journal et sur les données du paquetage pour reporter les changements dans la source.

Le flux peut être décrit sans le réduire à une procédure mécanique:

1. récupérer le dossier du projet depuis le terminal;

2. le conserver sans en modifier la structure;

3. ouvrir le projet source correspondant dans QGIS;

4. lancer l’outil de synchronisation depuis le dossier;

5. laisser QFieldSync réappliquer les modifications sur les couches préparées pour l’édition hors ligne;

6. contrôler le résultat dans le projet source avant de poursuivre les traitements.

La correspondance entre le paquetage et le projet source est centrale. Si le dossier récupéré provient d’un autre export, si la source a changé de structure entre-temps ou si des fichiers nécessaires ont été supprimés, le journal ne dispose plus du même contexte pour appliquer les opérations.

Contrôler les géométries et les attributs après synchronisation

La synchronisation technique ne remplace pas le contrôle métier. Une fois les modifications réintégrées, il faut examiner les couches qui ont réellement évolué, en portant une attention particulière à la cohérence entre géométrie et attributs.

Dans un projet topographique, ce contrôle peut porter sur:

• la présence des nouvelles entités dans les secteurs attendus;
• la conservation des identifiants et des relations entre tables;
• la validité des valeurs attributaires saisies sur le terrain;
• la cohérence topologique des objets modifiés;
• l’absence de doublons issus d’une création répétée;
• la compatibilité des géométries avec les règles de validation du projet QGIS.

Cette vérification ne constitue pas une remise en cause de l’édition hors ligne. Elle permet de replacer le changement dans le modèle relationnel global. Une donnée peut être correctement transférée tout en restant incohérente avec une autre couche, une contrainte attributaire ou une règle de topologie.

Le cas des erreurs de synchronisation

Une erreur de synchronisation QField ne doit pas être traitée comme un problème unique. Elle peut provenir de plusieurs couches du flux:

• le paquetage initial ne contient pas la donnée attendue;
• la couche n’a pas été configurée avec l’action d’édition hors ligne;
• le dossier récupéré n’est pas celui utilisé sur le terrain;
• la structure du paquetage a été modifiée pendant le transfert;
• le projet source n’est plus aligné avec la version exportée;
• plusieurs opérations ont été réalisées sur des copies concurrentes.

Le diagnostic doit donc suivre la chaîne de dépendances plutôt que de se limiter à l’écran de l’application. On commence par vérifier l’identité du paquetage, puis la présence du GeoPackage et du journal, ensuite la configuration de la couche dans QFieldSync, et enfin l’état du projet source.

Il est préférable de conserver le dossier récupéré avant toute tentative de correction. Une copie intacte permet de reprendre l’analyse sans perdre les éléments nécessaires au suivi. À l’inverse, modifier directement les fichiers retournés peut rendre plus difficile l’identification de l’étape qui a rompu le flux.

Concevoir un flux hors ligne durable

La synchronisation QField sans connexion internet fonctionne bien lorsqu’elle est intégrée à une architecture de données explicite. Le mode hors ligne n’est pas un réglage isolé de l’application mobile; c’est une organisation du passage entre plusieurs états du même projet.

Le bureau prépare une version terrain. Le terminal modifie une copie locale. QGIS réintègre les écarts dans la source. Chacune de ces étapes possède ses propres contraintes, et la robustesse du processus dépend de leur continuité.

Pour rationaliser le fonctionnement d’une équipe, plusieurs règles opérationnelles peuvent être intégrées au modèle de projet:

• attribuer un identifiant clair à chaque paquetage exporté;
• séparer les dossiers d’export, de transfert et de retour;
• conserver le projet source à l’écart des copies destinées aux terminaux;
• réserver l’édition hors ligne aux couches qui doivent réellement remonter vers QGIS;
• utiliser le GeoPackage comme conteneur vectoriel portable lorsque le projet s’y prête;
• éviter de mélanger les retours de plusieurs missions dans un même dossier;
• archiver le paquetage utilisé et le dossier retourné avant la consolidation;
• documenter les couches éditables et les couches uniquement consultées.

Cette discipline réduit les erreurs de chemin et clarifie la responsabilité de chaque fichier dans le flux. Elle facilite aussi l’évolution du projet: lorsqu’une couche est ajoutée, qu’un formulaire est modifié ou qu’une relation est restructurée, l’équipe sait quelles parties du paquetage doivent être réévaluées avant le prochain départ terrain.

Une architecture simple, mais pas simpliste

Le fonctionnement local de QFieldSync peut sembler plus rudimentaire qu’une synchronisation par service distant. Il exige pourtant une compréhension plus nette des versions, des copies et des journaux. Le réseau ne masque plus les opérations: c’est l’équipe qui doit organiser le transport, l’identification et la consolidation.

Cette approche possède un avantage structurel: les données restent dans le périmètre défini par le projet et les supports de transfert choisis. Elle convient notamment aux missions ponctuelles, aux zones sans couverture et aux environnements où la connectivité ne peut pas être considérée comme une dépendance fiable.

Elle demande en contrepartie une gouvernance minimale. Le câble ne remplace pas une stratégie de versionnement, et le paquetage ne remplace pas un modèle de données. Pour éviter les erreurs récurrentes, il faut traiter la collecte mobile comme un sous-flux du système SIG, avec une entrée clairement préparée et une sortie contrôlée.

La méthode directe, à condition de maîtriser le cycle complet

Le mode hors ligne de QField repose sur une chaîne cohérente: préparation avec QFieldSync, configuration de l’édition par couche, export du paquetage, transfert local vers Android ou iOS, collecte dans une copie de travail, puis synchronisation retour depuis le dossier dans QGIS.

La valeur de cette méthode ne tient donc pas seulement à l’absence de connexion internet. Elle réside dans la séparation propre entre le projet source et sa version terrain, dans l’utilisation du journal de modifications et dans la conservation du contexte nécessaire à la réintégration.

Pour un projet bien structuré, le flux est lisible et reproductible. Pour un projet dont les couches, les chemins et les versions sont mal définis, le hors ligne ne fera qu’exposer les incohérences déjà présentes. La bonne approche consiste à traiter QField comme une couche d’exécution mobile au-dessus d’un modèle SIG préparé: les données partent avec une structure, reviennent avec un historique, et ne retrouvent leur statut de données de production qu’après contrôle dans QGIS.