Exercices pour la clef 6G

Voir l’information détaillée pour cette clef

exercice 1

Texte de base pour l'exercice
(les problèmes seront présentés à la suite du texte à l’intérieur d’une nouvelle fenêtre)

Version imprimable du texte

Au bonheur des bogues

Les bogues sont aussi vieux que les premiers ordinateurs. Pourra-t-on un jour s'en débarrasser?

Vous travaillez tranquillement sur votre ordinateur et, soudain, une fenêtre s'ouvre: dans un langage sibyllin à souhait, votre système vous signale qu'il est en mauvaise posture. Mieux encore, l'écran se fige, ni clavier ni souris ne répondent à vos supplications. Étouffant un juron, vous redémarrez votre ordinateur. Un bogue a encore frappé... [2e paragraphe]

Le terme "bogue" vient de l'anglais "bug", insecte. Thomas Edison l'utilisait déjà pour excuser une défaillance technique. Pour l'ère informatique, c'est à Grace Murray Hopper, vice-amirale de la marine américaine et informaticienne de renom, qu'on attribue l'expression. Le 9 septembre 1945, lors d'une panne du Mark II, l'un des premiers ordinateurs électromécaniques, Grace Hopper et son équipe eurent la surprise de découvrir qu'un papillon de nuit s'était coincé dans un relais électrique. Elle conserva l'insecte collé dans le journal de bord. Par la suite, lorsque le système était en panne, l'équipe s'excusait en expliquant qu'il était occupé au déboguage (debugging). [3e paragraphe]

Soixante-cinq ans plus tard, toujours aussi insaisissables et sournois, les bogues continuent de ternir la réputation de l'industrie informatique. Selon une étude du Standish Group sur 8 000 projets informatiques, pas plus de 16,2 % respectent les délais et les budgets. Le reste: saboté par les bogues ! Dans un cas sur deux, la facture des projets double en cours de route, et le délai de livraison est dépassé, en moyenne, de... 222 %!

Bien entendu, plus le projet est imposant, plus les risques d'échec sont élevés. Vingt pour cent des grands projets -- ceux qui comptent plus d'un million de lignes de codes -- n'aboutissent jamais.

Bref, cela ne va pas tout seul, au point que certains spécialistes de l'informatique font référence à la "crise du logiciel" pour décrire la situation. "Depuis 50 ans, nos connaissances techniques se sont nettement améliorées, explique Ettore Merlo, professeur au département de génie électrique et génie logiciel à l'École polytechnique de Montréal. Par contre, la complexité des programmes est aussi en constante croissance! Nous nous attaquons à des problèmes que nous n'osions même pas approcher il y a quelques années." [6e paragraphe]

Entre-temps, ce ne sont pourtant pas les idées qui ont manqué pour faire la chasse aux bogues.

Traditionnellement, les programmeurs se fient à la bonne vieille méthode des tests. On soumet le logiciel à rude épreuve pour révéler ses points faibles. Lorsqu'on détecte un bogue, on corrige et on teste à nouveau pour s'assurer que d'autres bogues n'ont pas été introduits. Bref, tester, corriger, et tester encore...

Une autre technique est l'inspection du code: chaque ligne est examinée, selon un protocole bien défini, afin de détecter les anomalies. Malheureusement, ces deux méthodes arrivent rarement à tout détecter. En situation réelle, il survient pratiquement toujours une défaillance imprévue.

Dans les années 80, les informaticiens ont espéré mieux s'en sortir avec les méthodes formelles. Il s'agit, en se basant sur des déductions mathématiques, de prouver qu'un logiciel est logiquement correct. " Ces techniques déplacent le niveau où les erreurs peuvent se produire, explique Ettore Merlo. Au lieu du programme lui-même, c'est la preuve mathématique qui peut contenir des erreurs! On peut aussi obtenir la preuve que le programme correspond parfaitement à ses spécifications, mais cela ne garantit pas qu'il réponde aux besoins!"

Le monde informatique a aussi cherché son salut en inventant de meilleurs langages informatiques ou systèmes d'exploitation. Mais, là encore, ce n'est pas suffisant. "Même s'il y a des ceintures de sécurité dans les voitures, cela ne veut pas dire qu'elles sont nécessairement utilisées ! remarque Ettore Merlo. La qualité des concepteurs et le contexte de développement demeurent plus importants que la qualité du langage. Un mauvais programmeur fera de mauvais logiciels, même avec un bon langage."

Bref, à l'heure actuelle, il n'existe pas de solution magique. L'approche la plus efficace consiste à cultiver une vue d'ensemble du processus de développement d'un système pour tenter d'identifier toutes les possibilités d'introduction d'erreur, y compris l'environnement de travail. C'est ce genre d'approche globale qu'encouragent des organismes comme le réseau SPIN (Software Process Improvement Network). Parrainé par le Software Engineering Institute (3), ce réseau international compte plusieurs dizaines de milliers de membres dans le monde, et tente d'enseigner de meilleures méthodes de programmation.

"Malgré les récents progrès techniques, la situation est encore alarmante, considère Richard Basque, président de SPIN Montréal. Il y a beaucoup trop de laisser-aller. On peut améliorer la situation, mais à condition de se discipliner. Il faut espérer que les gens vont réaliser le rôle critique que jouent certains logiciels dans leur vie et devenir plus exigeants. Ainsi, avant d'acheter une voiture équipée de freins contrôlés par ordinateur, il serait peut-être légitime de se demander qui peut assurer que le logiciel de freinage va bien fonctionner, et si ses concepteurs ont reçu une certification particulière."

Mais peut-on imaginer des systèmes totalement fiables? "Il est utopique de penser qu'un jour il n'y aura plus de bogues, croit Richard Basque, puisque la conception de systèmes informatiques est essentiellement une activité humaine. On peut tout de même obtenir un bon niveau de fiabilité, mais c'est une question de compromis. En appliquant les techniques de pointe, on pourrait créer un traitement de texte très fiable, avec un minimum de bogues. Mais il risque de coûter 200 000 dollars au lieu de 200."

Ettore Merlo est du même avis: " Même en informatique, il est possible d'appliquer les concepts de l'ingénierie classique, comme la redondance et la robustesse. Contre les pannes d'équipement, on peut par exemple doubler ou tripler les composantes d'un ordinateur (disque dur, microprocesseur, etc.). Au niveau du logiciel, on peut faire la même chose, en faisant réaliser les modules importants en plusieurs exemplaires par différentes équipes. Évidemment, cela suppose des coûts supplémentaires.

À moins d'être prêt à investir dans un système digne de figurer dans une centrale nucléaire, un avion de ligne ou une sonde spatiale, il ne faudra donc pas s'étonner des sautes d'humeur de notre ordinateur. On peut toujours se consoler en se rappelant l'âge héroïque de l'informatique où les systèmes étaient en panne le tiers du temps..."

Texte anonyme tiré du site WEB de la revue Québec-Science (http://www.cybersciences.com/Cyber/4.0/2001/02/internet.asplien externe).

> Accéder aux problèmes

Haut de page

© Victor Thibaudeau, mai 2008