Logiciel SIG : open source ou propriétaire pour la topographie ?

Logiciel SIG: open source ou propriétaire pour la topographie?

Sur un chantier, le temps perdu ne vient pas toujours d’une mauvaise mesure. Il disparaît souvent entre deux logiciels, au moment de convertir un fichier, de retrouver un attribut, de resynchroniser une tablette ou de comprendre pourquoi le fond de plan n’est plus dans le bon système de coordonnées. Une équipe peut relever correctement les points GNSS le matin et passer l’après-midi à remettre les données en ordre.

C’est là que le choix entre un logiciel SIG open source et une solution propriétaire devient concret. La question n’est pas seulement de savoir si QGIS coûte moins cher qu’ArcGIS Pro. Il faut regarder la chaîne complète: préparation du projet, collecte terrain, traitement des données, échanges avec la CAO, publication, support et adoption par l’équipe.

Dans un logiciel SIG open source vs propriétaire, le bon choix n’est donc pas celui qui affiche le plus de fonctions dans sa brochure. C’est celui qui réduit les frictions entre le bureau, le terrain et le donneur d’ordre.

Le prix de la licence ne raconte qu’une partie de l’histoire

Le premier écart est évident: QGIS est distribué sous licence GNU GPL, version 2 ou ultérieure. Le logiciel peut être installé et utilisé sans coût d’acquisition comparable à celui d’une plateforme propriétaire. Mais « open source » ne veut pas dire « gratuit » au sens opérationnel.

Une équipe doit toujours financer le temps passé à configurer les projets, documenter les méthodes, former les utilisateurs et maintenir les extensions ou les scripts spécifiques. Elle peut aussi avoir besoin d’un hébergement, d’un serveur, d’un accompagnement ou d’un développement pour adapter l’outil à son fonctionnement. Le coût se déplace parfois de la licence vers l’intégration.

À l’inverse, une solution propriétaire encadre davantage la dépense. ArcGIS Pro propose plusieurs niveaux de licence — Basic, Standard et Advanced — associés à différents types d’utilisateurs, de Creator à Professional Plus. Les droits d’usage, les extensions, les services en ligne et les modalités de déploiement doivent toutefois être examinés séparément. Une licence de base ne couvre pas nécessairement toutes les opérations dont un cabinet de topographie aura besoin.

La licence Single Use d’ArcGIS Pro, par exemple, autorise un utilisateur à employer le logiciel sur un ordinateur à la fois, avec une installation possible sur deux ordinateurs maximum. Ce modèle peut convenir à une petite structure qui travaille principalement sur des postes identifiés. Il est moins souple dès que les équipes alternent entre plusieurs machines ou que le travail devient collaboratif.

Le type de licence Concurrent Use a par ailleurs été déprécié par Esri le 1er juillet 2025. Depuis le 1er décembre 2025, les conversions de licences Named User vers Single Use ou Concurrent Use ne sont plus possibles dans My Esri. Ce n’est pas un détail administratif: le modèle de licence conditionne la manière dont on attribue les postes, accompagne les collaborateurs et absorbe les changements d’organisation.

Le vrai coût d’un logiciel SIG se mesure moins à son prix d’achat qu’au nombre de manipulations que l’équipe doit inventer autour de lui.

Deux modèles, deux formes de dépendance

L’open source limite la dépendance à un éditeur unique, mais il ne supprime pas la dépendance à l’expertise. Une structure qui ne documente pas ses modèles de projet, ses styles, ses scripts et ses règles de contrôle qualité peut devenir dépendante d’une seule personne en interne. Le jour où cette personne quitte l’entreprise, le logiciel reste disponible, mais le savoir-faire opérationnel peut disparaître avec elle.

Le propriétaire réduit souvent cette incertitude par une documentation organisée, un support contractuel et un écosystème de prestataires identifiés. En contrepartie, l’entreprise dépend du rythme de l’éditeur, de ses changements de licence et de la compatibilité de ses versions.

Le compromis se situe rarement entre liberté totale et enfermement complet. Il se joue plutôt entre plusieurs questions très pratiques:

