Python

Présentation

Tu as deux cents fichiers à renommer.

Tu peux les ouvrir un par un.

Cliquer.

Renommer.

Recommencer.

Et réfléchir doucement aux décisions qui t’ont conduit jusqu’ici.

Ou écrire quelques lignes de Python.

C’est souvent comme ça qu’on rencontre ce langage : non pas parce qu’on voulait apprendre un nouveau paradigme informatique, mais parce qu’un problème un peu pénible pouvait probablement être automatisé.

Puis le petit script devient un outil.

L’outil récupère des données.

Les données doivent être analysées.

Une API apparaît.

Puis une interface.

Et sans vraiment l’avoir prévu, Python est toujours là.

Un langage qui essaie de ne pas se mettre entre l’idée et le code

Python est un langage de programmation généraliste créé par Guido van Rossum au début des années 1990.

Sa réputation repose en grande partie sur quelque chose de très visible dès les premières lignes : sa syntaxe privilégie la lisibilité.

for image in images:
    resize(image)

Pas besoin d’une cérémonie de quinze lignes pour comprendre approximativement ce qui se passe.

Cela ne signifie pas que Python soit un langage « simple » dans tous ses usages.

Il possède des classes, générateurs, décorateurs, context managers, programmation asynchrone, métaclasses, descriptors, annotations de types et suffisamment de profondeur pour occuper quelques longues soirées.

Mais il cherche à garder les opérations courantes relativement lisibles.

Cette différence compte.

Python ne supprime pas la complexité des problèmes. Il essaie surtout de ne pas ajouter trop de complexité avant même d’avoir commencé à les résoudre.

Un langage, plusieurs mondes

Python n’est pas spécialisé dans un seul domaine.

C’est précisément ce qui rend difficile la phrase « Python sert à… ».

Il sert notamment à :

Cette polyvalence ne vient pas uniquement du langage.

Elle vient surtout de ce qui s’est construit autour.

Django ou FastAPI pour le web.

NumPy, pandas ou SciPy pour les données et les sciences.

PyTorch, TensorFlow, scikit-learn ou Transformers pour l’IA.

Pillow pour l’image.

Requests ou HTTPX pour le réseau.

PySide, PyQt, Tkinter ou Kivy pour les interfaces.

Jupyter pour l’exploration interactive.

Le langage est le centre.

L’écosystème est ce qui lui donne autant de métiers différents.

Python et CPython ne sont pas exactement synonymes

Il existe une distinction utile.

Python désigne le langage, sa syntaxe, ses concepts et ses spécifications.

CPython est son implémentation de référence, écrite principalement en C.

C’est elle que la majorité des utilisateurs installent lorsqu’ils téléchargent Python depuis python.org.

Mais d’autres implémentations existent ou ont existé avec des objectifs différents : PyPy pour certaines optimisations grâce à la compilation JIT, MicroPython pour les microcontrôleurs, ou encore différentes intégrations destinées à des environnements particuliers.

Cette nuance devient importante dès que l’on parle de performances, de GIL, d’extensions natives ou de compatibilité.

Une caractéristique de CPython n’est pas nécessairement une propriété fondamentale du langage Python lui-même.

Une communauté plutôt qu’un propriétaire unique

Python n’appartient pas à une entreprise qui décide seule de sa feuille de route.

La Python Software Foundation — PSF est une organisation à but non lucratif qui protège et soutient l’écosystème, maintient des infrastructures comme python.org et PyPI et accompagne la communauté.

L’évolution technique du langage repose sur les développeurs principaux, les contributeurs et le processus des PEP — Python Enhancement Proposals.

Depuis la fin du modèle historique où Guido van Rossum occupait le rôle de BDFL, la gouvernance du langage s’organise autour d’un Steering Council élu.

Ce fonctionnement ne rend évidemment pas chaque décision simple.

Aucune communauté de développeurs n’a encore trouvé le patch qui supprime les débats humains.

Mais il donne à Python une continuité qui ne dépend pas du produit trimestriel d’une entreprise particulière.

