Pourquoi un langage de script lent, interprété et vieux de 30 ans est devenu l’infrastructure de l’IA moderne
Cet article est un point de départ pour la discussion — pas une spécification de produit. Les observations ici reflètent notre propre expérience et sont sujettes à révision au fur et à mesure que la chaîne d’outils évolue.
1. Not the Language You'd Design for This Job
Python was released in 1991 as a general-purpose scripting language built around readability and rapid prototyping. For most of its first two decades, it was a sysadmin and glue-code language: the tool you used to automate server tasks, move files between systems, call external processes, and wire together components written in other languages. Researchers doing serious numerical work used MATLAB, Fortran, or C. Python was for the scaffolding, not the computation.
It is also, by technical measure, a poor fit for computationally intensive work. It is interpreted. It is dynamically typed. Its global interpreter lock prevents true thread-level parallelism. If you were designing a language specifically for AI workloads in 2024, you would not design Python.
NumPy (2006) changed the trajectory. By wrapping compiled C and Fortran numerical routines in a clean Python interface, it gave researchers numerical computing that actually worked inside Python without abandoning the language they already used for everything else. SciPy and matplotlib followed. By 2012, when deep learning began its current run, Python already had the numerical infrastructure in place. The language had drifted from sysadmin tool to scientist's notebook without anyone officially deciding that's what it was for.
Theano, the precursor to most modern deep learning frameworks, chose Python for its interface in 2010. TensorFlow (Google, 2015) and PyTorch (Meta, 2016) did the same — not because Python was the best language for the job but because their research teams were already using it. That series of decisions, each reasonable in isolation, compounded for fifteen years into the situation we have now.
2. How Ecosystem Gravity Works
A programming language ecosystem is a network. Each package that exists increases the value of the ecosystem to every other package and every developer using them. More packages mean more problems solved, which attracts more developers, which produces more packages. The same dynamic governs operating system market share and industrial standards — and it is difficult to reverse once established.
Numerical Foundation
NumPy, SciPy, pandas — the base layer. Arrived because researchers needed it and Python was the path of least resistance for writing C wrappers that scientists could actually use.
Framework Layer
TensorFlow, PyTorch, JAX — all Python-first. Built by research teams who were already in Python. Locked the next generation of the stack to the same language.
Application Layer
LangChain, Hugging Face Transformers, LlamaIndex, the Anthropic and OpenAI SDKs — all Python-first, some Python-only. Built on top of Layer 2, which was built on top of Layer 1.
PyPI now hosts over 600,000 packages. The libraries that matter for AI work — GPU acceleration wrappers, transformer implementations, document parsers, vector database clients, MCP tooling — exist in Python first and sometimes only in Python. When we scoped the DAITK toolchain, the language question resolved itself in the first hour: the libraries we needed either had no equivalent outside Python or had Python implementations years ahead of alternatives. That is not a design decision. It is a dependency resolution.
3. What This Means for Building AI Systems
The practical consequences are not uniformly positive, and teams building AI systems should understand the tradeoffs rather than treating Python as an unexamined default.
Python is the correct tool for AI logic: model calls, prompt engineering, data processing, orchestration, and anything that touches the framework and application layers above. Prototyping is faster in Python than in any other language given the available libraries. Community knowledge defaults to Python — documentation, Stack Overflow answers, and research notebooks are written in Python first.
Python is a poorer fit for the serving layer. Web servers in Go or Rust handle concurrent requests at lower latency. Large Python codebases accumulate maintenance debt that compiled languages avoid. The emerging production pattern is layered: Python for AI logic, a faster language or managed platform for request handling, infrastructure tooling for deployment. Python's role is not "the whole system." It is the part where the AI libraries live.
For Canadian defence applications, sovereign AI capability does not require a different language. It requires controlling where data flows and what models are called. Python is the tool. Sovereignty is an architectural and operational property, not a language property — and the DAITK toolchain is built on that distinction.
4. Conclusion
Python went from sysadmin scripting language to the infrastructure of modern AI without a deliberate plan. A prototyping-first design philosophy made it easy to wrap compiled numerical libraries. That attracted scientists. Scientists attracted framework builders. Framework builders attracted application developers. By the time large language models became a mainstream engineering problem, the question of language had already been answered by fifteen years of compounding ecosystem investment.
For any team building AI systems today, the productive question is not "should we use Python?" — that is settled by the ecosystem. It is "where does Python fit in the architecture, and where do we need to supplement it?" Python is not the best language for AI. It is the language of AI. The distinction matters for how you design what you build.