Le bug dans tous ses états

Le bug dans tous ses états

Il existe de nombreuses anecdotes plus ou moins crédibles pour expliquer l'utilisation du mot bug (« insecte » en anglais) en informatique. La plus plausible est la suivante :

(Ah oui, et en ce qui concerne la francisation à deux ronds « bogue », je commencerai à l'utiliser le jour on prononcera « bogz bonny ».)

💡 Le bug désigne en fait pas mal de choses, du simple plan-tage à l'erreur de conception en passant par le petit ralentissement.

Même si en cas de ralentissement informatique, on aura plutôt tendance à parler de « lag » que de « bug ».

Le fait est que l'informatique, ça repose sur un certain nombre de niveaux complexes, chacun de ces niveaux étant une source potentielle de bugs.

Et plus on est bas niveau, plus ça a intérêt à être stable, sinon tout ce qui est au-dessus risque de buguer.

▶️ Le bug de plus bas niveau que l'on puisse trouver, c'est le bug matériel, celui qui arrive au niveau du microprocesseur.

C'est un peu comme si vous aviez un boulier mal foutu.

C'est très rare que ça arrive.

Principalement parce qu'un processeur, c'est la base de toute l'informatique et que si ça ne marche pas, ça impacte absolument tout le reste, quelle que soit la qualité du logiciel qu'on fait tourner dessus !

⚠️ Mais c'est arrivé par exemple sur les processeurs Pentium d'Intel en 1994, qui pouvaient parfois renvoyer des résultats très très inexacts en divisant deux nombres.

▶️ Ensuite, le niveau au-dessus, c'est l'erreur de compilation.

Vous vous souvenez que dans l'article Des zéros et des uns, on avait dit qu'un logiciel, c'était un peu comme une maison ?

Et que le compilateur, c'était ce qui se chargeait de construire la maison utilisable par l'ordinateur (en zéros et en uns) à partir du langage de programmation utilisé par l'humain ?

💡 Une erreur de compilation, en gros, c'est quand vous faites une erreur en écrivant les plans de votre maison et que votre maçon vous explique gentiment qu'il ne peut pas la construire.

Bon okay, à moins d'être programmeur ou programmeuse, il y a peu de chance que vous croisiez une erreur de compilation.

▶️ Il y a beaucoup plus de chances que vous tombiez sur une erreur d'exécution (« runtime error » comme on dit outre-atlanmanche).

💡 Un programme peut en effet être compilé sans erreur (les plans de la maison sont corrects) mais planter lorsqu'il est utilisé.

Les causes qui peuvent faire planter votre programme en cours de route sont trèèèèèèèèès nombreuses.

⚠️ Parlons par exemple de l'erreur de segmentation (« seg fault » for the intimes), qui arrive lorsque le programme essaie d'accéder à une zone de la mémoire qui ne lui appartient pas.

▶️ Ou encore le dépassement de pile (« stack overflow » like we say outer-Manching), qui arrive quand le programme doit stocker (= empiler) tellement d'informations à la suite que l'ordinateur n'a plus de place à lui allouer*.

✷ En fait la pile est un mécanisme particulier du système qui concerne par exemple les appels de fonctions, mais je simplifie parce que c'est compliqué et que dans le contexte, on s'en tamponne.

▶️ Ensuite, il y a la possibilité que votre programme ne plante pas… mais qu'il fasse des choses « fausses ».

💡 Le programmeur ou la programmeuse a écrit son programme correctement (pas d'erreur de compilation), ne fait aucune action illégale et ne demande pas plus de ressources que possible au système d'exploitation (pas d'erreur à l'exécution)… mais a peut-être juste écrit un calcul faux, remplacé un + par un -, etc.

Là, c'est tout de suite plus compliqué, notamment parce que le logiciel marche, il ne fait juste pas la bonne action. Et on ne remarque pas forcément tout de suite qu'il y a problème !

▶️ Et ensuite ? Eh bien, on arrive au niveau où la frontière entre « bug », « logiciel mal conçu » et « fonctionnalité mal comprise » devient floue…

⚠️ Mais pour conclure, notez le point commun entre chacun de ces bugs : ils sont tous le fruit d'une erreur humaine. Un bug, c'est pas la machine qui décide de se planter par l'opération du Saint Esprit. C'est quelqu'un qui a merdé quelque part.