Python - Comment vérifier si un nombre est pair facilement ?

Vérifier si un entier est pair fait partie des réflexes les plus utiles en Python, surtout dès qu’on écrit une validation de formulaire, un script d’automatisation ou une règle métier simple. Le test est court, mais il mérite d’être posé proprement: choisir la bonne expression, gérer les mauvaises entrées et éviter les faux raccourcis change vite la lisibilité du code.

Dans cet article, je montre la méthode la plus directe, les variantes que j’utilise selon le contexte, et les erreurs qui reviennent souvent quand on manipule des nombres, des chaînes ou des valeurs saisies par l’utilisateur.

Ce que signifie vraiment la parité en Python

Avant de parler syntaxe, je garde une règle simple en tête: un entier est pair si sa division par 2 laisse un reste nul. C’est une notion mathématique banale, mais elle évite beaucoup d’ambiguïtés quand on écrit du code de validation.

Ce point compte parce que Python manipule plusieurs types numériques. Un entier, un flottant et une chaîne de caractères ne se traitent pas de la même façon. Si je veux savoir si une valeur est paire, je commence donc par vérifier ce qu’elle représente réellement, pas seulement à quoi elle ressemble à l’écran.

Le cas de 0 mérite d’être rappelé: il est pair. Même logique pour les entiers négatifs, car la parité ne dépend pas du signe. -4 est pair, -3 est impair. Une fois ce cadre posé, le test devient presque trivial.

Avec cette base, la vraie question n’est plus « qu’est-ce qu’un nombre pair », mais quelle expression rend ce contrôle lisible et robuste dans un script.

La méthode la plus simple avec l’opérateur modulo

La version que j’utilise le plus souvent est aussi la plus lisible: n % 2 == 0. La documentation Python rappelle que l’opérateur % renvoie le reste d’une division; ici, on cherche donc simplement un reste nul après division par 2.

n = 14

if n % 2 == 0:
    print("pair")
else:
    print("impair")

Cette écriture a un avantage net: elle se lit presque comme une phrase. Pour un lecteur, il n’y a pas d’interprétation à faire. Je la recommande par défaut dans la plupart des scripts, des notebooks et des fonctions métier.

Si la valeur peut venir d’une saisie, je préfère convertir d’abord la donnée en entier, puis faire le test. Le contrôle de type et le contrôle de parité ne devraient pas être mélangés dans la même ligne si le code doit rester maintenable.

raw_value = input("Entrez un entier : ")

try:
    n = int(raw_value)
except ValueError:
    print("Valeur invalide")
else:
    print(n % 2 == 0)

Ce découpage rend le flux plus clair: d’abord je valide l’entrée, ensuite je teste la parité. C’est ce qui évite les scripts fragiles dès qu’on les branche sur une API, un CSV ou une interface utilisateur.

Une fois ce réflexe acquis, on peut passer à une version encapsulée, plus utile dès qu’un même test revient plusieurs fois dans le projet.

Construire une fonction réutilisable sans perdre en clarté

Dans un code un peu sérieux, je préfère presque toujours isoler le test dans une fonction. Cela donne un nom explicite à l’intention, facilite les tests unitaires et évite de répéter la même condition partout.

def est_pair(n):
    return n % 2 == 0

print(est_pair(8))   # True
print(est_pair(11))  # False

Cette version suffit si je maîtrise déjà le type de n. En revanche, dès qu’une fonction peut recevoir des données moins propres, j’ajoute une vérification minimale. C’est particulièrement utile dans un contexte d’automatisation, où les entrées viennent parfois d’un fichier, d’un message JSON ou d’une saisie manuelle.

def est_pair(valeur):
    if isinstance(valeur, bool):
        raise TypeError("bool ne doit pas être traité comme un entier métier")
    if not isinstance(valeur, int):
        raise TypeError("un entier est attendu")
    return valeur % 2 == 0

J’insiste sur le cas de bool parce qu’en Python, True et False se comportent comme des entiers dans certains contextes. Techniquement, True vaut 1 et False vaut 0. Dans un code métier, ce raccourci peut semer une confusion inutile, donc je le bloque si le sens métier est vraiment « nombre ».

