Bug (informatique)

Pour les articles homonymes, voir Bogue et Bug.

Écran indiquant un code erreur sur les premières versions de Macintosh.

En informatique, un bug (de l’anglais bug, « insecte ») ou bogue (au Nouveau-Brunswick et au Québec^[1] et recommandé en France par la DGLFLF^[2]) est un défaut de conception d'un programme informatique à l'origine d'un dysfonctionnement. Ce nom vient du tout premier incident informatique qui a été causé par un insecte^[3].

La gravité du dysfonctionnement peut aller de bénigne (défauts d’affichage mineurs) à majeure (crash système pouvant entrainer de graves accidents : par exemple, l'explosion du Vol 501 d'Ariane 5).

Un bug peut résider dans un logiciel applicatif, dans les logiciels tiers utilisés par ce logiciel applicatif, voire dans le firmware d'un composant matériel comme ce fut le cas du bug de la division du Pentium^[4]. Un patch (terme francisé en « rustine ») est un morceau de logiciel destiné à corriger un ou plusieurs bugs.

Introduction

Les bugs sont une des causes de dysfonctionnement des appareils informatiques, parmi les autres causes de dysfonctionnement on trouve :

Les erreurs de manipulation, les virus informatiques — des logiciels malveillants qui falsifient les logiciels présents dans l'appareil. Mais aussi le dépassement des capacités du matériel - mémoire pleine, réseau saturé, processeur occupé - ainsi que l'absence de compatibilité, les pannes du matériel informatique, les valeurs incorrectes des paramètres de configuration et les influences extérieures (température et champs magnétiques).

Un bug peut provoquer un plantage c'est-à-dire un arrêt inattendu d'un logiciel voire d'importantes pertes d'informations ou dans des cas extrêmes une véritable catastrophe (voir explosion du vol 501 de la fusée Ariane 5). Une faille de sécurité est un défaut mineur qui ne provoque pas de dysfonctionnement en utilisation courante, mais permet à un utilisateur malicieux ou un logiciel malveillant d'effectuer des opérations non autorisées à partir d'un exploit.

Un système critique est un dispositif informatique dont le dysfonctionnement peut mettre en danger la santé et la vie des gens et des écosystèmes, provoquer des importants dégâts matériels ou avoir des répercussions sur la stabilité économique et politique.

Terminologie

Photo du « premier cas véritable de découverte de bug », dans le journal d’entretien du Harvard Mark II conservé à la Smithsonian Institution.

Le mot anglais bug (insecte) vient du jargon des ingénieurs de maté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 les années 1870. Thomas Edison, entre autres, utilisait le mot dans ses notes^[5]. Si l’origine précise du mot est donc incertaine, le rapprochement avec les dysfonctionnements dus à la présence d’un insecte dans le système semble évident.

Le terme bug vient du fait que dans les années 30, les premiers ordinateurs fonctionnaient à l'aide d’amplificateurs à lampe (ancêtres du transistor). Ces ordinateurs prenaient la place d'une pièce entière. En été, la chaleur dégagée par les tubes était telle qu'il fallait ouvrir les fenêtres donc l'intrusion des insectes était inévitable. Ces ordinateurs étaient alors vulnérables à ces insectes volants qui pouvaient se coller à l'un des tubes. Cela provoquait un choc thermique mettant le tube hors service et produisant un mauvais fonctionnement de la machine, d'où le terme bug employé par les anglo-saxons.

Le terme est parfois faussement attribué à Grace Hopper : une anecdote raconte qu’elle aurait découvert qu’un insecte (bug), coincé entre deux contacts d’un relais, causait le mauvais fonctionnement du Harvard Mark II, l’un des premiers ordinateurs électromécaniques. Son journal d’entretien, conservé à la Smithsonian Institution, contient encore en date du 9 septembre 1947, 15 h 45, le corps de la mite retirée du relais défectueux, avec l’annotation « premier cas avéré de bug ayant été trouvé ». Cette anecdote a popularisé l’expression bug pour représenter les erreurs dans un programme^[6]^, ^[7].

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.».

