Au 3 octobre 2026, la page officielle de QGIS présente QGIS 4.2.3 comme version actuelle et QGIS 3.44.15 comme version LTR. Ces statuts indiquent où se situent les versions dans la publication du logiciel ; ils ne démontrent pas que les extensions, projets ou scripts de votre équipe sont compatibles. Vérifiez l’état publié sur la page de téléchargement de QGIS avant de décider.

Votre première décision ne porte pas sur la nouveauté

Pour un nouveau sujet, tester QGIS 4.2.3 peut être pertinent si vos dépendances essentielles sont identifiées et validées. Pour un projet en cours, la priorité est différente : ne changez pas une version qui permet de reproduire les analyses tant que les dépendances n’ont pas été contrôlées. Un environnement parallèle vous permet d’évaluer la cible sans transformer l’essai en migration irréversible.

QGIS 4 a effectué sa transition vers Qt 6, comme l’indiquent les informations officielles sur la version 4.2. Ce changement est utile à connaître pour évaluer les dépendances et le travail d’adaptation des extensions. Il ne constitue toutefois pas un verdict sur vos propres outils.

Séparez les trois niveaux de preuve

Pour éviter de confondre une information de publication avec une validation de recherche, consignez distinctement :

• La compatibilité annoncée : indication de version, note de l’auteur ou information publiée pour une extension.
• Le fonctionnement observé : résultat d’un essai dans votre version cible, sur une configuration et des données identifiées.
• La reproductibilité du projet : capacité d’un autre membre à reprendre les données, les paramètres et les consignes pour retrouver les résultats attendus.

Une indication officielle ou une fiche d’extension est une première piste de tri. Seul l’essai dans votre contexte peut valider une fonction donnée.

Commencez par dresser la liste des extensions sans lesquelles le projet ne peut pas produire ses résultats. Pour chacune, consultez les informations publiées dans le dépôt officiel des extensions : versions déclarées, date ou état de mise à jour, notes de l’auteur et fonctions annoncées. Les indications de compatibilité avec QGIS 4 sont un filtre de présélection, pas une garantie de fonctionnement sur chaque projet.

Le passage à Qt 6 rend particulièrement important le contrôle des dépendances dont l’extension dépend. La documentation de migration et les informations de version de QGIS aident à repérer ce qui a changé, mais elles ne remplacent pas les essais de vos commandes habituelles. La chronologie visuelle de QGIS 4.2 fournit le contexte des évolutions publiées.

Le cas typique est celui d’un projet de géographie urbaine où une extension prépare des couches avant l’analyse, tandis qu’une autre intervient dans la mise en page finale. Tester chaque extension seule ne suffit pas si elles sont utilisées successivement. Rejouez la chaîne dans l’ordre réel, puis vérifiez les fichiers transmis aux autres membres.

Si une extension indispensable ne se charge pas, si une fonction centrale échoue ou si aucune solution de remplacement n’a été validée, bloquez la migration de ce projet. Vous pouvez continuer à évaluer la nouvelle version sur une copie, mais ne remplacez pas l’environnement de référence.

L’ouverture réussie d’un projet est un contrôle de premier niveau, pas une preuve de reproduction. Les chemins des sources, les couches, les styles, les mises en page, les expressions et les traitements peuvent exiger une vérification séparée. Pour chaque projet pilote, partez d’une copie et conservez une version de référence non modifiée.

La documentation de QGIS décrit les formats de fichiers associés aux projets et aux données. Servez-vous-en pour établir ce que votre projet contient et ce qu’il faut archiver. Vérifiez aussi la configuration propre au poste ou à l’environnement : certains réglages et chemins ne sont pas nécessairement partagés avec le fichier de projet, comme l’explique la documentation sur la configuration de QGIS.

Une séquence de validation reproductible

