Papgeek et les bugs …

bug-1Aujourd’hui, notre ami Google nous a fait un Doodle* spécial informatique qui célèbre la date anniversaire de Grace Hopper, dont la biographie Wikipédia nous apprend que le terme bug daterait de l’époque où cette personne officiait dans l’informatique de la marine américaine sur des ordinateurs Harvard Mark II et III.

À partir du moment où vous allumez un ordinateur quelconque, un truc qui fonctionne avec des 0 et des 1, donc même un smartphone, votre machine à laver, votre voiture ou votre micro-onde, vous êtes exposés au bug informatique.

Bien entendu, PapGeek a été exposé très jeune au bug informatique. Vous vous souvenez certainement du premier week-end où j’ai commencé à entrer des programmes dans la bécane et que ça retournait un « Syntax error » ? Voilà ! C’étaient les premiers bugs que je rencontrais. Et cela n’a rien à voir avec moi, mes compétences ou ma manière de programmer. À partir du moment où un programmeur, même une pointure, commence à coder (entrer du code = programmer), il s’expose au bug. Il peut être de son fait, du fait d’une bibliothèque de programme qu’il utilise ou de la conception même du programme. Il existe un nombre incalculable de cas d’erreurs. C’est pour cela que l’on a inventé les tests. Le concepteur conçoit, le programmeur programme, et le boulot du testeur consiste à noter les écarts entre ce qu’à demander le concepteur et sa traduction par le programmeur.

Comme j’aimais bien tester toutes sortes de logiciels et qu’il m’arrivait de remonter les problèmes aux développeurs — encore un autre nom pour désigner un barbu à lunettes qui boit du café derrières un écran — j’ai vite pris goût au truc.

Vous pensez bien que PapGeek en a vu des vertes et des pas mûres en terme de bug. Il a même fait partie d’un groupe de musique nommé « Les Bugs »… C’est dire… Marqué à vie… Et ce qui est marrant avec le bug, c’est surtout d’en raconter les histoires quelques années après, car sur le moment c’est rarement la fête. Voici donc un premier bug que j’ai pu rencontrer :

– N°1 des Services en Ligne (1995 – 1998) : j’étais responsable du support technique (Hotline) pour les services en ligne. Nous avions une équipe de développement en interne qui créait les premières applications sur Internet (Larousse en ligne, micro-paiement, …). Nous avions aussi une équipe de localisation (adaptation d’un logiciel d’une langue étrangère vers le français) qui était en charge de traduire et d’adapter le logiciel de connexion à nos services services en ligne à la langue française. C’est à la demande de ce dernier service que je vais créer le premier poste de QA Tester (Testeur Assurance Qualité) dans cette entreprise. Il m’était rattaché au début de l’activité car elle était essentiellement technique. De plus, à cette époque, nous avions la possibilité de créer nous-même nos propres disquettes avec notre logiciel dessus à partir d’un package complet venant des USA.

Une version française de ce logiciel a existé rapidement pour Windows (3.0/3.1 à l’époque). Il y avait aussi une version DOS encore utilisée en 1995 sur certaines configurations.

Malheureusement, sur Macintosh, cela a d’abord été la croix et la bannière pour arriver à obtenir des versions fonctionnant sur cet OS et encore pire quand il fallait en obtenir une version française !

Pourtant à l’époque, les Powerbook d’Apple remportent un grand succès. Et beaucoup de modèles commencent à être vendus avec un modem** interne. La particularité de ce modem interne est qu’il ne comporte que très peu de composants électroniques. Tout est fait par logiciel et la carte elle-même ne sert que d’adaptation entre le réseau téléphonique et l’ordinateur (pour les puristes, je résume, hein… surtout pour Cécile)

Et qui dit logiciel, dit… bug ! Ou pour les geeks : qui dit logiciel, debug !

