Worldlex Wiki Les effets d'un bogue logiciel peuvent aller de mineurs (comme un mot mal orthographié dans l' interface utilisateur ) à graves (comme des plantages fréquents ).
En 2002, une étude commandée par l' Institut national des normes et de la technologie du département du Commerce des États-Unis a conclu que « les bogues ou erreurs de logiciels sont si répandus et si préjudiciables qu'ils coûtent à l'économie américaine environ 59 milliards de dollars par an, soit environ 0,6 % du produit intérieur brut ».
Depuis les années 1950, certains systèmes informatiques ont été conçus pour détecter ou corriger automatiquement diverses erreurs logicielles pendant leur fonctionnement.
Thomas Edison écrivait ceci dans une lettre à un collaborateur en 1878 :Il en a toujours été ainsi pour toutes mes inventions. La première étape est une intuition, qui survient avec force, puis des difficultés apparaissent – telle ou telle chose tombe en panne – et c’est alors que les « bugs » – comme on appelle ces petits défauts et difficultés – se manifestent, et des mois d’observation intense, d’étude et de travail sont nécessaires avant de pouvoir affirmer avec certitude le succès ou l’échec commercial.
Les problèmes rencontrés avec le matériel militaire pendant la Seconde Guerre mondiale étaient appelés bugs ou dysfonctionnements.
Isaac Asimov a utilisé le terme « bug » pour désigner les problèmes rencontrés avec un robot dans sa nouvelle « Attrape ce lapin », publiée en 1944.
La contre-amirale Grace Hopper , pionnière de l'informatique dans l'US Navy, a popularisé l'histoire d'un papillon de nuit à l'origine d'un dysfonctionnement sur un des premiers ordinateurs électromécaniques . Alors qu'elle travaillait sur les Mark II et Mark III en tant que professeure à Harvard vers 1947, des opérateurs ont identifié un papillon de nuit coincé dans un relais comme étant la cause d'une erreur sur le Mark II. Le papillon a été retiré du mécanisme et consigné dans un registre avec la mention : « Premier cas avéré de dysfonctionnement informatique ». Il semblerait que les opérateurs, dont William « Bill » Burke, qui travaillera plus tard au Laboratoire des armes navales de Dahlgren, en Virginie , [ le terme technique et faisaient probablement un jeu de mots en confondant les deux sens du mot « bug » (biologique et technique). Même s'il s'agissait d'une plaisanterie, cette histoire montre que le terme était couramment utilisé dans le domaine informatique à cette époque.
Terminologie
La métamorphose des erreurs (du grec meta = « changement », morph = « forme ») désigne l’évolution d’un défaut lors de la phase finale du déploiement logiciel. La transformation d’une erreur commise par un analyste au début du cycle de vie du développement logiciel, qui conduit à un défaut lors de la phase finale du cycle, est appelée métamorphose des erreurs .
Les différentes étapes d'une erreur dans le cycle de développement peuvent être décrites comme une erreur, une anomalie, une faute, un échec, une erreur, une exception, un crash, un glitch, un bug, un défaut, un incident, ou un effet secondaire.
Exemples
Des bogues logiciels ont été liés à des catastrophes.
- Des bogues logiciels dans la machine de radiothérapie Therac-25 ont été directement responsables de décès de patients dans les années 1980.
- En 1996, le prototype de fusée Ariane 5 de l' Agence spatiale européenne, d'une valeur de 1 milliard de dollars américains, a été détruit moins d'une minute après son lancement en raison d'un bug dans le programme informatique de guidage embarqué.
- En 1994, un hélicoptère Chinook de la RAF s'est écrasé , tuant 29 personnes ; l'accident a d'abord été attribué à une erreur de pilotage, mais on a ensuite pensé qu'il avait été causé par un bogue logiciel dans l' ordinateur de contrôle du moteur .
- Un logiciel défectueux a provoqué le scandale de la Poste britannique au début du XXIe siècle .
Controverse
L’utilisation du terme « bogue » pour décrire le comportement d’un logiciel est parfois sujette à controverse en raison de différences de perception. Certains suggèrent d’abandonner ce terme, arguant qu’il sous -entend que le défaut est apparu spontanément, et préconisent plutôt l’utilisation du terme « défaut » , car il indique plus clairement qu’il est causé par une erreur humaine.
Certains affirment que ce bug pourrait servir à dissimuler un choix de conception délibéré. En 2011, suite aux critiques du sénateur américain Al Franken concernant l'enregistrement et le stockage des données de géolocalisation des utilisateurs dans des fichiers non chiffrés , Apple a qualifié ce comportement de bug. Cependant, Justin Brookman, du Center for Democracy and Technology, a contesté cette interprétation, déclarant : « Je suis ravi qu'ils corrigent ce qu'ils appellent des bugs, mais je m'insurge contre leur déni catégorique de tout suivi des utilisateurs. »
Prévention
La prévention des bogues le plus tôt possible dans le processus de développement logiciel est un objectif d'investissement et d'innovation.
Soutien linguistique
Les langages de programmation récents sont généralement conçus pour corriger les bogues courants en exploitant les vulnérabilités des langages existants. Les enseignements tirés des langages plus anciens comme BASIC et C servent à concevoir des langages plus récents tels que C# et Rust .
Un langage compilé permet de détecter certaines fautes de frappe (comme un identifiant mal orthographié) avant l'exécution, ce qui intervient plus tôt dans le processus de développement logiciel que pour un langage interprété .
Les langages peuvent inclure des fonctionnalités telles qu'un système de typage statique , des espaces de noms restreints et une programmation modulaire . Par exemple, pour un langage typé et compilé (comme le C ) :
nombre flottant = "3";
L'instruction est syntaxiquement correcte, mais échoue à la vérification de type car la partie droite, une chaîne de caractères, ne peut pas être affectée à une variable de type flottant. La compilation échoue Java ne prend pas en charge l'arithmétique des pointeurs , qui peut être très rapide mais risque d'entraîner des corruptions de mémoire ou des erreurs de segmentation si elle n'est pas utilisée avec une extrême prudence.
Certains langages intègrent des fonctionnalités qui augmentent la charge d'exécution afin de prévenir les bogues courants. Par exemple, de nombreux langages incluent une vérification des limites d'exécution et un mécanisme de récupération en cas d'erreur de dépassement de limites, évitant ainsi le plantage.
Techniques
Les règles de style et la programmation défensive peuvent éviter les erreurs typographiques (fautes de frappe) faciles à manquer.
Par exemple, la plupart des langages de programmation de la famille C autorisent l'omission des accolades autour d'un bloc d'instructions s'il ne contient qu'une seule instruction. Le code suivant exécute la fonction d’une revue de code ) ou automatisée (par exemple, par l’intermédiaire d’outils tels que les linters ).
Spécification
Certains affirment que la rédaction d'une spécification de programme , qui décrit le comportement attendu d'un programme, permet de prévenir les bogues. D'autres , en revanche, soutiennent que les spécifications formelles sont impraticables pour tout programme autre que les plus courts, en raison des problèmes d' explosion combinatoire et d'indétermination .
Tests logiciels
L’un des objectifs des tests logiciels est de détecter les bogues. Les mesures effectuées pendant les tests permettent d’estimer le nombre de bogues susceptibles de subsister. Cette estimation est d’autant plus fiable que le produit est testé et développé longtemps.
Pratiques agiles
Le développement logiciel agile peut impliquer des mises à jour fréquentes avec des modifications relativement mineures. Les défauts sont révélés par les retours des utilisateurs.
Avec le développement piloté par les tests (TDD), les tests unitaires sont écrits en même temps que le code de production, et ce dernier n'est considéré comme terminé que lorsque tous les tests ont été écrits et exécutés avec succès.
Analyse statique
Les outils d' analyse statique de code aident les développeurs en inspectant le code source du programme au-delà des capacités du compilateur afin de repérer les problèmes potentiels. Bien qu'il soit généralement impossible de résoudre le problème de la détection de toutes les erreurs de programmation à partir d'un cahier des charges (voir le problème de l'arrêt ), ces outils exploitent le fait que les programmeurs humains ont tendance à commettre certains types d'erreurs simples lors de l'écriture de logiciels.
Instrumentation
Des outils de surveillance des performances du logiciel en cours d'exécution, destinés soit à identifier des problèmes tels que des goulots d'étranglement , soit à garantir son bon fonctionnement, peuvent être intégrés explicitement au code (par exemple, par une simple instruction PRINT "I AM HERE") ou fournis sous forme d'outils. Il est souvent surprenant de constater qu'un fragment de code consomme la majeure partie du temps d'exécution ; la suppression de ces hypothèses peut alors nécessiter une réécriture du code.
Source libre
Le développement open source permet à quiconque d'examiner le code source. Selon une théorie popularisée par Eric S. Raymond sous le nom de loi de Linus , les logiciels open source populaires ont plus de chances de contenir peu ou pas de bogues que les autres logiciels, car « avec suffisamment de relecteurs, tous les bogues sont superficiels » . Cette affirmation a toutefois été contestée : le spécialiste en sécurité informatique Elias Levy a écrit qu'« il est facile de dissimuler des vulnérabilités dans un code source complexe, peu compris et non documenté », car « même si des personnes examinent le code, cela ne signifie pas qu'elles possèdent les compétences requises » . La vulnérabilité OpenSSL de 2008 dans Debian est un exemple de bogue affectant un logiciel open source .
Débogage
En règle générale, la première étape pour localiser un bogue consiste à le reproduire de manière fiable. Si le problème ne peut être reproduit, le programmeur ne peut en déterminer la cause et, par conséquent, ne peut le corriger.
Certains bogues sont révélés par des entrées difficiles à reproduire. L'une des causes des décès survenus avec la machine à radiothérapie Therac-25 était un bogue (plus précisément, une condition de concurrence ) qui se manifestait uniquement lorsque l'opérateur saisissait très rapidement un plan de traitement ; plusieurs jours d'entraînement étaient nécessaires pour y parvenir, si bien que le bogue ne s'est pas manifesté lors des tests ni lorsque le fabricant a tenté de le reproduire. D'autres bogues peuvent cesser de se produire dès que la configuration est améliorée pour faciliter leur détection, par exemple en exécutant le programme avec un débogueur ; on les appelle des « heisenberg bogue » (un terme humoristique faisant référence au principe d'incertitude d'Heisenberg ).
Parfois, un bogue n'est pas un défaut isolé, mais résulte d'une erreur de raisonnement ou de planification de la part des programmeurs. Souvent, une telle erreur logique nécessite la refonte ou la réécriture d'une partie du programme : un processus appelé refactoring de code .
Une revue de code , consistant à parcourir le code étape par étape et à imaginer ou transcrire le processus d'exécution, peut souvent permettre de déceler des erreurs sans jamais reproduire le bogue en tant que tel.
Un programme appelé débogueur peut aider un programmeur à trouver du code défectueux en examinant le fonctionnement interne d'un programme, par exemple en exécutant le code ligne par ligne et en visualisant les valeurs des variables.
Au lieu d'utiliser un débogueur, le code peut être instrumenté avec une logique permettant d'afficher des informations de débogage afin de suivre l'exécution du programme et d'observer les valeurs. La sortie se fait généralement sur la console , dans une fenêtre , dans un fichier journal ou via une sortie matérielle , pouvant par exemple piloter une LED témoin .
Depuis les années 1990, et en particulier après la catastrophe du vol 501 d'Ariane 5 , l'intérêt pour les aides automatisées au débogage a augmenté, comme l'analyse statique du code par interprétation abstraite .
Dans un système embarqué , le logiciel est souvent modifié pour contourner un bug matériel, car les modifications logicielles peuvent être moins coûteuses et moins perturbatrices que la modification du matériel.
Gestion
La gestion des bogues passe par des activités telles que la documentation, la catégorisation, l'attribution, la reproduction, la correction et la publication du code corrigé.
Des outils sont souvent utilisés pour suivre les bogues et autres problèmes liés aux logiciels. Généralement, l'équipe de développement logiciel utilise des outils différents de ceux utilisés par le service client pour suivre les commentaires des utilisateurs .
Un élément suivi est souvent appelé bug , défaut , ticket , problème , fonctionnalité , ou, dans le cadre du développement logiciel agile , récit utilisateur ou épopée . Les éléments sont généralement catégorisés selon des critères tels que la gravité, la priorité et les numéros de version concernés.
Dans un processus parfois appelé triage , des décisions sont prises pour chaque bogue quant à son traitement et au moment opportun, en fonction d'informations telles que sa gravité, sa priorité et des facteurs externes comme les calendriers de développement. Le triage n'inclut généralement pas d'enquête sur la cause. Il peut être effectué régulièrement et consiste au minimum à examiner les nouveaux bogues signalés depuis le dernier triage, pouvant s'étendre à tous les bogues ouverts. Les participants peuvent inclure le chef de projet, le responsable du développement, le responsable des tests, le responsable de la compilation et des experts techniques.
Gravité
La gravité est une mesure de l'impact d'un bogue. Cet impact peut se traduire par une perte de données, des pertes financières, une atteinte à la réputation et un gaspillage d'efforts. Les niveaux de gravité ne sont pas standardisés et varient selon le contexte, notamment le secteur d'activité et l'outil de suivi. Par exemple, un plantage dans un jeu vidéo a un impact différent d'un plantage sur un serveur bancaire. Exemples de descriptions de niveaux de gravité : plantage ou blocage , absence de solution de contournement (l'utilisateur ne peut pas accomplir une tâche), solution de contournement disponible (l'utilisateur peut toujours accomplir la tâche), défaut visuel (une faute d'orthographe, par exemple) ou erreur de documentation . Autres exemples de niveaux de gravité : critique , élevé , faible , bloquant , mineur . La gravité d'un bogue peut correspondre à sa priorité de correction, ou bien les deux peuvent être quantifiées et gérées séparément.
correctif .
Mise à jour de maintenance
Une version logicielle qui met l'accent sur les corrections de bogues peut être qualifiée de version de maintenance modification incompatible.
Implications
L'ampleur et la nature des dommages qu'un bogue logiciel peut causer influencent les décisions, les processus et les politiques en matière de qualité logicielle. Dans des domaines tels que les vols spatiaux habités , l'aviation , le nucléaire , la santé , les transports publics ou la sécurité automobile , les logiciels présentant un risque de blessures, voire de décès, font l'objet d'un contrôle qualité bien plus rigoureux que, par exemple, un site de vente en ligne. Dans le secteur bancaire, où les défauts logiciels peuvent engendrer de graves pertes financières pour la banque ou ses clients, le contrôle qualité est également primordial, contrairement à une application de retouche photo.
Outre les dommages causés par les bogues, une partie de leur coût est liée aux efforts déployés pour les corriger. En 1978, Lientz et al. ont montré que la médiane des projets consacre 17 % de leurs efforts de développement à la correction des bogues . En 2020, une étude menée sur les dépôts GitHub a révélé que cette médiane s'élevait à 20 % .
le Goddard Space Flight Center de la NASA a réussi à réduire son nombre moyen d'erreurs de 4,5 pour 1 000 lignes de code ( SLOC ) à 1 pour 1 000 SLOC.
Une autre étude de 1990 a montré que des processus de développement logiciel exceptionnellement performants peuvent atteindre des taux d'échec de déploiement aussi bas que 0,1 pour 1 000 lignes de code source (SLOC). Ce chiffre est repris dans des publications telles que Code Complete de Steve McConnell [ et l' étude de la NASA sur la complexité des logiciels de vol . Certains projets ont même atteint le zéro défaut : le firmware de la machine à écrire IBM Wheelwriter, compte 63 000 lignes de code source, et le logiciel de la navette spatiale, avec 500 000 lignes de code source.
Pour faciliter la reproductibilité des recherches sur les tests et le débogage, les chercheurs utilisent des ensembles de référence de bogues sélectionnés :
- le benchmark Siemens
- ManyBugs est un benchmark de 185 bogues C dans neuf programmes open-source.
- Defects4J est un ensemble de données de référence comprenant 341 bogues Java issus de 5 projets open source. Il contient les correctifs correspondants, couvrant une variété de types de corrections. Il a été largement utilisé pour la recherche sur la réparation automatique de programmes.
Types
Quelques types de bugs notables :
Erreur de conception
Un bogue peut être dû à une conception insuffisante ou incorrecte par rapport aux spécifications. Par exemple, si les spécifications consistent à classer par ordre alphabétique une liste de mots, un bogue de conception peut survenir si la conception ne prend pas en compte les symboles, ce qui entraîne un classement alphabétique incorrect des mots contenant des symboles.
Arithmétique
Les opérations numériques peuvent entraîner des résultats inattendus, un traitement lent ou un plantage. Un tel bogue peut provenir d'un manque de connaissance des qualités du stockage des données, comme une perte de précision due à l'arrondi , des algorithmes numériquement instables , un dépassement et un sous-dépassement arithmétiques , ou d'un manque de connaissance de la façon dont les calculs sont gérés par différents langages de programmation, comme la division par zéro qui, dans certains langages, peut lever une exception et, dans d'autres, peut renvoyer une valeur spéciale telle que NaN ou l'infini .
Flux de contrôle
Interface
- Utilisation incorrecte de l'API.
- Implémentation du protocole incorrecte.
- Manipulation incorrecte du matériel.
- Hypothèses erronées concernant une plateforme particulière.
- Systèmes incompatibles . Une nouvelle API ou un nouveau protocole de communication peut sembler fonctionner correctement lorsque deux systèmes utilisent des versions différentes, mais des erreurs peuvent survenir si une fonction implémentée dans une version est modifiée ou absente dans une autre. Dans les systèmes de production qui doivent fonctionner en continu, l'arrêt complet du système pour une mise à jour majeure est souvent impossible, comme dans le secteur des télécommunications ou sur Internet . Dans ce cas, les segments d'un système étendu sont mis à jour individuellement afin de minimiser les perturbations sur le réseau. Cependant, certaines sections peuvent être négligées et non mises à jour, ce qui engendre des erreurs de compatibilité parfois difficiles à identifier et à corriger.
- Annotations de code incorrectes.
Concurrence
- Interblocage Condition de concurrence les sections critiques , exclusions mutuelles et autres caractéristiques du traitement concurrent . Le protocole TOCTOU ( Time-of-check to time-of-use ) est une forme de section critique non protégée.
Ressources
Syntaxe
travail d'équipe
- Mises à jour non propagées : par exemple, lorsqu’un programmeur modifie « myAdd » mais oublie de modifier « mySubtract », qui utilise le même algorithme. Ces erreurs sont atténuées par le principe « Don’t Repeat Yourself » (Ne vous répétez pas) .
- Commentaires obsolètes ou incorrects : de nombreux programmeurs supposent que les commentaires décrivent fidèlement le code.
- Différences entre la documentation et le produit.
En politique
Rapport « Bugs dans le système »
L'Open Technology Institute, géré par le groupe New America [ a publié en août 2016 un rapport intitulé « Bugs in the System » (Des bugs dans le système) affirmant que les décideurs politiques américains devraient entreprendre des réformes pour aider les chercheurs à identifier et à corriger les bugs logiciels. Le rapport « souligne la nécessité d'une réforme dans le domaine de la détection et de la divulgation des vulnérabilités logicielles » . L'un des auteurs du rapport a déclaré que le Congrès n'avait pas fait assez pour lutter contre les vulnérabilités des logiciels, même s'il a adopté plusieurs lois pour s'attaquer au problème plus vaste de la cybersécurité [
Ce sont généralement les chercheurs gouvernementaux, les entreprises et les experts en cybersécurité qui découvrent les failles logicielles. Le rapport préconise une réforme des lois sur la cybercriminalité et le droit d'auteur.
glitch » est parfois utilisé pour désigner un bug logiciel. On peut citer en exemple le bug et l'espèce non officielle de Pokémon nommée MissingNo.