Bogue informatique

Un bogue ou bug informatique est une anomalie dans un programme informatique l’empêchant de fonctionner correctement. Sa gravité peut aller de bénigne (défauts d’affichage mineurs) à majeure (explosion du vol 501 de la fusée Ariane 5).

Les bogues sont généralement dus à un problème de conception du logiciel ; l'erreur peut parfois être identifiée (et la correction effectuée simplement), mais elle peut aussi bien provenir de la conception même du programme, ce qui nécessite une refonte profonde. Plus rarement, les bogues dans les logiciels peuvent être dus à des erreurs dans les outils de développement utilisés par les programmeurs du logiciel. Enfin, le matériel lui-même peut comporter des bogues, comme ce fut le cas du bogue de la division du Pentium qui a affecté les premières versions de ce processeur.

Le terme est dérivé du mot anglais bug (insecte), venant du jargon des ingénieurs de matériel et représentant les erreurs de matériel qui survenaient. Le terme est parfois faussement attribué à Grace Hopper : une anecdote raconte qu'elle aurait découvert qu'un insecte (bug), coincé entre deux contacts du relais qui faisait fonctionner l’appareil, était la raison du mauvais fonctionnement d’un des premiers ordinateurs électromécaniques.

En 1946, Hopper a rejoint la faculté de Harvard au laboratoire où elle a continué son travail sur Harvard Mark II et Harvard Mark III. Elle a attribué une erreur dans Mark II à un papillon nocturne pris dans un relais, créant le terme bug. L’insecte fut enlevé avec soin et placé dans un journal de bord. Cette première anomalie a popularisé l’expression bug ou bogue pour représenter les erreurs dans un programme.

Malgré l’intérêt de l’anecdote ci-dessus, il est reconnu que l’utilisation du mot bug 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. 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 anglais bug vient du français « parasite ». En France, c'était le terme utilisé par les électriciens pour les problèmes de lignes utilisé sous la forme « la ligne est parasitée ». Adapté en anglais il est devenu bug puis est revenu en France sous la forme de « bogue » (de châtaigne ?) sous l’égide de la DGLF. Bug reste très largement utilisé.

En France, le terme « bogue » est recommandé par la Délégation générale à la langue française et aux langues de France (DGLF) depuis un arrêté paru au Journal officiel du 30 décembre 1983. Ce mot, qui se veut plus français, n'exprime pas une étymologie. C'est pourquoi peu de gens utilisent la version francisée. À cette époque le genre féminin était préconisé.

Cependant à la fin de la décennie 1990, les dictionnaires tels que le « Nouveau petit Robert » et « Le Petit Larousse illustré » rapportaient l’usage de ce terme au masculin, sans doute sous l’influence québécoise où l’Office québécois de la langue française (OQLF) prônait depuis longtemps l’emploi du genre masculin. Le terme français a été popularisé avec le fameux bogue de l'an 2000 qui, sans avoir entraîné de dysfonctionnement visible majeur, a néanmoins nécessité beaucoup de travaux de transformation des systèmes d'information dans la décennie 1990.

Désormais la DGLF recommande aussi le genre masculin pour ce mot.

Les pessimistes disent qu'il y a des bogues dans tous les programmes informatiques. En revanche, les programmes de qualité contiennent relativement peu d'erreurs et n'empêchent généralement pas le système de continuer ses tâches. Au contraire, les programmes moins bons, quelquefois dits bogués, contiennent beaucoup d’anomalies qui interfèrent souvent avec le fonctionnement du système.

Les bogues ont des effets qui varient grandement. Quelques-uns ont un effet subtil sur le fonctionnement du logiciel et peuvent demeurer inconnus pendant une longue période. D'autres sont plus sévères et peuvent arrêter le logiciel voire bloquer le système.

Dans certains cas, sur les systèmes d’exploitation, les bogues de logiciels peuvent rendre instable le système jusqu’à ce qu’il soit rechargé.

D'autres erreurs de programmation peuvent mener à des failles de sécurité ; le dépassement de tampon est un des bogues les plus communs permettant à un pirate informatique d'exécuter un nouveau programme sur la machine cible.

Les bogues peuvent avoir des répercussions économiques considérables. Steve McConnell a comptabilisé plusieurs bogues qui ont coûté plus de 100 millions de dollars US.

• Un des cas les plus spectaculaires est celui de la fusée européenne Ariane 5, qui a coûté plus d'un milliard de dollars. Quelques instants après le décollage, elle fut détruite à cause d'une erreur de l'ordinateur de guidage embarqué à bord de l'appareil. Toutefois, dans ce cas, le terme "bogue" est quelque peu impropre : en effet, "l'erreur" a consisté à reprendre à l'identique l'ordinateur et le logiciel utilisé sur Ariane 4 pour la gestion des centrales inertielles de guidage, ordinateur et logiciel qui fonctionnaient parfaitement sur cette fusée. Cependant le reste du système informatique d'Ariane 5 travaillait avec des nombres de 64 bits en virgule flottante alors que ces éléments travaillaient avec des nombres de 16 bits en entier signé. Lors du passage de valeurs d'un système à l'autre est apparu une exception matérielle (plus précisément, un dépassement arithmétique, ou les nombres de 64 bits ont une trop grande valeur pour être représentés en 16 bits, ce qui a fait partir le comportement par défaut de gestion d'erreur : un autotest), ce qui a eu pour effet une déviation de la trajectoire impossible à rectifier depuis le sol.
• La sonde de Vénus Mariner 1 fut perdue d’une façon similaire en 1962. Un trait d’union oublié dans un programme Fortran a coûté plus de 80 millions de dollars. D’après Arthur C. Clarke, ce fut le « plus coûteux trait d’union de l’histoire ».
• Le fameux bogue de l'an 2000, a enrichi les entreprises de conseil en informatique, mais a fait dépenser des fortunes aux entreprises qui ont bien été obligées de modifier la majorité de leurs logiciels, dans la crainte que ceux-ci ne traitent pas correctement les quatre chiffres des années et se retrouvent en 1900 au 1 janvier 2000.