Après que le service Marketing  — je sais pas lequel, ils sont plein, ils ont des costumes, boivent des cocktails et conduisent des voitures de sport, et au Service Clientèle on prend tous le RER — se soit battu pour obtenir une version française du navigateur pour Macintosh, le Service Commercial se met à envoyer les disquettes aux prospects. Et comme on était content, on faisait des envois massifs. Et là commencent nos ennuis…

Ça démarre par des remontées d’appels à l’assistance technique. Les techniciens de mon équipe avaient une sainte trouille de recevoir des appels d’utilisateurs de Macintosh, qui connaissent assez bien — en ce temps là, car distribution de masse oblige, ce n’est plus toujours le cas aujourd’hui — leur matériel et ses possibilités. La terminologie n’est pas non plus la même que sur PC/Windows et les problèmes qu’ils rencontraient n’étaient pas toujours simples. Par effet de vase communiquant, c’est sur mon poste qu’atterrissaient les cas les plus désespérés.

À force de chercher le problème, on a fini par trouver. Mais entre temps, mot d’ordre avait été donné au service commercial de ne plus envoyer de version française à cause d’un problème non identifié qui empêchait les utilisateurs de pouvoir se connecter. Ce qui pour un logiciel de connexion la fichait vraiment mal. Galère donc, car les clients et prospects savaient que la version existait mais on ne voulait pas leur donner !

De mon passage de près d’un an à Apple Assistance (je vous raconterai après), j’avais gardé quelques contacts et la personne qui s’occupait des tests le logiciel avait aussi quelques contacts développeurs avec Apple.

Après des tests dans tous les sens, se confirme un bug dans notre logiciel. Un truc bête comme chou. Quand le logiciel cause au modem pour ouvrir la connexion — en gros pour lui dire « réveille-toi coco, y’a du boulot » — au lieu d’envoyer un 1 pour le faire, il envoie un 0. Idem pour la fermeture de la connexion. Pour être con, c’est très con comme histoire mais en même temps ça avait l’air plutôt simple à régler. Et la précision sur le bug, l’endroit où il se trouve dans le code, est confirmée plusieurs fois par mon contact chez Apple Europe.

Nous faisons ni une, ni deux avec mon collègue du QA — qui en plus parle plusieurs langues et maitrise parfaitement celle de Barack — nous appelons nos collègues US pour leur décrire le phénomène, expliquons que c’est simple à corriger et qu’on en a archi besoin car on a un build à livrer pour duplication et on ne peut pas le faire avec un soft bugué. Le gars semble dubitatif, demande à ce qu’on fasse la demande officielle par mail, ce qu’on fait asap. Tout ça pour nous dire par retour de mail que les équipes US sont sur un nouveau projet et qu’on peut toujours se mettre notre version autour du coup pour avoir chaud l’hiver, en tous cas, ils ne feront rien pour nous !

Gasssppp ! On a bossé plusieurs semaines jusqu’à pas d’heure avec mon collègue pour trouver le bug, remué ciel et terre pour trouver de l’aide pour qu’on puisse avoir une version clean, et nos propres collègues nous envoient paître gentiment dans nos verts alpages !

Nos deux cerveaux cogitent à 2000 à l’heure (on est jeune et nos neurones fonctionnent plutôt bien) … Nous nous regardons et je lui dis : « Que penses-tu si on faisait notre build nous-même ? » Il me regarde avec des yeux qui pourraient être ahuris s’ils n’avaient déjà le regard brillant du gamin qui sent qu’on lui propose une connerie à faire et qui sait qu’il va dire oui en sautant à pieds joints sur l’occasion !

« Mais on n’a pas les fichiers, on a que le build, comment tu veux faire ? », me dit-il, persuadé que j’ai la solution et que je ne fais que m’amuser avec lui. En fait, au fur et à mesure que l’on discute de ce sujet, mon cerveau fomente un coup d’état en arrière plan (qui a dit que les hommes ne savaient faire qu’un seul truc à la fois ?)