Le CNRTL 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 ».

Le site FranceTerme recommande le terme bogue ainsi que les dérivés déboguer, débogage et débogueur^[8].

Causes

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'existe pas de balle en argent - un outil miracle - pour parer aux bugs, faisant ici allusion à une légende du Moyen Âge selon laquelle seule une balle en argent peut parer au loup-garou^[9].

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 les automobiles ou les bâtiments^[9].

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 nombreuses normes, caractéristique des domaines proches de la té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^[9].

Conséquences

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 sont jamais utilisées lors de fonctionnement correct du logiciel - déclenchent un mécanisme à la fois matériel et logiciel qui met alors hors service le logiciel défaillant, ce qui provoque un crash informatique ou un déni de service.

Un chien 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 des systèmes d'exploitation Microsoft Windows, qui s'affiche lorsqu'une exception est décelée au cœur du système d'exploitation. La Kernel panic est le message affiché dans des conditions similaires sur les systèmes d'exploitation UNIX.

Dysfonctionnements courants

Une fuite 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.

Une erreur de segmentation est un dysfonctionnement dû à un bug dans des opérations de manipulations de pointeurs ou d'adresses mémoire. Le logiciel défaillant va tenter de lire ou d'écrire des informations dans un emplacement de mé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.

Un dé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.

Un dé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 une faille de sécurité courante des serveurs qui est souvent exploitée par les pirates informatiques. voir Exploit.

