L'informaticien con [au bistro !]

Ca faisait quelques temps que je les ai repérés, ces clowns qui fréquentent le même bistro que moi, Le Tourbillon, à La Défense, au comptoir, le soir ou le midi. Je dois avouer que j’y vais pour me couper du monde du travail, je plonge dans mon iPhone en mangeant un sandwich ou un plat du jour, voire une omelette les jours de fête. Alors le processus a duré plus d’un an. J’ai capté quelques mots de phrase et j’ai deviné qu’une grande partie bosse dans l’informatique voire sont consultants, comme je l’ai été pendant vingt ans, donc huit ans, développeur ou chef de projet, comme eux. Cela me faisait rigoler car nous employions le même jargon.

Alors, j’ai fini par repérer les groupes, les boites,… Par exemple, il y en a beaucoup chez Dexia, dont le siège est juste à côté mais je n’y prête une oreille attentive que depuis quelques mois. Je ne le fais pas par curiosité : ils parlent très fort et n’arrêtent pas de gueuler.

Hier midi, mes voisins étaient des « ingénieurs Citrix ». Je connais un peu Citrix mais j’ignorais qu’il y avait des « ingénieurs Citrix ». C’est une boite qui fait un tas de truc dont des applications qui permettent d’utiliser des logiciels installés sur des serveurs comme s’ils étaient sur votre propre poste. C’est très bien, c’est à la mode et 99% des grosses boites utilisent ces machins. Toujours est-il qu’ils ne se rendent même pas compte, qu’en se qualifiant ainsi, ils se dévalorisent. « Moi, je suis ingénieur Citrix. » « Non, toi, connard, tu paramètres des applications et te rend indispensable au fonctionnement de la boîte alors ton patron, pour te faire plaisir, te donne un titre. » Ingénieur Citrix.

Aujourd’hui, j’avais droit à d’autres lascars qui ne comprennent même pas qu’ils passent pour des ânes. L’informaticien est comme ça : il est toujours le meilleur dans son rôle sans même admettre que les autres rôles sont autant voire plus importants que le sien. Tiens ! L’ingénieur Citrix ! Sans lui les applications conçues par d’autres ne fonctionneraient. C’est pourtant assez simple d’admettre que sans les applications des autres, ses compétences Citrix ne serviraient à rien.

S’il est meilleur que tout le monde, il l’est surtout que ses clients, sa hiérarchie, ses commerciaux. Alors, quand il est au bistro, avec ses collègues, il n’arrête pas de ronchonner, de critiquer tout le monde, sauf son collègue. Dans chaque groupe, il y en a un qui parle plus fort que les autres. Du coup, ces derniers sont obligés d’hausser le ton pour en placer une. C’est pour cela que je les ai repérés et je sais même pourquoi je ne les ai pas repéré auparavant : le serveur a changé. Ces lascars ne venaient pas dans mon coin de comptoir.

Comme ils parlent fort, outre le fait que c’est désagréable, on a l’impression qu’ils commencent à être saoul, comme s’ils avaient déjà bu cinq ou six bières, ce moment précis (variable selon les individus) où l’on se rend bien compte qu’on commence à avoir trop bu mais à vouloir résister, faire semblant,…

Alors j’ai vérifié : je me suis pointé, une fois, plus tôt que d’habitude : l’informaticien con et prétentieux parle fort dès qu’il arrive au comptoir, à la première gorgée de bière. Il a des vérités à dire à ses collègues.

Le moment le plus délirant est quand ils commencent à parler de leur propre carrière. Par exemple, l’ingénieur Citrix sait que son boulot est porteur mais ne se rend pas compte qu’il s’enferme dans une technologie. Il faut être franchement taré pour développer ses compétences dans un domaine précis : le gars va poursuivre les missions dans ce domaine, il sera très demandé, bien payé,… et au bout de dix ans, la technologie aura disparu et il n’aura rien vu ! Pire, il aura échappé au marché, un peu comme un développeur web qui aurait loupé le HTML5 pour ses nouvelles applications (je prends cet exemple en connaissance de cause… : dans mes fonctions de maîtrise d’ouvrage, j’ai fait la même bourde).

Alors il est aigri. Les jeunes ne savent pas travailler. Les vieux sont has been. Les autres sont des cons. Si vous travaillez dans l’informatique – mais je suppose que dans les autres secteurs, ce n’est pas très éloigné, vous pouvez regarder autour de vous et observer vos collègues. Les pires sont les consultants et autres prestataires de service. Ils sont persuadés être là pour leurs compétences supérieure mais se refusent à comprendre que ces compétences sont dans un domaine précis pas sur le principe de base du métier…

La conséquence est qu’il est incapable de se remettre en cause. Et c’est la plus grave : l’informaticien est lui-même un frein à la transformation numérique.

Le Digital Washing et le coût des projets informatiques

Il est toujours surprenant d'observer le coût de l'informatique dans les grandes entreprises, que cela soit pour la maintenance évolutive ou les projets. Le « numérique » est bien trop souvent le prétexte à de nouvelles dépenses. Essayons d'en trouver des raisons.

La première : la routine

Les gens « du métier » de l'entreprise expriment des besoins et les informaticiens acceptent. Le métier aurait tort de se priver puisque cela marche, tout comme l'informatique qui justifie son budget ou ses factures si les développements sont externalisés. Alors le guignol comme moi dit : hé ho, on n'a pas de sous pour faire ça, ce n'est pas indispensable et il y a d'autres priorités. Généralement il perd car il est moins nombreux que les autres et ne tient pas à se fâcher avec eux ou à aller voir le grand patron ce qui nécessiterait d'expliquer le truc à un tas d'échelons hiérarchiques. 

C'est ainsi qu'on se retrouve avec un tas de développements informatiques inutiles et des factures incroyables tout en ayant de gros manques dans le système d'information parce que le guignol comme moi n'a pas réussi à imposer son point de vue voire a eu la flemme de le faire.

Je vais donner un gros exemple en le caricaturant volontairement : Moneo, le porte-monnaie électronique développé à la fin des années 90. Les "métiers" dans les différentes banques ont imaginé ce truc et ne se disant que c'est vachement bien. Les informaticiens ont vu un truc génial, nouveaux. Vous ne pouvez pas imaginer le coût de ce truc ! Des dizaines de millions d'euros, voire des centaines !

Moi, le guignol dans le bureau d'à côté, je disais : vous êtes fous. Ca va coûter une fortune, vous feriez mieux de changer le système de paiement par car pour qu'on puisse faire des paiement de petits montant sans saisir de code confidentiel. Ca ne coûterait presque rien au niveau informatique.

L'avenir m'a donné raison. D'ailleurs, quinze ans après, avec l'apparition des cartes sans contact, ils l'ont fait. Quinze ans de retard.

Je répète : mon exemple est caricatural. Mais dans une grande entreprise, ce sont des dizaines ou des centaines de projets de quelques dizaines de milliers d'euros qui qui sont lancés inutilement... Une partie de mon job est déjà les arrêter à temps.

L'autre jour, j'étais en "comité projet". Le chef de projet est un collègue à moi moins expérimenté, ancien informaticien en SSII donc habitué au lancement de projets inutiles parce qu'il gagnait de l'argent avec. Les gens du métier participaient. Un d'entre eux me rappelle que je n'ai pas pris en compte une demande or il avait été décidé que.elle serait étudiée plus tard ce dont il n'avait pas encore été informé. On avait trouvé des prétextes pour retarder la chose mais la demande était tellement conne et inutile qu'on espérait qu'il allait oublier.

Mon collègue, sentant bien une sorte de gêne, mon collègue dit qu'il allait s'en occuper. La réunion se termine. Je vais dans une autre et reviens à mon bureau une heure après. Le gars du métier avait envoyé une copie de sa demande initiale et mon collègue avait organisé une réunion de cadrage. Tous les deux croyaient bien faire. Mon collègue est habitué à accepter les demandes des clients. Il a été payé pour ça pendant des années...

La routine !

La deuxième : la non prise en compte du coût et d'organisation

L'autre jour, un informaticien chez un client me signale un problème potentiel. Je suis d'accord avec lui et soumet le cas au fournisseur du logiciel. Hier, il me fait une proposition de contournement. Je demande au client, l'informaticien et le métier, si la solution proposée est satisfaisante. Le métier me dit « OK ». L'informaticien réponde « si le métier est OK, c'est OK pour moi. » On se retrouve dans la routine ci-dessus. Il rajoute : « La documentation mise à jour en fonction sera livrée quand ? Et on pourra commencer l'homologation du logiciel à quelle date ? »

Ils ont totalement zappé le fait qu'une modification du logiciel avait un coût. Enervé, j'ai répondu sèchement que j'allais demander officiellement le devis au fournisseur, estimer nos charges d'intégration et d'homologation, vous demander d'estimer les vôtres, établir un dossier de deux ou trois pages et le soumettre à la direction puis au Comité de pilotage.

