Cet article est le dernier de la série consacrée à la collaboration avec Soilcloud et Apeiron, dont nous vous aviez fait part dans un précédent article, et à travers laquelle nous avions souligné l’importance de SFCGAL et de Giro3D.
Nous allons reparler ici du projet Albion, bien connu des utilisateurs de QGIS dans le minier !
Passer d’un projet client à un produit n’est jamais facile, passer d’une application desktop au web non plus, combiner les deux est un véritable challenge !
Albion, qu’est-ce que c’était ?
Albion est né sous forme de plugin QGIS, en 2017, pour répondre à un besoin d’exploration minier exprimé par Orano.
Vue synthétique du plugin QGIS Albion
Albion reposait déjà sur une base PostgreSQL/PostGIS, et s’inscrivait dans la mouvance des bases épaisses, stratégie de modélisation dans laquelle l’intelligence métier est placée du côté de la base de données plutôt que du côté applicatif, avec un maximum de contraintes d’intégrité, et une grande place laissée aux triggers pour l’insertion, la mise à jour et la suppression de données.
Pour avoir une idée du contenu du plugin, la vidéo de présentation du projet par Vincent Mora au FOSS4G 2018 est un incontournable.
Le projet Albion historique était porté par Orano, qui a accompagné son développement jusqu’en 2021. Puis faute de financeurs, notamment pour améliorer les problématiques d’installation et de packaging, aucune nouvelle contribution n’est intervenue depuis. Aujourd’hui, le projet hébergé sur gitlab.com n’est plus maintenu.
Albion, qu’est-ce que c’est aujourd’hui ?
Le projet est donc revenu sur le devant de la scène en 2024, poussé par le besoin exprimé par Soilcloud, cette fois-ci dans le secteur de la géotechnique.
Exit QGIS, Albion se présente désormais sous la forme d’une API HTTP, associée à un backend Python et une base PostgreSQL/PostGIS.
](https://oslandia.com/wp-content/uploads/2026/09/albion_mansfield_middle.png)
Albion web: modélisation 3D du sous-sol via une API HTTP, et visualisation via [Piero](https://giro3d.org/piero.html)
Même si elle n’est plus aussi « épaisse » que par le passé, la base PostGIS conserve la substantifique moëlle du modèle de données. Les calculs géométriques étant assurés tantôt directement dans la base, tantôt via PySFCGAL, le binding Python de SFCGAL.
De fait, le plugin QGIS n’existe plus dans la nouvelle version, mais rien de rédhibitoire : en l’état, il suffirait de redévelopper une IHM, et de se brancher à l’API. Dans cette nouvelle architecture, le plugin QGIS serait un client consommateur de l’API, plutôt que la pièce centrale de l’édifice.
Autre différence fondamentale : alors que la première mouture d’Albion était développée comme un projet spécifique au besoin d’un client, le nouvel Albion passe en mode produit, sous la houlette d’Apeiron !
Le choix cornélien de la refonte
Au redémarrage du projet en 2024, après une phase d’étude permettant de valider la réutilisation du moteur de calcul pour le nouveau besoin à couvrir, s’est posée la question de la pérennité du code source déjà en place. Que garder ? Garde-t-on seulement quelque chose de l’ancienne version ?
Devait-on recycler l’existant, ou repartir de zéro ? Quelle solution est la plus pragmatique ? La plus réaliste ? Bien entendu, répondre à ces questions sans parler de budget disponible, ni de retour sur investissement attendu est une sinécure…
Il est forcément tentant de faire ce que tout projet de refonte considère à un moment ou à un autre, par facilité : tout brûler, et repartir d’une page vierge. Les difficultés de maintenance de la première version d’Albion faisaient pencher la balance vers cette option. D’autant que la feuille de route initiale pour cette relance s’est fixé sur un périmètre fonctionnel finalement assez réduit par rapport aux capacités du projet initial. Les années passant, se posait aussi la question de la perte de compétence sur le projet : les contributeurs de 2021 ne sont plus ceux de 2017, et le coeur du plugin n’était finalement plus réellement maîtrisé.
Ceci dit, difficile de passer par pertes et profits la base de données, et plus spécifiquement la richesse du moteur de calcul…
La réponse à ce dilemme est finalement passée par une démarche d’ingénierie : découper le fonctionnel, arbitrer sur chaque bloc du projet, et séparer clairement les responsabilités, du côté de l’architecture du projet :
- L’API sert de passe-plat, les clients doivent passer par là pour envoyer de la donnée et récupérer des résultats de simulation.
- La base de données, identifiée comme ayant la plus forte valeur ajoutée, a été repensée à partir du squelette XplorDB, pour assurer la compatibilité de long terme avec les autres projets d’Apeiron, les différents objets-clés du modèle Albion étant réécrits autour de ce noyau. Une partie des comportements issue de la base épaisse a été conservée dans la base sous forme de fonctions SQL appelées par le backend.
- Le backend Python permet de relier les deux premiers blocs, et d’opérer la plupart des calculs géométriques, avec l’appui de PySFCGAL.
- Les applications consommatrices sortent du périmètre d’Albion, on les imagine désormais comme étant soit de la responsabilité du client (l’API Albion est ainsi requêtée par la plateforme Soilcloud), soit comme des projets additionnels portés par Apeiron (à l’image de l’appli Piero décrite dans le précédent article, ou comme le potentiel futur plugin QGIS évoqué plus haut).
Une autre histoire de renaissance
Finalement, l’histoire d’Albion suit de près celle de SFCGAL, le second ayant toujours eu un rôle critique pour le premier. La période entre 2020 et 2023, soit grosso modo la transition entre les deux vies d’Albion, a marqué un temps faible du développement de SFCGAL.
La relance de SFCGAL bénéficie forcément à Albion : plus de stabilité avec un gros travail sur la chaîne d’intégration, l’ajout de nombreuses fonctionnalités désormais utilisée côté Albion. Nul doute que la réussite du projet doit aussi sa juste part aux contributeurs SFCGAL !
Ainsi va la vie des projets informatiques !
Conclusion
Comme nous l’avons vu dans cet article, les refontes logicielles peuvent permettre de faire rebondir des projets informatiques en perte de vitesse, en améliorant le produit en tant que tel, mais aussi en le repensant pour des cibles différentes de celles initialement visées.
C’est également un bon rappel de l’importance critique de l’architecture logicielle, a fortiori à une époque où la production de code en tant que telle connaît d’importants bouleversements avec l’avènement des IA génératives.
Quoiqu’il en soit, la renaissance d’Albion nous a fait particulièrement plaisir à Oslandia, comme c’était un des projets que nous appréciions particulièrement en interne lors de sa première vie ! C’est de fait l’occasion de saluer Vincent Mora et Emmanuel Duguey, à l’origine de la première version d’Albion, et de remercier Soilcloud et Apeiron pour nous avoir permis de relancer ce beau projet !
Si ce cas d’usage vous interpelle, ou si l’exploitation de données géospatiales en 3D vous intéresse, n’hésitez pas à nous en faire part en nous écrivant à infos@oslandia.com !