Python 3.14 aujourd’hui, Python 3.15 déjà en vue

Au 7 août 2026, la branche stable actuelle est Python 3.14, avec Python 3.14.7 publié le 5 août.

Python 3.14 a notamment marqué une étape importante pour le free-threaded Python, désormais officiellement supporté, ainsi que pour les interpréteurs multiples, les annotations différées et plusieurs améliorations de l’outillage et du runtime.

Python 3.15 est déjà très proche.

La première release candidate, Python 3.15.0rc1, est sortie le 4 août 2026.

Mais « release candidate » contient encore le mot important : candidate.

La version finale est prévue pour octobre 2026.

Pour un projet de production, Python 3.14 reste donc la référence stable au moment de cette fiche.

Fonctionnalités

Une syntaxe qui privilégie la lecture

Python utilise notamment l’indentation pour structurer les blocs de code.

Pas d’accolades pour entourer chaque condition ou fonction.

Pas besoin de déclarer explicitement le type d’une variable avant de lui affecter une valeur.

name = "Ambre"
age = 28

if age >= 18:
    print(f"{name} est majeure.")

Cette lisibilité contribue fortement à son accessibilité.

Elle permet aussi de lire relativement vite du code écrit par quelqu’un d’autre — ce qui, dans un projet réel, arrive légèrement plus souvent que d’écrire éternellement un programme neuf sur une plage de sable blanc.

Python reste cependant un langage à typage dynamique.

Le type des objets est déterminé à l’exécution.

Cette souplesse accélère beaucoup de développements, mais elle peut aussi reporter certaines erreurs jusqu’au moment où le programme exécute réellement le chemin concerné.

Plusieurs paradigmes sans grande cérémonie

Python n’impose pas une seule manière d’organiser le code.

Il permet une programmation :

• impérative ;
• procédurale ;
• orientée objet ;
• fonctionnelle dans certains usages ;
• asynchrone.

Une petite automatisation peut rester un script de vingt lignes.

Une application plus importante peut être organisée autour de modules, classes, services et packages.

On peut utiliser des fonctions comme valeurs, construire des générateurs, écrire des décorateurs ou définir des objets beaucoup plus sophistiqués.

Cette progressivité compte énormément.

Le premier programme Python n’a pas besoin de ressembler au dernier.

Une bibliothèque standard étonnamment vaste

Python arrive déjà avec beaucoup d’outils.

La bibliothèque standard couvre notamment :

fichiers et chemins, JSON, CSV, SQLite, expressions régulières, dates, compression, journalisation, tests, réseau, processus, concurrence, cryptographie de base, arguments de ligne de commande, sérialisation et de nombreux protocoles.

L’expression historique « batteries included » résume assez bien cette philosophie.

On peut accomplir énormément de choses avant même d’installer une dépendance externe.

Par exemple :

from pathlib import Path

for file in Path(".").glob("*.txt"):
    print(file.name)

Pas besoin de chercher immédiatement un package pour parcourir quelques fichiers.

Et quand la bibliothèque standard ne suffit plus, un autre monde s’ouvre.

PyPI : quelques lignes de langage, puis plusieurs centaines de milliers de projets

Le Python Package Index — PyPI est le dépôt principal de packages de l’écosystème Python.

Au moment de cette vérification, il référence plus de 850 000 projets.

C’est vertigineux.

Et cela change complètement la manière de développer.

Besoin de lire un fichier Excel ?

Communiquer avec une API ?

Créer un modèle de machine learning ?

Manipuler une image ?

Construire une CLI ?

Il existe probablement déjà une bibliothèque qui résout une partie du problème.

Le gestionnaire de packages de référence, pip, permet d’installer ces distributions :

python -m pip install requests

Le véritable super-pouvoir de Python se trouve souvent ici.

Pas dans une instruction magique du langage.

Dans la probabilité extrêmement élevée que quelqu’un ait déjà construit une bonne partie de ce dont tu as besoin.

