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 !