Si l’on a en face de soi des chaînes ou des flottants, il faut aller un peu plus loin pour garder une fonction honnête et prévisible.

Gérer les chaînes, les flottants et les valeurs douteuses

La plupart des erreurs ne viennent pas du test de parité lui-même, mais de la valeur qu’on lui donne. Une chaîne comme "12" doit être convertie. Un flottant comme 12.0 mérite une décision explicite. Et une valeur comme "12a" doit être rejetée sans ambiguïté.

Pour une chaîne, je pars du principe qu’elle représente un entier seulement si la conversion int() réussit. Pour un flottant, je suis plus prudent: 12.0 peut être accepté si le besoin métier l’autorise, mais 12.5 ne peut pas être considéré comme pair au sens strict.

def est_pair_strict(valeur):
    if isinstance(valeur, bool):
        raise TypeError("bool ne doit pas être traité comme un entier")
    if isinstance(valeur, int):
        return valeur % 2 == 0
    if isinstance(valeur, float) and valeur.is_integer():
        return int(valeur) % 2 == 0
    if isinstance(valeur, str):
        try:
            return int(valeur) % 2 == 0
        except ValueError as exc:
            raise ValueError("chaîne non convertible en entier") from exc
    raise TypeError("un entier, une chaîne entière ou un flottant entier sont attendus")

Je ne conseille pas d’étendre cette fonction sans raison. Plus on accepte de formats d’entrée, plus il faut documenter le comportement. Dans une API, cette décision doit être cohérente avec la validation en amont et le contrat de données.

Une fois ces cas limites cadrés, on peut comparer les méthodes pour choisir celle qui correspond vraiment au contexte du projet.

Comparer les approches les plus utiles selon le contexte

Pour un débutant, le modulo reste la meilleure porte d’entrée. Mais il existe deux variantes qu’on rencontre souvent: divmod() pour obtenir quotient et reste en même temps, et & 1 pour une optimisation binaire très compacte. La documentation Python précise d’ailleurs que divmod() renvoie le quotient et le reste de la division entière.

Je réserve & 1 aux situations où je sais que le public est à l’aise avec les opérations binaires. Pour un projet partagé, la lisibilité compte plus que le style « astucieux ». En pratique, le gain de performance est rarement le vrai sujet ici.

Ce tableau aide surtout à choisir sans sur-optimiser. La dernière étape consiste à éviter les erreurs qui reviennent quand on code vite.

Les erreurs que je vois le plus souvent

La première erreur consiste à confondre division et reste. n / 2 == 0 ne teste rien de pertinent pour la parité, parce que / produit un quotient, pas un reste. Le bon opérateur pour ce problème est bien %.

La deuxième erreur vient des entrées textuelles. Beaucoup de scripts lisent une valeur avec input(), puis appliquent le test sans conversion. Le résultat est soit une erreur, soit un comportement incohérent si le code a été bricolé pour « passer quand même ».

La troisième erreur est plus subtile: croire qu’un flottant proche d’un entier est un entier. 4.0 peut être traité comme un entier si le besoin le justifie, mais 4.2 n’entre pas dans la même catégorie. Je conseille de décider ça explicitement au lieu de laisser le code improviser.

Enfin, il y a le piège du faux raccourci. Une expression compacte n’est pas forcément meilleure. Dans un script de production, je préfère une ligne simple et correcte à une astuce difficile à relire six mois plus tard.

Quand ces pièges sont évités, le test de parité devient un petit bloc de code fiable, presque invisible, qui fait exactement son travail.

Ce que je garde en tête pour un vrai script

Pour vérifier qu’un nombre est pair, je reviens presque toujours au même principe: une valeur claire, une conversion explicite si besoin, puis n % 2 == 0. C’est court, lisible et solide dans la majorité des cas.

Si je dois intégrer ce contrôle dans un projet plus large, je pense aussi au contrat de données: quel type arrive, quelle erreur je renvoie, et si bool doit être accepté ou rejeté. Ces détails font souvent la différence entre un script qui « marche » et un composant qu’on peut vraiment réutiliser.

En pratique, la bonne approche n’est pas la plus sophistiquée, mais celle qui garde le comportement évident pour le lecteur, y compris plusieurs semaines après l’écriture du code.