Les environnements virtuels : empêcher les projets de se marcher dessus

Projet A utilise une version d’une bibliothèque.

Projet B en nécessite une autre.

Si tout est installé dans le même Python global, la paix peut être assez courte.

Le module standard venv permet de créer un environnement isolé :

python -m venv .venv

Chaque projet peut alors disposer de ses propres dépendances.

On active l’environnement.

On installe les packages nécessaires.

Et l’application n’a plus à négocier son existence avec les trente-sept expériences Python réalisées sur la même machine depuis 2022.

Cette isolation est devenue une pratique essentielle de l’écosystème.

En Python, apprendre à créer un environnement virtuel arrive presque juste après apprendre à créer une boucle.

Typage dynamique, mais annotations possibles

Python permet d’ajouter des type hints :

def total(price: float, quantity: int) -> float:
    return price * quantity

Ces annotations améliorent la documentation du code et permettent aux IDE ainsi qu’à des outils comme mypy ou Pyright de détecter de nombreuses incohérences avant l’exécution.

Mais elles ne transforment pas Python en langage statiquement typé.

Par défaut, Python n’empêche pas automatiquement une fonction de recevoir une valeur incompatible simplement parce qu’une annotation indique autre chose.

Le typage devient donc progressivement plus structuré sans abandonner complètement la souplesse historique du langage.

Pour les gros projets, c’est souvent un compromis très intéressant.

Scripting et REPL : essayer avant de construire

Python peut être utilisé interactivement.

On lance l’interpréteur.

On écrit une expression.

On observe le résultat.

Puis on recommence.

Cette boucle rapide est extrêmement pratique pour :

tester une API, vérifier une transformation, explorer une bibliothèque, manipuler quelques données ou comprendre le comportement d’une fonction.

Des environnements comme IPython et Jupyter ont poussé cette logique beaucoup plus loin.

On peut mélanger code, résultats, graphiques, texte et expérimentation.

Cela explique une partie de la popularité de Python dans la recherche et la data.

L’idée peut rester vivante pendant qu’on l’explore.

Pas besoin de construire toute l’application avant de savoir si elle était intéressante.

Asyncio : gérer beaucoup d’attente sans multiplier naïvement les threads

Python dispose avec asyncio d’une infrastructure standard pour la programmation asynchrone.

Elle devient particulièrement utile lorsque le programme passe beaucoup de temps à attendre :

réponses réseau, fichiers, bases de données, API ou autres opérations d’entrée-sortie.

Avec async et await, une application peut organiser de nombreuses tâches concurrentes sans traiter chaque opération comme un thread système indépendant.

C’est l’une des fondations de nombreux frameworks web Python modernes.

Mais concurrence ne signifie pas automatiquement parallélisme CPU.

Et c’est là qu’apparaît un vieux personnage de l’histoire Python.

Le GIL commence enfin à perdre son statut de fatalité

Dans CPython classique, le Global Interpreter Lock — GIL limite l’exécution simultanée de bytecode Python par plusieurs threads dans un même interpréteur.

Pendant longtemps, cette caractéristique a compliqué l’utilisation directe des threads pour accélérer les tâches purement CPU.

Les solutions existent depuis longtemps : multiprocessing, extensions natives, bibliothèques spécialisées, calcul distribué.

Mais Python évolue.

Depuis Python 3.13, CPython propose une construction free-threaded dans laquelle le GIL peut être désactivé.

Avec Python 3.14, cette configuration est officiellement supportée.

Elle permet à plusieurs threads d’exécuter du Python en parallèle sur plusieurs cœurs.

Ce n’est pas encore un bouton magique « rendre tout plus rapide ».

Certaines extensions tierces peuvent réactiver le GIL lorsqu’elles ne sont pas compatibles, et la version free-threaded possède encore des compromis de performance et de compatibilité.

Mais quelque chose de très ancien est clairement en train de bouger.

Parler avec C, C++ et le reste du monde

Python peut être étendu par des fonctions et types écrits dans des langages comme C ou C++.