« Je sais bien, mais on connait la séquence de code où se trouve le bug et elle est unique dans le build même compressé. Nous n’avons qu’à rechercher la séquence de code, et remplacer le 0 par un 1 à l’ouverture et un 1 par un 0 à la fermeture de la connexion. Les deux séquences sont identiques à ce chiffre près mais uniques car elles ne reviennent pas ailleurs dans le code. »

« OK, mais avec quoi tu vas faire ça ? » me dit-il… Et là, nous répondons quasi simultanément « ResEdit ! »

Ah, outil magique qui était dans la panoplie obligatoire de tout développeur sur Mac mais aussi du technicien d’assistance, du bidouilleur ou tout simplement du gars intéressé et qui voulait savoir comment ça marchait. ResEdit était un logiciel créé par Apple qui servait au développement mais aussi à la localisation. Un logiciel Macintosh — c’est toujours vrai aujourd’hui mais cela fonctionne autrement et avec d’autres outils — contient ce que l’on appelle des ‘ressources’.

D’ailleurs, si vous avez un Mactintosh sous la main, prenez n’importe quel logiciel qui se trouve dans votre dossier Applications. Faites un clic droit dessus et sélectionnez ‘Afficher le contenu du paquet’. Une fenêtre s’ouvre avec un dossier ‘contents’. Ouvrez-le et vous verrez d’autres dossiers, dont un dossier qui se nomme ‘Resources’. Dedans vous allez trouver des tas d’autres fichiers et dossiers dont certains se terminent par ‘.lproj’ et probablement des fichiers ‘.nib’. Ce sont ces fichiers que l’on utilise aujourd’hui pour localiser les applications dans différentes langues.

Pour schématiser, une ressource est le code du programme lui-même, et les autres ressources vont contenir le menu, les boites de dialogues, les fenêtres, les fichiers d’aide, … Quand quelqu’un crée un logiciel en anglais, il créé tout son environnement avec ResEdit, Menu, fenêtres, etc Pour le localiser, et donc en traduire les menus et boites de dialogues, il suffisait d’ouvrir le logiciel avec ResEdit et ce dernier se chargeait de vous présenter le tout sous forme graphique. Comme Apple avait bien fait les choses dès la conception de son système d’exploitation, les menus et boites de dialogues étaient dynamiques, c’est à dire que si vous remplaciez le menu ‘File’ par son équivalent français ‘Fichier’, le menu s’agrandissait sans rien casser dans l’interface*** C’était même flagrant avec le remplacement de « Save as… » par « Enregistrer sous… »

Nous voilà donc parti à ouvrir ResEdit, ouvrir la ressource représentant le code et à chercher la suite de caractères qui nous intéressait. On change nos 0 et nos 1 comme prévu. On enregistre. Et on essaie…

Et miracle ! Ça marche !

Ce que j’adore avec l’informatique c’est que même quand on est certain de ce que l’on fait et que l’on est persuadé que cela va marcher, on crie au miracle tellement tout ça est aléatoire au possible !

Et nous voilà rendu au vendredi soir 19H où nous avons appelé un coursier pour livrer notre précieux build au dupliqueur qui attendait de nos nouvelles pour lancer la duplication des disquettes et nous livrer au plus vite.

Vous imaginez que le bug c’est juste un 1 à la place d’un 0 au départ ? Et quand vous chiffrez ce que vient de vous coûter l’histoire en temps de résolution et en perte d’abonnés… Mais malheureusement, mon expérience a montré que partout où il y a un enjeu entre le temps de développement et la mise sur le marché du produit (le fameux Time to Market), il y a tension, pression, et forcément bugs à l’arrivée, quelles que soient les compétences des uns et des autres. C’est pour cela qu’une méthode Agile peut être une bonne solution quand on met tous les acteurs dans une même pièce pour travailler d’une manière itérative sur un développement.

