QGIS 4.2 doit-il être mis à niveau maintenant : choix de migration pour les projets de recherche en 2026

Le statut de la version compte davantage que la possibilité de l’installer. Au 25 août 2026, la page officielle présente QGIS 4.2 comme la version courante et QGIS 3.44 comme la version LTR actuelle. La feuille de route prévoit l’entrée de QGIS 4.2 dans le canal LTR en octobre 2026, mais cette transition n’est pas encore réalisée. Il faut donc distinguer version courante et version de maintenance longue durée.

Pour un projet de recherche, le bon choix dépend surtout de la date du prochain livrable :

• Article ou mémoire en phase finale : conservez QGIS 3.44 LTR jusqu’à l’export et à l’archivage des résultats.
• Analyse en cours avec des traitements déjà validés : ne remplacez pas l’installation principale ; créez un environnement parallèle.
• Nouveau projet sans dépendance héritée : QGIS 4.2 peut être évalué dès maintenant, à condition de verrouiller l’environnement.
• Migration collective du laboratoire : préparez les tests avant octobre 2026, puis réévaluez la décision lorsque QGIS 4.2 sera effectivement proposé comme LTR.

La feuille de route QGIS doit servir de calendrier de gouvernance, pas de promesse de compatibilité pour chaque extension. Une date de canal LTR ne garantit ni la mise à jour des plugins ni l’équivalence des résultats scientifiques.

Point d’arrêt : si un résultat doit être soumis avant la fin de la campagne expérimentale, aucune mise à niveau de QGIS 4.2 ne doit modifier l’environnement qui a produit les figures, les statistiques spatiales ou les couches finales.

La première métrique est la stabilité du livrable. Elle se mesure avec des preuves concrètes : copie archivée du projet, données accessibles, liste des dépendances, commande de traitement reproductible et possibilité de rouvrir le projet avec l’ancienne version.

Un fichier .qgz qui s’ouvre n’est pas nécessairement un projet migré avec succès. Les chemins vers les rasters, les bases spatiales, les couches WMS ou les fichiers de style peuvent rester invalides. Une mise en page peut également s’afficher tout en ayant perdu une police, une règle de symbologie ou une expression de champ.

Avant le premier essai, archivez :

• le fichier de projet et une copie des données réellement utilisées ;
• les styles .qml, modèles de traitement et scripts ;
• les paramètres de projection et les connexions aux sources ;
• la version de QGIS, la version de Python et les bibliothèques appelées ;
• les fichiers exportés ayant déjà été remis au directeur de recherche ou au partenaire.

Pour un travail de thèse, conservez aussi une note expliquant quelle version a produit chaque carte. Cette information est aussi importante que le nom de la couche source : si une différence apparaît après migration, elle permet de localiser l’étape responsable.

Le deuxième indicateur est la couverture des dépendances. Il ne suffit pas de lancer QGIS 4.2 et d’ouvrir le gestionnaire de plugins. Il faut examiner les extensions effectivement utilisées par le projet, y compris celles appelées indirectement par Processing ou par un modèle graphique.

QGIS 4 introduit une base Qt6 et impose des vérifications spécifiques aux extensions. La documentation officielle de migration des plugins vers QGIS 4 donne le cadre à utiliser pour les extensions maintenues par un laboratoire ou par un tiers.

Pour chaque plugin critique, nous vous recommandons de relever :

1. son nom exact et sa version ;
2. sa présence dans le répertoire officiel des plugins ;
3. la version minimale de QGIS annoncée ;
4. la date de la dernière publication ;
5. l’existence d’un dépôt de code actif ;
6. le rôle précis joué dans le projet ;
7. la solution de repli si l’extension ne fonctionne pas.

Un plugin purement visuel n’a pas le même poids qu’un fournisseur Processing qui calcule une métrique ou transforme une géométrie. Le premier peut être temporairement désactivé. Le second devient un motif de suspension tant qu’un résultat équivalent n’est pas démontré.

La même règle s’applique à PyQGIS. La documentation PyQGIS de QGIS 4.2 doit être utilisée pour contrôler les imports, les objets d’interface, les appels Processing et les scripts exécutés sans interface graphique.

Un test minimal doit couvrir :

