Qu'est-ce qu'un bug ?

Le terme "bug" est souvent présenté comme étant apparu dans l'informatique lors d'un rapport envoyé par l'ingénieure Grace Hopper, après avoir repéré une défaillance due à une mite coincé dans l'un des relais électrique du Mark II.

Grace Hopper est un grand nom de l'informatique : créatrice du COBOL et notamment programmeuse émérite des machines Harvard Mark I, II et III.

Seulement, il y a deux éléments à ne pas écarter dans l'histoire de ce mot utilisé à tord et à travers aujourd'hui :

L'insecte en question n'a pas été découvert par Grace Hopper elle-même, mais par les opérateurs travaillant sur la machine, cette dernière l'a seulement consigné dans un rapport officiel, laissant une trace indélébile dans notre histoire.

Mais plus étonnant encore, le terme "bug" n'est pas arrivé avec l'informatique. Ce mot avait déjà été utilisé dans le jargon de l’ingénierie auparavant, à tels point que l'en on conserve des traces de son utilisation par Thomas Edison à propos de ses inventions et d'Isaac Asimov à propos de ses robots fictifs.

Néanmoins depuis son apparition, l'utilisation de cet anglicisme n'a jamais été aussi fréquente, renfermant souvent bien trop de sens différents pour un simple mot de trois lettres.

Les sens cachés

C'est bien souvent que lors de la gestion d'un projet informatique, un développeur se fait remonter de nombreux "bugs" et de natures très différentes :

• "La couleur du texte n'est pas la bonne"
• "Le bouton n'apparait pas"
• "Il manque un mot"
• "L'application s'arrête brusquement"
• ...

Tous ces retours sont dus à des "erreurs" de l'équipe de développement (ou parfois de l'équipe projet en général), et ces erreurs peuvent avoir des conséquences minimes (ou non) sur le produit final.

Explorons donc les différents termes alternatifs et plus précis que nous pouvons employer pour désigner un "bug" selon la gravité de la conséquence qu'il introduit :

Un défaut

Un défaut désigne une simple divergence par rapport aux spécifications et au rendu attendu par le commanditaire du projet. On peut parler d'un défaut graphique, d'un défaut de rédaction, d'un défaut fonctionnel, etc...

N'importe quelle erreur ayant entrainé un état différent de l'état attendu est un défaut, mais si cette erreur n'entraine qu'un simple défaut alors les conséquences ne sont pas grave, et certains défauts peuvent être laissés de côté si il ne sont pas prioritaires.

Une erreur de couleur ou dans la rédaction d'un texte est un simple défaut.

Une anomalie

Une anomalie désigne une erreur qui impute le fonctionnement "normal" du logiciel, c'est à dire que cela n'influe pas seulement sur le ressenti de l'utilisateur (comme pourrait le faire un simple défaut graphique), mais il peut impacter son utilisation, et faire que le logiciel ne fonctionne pas correctement.

Une anomalie n'implique pas que le logiciel soit inutilisable, mais que le comportement de ce dernier ne soit pas celui attendu, ce qui peut être problématique.

Si lors de l'inscription, l'utilisateur reçoit un e-mail pour supprimer son compte, alors c'est une anomalie ; le logiciel reste utilisable, mais son comportement comporte un évènement inattendu.

Une défaillance

Une défaillance est le niveau le plus haut de problème que peut provoquer une erreur de développement. Cela implique que le logiciel, ou une partie de ce dernier, n'est pas utilisable, ou que son fonctionnement diverge tellement de celui attendu qu'il en devient inutile.

Une défaillance doit être réglée sans attendre et ne peut pas être remis au lendemain car l'ensemble du côté fonctionnel du produit est en jeu.

Un crash dès le lancement de l'application est un exemple typique de défaillance.

Conclusion

Le terme bug est un mot trop générique qui ne porte pas suffisamment de sens sur la priorité des problèmes au sein d'un logiciel.

À la place on préfèrera les termes défauts (divergence par rapport aux attentes),  anomalies (fonctionnement incorrect) ou encore défaillances (logiciel ou fonctionnalité non utilisable).