• Qui sait administrer et maintenir la solution?
• Combien de personnes doivent l’utiliser, et sur quels appareils?
• Quelles fonctions sont réellement nécessaires au quotidien?
• Les données doivent-elles rester dans une infrastructure maîtrisée en interne?
• Quelle réversibilité est prévue si la solution change ou si le prestataire disparaît?

QGIS est solide sur le SIG, mais le terrain demande une chaîne bien préparée

QGIS couvre un périmètre large: visualisation et superposition de données raster et vecteur en 2D et en 3D, numérisation, géoréférencement, gestion des tables attributaires, import-export GPS et production cartographique. La documentation QGIS 3.44 montre aussi que le logiciel peut manipuler différents formats et projections sans imposer une conversion préalable vers un format interne unique.

Pour un cabinet de géomètre ou un service topographique, cette souplesse est précieuse. On peut ouvrir un ensemble de données existant, construire une base projet, symboliser les objets, créer des formulaires attributaires et exporter vers différents interlocuteurs. Le logiciel accepte notamment les échanges GPX et propose un export DXF avec des fonctions de gestion des styles, la possibilité de forcer une sortie en 2D et d’exporter les étiquettes en éléments MTEXT ou TEXT.

Mais la souplesse n’est pas une méthode de travail. Un projet QGIS mal structuré peut devenir un assemblage de couches, de fichiers temporaires et de styles locaux que chacun modifie à sa façon. La courbe d’apprentissage ne concerne pas seulement les boutons. Elle touche les principes mêmes de la donnée géographique: projection, identifiant unique, domaines de valeurs, géométrie valide, nommage des champs et historique des modifications.

Sur le terrain, QField prolonge l’environnement QGIS avec une application open source conçue pour fonctionner en mode connecté ou hors ligne. La préparation et la synchronisation des projets passent notamment par QFieldSync. C’est un ensemble cohérent, mais il faut le préparer comme un vrai workflow, pas comme un simple transfert de couches vers une tablette.

Un projet terrain bien construit doit répondre à des questions que l’interface ne posera pas toujours à la place de l’équipe:

• quelles couches sont consultables et lesquelles peuvent être modifiées;
• quels champs sont obligatoires à la saisie;
• comment sont gérées les valeurs par défaut et les listes de choix;
• que se passe-t-il si deux opérateurs modifient le même objet hors connexion;
• quel référentiel de coordonnées est utilisé à l’export;
• comment les photos, croquis et observations sont-ils rattachés aux objets;
• qui valide les données avant leur retour dans la base de production.

QGIS et QField peuvent très bien couvrir un besoin de collecte SIG, d’inventaire, de suivi d’ouvrages ou de contrôle de réseaux. Ils ne transforment pas pour autant une tablette en contrôleur de levé complet. La différence avec une solution métier dédiée comme Trimble Access se situe dans la profondeur de l’intégration avec les instruments, les styles de levé, les contrôles et les routines propres à la mesure topographique.

ArcGIS Pro et les solutions métier gagnent surtout sur l’encadrement des workflows

Le logiciel propriétaire n’est pas automatiquement plus précis. La précision GNSS dépend d’abord du récepteur, des corrections, des conditions d’observation, du système de coordonnées et du contrôle qualité. Un environnement propriétaire peut en revanche mieux encadrer la manière dont les données sont préparées, mesurées, contrôlées et transmises.

Trimble Access illustre ce point avec des workflows dédiés au levé GNSS RTK, RTX, FastStatic et cinématique post-traitée. Le FastStatic utilise des occupations pouvant aller jusqu’à 20 minutes, tandis que le post-traitement est annoncé pour atteindre une précision subcentimétrique dans les conditions prévues par le workflow. Cette formulation est importante: elle décrit une méthode, un équipement et des conditions déterminés, pas une promesse valable pour n’importe quel récepteur ou n’importe quel chantier.