Cette capacité joue un rôle énorme dans son écosystème scientifique.

Une API Python peut être agréable à utiliser tandis que le calcul intensif s’effectue dans du code natif beaucoup plus performant.

C’est une partie du secret derrière de nombreuses bibliothèques.

L’utilisateur écrit :

result = model(data)

Sous cette ligne relativement innocente peuvent travailler du C, du C++, du Fortran, du CUDA ou d’autres couches beaucoup moins innocentes.

Python devient alors un langage d’orchestration.

Il ne fait pas forcément lui-même chaque opération.

Il relie les morceaux qui savent les faire.

Cas d’usage

Automatiser ce qu’on n’a aucune envie de refaire demain

Un dossier contient 800 images.

Il faut les renommer, vérifier leur extension, construire un fichier JSON et déplacer celles qui ne respectent pas certaines règles.

C’est presque une publicité involontaire pour Python.

Les scripts permettent d’automatiser les tâches répétitives avec très peu d’infrastructure.

Fichiers.

Dossiers.

CSV.

API.

Conversions.

Sauvegardes.

Scraping raisonnable.

Traitement de texte.

Administration.

Git.

Builds.

Une opération manuelle répétée suffisamment souvent finit souvent par devenir un script .py.

Et une petite quantité de paresse bien orientée peut être une excellente compétence de développeur.

Construire le backend d’une application web

Une application mobile ou une interface JavaScript doit enregistrer des utilisateurs, gérer des données et exposer une API.

Python dispose de plusieurs familles de frameworks.

Django propose un environnement très intégré pour construire des applications web complètes.

Flask privilégie une approche plus légère.

FastAPI s’est imposé dans de nombreux projets d’API modernes, notamment grâce à son utilisation des annotations de types et à son intégration avec les standards OpenAPI.

Python ne s’exécute pas directement dans le navigateur comme JavaScript.

Mais côté serveur, il reste extrêmement présent.

Explorer des données avant même de savoir exactement ce qu’on cherche

On charge un CSV.

On regarde quelques lignes.

On calcule une moyenne.

On filtre.

On produit un graphique.

On remarque quelque chose.

On modifie l’hypothèse.

Puis on recommence.

Python s’adapte particulièrement bien à cette manière exploratoire de travailler.

L’écosystème autour de NumPy, pandas, Matplotlib, SciPy, Jupyter et de nombreux autres outils permet de passer rapidement de données brutes à une analyse manipulable.

Ce n’est pas seulement une affaire de performances.

C’est une affaire de distance entre la question et l’expérience.

Construire avec l’intelligence artificielle

En 2026, impossible de parler de Python sans parler d’IA.

Une grande partie de l’écosystème moderne du machine learning et du deep learning expose Python comme interface principale.

PyTorch.

TensorFlow.

scikit-learn.

Transformers.

Diffusers.

LangChain.

LlamaIndex.

Et une foule de bibliothèques spécialisées.

Cela ne signifie pas que les calculs eux-mêmes soient entièrement exécutés en Python.

Souvent, ils ne le sont pas.

GPU, CUDA, kernels optimisés et bibliothèques natives font le travail lourd.

Python sert de langage pour préparer les données, construire les pipelines, définir les modèles et orchestrer l’expérience.

C’est justement là qu’il excelle.

Prototyper avant de savoir si l’idée mérite une architecture

Certaines idées ne méritent pas immédiatement :

microservices, Kubernetes, six couches d’abstraction et une réunion sur la nomenclature des repositories.

Parfois, il faut simplement savoir si ça marche.

Python est excellent pour construire rapidement une preuve de concept.

Une fonction.

Un script.

Une petite API.

Un notebook.

Une interface minimale.

Le prototype ne deviendra peut-être jamais le produit final.

Ou peut-être que, comme souvent, quelqu’un dira :

« C’est juste temporaire. »

Puis le serveur exécutera encore ce code quatre ans plus tard.

La vie logicielle possède son propre sens de l’humour.

