Automatiser QGIS : une tâche, 4 méthodes, chronométrées sur 2 villes

Il existe quatre façons d'automatiser un traitement répétitif dans QGIS : le traitement par lots (Batch Processing) pour un seul outil sur de nombreux fichiers, le modeleur graphique (Graphical Modeler) pour une chaîne d'outils que vous relancerez, un script PyQGIS pour les boucles et un contrôle précis, ou un agent IA dans QGIS quand vous voulez le résultat à partir d'un seul message en langage courant.

Les tutoriels que j'ai lus enseignent une seule de ces quatre méthodes, isolément, sur un exemple jouet, et aucun ne teste ce qui se passe quand on relance le traitement une seconde fois sur une nouvelle ville. Le 7 novembre 2026, j'ai pris une tâche en plusieurs étapes (la surface bâtie par quartier à partir de 180 602 bâtiments OpenStreetMap à Bielefeld, en Allemagne), je l'ai passée dans les quatre méthodes sous QGIS 3.44.15, puis je les ai toutes relancées sur Münster (135 577 bâtiments, 6 quartiers). Chaque méthode a réussi sur les deux villes, même si un passage du modeleur graphique s'est d'abord terminé « OK » en écrivant 1 058 polygones au lieu de 10.

Qu'est-ce que l'automatisation dans QGIS ?

Automatiser QGIS, c'est lancer un outil de traitement ou une chaîne d'outils sur des couches sans passer à la main par chaque boîte de dialogue. Sous chaque méthode se trouve le framework Processing de QGIS, le même moteur que celui de la boîte à outils de traitements (Processing Toolbox). Comme les outils sont identiques que vous les appeliez depuis un tableau de traitement par lots, un diagramme du modeleur graphique, un script Python ou l'outil en ligne de commande qgis_process, choisir une méthode d'automatisation revient en fait à choisir comment relier ces outils entre eux et quel fichier vous voulez garder sur le disque pour le mois prochain.

La tâche et les données testées

J'ai choisi un travail très courant en urbanisme et en bureau d'études : pour chaque quartier, découper les bâtiments selon la limite du quartier, compter les emprises, additionner leur surface en mètres carrés, appliquer un tampon de 25 m aux bâtiments découpés et les fusionner en un seul polygone bâti, puis enregistrer un GeoPackage propre avec une ligne par quartier.

Si un bâtiment chevauche une limite de quartier, il est découpé et compté une fois dans chaque quartier qu'il touche. Les deux villes utilisent des données OpenStreetMap issues d'extraits PBF de BBBike (ODbL, contributeurs OpenStreetMap), reprojetées en EPSG:25832 (ETRS89 / UTM zone 32N) pour toutes les mesures.

• Ville 1, Bielefeld : 180 602 polygones de bâtiments répartis sur 10 quartiers (admin_level=9), soit 115 002 morceaux de bâtiments découpés. Deux bâtiments OSM bruts avaient des géométries invalides et ont été réparés une fois avec Fix geometries (Réparer les géométries), pour que les quatre méthodes partent des mêmes fichiers propres.
• Ville 2, Münster (le second passage) : 135 577 polygones de bâtiments répartis sur 6 quartiers, soit 116 382 morceaux découpés.

Avant de lancer les quatre méthodes, j'ai écrit une référence indépendante avec de simples appels de géométrie PyQGIS (QgsSpatialIndex, geometry.intersection(), unaryUnion() et buffer(25, 5), sans appeler d'algorithmes Processing) et enregistré un script de vérification. Une méthode n'était validée que si elle produisait un GeoPackage avec une couche de polygones built_up en EPSG:25832, des nombres de bâtiments exacts par quartier, une surface d'emprise à moins de 0,5 % de la référence, des hectares bâtis à moins de 1 %, et aucune retouche à la main après coup.

Méthode 1 : le traitement par lots

Chaque outil de la boîte à outils de traitements a un bouton Run as Batch Process (Exécuter comme processus de lot) en bas à gauche de sa boîte de dialogue. Il transforme la boîte de dialogue en tableau où chaque ligne est une exécution de cet outil unique.