Un dépassement de pile est un dysfonctionnement dans lequel la taille de la pile d'exécution d'un logiciel dépasse la capacité de la mémoire tampon qui la contient, ce qui provoque des dysfonctionnements similaires à un dépassement de tampon. La pile d'exécution est une structure de données stockée en mémoire qui contient l'état du déroulement des automatismes du logiciel (voir processus (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é suite à un bug.

Une situation de compétition (anglais race 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.

Un interblocage (anglais deadlock) est un dysfonctionnement durant lequel lorsque 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 effet domino 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 (anglais timeout).

Dans le folklore hacker

Article détaillé : Bug logiciel inhabituel.

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 folklore hacker 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^[10].

Heisenbug : (du principe d'incertitude de Heisenberg) un bug qui disparaît ou se modifie quand on essaye de l'isoler.
Mandelbug : (des ensembles de Mandelbrot) un bug dont les causes sont si obscures et complexes que le résultat est un comportement chaotique et non déterministe.
Schrödinbug : ( du chat de Schrödinger) un bug qui ne se manifeste pas jusqu'à ce que quelqu'un lise le code source, utilise le programme d'une façon peu ou pas usuelle et constate qu'il n'aurait jamais dû fonctionner.
Bohr bug : Un bug répétable, qui se reproduit lorsqu'un ensemble - même inconnu - de conditions sont remplies^[11].

L'exécution pas-à-pas d'un logiciel à l'aide d'un débogueur peut provoquer des Heisenbug du simple fait que le logiciel se déroule moins rapidement^[11]. Et les situations de compétition peuvent entraîner des Mandelbug, où le comportent du programme est différent à chaque fois que celui-ci est exécuté^[12].

Cycle de vie

Les bugs résultent d'erreurs humaines lors des travaux de spécification, de conception, de programmation et de tests 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^[13].

Les tests 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 comme Microsoft Word compte 850 commandes et 1 600 fonctions, ce qui fait un total de plus de 500 millions de conditions à tester^[14].

L'utilisation de langages de programmation de haut niveau, qui facilitent le travail de l'ingénieur. 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 du dé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 du dé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 un patch, c'est-à-dire un kit qui remplace les parties défaillantes du logiciel par celles qui ont été corrigées.

Logiciel de suivi des problèmes

Les ingénieurs utilisent souvent un logiciel de suivi de problèmes : un logiciel de base de données dans lequel sont inscrits les différents bugs ainsi que les travaux réalisés pour chacun :

Une personne (développeur, testeur, utilisateur...) qui voit quelque chose qui lui semble anormal remplit un formulaire, qui crée une entrée dans la base de donnée et lui affecte un numéro.
Ensuite, un expert effectue une analyse, il regarde s'il s'agit réellement d'un bug ou d'une méprise (manuel pas clair par exemple, ou utilisateur mal formé).
Si une correction est possible (peut être aussi bien une correction dans le code qu'une précision à ajouter dans le manuel, une spécification à corriger, une traduction à améliorer...), la décision est prise de faire une correction ou pas, et avec quelle priorité. Le travail à faire est généralement affecté à quelqu'un en particulier.
Puis, la personne désignée traite le problème, et indique que le problème est réglé.
Généralement, une confirmation par une tierce personne (testeur, autre développeur, utilisateur...) est requise.
Si tout va bien, le problème est clos. Sinon, le problème est rouvert et le cycle recommence.

Mesures préventives

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 au code machine ou au bytecode du logiciel lors de la compilation. Les instructions peuvent provoquer l'activation automatique du débogueur, le logiciel de diagnostic des bugs.

La revue 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 :

le logiciel ne fait pas ce qu'il doit faire ;
le logiciel fait quelque chose qu'il ne doit pas faire ;
le logiciel fait quelque chose qui ne lui est pas demandé ;
le logiciel ne fait pas bien ce qu'il doit faire (ex. : trop lentement^[15]).

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'éventuels bugs de régression : des bugs survenus suite à 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.

Les test unitaires consistent à utiliser une fonction unique du logiciel en vue de déceler des dysfonctionnements. Les test d'intégration consistent à utiliser un ensemble de fonctions en vue de contrôler la cohérence de l'ensemble. Les tests 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 la preuve 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 lourde 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 suivis 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 a ces éléments de suivis, des vérifications sont ensuite possible, et des contraintes de respect de la spécification peuvent être imposées et verrouillées.

Dans les domaines 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 la notation Z. Pourtant, c'est la Méthode B qui a été utilisée pour en créer la version finale^[16]. La mé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'être humain et ou l'on se contente pourtant de créer des programme bourrés de bugs, de manière traditionnels, puis de faire des test 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 a 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).

Débogage

Pour le débogage^[17] (de l'anglais : « debugging »), soit la recherche et la correction de bugs, les ingénieurs se servent d'un logiciel, le débogueur, ainsi qu'un logiciel de suivi de problèmes.

Le logiciel de suivi de problèmes 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 de configuration ou des erreurs de manipulation. Le logiciel de suivi de problèmes est utilisé aussi bien par les usagers du logiciel défaillant que par les ingénieurs ou les administrateurs 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 un dé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ébogueur post-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 les systèmes d'exploitation Unix.

Après la correction

Une version 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 dite alpha ou beta 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 entre temps été décelés et corrigés.

Une fois un ou plusieurs défauts corrigés, ceux-ci sont regroupés dans un patch, 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.

Quelques évènements

Entre 1985 et 1987, plusieurs patients sont décédés ou ont été gravement atteints dans leur santé suite à un bug de dosage d'un appareil médical de radiothérapie. L'appareil, le Therac-25, permet d'envoyer des faisceaux d'électrons, de rayons X ou de lumière (pour éclairer le patient). La puissance d'émission du faisceau d'électrons est 100 fois plus élevée que celle des rayons X. Un logiciel ajuste la puissance de l'émetteur, et un dispositif mécanique / optique permet de produire soit des rayons X, soit des électrons, soit de la lumière. Suite à un crash informatique durant le traitement, l'appareil envoyait au patient une dose de rayons X 100 fois supérieure à celle prévue. L'incident se reproduisit plusieurs fois dans divers hôpitaux des États-Unis et passa inaperçu jusqu'au jour où des patients, gravement atteints dans leur santé déposent plainte contre leur hôpital. C'est le bug informatique le plus grave de l'histoire^[18].

L'échec du vol inaugural de la fusée Ariane 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ée Ariane 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. Un dépassement d'entier provoque le crash informatique de l'appareil. Aveuglé, le pilote automatique perdit le contrôle de la fusée, et un dispositif de sécurité provoqua son auto-destruction quelques secondes après le décollage. C'est le bug informatique le plus coûteux de l'histoire^{[réf. nécessaire]}.

En 1962, la mission Mariner 1 a connu un incident similaire^[19].

Le bug 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 font uniquement sur les deux 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 par Bob Berner en 1971^[20]. Ils ont provoqué une importante mobilisation des entreprises de génie logiciel quelques années avant la date butoir et le coût total des travaux de contrôle et de maintenance préventive sont estimés à plus de 600 millions de dollars^[21].

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.

Comment s’en défaire ?

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. Cela inclut :

Les règles de programmation. On s’impose l’uniformité du style d’écriture (réduit la confusion possible pour les autres développeurs) et l’écriture de documentations détaillées. Typiquement, l’écriture de programmes devra suivre un processus formalisé en étapes successives et documentées ;
Les techniques de programmation. Un bug peut parfois créer des incohérences dans les données internes d’un programme en fonctionnement. Les programmes peuvent être écrits pour vérifier la cohérence des données internes durant leur exécution. Si un problème est trouvé, le logiciel peut s’arrêter immédiatement pour que le bug puisse être trouvé et réparé, ou simplement avertir l’utilisateur, essayer de corriger l’incohérence et continuer à fonctionner. De plus, on peut interdire ou du moins sévèrement réglementer l’usage de fonctionnalités de maniement délicat du langage de programmation ou du système ;
Les méthodologies de développement. Il y a plusieurs méthodes pour gérer l’activité des programmeurs afin de minimiser les risques de bugs. Plusieurs de ces techniques relèvent de la spécialité du génie logiciel ;
Le support des langages de programmation. Les langages incluent parfois des fonctionnalités qui aident les programmeurs à traiter les bugs, comme le traitement des exceptions. De plus, plusieurs langages récents ont délibérément exclu des fonctions avancées susceptibles de mener à des bugs. Par exemple, les langages Java et Perl n’offrent pas d’accès de bas niveau aux pointeurs, évitant qu’un programme n’accède à une zone de la mémoire par inadvertance ;
Le test. Le logiciel est essayé dans diverses configurations, notamment des configurations difficiles et « extrêmes ». On va aussi tenter de couvrir toutes les fonctionnalités, ou toutes les portions de code du logiciel, ou tous les chemins dans le code (ce dernier critère est en général impossible à atteindre). Cependant, le test ne donne pas d’assurance sur le bon fonctionnement du logiciel dans tous les cas, car il ne tient compte que d’un nombre limité de configurations du système, d’entrées des utilisateurs ou du monde extérieur… ;
Les méthodes formelles. Il s’agit ici de parvenir à une preuve, au sens mathématique, de bon fonctionnement du logiciel. La méthode peut fournir plus au moins d’automatisation : les assistants de preuve aident un utilisateur à formuler une preuve mathématique et la vérifient ; le model checking et l’analyse statique par interprétation abstraite sont automatiques ; il existe des gradations intermédiaires. Citons par exemple la Méthode B, utilisée pour la ligne 14 (Meteor) du métro parisien^[16] ;

Trouver et corriger les bugs, ou débuguer, est une partie majeure de la programmation de logiciels. Maurice Vincent Wilkes, pionnier de l’informatique, décrit ses réalisations des anné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és débogueurs existent afin d’aider les programmeurs à trouver les bugs. Toutefois, même avec l’aide d’un dé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 le dé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 un débogueur ; ceux-ci sont appelés heisenbugs (faisant, par plaisanterie, référence au principe 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.

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^[22] ») – 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 généralement obsolète. » – 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.

Jeux vidéo

Le terme de bug dans les jeux 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 un FPS n’aura pas la même nuisance qu’une impossibilité d’accomplir la quête principale d’un jeu de rôle.

L’existence des bugs n’apportent pas que des points négatifs :

La recherche et la correction de bugs démontrés permettent souvent une correction d’autres bugs inconnus à ce jour et/ou une optimisation du code source, ce qui est très profitable au joueur (jouabilité améliorée) comme au développeur (le support technique régulier d’un jeu est un gage de renommée).
La popularité exceptionnelle d’un jeu qui connaît toutefois des bugs est souvent initiatrice d’une communauté très prolifique capable de corriger ces bugs à l’aide de différents outils. Le jeu le plus symbolique de ce phénomène est certainement Fallout 2.
Certains bugs peuvent être profitables à des joueurs plus ou moins mal intentionnés. Dans les parties jouables en réseau (sur Internet ou en réseau local), les bugs exploitables sont duaux : soit ils sont source de destruction du fair play (notamment dans les jeux de tir subjectif), soit ils permettent une avancée spectaculaire et peuvent, par le fait, s’apparenter à de la triche.
Dans les concours de Speedrun, certains bugs sont très profitables afin de finir un jeu ou une séquence le plus rapidement possible.

Le terme de bug englobe d’autres notions moins usitées à cause de la popularité du nom de bug. Il serait judicieux de nommer certaines erreurs par oubli plutôt que par bug.

Notes et références

↑ « bogue », sur Grand dictionnaire terminologique, Office québécois de la langue française (consulté le 15 juillet 2012)
↑ Voir la section terminologie
↑ « Lorsqu'une soirée de l'été 1945, le tintamarre des rouages s'arrêta net. »Le bug informatique
↑ bug qui a affecté les premières versions de ce processeur
↑ Edison to Puskas, 13 novembre 1878, Edison papers, Edison National Laboratory, U.S. National Park Service, West Orange, N.J., cited in Thomas P. Hughes, American Genesis: A History of the American Genius for Invention, Penguin Books, 1989, ISBN 978-0-14-009741-2, on page 75.
↑ Fred R. Shapiro, April 1994, Byte Magazine, http://web.archive.org/web/20080106210506/http://www.byte.com/art/9404/sec15/art1.htm
↑ Le départ de l’intrigue du film Brazil est une illustration de cette anecdote : un insecte provoque un court-circuit dans une machine, transformant le nom Tuttle en Buttle ; ici, le bug met à jour les excès de la bureaucratie.
↑ http://www.culture.fr/franceterme/result?francetermeSearchTerme=bug&francetermeSearchDomaine=0&francetermeSearchSubmit=rechercher&action=search
1 2 3 (en) Nick Heap, Information technology and society: a reader, SAGE - 1995, (ISBN 978-0-8039-7981-9)
↑ (en) Guy Hart-Davis, Mastering Microsoft VBA, John Wiley & Sons - 2005,(ISBN 9780782144369)
1 2 (en) Andreas Zeller, Why programs fail: a guide to systematic debugging, Morgan Kaufmann - 2009,(ISBN 9780123745156)
↑ (en) Jon Shemitz, NET 2.0 for Delphi programmers, Apress - 2006,(ISBN 9781590593868)
↑ (en) « Top 10 reasons why there are bugs in software »
↑ (en) « Anatomy of a software bug »
↑ (en) « Basic software testing concepts »
1 2 Voir : Mise en œuvre de la méthode B
↑ Des orthographes moins courantes sont aussi débuggage, débugage, ou encore déboggage.
↑ (en) « Investigation of the Therac-25 incidents »
↑ (en) « Wired - History's worst software bugs »
↑ (en) « Engineering ethics, Google books »
↑ (en) « Accessing cost of the millenium bug »
↑ (en) Suppositions sur l'origine de l'expression.

Annexes

Bibliographie

BOULANGER Jean-Louis, Mise en œuvre de la méthode B,‎ 2013 (lire en ligne)

Liens externes

(en) La loi de Murphy appliquée à l’informatique
Le premier bug

Portail de l’informatique
Portail du logiciel
Portail de la programmation informatique

This article is issued from Wikipédia - version of the Friday, October 23, 2015. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.