Apprendre à programmer sans combattre immédiatement la syntaxe

Python est largement utilisé dans l’enseignement.

Sa lisibilité permet de se concentrer assez vite sur des notions fondamentales :

variables, conditions, boucles, fonctions, structures de données, algorithmes et objets.

Un débutant doit déjà apprendre à penser comme un programme.

Il n’est pas forcément nécessaire de lui demander simultanément de résoudre une négociation diplomatique avec les pointeurs, le compilateur et trente accolades.

Cela ne fait pas de Python un langage uniquement destiné aux débutants.

C’est justement son intérêt.

On peut apprendre avec lui.

Et continuer à construire des systèmes sérieux des années plus tard.

Avis PANACHES

La vraie force de Python n’est peut-être pas sa syntaxe.

C’est la faible résistance qu’il oppose entre une intention et une première version fonctionnelle.

Tu veux tester une idée.

Tu peux souvent l’exprimer rapidement.

Tu veux aller plus loin.

Il existe probablement une bibliothèque.

Tu veux construire une API.

Un framework existe.

Analyser des données.

Un écosystème entier existe.

Lancer un modèle d’IA.

Bienvenue dans une autre galaxie de packages.

Cette continuité explique une grande partie de sa longévité.

Accessible ne signifie pas petit

Python souffre parfois de sa propre réputation.

Parce qu’il est recommandé aux débutants, on pourrait croire qu’il s’agit d’un langage « simple » que les projets sérieux finissent forcément par dépasser.

C’est faux.

Le langage reste accessible à l’entrée.

Mais l’écosystème peut atteindre une profondeur considérable.

Il existe une différence importante entre :

écrire ses premières lignes de Python

et

concevoir correctement une grosse application Python.

Architecture.

Concurrence.

Typage.

Packaging.

Profiling.

Gestion mémoire.

Tests.

Déploiement.

Extensions natives.

Les questions reviennent.

Elles arrivent simplement un peu plus tard.

Et ce n’est pas nécessairement une mauvaise chose.

Son plus grand avantage est aussi son plus grand piège : il y a un package pour tout

L’écosystème Python est immense.

C’est merveilleux.

Jusqu’à ce que l’on trouve :

quatre bibliothèques qui font presque la même chose,

trois méthodes de gestion de projet,

plusieurs systèmes de packaging,

deux environnements qui ne se comportent pas pareil,

un tutoriel de 2019,

une commande désormais déconseillée,

et Stack Overflow qui explique avec beaucoup d’assurance quelque chose qui était parfaitement vrai sous Python 3.7.

Python lui-même peut être assez cohérent.

Son écosystème l’est beaucoup moins.

Cela demande donc de distinguer le langage des habitudes historiques accumulées autour de lui.

Python est souvent le langage qui relie les autres

C’est peut-être son rôle le plus intéressant.

Un pipeline utilise du C++ pour les performances.

CUDA pour le GPU.

Une base PostgreSQL.

Un modèle d’IA.

Des fichiers JSON.

Une API externe.

Quelques commandes système.

Et au milieu :

Python.

Pas nécessairement parce qu’il est le meilleur à chacune de ces tâches.

Parce qu’il est très bon pour les faire communiquer.

Python gagne souvent non pas en faisant tout mieux, mais en rendant beaucoup de choses différentes assez simples à assembler.

Et l’IA a renforcé cette position

L’explosion de l’intelligence artificielle aurait pu rendre Python moins central.

Elle a produit presque l’inverse.

Une grande partie de la recherche et des outils d’IA modernes utilisent Python comme couche d’expérimentation et d’orchestration.

Cela crée un effet cumulatif.

Les chercheurs utilisent Python.

Les bibliothèques sont donc écrites avec une API Python.

Les nouvelles équipes choisissent Python parce que les bibliothèques y sont.

Puis de nouveaux outils apparaissent pour cette communauté.

L’écosystème attire l’écosystème.

C’est une boucle extrêmement difficile à reproduire pour un concurrent.

