Développer un plugin Isogeo sur QGIS : un retour d’expérience (partie 1/2)

L’un des axes de la vision d’Isogeo est de développer les usages au-delà du catalogage, notamment via notre API : les métadonnées ne sont pas une fin, mais un moyen. C’est dans cette optique que s’inscrivent les plugins et widgets destinés à faciliter la découverte et l’usage des données directement dans votre SIG préféré.

Quelques mois après la mise en production du plugin Isogeo dans QGIS, c’est avec un recul nécessaire que cet article donne à voir les différents aspects du développement (objectifs, phases, méthodes, choix…). L’idée est de partager notre retour d’expérience en espérant qu’il profite à d’autres qui souhaiteraient se lancer dans l’aventure !

Ce logo n’a pas été réalisé sous Qt

Cet article a été écrit principalement par Théo Sinatti sous la forme d’un retour d’expérience, et a été remanié et complété par Julien Moura et Clotilde Pinault. 

Développer le plugin à Isogeo

Le choix de le développer en interne s’est fait pour plusieurs raisons :

  • tout d’abord, notre envie de faire par nous-mêmes. Isogeo est un éditeur logiciel et a, à ce titre, un appétit et une curiosité à satisfaire, et un intérêt à monter en compétences et engranger de l’expérience sur l’un des outils emblématiques de notre écosystème ;
  • c’est aussi l’occasion rêvée de démontrer les capacités de notre API et plus largement d’illustrer concrètement notre vision sur les métadonnées, si souvent décriées. Celle d’ajouter un maillon à la chaîne de valeur de notre plate-forme en réalisant la voie de valorisation naturelle du catalogage des données géographiques , à savoir l’ajout pour consultation dans un SIG.
  • engagés dans la diffusion de notre API, il s’agissait aussi de mettre en ligne un exemple en termes fonctionnels mais aussi techniques (sécurité, bonnes pratiques, manipulation de notre modèle métier, …). De manière à pouvoir fournir un socle pratique aux partenaires, clients ou développeurs tiers intéressés, le code étant accessible en public (open source) et ouvert à réutilisation (libre).
  • c’est aussi pour une raison toute rationnelle, celle de la balance coûts entre le développement externalisé ou internalisé. Les compétences étaient présentes en internes mais peu disponibles en termes de temps (gestion de projet oblige). C’était aussi l’occasion de mettre en oeuvre l’implication traditionnelle d’Isogeo dans le milieu universitaire (ENSG, ESIPE…) en proposant un stage dans lequel Isogeo avait une vraie valeur ajoutée à apporter à un stagiaire (expérience, intérêt, autonomie, encadrement bienveillant et compétent, etc.). 
Un aperçu du plugin

Le plugin, de la conception à la livraison : mode d’emploi

Si l’idée d’un plugin QGIS avait eu le temps de mûrir au sein d’Isogeo bien avant mon arrivée, le contour précis du projet n’avait pas encore été tracé. Il m’a donc fallu définir quel était le besoin, aussi bien au sein d’Isogeo qu’auprès de ses clients, les utilisateurs finaux du plugin. Le projet à mener était donc complet, de sa conception à son développement, en prenant en compte les retours intermédiaires des utilisateurs.

La faisabilité technique avait été validée via la réalisation d’une POC au noël 2015.

Les besoins clients étaient concrétisés par une commande (SMAVD), bientôt doublée d’une autre (CA Lorient).

Comprendre les besoins

Pour comprendre au mieux quels étaient les besoins et les attentes des clients d’Isogeo par rapport au plugin QGIS (et de manière plus générale, à un plugin SIG), la première étape a été pour moi la réalisation d’un questionnaire. Son but était de guider des entretiens auprès de clients ayant accepté d’y participer, et de permettre de répondre à un maximum de questions fonctionnelles. Grâce à cette enquête utilisateur, j’ai pu trancher des questions fondamentales, comme les filtres de recherche à privilégier au niveau de l’interface, ou les informations à faire apparaître dans la description succincte des résultats de recherche.

L’analyse de ces résultats, la réflexion autour de ceux-ci, et leur reformulation sous forme de spécifications fonctionnelles ont abouti à la définition du produit minimum viable. Ce produit minimum correspond à l’ensemble des fonctionnalités nécessaires à ce que le produit réponde scrupuleusement aux besoins établis, sans aucun supplément. Il s’agit donc du stade minimale à partir duquel le produit peut être considéré comme satisfaisant.

Développer

Méthodologie retenue

Le but de mon stage était d’obtenir, de manière itérative, un produit au plus proche des besoins d’un utilisateur, afin qu’il soit attractif, et non de créer un objet au champ fonctionnel pré-établi et figé. Afin d’intégrer continuellement les retours utilisateurs, le choix de l’agilité était une évidence. C’est pour cette raison que mon développement s’est composé de cycles découpés selon la méthode Kanban. J’ai ainsi pu développer chaque nouveau champ de fonctionnalité tout en intégrant les retours des bêta testeurs dans des cycles relativement courts (2 semaines).

Aucun Post-It(r) n’a été maltraité pendant le développement

En mode bac à sable

Une fois les besoins des utilisateurs finaux consolidés, le développement pouvait commencer. Enfin plus exactement, la phase de spécifications fonctionnelles et techniques ! Cela s’est fait durant une phase de «sandbox » d’environ un mois (juin 2016), destinée à :

  • valider les réponses techniques aux demandes fonctionnelles (est-ce possible de faire ce qui est demandé ? si oui, comment ? si non, pourquoi et comment faire autrement ?) ;
  • me familiariser avec l’API Python de QGIS (PyQGIS) ;
  • ainsi qu’avec Qt 4, la version du framework d’interface graphique Qt utilisée par QGIS ;
  • apprendre à dialoguer avec l’API Isogeo.
L’artiste au travail (photo non contractuelle)

Mon premier château !

Peu après le début du mois de juillet a commencé la phase de développement actif du plugin, avec pour objectif d’aboutir le plus rapidement possible à une première version fonctionnelle du plugin, correspondant au périmètre de ce qui avait été défini comme produit minimum.

Ce “minimum” n’est cependant pas synonyme d’une version tronquée, le nombre de fonctionnalités retenues étant somme toute assez important. Il a donc été décidé de mener une phase de bêta fermée, durant laquelle ont été  régulièrement publiées (dans le canal des extensions expérimentales de QGIS) des pré-versions au champ fonctionnel incomplet ou non abouties. Cette phase de bêta fermée n’était accessible qu’aux clients ayant participé au financement du plugin. De fin juillet à début septembre, 4 pré-versions ont été diffusées aux participants à cette phase fermée.

De la version sable à la version stable

Le 19 septembre, la version 1 du plugin a donc été publiée sur le canal des extensions stables de QGIS. Dès lors, il a pu être testé par un plus grand nombre de clients d’Isogeo, multipliant les retours d’utilisation pour nourrir les cycles de développement suivants.

Le mois de validation d’aptitude (VA) convenu avec les clients, a été l’occasion de repérer les erreurs de jeunesse et de publier une version 1.1 dès le mois d’octobre, suivie d’une version 1.2 comme cadeau de fin d’année (avec documentation utilisateur complète et mention des sponsors).

Aujourd’hui, une version 1.5 attendue pour la fin avril 2017, tient compte de cas particuliers et enrichit légèrement le champ fonctionnel, grâce à de nouvelles commandes clients.

La suite concernant l’expérience de développement en tant que telle arrivera au prochain épisode. A la semaine prochaine !

Un commentaire

Laisser un commentaire

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

Unable to load the Are You a Human PlayThru™. Please contact the site owner to report the problem.