Extrait de l'émission CPU release Ex0094 : Crie si tu sais… I.
C'est avec la gorge serrée par la peur et la honte, que je me présente à vous, sous couvert d'anonymat.
Je suis un ingénieur diplômé d'une grande école, qui totalise pas moins de 20 ans d'expérience dans l'informatique financière.
J'ai débuté ma carrière en 1998 dans une société spécialisée dans les marchés financiers.
Cette année-là, mes anciens camarades d'école commençaient déjà à s'inquiéter du passage à l'an 2000, synonyme d'un potentiel réveillon de la Saint-Sylvestre et jour de l'an à passer au bureau, tout ceci dans l'hypothèse où, bien entendu, nos centrales nucléaires ne venaient pas à exploser à cause d'un bug, éradiquant toute forme de vie de notre planète.
Pour ma part, je ne pouvais m'empêcher d'esquisser un sourire moqueur, et de leur dire que ce qui m'attendait, ce n'est pas un, mais deux changements d'année aux conséquences inconnues. Ce que je n'avais pas anticipé, cependant, c'est que j'allais en vivre un troisième, bien malgré moi.
Pour la plupart des gens, le passage à l'Euro correspond à l'introduction des pièces et billets à compter du 1er janvier 2002, mais en réalité, un premier passage à l'Euro a été réalisé fin 1998 sur les marchés financiers. La société qui m'employait était donc en première ligne.
J'ai donc passé mon réveillon du 31 décembre 1998 avec mes collègues de bureau, à boire du mauvais mousseux accompagné de petits fours surgelés, dans l'attente frénétique du taux de conversion Franc/Euro, l'introduction des nouveaux produits financiers dans nos systèmes, et les vérifications méticuleuses en suivant, dans l'angoisse qu'un bug non éradiqué devienne responsable d'un désastre financier qui en comparaison ferait passer l'affaire Jérôme Kerviel pour un vol à l'étalage. Au final, tout se passe à merveille.
Bref, fort de cette expérience, c'est avec sérénité que j'ai accueilli l'année 2000. La station spatiale Mir avait finalement décidé de rester là où elle était, la Fin du Monde n'était pas pour cette fois, apparemment.
A mon niveau, RÀS, tout se passe sans accroc.
Mais voilà, appelez ça le karma, le destin, la faute à pas de chance, bref, peu importe, il était écrit que je ne m'en sortirai pas aussi facilement.
En 2003, je déménage sur Toulouse, pour intégrer une start-up œuvrant dans le domaine du paiement par carte bancaire. J'y suis embauché comme développeur, et malgré la croissance de la société qui m'a de facto
poussé vers un poste d'encadrement, je code toujours sur des systèmes bancaires.
Et me voilà en 2009, le 31 décembre, pour un réveillon en famille. Au petit matin du 1er janvier 2010, je reçois un appel de mon patron, m'indiquant que tous les paiements par carte bancaire sont refusés depuis le 1er janvier à minuit.
Gloups.
Ni une, ni deux, je file à mon bureau, et je constate que tous les paiements par carte bancaire sont rejetés par les banques. J'analyse les demandes de paiement, et je finis par trouver le bug. Un simple bug de représentation.
Si vous avez quelques bases en informatique, vous savez que les ordinateurs manipulent des données en binaire, ils ne comprennent que des zéro et des un, ce qu'on appelle des bits. En regroupant ces bits 8 par 8, on obtient des octets. Un octet est composé de deux quartets, ou digits
, ou encore nibbles
.
C'est là ou la notion de représentation intervient, sous la forme de ce qu'on appelle une base de calcul
.
Nous sommes habitués à compter en décimal, ce qui veut dire base dix
, à l'aide de nos dix doigts, ou en représentant un nombre donné par les sigles arabes nommés chiffres
, qui vont de zéro à neuf.
En informatique, pour représenter un octet, on utilise en général la base hexadécimale, soit seize.
Les chiffres qu'on utilise sont ceux de 0 à 9, complétés par les lettres de A à F.
Cependant, l'être humain moyen ne sait compter qu'en décimal. C'est donc à l'ordinateur de s'adapter.
Dans les années 1970, des processeurs tels le 6502 de MOS Technologies proposaient un mode dit BCD (Binary-Coded Decimal). Ceci permettait de faire des calculs directement en décimal, dans des environnements où la mémoire ou la vitesse sont extrêmement faibles, tels les calculatrices ou les flippers.
La société Commodore, un fabriquant de calculatrices, a fini par racheter MOS Technologies, et sortir des ordinateurs tels le PET, le VIC-20, et surtout le Commodore 64, ordinateur le plus vendu au monde.
On retrouve ce processeur aussi dans les premiers ordinateurs créés par Apple, notamment le légendaire Apple II.
Bref, revenons à nos moutons du boxon généré par ce problème de représentation. La cause est simple.
Un paiement par carte bancaire contient une information de date, et notamment les 2 derniers chiffres de l'année, stockée dans un octet en format BCD. Logique, un premier digit pour les dizaines, et un deuxième pour les unités. Mais voilà, j'ai complètement zappé ce détail, qui est passé inaperçu pendant plusieurs années.
En effet, de 2000 à 2009, la valeur des 2 derniers chiffres de l'année court de 0 à 9, qui s'écrit quelque soit la représentation choisie 00 à 09. Mais la valeur 10 s'écrit bien 10 en BCD, mais 0A en hexadécimal !
Je venais donc de planter toutes les transactions par carte bancaire en e-commerce, une façon originale de souhaiter à ses clients une bonne année 200A ! Je venais donc de créer le bug de l'année 2010. J'avoue ne pas être particulièrement fier de cette invention.
Néanmoins, les conséquences de mon bug sont restées relativement discrètes en France, ce qui n'est pas le cas d'un confrère outre-Rhin qui a bloqué la bagatelle de 20 millions de cartes bancaires allemandes.
Nous sommes en 2018, bientôt en 2019, et depuis ce sinistre jour, chaque changement d'année me procure des sueurs froides. Angoisse infondée selon vous ? Faites une recherche sur internet à propos du bug de l'année 2038
, vous ferez moins les malins…
Auteur : Torlus.
Illustration : Seven segment display gallery, par Oliver Wolters CC
