« Erreur fatale » redirige ici. Pour l’article homophone, voirErreurs fatales.
« Erreur fatale » redirige ici. Pour le film allemand, voirErreur fatale (film).
Eninformatique, unbug (prononcé en français :/bœg/[note 1]) oubogue[note 2] est un défaut de conception d'unprogramme informatique à l'origine d'undysfonctionnement.
La gravité du dysfonctionnement peut aller de bénigne, causant par exemple des défauts d'affichage mineurs — on parlera alors parfois dans ce cas de « glitch(es) » — à majeure, tels unplantage du système pouvant entraîner de graves accidents, par exemplela destruction en vol de la première fusée Ariane 5, en 1996.
Un bug peut résider dans uneapplication, dans les logiciels tiers utilisés par cette application, voire dans lefirmware d'un composant matériel comme ce fut le cas dubug de la division du Pentium[note 3]. Un correctif (patch) est un morceau de logiciel destiné à corriger un ou plusieurs bugs.
Les bugs sont une des causes de dysfonctionnement des appareils informatiques ; parmi les autres causes de dysfonctionnement, on trouve :
Le mot anglaisbug appartient au jargon des ingénieurs dematériel et représentant les problèmes qui y survenaient. L'utilisation du terme pour décrire les défauts de systèmes mécaniques date d'au moins avant lesannées 1870.Thomas Edison, entre autres, utilisait le mot dans ses notes[1].
Le terme « bogue » est référencé dans le dictionnaire Larousse en ligne avec pour définition : « Défaut de conception ou de réalisation d'un programme informatique, qui se manifeste par des anomalies de fonctionnement de l'ordinateur[2]. »
LeTrésor de la langue française informatisé ne retient le mot « bogue » que dans son acception de « Enveloppe piquante de la châtaigne, de la faîne, de la noisette et de certaines graines de légumineuses »[3].
LaCommission d’enrichissement de la langue française, l'Office québécois de la langue française et laDirection de la langue française (Belgique) recommandent le terme « bogue » ainsi que les dérivés déboguer, débogage etdébogueur[4],[5],[6]
Le terme est parfois faussement attribué àGrace Hopper. Elle constata dans son journal d'entretien, conservé à laSmithsonian Institution, en date du,15 h 45, que deux contacts d'unrelais causaient le mauvais fonctionnement duHarvard Mark II, l'un des premiersordinateurs électromécaniques[7].
Hopper ne trouva pas le bug, comme elle le reconnaissait volontiers. Les opérateurs qui l'ont trouvé plus tard, y compris William « Bill » Burke, du laboratoire d'armes naval étaient familiers avec le terme d'ingénierie et amusés ont gardé l'insecte avec l'annotation « premier cas réel de bug trouvé »[8],[9],[7].
« Bug » était un terme utilisé par les ingénieurs en mécanique et électricité, expliquant les anomalies rencontrées dans l'équipement, longtemps avant que Grace Hopper eût entendu parler de ce mot[7],[note 4].
Dans son livre paru en 1987,Frederick Brooks dit que la présence de bugs dans les logiciels n'est pas un accident mais est due à la nature même des logiciels, autrement dit, il existe des bugs dans les logiciels parce que ce sont des logiciels. Il dit également qu'il n'existepas de balle en argent - un outil miracle - pour parer aux bugs, faisant ici allusion à une légende duMoyen Âge[10] selon laquelle seule uneballe enargent, évocatrice de la couleur de la Lune, peut parer auloup-garou[11].
Les logiciels sont des produits invisibles et immatériels, leur modification ne requiert pas de matière première. L'évolution très rapide du marché informatique engendre une forte demande en changement. Tous ces facteurs font que les changements dans les logiciels sont beaucoup plus fréquents que dans d'autres produits tels que lesautomobiles ou lesbâtiments[11].
Les ordinateurs sont parmi les produits les plus complexes que l'homme ait fabriqué, et ils ont par conséquent un très grand nombre d'états. Les logiciels sont plus complexes que les ordinateurs, et, contrairement à une automobile, aucune pièce ne se ressemble. La conformité à de nombreusesnormes, caractéristique des domaines proches de latélécommunication, accroît la complexité de ces derniers. Les logiciels sont de plus des produits invisibles, qui ne peuvent pas être représentés dans un espace géométrique, les représentations graphiques de logiciels comportent souvent deux, voire trois ou quatre diagrammes qui correspondent chacun à une réalité différente[11].
Les bugs peuvent amener les logiciels à tenter d'effectuer des opérations impossibles à réaliser (exceptions) :division par zéro, recherche d'informations inexistantes. Ces opérations - qui ne sontjamais utilisées lors de fonctionnement correct du logiciel - déclenchent unmécanisme à la fois matériel et logiciel qui met alors hors service le logiciel défaillant, ce qui provoque uncrash informatique ou undéni de service.
Unchien de garde est un dispositif électronique autonome qui sert à déceler les dysfonctionnements. Ce mécanisme est souvent utilisé avec les systèmes critiques et l'informatique industrielle.
L'écran bleu de la mort est, dans le langage populaire, le nom donné au message de mise hors service dessystèmes d'exploitationMicrosoft Windows, qui s'affiche lorsqu'une exception est décelée au cœur du système d'exploitation. LaKernel panic est le message affiché dans des conditions similaires sur les systèmes d'exploitationUNIX.
Unefuite de mémoire est un dysfonctionnement dû à un bug dans les opérations d'allocation de mémoire. Avec ce dysfonctionnement, la quantité de mémoire utilisée par le logiciel défaillant va en augmentant continuellement. Si le logiciel défaillant arrive à utiliser la quasi-totalité de la mémoire disponible, celui-ci gêne alors le déroulement des autres logiciels et les entraîne à des dysfonctionnements.
Uneerreur de segmentation est un dysfonctionnement dû à un bug dans des opérations de manipulations depointeurs ou d'adresses mémoire. Le logiciel défaillant va tenter de lire ou d'écrire des informations dans un emplacement demémoire (segment) qui n'existe pas ou qui ne lui est pas autorisé. Le mécanisme de détection des exceptions provoque alors la mise hors service du logiciel défaillant.
Undépassement d'entier est un dysfonctionnement dû à un bug dans des opérations de calcul mathématique. Le logiciel défaillant va tenter d'effectuer un calcul dont le résultat est supérieur à la valeur maximum autorisée. Le mécanisme de détection des exceptions provoque alors la mise hors service du logiciel défaillant.
Undépassement de tampon est un dysfonctionnement dû à un bug. Un logiciel qui doit écrire des informations dans un emplacement déterminé et limité de mémoire (mémoire tampon) dépasse les limites de cet emplacement et va alors écrire des informations sur un emplacement destiné à un autre usage, cette modification inopinée entraine une exécution erratique du logiciel, qui peut se terminer par une erreur de segmentation ou un dépassement de capacité. C'est unefaille de sécurité courante desserveurs qui est souvent exploitée par lespirates informatiques. voirExploit.
Undépassement de pile est un dysfonctionnement dans lequel la taille de lapile d'exécution d'un logiciel dépasse la capacité de lamémoire tampon qui la contient, ce qui provoque des dysfonctionnements similaires à undépassement de tampon. La pile d'exécution est unestructure de données stockée enmémoire qui contient l'état du déroulement des automatismes du logiciel (voirprocessus (informatique)), cette structure est enregistrée dans une mémoire tampon dont la taille est sur-dimensionnée. Un dépassement de pile résulte d'un déroulement erroné à la suite d'un bug.
Unesituation de compétition (anglaisrace condition) est un dysfonctionnement dû à un bug, qui fait que dans un même logiciel deux automatismes qui travaillent simultanément donnent des résultats différents suivant l'automatisme qui termine avant l'autre.
Uninterblocage (anglaisdeadlock) est un dysfonctionnement durant lequel plusieurs automatismes s'attendent mutuellement, c'est-à-dire qu'ils attendent chacun que l'autre libère les ressources qu'il utilise pour poursuivre. Les ressources restent verrouillées durant les attentes, ce qui peut bloquer d'autres automatismes et par effetdomino bloquer l'ensemble du système. Un mécanisme de prévention provoque l'annulation de l'opération lorsque la durée d'attente dépasse le délai admissible (anglaistimeout).
Plus le code est complexe, plus il est difficile de localiser un bug. Des bugs qui dépendent d'une combinaison de conditions imprévues et improbables sont particulièrement difficiles à localiser. Dans le folklorehacker il existe des catégories de bugs bizarres dont les noms humoristiques sont dérivés de ceux d'éminents scientifiques en physique quantique et en mathématique[12].
L'exécution pas-à-pas d'un logiciel à l'aide d'un débogueur peut provoquer desHeisenbug du simple fait que le logiciel se déroule moins rapidement[13]. Et les situations de compétition peuvent entraîner desMandelbug, où le comportement du programme est différent à chaque fois que celui-ci est exécuté[14].
Les bugs résultent d'erreurs humaines lors des travaux despécification, deconception, deprogrammation et detests de logiciel et de matériel informatique. La complexité grandissante des logiciels, les problèmes de communication, le manque de formation des ingénieurs et la pression des délais et des coûts durant les travaux d'ingénierie sont des facteurs qui tendent à augmenter le nombre de bugs[15].
Lestests de logiciels sont la première mesure pour contrer les bugs. Pour des raisons pratiques (coût des travaux et délais), il n'est pas possible de tester un logiciel dans toutes les conditions qu'il pourrait rencontrer lors de son utilisation et donc pas possible de contrer la totalité des bugs : un logiciel commeMicrosoft Word compte 850 commandes et 1 600 fonctions, ce qui fait un total de plus de 500 millions de conditions à tester[16].
L'utilisation de langages de programmationde haut niveau, qui facilitent le travail de l'ingénieur, et la mise en application de conventions de rédaction sont d'autres techniques préventives destinées à diminuer le nombre de bugs.
Le débogage est l'activité qui consiste à diagnostiquer et corriger des bugs. Lors dudébogage en ligne, l'ingénieur exécute le logiciel pas à pas et effectue après chaque pas une série de vérifications. Lors dudébogage post-mortem, l'ingénieur examine un logiciel à la suite d'un crash informatique.
Lorsque le bug est décelé et corrigé après la distribution du logiciel, le fournisseur met souvent à disposition uncorrectif, c'est-à-dire un kit qui remplace les parties défaillantes du logiciel par celles qui ont été corrigées.
Les ingénieurs utilisent souvent unsystème de suivi des bugs, c'est-à-dire un logiciel debase de données dans lequel sont inscrits les différents bugs ainsi que les travaux réalisés pour chacun :
De nombreux langages de programmation incluent des mécanismes de vérification des dysfonctionnements. Les instructions nécessaires aux vérifications sont ajoutées automatiquement aucode machine ou aubytecode du logiciel lors de lacompilation. Les instructions peuvent provoquer l'activation automatique dudébogueur, le logiciel de diagnostic des bugs.
Larevue de code consiste à soumettre le code source fraîchement développé à une tierce personne qui va le relire et rechercher des défauts.
Les tests logiciel sont la première mesure pour contrer les bugs. Ils consistent à utiliser le logiciel dans le plus de conditions possibles. Le but des tests est de déceler différents problèmes :
Les tests sont répétés plusieurs fois, à mesure de l'avancée de la programmation et des corrections, ceci afin de valider les corrections et déceler d'éventuelsbugs derégression : des bugs survenus à la suite de la correction erronée d'un autre bug. Les tests peuvent être automatisés à l'aide de logiciels qui agissent à la place de l'utilisateur. Parfois un second logiciel est développé pour servir aux tests.
Lestests unitaires consistent à utiliser une fonction unique du logiciel en vue de déceler des dysfonctionnements. Lestests d'intégration consistent à utiliser un ensemble de fonctions en vue de contrôler la cohérence de l'ensemble. Lestests de validation consistent à utiliser l'ensemble du logiciel en vue d'évaluer son adéquation au besoin de l'acheteur.
Les tests unitaires et d'intégration sont typiquement effectués par l'ingénieur, tandis que les tests de validation sont typiquement effectués par l'acheteur ou son représentant.
Une autre mesure préventive pour éviter les bugs est lapreuve formelle (ou démonstration mathématique) du fonctionnement du programme, de manière générique. Contrairement au test qui ne vérifie qu'un seul cas de fonctionnement donné, cette preuve cherche à assurer que le programme fonctionne dans tous les cas, quelles que soient les conditions d'utilisation. Mais toutes les techniques de vérification formelles sont lourdes et complexes. Dans l'absolu, on ne sait pas vérifier le bon fonctionnement d'un programme quelconque dans tous les cas. En revanche, il existe des méthodes de création de logiciels, qui, au cours de la création du logiciel, mettent en place des éléments de suivi du passage vers chaque étape intermédiaire entre les spécifications ou le cahier des charges du logiciel d'une part, et le programme final d'autre part. Grâce à ces éléments de suivi, des vérifications sont ensuite possibles, et des contraintes de respect de la spécification peuvent être imposées et verrouillées.
Dans les domaines où un bug causerait la mort d'êtres humains, (par exemple dans l'aéronautique), des méthodes lourdes et complexes sont utilisées pour prouver l'absence de bug dans le logiciel, lors de sa conception. Ainsi, le logiciel de contrôle du métro automatique ligne 14 à Paris a été à l'origine réalisé avec lanotation Z. Pourtant, c'est laMéthode B qui a été utilisée pour en créer la version finale[18]. Laméthode B est d'ailleurs considérée comme le meilleur outil pour garantir qu'un programme informatique est conforme aux spécifications de son comportement. En effet, l'utilisation de la Méthode B pour créer le programme conduit aussi (automatiquement) à démontrer mathématiquement la conformité du programme ainsi créé, qui devient donc par définition un théorème démontré.
Cependant, la complexité d'utilisation de cette méthode entraine un surcroit de travail tel, qu'un programmeur seul peut avoir besoin de 100 fois plus de temps pour créer un programme avec cette méthode que s'il avait créé le même programme de manière traditionnelle. Cela signifie alors que cela coute 100 fois plus cher de créer le programme avec cette méthode. En conséquence, malgré son efficacité, cette méthode n'est que très rarement utilisée, et il existe de nombreux domaines dans lesquels des bugs peuvent causer la mort d'êtres humains et où l'on se contente pourtant de créer des programmes bourrés de bugs, de manière traditionnelle, puis de faire des tests très rigoureux pour en éliminer la plupart. À partir du moment où la probabilité qu'un bug crée un dysfonctionnement qui tue des gens reste inférieure à la probabilité qu'une erreur humaine crée le même genre de dysfonctionnement, cela est souvent jugé « acceptable ». (Et le surcout entrainé par l'utilisation de la méthode B pour garantir que personne ne meurt est jugé inacceptable).
Pour ledébogage[note 5] (de l'anglais : « debugging »), soit la recherche et la correction de bugs, les ingénieurs se servent d'un logiciel, ledébogueur, ainsi que d'unsystème de suivi des bugs.
Le système de suivi des bugs sert à coordonner les travaux de débogage, il est utilisé pour collecter tous les dysfonctionnements constatés, inscrire les causes et les actions de correction effectuées et ainsi suivre l'avancement des corrections. Les causes peuvent être des bugs, mais aussi des défauts dans les paramètres deconfiguration ou des erreurs de manipulation. Le système de suivi des bugs est utilisé aussi bien par les usagers du logiciel défaillant que par les ingénieurs ou lesadministrateurs systèmes.
Le débogueur permet d'analyser l'état d'exécution d'un logiciel à un instant donné, les opérations en cours, les informations en mémoire, les fichiers ouverts, etc. Avec undébogueur en ligne, il est possible de suspendre l'exécution du logiciel à tout moment, d'analyser l'état, puis de continuer les traitements.
Avec un débogueurpost-mortem, il est possible d'analyser l'état d'exécution d'un logiciel après un crash. L'analyse se fait sur la base d'un fichier qui contient la copie du contenu de la mémoire au moment du crash. Fichier appelécore dump sur lessystèmes d'exploitationUnix.
Uneversion de logiciel est l'état d'un logiciel à une date donnée, y compris toutes les corrections et améliorations qui ont été faites jusqu'à cette date. La version est ditealpha oubeta lorsqu'elle correspond à l'état du logiciel avant la fin de la durée des tests. Une telle version est susceptible de contenir des bugs qui ont entretemps été décelés et corrigés.
Une fois un ou plusieurs défauts corrigés, ceux-ci sont regroupés dans uncorrectif, un kit qui contient uniquement les composants du logiciel qui ont été corrigés. Il sera utilisé par toute personne qui possède une copie du logiciel pour y appliquer les corrections et le faire correspondre à une version donnée.
L'échec duvol inaugural de la fuséeAriane 5 en 1996 a pour origine un défaut dans les appareils d'avionique de la fusée, appareils utilisés avec succès pendant plusieurs années sur la fuséeAriane 4. Lors du décollage, l'appareil informatique qui calculait la position de la fusée en fonction de son accélération ne supporta pas les accélérations d'Ariane 5, 5 fois plus fortes que celles d'Ariane 4. Undépassement d'entier provoqua le crash informatique de l'appareil. Aveuglé, lepilote automatique perdit le contrôle de la fusée, et un dispositif de sécurité provoqua son autodestruction quelques secondes après le décollage. C'est l'un des bugs informatiques les plus coûteux de l'histoire[19].
En 1962, la missionMariner 1 a connu un incident similaire[20].
Dans les années 1980, un bug affectant le logiciel d'une machine deradiothérapie pilotée par unPDP-11, leTherac-25[21], a eu des conséquences tragiques, des patients reçurent des doses massives de radiation et au moins cinq en sont morts.
Lebug de l'an 2000, aussi appelébug du millénaire : un ou plusieurs bugs dans un logiciel qui manipule des dates provoquent des dysfonctionnements lorsque les dates sont postérieures au 31 décembre 1999. Une des causes est que les calculs sur les dates se faisaient uniquement sur lesdeux derniers chiffres de l'année.
Les problèmes potentiels posés par la date du 31 décembre 1999 ont été anticipés la première fois parBob Berner en 1971[22]. Ils ont provoqué une importante mobilisation des entreprises degénie logiciel quelques années avant la date butoir et le coût total des travaux de contrôle et demaintenance préventive est estimé à plus de 600 millions de dollars[23].
En 2002, le système informatique de l'hôpital St Mary's Mercy dans le Michigan a déclaré par erreur la mort de 8 500 patients qui étaient en fait encore vivants, envoyant à leur domicile une facture et une déclaration de décès, ainsi qu'une annonce de leur mort à leur société d'assurance et à la sécurité sociale américaine[24]. Il a fallu plusieurs semaines pour que ces décès soient annulés auprès des différentes administrations.
Un bug peut être, soit :
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 det 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 bogué est un programme dont lamise 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 bogué 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, lethé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 estindécidable, c'est-à-dire qu'un logiciel ou une méthode automatique ne peut y répondre, sauf pour 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 2n états ; dans un ordinateur personnel actuel,n est de l'ordre de 238. 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.
L'industrie du développement logiciel fait de gros efforts pour trouver des méthodes de prévention des erreurs des programmeurs menant à des bugs.
Trouver et corriger les bugs, oudéboguer, est une partie majeure de laprogrammation de logiciels.Maurice Vincent Wilkes, pionnier de l'informatique, décrit ses réalisations desannées 1940 en disant que l'essentiel du reste de sa vie serait occupé à réparer les erreurs dans ses propres programmes. Alors que les programmes informatiques deviennent de plus en plus complexes, les bugs deviennent plus fréquents et difficiles à corriger. Quelquefois, les programmeurs passent plus de temps et d'efforts à trouver et à corriger les bugs qu'à écrire du nouveau code.
Habituellement, la partie la plus difficile du débugage est de trouver la partie du code responsable de l'erreur. Une fois localisée, la corriger est souvent facile. Des programmes appelésdébogueurs existent afin d'aider les programmeurs à trouver les bugs. Toutefois, même avec l'aide d'undébogueur, dénicher un bug est une tâche souvent très difficile.
Ordinairement, la première étape pour trouver un bug est de trouver un moyen de le reproduire facilement. Une fois le bug reproduit, le programmeur peut utiliser ledébogueur ou un autre outil pour observer l'exécution du programme dans son contexte habituel, et éventuellement trouver le problème. En revanche, il n'est pas toujours facile de reproduire un bug. Certains sont causés par des entrées au logiciel qui peuvent être difficiles à reproduire pour le programmeur. D'autres peuvent disparaître quand le programme est lancé dans undébogueur ; ceux-ci sont appelésheisenbugs (faisant, par plaisanterie, référence auprincipe d'incertitude de Heisenberg). Enfin, les bugs des programmes parallèles (composés de plusieurs modules s'exécutant de façon concurrente, par exemple sur plusieurs processeurs) sont souvent difficiles à reproduire s'ils dépendent de l'ordonnancement précis des calculs sur la machine.
Le terme de bug dans lesjeux vidéo a pour signification première une erreur dans le déroulement supposé d'une action. La résultante finale du bug n'occasionnera pas la même gêne suivant son intensité. Une main d'un joueur traversant un mur dans unFPS n'aura pas la mêmenuisance qu'une impossibilité d'accomplir la quête principale d'unjeu de rôle.
L'existence des bugs n'apportent pas que des points négatifs :
Le terme de bug englobe d'autres notions moins usitées à cause de la popularité du nom debug. Il serait judicieux de nommer certaines erreurs par « oubli » plutôt que par bug.
Sur les autres projets Wikimedia :
Voir aussi la catégorie
