C'est le point où l'intuition venant du C ou du calcul parallèle classique induit en erreur. Trois modèles de concurrence coexistent en Python, ils ne servent pas aux mêmes problèmes, et choisir le mauvais peut ralentir un programme au lieu de l'accélérer. Ce module part de zéro : ce qu'est un thread, pourquoi le GIL existe, comment savoir lequel des trois modèles s'applique à votre cas, puis chaque outil avec des exemples complets.

1. Processus, thread, concurrence, parallélisme

Quatre mots qu'on emploie souvent l'un pour l'autre, et qu'il faut séparer une bonne fois.

Un processus est un programme en cours d'exécution, avec sa propre zone de mémoire, isolée de celle des autres. Deux processus ne peuvent pas se marcher dessus : pour échanger des données, ils doivent explicitement se les envoyer.

Un thread (ou fil d'exécution) est une ligne d'exécution à l'intérieur d'un processus. Plusieurs threads d'un même processus partagent la même mémoire : ils voient les mêmes variables. C'est ce qui les rend légers — créer un thread coûte bien moins cher que créer un processus — et c'est aussi ce qui les rend dangereux, puisque deux threads peuvent modifier la même donnée en même temps (section 5).

La concurrence, c'est gérer plusieurs tâches en cours en même temps, sans forcément les exécuter simultanément : un cuisinier qui met l'eau à bouillir, découpe des légumes pendant ce temps, puis revient à sa casserole, est concurrent. Le parallélisme, c'est exécuter réellement plusieurs calculs à la même seconde, ce qui exige plusieurs cœurs : deux cuisiniers. La distinction est décisive : pour une tâche qui passe son temps à attendre, la concurrence suffit ; pour une tâche qui calcule, il faut du parallélisme.

2. Le GIL, énoncé correctement

Ce que c'est

Le Global Interpreter Lock est un verrou interne à CPython, l'implémentation de référence de Python. Sa règle : un seul thread exécute du bytecode Python à un instant donné dans un processus. Les threads existent bien, le système d'exploitation les ordonnance, mais ils se passent ce jeton à tour de rôle au lieu de travailler en même temps.

Pourquoi il existe

Python gère la mémoire par comptage de références : chaque objet sait combien de variables pointent vers lui, et il est détruit quand ce compteur tombe à zéro. Si deux threads modifiaient ce compteur simultanément, il deviendrait incohérent — des objets encore utilisés seraient libérés, d'autres ne le seraient jamais. Le GIL est la solution la plus simple à ce problème : un verrou global plutôt qu'un verrou par objet. Il rend l'interpréteur simple, rapide en mono-thread, et facile à interfacer avec du C. Le prix est celui qu'on connaît.

La conséquence, mesurée

import time
from concurrent.futures import ThreadPoolExecutor

def calcul(n=10_000_000):            # boucle Python pure : CPU-bound
    total = 0
    for i in range(n):
        total += i * i
    return total

debut = time.perf_counter()
[calcul() for _ in range(4)]                       # séquentiel
print(f"séquentiel : {time.perf_counter() - debut:.1f} s")     # ≈ 4,0 s

debut = time.perf_counter()
with ThreadPoolExecutor(max_workers=4) as ex:      # 4 threads sur 4 cœurs
    list(ex.map(lambda _: calcul(), range(4)))
print(f"4 threads   : {time.perf_counter() - debut:.1f} s")    # ≈ 4,1 s — AUCUN gain

Quatre threads sur quatre cœurs ne vont pas plus vite qu'un seul, et sont même légèrement plus lents à cause du coût de bascule entre threads. Voilà l'effet du GIL sur du calcul Python pur.

Les deux exceptions, qui changent tout

Le GIL est relâché — c'est-à-dire rendu aux autres threads — dans deux situations :

• pendant une attente d'entrée/sortie : lecture disque, requête réseau, appel à une base de données. Le thread qui attend une réponse HTTP n'exécute aucun bytecode : il rend le jeton et les autres travaillent.
• pendant l'exécution de code natif qui le relâche explicitement — et c'est exactement ce que font NumPy, SciPy, scikit-learn, PyTorch et polars dans leurs boucles de calcul, écrites en C ou en Rust.

Autrement dit : un produit matriciel NumPy lancé dans quatre threads utilise réellement quatre cœurs, alors que la boucle Python ci-dessus n'en utilise qu'un. Ce n'est pas « les threads sont inutiles en Python », c'est « les threads sont inutiles pour du bytecode Python ».

Depuis Python 3.13 existe un mode expérimental free-threaded (PEP 703) qui supprime le GIL, mais l'écosystème scientifique n'y est pas encore entièrement porté. En 2026, on continue de raisonner avec le GIL.

3. Diagnostiquer : où passe le temps ?

Avant de choisir un outil, il faut savoir si le programme attend ou s'il calcule. C'est la seule question qui compte, et elle se tranche par la mesure, pas par l'intuition.

import time, cProfile

debut_mur = time.perf_counter()     # temps réellement écoulé (horloge murale)
debut_cpu = time.process_time()     # temps de CPU consommé par le processus

mon_traitement()

mur = time.perf_counter() - debut_mur
cpu = time.process_time() - debut_cpu
print(f"mur={mur:.1f}s  cpu={cpu:.1f}s  ratio={cpu/mur:.0%}")

# ratio proche de 100 % → le CPU travaille : CPU-bound     → processus (section 6)
# ratio faible (10-20 %) → le programme attend : I/O-bound → threads ou asyncio
cProfile.run("mon_traitement()", sort="cumtime")   # où exactement, ligne par ligne

4. Les threads, pour attendre

Le module concurrent.futures fournit une interface uniforme pour les threads comme pour les processus. Le vocabulaire : on soumet des tâches à un pool de workers, et chaque soumission renvoie un Future — un objet qui représente « un résultat qui n'existe pas encore ». On l'interroge quand on en a besoin.

from concurrent.futures import ThreadPoolExecutor
import requests

def telecharger(url: str) -> int:
    r = requests.get(url, timeout=10)      # le GIL est relâché pendant l'attente réseau
    return len(r.content)

urls = [f"https://exemple.fr/page/{i}" for i in range(200)]

with ThreadPoolExecutor(max_workers=16) as ex:   # 16 threads ; le with attend la fin
    tailles = list(ex.map(telecharger, urls))    # map : garde l'ORDRE des urls

print(sum(tailles))

Deux cents requêtes séquentielles à 100 ms font 20 secondes ; avec seize threads, environ 1,3 seconde. Le gain vient du fait que les threads passent leur temps bloqués en attente réseau, GIL relâché.

ex.map est le plus simple, mais il renvoie les résultats dans l'ordre des entrées : si la première requête est lente, on attend. Pour traiter chaque résultat dès qu'il arrive, et surtout pour gérer les erreurs proprement, on utilise submit et as_completed :

from concurrent.futures import ThreadPoolExecutor, as_completed

resultats, echecs = {}, {}

with ThreadPoolExecutor(max_workers=16) as ex:
    # on soumet tout, et on garde la correspondance future → url
    futures = {ex.submit(telecharger, url): url for url in urls}

    for fut in as_completed(futures):          # rend la main dès qu'un résultat arrive
        url = futures[fut]
        try:
            resultats[url] = fut.result()      # l'exception éventuelle surgit ICI
        except requests.Timeout:
            echecs[url] = "timeout"
        except Exception as e:                 # ne jamais laisser une tâche tuer la boucle
            echecs[url] = repr(e)

print(f"{len(resultats)} réussites, {len(echecs)} échecs")

Combien de threads ? Pour de l'I/O, on peut largement dépasser le nombre de cœurs — quelques dizaines — puisqu'ils attendent la plupart du temps. La limite vient plutôt de ce qu'accepte le service distant : au-delà, on se fait limiter ou bannir. Un ordre de grandeur raisonnable est 8 à 32, en surveillant les codes 429.

5. Partager de l'état entre threads

Puisque les threads partagent la mémoire, ils peuvent modifier les mêmes variables — et c'est là que surgissent les bugs les plus difficiles à reproduire. Une condition de course (race condition) apparaît quand le résultat dépend de l'ordre, imprévisible, dans lequel les threads s'intercalent.

compteur = 0

def incrementer(n=100_000):
    global compteur
    for _ in range(n):
        compteur += 1        # PAS atomique : lire, ajouter 1, réécrire — 3 étapes

with ThreadPoolExecutor(max_workers=4) as ex:
    list(ex.map(lambda _: incrementer(), range(4)))

print(compteur)              # attendu 400 000 ; obtenu 387 412, 400 000, 392 118...

L'explication : compteur += 1 se décompose en trois opérations. Un thread peut lire la valeur 100, être interrompu, puis un autre lit aussi 100, ajoute 1 et écrit 101 ; le premier reprend, écrit lui aussi 101. Un incrément est perdu. Le GIL ne protège pas de cela : il garantit qu'une seule instruction de bytecode s'exécute à la fois, pas qu'une séquence de trois reste indivisible.

import threading, queue

# 1. un verrou : une seule section critique à la fois
verrou = threading.Lock()
def incrementer_sur(n=100_000):
    global compteur
    for _ in range(n):
        with verrou:          # acquiert, exécute, relâche — même en cas d'exception
            compteur += 1     # correct, mais le verrou coûte cher s'il est très sollicité

# 2. NE RIEN PARTAGER : chaque thread renvoie son résultat, on agrège à la fin
def compter(n):
    total = 0
    for _ in range(n):
        total += 1
    return total              # aucune variable partagée → aucun verrou nécessaire
with ThreadPoolExecutor(4) as ex:
    compteur = sum(ex.map(compter, [100_000] * 4))    # exact, et plus rapide

# 3. une file : la structure conçue pour la communication entre threads
travaux = queue.Queue()       # thread-safe par construction
resultats = queue.Queue()

La deuxième approche est presque toujours la bonne : ne pas partager d'état mutable. Chaque tâche produit un résultat indépendant, et l'agrégation se fait dans le thread principal. Les verrous n'ont leur place que lorsqu'une ressource est intrinsèquement unique — un fichier de log, une connexion. Et il faut savoir qu'ils apportent leurs propres pièges : deux verrous acquis dans des ordres différents par deux threads produisent un interblocage, où chacun attend indéfiniment l'autre.

6. Les processus, pour calculer

Pour du calcul Python pur, la seule échappatoire au GIL consiste à lancer plusieurs processus : chacun a son propre interpréteur, donc son propre GIL. L'interface est identique à celle des threads, ce qui rend le passage de l'un à l'autre presque gratuit — mais les contraintes, elles, sont très différentes.

from concurrent.futures import ProcessPoolExecutor
import random

def simuler(graine: int) -> float:
    """Monte-Carlo en Python pur : CPU-bound, donc les threads seraient inutiles."""
    rng = random.Random(graine)
    return sum(rng.random() ** 2 for _ in range(1_000_000)) / 1_000_000

if __name__ == "__main__":                 # OBLIGATOIRE — explication ci-dessous
    with ProcessPoolExecutor(max_workers=8) as ex:
        resultats = list(ex.map(simuler, range(64), chunksize=4))
    print(sum(resultats) / len(resultats))

Ici, le gain est réel : sur huit cœurs, on approche un facteur sept. Trois contraintes expliquent en revanche la plupart des échecs rencontrés avec les processus.

a. La sérialisation

Les processus ne partagent pas la mémoire : arguments et résultats doivent donc être sérialisés — convertis en octets par le module pickle, transmis, puis reconstruits de l'autre côté. Conséquences concrètes : envoyer un DataFrame de 3 Go à huit workers, c'est le sérialiser huit fois, et le transfert coûte alors bien plus cher que le calcul. Et tout n'est pas sérialisable — les fonctions anonymes (lambda), les fonctions définies dans une autre fonction, les objets tenant un fichier ouvert ou une connexion échouent avec un message souvent obscur.

# ÉCHOUE : une lambda n'est pas picklable
ex.map(lambda x: x ** 2, donnees)

# FONCTIONNE : une fonction définie au niveau du module
def carre(x): return x ** 2
ex.map(carre, donnees)

b. La méthode de démarrage

Deux façons de créer un processus enfant. fork (historique sous Linux) duplique le processus courant : rapide, mais dangereux en présence de threads, car un verrou détenu au moment de la duplication reste verrouillé à jamais dans l'enfant — d'où des blocages inexplicables. spawn (défaut sous Windows et macOS, et sous Linux à partir de Python 3.14) démarre un interpréteur neuf qui réimporte le module.

C'est cette réimportation qui explique le fameux if __name__ == "__main__":. Sans lui, le code de lancement du pool serait réexécuté par chaque enfant, qui créerait à son tour un pool, et ainsi de suite — une bombe à fourche qui sature la machine en quelques secondes.

c. Le coût fixe

Créer un processus coûte quelques dizaines à quelques centaines de millisecondes. Paralléliser des tâches de 5 ms est donc perdant : le temps passé à distribuer dépasse le temps de calcul. C'est le rôle de chunksize, qui regroupe les tâches en paquets pour amortir ce coût. Règle simple : viser des paquets d'au moins une centaine de millisecondes de travail.

Éviter les copies : mémoire partagée et joblib

from joblib import Parallel, delayed

# n_jobs=-1 : tous les cœurs. Les grands tableaux NumPy sont mémoire-mappés
# sur disque et partagés en lecture, pas copiés dans chaque worker.
scores = Parallel(n_jobs=-1, backend="loky", verbose=1)(
    delayed(evaluer_pli)(X, y, pli) for pli in plis
)

delayed est un décorateur (module 1) qui transforme un appel en description d'appel : il capture la fonction et ses arguments sans les exécuter, pour que joblib puisse les distribuer. C'est ce backend que scikit-learn utilise sous le capot pour n_jobs.

Pour un contrôle plus fin, multiprocessing.shared_memory permet d'exposer un même bloc mémoire à plusieurs processus sans copie — utile pour un grand tableau en lecture seule partagé par tous les workers.

7. asyncio, pas à pas

L'idée

asyncio ne parallélise rien : il entrelace. Tout se passe dans un seul thread, piloté par une boucle d'événements — un ordonnanceur qui tient la liste des tâches en attente. Chaque tâche s'exécute jusqu'au moment où elle doit attendre quelque chose ; à cet instant, elle le signale, la boucle la met de côté et donne la main à une autre tâche. Quand la réponse arrive, la tâche reprend là où elle s'était arrêtée.

C'est exactement le comportement du cuisinier de la section 1 : il ne va pas plus vite, mais il ne reste jamais planté devant la casserole. Le gain est le même qu'avec des threads pour de l'I/O, sans le coût d'un thread système par tâche — on tient ainsi des dizaines de milliers de connexions simultanées.

Le vocabulaire minimal

import asyncio

async def tache(nom, duree):        # "async def" → ce n'est plus une fonction ordinaire,
    print(f"{nom} démarre")         #    mais une COROUTINE
    await asyncio.sleep(duree)      # "await" → point de pause : je rends la main
    print(f"{nom} terminée")        #    la boucle en profite pour faire tourner les autres
    return nom

async def main():
    # gather : lancer plusieurs coroutines ENSEMBLE et attendre qu'elles finissent
    resultats = await asyncio.gather(
        tache("A", 2),
        tache("B", 1),
        tache("C", 3),
    )
    return resultats

asyncio.run(main())    # "asyncio.run" → démarre la boucle d'événements et attend main()

# affiche : A démarre, B démarre, C démarre, B terminée, A terminée, C terminée
# durée totale : 3 s (le maximum), et non 6 s (la somme)

Le point à retenir : appeler tache("A", 2) ne l'exécute pas, cela crée un objet coroutine. Rien ne se passe tant qu'une boucle ne le prend pas en charge, via await, gather ou create_task. C'est d'ailleurs l'origine d'un avertissement classique — coroutine was never awaited — qui signifie simplement qu'on a oublié le await.

Un exemple réaliste

import asyncio, httpx          # httpx : l'équivalent asynchrone de requests

async def recuperer(client: httpx.AsyncClient, url: str,
                    sem: asyncio.Semaphore) -> dict | None:
    async with sem:                          # au plus N requêtes EN VOL simultanément
        for essai in range(3):               # petite politique de reprise
            try:
                r = await client.get(url, timeout=10)
                r.raise_for_status()
                return r.json()
            except (httpx.TimeoutException, httpx.HTTPStatusError):
                await asyncio.sleep(2 ** essai)    # attente exponentielle : 1s, 2s, 4s
        return None

async def main(urls: list[str]) -> list[dict | None]:
    sem = asyncio.Semaphore(20)              # le garde-fou : 20 requêtes au maximum
    async with httpx.AsyncClient() as client:     # une seule session, connexions réutilisées
        taches = [recuperer(client, u, sem) for u in urls]
        return await asyncio.gather(*taches)

resultats = asyncio.run(main(urls))
print(sum(r is not None for r in resultats), "réponses valides")

Le sémaphore mérite une explication : c'est un compteur de jetons. async with sem prend un jeton, et le rend à la sortie du bloc ; s'il n'en reste plus, la tâche attend. Sans lui, gather lancerait les 500 requêtes d'un coup, ce qui saturerait le serveur distant et provoquerait des bannissements. C'est la forme asynchrone de la politesse.

valeur = await asyncio.to_thread(fonction_bloquante, argument)

Le second inconvénient est la contagion : une fonction async ne peut être appelée que depuis du code async. Introduire asyncio dans une base de code synchrone finit par colorer toute la chaîne d'appels, et exige des bibliothèques asynchrones de bout en bout (httpx, asyncpg, aiofiles). C'est la raison pour laquelle, pour deux cents requêtes ponctuelles dans un script, un ThreadPoolExecutor reste souvent le choix le plus raisonnable.

8. Le piège de la sursouscription

Une précision de vocabulaire : BLAS (Basic Linear Algebra Subprograms) désigne les bibliothèques d'algèbre linéaire compilées — OpenBLAS, MKL — sur lesquelles reposent NumPy et scikit-learn. Elles sont déjà multi-threadées, et c'est précisément ce qu'on oublie.

# à placer AVANT l'import de numpy : ces variables sont lues au chargement
export OMP_NUM_THREADS=1
export OPENBLAS_NUM_THREADS=1
export MKL_NUM_THREADS=1

# ou, plus finement, sur un bloc de code précis :
from threadpoolctl import threadpool_limits

with threadpool_limits(limits=1, user_api="blas"):
    scores = cross_val_score(modele, X, y, cv=5, n_jobs=8)

# pour vérifier ce qui tourne réellement :
from threadpoolctl import threadpool_info
print(threadpool_info())      # liste les bibliothèques natives et leur nombre de threads

La règle générale : un seul niveau de parallélisme à la fois. Soit on parallélise les plis de validation croisée et le BLAS reste mono-thread, soit on laisse le BLAS travailler et on garde n_jobs=1. Le bon réglage se mesure sur le cas réel, il ne se devine pas.

9. Récapitulatif

Type de charge                Outil                       Parallélisme réel ?
──────────────────────────────────────────────────────────────────────────────
Requêtes HTTP, base de        asyncio + httpx             oui (entrelacement)
données async, scraping
I/O avec une bibliothèque     ThreadPoolExecutor          oui (GIL relâché)
bloquante (requests, open)
Boucles Python pures,         ProcessPoolExecutor         oui (N interpréteurs)
parsing, simulation
Validation croisée,           joblib / n_jobs             oui (backend loky)
recherche d'hyperparamètres
NumPy, PyTorch, polars        ne rien ajouter             oui (BLAS, Rayon)
Boucle Python + threads       —                           NON : le GIL bloque
Données plus grosses          Dask (module 3)             oui (out-of-core)
que la RAM

What this module covers

• The vocabulary first: processes versus threads, concurrency versus parallelism, with a flat-share analogy.
• The GIL: what it is, why CPython has it (reference counting), a ten-line measurement showing four threads gaining nothing, and the two situations where it is released.
• Diagnosing the regime by comparing wall time to CPU time, and a decision tree.
• Threads with concurrent.futures: futures, map versus submit/as_completed, mandatory timeouts, exception handling, and how many workers to use.
• Shared state between threads: a race condition demonstrated on a counter, why the GIL does not prevent it, locks, and why sharing nothing is almost always the better answer.
• Processes: pickling constraints, spawn versus fork and the if __name__ == "__main__" guard, chunk sizing, shared memory and joblib.
• asyncio explained step by step: the event loop, coroutines, await, gather, semaphores for rate limiting, retries, and the two pitfalls (a blocking call freezes everything; async colours the whole call stack).
• Thread oversubscription: why BLAS threads multiplied by process workers makes cross-validation slower, and how to control it.

Course outline

1. Modern Python: typing, decorators, iterators and tooling
2. Concurrency in Python: the GIL, threads, processes, asyncio
3. Numerical toolbox: NumPy, pandas, polars, Dask
4. SQL and databases
5. Docker, Compose and Kubernetes
6. Serving a model: FastAPI, Pydantic, Jinja
7. Data engineering: formats, pipelines and streams
8. Math for ML: optimisation, linear algebra, SVD and PCA
9. Inferential statistics: estimate, test, decide
10. Probability, Bayesian inference and uncertainty quantification
11. Causal inference: measuring the effect of an action
12. Data science in practice: from problem to dataset
13. Learning with few labels
14. Classical machine learning
15. Learning theory: why generalisation happens
16. Deep learning
17. Time series, signals and time-to-event data
18. Non-tabular data: text, images, audio, graphs
19. Gaussian processes and Bayesian optimisation
20. Reinforcement learning
21. Machine learning for simulation and engineering
22. LLMs, embeddings, RAG and adaptation
23. Search, ranking and recommendation
24. From scores to decisions
25. Scaling up: GPUs, distributed training, performance
26. MLOps: taking a model to production
27. Fairness, robustness, privacy and security
28. End-to-end project: property listings, from scraping to price prediction