Mais Python n’est pas la réponse automatique à tout

Pour du code système à très fortes contraintes de performances ou de mémoire, Rust, C ou C++ peuvent être plus naturels.

Pour une application dont l’essentiel vit directement dans le navigateur, JavaScript ou TypeScript sont incontournables.

Pour certains services fortement concurrents et faciles à déployer en binaire, Go possède des qualités très séduisantes.

Pour certains environnements d’entreprise, Java, Kotlin ou C# restent extrêmement solides.

Pour l’analyse statistique spécialisée, R conserve son propre univers.

Et des langages comme Julia explorent un équilibre différent entre expressivité scientifique et performances.

Choisir Python simplement parce que « tout le monde utilise Python » serait rater le sujet.

La meilleure question reste :

qu’est-ce que l’on cherche à construire ?

Points d’attention

La version de Python fait partie du projet

Python évolue régulièrement.

Au 7 août 2026, Python 3.14.7 est la version stable la plus récente.

Python 3.15.0rc1 existe déjà, mais reste une préversion et n’est pas recommandée pour les environnements de production.

Cette distinction doit rester claire.

Une nouvelle version peut apporter de meilleures performances, de nouvelles fonctions et des améliorations importantes.

Mais les bibliothèques tierces peuvent avoir besoin de temps pour l’accompagner.

Installer « la toute dernière version qui existe » n’est donc pas toujours équivalent à choisir « la meilleure version pour ce projet aujourd’hui ».

Le Python du système n’est pas ton bac à sable personnel

Sur Linux notamment, Python peut être utilisé par le système d’exploitation et ses outils.

Installer ou remplacer sauvagement des packages dans cet environnement global peut provoquer des conflits.

Ce n’est pas l’endroit idéal pour tester quatorze versions de bibliothèques trouvées dans un tutoriel.

Les environnements virtuels existent précisément pour éviter ce genre de mélange.

Pour un projet :

un environnement isolé est généralement une bien meilleure habitude qu’un sudo pip install lancé avec optimisme.

Les environnements et dépendances demandent de la discipline

Python facilite énormément l’installation d’une bibliothèque.

Cela rend aussi très facile l’installation de beaucoup de bibliothèques.

Puis vient la question :

Quelles versions exactes ?

Pour quelle version de Python ?

Sur quelle plateforme ?

Avec quelles dépendances transitives ?

Le projet doit donc décrire suffisamment son environnement pour pouvoir être reproduit.

pyproject.toml, fichiers de verrouillage selon l’outil choisi, environnements virtuels, conteneurs ou systèmes comme conda peuvent participer à cette reproductibilité.

La commande pip install machin résout le problème de maintenant.

Un projet maintenable doit également penser au problème de dans six mois.

Le typage dynamique accélère autant qu’il peut surprendre

Python permet de modifier très vite un programme.

Mais certaines incohérences qui auraient été détectées par un compilateur statique peuvent n’apparaître qu’à l’exécution.

Les annotations de types et les analyseurs statiques modernes réduisent énormément ce problème.

Ils ne sont cependant pas obligatoires dans tous les projets et ne sont pas, par défaut, des validations effectuées par le runtime.

Sur une grosse base de code, ajouter progressivement une discipline de typage peut rendre Python beaucoup plus confortable à maintenir.

Le GIL n’a pas disparu du Python standard classique

Python 3.14 marque une étape majeure : le mode free-threaded sans GIL est désormais officiellement supporté.

Cela ne signifie pas que toutes les installations Python utilisent soudainement cette configuration.

Le build CPython standard avec GIL reste bien présent.

Le free-threading doit être utilisé dans une configuration adaptée, et toutes les extensions tierces ne sont pas encore nécessairement compatibles.

Certaines peuvent même réactiver le GIL lors de leur import.

Le changement est donc réel.

Mais nous sommes encore dans une transition.

Free-threading ne signifie pas « deux fois plus rapide avec deux threads »

Le parallélisme n’obéit malheureusement pas à la poésie des nombres ronds.

