NSI · Terminale · Génie logiciel
Mise au point logicielle
Trouver la cause, pas le symptôme.
En bref
Corriger un programme est une enquête : le message d’erreur signale l’endroit où le problème est devenu visible, presque jamais celui où il a été introduit.
Les trois familles d’erreurs
| Famille | Quand elle se manifeste | Sa dangerosité |
|---|---|---|
| De syntaxe | Avant toute exécution : le code ne peut pas être lu | La plus facile |
| D’exécution | Le programme s’arrête en route : division par zéro, indice hors bornes, fichier absent | Bruyante, donc repérable |
| De logique | Jamais : le programme s’exécute et donne un résultat faux | La plus dangereuse |
La méthode en cinq temps
- Reproduire l’erreur de façon fiable, avec le plus petit cas d’entrée possible ;
- Localiser : encadrer la zone où l’état devient incorrect ;
- Comprendre la cause, et non seulement le symptôme ;
- Corriger ;
- Ajouter un test qui échouait avant la correction.
L’étape 5 est celle qu’on saute — et c’est elle qui distingue une correction d’un rafistolage.
Les outils
| Outil | Ce qu’il donne |
|---|---|
| L’affichage de valeurs intermédiaires | Rudimentaire mais efficace |
| Le débogueur | Points d’arrêt, pas à pas, inspection des variables |
| Les assertions | Elles font échouer au moment exact où une hypothèse est violée, pas dix lignes plus loin |
| La journalisation | Une trace en production, là où le débogueur n’existe pas |
Les exceptions
Une exception signale une situation anormale. On la traite au niveau où l’on sait quoi faire : essayer d’ouvrir le fichier, et s’il est absent, avertir l’utilisateur et proposer un autre chemin.
| Erreur opposée | Ce qu’elle produit |
|---|---|
| Tout attraper sans rien en faire | Les bugs sont masqués au lieu d’être traités |
| Ne rien attraper | Le programme tombe sur une cause pourtant prévisible |
Une exception ne doit pas servir de contrôle de flux ordinaire : elle signale l’exceptionnel.
Les bugs les plus fréquents
Les erreurs de borne (le décalage d’un rang), la confusion entre affectation et comparaison, la modification d’une liste pendant son parcours, les effets de bord sur un argument mutable, l’oubli du cas collection vide.
La complexité comme bug
Un programme correct mais trop lent est inutilisable. Estimer la complexité avant de coder évite de découvrir sur des données réelles qu’un algorithme quadratique ne passera jamais à l’échelle.
Un bug n’est jamais « bizarre » : il est la conséquence exacte de ce qui est écrit. Cesser de trouver l’ordinateur capricieux, c’est commencer à déboguer vraiment.
Teste-toi
6 questions pour vérifier
Touche une réponse : la correction s’affiche tout de suite.
1.Quelle famille d’erreurs est la plus dangereuse ?
2.Quelle étape de la correction d’un bug est le plus souvent oubliée ?
3.À quoi sert une assertion pendant la mise au point ?
4.Attraper toutes les exceptions sans rien en faire est une bonne pratique.
5.Que permet la journalisation, qu’un débogueur ne permet pas ?
6.Un message d’erreur indique l’endroit où le bug a été introduit.
0 / 6 questions
Dans l’app, ce chapitre a son quiz complet, chronométré, et tes erreurs reviennent au bon moment pour ne plus les refaire.
La fiche de révision, sur une page
Tout « Mise au point » sur une seule page A4 illustrée : l’essentiel, les pièges et un mini-test. Elle se débloque dans l’app avec des gemmes — et ton compte gratuit en offre assez pour tes trois premières fiches.