Dans Trimble Access, le style de levé concentre les paramètres de configuration de l’équipement, de mesure et d’implantation. Les levés RTK peuvent utiliser des formats de diffusion réseau comme FKP, VRS et RTCM3Net. Pour un opérateur habitué à travailler avec un contrôleur et une antenne GNSS, cette continuité réduit la friction: les paramètres sont regroupés, les routines sont identifiées et les contrôles sont intégrés au parcours de mesure.

Un logiciel SIG généraliste, même très complet, n’a pas forcément vocation à remplacer ce type d’outil. Il peut recevoir les données, les contrôler, les enrichir et les publier. Il ne doit pas nécessairement prendre en charge chaque étape de l’implantation ou du levé statique.

ArcGIS Pro occupe une position intermédiaire selon l’organisation. Il s’agit d’une plateforme SIG structurée, avec des niveaux de licence, des extensions et un écosystème de services. Elle convient aux équipes qui ont besoin de règles communes, de modèles de données partagés, de traitements reproductibles et d’une gouvernance plus centralisée. Dans un environnement déjà équipé de solutions Esri, le bénéfice vient souvent moins d’une fonction isolée que de la continuité entre les composants.

Comparatif rapide pour une équipe de topographie

Ce tableau ne désigne pas un vainqueur. Il montre surtout que les solutions ne répondent pas exactement au même problème. Comparer QGIS à un logiciel de levé GNSS dédié revient à comparer une plateforme de préparation et d’analyse à un outil de mesure terrain. La bonne question est alors celle de l’articulation entre les deux.

L’interopérabilité se joue dans les données, pas dans la liste des formats

Un fichier qui s’ouvre dans deux logiciels n’est pas forcément une donnée qui circule correctement. La géométrie peut être conservée tandis que les attributs sont tronqués, les styles perdus, les règles métier ignorées ou les objets 3D aplatis. L’interopérabilité des logiciels géospatiaux commence donc par un modèle de données explicite.

Le GeoPackage est particulièrement intéressant dans ce contexte. Ce standard OGC fondé sur SQLite peut stocker des objets vectoriels, des tuiles raster et des données tabulaires non spatiales dans un conteneur portable et indépendant de la plateforme. Pour une petite équipe, il offre une base structurée plus robuste qu’un empilement de fichiers isolés. Pour une équipe plus importante, il ne remplace pas nécessairement une base serveur et une gouvernance multi-utilisateur, mais il constitue un support d’échange et de travail efficace dans de nombreux cas.

QGIS peut également fonctionner comme client de services OGC WMS, WMTS, WCS, WFS, WFS-T et OAPIF. QGIS Server peut publier des données via WMS, WCS, WFS et OAPIF. Cette capacité permet de séparer les usages: les équipes consultent un service cartographique, téléchargent les données nécessaires ou travaillent sur une copie contrôlée plutôt que de manipuler directement tous les fichiers de production.

Il faut toutefois rester précis sur ce que permettent ces services. Un WMS sert principalement à afficher une image cartographique. Un WFS fournit des objets vectoriels, mais toutes les implémentations ne permettent pas de modifier les données. Les opérations transactionnelles dépendent du standard utilisé et de la configuration du serveur. Le simple fait de voir une couche dans un projet ne signifie donc pas que l’on peut l’éditer, la synchroniser ou la mettre à jour.

Le DXF reste utile, mais il ne doit pas devenir la base du système

Dans les échanges avec la CAO, le DXF reste un passage obligé pour de nombreuses équipes. QGIS permet d’en exporter les données et de gérer certains aspects de style et d’étiquetage. C’est pratique pour transmettre un fond ou récupérer une géométrie dans un environnement de dessin.

Mais le DXF n’est pas un format complet de gestion de données SIG. Il transporte bien une représentation exploitable dans la CAO; il ne remplace pas une base géospatiale structurée avec des attributs, des relations, des contrôles et un historique. Si l’on utilise le DXF comme unique source de vérité, on finit par demander à des calques de dessin de jouer le rôle d’une base de données. C’est là que les erreurs commencent à se multiplier.

Pour éviter ce piège, nous pouvons séparer trois objets:

