Logique de programmation : décomposer un problème en étapes actionnables

Passer d’un énoncé à un algorithme : une méthode reproductible

Décomposer un problème en étapes actionnables consiste à transformer une phrase du quotidien (souvent floue) en une suite d’instructions non ambiguës. L’objectif n’est pas d’écrire du code, mais de produire un algorithme clair : quelles informations on reçoit, ce qu’on doit produire, quelles règles on doit respecter, et comment traiter les cas particuliers.

Étape 1 — Lire le problème avec une grille : entrées, sorties, contraintes

Avant toute solution, on extrait explicitement :

• Entrées : données fournies (par l’utilisateur, un capteur, un fichier…).
• Sorties : résultat attendu (affichage, valeur calculée, décision oui/non…).
• Contraintes : règles à respecter (plages de valeurs, formats, arrondis, interdictions, priorités).
• Critères de réussite : comment sait-on que c’est correct ? (ex. somme exacte, format précis, validation).

Astuce pratique : sur l’énoncé, surlignez les verbes d’action (calculer, convertir, vérifier, comparer) et les mots de règle (doit, uniquement, au moins, au plus, arrondi, valide).

Étape 2 — Reformuler en phrase testable

Une bonne reformulation est une phrase qui pourrait servir de test :

• « Étant donné … (entrées), produire … (sorties) en respectant … (contraintes). »

Exemple de reformulation : « Étant donné un montant payé et un prix, calculer la monnaie à rendre en billets/pièces, uniquement si les montants sont valides et si le paiement couvre le prix. »

Continuez dans notre application.

Vous pouvez écouter le livre audio écran éteint, recevoir un certificat gratuit pour ce cours et accéder également à 5 000 autres cours en ligne gratuits.

Ou poursuivez votre lecture ci-dessous...

Téléchargez l'application

Étape 3 — Choisir les variables, les unités et les domaines de valeurs

On liste les variables nécessaires et on précise :

• Nom (explicite), unité (€, centimes, secondes…), type (entier, réel, texte), domaine (ex. entier ≥ 0).
• Représentation : éviter les ambiguïtés (ex. argent en centimes plutôt qu’en décimales).

Étape 4 — Distinguer cas nominaux et cas limites

Cas nominaux : ceux qu’on s’attend à rencontrer le plus souvent (données correctes, valeurs « normales »). Cas limites : valeurs aux frontières ou situations atypiques (zéro, maximum, format invalide, mois 2, 31, etc.).

Technique : pour chaque entrée, notez au moins 3 valeurs : une valeur typique, une valeur minimale, une valeur maximale (ou une valeur « interdite »).

Exercice guidé 1 — Rendu de monnaie avec validation des montants

Analyse (entrées / sorties / contraintes)

• Entrées : prix, paye (montants).
• Sorties : soit un message d’erreur, soit le détail du rendu (quantités par coupure) et le total rendu.
• Contraintes : montants ≥ 0 ; paye ≥ prix ; travailler en centimes (entiers) ; utiliser une liste de coupures (ex. 2000, 1000, 500, 200, 100, 50, 20, 10, 5, 2, 1).

Tableau d’exemples

Pseudo-code commenté

// Objectif : calculer la monnaie à rendre en coupures, avec validation stricte.// Convention : tous les montants sont en centimes (entiers).ENTRÉE prix, payeSI prix < 0 OU paye < 0 ALORS    SORTIE "Erreur : montants négatifs interdits"    STOPFIN SI SI paye < prix ALORS    SORTIE "Erreur : paiement insuffisant"    STOPFIN SI rendu <- paye - prixSI rendu = 0 ALORS    SORTIE "Aucun rendu"    STOPFIN SI coupures <- [2000, 1000, 500, 200, 100, 50, 20, 10, 5, 2, 1]POUR CHAQUE c DANS coupures FAIRE    nb <- rendu DIV c          // nombre de coupures de valeur c    SI nb > 0 ALORS        SORTIE nb, "x", c, "centimes"  // ou format € si besoin        rendu <- rendu - nb * c   // on retire ce qu'on a rendu    FIN SIFIN POUR// À la fin, rendu doit être 0 si la liste contient 1 centime.

Erreurs fréquentes

• Oubli d’unités : mélanger euros et centimes (ex. 7,50 traité comme 7500).
• Confusion entrée/sortie : recalculer prix au lieu de produire le rendu.
• Hypothèses implicites : supposer que paye est toujours ≥ prix sans le vérifier.
• Décimales non maîtrisées : utiliser des réels pour l’argent et obtenir des erreurs d’arrondi.

Exercice guidé 2 — Convertir une durée (secondes → h/min/s)

Analyse (entrées / sorties / contraintes)

