GISPulse vs QGIS Processing : complementaires, pas concurrents

QGIS est l'un des meilleurs logiciels SIG open-source. Son framework Processing est puissant, extensible, et gratuit. Alors pourquoi GISPulse existerait-il ? La reponse est simple : QGIS Processing n'a pas ete concu pour l'automatisation headless, les APIs, ou les pipelines CI/CD. GISPulse oui.

Ce que QGIS Processing fait tres bien

QGIS Processing est un framework de geotraitement qui s'appuie sur une interface graphique riche. Ses points forts :

Algorithmes integres — Buffer, clip, union, dissolve, spatial join... des centaines d'algorithmes disponibles sans ecrire une ligne de code.
Modeler graphique — Enchainer des traitements visuellement dans une interface drag-and-drop.
Scripts Python — Possibilite d'ecrire des algorithmes custom en PyQGIS.
Acces aux providers — GDAL, GRASS, SAGA, Orfeo Toolbox... tous accessibles depuis la meme interface.
Facilite d'acces — Aucune configuration serveur. Ouvrez QGIS, lancez un traitement.

Pour un analyste SIG qui travaille en mode interactif — exploration de donnees, validation visuelle, traitements one-shot — QGIS Processing est souvent suffisant et pertinent.

Ou QGIS Processing atteint ses limites

Le framework Processing a ete concu pour l'interactivite dans un contexte desktop. Cela implique plusieurs contraintes structurelles :

Pas de mode headless natif

Executer un algorithme QGIS Processing sans interface graphique est possible via qgis_process (depuis QGIS 3.14), mais :

Necessite une installation QGIS complete (X11 ou Qt minimal)
Pas de daemon, pas de service HTTP
La configuration de l'environnement est fragile en CI/CD
Le startup time est de l'ordre de 3-10 secondes par invocation

bash

# qgis_process — fonctionne, mais fragile en automatisation
qgis_process run qgis:buffer -- \
  INPUT=/data/parcelles.gpkg \
  DISTANCE=100 \
  OUTPUT=/data/parcelles_buffer.gpkg

Pas d'API REST native

Il n'existe pas d'API REST standard pour QGIS Processing. Des projets comme QgsServer exposent le WPS, mais ce n'est pas une API REST moderne (pas de JSON, pas de webhooks, pas de gestion de jobs asynchones).

Pas de regles versionnables nativement

Les modeles Processing sont des fichiers XML (.model3) ou des scripts Python. Ils ne sont pas des configs declaratives portables :

Un modele .model3 contient les geometries de l'UI, pas seulement la logique
Un script PyQGIS est du code imperatif
Partager un workflow avec un colleguene = partager un fichier XML ou du code

Pas de scheduling integre

QGIS Processing n'a pas de scheduler. Pour automatiser un traitement toutes les heures, vous devez passer par un cron + un script bash qui invoque qgis_process, ce qui pose les problemes de headless mentionnes ci-dessus.

Ce que GISPulse apporte en complement

GISPulse a ete concu pour les cas ou QGIS Processing n'est pas adapte.

Headless par design

GISPulse est un moteur Python pur. Aucune dependance graphique. Installez-le avec pip et lancez-le sur n'importe quelle machine, container Docker, ou runner CI/CD :

bash

pip install gispulse

# Traitement immediat, aucun X11, aucun Qt
gispulse run rules.json --input parcelles.gpkg

Startup time : < 200ms pour le mode DuckDB portable.

Regles JSON declaratives

Un pipeline GISPulse est un fichier JSON qui decrit les traitements dans l'ordre :

json

[
  {
    "name": "parcelles_buffer",
    "capability": "buffer",
    "params": {
      "input": "parcelles.gpkg",
      "distance": 100,
      "unit": "meters"
    }
  },
  {
    "name": "parcelles_en_zone_risque",
    "capability": "spatial_join",
    "params": {
      "input": "parcelles_buffer",
      "ref_layer": "zones_risque.gpkg",
      "predicate": "intersects",
      "columns": ["niveau", "date_arrete"]
    }
  }
]

Ce fichier est :

Versionnable sous Git (diff lisible)
Partageable sans dependances
Executable par un non-developpeur via CLI
Consommable via API REST ou SDK Python

API REST incluse

GISPulse expose une API REST FastAPI :

bash

# Demarrer le serveur
gispulse serve --port 8000

# Soumettre un job
curl -X POST http://localhost:8000/jobs \
  -H "Content-Type: application/json" \
  -d @rules.json

# Verifier le statut
curl http://localhost:8000/jobs/abc123/status

Scheduling natif

Planifiez des traitements recurrents directement dans la configuration :

json

{
  "schedule": "0 6 * * 1",
  "pipeline": "validation_cadastrale.json",
  "notify": "webhook:https://hooks.slack.com/..."
}

Tableau comparatif

Critere	QGIS Processing	GISPulse
Interface graphique	Oui (natif)	Non (Portal Web separement)
Mode headless	Partiel (qgis_process)	Oui (natif)
API REST	Non (WPS uniquement)	Oui (FastAPI)
Regles declaratives	Non (XML / Python)	Oui (JSON)
Versionnable Git	Difficile	Natif
Scheduling	Non	Oui (cron integre)
SDK Python	PyQGIS (complexe)	SDK minimal inclus
Docker / CI/CD	Fragile	Natif
Acces GRASS/SAGA/GDAL	Oui	Via PostGIS + extensions
Analyse interactive	Excellent	Non (usage CLI/API)
Courbe d'apprentissage	Douce (GUI)	Douce (JSON)

