Python 2 a officiellement atteint sa fin de vie le 1er janvier 2020. Depuis, aucune mise à jour, aucun correctif de sécurité, aucun support des bibliothèques tierces. Pourtant, de nombreux scripts tournent encore en Python 2 sur des systèmes industriels, des automates, des équipements embarqués ou des serveurs de supervision, souvent parce que « ça marche et qu’on n’y touche pas ». Migrer vers Python 3 est pourtant une nécessité de sécurité et de pérennité, en particulier sur des environnements critiques où un script défaillant peut arrêter une chaîne de production.
Pourquoi Python 2 est un risque permanent
Un interpréteur Python 2 non maintenu expose à des vulnérabilités connues qui ne seront jamais corrigées. Les bibliothèques scientifiques, de communication ou d’automatisation (numpy, pandas, requests, pyserial, pymodbus) ont toutes abandonné Python 2 : impossible de les mettre à jour, donc de corriger leurs failles. Sur un système industriel connecté au réseau de l’usine, cette accumulation de failles non patchées devient une porte d’entrée pour une compromission de l’ensemble du système d’information opérationnel.
Les différences qui cassent le code
Le passage de Python 2 à Python 3 introduit des changements de comportement majeurs, qui cassent silencieusement ou brutalement le code :
| Élément | Python 2 | Python 3 |
|---|---|---|
print | Instruction | Fonction print() |
| Chaînes | str = octets | str = Unicode, bytes distinct |
| Division d’entiers | 3 / 2 → 1 | 3 / 2 → 1.5 |
range() / map() | Listes | Itérateurs |
| Exceptions | except E, e | except E as e |
Parmi ces changements, les plus dangereux sont ceux qui ne provoquent aucune erreur :
printdevient une fonction :print "x"ne compile plus, il fautprint("x").- Les chaînes sont Unicode par défaut : la distinction
str/unicodedisparaît, et les opérations sur les octets nécessitent le typebytes. C’est le piège numéro un pour les scripts qui dialoguent avec des équipements en protocole binaire. - La division d’entiers :
3 / 2renvoie1.5en Python 3, contre1en Python 2 ; il faut utiliser//pour la division entière. - Les itérateurs remplacent les listes :
range(),map(),filter(),zip()renvoient des itérateurs, pas des listes, ce qui casse le code qui les réutilise ou les indexe. - Les exceptions : la syntaxe
except Exception, eest remplacée parexcept Exception as e, et la comparaison des exceptions a changé.
La stratégie de migration : traduire ou réécrire ?
Deux approches s’opposent. La première est la migration assistée par outils : 2to3 (fourni avec Python), futurize (bibliothèque future) ou modernize transforment automatiquement la syntaxe et les idiomes les plus courants. Ces outils traitent 80 à 90 % du code, mais laissent les cas subtils — gestion des octets, encodages, comportement des itérateurs — à corriger à la main. La seconde est la réécriture ciblée : pour un script critique, il est parfois plus sûr de le réécrire proprement en Python 3, en réutilisant les règles métier validées. La bonne approche combine les deux : traduction automatique, puis revue manuelle des zones sensibles.
Les étapes d’une migration réussie
- Inventaire des scripts et des dépendances : lister les scripts, leurs bibliothèques et les versions d’interpréteur utilisées.
- Gel et sauvegarde : versionner l’existant et en faire une copie de référence avant toute modification.
- Compatibilité des dépendances : vérifier que chaque bibliothèque dispose d’une version Python 3, sinon identifier un remplaçant.
- Traduction automatique : appliquer
2to3oufuturizesur une copie du code. - Revue manuelle des zones sensibles : encodages, protocoles binaires, divisions, itérations, gestion des exceptions.
- Tests sur banc de test : rejouer les scénarios réels sur un équipement de test ou un simulateur, jamais directement sur la production.
- Déploiement progressif : basculer les scripts un par un, avec une période d’observation.
Les pièges spécifiques aux systèmes industriels et embarqués
Les scripts Python 2 qui pilotent des équipements manipulent souvent des trames binaires, des registres Modbus, des ports série. La migration vers Python 3 change la nature des chaînes et des octets : un bytes n’est plus une str, et les opérations de concaténation ou de slicing doivent être revues. Les encodages (ASCII, Latin-1, UTF-8) doivent être explicités, sous peine de corrompre silencieusement les données transmises à l’équipement. Enfin, la compatibilité de l’interpréteur avec l’OS embarqué (vieux Debian, Yocto, systèmes temps réel) doit être vérifiée : installer Python 3 peut exiger une mise à jour du système d’exploitation lui-même.
Encodages, typage et bonnes pratiques de test
Les scripts industriels manipulent des données issues de capteurs, d’automates ou de fichiers de logs, souvent dans des encodages historiques (Latin-1, CP1252, voire des trames binaires brutes). La migration vers Python 3 impose d’expliciter ces encodages partout : lire un fichier ou un flux avec open(..., encoding='latin-1'), distinguer bytes et str, et décoder explicitement les trames. C’est là que se nichent la plupart des régressions silencieuses, car un décodage implicite erroné corrompt les données sans provoquer d’erreur visible.
Les bonnes pratiques pour sécuriser la migration :
- Ajouter progressivement des annotations de type, pour gagner en robustesse et faciliter la revue de code ;
- Mettre en place des tests unitaires rejouant des trames réelles capturées en production (golden files) ;
- Utiliser un environnement virtuel (
venv) et un fichier de dépendances figé (requirements.txtoupyproject.toml) ; - Valider chaque script sur un banc de test ou un simulateur avant de le déployer sur l’équipement réel ;
- Prévoir un mécanisme de retour arrière (conservation de l’ancien script) pendant la période d’observation.
Sur les systèmes embarqués, la place mémoire et la version de Python disponible sont des contraintes supplémentaires : vérifiez que l’image du système d’exploitation embarque bien un interpréteur Python 3 récent, ou prévoyez sa mise à jour dans le cadre du projet. Dans les environnements temps réel, mesurez également l’impact de la migration sur la latence et l’empreinte mémoire avant toute généralisation.
L’accompagnement d’un expert
Migrer des scripts industriels ou embarqués de Python 2 vers Python 3 exige de la rigueur et une connaissance fine des protocoles et des équipements. Chez Performances Digital, nous pilotons cette migration de bout en bout : audit des scripts, traduction et revue du code, tests sur banc, et déploiement sans interruption de la production. Notre méthode s’appuie sur des environnements de test fidèles aux équipements réels, pour valider chaque script avant sa mise en service.
Python 2 est mort depuis 2020, mais vos scripts, eux, continuent de tourner — avec une exposition croissante aux failles non corrigées. Demandez votre devis gratuit : nous auditerons votre parc de scripts Python 2 et vous proposerons un plan de migration sécurisé, adapté à vos contraintes industrielles.
