Python est partout. Dans les data centers qui font tourner les IA, dans les scripts qui automatisent nos vies, dans les notebooks des chercheurs, dans les Raspberry Pi qui contrôlent des trucs improbables, et dans les tutoriels qui promettent de vous rendre développeur en 21 jours (non). Pourtant, son histoire est moins lisse que son import this ne le laisse penser. Retour sur un langage né des leçons d’un échec, devenu roi presque par accident, et qui assume aujourd’hui son statut de couteau suisse préféré de la tech.
ABC : le langage qui a tout raté, sauf Python
Dans les années 80, une équipe de chercheurs néerlandais du CWI (Centrum Wiskunde & Informatica) travaille sur ABC, un langage éducatif pensé comme une alternative plus simple aux langages de programmation de l’époque. Leur ambition ? Créer un outil lisible, interactif, et surtout, accessible aux non-programmeurs. Sur le papier, c’était plutôt une bonne idée. Dans la vraie vie, beaucoup moins.
ABC avait quelques concepts brillants, mais souffrait d’un problème assez classique dans l’histoire de l’informatique : il avait été pensé comme un environnement presque fermé. Difficile de l’étendre, difficile de dialoguer avec le système, difficile de sortir du chemin imaginé par ses concepteurs. Pour apprendre, pourquoi pas. Pour construire des outils réels et connecter des bibliothèques existantes, c’était nettement moins pratique.
Parmi les personnes qui travaillent avec ABC se trouve un certain Guido van Rossum. Il retient plusieurs de ses bonnes idées, notamment l’importance de la lisibilité et d’une syntaxe relativement épurée, mais aussi une leçon fondamentale : un langage doit être utilisable, extensible et capable de communiquer avec le monde extérieur, pas simplement être élégant dans un laboratoire.
À la fin de l’année 1989, pendant les vacances de Noël, Guido commence donc à travailler sur un nouveau langage. Python est né. Le nom est bien un hommage aux Monty Python et à leur émission Monty Python’s Flying Circus, et non au serpent. Ce qui explique au passage pourquoi la documentation historique de Python est remplie de références à des œufs, du spam et autres absurdités britanniques.
La première version publique arrive en 1991. Python possède déjà plusieurs caractéristiques qui vont devenir sa signature : les exceptions, les fonctions, les modules, les classes, des types de données de haut niveau et, évidemment, cette fameuse indentation significative qui provoquera pendant trente ans des discussions passionnées entre programmeurs.
Contrairement à une idée souvent répétée, Python n’est d’ailleurs pas simplement un langage « non compilé ». L’implémentation de référence, CPython, compile généralement le code source en bytecode, ensuite exécuté par la machine virtuelle Python. Les fameux fichiers .pyc que l’on retrouve dans les dossiers __pycache__ ne sont donc pas apparus uniquement pour décorer vos dépôts Git.
Le plus drôle ? ABC était censé être un langage particulièrement accessible. Python a largement repris cette place… mais avec une différence de taille : il est devenu le couteau suisse de la tech, là où ABC est resté essentiellement une note de bas de page dans l’histoire de l’informatique.
Une philosophie cachée dans 19 aphorismes
Python ne se contente pas d’avoir une syntaxe. Il possède aussi une sorte de manifeste officiel : le Zen of Python, écrit par Tim Peters et enregistré sous le nom PEP 20. Pour le lire, il suffit d’ouvrir un interpréteur et de taper :
import this
Python affichera alors une série d’aphorismes devenus cultes : « Beautiful is better than ugly », « Explicit is better than implicit », « Simple is better than complex » ou encore « There should be one-- and preferably only one --obvious way to do it ».
Ce dernier principe est probablement le plus amusant quand on connaît l’écosystème Python moderne, où installer un projet peut impliquer pip, pipx, venv, Poetry, Conda, uv, un fichier requirements.txt, un pyproject.toml, trois prières et parfois un sacrifice à la divinité des dépendances.
Mais cette philosophie explique une grande partie du succès du langage. Python privilégie historiquement la lisibilité du code et la productivité du programmeur plutôt que la proximité avec la machine. C’est un choix. Et contrairement à beaucoup de choix technologiques, celui-ci a plutôt bien vieilli.
De l’ombre à la lumière : comment Python a conquis le monde sans vraiment le vouloir
Pendant les années 90 et une bonne partie des années 2000, Python reste relativement discret face à des mastodontes comme C, C++, Java, PHP ou Perl. Il est apprécié pour les scripts, l’administration système et certains projets scientifiques, mais traîne encore cette image de « petit langage sympathique ».
Et puis son écosystème commence à grossir. C’est probablement là que se trouve la vraie clé du succès de Python : pas uniquement dans le langage lui-même, mais dans tout ce que les autres ont construit autour.
- Le calcul scientifique : Numeric, puis NumPy, SciPy et plus tard Pandas donnent à Python des outils redoutables pour manipuler des tableaux, faire du calcul numérique et traiter de gros volumes de données. Une grande partie des calculs intensifs n’est d’ailleurs pas exécutée directement en Python : les bibliothèques s’appuient sur du C, du C++, du Fortran et des bibliothèques hautement optimisées. Python donne les ordres, les gros bras travaillent derrière.
- Le web : Zope fait partie des pionniers, puis Django arrive au milieu des années 2000 avec une philosophie « batteries included ». Flask popularise ensuite une approche beaucoup plus minimaliste. Plus tard, FastAPI remet Python sur le devant de la scène pour les API modernes, avec typage, validation et documentation OpenAPI presque automatiques. Python est alors très loin du simple script de cinq lignes.
- L’administration système et l’automatisation : pendant des années, Python devient un compagnon naturel des administrateurs Linux. Ansible est écrit en Python, de nombreux outils système utilisent Python et une quantité indécente de scripts internes commencent leur vie par un innocent
#!/usr/bin/env python3avant de devenir, six ans plus tard, une application critique que personne n’ose toucher. - La data science : Jupyter, Pandas, Matplotlib, SciPy et scikit-learn rendent l’écosystème particulièrement attractif pour les chercheurs, analystes et ingénieurs. Pas besoin de construire une application complète : on charge des données, on exécute quelques cellules, on affiche un graphique, et on peut déjà commencer à travailler.
- L’IA et le machine learning : TensorFlow, PyTorch, Keras, Transformers et une multitude d’autres projets utilisent Python comme interface principale. Les calculs lourds sont pourtant largement réalisés dans du code natif hautement optimisé, souvent sur GPU. Python joue ici le rôle de chef d’orchestre : il est relativement lent lui-même, mais il sait parfaitement demander à CUDA de faire exploser votre facture d’électricité.
Ce dernier point est essentiel pour comprendre pourquoi la lenteur de Python n’a jamais empêché son adoption dans l’IA. Quand un réseau de neurones effectue des milliards d’opérations matricielles sur un GPU NVIDIA, la boucle Python qui a demandé le calcul représente souvent une fraction minuscule du temps total.
Python est donc devenu une sorte de langage de colle universel. Il relie des bibliothèques, des API, des bases de données, des programmes natifs et des GPU sans obliger le développeur à comprendre comment implémenter une multiplication matricielle en AVX-512. Et franchement, c’est probablement mieux pour tout le monde.
Python 2 contre Python 3 : la guerre civile qu’on aurait préféré oublier
Tout n’a pourtant pas été tranquille. En 2008 arrive Python 3, une nouvelle version volontairement incompatible avec Python 2 sur plusieurs points. L’objectif est parfaitement raisonnable : corriger des choix historiques devenus encombrants, nettoyer le langage et notamment remettre un peu d’ordre dans la gestion des chaînes de caractères et d’Unicode.
Le problème, c’est qu’une quantité gigantesque de code Python 2 existe déjà.
Et personne n’a vraiment envie de le migrer.
Pendant plus d’une décennie, les deux versions cohabitent donc. Des projets restent volontairement sur Python 2, certaines bibliothèques doivent maintenir deux bases compatibles et les tutoriels commencent tous par l’inévitable question : « Vous utilisez Python 2 ou Python 3 ? ».
La situation devient suffisamment absurde pour que Python 2.7, publié en 2010 et initialement destiné à être une branche de transition, survive presque dix ans. Son support officiel prend finalement fin le 1er janvier 2020.
Cette transition est aujourd’hui pratiquement terminée, mais elle reste une excellente leçon de développement logiciel : casser la compatibilité est parfois nécessaire, mais quand votre langage fait tourner des millions de programmes, « il suffit de migrer » devient rapidement la phrase la plus optimiste de l’année.
Le vrai super-pouvoir de Python : son écosystème
On parle souvent de la syntaxe de Python pour expliquer son succès. C’est vrai, mais seulement en partie. Son avantage le plus difficile à reproduire aujourd’hui est probablement son écosystème.
PyPI, le Python Package Index, contient des centaines de milliers de projets. Vous voulez lire un fichier Excel ? Il existe une bibliothèque. Piloter un navigateur ? Il existe une bibliothèque. Interroger Kubernetes ? Il existe une bibliothèque. Reconnaître un chat sur une photo prise par une caméra branchée à un Raspberry Pi afin d’ouvrir automatiquement une chatière ? Malheureusement, quelqu’un l’a probablement déjà fait.
Cette abondance change complètement la façon dont on développe. Dans beaucoup de projets Python, la première question n’est plus « comment vais-je programmer ça ? », mais « quelle bibliothèque fait déjà 80% du travail ? ».
C’est formidable pour la productivité. C’est également une source infinie de problèmes de dépendances, de versions incompatibles, de paquets abandonnés et de risques liés à la supply chain. Parce que rien ne dit « infrastructure professionnelle » comme une application critique dépendant d’un package maintenu depuis 2017 par un inconnu appelé dragonmaster42.
Le GIL : trois lettres pour déclencher une guerre sur Stack Overflow
Impossible de parler sérieusement de Python sans parler du fameux GIL, le Global Interpreter Lock de CPython.
Dans l’implémentation classique de CPython, le GIL empêche plusieurs threads d’exécuter simultanément du bytecode Python dans un même interpréteur. Cela simplifie notamment certaines parties de la gestion mémoire et de l’implémentation interne de CPython, mais cela limite historiquement l’intérêt du multithreading pour les calculs intensifs purement Python.
Attention toutefois au raccourci « Python ne sait pas utiliser plusieurs cœurs », qui est faux. On peut utiliser plusieurs processus avec multiprocessing, certaines extensions natives libèrent le GIL pendant leurs calculs, et les threads restent parfaitement utiles pour de nombreuses tâches d’entrées-sorties : réseau, fichiers, API, bases de données, etc.
Et surtout, la situation est en train d’évoluer. Le projet Python travaille depuis plusieurs versions sur le free-threaded CPython, issu notamment du travail autour de la PEP 703. Des builds capables de fonctionner sans le GIL sont désormais une réalité expérimentale puis progressivement supportée par l’écosystème. Cela ne signifie pas que le GIL a magiquement disparu de toutes les installations Python du monde, mais une limitation historique que beaucoup pensaient quasiment intouchable est désormais activement remise en question.
Comme quoi, en informatique, « impossible à changer » signifie parfois simplement « personne n’a encore eu le courage d’y consacrer plusieurs années ».
Python moderne : le roi est lent, alors on lui a acheté des baskets
Python a un problème : pour du calcul exécuté directement dans l’interpréteur, il reste souvent nettement plus lent que C++, Rust, Go ou Java. Sur certains workloads, l’écart peut être considérable. Pourtant, dans une immense partie des applications, ce n’est tout simplement pas le facteur dominant.
Une application web passe son temps à attendre une base de données, Redis, une API distante ou le disque. Un pipeline d’IA attend son GPU. Un script d’administration attend le réseau. Et une application d’entreprise attend probablement une requête SQL écrite en 2014 par quelqu’un qui a depuis changé de continent.
Autrement dit : optimiser l’interpréteur Python alors que votre requête SQL effectue 14 jointures et un SELECT * sur quatre millions de lignes revient parfois à installer un aileron en carbone sur un tracteur.
Mais les développeurs de CPython n’ont pas pour autant abandonné la question des performances. Depuis Python 3.11 notamment, un important travail d’optimisation de l’interpréteur a été engagé. Spécialisation adaptative du bytecode, améliorations de l’interpréteur, optimisations internes et travaux autour d’un JIT expérimental montrent une chose : Python ne compte pas rester éternellement assis sur son excuse du « de toute façon, NumPy est écrit en C ».
Il ne deviendra probablement jamais le langage que vous choisirez pour écrire un moteur 3D AAA ou un kernel temps réel. Mais ce n’est pas vraiment ce qu’on lui demande.
Le typage : Python met une cravate, mais garde ses baskets
Autre transformation majeure : le typage. Historiquement, Python est un langage dynamiquement typé. On peut tranquillement écrire :
x = 42 x = "maintenant je suis une chaîne"
Et Python ne voit absolument aucun problème à cela.
Avec la PEP 484 et l’arrivée des type hints dans Python 3.5, le langage commence pourtant à proposer une syntaxe standard pour annoter les types :
def greet(name: str) -> str:
return f"Hello {name}"
Ces annotations ne transforment pas Python en langage statiquement typé. CPython ne va pas automatiquement refuser tous les mauvais types à l’exécution. Elles permettent surtout à des outils comme les analyseurs statiques, les IDE et les linters de comprendre beaucoup mieux le programme.
Et mine de rien, cela a profondément changé le développement Python professionnel. Sur une fonction de dix lignes, on peut parfaitement vivre sans typage. Sur une application de 300 000 lignes maintenue par quarante personnes, savoir qu’un argument attend un dict[str, User] plutôt qu’un mystérieux data devient soudainement assez sympathique.
Python conserve donc son typage dynamique, mais permet à ceux qui le souhaitent de construire des bases de code beaucoup plus strictes. Une sorte de compromis typiquement Python : vous pouvez mettre une ceinture de sécurité, mais personne ne vous oblige à l’attacher.
Et pendant ce temps, Python est devenu le langage de l’IA
L’explosion de l’IA générative a encore renforcé une position que Python occupait déjà dans le machine learning. PyTorch, TensorFlow, JAX, scikit-learn, Hugging Face Transformers et une immense partie de l’écosystème proposent Python comme interface principale.
Mais dire que « les IA sont écrites en Python » est un raccourci trompeur.
Une grande partie des opérations réellement coûteuses est effectuée dans des kernels CUDA, du C++, des bibliothèques comme cuDNN, cuBLAS ou d’autres couches natives optimisées. Python sert surtout à décrire les modèles, charger les données, orchestrer les calculs, lancer l’entraînement et assembler les différentes briques.
En clair, Python est souvent le type dans la salle de contrôle qui appuie sur les boutons. Le GPU, lui, est celui qui soulève les caisses.
Et c’est justement ce qui rend Python si adapté à ce domaine. Les chercheurs peuvent expérimenter rapidement sans devoir recompiler un projet C++ de quinze millions de lignes chaque fois qu’ils veulent changer trois paramètres. Dans un domaine où l’expérimentation compte énormément, la productivité humaine vaut souvent bien plus que quelques millisecondes de temps CPU.
Le paradoxe Python : simple à apprendre, compliqué à industrialiser
Python est souvent recommandé comme premier langage, et ce n’est pas un hasard. Pour afficher quelque chose, pas besoin de classe, de fonction main, de compilation ou de quinze lignes de boilerplate :
print("Hello World")
Difficile de faire beaucoup plus accueillant.
Mais cette simplicité initiale peut être trompeuse. Dès qu’on passe à un vrai projet, on découvre les environnements virtuels, les versions de l’interpréteur, les wheels, les dépendances natives, les fichiers pyproject.toml, les outils de lint, les formatters, les tests, les annotations de types et les joies d’un package qui compile parfaitement sur Linux mais décide que Windows n’était finalement pas prévu au programme.
Pendant longtemps, l’installation des dépendances Python a d’ailleurs été l’un des aspects les moins élégants de l’écosystème. pip reste omniprésent, mais de nouveaux outils comme uv ont montré qu’il était possible de rendre la gestion des environnements et des packages beaucoup plus rapide et agréable.
Python reste donc facile à commencer. Le maîtriser est une autre histoire. Mais c’est finalement le cas de presque tous les outils qui ont survécu assez longtemps pour devenir importants.
La hype : quand Python devient une compétence magique sur LinkedIn
Et puis, il y a la hype.
Python est devenu le langage des « data scientists » qui font du « deep learning » avec des « neural networks » pour prédire des choses qui ne se prédisent probablement pas. C’est le langage des bootcamps qui promettent de vous apprendre Python, Docker, Kubernetes, le cloud, l’IA et probablement la fusion nucléaire en douze semaines.
C’est aussi le langage que certaines entreprises ajoutent à une fiche de poste parce qu’elles ont décidé de « faire de l’IA », même lorsque le poste consiste essentiellement à exporter des CSV depuis un ERP.
Mais derrière la caricature, il existe une vraie raison à cette omniprésence : Python permet de passer très rapidement d’une idée à quelque chose qui fonctionne.
Et en entreprise, c’est une qualité extraordinairement importante.
Un programme qui consomme deux fois plus de CPU mais qui a été développé en trois jours plutôt qu’en trois semaines peut être un excellent compromis. Le temps des machines coûte de l’argent. Celui des développeurs aussi. Et contrairement aux CPU, les développeurs refusent généralement qu’on en installe 128 dans un rack.
Guido quitte le trône, Python continue
Pendant longtemps, Guido van Rossum possède dans la communauté Python le titre semi-officiel de Benevolent Dictator For Life, ou BDFL. En clair : la communauté discute, propose, argumente pendant des kilomètres sur les mailing lists… et lorsqu’il faut vraiment trancher, Guido peut prendre la décision finale.
En 2018, après une controverse particulièrement fatigante autour de la PEP 572 et de l’opérateur d’affectation :=, surnommé walrus operator, Guido annonce qu’il quitte son rôle de BDFL.
Python adopte ensuite un modèle de gouvernance reposant notamment sur un Steering Council élu. Le langage n’est donc plus dirigé par son créateur, ce qui est probablement l’un des meilleurs signes de maturité possibles pour un projet open source.
Un langage qui survit au départ de son créateur n’est plus vraiment son projet. Il est devenu une infrastructure.
Conclusion : Python, ou l’art de gagner sans être le meilleur partout
Python est la preuve qu’une technologie n’a pas besoin d’être la plus rapide, la plus stricte ou la plus sophistiquée pour gagner. Elle doit surtout résoudre suffisamment de problèmes, suffisamment bien, pour suffisamment de monde.
C++ sera plus performant. Rust offrira des garanties mémoire que Python ne cherche même pas à fournir. Java et C# disposent d’écosystèmes industriels gigantesques. JavaScript est pratiquement impossible à éviter dès qu’un navigateur entre dans l’équation. Go produit des binaires particulièrement pratiques à déployer.
Et pourtant, Python reste là.
Parce qu’il permet d’écrire un script en cinq minutes, une API en une heure, un prototype de machine learning dans un notebook et une application complète sans changer de langage. Parce qu’il existe une bibliothèque pour presque tout. Parce que son code est généralement lisible. Et surtout parce qu’il a compris quelque chose que l’industrie oublie régulièrement : la machine n’est pas la seule à devoir comprendre le programme. Les humains doivent aussi le maintenir.
# Un exemple de code Python qui résume bien son esprit
# Simple, lisible, et un peu trop flexible
def greet(name="World"):
"""Affiche un message de bienvenue.
Args:
name (str): Le nom à saluer. Par défaut, "World".
"""
print(f"Hello, {name}! Python is {type(42).__name__}.")
if __name__ == "__main__":
greet()
greet("developers who love sarcasm")
Alors oui, Python a ses défauts. Il est parfois lent. Son packaging a longtemps ressemblé à une expérience sociale. Son typage peut donner lieu à des discussions interminables. Le GIL a traumatisé plusieurs générations de développeurs. Et sa popularité dans l’IA lui vaut aujourd’hui d’être utilisé dans une quantité impressionnante de projets dont le seul rapport avec l’intelligence artificielle est la présence du mot AI dans le README.
Mais au fond, c’est aussi ce qui fait son charme : Python n’a jamais vraiment cherché à être le langage parfait. Il a cherché à être pratique.
Plus de trois décennies après sa naissance, il fait tourner des sites web, des infrastructures, des outils scientifiques, des pipelines de données, des systèmes d’automatisation et une bonne partie de la révolution actuelle de l’IA. Pas mal pour un projet commencé pendant les vacances de Noël par un Néerlandais qui voulait simplement fabriquer un langage plus agréable à utiliser.
ABC voulait apprendre aux gens à programmer. Python a fini par leur permettre de programmer pratiquement n’importe quoi. Et ça, c’est quand même une sacrée punchline pour un langage qui porte le nom d’une troupe de comiques britanniques.