Dans les grandes DSI, ils ont une enveloppe globale pour la maintenance évolutive et ont pris l'habitude de faire les petites évolutions sans se préoccuper du coût.

La troisième : la mauvaise répartition des rôles entre le métier et l'informatique ou la déconsidération du rôle de maîtrise d'ouvrage

Je reprends l'exemple de mon collègue qui lance un dossier que j'avais enterré. Le métier avait commis l'erreur habituelle, celle qui coûte si cher, est d'avoir présenté une expression de besoin informatique et pas une expression de besoin tout court. Revenons à Monéo. Le métier n'a pas dit « on veut un moyen de paiement sans code confidentiel et sans signature pour limiter les manipulations d'espèces et toucher un peu de commissions ». Il a dit : « on veut un porte-monnaie électronique. » Et la technologie sans contact arrivant 15 ans après, il a dit « je veux pouvoir faire un paiement de petit montant sans code et sans signature en mode sans contact ».

Il a mélangé trois problèmes :

• le développement de la puce puis du sans contact
  

• le volet juridique du paiement de petit montant sans code et sans signature,
  
• volet commercial (le coût du service pour le client ou le commerçant).
  

Il n'aurait pas du imposer à l'informatique le moyen. Il aurait fallu une couche intermédiaire pour dégrossir le sujet et la couche intermédiaire aurait dit : « bon ben les gars, si on utilisait les terminaux et les cartes actuelles, hein ? Ca coûterait moins cher, non ? »

La quatrième : l'absence d'avant projet efficace et la précipitation

Tout est dit dans la section précédente. Deux fois la même erreur car on ne se pose pas autour d'une table pour bien décomposer le sujet.

La cinquième : l'excuse du numérique ou le Digital Washing

En quoi consiste la transformation numérique dans cette histoire ? Le sans contact ? Tu parles ! Ca n'est qu'un gadget. La vraie révolution est le paiement par carte sans code et sans signature, autorisé jusque là uniquement pour les autoroutes car les sociétés acceptent de payer en cas de carte volée. Les gens du marketing (le métier) étaient contents. Ils avaient un nouveau service à proposer aux clients et aux commerçants. Les gens de l'informatique étaient contents. Ils ont trouvé de nouveaux trucs à vendre aux banques.

Le paiement sans contact est du Digital Washing.

Monéo est du Digital Washing avant l'heure. Les lascars ont dit : hé ho, c'est génial, on va pouvoir stocker de l'argent dans une carte à puce et payer avec. Mais qu'est-ce qu'on en a à cirer ? Ce qui faut, c'est payer des petits montants avec une carte, j'insiste : sans code. Et accessoirement, ne pas avoir une ligne sur son relevé de compte à chaque fois qu'on prend un café à 30 centimes dans une machine...

La sixième : l'absence de stratégie globale

J'avais déjà fait un billet pour dire qu'une des raisons de l'échec de Monéo et que ces ânes n'avaient négocié avec la mairie de Paris pour que Monéo puisse être utilisé sur les parcmètres dès le lancement des deux projets à la même époque. Mais je suis presque hors sujet.

Si vous trouvez une place de parking libre et que vous n'avez plus de sous dans votre Monéo ou votre carte de stationnement, vous êtes emmerdés. Il faut recharger le Monéo ou acheter une carte. Comment recharger un Monéo si vous n'avez pas de borne de rechargement à côté. Vous êtes coincés.

Je vais donc raconter une anecdote archi confidentielle : les ânes de Monéo n'ont pas pensé que la meilleure borne de rechargement pouvait être un distributeur de billets et ils ont conçu une technologie, pour la puce, incompatible avec celle des distributeurs. Voila pourquoi on ne peut pas recharger (sauf exceptions non conformes, à l'époque, à la réglementation) de Monéo sur les GAB...

Il a fallu investir des sommes incroyables pour le rechargement... alors que le projet était bien sur les rails.

Voila

Je vais donner deux conseils aux chefs d'entreprise.

Le premier : formez bien vos équipes d'informaticiens (les développeurs mais aussi les intégrateurs de solutions externes) à refuser tout projet s'il n'est pas financé et validé par des « instances supérieures ». Quand les banques ont lancé Monéo, les PDG des banques auraient dû se réunir en personne... Mais j'ai bien dit que j'avais pris Monéo pour caricaturer. L'important porte surtout sur les centaines ou milliers de petits développements informatiques qui sont réalisés sans le moindre contrôle.

Le deuxième : mettez en place des équipes dédiées pour ce qui touche à l'évaluation des projets.

Au boulot !

L'informaticien au bistro avec des collègues

Le bistro où je mange tous les midis est en plein centre de La Défense, à une quinzaine de minutes de la Grande Arche. Il y a différents types de clients, au comptoir, notamment des gens comme moi qui n’aiment pas spécialement la cantine. Mais il y a aussi parfois des groupes. Je pensais que c’était des ouvriers ou, du moins, des gens bossant dans le secteur mais n’ayant pas accès à la cantine. Je ne faisais pas attention et j’ai mis plus d’un an avant de me rendre  compte qu’il y avait beaucoup d’informaticiens. Souvent ils viennent le soir, aussi.

Le fait que les informaticiens soient surreprésentés peut s’expliquer, outre par le lieu, par le fait que la sous-traitance est fréquente dans l’informatique et que les sous-traitants n’ont pas accès aux tarifs privilégiés de la cantine.

Si un informaticien reconnait facilement un informaticien, ce n’est pas avec les propos techniques mais avec le jargon employé. Un type qui dit «  il faut que j’envoie le DMP à la DPI » est aisément identifiable par un type qui doit aussi envoyer des Dossiers de Mise en Production à la Direction de la Production Informatique.

Alors, depuis quelques temps, je me mets à écouter les conversations. Dans le blog bistro, j’ai fait récemment un billet parce que des types, à côté de moi, bossaient très certainement pour une boite qui a été mon client. Ils parlaient de gens que je connaissais. Je fais même exprès de me mettre pas trop loin de ceux que j’ai repérés dans l’espoir d’en faire un billet de blog.

Tout d’abord, il est assez de frappant de voir que le jargon utilisé est vraiment à peu près le même. Il y a très peu de propos que je ne comprends pas. Le plus rigolo est que tout le monde fait les mêmes fautes. L’autre jour une collègue : « le fournisseur a livré toutes les anomalies ». Je lui ai répondu : « non, il a livré le logiciel corrigé avec toutes les anomalies corrigées ». Elle a fait un raccourci très fréquent (mais toujours horripilant).

Le midi, quand ils sont ensemble, ils parlent parfois boulot et avec un relatif sérieux, comme s’ils étaient en réunion.

Le soir, ils parlent systématiquement du travail mais uniquement pour dénigrer la hiérarchie, l’entreprise, l’organisation, les clients, les fournisseurs. Et ils sont toujours d’accord entre eux. Il n’y a strictement aucune humilité, aucune remise en cause. C’est le trait commun à tous les informaticiens : ils sont meilleurs que les autres. Si la direction met en place une nouvelle organisation, c’est parce qu’elle fait toujours n’importe quoi. L’informaticien ne se posera que rarement la question : mais n’aurait-elle pas raison ? Ou ne fait-elle pas une réorganisation pour nous obliger à bouger ? Aucune remise en cause (le plus drôle, pour l’avoir vécu plusieurs fois, c’est qu’ils acceptent toujours les réorganisations sans broncher !).

Le pire est que je suis probablement comme eux à ceci près que, dans ma carrière, j’ai toujours eu des longues périodes où je fuyais les collègues le midi et le soir.

En écoutant les informaticiens parler au bistro le soir, on arrive assez facilement à distinguer les bons des mauvais ou, du moins, des peine-à-jouir. Ce sont ceux qui critiquent toujours les technologies utilisées. En fait, ils peuvent être très bons, techniquement, mais vivent dans une autre planète ce qui les empêche de mener normalement des projets. Par exemple, j’ai eu une fois une discussion avec un collègue qui nous reprochait de mettre du Windows sur nos machines et pas Linux ou un truc comme ça. Il peut te tenir la grappe pendant une heure sur le sujet sans prendre en compte l’argument essentiel : nous utilisons des progiciels qui ne fonctionnement que sous Windows. Changer cela coûterait la peau des fesses.

Ils savent tout mieux que tout le monde. Au bistro, on les reconnait facilement : ce sont les plus bavards. Les autres les laissent parler car ils savent qu’il n’y a rien à dire. Tous les informaticiens en ont connu. Au bistro, il y en a presque toujours un dans un groupe.

Cette différence de comportement entre le midi et le soir et, surtout, ce côté très négatif envers les autres, le soir, n’est probablement pas spécifiques aux informaticiens ou à ceux qui gravitent autour mais il est démultiplié par le fait que l’informaticien est généralement dans les services centraux des sociétés et au cœur des processus d’organisation de l’entreprise et ils prennent leur job pour très important.

