Des Mathématiques combinatoires avec Python et itertools.combinations

En Mathématiques, “choisir” sans tenir compte de l’ordre, c’est la combinaison. En Python, c’est exactement ce que fait itertools.combinations : il énumère toutes les sélections possibles de taille k parmi une liste, sans doublon, et sans permutation inutile. Résultat : du code plus clair, plus sûr… et souvent plus rapide que des boucles bricolées.

Une combinaison de taille p parmi n objets, c’est un choix sans ordre.

• {A, B, C} et {C, B, A} représentent la même combinaison.
• Le nombre de choix possibles est le coefficient binomial :  C_n^p

C_n^p, souvent écrit \binom{n}{p} dans la littérature anglo-saxonne et en informatique.

C_n^p se lit : « p parmi n »

Cela désigne le nombre de combinaisons de p éléments choisis parmi n, sans tenir compte de l’ordre.

itertools.combinations ne renvoie pas une liste : c’est un itérateur

Lorsque l’on utilise itertools.combinations, il est tentant de penser que la fonction renvoie immédiatement une liste contenant toutes les combinaisons possibles. Ce n’est pas le cas. L’appel :

from itertools import combinations
comb = combinations([1, 2, 3, 4], 2)

ne construit pas en mémoire toutes les paires possibles. Il renvoie un objet itérateur, c’est-à-dire un objet capable de produire les combinaisons au fur et à mesure, uniquement lorsqu’elles sont demandées.

Si l’on affiche directement l’objet :

print(comb)

Python renvoie quelque chose comme :

>>> # script executed
<itertools.combinations object at 0x1164f90>
>>> 
 

Tester dans le Bac à sable Python!

Cela signifie que l’on dispose d’un générateur de combinaisons, et non d’une collection déjà matérialisée.

Pourquoi un itérateur et non une liste ?

Ce choix n’est pas anodin. Il est directement lié à la nature combinatoire du problème.

Le nombre de combinaisons de p éléments parmi n est donné par
C_n^p.

Or cette quantité peut devenir extrêmement grande lorsque $n$n augmente. Générer toutes les combinaisons et les stocker en mémoire pourrait devenir coûteux, voire impossible.

Un itérateur adopte une stratégie dite lazy (évaluation paresseuse) :

• une combinaison est calculée,
• elle est transmise au programme,
• puis la suivante est calculée uniquement si nécessaire.

Ainsi, la mémoire utilisée reste minimale.

Conséquence pratique : parcours progressif

L’utilisation naturelle d’un objet combinations se fait dans une boucle :

from itertools import combinations

for a, b in combinations([1, 2, 3, 4], 2):
    print(a, b)

Les paires sont produites successivement. À aucun moment l’ensemble des combinaisons n’est stocké dans une liste complète.

Cette approche présente un avantage important : si l’on cherche une combinaison vérifiant une condition donnée, il est possible d’interrompre le parcours dès que le résultat est trouvé :

from itertools import combinations

nums = [2, 7, 11, 15, 3, 6]
for a, b in combinations(nums, 2):
    if a + b == 9:
        print(a, b)
        break

Dans ce cas, seules les combinaisons nécessaires sont générées.

⚠ Un itérateur se consomme

Un point essentiel doit être souligné : un itérateur ne peut être parcouru qu’une seule fois.

from itertools import combinations

c = combinations([1, 2, 3, 4], 2)

print(list(c))   # première conversion
print(list(c))   # seconde conversion

La seconde conversion renverra une liste vide. L’itérateur a été “épuisé” lors du premier parcours.

Tester dans le Bac à sable Python!

Si plusieurs parcours sont nécessaires, il convient soit de recréer l’itérateur, soit de convertir explicitement le résultat en liste — à condition que le volume de données reste raisonnable :

pairs = list(combinations([1, 2, 3, 4], 2))

Itérateur et combinatoire : une cohérence conceptuelle

Il existe une cohérence profonde entre la notion mathématique de combinaison et l’implémentation choisie par Python.

Le coefficient combinatoire C_n^p peut croître très rapidement. En conséquence, une approche “en flux” est souvent plus pertinente qu’une approche fondée sur le stockage intégral des résultats.

itertools.combinations ne fournit donc pas une liste prête à l’emploi, mais un mécanisme de génération contrôlée. Ce choix reflète une philosophie plus large de Python : privilégier l’efficacité mémoire et la modularité des traitements.

Exemple : générer les mains de poker sans itertools (version lourde)

Au Texas Hold’em No Limit, vous recevez 2 cartes privatives.

Supposons que l’on représente le paquet par les entiers de 0 à 51.

Sans itertools, on peut écrire deux boucles imbriquées pour représenter ces cartes privatives possibles :

deck = list(range(52))

hands = []

for i in range(len(deck)):
    for j in range(i + 1, len(deck)):
        hands.append((deck[i], deck[j]))

print(len(hands))  # 1326

Tester dans le Bac à sable Python!

Ici :

Ici :

• toutes les 1326 mains sont construites,
• elles sont stockées dans la liste hands,
• la mémoire contient simultanément toutes les combinaisons.

Cette méthode fonctionne, mais :

• elle construit explicitement la liste complète,
• elle demande d’écrire la logique d’évitement des doublons (j = i + 1),
• elle devient très lourde si le nombre de cartes augmente (5 cartes par exemple).

Version avec itertools.combinations (version légère)

La même opération peut s’écrire :