Le plugin QGIS : le meilleur des deux mondes

GISPulse dispose d'un plugin QGIS officiel qui fait le pont entre les deux ecosystemes.

Ce plugin vous permet de :

Executer des regles GISPulse depuis QGIS — sans quitter votre environnement de travail
Charger les resultats directement dans le projet courant — les couches apparaissent dans le panneau des couches
Editer les regles JSON dans une interface assistee — formulaire avec autocompletion des capabilities et des parametres
Envoyer un job a un serveur GISPulse distant — API REST ciblee depuis QGIS

python

# Depuis la console Python QGIS
from gispulse.qgis import GISPulseRunner

runner = GISPulseRunner(server="http://gispulse.votre-org.fr")
result = runner.run("rules/validation_cadastrale.json")
iface.addVectorLayer(result["output_path"], "Validation", "ogr")

Le workflow typique devient :

Explorez vos donnees dans QGIS (interface graphique, visuels)
Identifiez le traitement a automatiser
Transformez-le en regles GISPulse JSON (le plugin aide)
Deployez les regles sur votre serveur GISPulse
Schedulez l'execution et recevez les notifications

Quand choisir quoi ?

Choisissez QGIS Processing si :

Vous faites de l'analyse exploratoire ad hoc
Vous avez besoin d'une visualisation immediate du resultat
Le traitement est one-shot et ne sera pas repete
Votre equipe est a l'aise avec l'interface QGIS
Vous avez besoin d'acces a GRASS, SAGA, ou Orfeo Toolbox

Choisissez GISPulse si :

Vous devez automatiser un traitement recurrent (quotidien, sur evenement)
Vous voulez versionner vos workflows sous Git
Vous integrez un traitement dans un pipeline ETL ou une application
Vous avez besoin d'une API REST pour declencher des jobs
Vous deployez sur un serveur, un container Docker, ou en CI/CD
Votre equipe preference les configs JSON au code imperatif

Utilisez les deux si :

Vous explorez dans QGIS, puis automatisez avec GISPulse
Votre equipe a des profils mixtes (GIS analysts + data engineers)
Vous voulez un pont entre l'analyse interactive et la production

Migration d'un modele Processing vers GISPulse

Vous avez un modele QGIS Processing existant que vous voulez automatiser ? La migration est generalement directe.

Un modele Processing typique (buffer + spatial join) :

xml

<!-- model.model3 (XML simplifie) -->
<model>
  <algorithm id="buffer">
    <parameter name="INPUT" value="parcelles"/>
    <parameter name="DISTANCE" value="100"/>
  </algorithm>
  <algorithm id="joinattributesbylocation">
    <parameter name="INPUT" value="buffer_output"/>
    <parameter name="JOIN" value="zones_risque"/>
  </algorithm>
</model>

Son equivalent GISPulse :

json

[
  {
    "name": "buffer_parcelles",
    "capability": "buffer",
    "params": { "input": "parcelles.gpkg", "distance": 100 }
  },
  {
    "name": "join_risque",
    "capability": "spatial_join",
    "params": {
      "input": "buffer_parcelles",
      "ref_layer": "zones_risque.gpkg",
      "predicate": "intersects"
    }
  }
]

La logique est identique. Le format JSON est plus lisible, plus compact, et versionnable.

Conclusion

QGIS Processing et GISPulse ne se font pas concurrence — ils repondent a des besoins differents dans le cycle de vie d'un workflow spatial.

QGIS est l'outil d'exploration et d'analyse interactive. GISPulse est le moteur d'automatisation et de deploiement. Le plugin QGIS fait le pont.

La combinaison des deux vous donne un workflow moderne : explorez dans QGIS, automatisez avec GISPulse, versionez sous Git.

Commencer avec GISPulse

bash

pip install gispulse
gispulse --help

Documentation complete · Plugin QGIS · GitHub

GISPulse vs QGIS Processing : complementaires, pas concurrents ​

Ce que QGIS Processing fait tres bien ​

Ou QGIS Processing atteint ses limites ​

Pas de mode headless natif ​

Pas d'API REST native ​

Pas de regles versionnables nativement ​

Pas de scheduling integre ​

Ce que GISPulse apporte en complement ​

Headless par design ​

Regles JSON declaratives ​

API REST incluse ​

Scheduling natif ​

Tableau comparatif ​

Le plugin QGIS : le meilleur des deux mondes ​

Quand choisir quoi ? ​

Migration d'un modele Processing vers GISPulse ​

Conclusion ​

GISPulse vs QGIS Processing : complementaires, pas concurrents

Ce que QGIS Processing fait tres bien

Ou QGIS Processing atteint ses limites

Pas de mode headless natif

Pas d'API REST native

Pas de regles versionnables nativement

Pas de scheduling integre

Ce que GISPulse apporte en complement

Headless par design

Regles JSON declaratives

API REST incluse

Scheduling natif

Tableau comparatif

Le plugin QGIS : le meilleur des deux mondes

Quand choisir quoi ?

Migration d'un modele Processing vers GISPulse

Conclusion