Mises à jour des services
De manière générale, les services que l’on vous propose sont mis à jour automatiquement quand de nouvelles versions correctives sont disponibles. C’est le cas par exemple, quand Lizmap passe de la version 3.9.0 à 3.9.1. Il en va de même pour Qgis (3.44.0 à 3.44.1 par exemple) ou de Postgresql (17.0 à 17.1 par exemple).
Mais ce n’est pas automatique pour passer à des versions majeures ou mineures. En effet, selon ce que ces nouvelles versions proposent, elles peuvent apporter des modifications profondes qui nécessitent des modifications dans vos themes Lizmap, vos scripts Javascript pour Lizmap, vos projets Qgis, ou encore dans les fonctions SQL de Postgis.
C’est pourquoi le passage à ces versions majeures et mineures nécessitent un accord de votre part.
De manière générale quand les mises à jour sont proposées, c’est qu’une batterie de tests a été effectué pour s’assurer de la compatibilité avec les modules complémentaires et avec QGIS.
Demande de montée de versions pour Lizmap ou Qgis
Quand une nouvelle version de Lizmap ou Qgis est disponible, des boutons apparaissent dans l’interface d’administration de Lizmap pour demander une montée de version. Cette demande est automatiquement enregistrée et notifiée (à notre équipe et à vous-même), mais n’est pas réalisée immédiatement.
Généralement la mise à jour est réalisée assez vite par notre équipe, le jour même ou le lendemain, selon les éventuels urgences ou impondérables.
Les mises à jour Lizmap ou Qgis génère une coupure de services de quelques secondes seulement.
La mise à jour Lizmap est irréversible. Vous devrez vérifier et peut-être adapter vos themes et scripts JS. Si vous avez la possibilité d’avoir plusieurs Lizmap dans l’abonnement que vous avez choisi, il est recommandé d’utiliser un des Lizmap pour tester vos themes, scripts et projets avant de basculer l’ensemble de vos Lizmap vers la nouvelle version.
La mise à jour de QGIS peut éventuellement être inversée, mais l’interface ne permet pas d’en faire la demande. Nous considérons que le version de QGIS LTR la plus récente est toujours plus pertinente que la précédente.
Après une mise à jour de QGIS, il est conseillé d’avoir des projets générés avec une version identique de QGIS bureautique (et donc de les mettre à jour), pour des raisons de performances. Mais en attendant, QGIS et Lizmap arrivent à interpréter correctement les projets d’une version précédente.
Montée de version de Postgresql
La mise à jour vers une version majeure de Postgresql (par exemple de 16 à 17), est toujours une opération chronophage, car il faut passer par un processus de migration des bases de données qui peut être plus ou moins long selon le volume de vos données, la puissance du materiel, mais aussi selon les modifications de stockage interne apportées par la nouvelle version de Postgresql. Cela peut durer de 5 minutes à quelques heures.
Il est aussi déjà arrivé qu’une montée de version de Postgis (par exemple de la version 2 à la version 3) impose des changements dans les procédures stockées ou requêtes SQL (fonctions dépréciées qui sont retirées etc), ce qui nécessite une intervention de votre part.
En effet, nous ne touchons pas au contenu de vos bases de données, à moins de nous demander de le faire via une prestation payante.
C’est pourquoi la montée de version de Postgres est en général une opération que l’on fait uniquement sur demande, ou lors d’un changement d’offre.
Il peut cependant que l’on fasse la montée de version de notre propre initiative, quand la version utilisée n’est plus maintenue par les développeurs de Postgresql ou trop vieille, et seulement si nos outils de migrations ne détectent aucun problème dans le contenu de votre base de données ou ne détectent pas de modifications à faire qui nécessiterait une intervention de votre part.
Dans tous les cas nous vous prevenons, et nous décidons avec vous d’une date d’intervention.
Montée de version des autres services
En ce qui concerne les autres services que nous proposons, comme QfieldCloud ou Superset, là aussi, les montées de versions correctives sont transparentes pour vous, mais pour les montées de versions majeures, nous décidons avec vous d’une date d’intervention. En effet, comme pour Lizmap ou Postgresql, ces montées de versions peuvent provoquer des interruptions de services de plusieurs minutes, et éventuellement des modifications pour lesquels une intervention de votre part est nécessaire (sur vos données, vos projets etc…).
Mise à jour des composants systèmes
Les mises à jour du système d’exploitation et des services systèmes qui permettent de faire tourner vos applications, sont faites de manière transparente et régulière afin de garder un service stable et sécurisée. Vous n’avez pas à vous en préoccuper.
Ces mises à jour peuvent amener à des interruptions de services, de quelques micro-secondes à moins de 10 minutes pour les plus grosses mises à jour. Mais elles sont toujours effectuées aux moments où l’activité de nos services est au plus bas (en général en soirée). Cela ne devrait pas être trop impactant pour vos utilisateurs.
Si malgré tout, ces interruptions de services sont critiques pour vous, même en plein milieu de la nuit (malgré que nos contrats ne spécifient pas de haute disponibilité de nos services), rapprochez-vous de notre service commerciale pour voir ce que l’on peut vous proposer comme solution.