Le bug dans tous ses états

Publié le 10 janvier 2017 par Gee dans Tu sais quoi ?

Inclus dans le livre Grise Bouille, Tome III

On continue notre petite aventure au pays des octets (après Bit, Byte, Bitten, Dites adieu aux kilos en trop !, Des zéros et des uns, etc.). Aujourd’hui, voyons un peu ce que c’est que cette bestiole qu’on appelle « bug ».

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 :

Un mec remarque : « Dis, tu t'es trompée, là ! Ça plante ! » L'informaticienne derrière son PC : « Ah non mais c'est pas une erreur, hein ! C'est un bug ! » Le mec : « Euuh, ouais ? Et c'est quoi, la différence ? » L'informaticienne : « Bah… un bug, c'est pas d'ma faute. » Derrière son écran, un insecte dit : « C'est un peu facile de tout balancer sur les autres… »

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

Bugs Bunny : « Quoi d'nof, doctor ? » Le smiley : « Non mais ta guole, toi. »

💡 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 Geek : « Coupons la poire en deux. Appelons ça un “lug”. » Tux, mécontent : « T'es en train de dire qu'un Linux User Group, c'est lent et ça n'marche pas ? »

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.

Un ordinateur anthropomorphisé, qui a pris la foudre, tout déglingué, dit : « Des mises-à-jours sont dispon^^^bles pour votre ⌘rdinateur. Souhaitez-vous ouvrir le lect@æur CD ou ♠䷅䷅¶? » Le smiley le regarde, dubitatif : « Boh, moi 'jvois pas bien la différence avec un Windoze standard… »

▶️ 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.

Le commissaire Bougret regarde un boulier : « Il manque une boule sur la ligne des dizaines ! Du coup quand on fait 89 + 1, on arrive à 100 ! Il faut à tout prix retrouver cette boule ! » Charolles, son adjoint : « Les types de Motus sont sur le coup. »

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.

Une institutrice face à un processeur qui divise 4 195 835,0 par 3 145 727,0 et trouve 1,333 739 068 902 037 589 : « Eh bah, mon petit Pentium ? Ça sera 5/10 en calcul, il va falloir faire un effort. » Le processeur, penaud : « Nan mais c'était hyper-chaud… »

▶️ 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 ?

Un mec lambda : « Non, j'me souviens pas. » Gee : « Eh bah un logiciel, c'est un peu comme une maison. » Le mec : « Ah ouais ? » Gee : « Et le compilateur, c'est ce qui se charge de construire la maison utilisable par l'ordinateur (en zéros et en uns) à partir du langage de programmation utilisé par l'humain. » Le mec : « Aaaah d'accord… » Le smiley, blasé : « C'est lourd… mais c'est lourd… »

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

Un maçon regarde des plans et commente : « La piscine verticale posée contre le mur, c'est pas possible. » La cliente demande : « Vous voulez pas essayer, juste pour voir ? Comment vous pouvez être sûr avant d'avoir essayé ? » Le maçon : « Je suis las. Mais tellement las. »

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 peloton d'exécution. Le chef dit : « Présentez armes ! En joue ! peloton.exe a rencontré une erreur et doit fermer. » Le type accroché au poteau dit : « C'te chance. J'ai bien fait de toucher du bois. »

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

$La cliente du dessus est fracassée, le bras dans le plâtre, une béquille, un bandage autour de la tête, etc. Elle dit : « Vous auriez pu me dire que le plancher au premier étage ne supporterait pas mon poids… » Le maçon : « Mais le plancher était bien constructible, les plans étaient parfaitement clairs. J'suis payé pour construire votre baraque, moi, pas pour savoir c'que vous allez en faire. » Le smiley : « Leçon n°1 : votre ordinateur n'a absolument aucune intuition. »$

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.

Un programme regarde une zone mémoire de 6 éléments et dit : « Et maintenant, je vais parcourir mon tableau entre les cases 0 et 7 ! » À côté, c'est la zone mémoire d'un autre programme, et un gros type baraqué, avec une massue, représentant le service d'ordre du système d'exploitation, dit : « Vas-y, essaie, qu'on rigole. »

▶️ 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*.

Gee, une pile à la main, explique : « Voilà, si vous vous demandiez pourquoi les vieilles erreurs de Windoze vous renseignaient sur “l'état de la pile”, bah c'est pour ça. Rien à voir avec une pile électrique, donc. » Le smiley : « Merci Morpheus, mais ça ne rend pas le message d'erreur beaucoup plus utile au commun des mortels, remarque. »

✷ 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 !

Une voiture est en train de monter sur la Tour de Pise. Une personne dans la voiture dit : « T'es sûr qu'il déconne pas un peu, ton GPS ? » Une autre répond : « J'sais pas. Par contre je suis impressionné par mes pneus. »

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

Le Geek, derrière un ordinateur, s'exclame : « Il est complètement bugué, ce compilateur ! Quand j'ajoute 2 milliards avec 1 milliard, il me sort un nombre négatif ! » La Geekette commente : « Bah non… c'est pas un bug. C'est juste comme ça que fonctionnent les entiers sur 32 bits… Par contre si tu utilises ça dans ton programme, là tu vas écrire quelque chose qui est un bug… »

Dans une voiture, le conducteur, pas content, s'exclame : « Il bugue complètement, ce GPS ! C'était vachement plus long de passer par là ! » Le passager remarque : « Baah… ton GPS avait pas prévu les travaux… Mais c'est plus une fonctionnalité manquante qu'un bug, non ? »

⚠️ 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.

Le robot de l'informatique remarque : « Tiens, pour une fois que c'est pas moi qui passe pour un con à la fin… » Gee, blasé, répond : « Et d'abord, je ferais moins d'erreurs si t'étais pas aussi psychorigide ! Espèce de… de… De machine, va ! » Note : BD sous licence CC BY SA (grisebouille.net), dessinée le 9 janvier 2017 par Gee.

Publié le 10 janvier 2017 par Gee dans Tu sais quoi ?

🛈 Si vous avez aimé cet article, vous pouvez le retrouver dans le livre Grise Bouille, Tome III.

Le bug dans tous ses états

Le bug dans tous ses états

S'abonner au blog par email ou par RSS.

Partager cet article :

Soutenir