Avant d'écrire la moindre instruction : définir l'objectif, les données d'entrée et les résultats attendus, décomposer le problème en étapes, puis examiner les cas particuliers. Cinq planches pour voir, sur des exemples concrets, ce que coûte chaque étape oubliée.
La démarche : comprendre avant de résoudre
Devant un problème, la tentation est de se lancer tout de suite dans les calculs ou le programme. L'expérience montre que la plupart des erreurs ne viennent pas d'un calcul faux, mais d'une question mal comprise, d'une donnée oubliée ou d'un cas que personne n'avait imaginé. On procède donc par étapes, et l'on revient en arrière dès qu'un test échoue : la démarche est un cycle, pas une ligne droite.
Le cycle de l'analyse. Le jeton parcourt les six étapes ; un test qui échoue renvoie vers l'analyse.
Un premier exemple : la moyenne d'une liste de notes
Le problème paraît trivial : « calculer la moyenne des notes ». On remplit pourtant la fiche d'analyse avant d'écrire la solution.
Objectif
Calculer la moyenne arithmétique des notes d'un élève.
Entrées
Une liste de notes, séparées par des points-virgules. Précondition : chaque note est un nombre compris entre 0 et 20.
Sortie
Un nombre entre 0 et 20 — ou un message clair si la moyenne n'existe pas.
Étapes
① lire et vérifier chaque note ; ② faire la somme ; ③ compter les notes ; ④ diviser la somme par le nombre de notes.
Cas particuliers
Liste vide (division par zéro !), valeur qui n'est pas un nombre, note hors du barème, une seule note.
notes
Programme naïf : somme ÷ nombre
—
aucune vérification
Programme issu de la fiche
—
—
Contrôle
—
moyenne × nombre de notes = somme
À retenir. Sur une liste vide, le programme naïf divise 0 par 0 et affiche « NaN » (Not a Number, « pas un nombre ») ; sur une note de 25, il rend sans broncher une moyenne impossible. Les cinq lignes de la fiche ont coûté une minute ; elles ont désigné d'avance chaque piège.
1
Définir l'objectif : une question précise
Question : « combien de jours entre le 1er et le 3 mars ? » Deux jours si l'on compte les sauts d'une date à l'autre, trois si l'on compte les deux dates, un seul si l'on ne garde que les jours strictement compris entre elles. La question semblait claire ; elle admet trois réponses justes. Définir l'objectif, c'est choisir l'une d'elles et l'écrire.
La fiche d'analyse ci-dessous se met à jour selon vos choix. Une précondition est une condition que doivent remplir les données pour que la solution s'applique ; il faut décider d'avance ce qu'on fait quand elle n'est pas remplie.
date D1
date D2
convention
si D2 précède D1
Ce que l'on compte selon la convention : les sauts d'un jour au suivant (arcs), ou les cases elles-mêmes. Bleu : déjà compté ; vert : les deux dates D1 et D2. Au-delà de deux mois, une barre de progression remplace les cases.
Réponse selon la convention
—
—
Les trois réponses possibles
—
écart · dates incluses · strictement entre
Trois méthodes pour l'écart
—
compter un par un · formule du numéro de jour · horloge du navigateur
Essais au hasard
calcul…
—
Ce que l'on voit. Les trois méthodes de calcul s'accordent toujours ; ce qui change la réponse, c'est la définition. Une erreur de convention ne se voit dans aucun calcul : elle se voit seulement en relisant l'objectif. Un hôtel compte les nuits (l'écart), une location de voiture les jours entamés (dates incluses).
2
Entrées et résultats attendus : écrire les tests d'abord
Question : comment savoir qu'une solution est juste ? On écrit, avant de la programmer, un tableau d'exemples dont on connaît la réponse : les résultats attendus. Exemple : une année est-elle bissextile (366 jours) ? La règle du calendrier grégorien (1582) dit : une année est bissextile si elle est divisible par 4, sauf les années divisibles par 100, à l'exception de celles divisibles par 400.
Quatre programmes candidats sont proposés. Choisissez-en un, puis le jeu de tests : les tests « ordinaires » se contentent d'années banales, les tests « avec cas particuliers » ajoutent les années séculaires.
programme
tests
Toutes les années de 1583 à 3000, une case par année, une ligne par siècle. Bleu : bissextile et juste ; clair : non bissextile et juste ; rouge : erreur du programme. Point noir : année présente dans le jeu de tests.
Tests réussis
—
—
Erreurs de 1583 à 3000
—
—
Durée moyenne de l'année
—
—
Résultats attendus contrôlés
—
chaque réponse attendue confrontée au nombre de jours que compte l'année selon l'horloge du navigateur
Ce que l'on voit. Avec les tests ordinaires, les quatre versions paraissent justes : 2020 et 2024 sont bissextiles pour toutes. Seules les années séculaires (1900, 2000, 2100…) séparent les programmes. La version C est la plus traîtresse : elle connaît toutes les règles, mais les applique dans le mauvais ordre et se trompe sur 1600, 2000, 2400 et 2800 — comme la version B, mais pour une autre raison. Un bon jeu de tests vise les frontières de la règle, pas les cas où tout le monde a raison.
3
Décomposer : quel jour de la semaine ?
Question : quel jour de la semaine tombait (ou tombera) une date donnée ? Le problème paraît d'un seul bloc ; on le découpe en sous-problèmes, chacun avec ses entrées et sa sortie, jusqu'à ce que chaque morceau soit évident. C'est l'analyse descendante, ou méthode des raffinements successifs.
Point de départ connu : le 1er janvier 1600 était un samedi. On compte les jours écoulés depuis, et le reste de la division par 7 donne le décalage. Remarquez que la brique « bissextile ? » de la planche 2 est réutilisée telle quelle : un sous-problème résolu devient une pièce qu'on assemble.
jour
mois
année
L'arbre de décomposition, lu de haut en bas et de gauche à droite. Pendant l'exécution, chaque brique affiche sa sortie ; la brique en cours est encadrée de rouge. On exécute d'abord les briques les plus profondes, puis on remonte.
Résultat
—
—
Contrôles indépendants
—
formule de Zeller (1882) · horloge du navigateur
Appels à la brique « bissextile ? »
—
—
Essais au hasard
calcul…
—
Ce que l'on voit. Aucune étape n'est difficile : additionner, diviser, lire un tableau. La difficulté était l'enchaînement, et la décomposition l'a fait disparaître. Elle a un autre avantage : chaque brique se teste séparément. Si le jour est faux, on sait où chercher. Et la vérification de la date est placée en premier : un 31 avril ne doit même pas entrer dans le calcul.
4
Examiner les cas particuliers : l'équation du second degré
Question : résoudre ax² + bx + c = 0. La formule apprise au lycée, x = (−b ± √Δ)/(2a) avec Δ = b² − 4ac, ne marche que dans le cas général. Que se passe-t-il si a = 0 ? si Δ est négatif ? si tous les coefficients sont nuls ? Chaque question ajoute une branche à l'organigramme.
Un dernier cas est plus sournois : quand b est très grand devant a et c, −b + √Δ soustrait deux nombres presque égaux, et l'ordinateur, qui ne garde qu'environ 16 chiffres significatifs, perd presque tout. On l'appelle l'annulation catastrophique. Le remède consiste à calculer d'abord la racine sans soustraction, puis l'autre par le produit des racines x₁x₂ = c/a.
a
b
c
La parabole y = ax² + bx + c et ses racines (points bleus).
L'organigramme complet. Le chemin suivi par les coefficients choisis est tracé en rouge.
Programme complet
—
—
Formule seule, sans cas particuliers
—
—
Référence à 40 décimales
—
calcul exact en entiers géants, sans virgule flottante
Erreur relative de la petite racine
—
—
Le banc d'essai des cas particuliers
Ce que l'on voit. La formule seule échoue sur cinq des huit cas du banc d'essai, et jamais de façon claire : elle rend « NaN » ou « ∞ » au lieu d'un message, et une petite racine fausse sans prévenir quand b = 10⁸. Les cas particuliers se trouvent en cherchant systématiquement où une opération peut échouer : une division (par 2a), une racine (de Δ), une soustraction de nombres voisins.
5
Signature : la démarche complète sur un point et un polygone
Question : un point est-il à l'intérieur d'un polygone ? C'est ce que fait un logiciel de cartographie quand on clique sur une commune, ou un jeu vidéo quand il teste une collision. On applique les quatre étapes de la démarche.
Objectif
Dire si le point P est à l'intérieur du polygone, à l'extérieur, ou sur son bord — trois réponses, pas deux.
Entrées
La liste des sommets dans l'ordre, et les coordonnées de P. Précondition : le polygone est simple (ses côtés ne se croisent pas).
Étapes
① P est-il sur un côté ? ② Tracer une demi-droite horizontale de P vers la droite (un « rayon ») ; ③ compter les côtés qu'elle traverse ; ④ un nombre impair signifie l'intérieur.
Cas particuliers
Le rayon passe par un sommet ; il longe un côté horizontal ; P est sur un côté ou un sommet.
Deux programmes appliquent la même idée. Le naïf compte un côté dès que le rayon le touche, extrémités comprises. Le robuste commence par l'étape ① et adopte une règle de demi-ouverture : un côté ne compte que si l'une de ses extrémités est strictement au-dessus du rayon et l'autre non — un sommet posé sur le rayon est traité comme s'il était juste en dessous. Une troisième méthode, indépendante, sert d'arbitre : la somme des angles sous lesquels P voit chaque côté vaut 360° à l'intérieur et 0° à l'extérieur.
polygone
Faites glisser le point P (rouge). Le rayon part vers la droite. Cercles verts : côtés comptés par le programme robuste ; croix orange : côtés comptés par le programme naïf. Sur la carte des erreurs, chaque point de la demi-grille est rouge quand le programme naïf se trompe, bleu quand il est sur le bord.
Programme naïf
—
—
Programme robuste
—
—
Arbitre : somme des angles
—
—
Sur la demi-grille
—
—
Sur 20 000 points au hasard
—
—
Ce que l'on voit. Sur des points tirés au hasard, le programme naïf ne commet aucune erreur : la probabilité de tomber pile sur la hauteur d'un sommet est nulle. Sur la grille, là où vivent les vraies données (coordonnées entières, points saisis à la main), il se trompe des dizaines de fois. Les cas particuliers ne se découvrent pas par hasard : il faut les chercher, en se demandant où la règle hésite.
Repères historiques
1637René Descartes, Discours de la méthode : « diviser chacune des difficultés en autant de parcelles qu'il se pourrait », et « faire partout des dénombrements si entiers » qu'on soit assuré de ne rien omettre.
1882Christian Zeller publie sa formule du jour de la semaine, utilisée ici comme contrôle.
1945George Pólya, How to Solve It : comprendre le problème, concevoir un plan, l'exécuter, revenir sur la solution.
1969Tony Hoare formalise les préconditions et postconditions d'un programme.
1970Edsger Dijkstra diffuse ses notes sur la programmation structurée.
1971Niklaus Wirth décrit la construction d'un programme par raffinements successifs.
1979Glenford Myers, The Art of Software Testing, insiste sur les valeurs aux frontières.
2002Kent Beck popularise le développement piloté par les tests : écrire le test avant le programme.
Définir
Écrire l'objectif, les entrées avec leurs préconditions, et la sortie, avant tout calcul. Une ambiguïté levée au départ ne coûte rien ; découverte à la fin, elle coûte tout.
Décomposer
Découper jusqu'à ce que chaque morceau soit évident, chacun avec ses entrées et sa sortie. Les briques se testent séparément et se réutilisent.
Chercher les cas particuliers
Vide, nul, égal, inversé, extrême, aligné : là où une division, une racine ou une comparaison hésite. Les tests au hasard ne les trouvent presque jamais.
Pour aller plus loin
La page L'algorithmique et ses applications montre ensuite comment mesurer le coût d'une solution (recherche, tris, récursivité, compression, PageRank, RSA).
Une fiche d'analyse type tient en cinq lignes : objectif, entrées et préconditions, sortie, étapes, cas particuliers. Elle s'applique aussi bien à un programme qu'à un problème de mathématiques.
Tous les chiffres de cette page sont calculés dans le navigateur et confrontés à une méthode indépendante.