• le chargement d’une couche connue ;
• la sélection d’entités par expression ;
• l’appel d’un algorithme Processing ;
• l’écriture d’un résultat dans un format déterminé ;
• la lecture du nombre d’entités et des champs ;
• l’exécution en ligne de commande si le laboratoire utilise l’automatisation.

Un script qui ne renvoie pas d’erreur peut toutefois produire un résultat différent. Comparez donc les fichiers de sortie, et pas seulement le code retour de l’exécution.

Le troisième indicateur concerne la configuration. Un projet, un profil utilisateur, un modèle et une connexion ne sont pas le même objet. La documentation QGIS sur la configuration utilisateur doit être consultée pour identifier les paramètres et répertoires susceptibles d’être migrés.

N’installez pas QGIS 4.2 en écrasant le seul environnement de la station de travail. Utilisez un profil utilisateur séparé et une copie du projet. Cette séparation permet de comparer les préférences, les extensions, les chemins Python, les modèles et les connexions sans contaminer la configuration de production.

La procédure de contrôle est la suivante :

1. notez l’emplacement du profil QGIS 3.44 LTR ;
2. exportez ou copiez les styles, modèles et paramètres nécessaires ;
3. dupliquez le projet dans un répertoire de test ;
4. installez QGIS 4.2 dans un environnement indépendant ;
5. créez un profil vierge pour le premier lancement ;
6. ajoutez uniquement les extensions nécessaires ;
7. ouvrez la copie et reconnectez les sources une par une ;
8. fermez QGIS 4.2, puis rouvrez la copie avec QGIS 3.44 LTR ;
9. vérifiez la mise en page, les formulaires, les symbologies et les chemins.

Le retour arrière n’est pas prouvé par la simple désinstallation de QGIS 4.2. Il est prouvé lorsque l’ancien QGIS peut rouvrir le projet de référence, retrouver les sources et restituer une mise en page exploitable.

Expérience de terrain : un laboratoire doit archiver le profil de l’utilisateur au même titre que le fichier de projet. Sans ce profil, il peut manquer des expressions, des connexions ou des paramètres de traitement nécessaires pour reproduire une figure plusieurs mois plus tard.

La quatrième métrique est la concordance des résultats. Une interface identique ou une carte qui semble correcte ne suffit pas. La comparaison doit utiliser un projet représentatif, avec les opérations réellement employées dans la recherche.

Choisissez un cas comprenant, si le projet en a besoin :

• une transformation de système de coordonnées ;
• une jointure attributaire ;
• un traitement spatial ;
• un modèle graphique ;
• une symbologie catégorisée ou graduée ;
• une mise en page ;
• un export PDF, image ou données vectorielles.

Exécutez ce cas dans QGIS 3.44 LTR, puis dans QGIS 4.2. Conservez les paramètres exacts et les fichiers intermédiaires. Contrôlez ensuite :

• le nombre d’entités produites ;
• le système de référence de coordonnées ;
• les champs et leurs types ;
• les valeurs nulles et les arrondis ;
• l’emprise de la carte ;
• les légendes, étiquettes et échelles ;
• le nombre de pages et les dimensions de l’export ;
• la taille et le format des fichiers générés.

Les outils de traitement tiers doivent être examinés séparément, car leur disponibilité et leur comportement ne découlent pas automatiquement de la version principale. La documentation QGIS sur les outils Processing tiers rappelle que ces fournisseurs constituent une couche de dépendance distincte.

Les modèles graphiques nécessitent également une vérification autonome. La documentation du concepteur de modèles de QGIS 4.2 permet de contrôler les entrées, les sorties et les paramètres enregistrés.

Si le nombre d’entités change, arrêtez la migration. Identifiez d’abord si l’écart vient de l’algorithme, de la bibliothèque géométrique, du fournisseur de données, du système de coordonnées ou d’un paramètre implicite. Une différence non expliquée est incompatible avec une validation scientifique.

QGIS 4.2 peut être évalué sur un Mac Apple Silicon, mais l’architecture du processeur n’est qu’un élément du système. La documentation officielle d’installation de QGIS doit être utilisée pour vérifier le paquet macOS disponible et les conditions d’installation.

Examinez ensuite les dépendances propres au sujet :