Récemment, j’ai au bistro à côté de lascars de Rank-Xeros. Ils travaillaient si j’ai bien compris dans la partie du système qui gère la récupération des cartouches d’encre usagées ! Cela existe. On m’aurait demandé ce qu’il y avait dans le système d’information de Xeros France, j’aurais répondu un gros machin qui s’occupe de la partie commerciale, de l’approvisionnement des revendeurs et des clients directs, une partie commerciale pour le commerce par internet, une partie pour la gestion de la maintenance, des interventions des techniciens,… Il faut savoir qu’il y en a une, aussi, pour la collecte des cartouches d’encre. Si j’ai bien compris.

J’avais donc, à côté de moi, une partie ou toute l’équipe en charge de ce machin. Il y avait évidemment un type plus vindicatif que les autres, a priori le chef de l’équipe. A les écouter, Xeros France ne tenait que sur l’informatique en charge de la récupération des cartouches d’encre…  C’était très rigolo !

Toujours est-il que voila une excellente raison de ne pas parler boulot au bistro, même avec des collègues : éviter de passer pour des crétins et se retrouver cités dans un blog.

La programmation orientée objet pour les nuls (et les cheffs)

Cela faisait des années que je n’avais pas entendu parler de ce concept fumeux de « Programmation orientée objet ». C’est l’ami Disp qui l’évoque dans son blog, aujourd’hui.  Amis informaticiens, ne ronchonnez pas ! Je sais que vous utilisez ce truc au quotidien. Je ne dénigre pas les développeurs mais uniquement leurs chefs.

Disp pousse un cri : « La POO n’est pas morte ! »

Néanmoins, je n’oublie pas qu’une partie de mes lecteurs sont des lascars qui ne connaissent rien à la programmation orientée objet. Je vais leur expliquer. Vous connaissez Candy Crush ? A l’écran, on va dire qu’on a des bonbons de différentes couleurs, disons des rouges des bleus, des jaunes et des verts, pour simplifier. Chaque bonbon a des caractéristiques communes : descendre d’un cran s’il n’y a personne en dessous, pouvoir être déplacés d’un cran, occuper la place de celui qui vient prendre sa propre place, être détruit dans certaines conditions (si les voisins sont identiques par exemple). On va dire que chaque bonbon est un objet. Tous les bonbons ont les caractéristiques que je viens de citer. Mais les bonbons de chaque couleur ont des caractéristiques différentes. Les bonbons jaunes rigolent quand on leur caresse les nichons, les rouges chantent la marseillaise en breton, les bleus boivent de la bière quand on a les yeux tournés et les verts racontent des conneries dans leurs blogs. Parmi ses caractéristiques différentes, n’oublions pas l’essentiel : la couleur et le fait qu’ils soient d’une même famille pour être détruits quand ils sont alignés.

Le mec  qui développe, il va définir ce qu’est l’objet bonbon avec les caractéristiques  principales, puis définir les bonbons des quatre couleurs qui « hériteront » des caractéristiques décrites dans les bonbons et avoir les caractéristiques propres. Ainsi, si vous avez trente bonbons à l’écran, le développeur n’a pas… développé trente bonbons mais un seul objet et ses quatre petits frères.

Normalement, à ce stade, vous avez tout compris de la programmation orientée objet. Je vais quand même continuer au cas où vous seriez très con.

Candy Crush est composé d’un certain nombre de tableaux, avec chacun un objectif (dépasser un certain nombre de points, casser toute la glace,…). Les tableaux ont ceci en commun : ils ont une ou plusieurs grilles dans lesquelles on pourra mettre les bonbons. Dans chaque grille, nous avons des cases, à peu près toutes identiques, d’un point de vue du développeur : une case peut contenir un bonbon ou être bouchée par du chocolat. On va donc définir un objet case, avec un attribut : ce qu’elle contient. Soit du chocolat, soit un bonbon. On va ensuite définir l’objet grille, qui sera composé d’un certain nombre de cases, définies sur la base de l’objet case.

Le développeur pourra ainsi se baser sur l’objet « grille » pour définir ses différents tableaux. Et tant qu’à faire vous créez des objets « tableau ».

Voila, c’est tout ! Ou presque, il faudra ajouter quelques milliers d’heures de travail pour faire fonctionner ce qu’un blogueur a écrit avant d’aller au bistro.

J’arrête mes explications. Si vous n’avez rien compris, vous pouvez chercher « programmation orientée objet » dans Google. Si vous n’avez pas de bol, vous tomberez sur le présent billet.

Mise en pratique

Vous allez donc réunir une équipe de développeurs. Celui pour l’objet bonbon, ceux pour chacun des bonbons de couleur, celui pour la case, celui pour la grille, quelques-uns pour les tableaux. Vous êtes le chef : vous pourrez aller boire une bière pendant qu’ils travaillent. Mais avant, il faudra leur dire précisément quoi faire et comment utiliser les objets définis par les autres.

C’est tout con, hein ?,  vu comme ça.

A notons qu’après avoir créé les objets « bonbon », nous pourrions les utiliser pour créer d’autres jeux, comme Jelly Mania qui ressemble à Candy Crush mais avec des yaourts. Il faudrait donc créer un « objet objet » destiné à occuper des cases dans les jeux. Les objets bonbon de Candy Crush et les objets yaourt de Jelly Mania hériteraient de leurs caractéristiques.

Hop !

Et sans objet ?

Imaginions que le dieu de l’informatique n’ait pas inventé la programmation orientée objet et que nous devions développer Candy Crush pour gagner beaucoup de sous pour payer beaucoup de bière. Comment ferions-nous ? Nous ne pourrions pas définir des objets bonbon, des objets bonbon vert, rouge, bleu et jaune, des objets case, des objets grilles et des objet tableau. Nous serions bien emmerdés et resterions à nous caresser les couilles en regardant l’écran.

L’objet est utile. J’espère que j’ai rassuré Disp.

Nous avancerions quand même. Nous n’allons quand même pas programmer chaque bonbon de chaque case de chaque grille indépendamment ! Nous créerions donc un certain nombre de fonctions pour gérer tout ça, ça serait vachement lourd et compliqué.

Mais, au final, nous n’aurions rien fait d’autre que de créer des objets, finalement… Nous aurions des bonbons de différentes couleurs, des grilles,…  Mais ce ne sont pas milliers d’heures que nous y aurions consacré mais des dizaines de milliers.

La programmation orientée objet est donc très utile. C’est une bonne méthode de programmation. Mais ce n’est qu’une méthode de programmation qui se découle en langages de programmation, les plus connus actuellement sont probablement PHP, Java, C++,…

Avec eux, on peut créer facilement des objets bonbon.

De la critique utile de la programmation orientée objet

Tout  d’abord et pour commencer, elle n’est pas adaptée pour tout. Plus précisément, elle n’est pas l’idéale pour tout. L’intérêt est : qui peut le plus peut le moins. Beaucoup de développeurs utilisent des langages dits « objet » mais c’est donner de la confiture aux cochons. Les amateurs de confitures doivent être formés et ça coûte des sous. En fait, dans beaucoup d’applications, les objets sont uniques. Par exemple, si vous faites une version de démonstration de Candy Crush avec un seul tableau, ce n’est pas la peine de créer un objet « tableau » ni même un objet « grille ». Dans le temps, on se passait très bien des objets. Du moins, on en faisait comme Monsieur Jourdain. Il faisait des objets sans le savoir.

Ensuite et pour poursuivre, si elle n’est pas adaptée pour tout, elle induit en erreur parce que des développeurs sobres pourraient dire : « tiens je vais faire de l’objet », or il n’en fait pas. Il fait de l’informatique traditionnelle. Cela génère des bugs et autres dysfonctionnements. C’est mal.

Enfin et pour terminer, il faut faire un peu d’histoire.

Un peu d’histoire

La programmation orientée objet est relativement ancienne (Wikipedia est ton ami) mais elle est devenue à la mode dans les années 80. A mon expérience personnelle, je pourrais dater cela de 86 ou 87. On ne parlait plus que de ça. Les entreprises voulaient découvrir ce qui serait la programmation du futur.

C’était très rigolo car nous avions des gens avec de cravates et du poil dans les oreilles, généralement on appelle ça des directeurs et des consultants, qui parlaient objet sans absolument savoir de quoi ils parlaient, confondant une méthode de programmation avec une méthode d’analyse. C’est dommage, Candy Crush n’existait pas à l’époque, mais ils faisaient très sérieusement ce que je faisais en déconnant ! Oui ! C’est génial, on va créer un objet bonbon, puis un bonbon vert et un bonbon rouge. Ou un yaourt, je ne sais plus, n’essayez pas de m’embrouiller.

Ils ne savaient absolument pas de quoi je parlais. Je suis prêt à parier, d’ailleurs, qu’une partie des développeurs qui font des objets aujourd’hui ne savent même pas quelles sont les conséquences : allocation de mémoire et tout ça.

