Bug (informatique) - Définition

Approche formelle : les méthodes formelles

Un bug peut être :

• soit un non-respect de la spécification du système (c’est-à-dire de la définition de ce que le système est censé faire),
• soit un comportement inattendu non couvert par la spécification (par exemple, cas non prévu de deux actions contradictoires à traiter simultanément, cas du bug de l'an 2000).

Une spécification peut être informelle et vague (comme : « le logiciel est un traitement de textes qui ne provoque pas d’erreur à l’exécution »), ou formelle et précise (« tri(t) est une permutation de t telle que tri(t) est ordonnée pour la relation < »), y compris au point d’obtenir des formules mathématiques. En supposant la spécification la plus complète possible, un programme bugué est un programme dont la mise en œuvre ne vérifie pas cette spécification.

On peut se demander s’il existe des méthodes universelles, sans faille et automatiques qu’il suffirait de suivre pour se rendre compte si un programme est bugué ou non. La réponse est non. En effet, si une telle méthode existait, il serait possible de l’automatiser par un ordinateur, c’est-à-dire par un logiciel d’analyse. Cet analyseur devrait opérer sur des programmes à analyser quelconques et devrait, par exemple, répondre à la question suivante : « l’état final du programme peut-il être un état d’erreur à l’exécution, ou est-il forcément un état correct (ou une non-terminaison) ». Or, le théorème de Rice dit qu’on ne peut répondre à cette question sur un système à état infini. Plus généralement, toute question de spécification portant sur l’état final du programme est indécidable, c’est-à-dire qu’un logiciel ou une méthode automatique ne peut y répondre, sauf les questions dont la réponse est toujours vraie ou toujours fausse.

On pourrait objecter que les ordinateurs sont des systèmes à état fini : chaque ordinateur a une quantité finie de mémoire. Cependant, à l’exception de systèmes de très petite taille, il convient, à des fins d’analyse, de considérer les ordinateurs comme des systèmes à mémoire non bornée. En effet, les techniques d’analyse utilisant la finitude de l’état vont toutes, de façon plus ou moins détournée ou optimisée, chercher à énumérer les états du système. Un système à n bits de mémoire a 2ⁿ états ; dans un ordinateur personnel actuel, n est de l’ordre de 2³⁸. On voit donc que toute tentative d’énumération des états du système est vouée à l’échec.

L’impossibilité de la recherche automatique universelle des bugs est donc un problème d’ordre fondamental, et non une limitation de la technologie actuelle.

Humour et citations célèbres liées aux bugs

• « Ce n’est pas un bug, c’est une fonctionnalité non documentée ! » (de l’anglais « It’s not a bug, it’s an undocumented feature ») – Réponse fréquente (et teinte d'humour) des développeurs de logiciels à leurs utilisateurs.
• « Tout programme non trivial possède au moins un bug. » (de l’anglais « Every non-trivial program has at least one bug ») – Tiré de la loi de Murphy appliquée à l’informatique (cf. liens externes ci-dessous)
• « L’erreur est humaine, mais un vrai désastre nécessite un ordinateur. » – Une petite erreur dans un logiciel peut entraîner de nombreuses conséquences par effet « boule de neige ».
• « Quand un logiciel n’a plus aucun bug, il est habituellement désuet. » – L'objectif « zéro bug » nécessite un temps de développement généralement très important, à comparer à la durée de vie espérée du logiciel.