Python 3.10 a atteint la fin de vie upstream le 1er octobre 2026. La dernière version de sécurité est 3.10.22. Il n’y a plus de mises à jour upstream. Le support du fabricant doit être vérifié séparément. La compatibilité spécifique de l’application doit être testée individuellement.
Créer un inventaire du projet
Avant une migration, il est important de créer un inventaire complet du projet. Cela inclut tous les paquets utilisés, les dépendances ainsi que la version actuelle de l’interpréteur Python. Cet inventaire permet d’identifier tôt les problèmes de compatibilité potentiels et de planifier des solutions.
Vérifier la compatibilité du fabricant et des paquets
La compatibilité doit être vérifiée de manière systématique, en tenant compte non seulement de la version Python, mais aussi de toutes les bibliothèques dépendantes et de leurs versions. Les interfaces externes, comme les pilotes de base de données ou les API, doivent être vérifiées pour leur prise en charge de la version cible. Pour les paquets binaires, la compatibilité de la plateforme et de l’architecture est cruciale. La planification doit définir des responsabilités claires et des fenêtres de maintenance pour réagir rapidement en cas de problème. Il est important de structurer les étapes de migration en phases et d’évaluer à chaque étape l’impact sur l’application globale. Une migration globale sans analyse préalable peut entraîner des erreurs inattendues.
Les informations fournies par les fabricants sur les versions prises en charge sont ici d’une importance centrale.
Sauvegarder l’application, les données et la configuration
Avant de commencer la migration, l’application, les données et les configurations doivent être sauvegardées complètement. Gardez l’environnement ancien inchangé afin de pouvoir y revenir en cas de problèmes.
Projet de test et vérification de l’interpréteur
Les commandes affichées sont des exemples Unix ; toutes les commandes sont exécutées dans le répertoire racine d’un projet de test séparé ; les chemins relatifs s’y réfèrent. Avant toute utilisation, vérifiez la version réelle de python3. La version cible doit déjà être installée, maintenue et compatible avec le projet. Aucune modification des services en production ne sera effectuée.
Le projet de test sert à vérifier de manière isolée les étapes de migration et ne doit pas être confondu avec les environnements de production. Avant de commencer la migration, déterminer la version actuelle de Python sur le site d’utilisation et la comparer à la version cible. Toutes les commandes dans le projet de test sont exemplaires et servent à la démonstration ; elles doivent être adaptées à votre propre environnement.
Avant l’installation, l’interpréteur python3 doit déjà être installé, maintenu et compatible avec le projet. Le fichier requirements-reviewed.txt est une liste de paquets préparée par vous-même et testée sur la version cible, ce n’est pas un fichier fourni. Le Python du système d’exploitation ne doit pas être remplacé. Le chemin global PATH ne doit pas être modifié. Les mises à niveau globales des paquets ne sont pas recommandées. Les commandes suivantes doivent être utilisées dans le projet de test :
python3 --version
python3 -m venv .venv-next
.venv-next/bin/python -m pip install -r requirements-reviewed.txt
.venv-next/bin/python -m pip checkInstallation et vérification des dépendances
pip check vérifie uniquement la compatibilité des dépendances déclarées. Aucun test d’application ni audit de sécurité n’est effectué. Un venv isole les paquets, mais n’est pas une sandbox de sécurité et ne résout pas la fin du support de l’interpréteur. Les environnements doivent être recréés, et non copiés ou déplacés. L’activation n’est pas nécessaire si le chemin de l’interpréteur est explicitement spécifié.
Test et planification du rollback
L’acceptation de la migration ne doit avoir lieu que si tous les tests planifiés ont réussi et qu’aucune erreur critique n’est survenue. Les données sensibles doivent être traitées conformément aux exigences du projet pour éviter tout risque de violation des réglementations sur la protection des données. Avant le passage, documenter les résultats attendus et les comparer aux résultats réels. Les différences doivent être documentées en détail et ne pas être ignorées simplement.
Après l’installation et la vérification des dépendances, l’application, les données d’exemple et les intégrations externes doivent être testées. Les critères de test doivent être documentés. Les environnements existants, ainsi que les sauvegardes d’application et de données, doivent être conservés jusqu’à l’acceptation. Ce n’est qu’ensuite qu’un basculement contrôlé peut être planifié. Un retour à l’ancien environnement n’est possible qu’à titre temporaire et ne rétablit pas le support upstream.
Pour plus d’informations, consultez les documentations officielles : PEP 619, Documentation venv, pip check.