1. La donnée de référence, conservée dans une base ou un format structuré avec son système de coordonnées, ses attributs et ses règles.

2. La donnée de production, adaptée au travail du jour: levé, contrôle, mise à jour ou analyse.

3. La donnée d’échange, exportée vers le format attendu par le client, le conducteur de travaux ou le bureau d’études.

Cette séparation réduit les allers-retours destructifs. On peut générer un DXF pour la CAO sans abandonner la base géographique qui porte les attributs et l’historique. On peut aussi revenir à la donnée source lorsqu’un interlocuteur demande une correction, au lieu de modifier directement un fichier d’échange déjà remanié.

Pour aller plus loin sur la logique des standards géospatiaux et des services de données, la documentation de référence de l’Open Geospatial Consortium permet de replacer ces formats dans leur cadre technique, au-delà des seuls noms de fichiers.

Le choix se décide souvent sur le support et l’adoption

Dans beaucoup de projets, la fonction qui manque n’est pas celle qui bloque l’équipe. Le blocage vient d’un bouton placé ailleurs, d’un vocabulaire différent, d’un formulaire trop long ou d’une procédure que personne n’a pris le temps de tester sur un vrai chantier.

L’adoption est rarement linéaire. Les opérateurs terrain veulent mesurer sans ralentir leur tournée. Les techniciens de bureau veulent récupérer des données propres. Le responsable de projet veut une traçabilité suffisante. Le dirigeant veut éviter de multiplier les abonnements. Ces attentes sont légitimes, mais elles ne se résolvent pas avec la même interface.

Une solution open source donne souvent plus de latitude pour adapter l’outil aux pratiques de l’équipe. Cette latitude peut devenir une force si elle est pilotée: projet modèle, formulaires standardisés, bibliothèque de styles, nomenclature commune, procédure d’export et versionnement documenté. Sans ce cadre, chaque utilisateur construit sa variante et l’interopérabilité se dégrade malgré la richesse du logiciel.

Une solution propriétaire fournit plus souvent un environnement déjà balisé. Les droits, les extensions, les rôles et les méthodes de partage sont intégrés dans une architecture cohérente. Cela peut accélérer le démarrage, surtout lorsque l’entreprise dispose déjà d’un référent ou d’un prestataire. Mais l’encadrement a un revers: chaque évolution peut entraîner une adaptation de licence, de serveur ou de méthode.

Le support local compte autant que le nom du logiciel. Dans un cabinet de petite taille, une personne capable de comprendre à la fois le métier, les systèmes de coordonnées, les équipements GNSS et l’administration du projet vaut souvent davantage qu’une longue liste de fonctions. La meilleure plateforme est celle que l’équipe sait maintenir un lundi matin, quand un fichier ne se synchronise pas et que le chantier, lui, n’attend pas.

Comment arbitrer pour un cabinet de géomètres ou un service topographique?

Il est rarement pertinent de choisir une solution pour toute l’entreprise en une seule fois. Les besoins du terrain, du bureau d’études et de la direction des données ne sont pas identiques. Une architecture mixte peut être plus cohérente qu’un remplacement complet.

Un cabinet peut par exemple conserver un logiciel métier propriétaire pour le levé et l’implantation GNSS, utiliser QGIS pour la préparation cartographique, le contrôle et l’analyse, puis produire des exports DXF ou des services web pour les partenaires. Une autre structure préférera une plateforme propriétaire de bout en bout afin de réduire le nombre d’interfaces et de responsabiliser un interlocuteur unique.

Avant de décider, il faut partir de quelques flux réels, pas d’une démonstration commerciale:

• réception d’un fond cadastral ou orthophotographique;
• préparation d’un projet de levé avec le bon référentiel;
• collecte de points et d’attributs hors connexion;
• import des observations GNSS et contrôle des écarts;
• mise à jour d’une base existante;
• export vers la CAO ou remise d’un livrable cartographique;
• publication pour consultation par une équipe non spécialiste.