• Copiez le projet et les données nécessaires dans un espace d’essai. Ne faites pas de la première ouverture du projet officiel une expérience de migration.
• Notez la version de QGIS utilisée pour produire les résultats de référence, les extensions requises, les sources de données et les consignes disponibles.
• Ouvrez la copie dans la version cible. Relevez les couches absentes, les chemins rompus, les avertissements, les expressions en erreur et les différences visibles dans les mises en page.
• Rejouez les actions importantes selon les paramètres utilisés par l’équipe. Enregistrez les sorties afin de pouvoir les comparer, plutôt que de vous fier à un affichage qui semble correct.
• Comparez les résultats pertinents pour l’étude : attributs, géométries, systèmes de coordonnées, mises en page et fichiers exportés. Le choix des contrôles dépend du projet ; il doit couvrir ce qui influence vos conclusions.
• Faites reprendre le projet par une autre personne à partir des consignes conservées. Notez ce qui manque à la reproduction, puis corrigez les instructions avant de valider la migration.
• Gardez la copie de référence, les entrées, les paramètres et les sorties de test. Si un résultat diffère ou ne peut pas être expliqué, revenez à l’environnement de référence et repoussez la migration.

Attention : une carte affichée correctement ne prouve pas que les traitements ont produit les mêmes valeurs. Comparez aussi les données dérivées et les réglages enregistrés qui fondent vos conclusions.

La migration ne se limite pas à l’interface. Les équipes doivent aussi contrôler les algorithmes qu’elles utilisent, les fournisseurs externes, les transformations de coordonnées et les formats de données impliqués dans leurs analyses. Une fonction disponible dans la nouvelle version n’établit pas que l’ancien flux de travail donnera une sortie identique.

La documentation du cadre de traitement de QGIS 4.2 aide à examiner les traitements et leur organisation. Relevez les étapes indispensables à votre recherche, puis exécutez-les dans l’environnement cible sur un projet de copie. Enregistrez les paramètres, les données d’entrée et les livrables obtenus. Lorsque des fournisseurs externes interviennent, documentez leur présence et vérifiez qu’ils sont disponibles dans l’environnement évalué.

Pour un projet d’analyse environnementale, par exemple, le contrôle ne s’arrête pas à la génération d’une carte thématique. Si le flux comprend une transformation de coordonnées, une opération géométrique et l’export d’une table destinée à une analyse ultérieure, chacune de ces étapes compte. Une sortie visuellement semblable peut masquer une différence dans les attributs ou dans les données remises à un autre membre.

À ce stade, prenez une décision conservatrice : si une opération nécessaire ne peut pas être rejouée ou si les écarts ne sont pas expliqués, ne migrez pas le flux officiel. La disponibilité d’un nouvel algorithme n’est pas une raison suffisante pour changer les outils d’un projet déjà engagé.

Une version peut fonctionner sur le poste qui a servi aux essais et néanmoins compliquer le travail collectif. Les membres peuvent avoir des extensions différentes, des chemins locaux distincts, des configurations particulières ou des consignes trop vagues pour reproduire les analyses. Avant d’adopter une version commune, vérifiez que l’installation, la liste des extensions et la procédure de reprise sont transmissibles.

Pour les cours et les projets avec plusieurs contributeurs, choisissez explicitement une règle d’équipe : version unique pour tous, ou versions différentes associées à des projets séparés. Le fonctionnement parallèle peut faciliter une transition progressive, mais il demande une documentation rigoureuse. Sans séparation claire entre les fichiers de référence et les copies d’essai, un projet risque d’être modifié sans que l’équipe sache dans quelle version les changements ont été introduits.

Une note de projet utile doit préciser la version de QGIS employée, les extensions nécessaires, l’emplacement ou la description des données, les paramètres des traitements et les résultats attendus. Désignez également la personne chargée de vérifier les extensions et de réexaminer la décision lorsque les dépendances évoluent. Cette responsabilité évite que chaque membre interprète seul un état de compatibilité.

Décision par conditions

