Pourquoi compiler Python, tout simplement
Si tu crées une application de bureau en Python et que tu veux qu'une personne ordinaire puisse l'exécuter, « pip install » n'est pas une option. Elle n'a pas Python installé, ne veut pas l'installer et ne devrait pas avoir à le faire. Il te faut un vrai .exe sur lequel double-cliquer. Cela implique de compiler : transformer ton code Python interprété et ses dépendances en quelque chose qui s'exécute sans installation de Python sur la machine cible.
Pourquoi PyInstaller ne suffisait pas
PyInstaller a été ma première tentative, et il fonctionne, techniquement. Le problème, c'est ce qu'il fait réellement : il regroupe un interpréteur Python et toutes tes dépendances dans un paquet, puis les décompresse dans un dossier temporaire à chaque lancement de l'application (en mode --onefile), ou les livre sous forme d'un dossier plein de fichiers en vrac (en mode --onedir). Dans les deux cas, tu exécutes toujours du bytecode interprété via un runtime Python embarqué au démarrage, et non du code machine compilé. Le démarrage paraissait lent, l'étape d'extraction temporaire ajoutait un délai visible au premier lancement, et les antivirus considèrent « se décompresse dans %TEMP% puis commence à s'exécuter » comme une heuristique classique de malware, ce qui a causé exactement le problème de faux positifs que je voulais éviter.
La bonne approche : Nuitka --standalone
Nuitka est un vrai compilateur de Python vers C. Il n'embarque pas d'interpréteur : il traduit ton code Python en C, le compile avec un vrai compilateur C et le lie en un véritable exécutable natif. Le résultat s'exécute comme du code machine compilé, et non comme du bytecode interprété dans un runtime embarqué. Le démarrage est quasi instantané et, point crucial, il ne s'extrait jamais dans un dossier temporaire à l'exécution, ce qui supprime le plus gros déclencheur des heuristiques antivirus. L'option la plus importante est --standalone : elle produit un dossier autonome avec ton .exe et ses dépendances natives juste à côté, prêt à être distribué tel quel ou intégré dans un installateur.
Comment faire concrètement
Les 3 erreurs qui m'ont coûté des heures
⚠️ Oublier --enable-plugin=tk-inter
Si ton interface utilise Tkinter ou CustomTkinter et que tu omets cette option, l'application compilée ne plante pas bruyamment : elle ne charge simplement pas la bibliothèque graphique et peut se fermer en silence ou afficher une fenêtre vide. Nuitka n'inclut pas la prise en charge des frameworks graphiques par défaut ; il faut l'activer framework par framework.
⚠️ Utiliser --onefile au lieu de --standalone
--onefile est tentant parce qu'il produit un seul .exe au lieu d'un dossier. Ne l'utilise pas pour quoi que ce soit que tu comptes distribuer publiquement. Les builds onefile s'extraient quand même dans un répertoire temporaire à l'exécution, le même comportement qui faisait réagir PyInstaller en faux positif, et j'ai vu Windows Defender les signaler comme Wacatac ou Sabsik uniquement à cause de ce schéma d'extraction, avec un code parfaitement propre. --standalone évite cela entièrement.
⚠️ Résoudre les chemins d'assets avec __file__ au lieu de sys.executable
Dans un script Python normal, __file__ pointe vers l'emplacement de ton fichier source. Dans un build standalone compilé, cette hypothèse ne tient plus. Utilise Path(sys.executable).parent pour trouver où ton .exe se trouve réellement sur la machine de l'utilisateur, et charge les fichiers de configuration, les icônes et les assets fournis relativement à cet emplacement, et non par rapport à l'endroit où ta source se trouvait pendant le développement.
Ce que ça t'apporte concrètement
ReelNox Studio et BackDrop_ sont tous deux livrés en builds Nuitka --standalone, signés avec un certificat DigiCert EV. Le démarrage est instantané, Windows Defender ne signale aucun des deux installateurs, et aucune des deux applications n'a jamais eu besoin d'un runtime Python embarqué auquel l'utilisateur doive penser. La combinaison qui compte est : --standalone (et non --onefile) plus une vraie signature de code. Ensemble, elles résolvent à la fois le problème de performance et le problème de confiance liés à la distribution d'une application Python comme exécutable Windows natif.
About
Patrick Chen — développeur indépendant derrière Sublimearts.io. J'écris sur les vrais problèmes de build que j'ai rencontrés en livrant ReelNox Studio, BackDrop_ et Time Precision à de vrais utilisateurs Windows, pas des tutoriels génériques.