If, else et elseif sans confusion pour écrire des conditions lisibles

Une condition sert à faire prendre une décision au code : exécuter une action si un test est vrai, en choisir une autre si le test est faux, ou passer à un cas suivant quand plusieurs scénarios existent. Pour une PME, c’est la base d’un script fiable : contrôle d’un fichier, validation d’un formulaire, seuil d’alerte, droit d’accès ou règle métier.

L’ancien article expliquait le principe, mais il restait trop abstrait et répétitif. Cette refonte revient à l’essentiel : comprendre if, else et else if / elif, puis savoir quand simplifier une condition avant qu’elle ne devienne difficile à maintenir.

À quoi sert une structure conditionnelle ?

Une structure conditionnelle exécute un bloc de code selon le résultat d’un test. Si la condition est vraie, le programme suit une branche ; sinon, il peut ignorer le bloc ou appliquer une alternative. C’est le mécanisme qui transforme une suite d’instructions rigide en logique capable de réagir à un contexte.

Le piège courant consiste à penser “syntaxe” avant de penser “décision”. Avant d’écrire la condition, formulez la règle en français : “si le fichier existe, je le traite ; sinon, je crée une erreur lisible”. Cette phrase devient ensuite un test simple, beaucoup plus facile à relire.

La forme de base : if puis else

Le modèle le plus simple oppose deux chemins. Il est adapté quand une décision a deux issues nettes : autorisé/refusé, présent/absent, actif/inactif, suffisant/insuffisant. En Python, la lecture reste directe grâce à l’indentation.

age = 19

if age >= 18:
    print("Accès autorisé")
else:
    print("Accès refusé")

Dans cet exemple, un seul message s’affiche. La condition age >= 18 est évaluée ; si elle passe, Python exécute le premier bloc. Si elle échoue, il bascule vers la branche else. Le même principe existe dans JavaScript, PHP, C, Java, PowerShell ou Bash, avec des différences de ponctuation et de blocs.

const stock = 3;

if (stock > 0) {
  console.log("Produit disponible");
} else {
  console.log("Rupture de stock");
}

Quand utiliser else if, elif ou elseif ?

Une branche intermédiaire sert quand deux issues ne suffisent pas. En Python, on écrit elif. En JavaScript, on écrit else if. En PHP, on peut rencontrer elseif. Le nom change, mais l’idée reste identique : tester les cas dans un ordre précis et s’arrêter dès qu’un cas correspond.

score = 82

if score >= 90:
    niveau = "excellent"
elif score >= 70:
    niveau = "correct"
else:
    niveau = "à revoir"

Ici, l’ordre est essentiel. Si vous testez score >= 70 avant score >= 90, le score 95 sera classé “correct” trop tôt. Une chaîne de conditions doit donc aller du cas le plus spécifique vers le cas le plus général, ou suivre une priorité métier explicitement assumée.

Exemple utile en script système

Dans un contexte IT, les conditions servent souvent à vérifier un prérequis avant d’exécuter une action. Un script Bash peut contrôler la présence d’un fichier de configuration avant de lancer une suite d’opérations. C’est simple, mais cela évite une erreur plus coûteuse plus loin dans le traitement.

CONFIG="/etc/app/config.yml"

if [ -f "$CONFIG" ]; then
  echo "Configuration trouvée"
else
  echo "Configuration manquante"
  exit 1
fi

Ce type de contrôle doit rester explicite. Le lecteur du script doit comprendre en quelques secondes ce qui est testé, pourquoi l’exécution s’arrête et quel message apparaîtra. Une bonne condition n’est pas seulement correcte : elle fournit un diagnostic exploitable.

Traduire une règle métier en condition simple

Dans une application interne, la condition n’est pas seulement un exercice de syntaxe. Elle représente souvent une règle métier : accorder une remise, bloquer une action, demander une validation ou afficher une alerte. Si la règle est floue, le code le sera aussi. Commencez donc par écrire la décision attendue avant de choisir les opérateurs.

Exemple : “si le client est actif et que la facture est en retard de plus de 30 jours, afficher une relance”. Cette phrase contient deux tests et une action. Elle peut être codée directement, mais elle sera souvent plus lisible si les sous-conditions sont nommées. Le code suivant reste volontairement simple, parce que la lisibilité compte plus que la démonstration technique.

client_actif = True
jours_retard = 42

facture_en_retard = jours_retard > 30

if client_actif and facture_en_retard:
    print("Envoyer une relance")
else:
    print("Ne rien envoyer")

Cette forme évite une expression compacte mais opaque. Dans un vrai projet, vous pourriez même extraire client_actif et facture_en_retard dans des fonctions séparées si la règle évolue. Le bénéfice est concret : quand un collègue relit le script, il comprend la décision sans reconstituer toute la logique dans sa tête.

Quand remplacer une cascade de if ?

Les conditions deviennent difficiles à maintenir quand elles testent trop de cas, répètent le même bloc ou mélangent plusieurs responsabilités. Si vous comparez toujours la même variable à plusieurs valeurs, un switch, un dictionnaire de correspondance ou une table de règles peut être plus propre. Si chaque branche contient beaucoup de logique, extrayez des fonctions nommées.

Les erreurs qui rendent les conditions difficiles à maintenir

La première erreur est l’imbrication excessive. Un if dans un if dans un autre if oblige le lecteur à garder trop d’états en mémoire. Quand c’est possible, inversez la logique avec une sortie anticipée : traitez d’abord les cas invalides, puis laissez le cas normal se lire sans indentation profonde.

La deuxième erreur est le test négatif mal nommé. Une variable comme notDisabled ou isNotInactive ralentit la lecture, surtout dans une condition déjà inversée. Préférez des noms positifs : utilisateurActif, fichierDisponible, quotaDepasse. Le code devient plus proche de la phrase métier.

La troisième erreur est le else fourre-tout. Si la branche de repli mélange absence de donnée, erreur de permission et cas inconnu, le diagnostic devient pauvre. Un bon else doit dire clairement ce qu’il couvre. Si plusieurs situations différentes y tombent, ajoutez une branche dédiée ou remontez une erreur plus précise.

La priorité n’est donc pas d’utiliser if partout. La priorité est de garder un flux décisionnel lisible. Commencez par écrire la règle en langage naturel, codez le cas principal, ajoutez le repli, puis seulement ensuite les branches intermédiaires. Si la lecture devient pénible, le problème n’est plus la syntaxe : c’est la structure.

Pour un script PME, retenez cette règle pratique : une condition doit protéger une action, expliquer un refus ou orienter vers un traitement clair. Si elle ne fait aucune de ces trois choses, elle mérite probablement d’être simplifiée.

Avant une mise en production, relisez enfin les chemins d’erreur avec autant d’attention que le chemin nominal. Ce sont souvent les branches rarement déclenchées qui révèlent les messages imprécis, les droits mal compris ou les retours utilisateur trop vagues.