from itertools import combinations

deck = range(52)

for hand in combinations(deck, 2):
    print(hand)

Différence fondamentale :

• aucune liste complète n’est créée,
• chaque main est produite une par une,
• la mémoire reste minimale.

Si l’on souhaite simplement connaître le nombre total :

count = 0
for _ in combinations(deck, 2):
    count += 1

print(count)  # 1326

Le résultat est identique, mais sans stockage massif.

Pourquoi la différence devient spectaculaire avec 5 cartes

Pour une main complète de 5 cartes :

soit 2 598 960 combinaisons.

La version “lourde” devrait créer une liste contenant plus de 2,5 millions de tuples :

hands = list(combinations(range(52), 5))

Cela représente plusieurs dizaines de mégaoctets en mémoire.

En revanche, l’itérateur :

for hand in combinations(range(52), 5):
    # analyse statistique
    pass

ne conserve qu’une seule combinaison à la fois.

En résumé

Sans itertools :

• on construit explicitement toutes les mains,
• on les stocke,
• la mémoire croît avec le nombre de combinaisons.

Avec itertools.combinations :

• on délègue la génération à un itérateur,
• les mains sont produites à la demande,
• la mémoire reste stable, même lorsque le nombre de combinaisons explose.

Dans un contexte combinatoire comme le poker, où les quantités passent rapidement de 1326 à plusieurs millions, cette différence n’est pas anecdotique : elle est structurelle.

Personnellement :

La première fois que j’ai utilisé itertools.combinations — encore avec une certaine hésitation — c’était lors de la génération des mains pour l’a page’application Poker Training de site2wouf.fr.

À ce moment-là, l’objectif était simplement pratique : produire proprement toutes les mains possibles sans écrire des boucles imbriquées interminables. Ce n’est qu’ensuite que la portée conceptuelle est devenue évidente. Derrière une ligne de code concise se cachait une idée mathématique ancienne : la combinatoire.

Ce qui paraissait être un simple outil Python révélait en réalité une cohérence profonde entre la théorie et l’implémentation. Générer des mains de poker revient exactement à parcourir les C_{52}^2 combinaisons possibles. Python ne faisait que traduire, de manière élégante, une formule déjà connue.

Avec un peu de recul, cette première utilisation a marqué un déclic : combinations n’est pas seulement pratique, il incarne une manière plus rigoureuse de penser les problèmes. Plutôt que de “fabriquer des listes”, il invite à raisonner en termes de génération contrôlée, de flux, et d’efficacité.

C’est précisément là que les mathématiques et la programmation cessent d’être deux mondes distincts pour devenir deux expressions d’une même idée.

Quand la mécanique masque l’idée

Imaginons que l’on souhaite former tous les groupes possibles de 3 élèves parmi une classe de 20.

students = [
    "Alice", "Mohamed", "Sofia", "Lucas", "Yuki",
    "Amina", "Ethan", "Fatou", "Mateo", "Inès",
    "Noah", "Lina", "Arjun", "Chloé", "Ibrahim",
    "Maya", "Diego", "Leïla", "Hugo", "Zara"
]

groups = []

for i in range(len(students)):
    for j in range(i + 1, len(students)):
        for k in range(j + 1, len(students)):
            groups.append((students[i], students[j], students[k]))

print(len(groups))

Tester dans le Bac à sable Python!

Ce programme fonctionne.

Mais plusieurs éléments apparaissent immédiatement :

• la structure repose sur trois boucles imbriquées ;
• les prénoms ne sont jamais manipulés directement ;
• le code parle d’indices (i, j, k) plutôt que d’élèves.

Autrement dit, la mécanique de parcours prend le pas sur l’idée mathématique.

Et si l’on décide de former des groupes de 4 élèves, il faut ajouter une quatrième boucle.
La structure du code devient dépendante de la profondeur combinatoire.

La version abstraite

Avec itertools.combinations, la même idée s’écrit :

from itertools import combinations

students = [
    "Alice", "Mohamed", "Sofia", "Lucas", "Yuki",
    "Amina", "Ethan", "Fatou", "Mateo", "Inès",
    "Noah", "Lina", "Arjun", "Chloé", "Ibrahim",
    "Maya", "Diego", "Leïla", "Hugo", "Zara"
]

groups = combinations(students, 3)

print(len(list(groups)))

Tester dans le Bac à sable Python!

Ici :

• aucune boucle imbriquée n’apparaît ;
• aucun indice n’est manipulé ;
• l’intention est explicite : “choisir 3 élèves parmi 20”.

Mathématiquement, le nombre de groupes possibles est :

soit 1140 combinaisons.

La structure du code ne change pas si l’on passe à 4 élèves :

groups = combinations(students, 4)

Seul le paramètre varie.
La mécanique reste identique.

Ce que l’outil change réellement

Dans la version artisanale :

• la profondeur des boucles reflète directement la profondeur combinatoire ;
• le code dépend structurellement du nombre d’éléments choisis ;
• l’intention est noyée dans la gestion des indices.

Dans la version avec combinations :

• la combinatoire est encapsulée ;
• la structure du programme reste stable ;
• l’idée mathématique devient visible.

Le programme ne décrit plus comment parcourir des indices,
il exprime simplement ce que l’on souhaite obtenir.

Et c’est précisément là que la programmation rejoint les mathématiques :
lorsque la structure du code devient l’expression directe d’un concept.