[FR]Développer un plugin QGIS – appliquer une logique métier aux valeurs saisies


Récupérer des valeurs depuis une interface de plugin QGIS est une étape importante, mais ce n’est qu’un début. La vraie question est : que faire de ces valeurs ?

Dans cet article, nous allons voir comment appliquer une logique métier simple aux données saisies par l’utilisateur, afin de transformer une interface statique en un plugin QGIS réellement fonctionnel. L’objectif n’est pas d’écrire du code complexe, mais de comprendre où placer la logique, comment la structurer, et comment éviter les erreurs classiques quand on débute.



Appliquer une logique métier aux valeurs saisies dans un plugin QGIS

Dans l’article précédent, nous avons vu comment récupérer les valeurs saisies par l’utilisateur depuis une interface (champ texte, liste déroulante, case à cocher…).

Dans cet article, nous passons à l’étape suivante : donner du sens à ces valeurs.
C’est ici qu’intervient la logique métier du plugin.


1. Qu’appelle-t-on “logique métier” dans un plugin QGIS ?

La logique métier correspond à l’ensemble des règles, calculs et décisions qui transforment des valeurs saisies en une action concrète.

Dans un plugin QGIS, cela peut être par exemple :

  • vérifier que des valeurs sont cohérentes entre elles,
  • calculer un seuil, une distance, un indice,
  • décider si une opération doit être lancée ou refusée,
  • transformer une saisie utilisateur en paramètres exploitables par QGIS.

Règle clé : la logique métier ne dépend pas de l’interface graphique. Elle doit pouvoir être comprise indépendamment des boutons et des champs.


2. Séparer interface et logique (sans complexité inutile)

Un plugin bien structuré repose sur une séparation simple :

  • Interface : collecte des valeurs (dialog, widgets)
  • Logique métier : traitement et validation des valeurs
  • Action QGIS : modification des couches, entités ou projets

Même dans un plugin simple, adopter cette séparation évite rapidement :

  • les bugs difficiles à comprendre,
  • le code dupliqué,
  • les interfaces impossibles à faire évoluer.

Concrètement, cela signifie que le slot du bouton ne fait presque rien :

  1. récupérer les valeurs,
  2. appeler une fonction de logique métier,
  3. réagir au résultat.

3. Exemple simple de logique métier

Imaginons un plugin avec :

  • une valeur numérique saisie par l’utilisateur,
  • un choix dans une liste déroulante.

Avant toute action, on souhaite :

  • vérifier que la valeur est positive,
  • appliquer un coefficient selon le choix utilisateur.

La logique métier peut alors être isolée dans une fonction dédiée :

 def calculer_valeur(valeur, mode):
     if valeur <= 0:
         raise ValueError("La valeur doit être positive")

     if mode == "simple":
         return valeur
     elif mode == "double":
         return valeur * 2
     else:
         raise ValueError("Mode inconnu")

Cette fonction :

  • ne connaît rien de QGIS,
  • ne connaît rien de l’interface,
  • fait une seule chose, clairement définie.

4. Gérer les erreurs intelligemment

Une logique métier robuste doit anticiper les erreurs.

Deux approches sont possibles :

  • retourner un résultat + un état (succès / échec),
  • lever des exceptions et les intercepter côté interface.

Dans un plugin QGIS, la seconde approche est souvent plus lisible :

  • la logique métier signale un problème,
  • l’interface décide comment l’afficher à l’utilisateur.

Cela permet par exemple :

  • d’afficher un message clair,
  • de bloquer l’exécution sans planter le plugin,
  • de guider l’utilisateur vers une correction.

5. Relier la logique métier à l’interface

Dans le slot du bouton, le rôle est volontairement limité :

 def on_run_clicked(self):
     try:
         valeur = self.spinBoxValeur.value()
         mode = self.comboBoxMode.currentText()

         resultat = calculer_valeur(valeur, mode)

         self.appliquer_resultat(resultat)

     except ValueError as e:
         QMessageBox.warning(self, "Erreur", str(e))

Ce code est lisible car :

  • chaque étape est explicite,
  • les responsabilités sont bien séparées,
  • la logique métier reste testable indépendamment.

Logique métier ≠ code compliqué

Quand on débute le développement de plugins QGIS, on associe souvent la notion de logique métier à quelque chose de complexe ou réservé aux développeurs expérimentés. En réalité, ce n’est pas la complexité du code qui définit la logique métier, mais l’intention derrière le traitement.

Une logique métier simple peut se résumer à :

  • vérifier qu’une valeur est valide,
  • appliquer une règle claire,
  • décider si une action est autorisée ou non.

Quelques lignes bien structurées, lisibles et isolées dans une fonction valent mieux qu’un long bloc de code mélangé à l’interface.

Si vous comprenez pourquoi vous appliquez une règle, alors vous êtes déjà en train d’écrire de la logique métier.


6. Pourquoi cette étape est essentielle

C’est à ce stade que beaucoup de plugins deviennent :

  • soit fragiles et difficiles à maintenir,
  • soit au contraire clairs, extensibles et fiables.

En isolant la logique métier :

  • vous pouvez la faire évoluer sans toucher à l’interface,
  • vous pouvez ajouter des règles sans réécrire le plugin,
  • vous préparez naturellement les articles suivants.

À retenir

  • la logique métier donne du sens aux valeurs saisies,
  • elle doit être séparée de l’interface graphique,
  • elle doit gérer les erreurs explicitement,
  • c’est le cœur réel de votre plugin.

Dans le prochain article, nous verrons comment appliquer cette logique métier à des couches et des entités QGIS, et passer enfin à l’action sur les données.


Si cet article vous a intéressé et que vous pensez qu'il pourrait bénéficier à d'autres personnes, n'hésitez pas à le partager sur vos réseaux sociaux en utilisant les boutons ci-dessous. Votre partage est apprécié !

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Are you human? Please solve:Captcha