Pour chaque flux, nous pouvons relever le nombre de conversions, les ressaisies, les contrôles manuels et les personnes nécessaires. C’est souvent à ce moment que la différence entre les solutions apparaît. Un logiciel peut être moins cher et demander trois manipulations supplémentaires à chaque chantier. À l’échelle d’une année, cette friction pèse davantage que prévu.

Une méthode de déploiement qui évite l’effet tunnel

Le déploiement d’une nouvelle technologie doit commencer par un périmètre réduit mais représentatif. Pas un exercice théorique avec des données propres: un chantier ordinaire, un opérateur expérimenté, un utilisateur moins à l’aise et un livrable qui doit réellement partir au client.

Le premier test doit porter sur l’ensemble de la chaîne:

1. Préparer un projet avec les couches et les attributs réellement utilisés.

2. Le transmettre à un appareil terrain et vérifier le mode hors ligne.

3. Effectuer une collecte complète, avec photos, observations et cas particuliers.

4. Synchroniser les données sans écraser les modifications existantes.

5. Contrôler les géométries, les coordonnées, les attributs et les métadonnées.

6. Générer le livrable attendu par le client ou le bureau d’études.

7. Documenter les points de friction avant de généraliser.

Cette démarche donne une place aux utilisateurs. Ils ne sont pas seulement les destinataires d’une décision informatique; ils connaissent les raccourcis, les contraintes de visibilité, les erreurs récurrentes et les moments où la précision affichée ne suffit pas à sécuriser la mesure.

La formation doit elle aussi rester proche des situations de travail. Une demi-journée consacrée à la logique des couches et des formulaires peut être plus utile qu’un catalogue complet de fonctionnalités. Il faut apprendre à reconnaître un mauvais système de coordonnées, à vérifier une synchronisation et à comprendre ce qui sera perdu lors d’un export. C’est moins spectaculaire qu’une démonstration 3D, mais beaucoup plus rentable sur le terrain.

Alors, open source ou propriétaire?

QGIS est un choix solide lorsque l’équipe cherche une plateforme SIG souple, capable de gérer des données raster et vecteur, de numériser, d’échanger avec des GPS, de publier via des services OGC et de s’intégrer à un environnement de collecte comme QField. Son intérêt est particulièrement fort lorsque la structure veut maîtriser ses formats, adapter ses formulaires et éviter de faire dépendre chaque usage d’une licence nominative.

ArcGIS Pro et les écosystèmes propriétaires prennent l’avantage lorsque l’organisation a besoin d’un cadre de gouvernance établi, d’un support éditeur, de rôles utilisateurs structurés ou d’une continuité avec des services et extensions déjà en place. Les solutions métier comme Trimble Access sont plus pertinentes dès que le cœur du besoin est le levé GNSS, l’implantation, le post-traitement ou l’intégration étroite avec un matériel donné.

Le coût de licence reste un critère, mais il ne doit pas écraser les autres. Il faut ajouter au calcul les contrôleurs, les abonnements, les extensions, le cloud, la maintenance, la formation et les développements spécifiques. Il faut également regarder ce qui se passe lorsque la connexion disparaît, lorsqu’un collaborateur change de poste ou lorsqu’un client demande un format inhabituel.

Notre position est simple: ne choisissons pas un logiciel SIG pour sa promesse générale, choisissons une chaîne de production que l’équipe pourra réellement tenir. L’open source offre de la liberté, à condition d’assumer l’intégration et la documentation. Le propriétaire offre un cadre, à condition d’accepter ses règles de licence et son écosystème. Dans les deux cas, la réussite dépend du même point: faire entrer l’outil dans les habitudes du chantier sans demander aux professionnels de la topographie de devenir informaticiens à plein temps.

Une technologie bien intégrée ne se remarque presque plus. Les mesures remontent, les attributs sont fiables, les exports partent au bon format et chacun sait où se trouve la donnée de référence. C’est à ce moment-là que le choix du logiciel cesse d’être un débat de catalogue pour devenir ce qu’il aurait toujours dû être: une décision de méthode, au service de la précision géographique et du travail de l’équipe.