• Si les extensions indispensables sont disponibles et testées dans QGIS 4, et si un projet représentatif ainsi que ses traitements ont été reproduits et contrôlés, choisissez QGIS 4.2.3 pour le projet concerné.
• Si une extension, un script, un traitement ou une donnée critique n’a pas été validé, conservez QGIS 3.44.15 LTR comme environnement de référence pour le travail en cours.
• Si un nouveau projet peut être validé mais que les projets hérités ne le sont pas, utilisez les deux versions en parallèle, avec une référence documentée pour chaque projet.
• Si un autre membre ne peut pas reprendre le projet avec les consignes et les données prévues, différez la migration jusqu’à ce que la procédure de reproduction soit corrigée.

Ces conditions transforment le choix de version en décision vérifiable. Elles évitent de confondre « le logiciel se lance » avec « le groupe peut maintenir et reproduire son travail ».

Une indication de compatibilité suffit-elle pour adopter une extension ?

Non. Elle vous aide à cibler les extensions à tester, mais ne valide pas leur fonctionnement dans votre projet. Vérifiez leurs fonctions réellement utilisées, leurs dépendances et leurs interactions avec les autres extensions de l’équipe. Consignez l’essai et la solution de remplacement éventuelle. Si une extension indispensable n’a pas passé ce contrôle, gardez la version de référence du projet plutôt que de supposer que l’étiquette garantit le résultat.

Comment confirmer qu’un projet QGIS existant n’a pas changé de résultat ?

Travaillez sur une copie avec les données d’entrée et les paramètres conservés. Contrôlez les sources, les expressions, les mises en page et les traitements, puis comparez les sorties enregistrées aux résultats de référence. Selon votre étude, vérifiez notamment les attributs, les géométries, les coordonnées et les fichiers exportés. Une ouverture sans erreur ou une ressemblance à l’écran ne démontre pas la reproductibilité.

Peut-on garder les deux versions dans une même équipe ?

Oui, si chaque projet a une version de référence clairement indiquée et si les fichiers d’essai ne sont pas confondus avec les livrables officiels. Ajoutez aux consignes les extensions et traitements nécessaires, puis faites reprendre le projet par un collègue. Cette organisation permet d’évaluer la migration sans interrompre les analyses en cours, au prix d’un suivi plus exigeant des projets et des environnements.

Que faire lorsque le laboratoire ne dispose pas de Mac ?

Préparez un projet de copie et des données non sensibles, puis convenez d’un essai dans un environnement macOS accessible à distance. Vérifiez au préalable les règles de l’établissement concernant les données de recherche et les accès externes. Faites porter le contrôle sur vos extensions, vos traitements et vos livrables réels. Un essai limité ne permet pas de généraliser à tous les projets QGIS.

Si votre laboratoire ne possède pas de Mac et doit confirmer le comportement d’un projet sous macOS, commencez par un essai contrôlé sur une copie et des données autorisées. L’installation officielle de QGIS décrit les options d’installation pour macOS, mais la disponibilité de l’application sur cette plateforme ne prouve pas que les extensions et traitements de votre équipe y fonctionneront comme prévu.

Le remplacement d’une version de référence sans essai expose votre équipe à des extensions indisponibles, à des écarts de résultats et à une charge de support difficile à répartir. L’achat d’un Mac peut convenir si vous avez besoin d’un poste dédié sur la durée ou d’interfaces physiques locales. Pour une validation ponctuelle, un environnement Mac accessible à distance peut plutôt éviter de devoir acheter une machine avant d’avoir confirmé le besoin.

Si vous envisagez cette voie, consultez les options Mac proposées par KVMNODE et comparez-les à votre besoin de test, aux règles de données de votre établissement et à la durée d’utilisation prévue. Vous pouvez aussi examiner la page consacrée au Mac mini M4 pour comparer les choix d’équipement disponibles. Avant de transférer un projet, assurez-vous qu’il ne contient pas de données que votre établissement interdit d’utiliser dans un environnement distant.

Ne migrez le projet officiel qu’après validation des extensions, des traitements, des résultats et de la procédure de reprise. Si un contrôle échoue, gardez QGIS 3.44.15 LTR pour le travail en cours et poursuivez les essais en environnement séparé.