Babel bug

Cette note n'a absolument aucun intérêt ; ni plus ni moins que les autres en tous cas. Nous nous attardons en effet sur un évènement qui laisse de marbre le monde entier ou presque, et non sans raison.
Il s'agit du bug de l'an 2010. Vous ne ne vous souvenez plus des descriptions apocalytpiques que nous firent alors les média pour le passage à l'an 2000 : en cause la programmation de la date dans les systèmes informatiques, qui, pour les plus anciens, se trouveraient pris dans une faille spatio-temporelle et retourneraient à l'année zéro de la création (1970). On rappela la vieille garde, celle qui, armée de son vieux Cobol, ne meurt jamais. Aucune catastrophe n'eut finalement jamais lieu, au grand désappointement des Raëliens et de Paco Rabanne.

Passage à l'an 2000, zéro problème.
Passage à l'an 2010 :
- Allemagne : 30% des cartes de crédits bloquées par certains terminaux de paiements ou de retraits.
- Australie : des terminaux de paiements refusent de valider les transactions.
- Téléphones mobile : SMS datés de 2016.
- Hôpitaux : certains appareils médicaux passent en 2016.
etc.

Presque le jugement dernier. Il semble donc que certains appareils se figurent être en 2016 : lorsqu'une carte de crédit indique une limite de validité inférieure à cette date, elle est donc "naturellement" rejetée.
Il s'agit ici vraisemblablement d'un "malentendu" sur la façon d'interpréter le format de la date - de la même façon qu'un malentendu sur la façon d'interpréter des paramètres de la sonde Mars Climate Orbiter en 1999 résulta en crash de toute beauté: certaines données de navigation envoyées par la sonde étaient interprétées selon le système métrique, alors qu'il aurait fallu les traiter selon le système de mesure anglo-saxon . Pour les détails cf Wikipedia.

Pour notre cas passionnant, le problème réside donc (à première vue) dans le codage de l'information "date" par certaines horloges : les systèmes informatiques (ordinateurs, terminaux de paiements etc.) utilisent ces horloges internes pour calculer la date et l'heure courante.
Sur certains modèles d'horloge, la partie unitaire et décimale de l'année en cours est codée sur un octet (8 bits), mais de la façon suivante :
Les quatre premiers bits concernent la partie décimale de l'année.
Les quatre suivants concernent la partie unitaire de l'année.
+> ainsi, pour l'année 2009, la partie 09 de l'année est codée comme suit :
Quatre premiers bits : 0000 en binaire -> 0 en décimal
Quatre suivants : 1001 en binaire -> 9 en décimal (pour la conversion : http://www.apprendre-en-ligne.net/crypto/images/bases.html)
Pour info, ce type d'encodage est appelé BCD (binary coded digital).


Mais pour les programmes qui ne savent pas qu'il faut lire l'octet non d'un bloc, mais 4 bits par 4 bits, le problème se pose quand on passe à l'an 2010 :
Quatre premiers bits : 0001 en binaire -> 1 en décimal
Quatre suivants : 0000 en binaire -> 0 en décimal
Dans le format BCD, on sait que 1 concerne les années décimales, et 0 les unités => 10.
Mais si on lit l'information d'un bloc, on obtient : 0001000 = 16 en décimal.  D'où au final un 2016 triomphant de toute la gloire de sa tyrannie usurpée.

Voici une raison possible de ce petit foutoir. Tout ceci montre que notre édifice est somme toute très fragile, et que, se complexifiant, il devient de plus en plus vulnérable à ce genre de détails aux conséquences disproportionnées. Cela pourrait fort bien devenir une autre tour de Babel. Une autre victime à l'époque d'un petit problème de compréhension et de langage.