Long billet pour un 1 à la place d’un 0. Alors quelques petits bugs en vrac, tous marrants aujourd’hui, moins le jour où ils vous tombent dessus.

Chez un autre N°1 des Services en Ligne (cherchez pas, ils sont tous numéro 1 de quelque chose, c’est la puissance du Marketing Communication qui fait ça) :

– Un développement web conséquent pour un produit phare de la maison (un site d’annonces de rencontres) qui cartonne bien car l’interface (désolé Cécile) qui a été conçue est une vraie tuerie en terme d’ergonomie et facilite la navigation au point où les utilisateurs passent beaucoup de temps sur le service. Qui dit passer du temps sur un endroit où il y a de la publicité, dit facilement monnayable, et donc attractif pour les annonceurs. Donc pépètes sonnantes et trébuchantes.

On l’apprendra plus tard en analysant le problème de ce service, en fait l’ergonomie a été facilité par le fait que l’application allait chercher tous les enregistrements de la base de données à la première connexion. Du coup, tant qu’il n’y avait pas trop de fiches de contacts à lire, l’application s’en sortait bien, allait chercher en une seule fois toutes les infos de la base de données, mettait tout ça en mémoire et laissait l’utilisateur naviguer super facilement puisqu’il n’y avait plus d’accès à la base de données, ce qui ralentit toujours un accès à une information.

Et plus le service avait de succès et moins il fonctionnait correctement. Il avait été changé deux fois d’environnement (serveur web et serveur d’application) et rien n’y faisait. Pendant plusieurs mois avant son arrêt (il allait être remplacé par un produit en marque blanche ), les ingénieurs systèmes en charge de l’exploitation avaient mis en place des redémarrages réguliers afin que les serveurs puissent répondre aux sollicitations des utilisateurs. Bien entendu, plus de mise en avant promotionnelle, plus de pub vendues, et donc un produit qui meurt.

Et pourtant l’idée de départ est très bonne. Mais son implémentation une catastrophe et un cercle vicieux : plus il y avait de fiches de contacts, plus le service était populaire. Plus il était populaire, plus il se remplissait de nouvelles fiches de contacts qui intéressaient toujours plus d’utilisateurs… et plus l’application plantait !

– Un dernier bug pour la route, pour la Coupe du Monde 2006 :

Toujours chez le même N°1,  du temps passé sur ses services cette fois — ruse Marketing pour dire qu’on est numéro 1 de quelque chose et utilisé généralement quand sur le marché vous êtes beaucoup plus loin — on profite de la Coupe du Monde 2006 qui a lieu en Allemagne pour créer tout un service avec toutes les informations sur les joueurs, les terrains, les statistiques, puis le classement. Derrière il y a de la publicité, de l’achat de contenu, de la communication, enfin un gros budget.

Côté conception, projet, développement, il y a aussi du monde. On démarre la mise en ligne du site et dès les premières sollicitations, les serveurs donnent des signes de faiblesse. On va bosser pendant quelques semaines d’arrache-pied pour fiabiliser et stabiliser le tout. Arrivent la compétition, les matchs. La France qui risque à chaque match de poule de se faire éjecter tant on la sent fébrile, à tel point qu’on crie de joie quand on bat le Togo 2-0 ! Après ce sera un festival jusqu’à cette finale déjà perdue avant les tirs au but par un coup de tête malencontreux.

Mais avant d’arriver à la finale, il y a le match pour la troisième place.

Retour à notre beau site sur la coupe du monde qui donne tous les résultats et classements. Il a bien fonctionné jusqu’au samedi soir, jour de la petite finale, le match pour la troisième place.

D’un point de vue programmation, c’est en fait comme s’il y avait deux finales. Une première avec les deux perdants des deux demi-finales et une seconde avec les gagnants des mêmes deux demi-finales.