Pour notre tâche, le traitement par lots gère proprement le Clip par quartier et le Buffer par quartier, car ces deux étapes répètent exactement le même algorithme sur les 10 quartiers. Il ne peut pas faire tout le traitement d'un coup, en revanche, car le traitement par lots ne lance qu'un outil à la fois et vous laisse 10 couches de sortie séparées qu'il faut encore fusionner et rejoindre.

Sur les 9 exécutions (8 algorithmes différents), le temps total d'exécution des outils sur Bielefeld a été de 62,0 secondes, et chaque nombre par quartier correspondait à la référence. Sur Münster, le temps des outils est descendu à 39,8 secondes pour 6 quartiers, mais j'ai dû reconstruire les tableaux de lot à 6 lignes et relancer les 9 étapes à la main. Quand votre traitement est une chaîne d'outils différents plutôt qu'un seul outil répété sur 50 fichiers, le traitement par lots n'est pas la bonne forme.

Méthode 2 : le modeleur graphique

Le modeleur graphique (Processing > Graphical Modeler) permet de relier une chaîne d'outils Processing dans un seul diagramme et de l'enregistrer en fichier .model3. Une fois construit, le modèle apparaît dans votre boîte à outils de traitements comme n'importe quel outil natif.

On pourrait croire qu'il faut une boucle sur les quartiers dans le modeleur, mais non. En lançant d'abord Intersection entre les bâtiments et les quartiers, chaque morceau de bâtiment hérite de l'attribut name de son quartier, donc Aggregate et Dissolve groupés par name produisent une ligne par quartier en un seul passage. (Vous pourriez aussi utiliser une jointure spatiale si vous n'aviez pas besoin de couper les bâtiments exactement sur la limite du quartier.)

Lancer le modèle depuis sa boîte de dialogue sur Bielefeld a pris 62,7 secondes et a passé toutes les vérifications. Mieux encore, le même fichier .model3 a tourné depuis le terminal macOS, sans ouvrir de fenêtre QGIS, via qgis_process en 44,5 secondes.

Le vrai gain est apparu lors du second passage sur Münster. J'ai ouvert la même boîte de dialogue du modèle, choisi muenster_buildings et muenster_districts dans les deux listes déroulantes, et cliqué sur Run. Il s'est terminé en 67,2 secondes sans aucune modification du modèle.

Méthode 3 : un script PyQGIS dans la console Python

Si vous êtes à l'aise avec Python, un script dans Plugins > Python Console > Show Editor vous donne une vraie boucle for, les entrées sous forme de variables en haut du fichier, et aucune étape de fusion.

Voici le script de 38 lignes (built_up_by_district.py) que j'ai lancé sous QGIS 3.44.15, avec les chemins de fichiers raccourcis :

# Built-up area by district. Run in the QGIS Python console (Plugins > Python Console > Show Editor > Run).
# Change the first five lines for a new city.
BUILDINGS = "data/bielefeld_buildings.gpkg"
DISTRICTS = "data/bielefeld_districts.gpkg"
NAME_FIELD = "name"
BUFFER_M = 25
OUT = "out/script/built_up_script.gpkg"

import processing
from qgis.core import (QgsVectorLayer, QgsCoordinateReferenceSystem, QgsFeature, QgsField, QgsFields, QgsGeometry)
from qgis.PyQt.QtCore import QVariant

crs = QgsCoordinateReferenceSystem("EPSG:25832")   # metric, Germany
def run(alg, **p):
    return processing.run(alg, p)["OUTPUT"]

buildings = run("native:reprojectlayer", INPUT=BUILDINGS, TARGET_CRS=crs, OUTPUT="memory:")
districts = run("native:reprojectlayer", INPUT=DISTRICTS, TARGET_CRS=crs, OUTPUT="memory:")

result = QgsVectorLayer("MultiPolygon?crs=EPSG:25832", "built_up", "memory")
result.dataProvider().addAttributes([QgsField("district", QVariant.String), QgsField("building_count", QVariant.Int),
                                     QgsField("building_area_m2", QVariant.Double), QgsField("built_up_ha", QVariant.Double)])
result.updateFields()