Dans les années suivantes, ils ont obligé leurs équipe à faire de la programmation orientée objet mais en insistant sur l’aspect « objet » parce que ça fait bien, pas sur le langage de programmation lui-même, vous savez, le truc qui permet d’écrire « class bonbon » pour créer l’objet bonbon. Ces valeureuses équipes se sont retrouvées à réécrire leurs logiciels en remplaçant les fonctions par des classes parce qu’ils ne savaient pas quoi faire d’autres, leur chef leur a dit de faire des objets. Je n’abuse pas, y compris parmi les paradoxes du présent paragraphe. C’était un bordel monstre.

Je pourrais vous raconter quelques anecdotes mais ce billet est trop long, d’autant qu’à peu près à la même époque, il y a eu une autre révolution : la généralisation de Windows. Passant d’un environnement « mono tâche » en MS-DOS, les boites se sont trouvées à passés à Windows et en ont profité pour faire le passage à l’objet (ce qui était une bonne idée) dans un joyeux bordel, sans penser réellement à l’avenir de leurs applications…

Mais pendant toutes cette phase, les « maîtrises d’ouvrage » (la partie des informaticiens qui ne font pas d’informatique mais font la relation entre les utilisateurs et les développeurs) ne sont pas restés à glander. Ils ont voulu créer « la conception orientée objet » et tout est parti en couilles.

Mais c’est une autre histoire.

Comment j'ai appris l'informatique dans les années 80

Alors qu’on parle de l’enseignement de la programmation en primaire, je me rappelle de mes cours d’informatique, quand j’étais étudiant, de septembre 84 à juin 87, en gros. C’était à une autre époque. Les écoles avaient du mal à trouver des profs compétents et on avait très peu de matériel. La première année d’IUT, on n’avait qu’un « Mini 6 » de Bull, c’est vous dire !

Travailler ainsi était une galère et la plupart des étudiants n’avaient jamais réussi à compiler un programme. On travaillait par binôme, ce qui était une aberration. Le type qui bossait avec moi s’en foutait et récupérait des bonnes notes.

J’avais appris la programmation bien avant de rentrer à l’IUT, à 13 ans, si ma mémoire est bonne. Je « parlais » couramment le Basic et je me débrouillais un peu dans les machins de l’éducation nationale.

A l’IUT, j’ai appris le Pascal, ce qui m’a bien rendu service ensuite, et le Fortran, ce qui était complètement con. Après l’IUT, j’ai fait une école privée d’informatique, destinée à la reconversion des chômeurs. J’avais choisi ce machin parce que c’était rémunéré… et parce que j’étais refusé dans toutes les formations en informatique du genre Miage, n’ayant pas le niveau. A posteriori, ceci est très drôle vu que j’étais quasiment le seul de l’IUT à savoir réellement programmer en sortant. Près de trente ans plus tard, c’est encore plus drôle vu que je suis probablement le seul à avoir fait une belle carrière dans l’informatique.

Ce qui me fait dire, d’ailleurs, que l’enseignement de l’informatique est largement merdique en France, ou, du moins, l’était à cette époque. D’ailleurs, en 1987, j’avais intégré une SSII. Beaucoup de mes collègues avaient une formation qui n’avait rien à voir avec l’informatique. Ceux qui avait un DUT informatique étaient réellement nuls ou, du moins, avaient un très mauvais esprit : ils s’imaginaient meilleurs que tout le monde. Ceux qui avaient une vraie formation informatique voire un diplôme d’ingénieur dans une matière proche avaient tellement les dents longues qu’ils ont probablement fini sous-chef de service dans une entreprise à la con.

Toujours est-il que dans cette école privée, j’ai appris le COBOL. Je l’ai un peu pratiqué de manière professionnelle pendant les six mois après le stage et, surtout, cela m’a aidé pendant ma carrière parce que je pouvais comprendre ce que faisaient les informaticiens du « back office ». D’ailleurs, près de 30 ans après, c’est moi qui fais les relations entre le back et le front dans la boite.

Dans ces années, le Pascal était à la mode. C’est un langage qui avait été créé pour l’éducation et certaines entreprises informatiques en avaient fait leur langage de développement, pensant qu’il serait l’avenir (C a pris la place et a du de nombreux descendants). Je l’ai beaucoup utilisé pour le boulot entre 1988 et 1993. Turbo Pascal avait révolutionné le monde de la programmation et c’était délirant de voir qu’à l’IUT nous avions encore des vieux compilateurs pourris…

Reprenons. J’ai fait un DUT de Statistiques. L’informatique n’était pas la matière principale mais y avait une place de choix après les statistiques, les probabilités et les maths, au même niveau que l’économie. Ensuite, j’ai fait un an d’école d’analyste fonctionnel. Si ! Ca existe. La programmation n’était pas au cœur de la formation.

Cette école était totalement bidon : elle touchait des subventions de l’Etat pour réorienter la formation de chômeurs (ce que je n’étais pas réellement). C’était de l’escroquerie sauf pour ce qui concerne la matière principale : l’analyse fonctionnelle pour laquelle le prof était réellement bon mais, à part moi qui voulait réellement apprendre, n’avait pas le bon public. J’ai d’ailleurs beaucoup appris, ne serait-ce qu’au niveau de la rigueur nécessaire à l’analyse pour tenter de couvrir l’exhaustivité des traitements. Le prof de comptabilité analytique était un abruti, un étudiant qui faisait des vacations et que les autres adulaient pour des raisons qui m’échappaient, jusqu’au jour où je l’ai cassé en cours, en lui démontrant les erreurs qu’il commettait. Je me demande pourquoi on avait des cours de comptabilité analytique dans cette formation et je mentionne cela à titre d’exemple.

L’enseignement de l’informatique était ainsi fait. Les écoles faisaient n’importe quoi. Elles recevaient de l’Etat la mission de former des jeunes à la programmation et trouvaient des professeurs vacataires sans pouvoir vérifier leurs compétences tant au niveau de l’informatique que de la pédagogie. A l’IUT, le premier prof d’informatique qu’on a eu était le prof de probabilité qui avait vaguement appris la programmation pendant ses heures de loisir. Il pratiquait un enseignement purement théorique (on rendait les « devoirs » sur papier…) et n’avait aucune idée de ce qu’était l’utilisation de ce bordel dans un environnement professionnel. Le second était plus efficace car beaucoup plus jeune, beaucoup plus branché informatique et comprenant de quoi il parlait. Il n’empêche qu’il avait été recruté par petites annonces. C’était un ancien élève de l’IUT qui tenait maintenant l’hôtel de sa mère et avait développé en Pascal les programmes nécessaires à sa gestion. Voila pour son CV.

Voila pourquoi je suis circonspect quand je vois que le ministère a consulté les associations en juin pour développer l’enseignement du « code informatique » en primaire à la rentrée… Même 30 ans après.

L'informatique à l'école

Benoît Hamon a annoncé différentes mesures pour l'informatique à l'école, comme l'apprentissage du code informatique à l'école, et je l'évoque dans mon billet politique du jour. J'y suis opposé. René Paul Henri me qualifie de « rétrograde » et Suzanne vient un peu à mon secours en rappelant des échecs de différents plans et en insistant sur le fait qu'il faille d'abord éduquer les enfants à l'apprentissage de l'outil informatique, en commençant par la dactylo.

J'aurais pu leur répondre longuement dans les commentaires mais quand on a l'occasion de faire un billet de blog, on s'y jette !

Tout d'abord, une des erreurs qui sont faites par la plupart des adultes y compris le personnel politique est de se baser sur ses propres connaissances pour définir ce qu'est l'informatique, voire le métier d'informaticien que l'on qualifie comme le métier d'avenir, celui qui permettra à la France de s'en sortir... et comme ce qui semble le plus évident dans ce métier est « la programmation », on en vient à des âneries comme la nécessité d'apprendre « le code informatique » à l'école.

Je le remarque également à mon boulot, alors que je bosse au sein d'une DSI, au sein de personnes parfaitement compétentes mais souvent incapables de voir au delà des technologies qu'ils connaissent, de ce qu'ils ont appris, du travail qu'ils ont à mettre en œuvre. J'ai déjà raconté cette anecdote : vers 2004, je suis arrivé dans un service où une personne était en charge des statistiques. Il recevait des paquets de listing et passait environ trois semaines à en faire des récapitulatifs. J'ai envoyé un mail à la personne qui produisait les listings. Je lui ai demandé s'il pouvait me les envoyer sous forme de fichiers informatiques. Elle l'a fait. J'ai incorporé les fichiers dans Excel et le temps de me lancer, en quelques mois, je faisais le même boulot que mon collègue en cinquante minutes. En changeant les outils, j'avais divisé environ par 100 un temps de traitement. Pour des aspects sociaux, on n'avait pas dit à mon collègue qu'il ne servait plus à rien, on avait donc continué à lui faire sortir les statistiques officielles, celles présentées au conseil de direction, mais on avait commencé à utiliser les miennes pour améliorer le fonctionnement de nos systèmes.

