Le petit Nicolas cause dans Facebook

Ces connards de chez LinkedIn !

Je pèse mes mots. Ils méritent des centaines de baffes. Récemment, j'ai voulu chercher des contacts et j'ai accordé le droit à l'application LinkedIn d'accéder à l'ensemble des contacts de mon iPhone. 

Je concède avoir fait une erreur mais je ne savais pas que tous mes contacts (des milliers à cause des blogs, des listes de diffusion,...) allaient recevoir une invitation. 

Y compris moi, d'ailleurs, sur l'adresse mail de ma boîte, cette de la filiale où je bosse, celle chez Outlook, celle chez Apple, celle correspondant à ma page Google+ et probablement celles de toutes les boîtes que j'ai testées,...

Aujourd'hui, je reçois une demande de mise en contact d'une bonne amie (Ilympe).  Je vais dans l'application et elle en a profité pour envoyer un rappel À TOUS MES CONTACTS. 

Bande de crétins. Dans une entreprise normale, le PDG serait viré pour faute grave. Le directeur informatique serait exécuté sur le champ. 

N.B. : j'ai évidemment viré les autorisations sur mon iPhone à l'instant.  

La qualification des incidents informatiques

Transformation numérique ou pas, n'oublions pas que la validation (l'homologation) des applications est un des principaux aspects des projets informatiques alors que beaucoup ne considère pas cela comme une tâche noble. Les développeurs et les architectes techniques ou ingénieurs systèmes sont égocentriques et dénigrent les autres, notamment les lascars comme moi qui font du transverses et de l'avant projet, et les homologateurs. 

Pourtant, l'homologation est essentielle. Outre le fait que c'est elle qui permet de donner le top à la diffusion d'un logiciel sans dommage pour les utilisateurs donc l'entreprise (elle intéresse beaucoup les dirigeants que le reste...), c'est avec elle qu'on mettra en confrontation les différentes applications du Système d'Information. 

Cela étant, les homogateurs ne sont pas parfaits. Ils appliquent des "procédures systématiques" sans trop comprendre ce qu'ils font. 

Prenons un exemple : les homologateurs de l'Apple Store doivent s'assurer que les applications ne font pas de mal aux gens qui vont la télécharger, donc aux smartphones et à l'image du produit et de la marque. Si vous faites une application pour noter les brasseries parisienne, l'homologation ne saura pas ce qu'est une brasserie et ne connaîtra pas les serveurs informatiques (pas des brasseries...) concernées par votre appli. Il applique son protocole de tests. 

Dans la vraie vie, c'est pareil. Du moins dans l'informatique en entreprise.  Récemment, j'ai eu des problèmes en traitant un incident signalé par un homologateur qui est arrivé dans ma boîte mail par erreur (en principe, j'interviens uniquement dans les cas désespérés). Alors j'ai fait un sondage sur une cinquantaine d'incidents : la plupart sont très mal rédigés et très mal qualifiés. 

Outre son titre, l'incident a trois "atteints essentiels" : 

- sa description,

- sa gravité,

- son urgence. 

Prenons un exemple dans la vraie vraie vie : un type qui doit vérifier si les ascenseur d'un immeuble fonctionne. 

Première bug détecté : l'ascenseur ne s'arrête pas toujours au bon étage. L'incident est gênant mais rigolo. Sa résolution est urgente parce que les utilisateurs vont gueuler. L'homologateur va qualifier l'incident de bloquant (parce que l'ascenseur ne répond pas à ce pour ce qu'il est conçu) mais pas urgent (l'utilisateur peut toujours changer d'étage). Il a tout faux : l'incident n'est pas bloquant (l'utilisateur peut toujours changer d'usage) mais urgent (la société l'ayant installé va se retrouver avec des indemnités à payer). 

La différence entre la gravité (peut-on continuer avec le produit ?) et l'urgence (faut-il une réparation immédiate ?) est très difficile à faire. 

Deuxième exemple : l'homologateur assiste à cent utilisations de l'ascenseur. Au centième, le hasard, l'ascenseur se bloque avec un type dedans. Je vous laisse définir la gravité et l'urgence et vous présente ma réponse : bah ! Ça arrive à tout ascenseur de se bloquer et c'est l'occasion de vérifier que les procédures de sécurité fonctionnent... Donc l'incident n'est pas grave (tout asceur peut tomber en panne) et la résolution n'est pas urgente (pour la même raison). Mais...