• Entrée : totalSecondes.
• Sorties : heures, minutes, secondes (reste).
• Contraintes : totalSecondes entier ≥ 0 ; conversion basée sur 1 h = 3600 s, 1 min = 60 s.

Tableau d’exemples

Pseudo-code commenté

// Objectif : décomposer un total de secondes en h/min/s.ENTRÉE totalSecondesSI totalSecondes < 0 ALORS    SORTIE "Erreur : durée négative"    STOPFIN SI heures <- totalSecondes DIV 3600reste <- totalSecondes MOD 3600minutes <- reste DIV 60secondes <- reste MOD 60SORTIE heures, minutes, secondes

Erreurs fréquentes

• Oubli d’unités : confondre minutes et secondes dans les constantes (60 vs 3600).
• Confusion entrée/sortie : modifier totalSecondes sans conserver un reste clair.
• Hypothèses implicites : accepter des valeurs non entières (ex. 12,5 s) sans règle de conversion.

Exercice guidé 3 — Déterminer si une date est valide (jour/mois)

Analyse (entrées / sorties / contraintes)

• Entrées : jour, mois.
• Sortie : booléen estValide (ou message).
• Contraintes : mois entre 1 et 12 ; jour ≥ 1 ; le maximum dépend du mois (31/30/28). Ici, on ne gère pas l’année : février = 28 jours.

Tableau d’exemples

Pseudo-code commenté

// Objectif : valider une date (jour/mois) sans année.ENTRÉE jour, moisSI mois < 1 OU mois > 12 ALORS    SORTIE FAUX    STOPFIN SI SI jour < 1 ALORS    SORTIE FAUX    STOPFIN SI // Déterminer le nombre de jours max du moisSI mois = 2 ALORS    maxJours <- 28SINON SI mois = 4 OU mois = 6 OU mois = 9 OU mois = 11 ALORS    maxJours <- 30SINON    maxJours <- 31FIN SI SI jour > maxJours ALORS    SORTIE FAUXSINON    SORTIE VRAIFIN SI

Erreurs fréquentes

• Oubli d’unités : moins fréquent ici, mais confusion possible si on reçoit une date en texte (ex. « 03 ») et qu’on ne définit pas la conversion.
• Confusion entrée/sortie : « corriger » la date (ex. transformer 31/04 en 30/04) au lieu de répondre valide/invalide.
• Hypothèses implicites : supposer que février a 29 jours, ou que le mois est toujours entre 1 et 12.

Exercice guidé 4 — Comparer deux offres (prix + frais) en explicitant les critères

Analyse (entrées / sorties / contraintes)

• Entrées : pour chaque offre A et B : prix, frais (livraison, service…), éventuellement delai si on veut un second critère.
• Sorties : l’offre gagnante (A/B/égalité) + explication du calcul (totaux).
• Contraintes : montants ≥ 0 ; même unité (centimes) ; définir une règle en cas d’égalité (ex. choisir la plus rapide, sinon « égalité »).

Expliciter les critères (avant le pseudo-code)

• Critère principal : coût total = prix + frais.
• Critère secondaire (optionnel) : délai le plus court si coûts égaux.
• Sortie attendue : une décision + les valeurs comparées (pour éviter une décision « magique »).

Tableau d’exemples

Pseudo-code commenté

// Objectif : comparer deux offres selon un critère principal (total) puis secondaire (délai).ENTRÉE prixA, fraisA, delaiA, prixB, fraisB, delaiBSI prixA < 0 OU fraisA < 0 OU prixB < 0 OU fraisB < 0 ALORS    SORTIE "Erreur : montants invalides"    STOPFIN SI totalA <- prixA + fraisAtotalB <- prixB + fraisBSI totalA < totalB ALORS    SORTIE "A", totalA, totalB    STOPSINON SI totalB < totalA ALORS    SORTIE "B", totalA, totalB    STOPFIN SI // Ici : égalité sur le coût totalSI delaiA < delaiB ALORS    SORTIE "A", "égalité coût, A plus rapide"SINON SI delaiB < delaiA ALORS    SORTIE "B", "égalité coût, B plus rapide"SINON    SORTIE "ÉGALITÉ", "même coût et même délai"FIN SI

Erreurs fréquentes

• Oubli d’unités : comparer un prix en euros avec des frais en centimes.
• Confusion entrée/sortie : afficher uniquement « A » sans donner les totaux, rendant la décision difficile à vérifier.
• Hypothèses implicites : supposer que les frais sont toujours inclus, ou qu’il n’y a jamais d’égalité.
• Critères non explicités : changer de règle en cours de route (parfois on choisit le moins cher, parfois le plus rapide) sans l’écrire.