Le portail francophone de la géomatique

Hello Axelrps,

De ce que je comprends de votre message, la seule brique qui ne soit pas open source dans votre SIG est l'application Business Geographic.

Cela simplifie grandement les choses si toutes vos données sont déjà regroupées dans la même base PostgreSQL et si vos utilisateurs sont déjà habitués à utiliser QGIS.

Il existe des solutions web open source, comme QWC, qui peuvent s'appuyer directement sur les données déjà présentes dans PostgreSQL.

Pour notre part, à Strasbourg, nous migrons depuis maintenant deux an notre ancien SIG Elyx/Oracle vers QGIS/PostgreSQL. Les deux systèmes ont d'ailleurs cohabité pendant plusieurs années.

Les principales difficultés que nous avons rencontrées proviennent surtout du fait que les données doivent être transférées depuis une base Oracle utilisant un modèle de données Elyx, parfois assez complexe, vers PostgreSQL, ce qui nécessite de nombreuses adaptations. Nous avons également dû reprendre certains développements métiers très spécifiques qui avaient été réalisés sur Elyx.

Un accompagnement a également été nécessaire pour former les agents habitués à Elyx afin qu'ils puissent prendre en main QGIS.

À l'heure actuelle, nous conservons encore quelques briques non libres, notamment FME pour les géotraitements et Opendatasoft pour la partie Open Data.

Concernant les délais, je dirais que cela dépend grandement de la taille de votre structure, du volume de données SIG à migrer et de la nécessité ou non de mettre en place des adaptations pour certains SIG métiers.

Enfin, en passant sur des solutions open source, même si les logiciels n'ont généralement pas d'éditeur attitré, il reste tout à fait possible de se faire accompagner par une société spécialisée dans le cadre d'un marché, notamment pour les développements spécifiques ou pour l'assistance à la gestion du projet.

Je ne sais pas si ma reponse à pu vous éclairer un peu, n'hésiter pas à me contacter si jamais vous avez plus de questions.

Cordialement, Clément.

Selon moi, la force de FME reste le fait que ca soit simple à utiliser pour un utilisateur moins à l'aise avec les outils en ligne de commandes ou Python.

Pour ma part je préfère utiliser python en tant qu'outils de geotraitement.

Une autre alternative pour être le model builder de Qgis qui a pas mal évolué des dernières années. je sais que plusieurs services techniques l'utilisent chez nous pour leur traitements.

Je suis plutôt d'accord avec le fait que FME permet d'accompagner les utilisateurs qui n'ont pas à la base de compétences en développement. Mais à quel prix !
Ceci dit, il est possible d'acquérir des compétences en développement par de la formation initiale (via des cursus de licence / master) ou continue (notamment via des prestataires). On voit bien d'ailleurs que certains profils de géomaticiens mutent depuis 10 ans pour prendre une part importante des tâches techniques initialement réservées aux DSI (pour du développement, maintenance des systèmes, etc.)

Et effectivement, pour les personnes qui ne rentrent pas dans cette case, le model builder de QGIS est monté en puissance depuis quelques temps, et c'est prometteur !


Pour compléter le propos sur FME, il existe aussi d'autres outils et langages comme alternatives :
- GDAL/OGR pour convertir des formats de données
- SQL et PL/PgSQL pour faire des (géo)traitements

Au delà de leur efficacité et de la richesse de leurs fonctionnalités, c'est l'avantage de pouvoir partager les méthodes gratuitement via un simple fichier texte ou un dépôt Git.

Côté échirollois, on a opté pour [G3W](https://v311.g3wsuite.it/en/map/demo-31/), une autre solution webcarto basée sur QGIS.
Et j'ai entendu parler d'une autre solution prometteuse (également basée sur QGIS) qui sort tout prochainement sa v1 : [Georama](https://demo.georama.io/) développée par la même entreprise que QFieldCloud. A suivre !

Dernière modification par Eric Vinouze (Mon 13 July 2026 10:26)