Un bogue est 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. 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. Un programme bogué est un programme dont la mise en œuvre ne vérifie pas la 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, 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 bogues est donc un problème d’ordre fondamental, et non une limitation de la technologie actuelle.

Les bogues sont une conséquence de la nature de la tâche de programmation. Quelques-uns surviennent à cause de simples erreurs d’inattention d’un programmeur écrivant du code source. D’autres bogues sont le résultat d’interférences inattendues entre différentes parties d’un logiciel, voire de comportements imprévus de systèmes extérieurs au logiciel (capteurs défaillants qui retournent des valeurs fantaisistes). Certains, enfin, relèvent de la non-prise en compte des termes exacts des normes définissant les langages et les bibliothèques employées par les programmeurs (cf. exemple). Ces situations arrivent parfois quand les logiciels deviennent trop complexes pour que les programmeurs puissent penser à toutes les possibilités d’interaction entre plusieurs parties d’un programme.

L’industrie du développement logiciel fait de gros efforts pour trouver des méthodes de prévention des erreurs des programmeurs menant à des bogues. 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 bogue 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 bogue 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 bogues. 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 bogues, 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 bogues. Par exemple, les langages Java et Perl n'offre 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, etc.
• 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.

Trouver et corriger les bogues, ou déboguer, est une partie majeure de la programmation de logiciels. Maurice 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 bogues deviennent plus fréquents et difficiles à corriger. Quelquefois, les programmeurs passent plus de temps et d’efforts à trouver et à corriger les bogues qu’à écrire du nouveau code.

Habituellement, la partie la plus difficile du débogage 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 bogues. Toutefois, même avec l’aide d’un débogueur, dénicher un bogue est une tâche souvent très difficile.

Ordinairement, la première étape pour trouver un bogue est de trouver un moyen de le reproduire facilement. Une fois le bogue 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 bogue. 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 bogues 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.

Exemple de code non bogué mais pouvant provoquer une erreur et correction du code pour un fonctionnement détectant les erreurs des autres programmes ou de la machine.

• Le pseudo-code suivant représente une fonction prenant en entrée une adresse mémoire et incrémentant la valeur qui y est stockée.

fonction IncPointeur( pointeur )
*pointeur ++
fin fonction

• Le problème est que dans les systèmes informatiques, il est fréquent que seule une portion de la mémoire soit accessible en écriture et qu’une tentative de le faire dans une zone mémoire protégée ou inexistante, provoque un bogue, une interruption du programme ou au pire, un arrêt du système.
• Dans les systèmes complexes, il est souvent difficile et fastidieux de prévoir tout les cas possibles, c’est pourquoi la tolérance totale n’existe pas. Ceci n’empêche pas de prévoir un maximum de cas pour rendre le programme le plus robuste possible.

fonction IncPointeur( pointeur )
si EstValide( pointeur )
*pointeur ++
retour OK
sinon
retour ERREUR
fin si
fin fonction

• Dans le pseudo-code ci-dessus, le programme teste la validité de l’adresse avant d’y accéder, ce qui permet au programme de continuer même si une adresse erronée lui est transmise.

• « Ce n’est pas un bogue, c’est une fonctionnalité !» (de l’anglais It’s not a bug, it’s a feature). - Réponse fréquente des développeurs de logiciels à leurs utilisateurs.
• « Tout programme non trivial possède au moins un bogue » (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 »
• « Quand un logiciel n'a plus aucun bogue, il est habituellement désuet »

Le terme de bogue 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 bogue n'occasionnera pas la même gêne suivant son intensité. Une main d'un joueur traversant un mur dans un jeu de tir subjectif n'aura pas la même nuisance qu'une impossibilité d'accomplir la quête principale d'un jeu de rôles.

L'existence des bogues n'apportent pas que des points négatifs :

• La recherche et la correction de bogues démontrés permettent souvent une correction d'autres bogues 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 bogues est souvent initiatrice d'une communauté très prolifique capable de corriger ces bogues à l'aide de différents outils. Le jeu le plus symbolique de ce phénomène est certainement Fallout 2.
• Certains bogues 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 bogues 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 a du cheat (triche).
• Dans les concours de Speedrun, certains bogues sont très profitables afin de finir un jeu ou une séquence le plus rapidement possible.

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

• Mandelbug
• Schrödinbug
• Heisenbug
• Bohr bug