Définition
Un programme a rarement deux issues seulement. Un formulaire d'inscription ne répond pas par « valide » ou « invalide » : il distingue un champ laissé vide, un mot de passe trop court, une adresse déjà utilisée. Or un if suivi d'un else n'ouvre que deux portes. Dès qu'il en faut une troisième, il manque un mot pour dire « sinon, essayons plutôt ceci ».
Ce mot est elif, contraction de « else if ». Il ajoute un test à une chaîne conditionnelle, et ce test n'est évalué que si tous ceux qui le précèdent ont échoué. Un if peut ainsi être suivi d'autant de elif que nécessaire, puis se terminer par un else facultatif qui ramasse les cas qu'aucune branche n'a attrapés.
Voici une chaîne complète, qui traduit une température en conseil vestimentaire. L'important n'est pas la logique, elle tient en trois seuils, mais l'ordre dans lequel ces seuils sont écrits.
temperature = 12
# Python descend les tests un par un et s'arrête au premier qui est vrai
if temperature > 30:
conseil = "Restez à l'ombre"
elif temperature > 20:
conseil = "Sortez couvert léger"
elif temperature > 10:
conseil = "Prenez une veste"
else:
conseil = "Manteau obligatoire"Suivez Python sur cet exemple. Il essaie temperature > 30, faux avec 12 degrés. Il passe au deuxième test, faux lui aussi. Le troisième, temperature > 10, est vrai : il exécute la ligne qui suit, puis quitte la chaîne. Le else n'est même pas regardé.
Une seule branche s'exécute donc, toujours la première dont la condition est vraie. Les suivantes ne sont pas simplement ignorées, elles ne sont jamais évaluées. La nuance compte dès que tester coûte quelque chose : un test qui interroge une base de données ou appelle un service distant, placé en fin de chaîne, ne sera joué que dans les rares cas où tout le reste a échoué.
Pourquoi elif plutôt qu'un if imbriqué
elif n'apporte aucune capacité nouvelle au langage. Tout ce qu'il exprime, un else contenant un autre if l'exprimerait aussi, et avec le même résultat. Son intérêt est ailleurs : dans la forme que prend le code une fois écrit.
Sans elif, chaque alternative supplémentaire décale le bloc suivant d'un cran vers la droite. Sur quatre cas, la dernière branche se retrouve à seize espaces du bord, et l'indentation finit par occuper plus de place que la logique qu'elle porte.
Voici la même décision écrite sans elif, réduite à trois cas pour rester lisible.
# Ce que elif évite : un niveau de plus à chaque alternative
if temperature > 30:
conseil = "Restez à l'ombre"
else:
if temperature > 20:
conseil = "Sortez couvert léger"
else:
if temperature > 10:
conseil = "Prenez une veste"Les deux versions produisent exactement le même résultat. La première se lit comme une liste de cas que l'œil parcourt de haut en bas ; la seconde comme un escalier, où il faut retenir à chaque marche ce qui a déjà été écarté plus haut. Le gain ne se mesure pas au temps d'exécution, identique dans les deux cas, mais au temps qu'il vous faudra pour relire ce code dans six mois. C'est exactement le genre d'arbitrage que Python tranche en faveur de la lisibilité.
Le mot s'écrit en un seul morceau. else if en deux mots, réflexe naturel quand on arrive de JavaScript ou de C, ne passe pas : après else, Python attend un deux-points et un bloc indenté, et signale une SyntaxError.
Une chaîne de elif n'est pas une suite de if
La confusion la plus fréquente ne porte pas sur la syntaxe, mais sur ce qui se passe quand on l'oublie. Trois if écrits l'un sous l'autre ressemblent beaucoup à une chaîne de elif : même alignement, mêmes tests, même allure à l'écran. Le comportement, lui, n'a rien à voir.
Reprenez l'exemple des températures et remplacez les deux elif par des if. Python ne voit plus une chaîne, mais trois questions indépendantes qu'il pose l'une après l'autre. Avec 35 degrés, la première est vraie, la deuxième aussi, la troisième également : conseil reçoit trois valeurs successives et conserve la dernière, « Prenez une veste ». Le else, qui ne se rattache plus qu'au dernier if, cesse d'être le filet de sécurité de l'ensemble.
Rien ne plante, et c'est bien le problème : le programme conseille une veste un jour de canicule. La distinction se retient en une phrase. Des if successifs posent des questions indépendantes, auxquelles plusieurs réponses peuvent être vraies en même temps ; une chaîne de elif pose une question à choix unique.
Cette erreur ne se trahit que sur les valeurs qui satisfont plusieurs tests à la fois. Avec les 12 degrés de l'exemple, la version fautive et la version correcte donnent le même conseil : le défaut passe les tests et n'apparaît qu'en production, sur la première valeur extrême rencontrée.
L'ordre est un piège
Sur des seuils numériques, une chaîne mal ordonnée donne un résultat faux sans lever la moindre erreur. Placez le test > 10 en premier : une température de 35 degrés y répond vrai, la branche s'exécute, et les deux tests plus exigeants qui suivent ne sont jamais atteints. Le programme tourne, il se trompe simplement de conseil.
La cause tient à la façon dont Python lit la chaîne. Il ne cherche pas le test le mieux adapté à la valeur, il prend le premier qui répond vrai. Le tri, personne ne le fera à votre place : classez les tests du plus restrictif au plus large, du cas le plus rare vers le plus courant.
Reste la situation où les branches ne s'ordonnent pas. Un aiguillage sur des noms de pays, de statuts ou de commandes n'a ni cas rare ni cas large, et la question du classement n'a plus de sens. Un dictionnaire y est presque toujours plus clair qu'une chaîne de dix elif : chaque clé associe directement une valeur ou une fonction à appeler, et ajouter un cas devient une ligne de données plutôt qu'une branche de code de plus.
Questions fréquentes
Combien de elif peut-on enchaîner ?
Le langage n'impose aucune limite. La lisibilité, elle, décroche vers cinq ou six branches : au-delà, un dictionnaire de correspondances ou l'instruction match se relit bien mieux. Une longue chaîne signale souvent une donnée qui mériterait d'être structurée plutôt que déroulée en code.
Un elif peut-il exister sans if ?
Non. Un elif isolé déclenche une SyntaxError avant même que le programme démarre, car il n'a de sens que rattaché au if qui ouvre la chaîne. La même règle vaut pour else, qui doit toujours clore une structure existante.
Faut-il toujours terminer par un else ?
Ce n'est pas obligatoire, mais c'est prudent dès qu'une valeur doit exister dans tous les cas. Sans branche finale, une variable affectée seulement dans certaines branches n'existe pas du tout ailleurs, et sa lecture provoque une NameError bien plus loin dans le programme, à un endroit qui ne dira rien de la vraie cause. Ce genre de décision se structure sur des cas réels dans notre formation Python.