for d in districts.getFeatures():
    one = run("native:extractbyexpression", INPUT=districts, EXPRESSION=f"$id = {d.id()}", OUTPUT="memory:")
    clipped = run("native:clip", INPUT=buildings, OVERLAY=one, OUTPUT="memory:")
    area = sum(f.geometry().area() for f in clipped.getFeatures())
    built_up = run("native:buffer", INPUT=clipped, DISTANCE=BUFFER_M, SEGMENTS=5, DISSOLVE=True, OUTPUT="memory:")
    geom = next(built_up.getFeatures()).geometry()
    f = QgsFeature(result.fields())
    f.setGeometry(geom)
    f.setAttributes([d[NAME_FIELD], clipped.featureCount(), area, geom.area() / 10000])
    result.dataProvider().addFeature(f)
    print(d[NAME_FIELD], clipped.featureCount(), round(area), round(geom.area() / 10000, 1))

processing.run("native:savefeatures", {"INPUT": result, "OUTPUT": OUT, "LAYER_NAME": "built_up"})
print("saved", OUT)

Le script garde chaque couche intermédiaire en mémoire et boucle sur les quartiers, et c'est de loin la méthode la plus rapide (nous n'avons pas mesuré pourquoi). Il a terminé Bielefeld en 8,1 secondes et correspondait à la référence indépendante à 0.00% près sur chaque quartier.

Pour le relancer sur Münster, j'ai changé trois lignes en haut (BUILDINGS, DISTRICTS et OUT) et cliqué sur le bouton vert Run Script. Il s'est terminé en 7,4 secondes. Pour comprendre en détail le fonctionnement de processing.run, consultez notre guide PyQGIS.

Comparaison des quatre méthodes sur les deux villes

Voici ce que nous avons mesuré pour les quatre méthodes le 7 novembre 2026 :

Chaque méthode correspondait à la référence pour le nombre de bâtiments et la surface d'emprise (building_area_m2) à 0.00% près. L'écart de +0.08% sur built_up_ha pour le traitement par lots et le modeleur graphique vient de $area dans Refactor fields, qui mesure sur l'ellipsoïde du projet, alors que le script et la référence utilisaient geometry().area() en plan dans EPSG:25832.

Ce qui a cassé en cours de route (dont une réponse fausse silencieuse)

Les tutoriels montrent rarement les exécutions qui échouent, alors j'ai noté chaque erreur de la journée. L'échec le plus inquiétant n'était ni un plantage ni un bandeau d'erreur rouge : c'était un passage du modeleur graphique qui annonçait un succès et donnait une sortie fausse.

Quand j'ai lancé le modèle sans interface pour la première fois, avant de limiter les champs du nœud Intersection, le journal affichait :

Model processed OK. Executed 8 algorithm(s) total in 84.548 s.

Aucune erreur, aucun avertissement. En vérifiant le GeoPackage de sortie, built_up contenait 1 058 polygones au lieu de 10.