La construction free-threaded ajoute elle-même un certain overhead dans plusieurs situations.

Une application mono-thread peut donc être légèrement moins rapide qu’avec le build standard.

Et un programme ne devient pas automatiquement parallèle simplement parce que le GIL a disparu.

Il faut toujours penser :

partage des données, synchronisation, contention, locks, architecture et nature réelle de la charge.

Supprimer une serrure ne transforme pas automatiquement tout l’immeuble en autoroute.

Python n’est généralement pas le champion du calcul brut exécuté directement dans le langage

CPython privilégie historiquement la flexibilité et la simplicité du modèle d’exécution plutôt que les performances brutes d’un langage compilé comme C, C++ ou Rust.

Cela peut devenir visible dans de grosses boucles CPU écrites directement en Python.

Mais comparer uniquement cette vitesse peut aussi être trompeur.

NumPy, PyTorch et de nombreuses bibliothèques déplacent les calculs intensifs vers du code natif optimisé.

Le programme Python orchestre.

Le vrai calcul se déroule ailleurs.

Il faut donc profiler l’application réelle plutôt que conclure simplement :

« Python est lent. »

Parfois oui.

Parfois la ligne Python vient simplement de demander à un GPU de faire trois billions d’opérations.

PyPI est immense : la confiance n’est pas automatique

Pouvoir installer plus de 850 000 projets depuis un index public est une force extraordinaire.

C’est aussi une surface de risque.

Un package tiers est du code que l’on ajoute à son application et, souvent, que l’on exécute sur sa machine ou son serveur.

Il faut donc regarder :

le projet réel, son mainteneur, son activité, sa documentation, ses dépendances, sa licence, ses versions et son origine.

Les attaques par typosquatting ou compromission de chaîne d’approvisionnement ne sont pas un concept abstrait.

pip install est une commande très courte.

La confiance qu’elle accorde peut être beaucoup plus grande.

Le packaging Python s’est amélioré, mais son histoire reste visible

Python possède désormais des standards modernes autour de pyproject.toml, des wheels et d’un écosystème PyPA beaucoup plus structuré.

Mais des années d’évolution restent visibles.

pip.

venv.

virtualenv.

pipx.

build.

setuptools.

Poetry.

PDM.

Hatch.

uv.

conda.

Et quelques vieux tutoriels qui recommandent encore d’exécuter directement setup.py.

Il n’existe pas toujours une seule réponse universelle à « comment dois-je gérer mon projet Python ? ».

La bonne nouvelle est que le paysage moderne devient beaucoup plus propre.

La mauvaise est qu’Internet conserve parfaitement les anciennes réponses.

Le support mobile existe, mais il ne ressemble pas encore au desktop

Python 3.14 dispose désormais de binaires officiels embarquables pour Android.

C’est une évolution importante.

Cela ne signifie pas pour autant qu’Android soit devenu une plateforme Python identique à Windows, macOS ou Linux où l’on installe simplement l’interpréteur puis n’importe quelle bibliothèque.

Les contraintes de packaging, d’intégration native et de compatibilité des extensions restent spécifiques au mobile.

Côté iOS, les packages officiels apparaissent avec la série Python 3.15 actuellement en préversion, mais aucune release stable iOS de Python 3.14 n’est proposée par python.org au moment de cette vérification.

C’est pour cette raison que la fiche référence Android dans les plateformes actuelles, mais pas encore iOS.

« Facile à apprendre » n’est pas « impossible à mal écrire »

Python permet d’obtenir un premier résultat très rapidement.

C’est formidable.

Il permet aussi de produire rapidement un fichier de 2 800 lignes contenant :

variables globales, appels réseau, logique métier, accès base de données et une fonction nommée process_final_v2().

Le langage ne dispense pas d’architecture.

Il repousse simplement le moment où son absence devient douloureuse.

Et au fond, c’est peut-être la meilleure manière de résumer Python :

Il permet de commencer petit sans décider trop tôt jusqu’où le projet devra aller.