• bibliothèques Python installées par le laboratoire ;
• commandes externes lancées depuis Processing ;
• outils GDAL ou autres utilitaires appelés par script ;
• pilotes et connecteurs de bases de données ;
• exécutables compilés pour une architecture différente ;
• accès aux volumes réseau et aux données distantes.

Dans un laboratoire principalement équipé de Windows ou de Linux, un Mac indépendant permet de tester sans interrompre les postes utilisés pour les analyses courantes. Cette approche est pertinente pour un projet qui doit produire une version macOS, pour une équipe qui développe un plugin ou pour un doctorant dont l’environnement imposé diffère de celui du laboratoire.

Un accès distant doit toutefois être validé sur les opérations qui comptent réellement. Vérifiez le déplacement dans une grande couche, l’édition d’une mise en page, le transfert d’un projet, l’ouverture d’une base distante et l’exécution d’un traitement continu. Les performances et les temps d’exécution ne doivent pas être généralisés sans mesure : ils dépendent du volume des données, du réseau, du protocole distant et du traitement utilisé.

Pour un besoin ponctuel, un environnement Mac distant destiné aux tests évite d’acheter une machine uniquement pour une validation de migration. Il ne remplace pas une station locale lorsque le projet exige des périphériques physiques, un accès permanent à des données internes ou une charge lourde et quotidienne.

Voici le cadre que nous utiliserions avant d’autoriser une migration. Il s’agit d’un outil de décision, non d’un classement théorique des versions.

La règle opérationnelle est simple :

• Tous les indicateurs sont validés : QGIS 4.2 peut être adopté pour un nouveau projet.
• Un plugin ou un script critique est bloqué : restez sur QGIS 3.44 LTR.
• Les résultats sont différents mais expliqués : documentez l’écart et obtenez une validation scientifique avant adoption.
• Le projet a besoin de fonctions récentes sans risque d’interruption : utilisez le double environnement.
• Le retour arrière n’est pas démontré : aucune bascule de production.

Le double environnement n’est pas une installation permanente et désordonnée. Il doit avoir une finalité, un projet de référence, une date de réévaluation, une personne responsable et des archives identifiables. Sans ces éléments, il crée deux sources de vérité et complique la reproductibilité.

Avant une migration d’équipe, nous vous conseillons de faire signer ou valider une fiche contenant :

• version exacte de QGIS utilisée pour chaque résultat ;
• système d’exploitation et architecture du poste ;
• version de Python et bibliothèques essentielles ;
• liste des plugins avec leur statut de compatibilité ;
• scripts PyQGIS et modèles exécutés ;
• sources de données et systèmes de coordonnées ;
• fichiers de référence produits avec QGIS 3.44 LTR ;
• résultats obtenus avec QGIS 4.2 ;
• différences observées et explication retenue ;
• procédure de retour à l’ancien environnement ;
• personne chargée de maintenir cette documentation.

Cette fiche répond à un problème souvent oublié : la migration n’est pas seulement une décision informatique. Elle modifie potentiellement la chaîne de preuve qui relie les données brutes, le traitement spatial et la figure publiée.

Pour les développements internes, surveillez aussi les mises à jour officielles de QGIS. Les notes de version aident à repérer les changements, mais elles ne remplacent pas un test sur les données du laboratoire.

La mise à niveau de QGIS 4.2 est donc un choix conditionnel. Pour une thèse en cours, l’environnement QGIS 3.44 LTR reste la référence tant que la régression n’est pas terminée. Pour un nouveau projet, QGIS 4.2 peut être adopté dans un profil isolé, avec des résultats vérifiables et une procédure de retour arrière.

Si le laboratoire ne possède pas de Mac Apple Silicon, une machine distante indépendante peut servir de banc de test. MESHLAUNCH propose des environnements Mac accessibles à distance, ce qui permet de reproduire un projet sans acheter immédiatement un poste dédié.

En revanche, la location n’est pas le meilleur choix pour une charge scientifique stable à long terme, pour un traitement exigeant une présence locale permanente ou pour un projet nécessitant des interfaces physiques. Dans ces cas, un achat local ou l’infrastructure déjà administrée par l’université peut être plus cohérent. Pour une validation limitée dans le temps, le test d’un plugin, une comparaison d’exports ou une migration progressive, la location évite les défauts du matériel acheté uniquement pour une échéance : immobilisation du budget, maintenance locale et machine inutilisée après la campagne de test.