Voici pourquoi : les bâtiments OpenStreetMap ont leur propre colonne name (le nom d'un commerce, d'une école ou d'une église), et la couche des quartiers a aussi une colonne name. Quand Intersection a combiné tous les champs des deux couches, le name des bâtiments est resté name et le name du quartier a été renommé en silence name_2. En aval, Aggregate et Dissolve groupaient par name, donc par nom de bâtiment au lieu du quartier ! Limiter Input fields to keep d'Intersection à osm_id a évité la collision et ramené la sortie aux 10 quartiers.

Trois autres choses ont cassé, et il vaut mieux les connaître avant d'automatiser vos propres données :

• Les géométries OSM invalides arrêtent Processing par défaut. Deux des 180 602 bâtiments de Bielefeld avaient des anneaux auto-intersectés. Avec le réglage par défaut de QGIS, Clip s'arrête immédiatement avec Feature (18818404) from 'b' has invalid geometry. Lancez Fix geometries en première étape dès que vos données viennent d'OpenStreetMap brut.
• savefeatures dans PyQGIS n'aime pas les chaînes de connexion GDAL. Lors de ma première exécution du script (10,0 s), passer ogr:dbname='...' table="built_up" à native:savefeatures a provoqué OGR driver for '' not found. Passez le simple chemin .gpkg dans OUTPUT et indiquez LAYER_NAME: "built_up" comme paramètre séparé.
• Charger de nombreuses couches intermédiaires a fait planter notre session. QGIS a planté (SIGSEGV) trois fois pendant que les sorties Processing se chargeaient dans l'arbre des couches avec Load layers on completion coché. Le décocher pour les lignes de lot intermédiaires a mis fin aux plantages.

Méthode 4 : demander à un agent IA dans QGIS

Nous développons AI Agent, donc cette section parle de notre propre plugin. Il ancre un panneau de chat dans QGIS, inspecte les couches et les champs déjà présents dans votre projet, appelle lui-même les outils Processing de QGIS et PyQGIS, et vérifie la sortie avant de répondre.

Pour un travail ponctuel ou un projet sur deux villes, construire un modèle graphique à 8 nœuds ou déboguer un script de 38 lignes demande souvent plus de mise en place que la tâche n'en mérite. J'ai ouvert un projet contenant les couches buildings et districts de Bielefeld, réglé le panneau sur l'effort Medium et les permissions Balanced, et envoyé un seul message :

The project has two layers: "buildings" (OSM buildings of Bielefeld, Germany) and "districts" (its 10 city districts, the district name is in the field "name"). For each district: clip the buildings to the district, count the buildings, sum their footprint area in square meters, and build a 25 m buffer around the clipped buildings, dissolved into one built-up polygon, with its area in hectares. Measure in a metric CRS (EPSG:25832). Write one GeoPackage at [output folder]/built_up_agent.gpkg with a single polygon layer named built_up, one feature per district, fields district, building_count, building_area_m2, built_up_ha, in EPSG:25832. Then show me the result table.

(Chemins de sortie raccourcis dans les deux prompts. Note de transparence : à la toute première tentative, QGIS a planté 9 secondes après mon clic sur Send, sur un segfault de slot Qt, avant qu'une réponse n'arrive. J'ai rouvert le projet, renvoyé exactement le même prompt une fois, et ne l'ai plus renvoyé ensuite.)

En 110 secondes, l'agent a fait 27 appels d'outils (12 run_processing, 7 get_algorithm_help, 4 execute_code, 2 get_layer_info, 1 export_layer, 1 get_features), s'est remis seul d'une erreur Processing interne sans afficher de carte de permission, a écrit le GeoPackage et affiché le tableau des 10 quartiers dans le chat. Sans qu'on le lui demande, il a aussi noté dans sa réponse : « Les tampons de 25 m peuvent dépasser les limites des quartiers et se chevaucher. »

J'ai ensuite glissé muenster_buildings et muenster_districts dans le projet et tapé un message de suivi de 46 mots dans le même chat :

Now do the same for Münster. I added two layers: "muenster_buildings" and "muenster_districts" (6 districts, the name is in the field "name"). Same fields and same 25 m buffer, in a new GeoPackage at [output folder]/built_up_agent_muenster.gpkg with the layer named built_up. Then show me the result table.

Avec le premier test dans le même chat, l'agent a terminé Münster en 60 secondes avec 15 appels d'outils (11 run_processing, 1 export_layer, 1 get_features, 1 zoom_to_layer, 1 execute_code), sans aucune erreur.

Chaque nombre de bâtiments et chaque surface d'emprise correspondaient à la référence à 0.00% près sur les deux villes.

Où sont les limites ? D'abord, les valeurs built_up_ha de l'agent se situaient de 0.07% à 0.21% au-dessus de la référence plane (par exemple, Brackwede est sorti à 1,390.51 ha contre 1,388.31 ha dans la référence ; nous n'avons pas mesuré quelle étape interne cause ce petit écart). Ensuite, le GeoPackage exporté gardait une colonne _export_fid en trop. Enfin, et c'est le plus important pour l'automatisation : l'agent planifie ses étapes à neuf à chaque message (27 appels d'outils sur Bielefeld, 15 sur Münster) et tourne dans une session QGIS ouverte, il ne vous laisse donc pas de fichier .model3 ou .py à planifier sans surveillance avec cron.

Quelle méthode d'automatisation QGIS choisir ?

Plutôt que de désigner un outil gagnant, choisissez la méthode selon la fréquence à laquelle vous répéterez le travail :

• Vous lancez exactement le même outil sur 10 à 100 fichiers : utilisez le traitement par lots. Il est intégré à chaque boîte de dialogue Processing, ne coûte rien et ne demande aucun code. Arrêtez de l'utiliser dès que votre traitement enchaîne trois ou quatre outils différents.
• Vous ou votre équipe lancerez une chaîne en plusieurs étapes chaque mois, ou selon un calendrier sur un serveur : construisez-la dans le modeleur graphique. Vous obtenez un seul fichier .model3 à partager avec des collègues qui n'écrivent pas de Python, et vous pouvez l'exécuter sans interface depuis un script shell ou une tâche planifiée via qgis_process.
• Vous avez besoin de boucles sur mesure, d'un contrôle exact en plan ou de la vitesse d'exécution la plus élevée : écrivez un script PyQGIS. Notre script de 38 lignes a tourné 8 à 9 fois plus vite que le modeleur sur les deux villes.
• Vous avez une tâche complexe à lancer une fois, deux fois, ou sur quelques variantes de projet aujourd'hui : utilisez un agent IA dans QGIS comme AI Agent (ou consultez notre vue d'ensemble sur la page QGIS AI). Vous évitez de chercher les noms exacts des outils et vous relancez sur une seconde ville en une phrase. Le plan Free donne 5 tâches par mois en effort Low ; ces tests ont tourné en Medium, inclus dans Pro (49 EUR / mois HT, 300 tâches).

Comment nous avons mesuré. Tous les tests ont eu lieu le 7 novembre 2026 sur un Mac Apple Silicon (macOS 27.0.1, arm64) dans une session isolée de QGIS 3.44.15-Solothurn (Python 3.12.11) avec AI Agent 1.9.4 (effort Medium, mode Balanced). La charge de la machine a varié pendant la journée, donc comparez les durées comme des ordres de grandeur, pas comme des benchmarks CPU. Nous avons mesuré le temps d'exécution machine réel et le nombre d'étapes, pas les minutes humaines qu'il faut à un analyste SIG pour assembler un modèle ou écrire un script à partir de zéro. Toutes les données d'entrée, le fichier .model3, les scripts .py, le script de vérification de référence et les journaux JSON bruts sont conservés dans notre archive d'expérience.

Questions fréquentes

Comment automatiser un traitement répétitif dans QGIS ?

Vous avez quatre options principales selon la fréquence de répétition. Pour un seul outil sur de nombreux fichiers, cliquez sur Run as Batch Process dans la boîte de dialogue de l'outil. Pour une chaîne en plusieurs étapes que vous relancerez régulièrement, reliez les outils dans Processing > Graphical Modeler et enregistrez un fichier .model3. Pour les boucles et les meilleures performances, écrivez un script Python avec processing.run() dans la console Python de QGIS. Pour des analyses ponctuelles ou peu fréquentes où vous ne voulez ni relier des nœuds ni écrire de code, décrivez le traitement avec des mots simples dans un plugin d'agent comme AI Agent.

Faut-il utiliser le modeleur graphique de QGIS ou Python (PyQGIS) ?

Utilisez le modeleur graphique quand votre traitement est une simple chaîne d'algorithmes Processing et que vous voulez un fichier .model3 visuel que les non-programmeurs de votre équipe peuvent ouvrir, ou que vous pouvez lancer en ligne de commande avec qgis_process. Utilisez PyQGIS quand vous devez boucler sur des entités, garder les couches intermédiaires en mémoire (le script a tourné en 8,1 s contre 62,7 s pour le modèle dans notre test sur Bielefeld), gérer les erreurs dans le code ou contrôler précisément les schémas de sortie.

Peut-on exporter un modèle graphique QGIS en script Python ?

Oui. Le modeleur graphique peut exporter un modèle en script Processing Python (Export as Script Algorithm), que vous pouvez ensuite modifier pour ajouter des boucles, des variables ou une logique sur mesure. Nous n'avons pas testé l'export dans cette comparaison.

QGIS peut-il lancer des traitements automatisés selon un calendrier sans ouvrir l'application ?

Oui. QGIS est livré avec un utilitaire en ligne de commande appelé qgis_process. Vous pouvez lui passer n'importe quel algorithme natif ou n'importe quel fichier .model3 enregistré (par exemple, qgis_process run model3 --BUILDINGS=... --DISTRICTS=... --built_up=...) depuis un script bash, le Planificateur de tâches Windows ou une tâche cron, sans lancer l'interface graphique de QGIS. Dans notre test sur Bielefeld, le modèle a tourné sans interface via qgis_process en 44,5 secondes.

Essayer AI Agent gratuitement

À lire ensuitePyQGIS : automatiser QGIS avec Python, avec ou sans code