Déjà, gérer des matchs de poule avec classement, puis des matchs à élimination directe, c’était déjà bien pour un développement web. Mais le dimanche matin du jour de la finale, vers 8h, je me retrouve avec une erreur 500 dans la fenêtre du navigateur. Je me dis alors que la petite finale a eu tellement de succès que la charge occasionnée par le nombre de visites avait eu raison des serveurs.

Appel à mon boss, qui appelle le développeur principal, qui regarde mais ne peut rien faire à distance. Déplacement dans les bureaux avec appel à la sécurité auparavant pour qu’ils puissent le laisser entrer.

Le développeur regarde, trouve le bug, corrige, appel l’exploitation d’astreinte pour mettre en production… et ça marche ! Le site est de nouveau disponible et le restera pendant encore de longues semaines sans causer de soucis.

Que s’est-il donc passé ?

Comme je l’indiquais plus haut, le programme s’attendait à ce qu’après les demi-finales il y ait une finale… et une seule, pas deux ! Le développeur n’avait probablement pas pris en compte, ou mal, le fait qu’il y avait deux finales et quand est arrivée le moment d’afficher le résultat, le programme ne savait pas où donner de la tête, occasionnant une erreur 500 !

Encore ? Allez, un petit dernier pour la route (mais j’en ai des caisses pleines) :

– Sortie du Macintosh Classic (fin 1990), entrée d’Apple dans la distribution grand public dans les années ’90 et début de la énième fin d’Apple (on a toujours prédit la fin d’Apple, surtout la concurrence). Je bosse dans une boutique, revendeur agréé Apple, sur le boulevard Montparnasse. Avec cette machine, Apple sort une imprimante jet d’encre pas cher, la StyleWriter. Configuration destinée aux étudiants, fortunés de préférence vu que le Mac Classic de base est à 9990 Francs (oui c’est avant 2001 et ça fait un peu plus de 1500€) plus l’imprimante dont je ne me souviens plus du prix. Pas cher pour de l’Apple mais la même en marque d’origine pour du PC valait la moitié prix.

Avec cette imprimante sort une nouvelle version de Mac OS (pas X, c’était bien avant. Et ça s’appelait le Système n.n ou n.n était le numéro de version, en l’occurrence, la version Système 6.07) et avec, une technologie permettant d’imprimer des polices de caractères lissées donnant une qualité proche du laser. Les polices ont la même qualité à l’écran qu’à l’impression. Ce sont les polices TrueType qui ont été mises au point par Apple et Microsoft, ce dernier cherchant aussi une solution pour Windows et les deux voulant faire moins cher que les police Adobe type 1 qui valaient une fortune et dont la licence postscript grève beaucoup le coût des imprimantes laser.

À la sortie des machines, tous les logiciels qui étaient développés selon les règles d’Apple fonctionnaient très bien avec ces nouvelle polices de caractères : Mac Write, Mac Paint, FileMaker, PageMaker, XPress, Illustrator, …

Tous… sauf Word et Excel de… Microsoft !

 A+,

PapGeek

* Suite à une demande d’une lectrice, je mettrai des liens sur des termes un peu techniques ou peu communs afin que ma prose reste accessible au grand public 😛

** Non Cécile, rien à voir avec Bayrou

*** Interface a plusieurs significations. Dans le précédent billet, interface était utilisé pour décrire un matériel qui se mettait au milieu de deux autres pour en quelque sorte augmenter les capacités de l’ensemble. Ici, il est utilisé de manière sous-entendu pour parler d’une interface graphique. Le nom interface décrit en fait quelque chose qui se met entre deux milieux différents pour les adapter. Dans le cas de l’interface graphique, c’est une représentation graphique entre l’utilisateur et la machine pour dialoguer avec elle dans un langage imagé. Exemple : quand vous cliquez dans un dossier et que l’ordinateur vous affiche tous les fichiers, ce double-clic se traduit pour une machine Windows par la commande « dir »

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *