Réponse courte

QGIS et Google Earth Engine (GEE) ne sont pas tant des concurrents que les deux extrémités d'un même pipeline de télédétection. Earth Engine est une plateforme cloud dont la raison d'être est le traitement de collections d'images (des années de Landsat, Sentinel, MODIS) à l'échelle continentale sans que vous ne téléchargiez jamais un pixel. QGIS est un SIG bureautique dont les forces sont l'inspection de scènes individuelles, l'édition de vecteurs, la cartographie et la production de livrables prêts pour le client. La réponse pratique pour presque tout projet est : composer et analyser en amont dans GEE, puis finaliser en aval dans QGIS.

Deux architectures fondamentalement différentes

La différence d'architecture détermine tout le reste.

Earth Engine s'exécute côté serveur. Vous écrivez du JavaScript (Code Editor) ou du Python (l'API ee), et votre code décrit des opérations sur des données qui restent dans le catalogue de Google. Rien ne s'exécute tant que vous ne demandez pas un résultat (print, une tuile de carte ou un Export) ; GEE parallélise alors le calcul sur son infrastructure et ne renvoie que la réponse. C'est pourquoi vous pouvez appliquer une opération à 40 ans d'archive Landsat et obtenir un résultat en quelques secondes : vous n'avez jamais déplacé l'archive. Le revers est un modèle de programmation contraint, paresseux et fonctionnel, un calcul dépendant de l'échelle, des limites de quota et une édition interactive ou un contrôle cartographique restreints.

QGIS s'exécute sur votre machine, sur des données que vous pouvez manipuler. Chaque couche est un fichier ou une connexion à une base de données que vous pouvez ouvrir, éditer pixel par pixel, restyliser avec un contrôle complet de la symbologie et mettre en page pour l'impression. Le revers est que vous êtes limité par le disque, la mémoire vive et le processeur locaux ; traiter 200 tuiles Sentinel-2 localement implique de télécharger et stocker d'abord des centaines de gigaoctets.

La ligne de partage est donc : volume de données et répétabilité contre contrôle local et présentation.

Ce à quoi chacun est réellement bon

Tournez-vous vers Earth Engine quand :

  • L'analyse couvre de nombreuses scènes ou une longue série temporelle : composites annuels sans nuages, analyse de tendance, détection de changement sur des décennies.
  • Vous avez besoin d'un masquage intégré des nuages et des ombres sur une ImageCollection (par exemple la bande SCL de Sentinel-2 ou les jeux de données QA60/Cloud Score+).
  • La zone d'étude est trop vaste à télécharger, ou vous avez besoin d'un retraitement à la demande à mesure que de nouvelles images arrivent.
  • Vous voulez des scripts reproductibles et partageables que n'importe qui peut réexécuter sur le catalogue vivant.

Tournez-vous vers QGIS quand :

  • Vous inspectez et interprétez quelques scènes en détail.
  • Vous avez besoin d'une cartographie précise, de légendes et d'une mise en page pour un rapport ou un client.
  • Le travail est à dominante vectorielle : numérisation, topologie, édition d'attributs, superposition avec des données de terrain.
  • Vous voulez un contrôle complet du fichier de sortie, du format, du SCR et du stylage, hors connexion.

Exemple concret : le NDVI, de deux façons

NDVI = (PIR − Rouge) / (PIR + Rouge). Le contraste d'approche est instructif.