Après quelques temps, j'avais été voir le directeur. Je lui avais dit : « dis donc, ça commence à me casser les burnes, de perdre 50 minutes par mois à croiser des chiffres dans Excel, tu ne pourrais pas me prendre un stagiaire pendant deux ou trois mois pour développer des macros pour automatiser tout ça ? » Je me suis alors rendu compte de deux choses : la première est qu'il ne savait pas qu'on puisse faire des macros dans Excel (tiens, si tu ne sais pas non plus, je vais t'expliquer : dans Excel on peut faire des programmes informatiques, du code, comme on dit, pour automatiser des traitements), la deuxième est qu'il ne pouvait pas imaginer qu'un lascar comme moi qui connaissais assez bien Excel ne pouvait pas le connaître au point de ne pas savoir faire de la programmation avec.

Je vais raconter une deuxième anecdote. Nos logiciels sont installés en France mais aussi dans des patelins comme Monaco où nous avons des filiales. Monaco n'est pas la France. C'est un autre pays. En informatique, les pays sont identifiés par des « codes pays ». Récemment, un jeune collègue avec 7 ou 8 ans d'expérience vient me demander où il pouvait trouver le code pays de Monaco, à qui il pouvait demander,... En fait, il espérait probablement que je le connaisse par cœur, ce qui n'est pas le cas. J'ai pris mon navigateur, j'ai tourné mon écran vers lui et je lui ai dit « regarde comment on fait des recherches pour le travail ». J'ai lancé Google, j'ai tapé « code pays iso monaco » et la réponse est arrivée en trois secondes (le temps de voir où Google l'avait affichée).

Ce type, par ailleurs, ingénieur en informatique, n'avait pas pensé à utilisé Google pour avoir une réponse dans le cadre professionnel.

Pourquoi je vous raconte toutes ces histoires ? Parce que l'on voit que des professionnels de l'informatique (un vieux développeur, un directeur de service, un jeune ingénieur,... et je pourrais multiplier) n'ont pas l'esprit assez ouvert pour imaginer ce que l'on pourrait faire de ce bazar...

Or, ce sont à peu près les mêmes qui font des programmes scolaires et qui vont développer des plans pour permettre à des gamins d'apprendre l'informatique, le tout enseigné par des gens qui n'ont pas les compétences (ce n'est pas une critique, on ne peut pas être bon partout),... Après échec, le tout sera moqué par des lascars qui se croient plus intelligents que tout le monde, sur le mode : « ah ah ah, le plan informatique pour tous ! ».

Pour apprendre à taper sur un clavier, il faut un prof de dactylo, pas un prof d'informatique, pas un instit. Pour apprendre à taper un texte cohérent, il faut un prof de français, pas un prof de sciences doué pour l'informatique. Pour décider quelles technologies enseigner à l'école, il ne faut pas un lascar qui reproduise ce qu'il a lui même appris quand il était en fac.

Il y a cinq ans, est-ce qu'une personne dans les ministères aurait pensé qu'il allait falloir apprendre aux gamins à utiliser des tablettes, parce que ça allait exploser dans les années suivantes ? Je parlais d'apprendre la dactylo et vous avez applaudi bêtement tant cela paraît évident que pour bien utiliser un ordinateur, autant savoir utiliser correctement un clavier, ce qui évite de se concentrer sur la position des touches quand on travaille... Mais c'est complètement con ! Les claviers des tablettes sont tellement merdiques que l'on finira par écrire directement sur l'écran avec un stylet, voir sur un papier avec un crayon et qu'on numérisera le tout ensuite...

Et l'on voudrait décider dans les ministères ce pourquoi il faudrait former des enseignants pour qu'ils donnent des leçons aux gamins pour des trucs de nouvelles technologies qui seront dépassées au moment de leur mise en pratique ? Déjà, dans les écoles d'informatiques, ils sont nécessairement dépassés par la vitesse d'évolution de ces machins (trouvez moi un prof qui ait déjà développé une vraie web application pour smartphone en HTML5...), les écoles primaires devraient être au top ?

Restons calmes...

Ce pays où les professionnels de l'informatique grand public sont des nuls...

En France, les professionnels de l'informatique grand public sont des ânes. Parole de professionnel d'informatique grand public utilisée par des braves gens qui mettent une carte dans un machin pour obtenir du liquide sans savoir que c'est de l'informatique qui gère tout ce bazar...

Trois exemples, liés au PC de ma mère.

Premier exemple – les vendeurs de grandes surfaces

Je racontais récemment un problème qu'elle avait : son téléphone, branché sur la Livebox, ne sonnait plus. C'est arrivé deux ou trois jours après un de mes passages en Bretagne et elle ne pouvait pas attendre le suivant. Elle a fait ce qu'elle pouvait faire : redémarrer la livebox et vérifier la câblage puis changer le téléphone au cas où le problème vienne de lui. Rien à faire.

Elle va donc interroger le vendeur de l'hypermarché qui ne sait rien lui dire sauf que ça ne pouvait pas venir de la Livebox. Il en était sûr.

Pas de bol, ça venait de la Livebox. Tous les indices étaient là. Je ne suis pas professionnel de la téléphonie mais en quelques réflexions, j'en étais arrivé à la conclusion que seule elle était en cause. Et j'avais raison. Comment un type dont c'est le métier peut-il faire une aussi grossière erreur ?

C'est d'autant plus con que, au mieux, il pouvait en vendre une nouvelle... On sait maintenant qu'il est incompétent.

Deuxième exemple – les petites boutiques

Il y a quelques mois, le PC de ma mère ne fonctionnait plus très bien. Elle l'amène dans une petite boite spécialisée, sur ma recommandation (à vue de nez son disque dur avait pris une claque ou un gros méchant virus). Ils font un premier diagnostic : quelle que soit l'origine de la panne, il fallait bien réinitialiser le disque dur. Ils disent donc à ma mère : dites nous quels logiciels vous utilisez pour que nous puissions les réinstaller sachant que la version de Microsoft Office que vous avez nous est inconnue. Ma mère m'appelle pour me demander. Je lui réponds qu'elle n'utilise pas Microsoft Office mais Open Office. Je lui fais noter devant moi, elle s'applique et tout ça pour ne pas faire d'erreur.

Elle va les voir. Ils ne connaissaient pas Open Office. Des professionnels...

Périodiquement, depuis, elle me dit : « tiens ! Tel ou tel truc ne fonctionne pas. » J'arrive, je regarde, je remets en place. La première fois, il manquait Open Office... Je l'ai donc installé... La fois suivante, elle me dit qu'elle n'arrive pas à ouvrir les PPT. C'est logique, le logiciel par défaut était toujours Power Point...

Je me pointe cette fois-ci, elle me dit : tu installeras Adobe, ça ne marche plus. Je dis : quoi ? Je vais sur son PC, ouvre un PDF, tout va bien. Finalement, elle me montre un truc qui ne marche pas : il manquait « Flash » sur son navigateur. Ces imbéciles de réparateurs avaient oublié de mettre Flash en réinstallant un PC...

Troisième exemple – les grosses boites

Avec son problème de téléphone qui ne sonne plus, je suis allé voir l'assistance Orange.

Je suis donc allé dans l'espace client. Il y a un onglet « Urgences et dépannage ». Là, on ne trouve rien pour l'assistance. Il faut cliquer sur « mes outils d'autodiagnostic »... Puis sur « accéder à mes outils ». Admettez qu'il faut le savoir ! Là, il y a un tas de truc... Dont « Un incident sur votre ligne ». On ne peut pas cliquer mais il y a un truc, en dessous, dans le même pavé. « Testez votre ligne ». On clique. Un deuxième onglet s'ouvre : « Un problème avec votre connexion Internet, le téléphone Livebox (téléphone par internet) ou votre TV d'Orange ? » Vous commencez à vous dire que vous êtes sur la bonne voie. Vous avez tort, ça ne débouche sur rien. Vous serez invité à tester, vous allez vous rendre compte que ce n'est pas le bon chemin.

Vous fermez donc le nouvel onglet et vous relisez toutes les options que si vous sont offertes. Vous voyez alors : « Besoin d’aide pour établir le diagnostic? » Heu... Oui, j'ai besoin d'aide... Vous ne pouvez pas cliquer mais, en dessous, il y a « Consultez l'assistance guidée ».

Est-ce que les crânes d’œuf de notre grand opérateur national ne pourraient-ils pas s'imaginer que si un client va dans l'assistance, c'est justement parce qu'il veut consulter l'assistance ? C'est quand même totalement délirant de devoir passer par tout ça ! En fait, c'est quasiment introuvable.

La première fois, je suis tombé dessus par hasard. Une fois que j'ai réparé la livebox, j'ai voulu y retourner en utilisant les menus de façon normale. J'y ai passé plus d'un quart d'heure. Pour préparer ce billet : plus de vingt minutes...

Après, ça va mieux ! Le diagnostic de la panne est ultra rapide. Une fenêtre s'ouvre.