Outre le fait qu'un type soit coincé dans le machin et qu'il fait le libérer en urgence (mais nous sommes hors "problématique" de l'homologation), l'homologateur ne peut plus poursuivre ses tests. Pour lui, c'est bloquant. Il ne peut plus faire son boulot. L'homologation est bloquée. 

Troisième urgence : l'ascenseur d'une maison de retraite tombe en panne deux fois par semaine sans que personne ne soit coincé. L'incident est bloquant : l'ascenseur ne remplit pas ses fonctions et les petits vieux ne peuvent pas descendre au réfectoire. Et l'urgence ? Cela dépend si l'établissement a un deuxième ascenseur. Dans ce cas, il n'y pas d'urgence (à part le fait que les réparations coûtent de l'oseille). Par contre, si c'est l'unique ascenseur d'un lycée qui a ce problème. Ce n'est pas bloquant. Les gamins peuvent aller en cours. Par contre, c'est urgent : les PMR (traduire par "handicapés") ne peuvent pas y aller facilement. Ainsi la qualification d'un incident dépend des circonstances. 

C'est un peu ce qui motive mon billet. Un homologateur a signalé un incident comme étant gênant, aujourd'hui, presque fier de lui pour nous mettre en défaut, en ne tenant pas compte des circonstances. Il n'est même pas urgent. Par contre, si on l'avait constaté en septembre, il serait devenu à la fois bloquant (on ne peut pas déployer l'application) et urgent (le blocage nous empêche de passer à la phase suivante du projet). Ainsi, un incident qui peut être qualifié de mineur aujourd'hui (sa correction est simple) et "pas urgent" (on peut attendre septembre) peut changer de statuts au cours du cycle de vie d'une application. 

Mais c'est surtout la façon dont l'homologateur va rédiger son incident qui motive ce billet. 

Changeons de vraie vie. Notre homologateur change de métier et doit vérifier que la température de la bière dans les bistros aux lumières d'un brasseur (mettons Kronembourg). Dans un, il constate que la bière est trop chaude. Notons que l'incident est mineur : il suffit de régler le thermostat (mais pourrait devenir grave si le système de réfrigération est HS). Il est urgent : les clients ne sont pas satisfaits. 

L'homologateur va donc rédiger une fiche d'incident. Vous et moi écriverions : "la bière est trop chaude, ça fait chier". 

L'homologateur écrira :

"Thermomètre introduit dans le verre.

Résultat attendu : entre 4 et 8 degrés.

Résultat obtenu : 9 degrés". 

Le lecteur doit donc relire deux fois pour comprendre que la bière est trop chaude. 

Ne rigolez pas, c'est ainsi. J'ai étudié des dizaines de fiches aujourd'hui pour tester. 

Et en plus, l'homologateur a besoin d'un thermomètre pour savoir si une bière est à la bonne température et n'a pas le droit de consommer le produit. 

Quand Microsoft envoie chier Facebook

Big Data et Digital Washing (et foot et bière)

C’est à reculons que je suis allé à une réunion professionnelle, ce matin. On nous a présenté des statistiques complètes sur le fonctionnement de nos machines. Je connaissais les chiffres mais j’ai eu la surprise de voir que j’étais le seul dans le cas, parmi les collègues. J’ai éclaté de rire quand la personne a expliqué que les travaux ont pu être réalisés grâce au « big data », sujet éminent connu de sa société. Les participants m’ont regardé bizarrement mais je ne pouvais pas leur expliquer la cause de mon hilarité : je tenais un billet de blog au sujet du Digital Washing.

Evoquer le Big Data est du Digital Washing.

Voilà le début de la définition aimablement fournie par Wikipedia : « Les big data, littéralement les « grosses données », ou mégadonnées, parfois appelées données massives, désignent des ensembles de données qui deviennent tellement volumineux qu'ils en deviennent difficiles à travailler avec des outils classiques de gestion de base de données ou de gestion de l'information. »

Je suis d’accord avec cette définition mais la personne qui m’a présenté des statistiques en présentant les technologies comme nouvelles faisait un abus de langage : la preuve, je connaissais les résultats depuis une dizaine d’années. Il se trouve qu’on a des bases de données considérables et qu’on ne sait pas trop quoi rechercher dedans. Quand on commence à se poser la question, on fait du « big data », c’est tout !

Prenez une chaîne d’hypermarchés. Avec les caisses automatiques, ils peuvent savoir, en centralisé, ce qui est vendu en temps réel. Je suppose qu’ils l’utilisent pour prévoir les approvisionnements, faire la gestion des stocks et toutes ces sortes de choses. Par contre, ils sont incapables de les croiser avec la météo, les prévisions météorologiques antérieures et le calendrier des matchs de foot. S’ils le faisaient, ils optimiseraient les approvisionnements en bière et la présentation du rayon correspondant, voire les opérations commerciales qui vont avec.

Ca serait du « big data ».

Mais les patrons savent que cela coûterait beaucoup trop chers et ils ne savent pas par où commencer.

Comme mes lascars avec leurs statistiques qui ont travaillé à l’envers : ils ont analysé les données pour savoir ce qu’ils pouvaient en obtenir sans réfléchir aux besoins. C’est du Digital Washing. Faire n’importe quoi en disant que c’est moderne et numérique.

Digital Washing libéral

Arnaud Dassier est un pro de l’internet et tout ça. C’est lui s’occupait de ce bazar pour Chirac puis pour Sarkozy. Autant dire qu’il n’a pas spécialement ma sympathie. Il a sorti un article, pour Atlantico, à propos du retard de la France dans le numérique. Néanmoins, je suis relativement d’accord avec une partie de ses propos (que je vous invite à lire), notamment parce qu’il dénonce, en introduction, le Digital Washing, c’est-à-dire cette manie qu’on a de brasser de l’air en criant « je fais du numérique. »

Néanmoins, il fait lui-même du Digital Washing par la suite tout en faisant du French Bashing ce qui me pousse à sortir un tas d’anglicismes incompréhensibles dans la même phrase, outre le fait qu’il se livre à un réquisitoire libéral propre à m’énerver.

Pour résumer, il limite numérique aux startups et au haut-débit pour montrer le retard de la France dans ce domaine ce que je ne conteste pas. Par contre, le numérique n’est pas une fin en soi, ni même le nombre de startups : ce qui importe, c’est ce qu’on fait du numérique et comment les entreprises traditionnelles ou nouvelles vont pouvoir créer de l’activité économique (ou ne pas en perdre).

Prenons un exemple au hasard : Amazon. Le numérique est au cœur de cette boîte mais ce n’est pas lui qui fait le chiffre d’affaire, c’est la vente de livres ! Si Amazon était une boite française, l’informatique pourrait être faite à l’autre bout du monde, cela ne changerait pas grand-chose : le chiffre d’affaire serait fait en France. J’ai menti : je n’ai pas pris cet exemple au hasard. Je vais te poser une question, cher lecteur : comment se fait-il qu’en quelques années Amazon soit passé devant la FNAC pour la « vente en ligne des produits culturels » en France alors que les services sont à peu près équivalents ?

Quand tu auras la réponse, tu pourras me la communiquer pour information et te mettre dans le crâne, enfin, que le numérique ne doit pas être réduits aux moyens techniques,  dont les startups et le haut débit.

Pour la FNAC, je ne sais pas. Mais pour de nombreuses entreprises, c’est un problème de culture, d’éloignement des informaticiens des opérationnels et tout ça.

Ne me faites pas dire ce que je n’ai pas dit, à savoir que les startups ne sont pas importantes mais il faut arrêter de me casser les glaouis avec la fiscalité des entrepreneurs, le coût du travail en France et tout ça. La propagande de droite libérale de M. Dassier est en béton mais ne passera pas moi.

Par ailleurs, rappelons que le modèle économie des startups repose sur du vent, à savoir ce que des investisseurs sont prêts à dépenser pour une boite ou pour la "valoriser". Alors que l'économie réelle repose essentiellement sur du chiffre d'affaire : de la vente d'un produit ou d'un service à un client.

Hop