Dans QGIS, vous chargez une scène Sentinel-2 et ouvrez la calculatrice raster (menu Raster, ou l'algorithme de traitement gdal:rastercalculator). Pour Sentinel-2, la bande 8 est le PIR et la bande 4 est le Rouge :

("scene@8" - "scene@4") / ("scene@8" + "scene@4")

Ou en ligne de commande avec GDAL, en convertissant en flottant pour ne pas tronquer en entiers :

gdal_calc.py -A B08.tif -B B04.tif \
  --calc="(A.astype(float)-B)/(A+B)" \
  --outfile=ndvi.tif --NoDataValue=-9999

Vous obtenez un raster NDVI pour une date. Pour le faire sur 100 dates, vous boucleriez sur 100 scènes téléchargées.

Dans Earth Engine, vous décrivez le même calcul mais l'appliquez à toute une collection, en masquant les nuages, et réduisez à un composite médian, le tout côté serveur :

var aoi = ee.Geometry.Rectangle([2.2, 48.7, 2.5, 48.95]);

var col = ee.ImageCollection('COPERNICUS/S2_SR_HARMONIZED')
  .filterBounds(aoi)
  .filterDate('2025-05-01', '2025-09-30')
  .filter(ee.Filter.lt('CLOUDY_PIXEL_PERCENTAGE', 20))
  .map(function(img) {
    var ndvi = img.normalizedDifference(['B8', 'B4']).rename('NDVI');
    return img.addBands(ndvi);
  });

var medianNdvi = col.select('NDVI').median().clip(aoi);

Export.image.toDrive({
  image: medianNdvi,
  description: 'ndvi_summer_median',
  region: aoi,
  scale: 10,
  crs: 'EPSG:32631'
});

Notez le scale: 10 explicite (résolution de 10 m de Sentinel-2) et le crs: 'EPSG:32631' (UTM 31N) dans l'export. Ces deux paramètres constituent le contrat de transfert : ils fixent la résolution et la projection du fichier que vous importez dans QGIS, afin qu'il s'aligne avec vos autres couches. Le GeoTIFF exporté s'ouvre ensuite dans QGIS pour le seuillage, la vectorisation, le stylage et la mise en page.

Coût, courbe d'apprentissage et reproductibilité

Trois facteurs plus subtils décident souvent du choix en pratique.

Modèle de coût. Earth Engine est gratuit pour un usage non commercial et de recherche, avec un palier commercial payant ; dans les deux cas, vous ne payez rien pour les pétaoctets d'imagerie sous-jacents, ce qui est son plus grand avantage économique. QGIS est gratuit et open source, sans palier du tout, mais l'imagerie qu'il traite doit être obtenue et stockée, et ce stockage et cette bande passante sont à votre charge. GEE déplace donc le coût de l'acquisition de données vers les conditions de la plateforme, tandis que QGIS le déplace vers l'infrastructure locale.

Courbe d'apprentissage. QGIS est accessible via une interface graphique bureautique familière ; un nouvel analyste peut charger une scène et calculer un indice en quelques minutes. Earth Engine exige d'apprendre un modèle de programmation paresseux, fonctionnel et côté serveur, où les habitudes bureautiques courantes (boucles sur les pixels, évaluation immédiate, édition en mémoire) ne s'appliquent pas. Le gain est l'échelle, mais la montée en charge est plus raide et le débogage moins intuitif (les erreurs n'apparaissent que lorsqu'un résultat est demandé).

Reproductibilité. Un script GEE est autonome et s'exécute sur le catalogue vivant : un collègue qui le réexécute obtient la même logique appliquée aux données actuelles, ce qui est excellent pour une analyse transparente et répétable. Un flux de travail QGIS est reproductible aussi, mais typiquement via un modèle de traitement documenté ou un script PyQGIS plus les fichiers d'entrée spécifiques, qui doivent être archivés. Pour une analyse de télédétection auditée et partageable, le script GEE est souvent l'enregistrement le plus propre ; pour un livrable figé lié à des scènes précises, le projet QGIS plus les entrées archivées est plus concret.

Travailler avec les deux : le contrat d'export

La couture entre les deux outils est l'endroit où les projets se brisent ; traitez donc l'export comme un contrat :

  • Définissez scale explicitement. Le calcul GEE dépend de l'échelle ; une échelle non définie ou erronée change la taille des pixels et les statistiques calculées.
  • Définissez crs explicitement. Les exports par défaut atterrissent en EPSG:4326 (degrés). Pour tout ce qui se mesure, exportez vers un SCR projeté (la zone UTM appropriée) afin que les mesures dans QGIS soient en mètres.
  • Documentez le filtre de date et le seuil de nuages. Un raster « NDVI Sentinel-2 » n'a aucun sens sans la fenêtre de dates et les règles de masquage qui le sous-tendent.
  • Validez après import. Confirmez que le raster atterrit au bon endroit dans QGIS, que les statistiques de bande sont plausibles (NDVI dans [−1, 1]) et que le NoData est respecté.

Pièges courants et pourquoi ils surviennent

  • Demander « lequel est meilleur » sans nommer la charge de travail. La réponse est déterminée par le volume de données et le type de sortie, pas par la préférence. Une carte d'une seule scène et une tendance sur 30 ans sont des problèmes différents.
  • Tenter de traiter des archives entières localement dans QGIS. Vous manquez de disque et de temps. Cette charge appartient à GEE.
  • Faire confiance à un résultat GEE sans vérifier l'échelle. Comme le calcul GEE dépend de l'échelle, le même script renvoie des statistiques différentes selon le zoom/l'échelle ; fixez l'échelle.
  • Exporter en degrés puis mesurer dans QGIS. La surface et la distance en EPSG:4326 ne sont pas en mètres ; exportez en projeté.
  • Ignorer le masquage des nuages. Une médiane sur une collection non masquée porte encore une contamination par les nuages et les ombres ; utilisez les bandes QA/SCL du jeu de données.
  • Supposer que les noms de bandes GEE correspondent aux attentes de QGIS. Sentinel-2 utilise B4/B8 ; la numérotation des bandes Landsat diffère selon la génération de capteur. Vérifiez la page du catalogue.

AQ et validation

  • Comparez un composite GEE à une ou deux scènes individuelles sans nuages dans QGIS pour confirmer que le compositage n'a pas introduit d'artefacts.
  • Vérifiez que la plage de valeurs de tout indice (NDVI, NDWI) se situe dans ses bornes théoriques ; des valeurs hors plage signalent une erreur de bande ou de mise à l'échelle.
  • Validez les motifs spatiaux par rapport à des preuves indépendantes : parcelles de terrain, imagerie à plus haute résolution, géologie ou terrain.
  • Confirmez le SCR et l'alignement des pixels dans QGIS en superposant une couche vectorielle fiable et en vérifiant le calage.

Le point de vue de Bathyl

Nous poussons le travail lourd, à l'échelle de la collection (filtrage, masquage des nuages, compositage, réduction de séries temporelles) dans Earth Engine, et nous traitons le scale et le crs de l'export comme une interface documentée vers le côté QGIS, où ont lieu l'interprétation, la superposition vectorielle et la cartographie. Les outils sont complémentaires : GEE répond à « que dit l'ensemble de l'archive », QGIS répond à « ce résultat précis est-il correct et présentable ».

Lectures complémentaires

Sources