Réponse courte

Il n'existe pas un seul « meilleur SIG pour la géologie » — il existe une chaîne la mieux adaptée à un flux de travail donné. Pour la plupart des équipes géologiques, cette chaîne combine : QGIS ou ArcGIS Pro pour la numérisation, l'interprétation, la symbologie et la mise en page cartographique ; GDAL/OGR pour un traitement raster et vecteur scripté et reproductible ; PostGIS lorsque les couches géologiques deviennent des actifs partagés et multi-éditeurs ; et Google Earth Engine lorsqu'il faut traiter de gros volumes d'imagerie satellite sans la télécharger. La bonne réponse est dictée par le volume de données, les compétences de l'équipe, les licences, les normes de publication (notamment GeMS) et le degré d'auditabilité requis — pas par une fidélité à une marque.

Les deux piliers bureautiques : QGIS et ArcGIS Pro

Pour la cartographie géologique quotidienne — tracer des contacts, attribuer des unités, enregistrer des mesures structurales, construire le contexte des coupes et produire des cartes imprimées — vous vivez dans un SIG de bureau.

QGIS est gratuit et open source, fonctionne sous Windows/macOS/Linux et est entièrement scriptable via PyQGIS et le framework Processing. Pour la géologie, il offre une symbologie puissante par règles et pilotée par les données (utile pour les remplissages lithologiques et les symboles structuraux), un excellent moteur d'expressions, la capacité d'afficher pendage/direction avec rotation et décalage à partir de champs d'attributs, ainsi qu'une lecture/écriture directe vers GeoPackage et PostGIS. Des extensions l'enrichissent pour les stéréonets, les logs de forage et les coupes géologiques. Comme il lit presque tout via GDAL, QGIS bute rarement sur un format inconnu.

ArcGIS Pro est commercial (licences par utilisateur nommé, avec Spatial Analyst et d'autres extensions vendues séparément). Ses avantages pour la géologie se concentrent là où les normes et l'intégration en entreprise comptent : la boîte à outils GeMS pour construire et valider des bases de données de cartes géologiques conformes à l'USGS, des règles de topologie matures (aucun trou/recouvrement entre polygones d'unités, contacts accrochés aux limites d'unités), le modèle de données géodatabase avec sous-types et domaines, et une publication transparente vers les portails ArcGIS Enterprise/Online. Si votre livrable doit être une base GeMS ou doit vivre dans une entreprise Esri, Pro supprime beaucoup de frictions.

Facteurs de décision entre les deux :

  • Licences/budget : QGIS est gratuit ; Pro est un abonnement par utilisateur plus des extensions.
  • Normes : la publication GeMS penche vers l'outillage ArcGIS (bien que QGIS + scripts puissent produire une sortie conforme).
  • Topologie et modèle de données : la topologie et les domaines de la géodatabase de Pro sont plus clés en main ; QGIS gère la topologie via le Vérificateur de topologie et les contraintes de base de données.
  • Personnalisation/automatisation : les deux se scriptent bien (PyQGIS vs ArcPy) ; les compétences de l'équipe tranchent généralement.
  • Symbologie des données structurales : les deux en sont capables ; la rotation pilotée par les données de QGIS est très flexible et gratuite.

Une posture pragmatique : choisissez l'un comme environnement principal d'interprétation et conservez les données dans des formats ouverts (GeoPackage/PostGIS) afin de ne pas vous enfermer.

Quand vous dépassez le bureau : GDAL, PostGIS, Earth Engine

GDAL/OGR est le moteur sous la plupart des logiciels SIG et le bon outil lorsqu'une tâche doit être reproductible, traitable par lots et documentée sous forme de code. Usages géologiques typiques : découper et reprojeter des dalles de MNT (gdalwarp -t_srs EPSG:32632 -tr 10 10 in.tif out.tif), produire des dérivées de terrain (gdaldem slope, gdaldem hillshade), mosaïquer l'imagerie et convertir/reprojeter des couches vecteur (ogr2ogr -t_srs EPSG:32632 out.gpkg in.shp). Une ligne gdalwarp dans un script est auditable d'une façon qu'un parcours d'assistant à la souris ne l'est pas.

PostGIS (l'extension spatiale de PostgreSQL) n'est pas un format de fichier — c'est une base de données spatiale multi-utilisateurs. Elle gagne sa place lorsque plusieurs géologues éditent les mêmes couches d'unités, de failles et d'échantillons, lorsque vous avez besoin de SQL spatial (ST_Intersects, ST_Transform, ST_Buffer, ST_DWithin) pour répondre à des questions comme « quels forages se trouvent à moins de 500 m d'une faille cartographiée », et lorsque vous voulez l'indexation, les contraintes et une source de vérité unique au lieu d'un dossier de GeoPackages contradictoires. QGIS et ArcGIS Pro s'y connectent directement, elle se glisse donc sous les outils de bureau plutôt que de les remplacer.

Google Earth Engine est une plateforme cloud pour l'analyse d'imagerie à l'échelle planétaire. Pour la géologie, sa valeur tient au traitement côté serveur de grandes piles d'imagerie Landsat et Sentinel-2 — calcul de rapports de bandes pour la cartographie des minéraux/altérations (par ex. rapports oxydes de fer et argiles/hydroxyles), exécution de séries temporelles ou génération de composites sans nuages sur tout un permis — sans télécharger des téraoctets. Vous écrivez l'analyse en JavaScript ou Python et n'exportez que le résultat. Cela complète, plutôt que de remplacer, le bureau où se font l'interprétation finale et la cartographie.

Des outils spécialisés de modélisation 3D/géologique (Leapfrog, GOCAD/SKUA, Move, GemPy) accompagnent le SIG pour la modélisation implicite et la restauration structurale ; le SIG reste le pôle de cartographie de surface et d'intégration des données.

Une liste de capacités spécifiques à la géologie

Lorsque vous évaluez un outil pour des travaux géologiques, notez-le sur les capacités que la géologie sollicite réellement, et non sur des fonctions SIG génériques :

  • Gestion du SCR et du datum : reprojection propre entre systèmes géographiques et projetés, transformations de datum et SCR par couche — non négociable pour combiner GPS de terrain, grilles nationales et imagerie.
  • Topologie : pouvez-vous imposer que les polygones d'unités ne présentent ni trou ni recouvrement et que les contacts coïncident avec les limites de polygones ? (Topologie de géodatabase ArcGIS ; Vérificateur de topologie QGIS plus accrochage.)
  • Symbologie pilotée par les données / par règles : rotation des symboles de direction/pendage selon un champ d'azimut, remplissages lithologiques liés à une table d'unités, légendes empilées ordonnées par âge.
  • Modèle d'attributs : domaines/contraintes, tables liées (forages vers intervalles en profondeur) et texte long pour les descriptions d'unités — les shapefiles échouent ici (noms de champ à 10 caractères, texte à 254 caractères), préférez donc GeoPackage/géodatabase/PostGIS.
  • Terrain raster et imagerie : dérivées de MNT (pente, exposition, ombrage), calculs de bandes pour les indices d'altération et grandes mosaïques.
  • Automatisation : scripts PyQGIS/ArcPy ou GDAL pour que le traitement soit reproductible et documenté.
  • Publication : validation GeMS si nécessaire, plus sortie web tuilée pour les parties prenantes.

Un outil qui maîtrise le SCR, la topologie et la symbologie pilotée par les données servira la plupart des cartographies géologiques ; les lacunes sur ces trois points sont là où les projets accumulent silencieusement des erreurs.

Exemple concret : composer une chaîne pour un projet d'exploration

Un projet de cartographie de permis doit : ingérer des MNT à 30 m et sélectivement à 1 m, cartographier unités/contacts/failles, intégrer ~400 stations de terrain et 60 forages partagés entre trois géologues, exécuter des indices d'altération Sentinel-2 et livrer une base de type GeMS plus un visualiseur web.

  1. Stockage/collaboration : PostGIS comme magasin éditable unique pour unités, contacts, failles, stations, forages — trois éditeurs, une seule vérité.
  2. Imagerie : Earth Engine pour construire un composite Sentinel-2 et des rasters de rapports argiles/oxydes de fer sur toute la zone ; exporter les rasters d'indices en GeoTIFF.
  3. Terrain : GDAL pour reprojeter tous les rasters vers la zone UTM du projet et une taille de cellule fixe, puis gdaldem pour la pente/l'ombrage — scripté pour se réexécuter à l'identique.
  4. Interprétation/cartographie : QGIS (ou ArcGIS Pro si la validation GeMS est obligatoire) connecté à PostGIS pour la numérisation et la mise en page.
  5. Publication : exporter une base GeoPackage/GeMS pour l'archive et une carte web tuilée pour les parties prenantes.

Remarquez qu'aucun outil n'est « le meilleur » — chacun possède l'étape où il excelle, et les transitions sont explicites.

Pièges fréquents et leurs causes

  • Choisir un outil avant de décrire le flux de travail. « QGIS ou ArcGIS ? » est sans réponse sans le cycle de vie ; les vraies contraintes sont le volume d'imagerie, le nombre d'éditeurs et la norme de publication. Définissez d'abord le cycle de vie.
  • Décider sur le seul coût de licence. Le gratuit n'est pas gratuit si la validation GeMS ou la publication d'entreprise coûte ensuite des semaines de contournements ; le payant est un gaspillage si un projet à un seul analyste n'en a jamais besoin.
  • Parcourir des assistants pour des tâches reproductibles. Reprojections/terrains manuels sont non auditables et sujets aux erreurs à grande échelle ; un script GDAL est reproductible. Scriptez les étapes reproductibles.
  • Stocker la géologie partagée dans des fichiers épars. Plusieurs GeoPackages divergent ; les éditions contradictoires se perdent silencieusement. Déplacez les couches partagées et multi-éditeurs dans PostGIS.
  • Télécharger d'énormes imageries sur le bureau. Tirer des archives Sentinel/Landsat complètes gaspille temps et disque. Traitez dans Earth Engine, n'exportez que les résultats.

Contrôle qualité avant d'arrêter une chaîne

  • Prototypez l'étape la plus risquée (grosse imagerie, données multi-éditeurs, validation GeMS) avant de standardiser tout le pipeline.
  • Vérifiez que tous les outils s'accordent sur le SCR, les unités et la taille de cellule à chaque transition — reprojetez explicitement, ne comptez pas sur l'alignement d'affichage à la volée.
  • Vérifiez que la chaîne est auditable : étapes de traitement scriptées, schéma documenté et format d'archive ouvert.
  • Contrôlez les allers-retours de format (PostGIS → GeoPackage → bureau) pour préserver noms de champs, encodage et validité géométrique.
  • Assurez-vous que le livrable s'ouvre pour le destinataire et peut être maintenu ensuite, pas seulement par l'analyste d'origine.

Le point de vue Bathyl

Nous sommes délibérément agnostiques quant aux outils : la chaîne est jugée selon qu'elle transforme les données de terrain et de télédétection en un système qui peut être inspecté, réexécuté et transmis. En pratique, cela signifie généralement PostGIS pour la géologie partagée, un traitement scripté GDAL, un SIG de bureau pour l'interprétation et Earth Engine pour l'imagerie à grande échelle — choisis par projet, documentés à chaque transition.

À lire aussi

Sources