Premier écran : « Sélectionnez l'objet de votre recherche : connexion internet (Wi-Fi, Ethernet, Clé 3G+, navigation...) - TV d'Orange - ligne Livebox - messagerie Orange et logiciels de messagerie - services internet (Anti-virus firewall, Contrôle Parental) » Comme le téléphone n'est pas mentionné (c'est un comble!), vous cliquez sur « ligne Livebox » par hasard (et vous avez raison mais vous ne le savez qu'après, déjà que vous avez perdu un temps monstre).

Nouvelle page : « Pour votre ligne Livebox, votre demande porte sur : aucune émission et réception d'appel - aucune émission d'appel - aucune réception d'appel - une mauvaise qualité des communications ou des coupures fréquentes » ! Magnifique ! Enfin on parle de vous : aucune réception d'appel ! Vous voilà enfin confirmé sur la bonne voie. Vous cliquez.

Une nouvelle page : « Pouvez-vous émettre des appels ? Oui - non ». Grandiose ! Vous avez enfin réussi à décrire votre problème : vous ne recevez pas d'appel mais vous pouvez en émettre. Vous cliquez sur Oui. Vous êtes alors invité à indiquer votre modèle de Livebox.

Une nouvelle page. Vous n'y comprenez plus rien. En première ligne, c'est indiqué : « remettre à zéro votre Livebox mini ». Ils ont fait le diagnostic mais plutôt que vous dire « Il vous faut réinitialiser votre livebox pour réparer votre ligne, voulez vous accéder à l'assistance correspondante ? », ils vous envoient directement dans l'assistance pour cette fonction. Vous ne savez pas ce que vous foutez là !

Pire ! Cette page commence par un tas d'avertissements qui vous foutent les boules alors que la seule consigne à donner devrait être : munissez vous de votre identifiant tel qu'il a été fournir par Orange lors de l'ouverture de votre ligne.

Si vous n'êtes pas découragé, vous déroulez la fenêtre et vous tombez sur un mode d'emploi très précis avec des illustrations, … Vous y allez donc franchement. Sauf qu'il y a une légère erreur. Ils oublient de vous dire, à un moment, qu'il faut patienter près de cinq minutes. Vous n'arrivez pas à poursuivre. Un type qui s'impatienterait foutrait tout en l'air... et j'ai failli le faire.

Finalement, ça se décoince ! Mais un type qui ne sait pas qu'il y a une interface d'administration de la livebox et comment y accéder sera foutu. Et si l'adresse IP correspondante n'avait pas été mémorisée dans mon PC, j'aurais perdu toute chance de pouvoir réparer ce bordel.

Troisième exemple – les grosses boites – je résume

Petit 1 : vous perdez des heures dans l'assistance de Orange.fr avant de pouvoir dire que vous avez besoin d'assistance.

Petit 2 : une fois que vous avez trouvé, tout cela va très vite pour vous donner le diagnostic et surtout ce qu'il faut faire pour réparer.

Petit 3 : le mode d'emploi des opérations à faire est bon à un détail près mais pourrait vous poussez à faire des conneries.

Petit 4 : c'est stupéfiant de voir que ces andouilles d'informaticiens et de spécialistes du marketing soient capables de vous dire quelles tâches faire sans pouvoir les lancer automatiquement...

Petit 5 : c'est stupéfiant d'obliger un type à réinitialiser une Livebox quand il vous dit qu'il ne reçoit pas les appels, tellement il devrait être évident que c'est un incident de configuration du logiciel qui pourrait être réparé automatiquement.

Imaginez que je fasse les mêmes conneries dans mon boulot... Je vous l'ai dit : je bosse dans l'informatique des machine qui distribuent du pognon. Imaginez que suite à un bug informatique connu ; je laisse du personnel de mon entreprise perdre du temps à faire des bêtises pour remettre le système en marche parce que c'est le personnel de mon entreprise qui est « mon client ». Je serais licencié sur le champ !

Reprenons les exemples :

Le premier : le type de l'hypermarché n'aurait pas du raconter une connerie à ma mère. Il aurait du dire : « désolé, Madame, je ne sais pas. Essayez d'appeler le service client d'Orange, ils vous diront quoi faire même si c'est parfois très long. »

Le deuxième : les types du réparateur ont merdé. Ils ont perdu un client qui aurait pu être sérieux. Le prochain équipement informatique ne sera pas acheté chez eux. Ils continueront à faire des réparations de merde jusqu'à ce que l'hypermarché offre le même service... Et ils couleront.

Le premier troisième : les types qui font le service web orange.fr devraient s'interroger sur les besoins du client. J'espère pour eux que le bigboss ne tombera pas sur ce blog. Il apporte la preuve qu'ils dépensent un tas de pognon à faire des truc sans intérêt en oubliant une des deux fonctions principales : l'assistance au client (la deuxième étant le commercial et le marketing).

Le deuxième troisième : les types qui font les logiciels chez Orange devraient penser à éviter de faire perdre du temps aux clients. J'espère pour eux le bigboss ne tombera pas sur ce blog. Il apporte la preuve que le fait que les clients puissent recevoir leurs appels sans s'emmerder dans des problèmes de configuration n'est pas une priorité pour eux.

Il y a des licenciements qui se perdent.

Un jour, des industriels étrangers vont venir sur ces marchés typiquement locaux. Et on l'aura dans l'os. Dans l'iOS, même...

Le SaaS (vu du bistro)

Ma copine Fiso est formatrice sur des logiciels destinés au monde professionnel. Son dernier employeur est un éditeur d’offres SaaS. Elle découvre ce domaine et en fait un billet qui m’a passionné puisque c’est typiquement un truc qui est au fond de ce blog : les grandes évolutions de l’informatique. En fait, c’est elle qui est passionnée. J’ai lu son billet une première fois ce matin puis une deuxième fois cette après-midi. J’ai googlelisé SaaS pour vérifier. Ca correspond exactement à ce qu’elle explique ce qui prouve soit que je suis très intelligent soit qu’elle explique très bien et que c’est une excellente formatrice !

Mais toi, cher lecteur, tu te demandes ce qu’est ce bordel, le SaaS. Ca veut dire « Software as a Service », c'est-à-dire « logiciel comme un service ». « L’éditeur » (appelons-le comme ça) ne vend plus de logiciels à un client mais un service complet avec l’hébergement des applications et des données sur ses propres serveurs. L’utilisateur, le salarié du client, se connecte alors via internet.

Dans le grand public, c’est un truc bien connu. Les utilisateurs de Google Docs (qui s’appelle maintenant Google Drive) le savent bien. Ils n’achètent plus de traitement de texte, de tableurs, … Ils se connectent à Google qui offre tout en ligne, y compris la gestion des documents.

Je cite Google mais Microsoft a exactement les mêmes services sous le délicieux nom de Office365. Microsoft préfère néanmoins continuer à vendre des licences… En outre, les entreprises n’ont pas nécessairement confiance dans ces boites et au fait de laisser les employer y mettre leurs fichiers (je ne vais pas parler des avantages et inconvénients du SaaS, vous pouvez lire le billet de Fiso et les longs commentaires que j’ai laissés et vous pouvez lire la fiche Wikipedia).

Google dispose également de services pour les professionnels : Google Apps, avec une messagerie, un agenda et des logiciels bureautiques. Ils sont passés dans un mode payant cette année, sans doute ont-ils jugé que le marché était suffisamment mur et allait se développer.

Quoi de neuf avec Fiso ?

Elle bosse dans une boite qui fait des logiciels qui ne sont pas grands publics ou de type bureautique mais spécifiques à des métiers.

Prenons un exemple au hasard : les bistros, des entreprises entre un travailleur et une dizaine (à plus, ce n’est plus vraiment un bistro…). Dans son logement, le patron a un bureau avec un ordinateur d’où il va voir des films de culs sur internet pendant que sa femme tient le comptoir mais ça n’a rien à voir avec le sujet du billet.

Une fois par jour, il va classer ses factures, les payés, noter la recette. Tout cela n’est pas simple, il faut trier les tickets restaurants et faire plein de trucs comme ça. Il finit par enregistrer le tout dans son logiciel de comptabilité. Périodiquement, il va faire des sauvegardes et transmettre ça à son comptable, par mail, par internet,…

On imagine que tout reviendrait au même s’il se connectait par internet sur un serveur et saisissait les données. Ca serait même plus simple car son comptable pourrait récupérer les informations dont il a besoin, voire faire directement tous les traitements nécessaires avec ce serveur.

Jusque là, pas grand-chose de neuf. Je suppose d’ailleurs que les solutions informatiques existent de longue date. La comptabilité d’un bistro n’a en outre rien de spécifique à un bistro.

Dans le bistro, tous les matins, le gars qui fait l’ouverture ouvre la caisse, y verse un fond (la monnaie pour commencer la journée et note ce qu’il fait. Le soir, un autre employé fait la caisse et note ce qu’il fait. Ca serait quand même plus simple s’ils saisissaient directement les informations dans un logiciel à partir du PC du bistro (celui qui sert à diffuser de la musique avec iTunes) voire sur son propre smartphone (ou la tablette du bistro, celle qui sert aussi à diffuser de la musique).

Un « éditeur SaaS » pourrait donc proposer un tel service. En plus de son application de comptabilité, il développe cette application dont ont besoin les bistros, l’héberge et vend ses services.

Voilà ce qu’est le SaaS pour les entreprises : un logiciel spécifique a une activité ou un métier mais que la société (le client) n’a pas à gérer et qui est accessible par internet. Pas de serveur à gérer, de sauvegarde à faire, de matériel spécifique à acquérir. Le bonheur.

J’ai pris un exemple au hasard mais on peut multiplier les activités. Tiens ! Le type qui fait la cave, l’après midi, pourrait saisir le stock ou les commandes à passer plutôt que de les noter sur un bout de papier et de téléphoner au fournisseur.

Prenons un autre exemple

Tiens ! Les bistros. Les bistros modernes ont maintenant une informatique qui leur est propre pour gérer les commandes des clients. Les clients les saisissent sur un ordinateur, un ticket s’imprime en cuisine pour les plats à préparer et un autre au comptoir pour les boissons à préparer. Le tout gère les commandes par table pour pouvoir taper la commande finale, voire répartir le montant entre les convives s’ils ont des notes de frais.

Le bistro doit dont avoir un serveur informatique qui servira notamment à gérer les tarifs et la comptabilité par loufiat, des périphériques portables pour les loufiats ou une machine spécifique centralisée avec écran tactile, un périphérique tactile au comptoir et des imprimantes.

Imaginez que le serveur tombe en panne au milieu du service (ou les périphériques).

Tout cela pourrait très bien être remplacé par des smartphones et des tablettes connectées en wifi et GSM à un serveur quelque part. Le patron n’aurait pas à se faire chier avec du matériel spécifique et ne serait plus emmerdé par les pannes. Le wifi est cassé ! Paf ! Il passe par le GSM. Les deux sont cassés : pas de bol. Ils prennent les commandes à la main…

Mon premier exemple n’était pas spécifique aux bistros : tout le monde fait de la comptabilité. Ici, c’est à peu près spécifique. J’ai pris un exemple que tout le monde peut voir mais imaginez ça étendu à chaque corps de métier.

Et alors ?

Rien ! Je disais en passant. Dans notre univers de geeks, tout cela est évident mais parlez en à un patron de bistro.

Mon exemple montre une limite du SaaS : les applications ne sont pas toutes hébergées sur des serveurs, certaines sont sur les périphériques mobiles (imaginez le loufiat en train de  prendre une commande sur un site internet ouvert dans Safari…). Le SaaS doit être étendu à ces applications installées sur mobile (ce qui ne change pas grand-chose).

Fiso aborde un sujet important : la taille des entreprises. Autant qu’il est évident que la grande entreprise peut développer ses propres applications ou en acheter puis les héberger, autant pour une petite, ce n’est pas évident, d’autant qu’elle n’aura pas d’informaticien chargé de voir ce que propose le marché. Par contre, elle pense que les grosses entreprises peuvent être intéressées également. Bizarrement, je pense que le marché est mur pour les petites entreprises (c’est d’ailleurs la cible de Google Apps que je citais plus haut) mais pas pour les grandes, d’autant qu’elle a aussi, probablement, l’hébergement des serveurs dans son corps de métier (je faisais remarquer à Fiso que mon entreprise, très grande, héberge beaucoup plus de serveurs que des entreprises spécialisées dans l’hébergement et qu’on est donc probablement moins chers…).

Comment l’informatique va-t-elle se développer pour les petites entreprises ? Les grandes entreprises laisseront-elles, un jour, se laisseront-elles envahir par les applications en SaaS pour son corps de métier ?

La réponse est oui. Ma boite est passée par une solution on line pour la messagerie, pour éviter les « clients lourds » comme Outlook et Lotus Notes. Ca fait longtemps qu’on n’utilise des applications externes pour gérer les demandes de congés et les notes de frais.

Le reste viendra…

L'avant-projet pour les nuls

Dans tout projet informatique d’envergure, il y a une phase préalable, l’avant-projet, assez peu connue, souvent décriée. Elle est pourtant indispensable et mérite bien un joli billet avec un exemple amusant pour qu’on évite de se faire chier et pour vous permettre de comprendre plus facilement, même s’il y a du boulot.

Un peu de sérieux ! Imaginez que le Comptoir de Jégoun ne soit pas une excellente page Google+ mais une entreprise "vins et spiritueux" qui travaille avec l0% des bistros de France. J'en serais le patron, bordel.

Elooooody est la secrétaire générale. En d'autres termes, elle dirige les services centraux au siège, au Kremlin-Bicêtre : la compta, la facturation, l'informatique, le juridique,...

Melclalex est le directeur commercial. Il est à la tête d'une équipe de commerciaux répartis sur le territoire, chargés de prospecter les nouveaux clients et surtout d'assurer les relations avec les clients déjà "en stock". Ils font un tour mensuel pour présenter les nouveaux produits, prendre les commandes,...

El Camino est le directeur marketing. C'est lui qui gère le catalogue de produits avec les produits traditionnels (Ricard, Coca, ...) mais aussi les produits spéciaux : vins du mois,... Pour ce faire, il a une équipe de prospecteurs, dont FalconHill, chargé de visiter les viticulteurs du Sud Est afin de repérer de bons produits. Il y aussi Juju, par exemple, qui navigue à l'international et Hiéléna en charge des boissons non alcoolisés.

Et il y a une importante division logistique, chargée des entrepôts, des livraisons,...

Le cadre est posé. Vous avez des questions ?

Lors d'un conseil de direction, Melclalex, dit : "j'aimerais bien équiper mes commerciaux d'ordinateurs portables pour saisir directement les commandes des clients et leur présenter les produits."  En tant que patron, je réponds "Hein ? Ils n'en ont pas ? Je ne m'étais jamais posé la question." Tous les patrons sont à la ramasse.

David, représentant des salariés : "Dites, les gars, on ne pourrait pas avoir des tablettes, plutôt, c'est beaucoup moins lourd ?"

Je dis "banco ! On va voir." Je réfléchis quand même. L'utilité est évidente. La société gagnera en coût de traitement et en image de marque...

Je demande donc à chaque direction de détailler les impacts pour elle et d'éventuels autres besoins. Je confie à Elooooody la coordination initiale et aussi une estimation des coûts à grosses mailles.

On fait un rapide brain storming. Il y a les coûts :
- des tablettes, investissements donc amortissements, maintenance,
- de télécommunication (forfaits 3G sur les tablettes),
- de développements informatique des applications et des logiciels sur les serveurs,
- d'hébergement (au sens large) des serveurs.

Je propose à Elooooody de prendre rapidement un consultant généraliste qui devra nous assister pendant la phase de conception. Je l'autorise donc à dépenser jusqu'à 30000€. Elle choisit Bembelly à cause de la légende.

Dans ce billet, je ne peux pas parler uniquement de picole, il fait un noir et du sexe.

La pré-étude est lancée.

Un mois après, nous avons les chiffres et les besoins. Nous nous réunissons à nouveau et papotons. L'instinct initial est le bon : le projet est "profitable". Pendant ce mois, j'aurais consulté des concurrents, le syndicat,... Aucun produit sur le marché ne répond à nos besoins, bien trop spécifiques !

D'ailleurs vous les avez oubliés. Pire ! Vous les avez déformés. Vous vous êtes dit qu'on voulait une application iPad pour prendre les commandes des clients parce que c'est ce qui saute aux yeux. Moi, qui suis le patron, j'ai rebondi sur une demande de mon directeur commercial. Je vous la rappelle : "j'aimerais bien équiper mes commerciaux d'ordinateurs portables pour saisir directement les commandes des clients et leur présenter les produits." Et de David qui a dit qu'on pourrait passer aux tablettes.

On s'imagine donc un catalogue avec les produits et d'un système pour préparer les commandes : nombre de bouteille de coca, de litres de rouge,... Or notre cœur de métier, le plus par rapport aux concurrents, est notre équipe marketing qui va étudier l'offre pour faire de sympathiques propositions aux patrons de bistro.

Il s'agit de donner des outils à un commercial pour donner envie à un patron de bistro de proposer à ces clients un petit vin de pays repéré par Falconhill ou un thé au houblon trouvé par Hiéléna. Le but du projet n'est pas de faire un développement informatique mais de gagner du pognon en vendant plus !

Il n'empêche : les coûts du projet sont compatibles avec notre budget. On peut donc passer à la première phase : l'avant-projet.

Vous imaginiez déjà des informaticiens à l'ouvrage ? C'est raté.

D'autant que l'avant projet est le thème de ce billet.

La mission de Bembelly est prolongée. Il est nommé responsable de projet. Il a trois mois pour en bâtir l'ossature. Sa mission :

Petit 1 : définir exactement les besoins.
Petit 2 : repartir le projet entre les équipes informatiques.
Petit 3 : affiner les coûts, les plannings.
Petit 4 : penser aux détails. Ben oui ! Vous avez pensé à la formation des commerciaux pour éviter qu'ils merdent chez les clients ? Vous avez pensé aux tests de l'application (l'homologation), pour s'assurer qu'il n'y aura pas de régression et d'erreurs face au client.

Paf ! Le coût initial vient d'augmenter de 50%... Sinon, on risque de perdre des clients qui se retrouveraient sans Ricard mais avec 200 caisses de coca.

Petit 5, tant que j'y suis : est-ce que nous ne pourrions pas mutualiser les développements avec d'autres boîtes ?

Je résume. Une fois l'avant projet terminé, nous pourrons lancer les développements et tout ça... Mais nous n’en sommes qu’à l’avant projet.

De quoi s’agit-il ? Il s’agit de faire le tour du projet avec « méthode ». C’est pour ça que les gens n’aiment pas les avant-projets : il faut une méthode, respecter des documents, des normes, …

Par exemple, on a vu plus haut qu’on se trompait sur le périmètre du projet : il ne s’agit pas d’avoir un machin pour prendre les commandes mais d’un truc pour présenter des produits à un patron de bistro pour lui donner envie de proposer des produits à des clients. C’est important de le rappeler. Il faut entrer en situation. Un patron près de la caisse du comptoir pour surveiller le service avec en face de lui un commercial et, entre eux, une tablette que le commercial « lira à l’envers » (puisqu’elle sera tournée vers le patron) et qui fera défiler des pages selon les réponses et les questions du patron.

Proposons une méthode.

Chapitre 1 : introduction

On y rappellera les enjeux du projet, les contraintes, le périmètre, …

Chaque détail a de l’importance. Tiens ! Les contraintes. L’application doit être opérationnelle pour les commerciaux. Quoiqu’il arrive. Et y compris quand il n’y a pas de connexion à Internet. Un informaticien serait parti bille en tête avec un joli serveur interfacé avec une base de données commerciales issues du marketing (fiches produit,…) et le fichier des clients pour passer des commandes. Ben non ! Il faut que les informations soient en local, dans la tablette, avec une synchronisation quand la connexion Internet est établie. Les données commerciales et les informations propres au client doivent être dans le truc en permanence.

Ca conditionne toute l’architecture qu’on avait pu imaginer ! Pire ! Le machin pouvant fonctionner « off line », il n’y a plus besoin de connexion 3G, le commercial fera la synchronisation en Wifi quand il sera chez lui.

Le périmètre ? On doit ainsi aller de la phase commerciale de présentation des produits, jusqu’à pouvoir rappeler au client ses dernières commandes, saisir des commandes, … Il nous faut donc un interfaçage avec l’ancien système de gestion des commandes et des clients. Cette interface deviendra le nœud du projet, ce qui délimite le périmètre entre le nouveau système et l’ancien. C’est essentiel : il faut que les systèmes soient interopérables (en français : puissent causer entre eux) et on aura fatalement des évolutions de l’ancien, ce qui n’était pas prévu au programme.

Chapitre 2 : l’ancien système

On y décrira précisément le mode de fonctionnement de l’entreprise et donc le travail du commercial. On peut supposer, par exemple, que le matin il prépare sa journée en commençant par se renseigner sur les nouvelles offres. Après, il va voir les clients, étudie les commandes à faire puis tente de caser des nouveaux produits. Au fur et à mesure, il remplit un bon de livraison. Le soir, il le faxe et un opérateur saisit la commande. Je dis ça au hasard, ce n’est pas mon job.  Mais cette visite au client devra avoir été préparée : le bon de commande ne sera pas vierge mais comprendra la liste des produits habituellement commandés par le client, les quantités, … pour ne rien oublier. C’est donc bien avec un vrai listing que le commercial commencera sa journée.

Tiens ! Et qu’est-ce qu’on fait des opérateurs quand ils n’auront plus de boulot ? Ah ! Merde ! Mon projet contient une composante sociale…

Tiens ! Et avec le nouveau système, comment le commercial sera informé des nouvelles offres alors qu’il les recevait, auparavant, par courrier ?

Tiens ! Nos catalogues sont faits au format A4. Les produits doivent maintenant être présentés au format « tablette » (16/9). Il faut qu’on refasse tout ! Comment vont faire nos « FalconHill » à la recherche des petits vins de pays pour faire leurs plaquettes de présentation ?

Tiens ! Que fait le commercial si le patron n’est pas là ? Il laisse le catalogue… Mais alors ? Le machin sur tablette, on en fait quoi ? Il faut donc maintenir un catalogue papier en plus de la tablette ? Doit-il être A4 comme l’ancien ?

Tiens ! Et si le patron n’est pas là au moment de passer la commande, on fait quoi ? Il le fait par téléphone ?

Tiens ! Et le double de la commande qu’on laisse habituellement au client ? On « l’imprime » comment ?

On va se retrouver avec des problèmes bien éloignés de ceux qu’on imaginait au départ avec notre tablette… C’est toute l’organisation qu’il va falloir revoir. On est très loin d’un projet informatique.

Je prends au hasard mon dernier exemple, le double de la commande. Si le patron est sympa, il acceptera de la recevoir par mail. Sinon, il faudra bien que le commercial se déplace avec une petite imprimante (moins de 100 euros) et du stock de papier.

Chapitre 3 : l’organisation cible

Il va falloir décrire ce qu’on attend de lui… Tout compris, puisqu’avec le chapitre 2, on se retrouve avec un catalogue papier qu’on pensait supprimer.

Il y a bien sûr la phase commerciale avec l’application sur la tablette, mais il faudra couvrir toutes les facettes du métier, en décrivant le rôle de chacun des acteurs, ce qu’il attend. Par exemple, le FalconHill voudra pouvoir disposer d’un logiciel qui lui permette de faire ses présentations de produits au nouveau format. Il lui faudra donc un logiciel, une formation, des moyens pour alimenter le catalogue de la société (un mail, quoi !)…

Je ne vais pas détailler : il s’agit de décrire le fonctionnement de l’entreprise une fois qu’elle aura changé.

Chapitre 4 : les fonctions informatiques

J’accélère : à partir de l’organisation cible, on va pouvoir déterminer les fonctions informatiques qu’il faudra mettre en œuvre, ce qui permettra de préparer les cahiers des charges pour chaque intervenant, chaque acteur de l’informatique.

Stop !

Vous pourrez rajouter un tas de chapitres : la migration (ben oui, comment on fait pour passer d’un système à l’autre ?), la sécurité (ben oui, on accède à l’informatique par Internet et des couillons de commerciaux vont se promener avec des iPad qui pourront se faire voler comprenant une partie du fichier client qu’il faudra déclarer à la CNIL, …), les exigences en termes de performances (ben oui, s’il faut cinq minutes pour ouvrir une session pour répondre à une question d’un client, ça ne serait pas génial), …

Résumons tout ça

Nous étions partis de l’idée fougueuse d’un directeur commercial qui voulait que ses commerciaux présentent leur catalogue à partir d’une appli pour tablette et en trois mois de travail, le périmètre a été complètement modifié parce qu’il a fallu faire une analyse complète de tous les processus.

Le coût a évolué mais à la marge uniquement (il va falloir acheter des imprimantes…).

Un informaticien serait parti bille en tête. Une application pour iPad qui va accéder à une application d’un serveur avec la gestion de la base des clients et des commandes d’un côté et le volet commercial de l’autre. On aurait eu une application dont il aurait été très fier mais que les commerciaux n’auraient pas pu utiliser dans les bistros au pied des tours de la Défense : la 3G ne passe pas. Si on avait découvert ça après les développements informatiques, il aurait fallu tout repenser : les coûts auraient été presque doublés puisqu’il aurait fallu redévelopper une grande partie.

Pire ! Les commerciaux n’auraient pas pu se « saisir » du nouvel outil à cause de plusieurs défauts (ben oui, sans imprimante pour faire la copie de la commande…) et auraient donc refusé tout changement.

Pourtant, personne n’aime ces études préalables ou avant-projets… De la paperasse, du formalisme, …

Personne n’aime ça ? Sauf moi

En menant ce projet, Bembelly aura eu l’occasion de se mêler et de connaître tous le processus commercial de l’entreprise, de la rédaction de l’offre jusqu’au travail au quotidien des opérateurs de saisie, des commerciaux… C’est passionnant.

Il aura du faire face à des résistances ! Le directeur commercial, tiens ! Il aura voulu imposer une nouvelle informatique à ses employés sans savoir quels sont leurs besoins réels, comme fournir un récépissé d’une commande à un vieux client ronchon qui utilise des formulaires papiers depuis 40 ans. Bembelly aura du aller voir des commerciaux alors que leur chef ne voulait pas, pensant tout connaître. Et Bembelly aura sauvé la peau du chef qui voulait un système informatique qui n’aurait pas fonctionné.

Passionnant.

C’est dommage que je ne puisse pas parler de mon job…

(illustration)