03 avril 2015

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 !

17 commentaires:

  1. Ton excellent billet va au delà du projet informatique. C'est du projet tout court.

    Je reprends ton point 3 qui est une de mes marottes professionnelles. L'expression de besoin fonctionnelle, quand on mélange besoin et outil.

    RépondreSupprimer
    Réponses
    1. Merci.

      Je dirai plutôt l'avant projet. C'est presque le plus important. Pas plupart que hier soir, avec mon directeur, on a fait faire des dizaines de milliers d'euros économie à un projet en suggérant à la maîtrise d'ouvrage de changer son expression de besoin pour une petite connerie. Ils avaient proposé un truc parce qu'il croyait que cela serait plus facile pour nous mais ils sortaient du standard. Les premiers informaticiens à avoir planché sur le sujet n'avaient pas vu la faille.

      Supprimer
  2. Je vais arrêter de lire tes trucs sur l'informatique, je suis à la retraite et tu me ramènes 5 ans en arrière au boulot. Je vois que çà n'a pas changé depuis mon départ, et comme c'était déjà comme çà il y a vingt ans, je ne crois pas que tu changeras grand chose. Courage

    RépondreSupprimer
  3. Comme tebruc, j'ai baissé le rideau professionnel après des dizaines d'années dans les projets informatiques mais toujours côté maîtrise d'ouvrage.
    Je partage ta vision et je te livre mes conclusions;
    Un invariant est l'incapacité des maîtrises d'oeuvre à faire passer le Quoi avant le Comment.
    De plus les DSI se font épauler (enfler ?) par des consultants qui ont des solutions...
    Et on en arrive au schéma classique "Solution cherche Problème" ce qui coûte horriblement cher pour au final ne servir à pas grand chose....
    De plus certains acteurs MOA sont atteints de la même vérole en décrivant dans leur cahier des charges des solutions en long en large et toujours de travers.
    Mon plaisir dans le job était de demander "Au fait c'est quoi le problème" et de renvoyer les demandeurs à la case départ ...
    Les projets grands ou petit, y compris ceux des pouvoirs publics, sont voués à l'échec dès lors qu'ils ne sont pas l'expression d'une vraie demande.....
    Une chose est certaine, l'éducation actuelle fabrique des gens qui pensent comment et de moins en moins quoi. L'esprit critique est dangereux donc nos utilisateurs, demandeurs, mandants vont s'enfoncer vers des échecs de plus en plus couteux.
    De temps à autre, un râleur, (genre frisé amateur de houblon) arrive à faire que tout ce beau monde (DSI et MOA) redescende sur terre (atterrissage douloureux) et on peut mener un vrai projet à terme.

    Pour mener mes travaux à bien, je prenais l'image de la construction d'un maison et la métaphore permet aux MOA de mieux comprendre leur rôle et parfois de bien tenir leur rôle....

    Nicolas, tu as encore de belles séances de rigolades (car il vaut mieux en rire qu'en pleurer) devant toi.

    Bon courage quand même et bravo pour ce bobyié...

    RépondreSupprimer
    Réponses
    1. Merci !

      Tu dis des choses vraies dans ton commentaire. Mais je vais revenir sur certains points.

      "Une chose est certaine, l'éducation actuelle fabrique des gens qui pensent comment et de moins en moins quoi." oui et non. C'est aussi l'informatique qui est ainsi : les gens sont payés pour faire ce qu'on leur demande.

      "De plus les DSI se font épauler (enfler ?) par des consultants qui ont des solutions..." Non, il y a de bons consultants. Tant pis pour mes chevilles : je l'ai été et j'en rencontre toujours.

      "Un invariant est l'incapacité des maîtrises d'oeuvre à faire passer le Quoi avant le Comment." c'est aussi le cas des "métiers", c'est le phénomène que je décris dans le billet. Du coup, les maîtrises d'oeuvre (et d'ouvrage) ne sont plus intéressées par le "quoi" alors qu'ils ont des solutions techniques à apporter.

      Supprimer
    2. Nicolas, les consultants comme toi qui privilégient la réussite du projet sont moins nombreux que ceux qui (sous la pression infecte de leur propre hiérarchie) sont priés de générer du chiffre au-delà de la mission pour laquelle ils interviennent. D'expérience, je dirais deux qui poussent au chiffre pour un qui est centré sur le projet.
      Dans ton cas, je n'ai aucun doute, car tu es un humaniste et pas un homme d'argent ou d'appareil
      Quand à l'éducation, je pensais plus à la formation des utilisateurs (non informaticiens), qui devraient eux avoir l'esprit critique et savoir ce qu'ils veulent, puisque c'est eux qui vont le financer puis l'utiliser...

      Globalement on est en phase.

      Et Joyeuses Pâques.

      Supprimer
    3. Pareil.

      Pour les consultants, outre le fait que tu te trompes sur mon compte (c'est en faisant bien le boulot qu'on génère du chiffre d'affaire en faisant durer les missions), ce que tu dis est valable pour certains consultants "haut de vol" proche des directions.

      J'aurais d'autres trucs à dire sur les consultants, comme profiter du travail des autres...

      Supprimer
    4. Je me sens obligé de répondre à ElZede. Les consultants sont aussi honnêtes et compétents que les informaticiens. Et leurs hiérarchies ne sont pas plus infectes que les hiérarchies de toutes les organisations.
      Quand un projet ou une solution est proposée par un consultant, c'est souvent parce que le responsable dont il dépend chez le client est lui même impliqué dans ce projet ou cette solution. Si le consultant ne le suit pas, il est viré du client le lendemain, déclaré incompétent et sa hiérarchie convoquée. Qu'il le fasse 2 fois, et il peut commencer à chercher un autre boulot.
      Dans 90% des cas, le consultant est là pour proposer une solution que le client a déjà choisie, mais qu'il ne veut pas présenter lui-même en interne.

      Supprimer
    5. Non, pas 90%... Mais tu as raison : le consultant est souvent manipulé par le client. Il m'est arrivé de faire une étude statistique (avec des vrais chiffres
      !) qui allaient à l'encontre de ce que pensais mon chef et qu'il voulait que je démontre (le gars était sympathique et a admis son erreur mais je n'étais pas fier de moi).

      Plusieurs fois,on m'a demandé de faire des présentations PP avec des éléments sur lesquels je n'étais pas d'accord.

      Supprimer
    6. Nicolas, je crois qu'il y a dans le commentaire de tebruc matière à un autre bobyié sur les patrons de DSI et l'art d'utiliser les Consultants. Qui manipule qui, qui assume ou pas ses choix face à une Direction Générale... Quand on regarde ça de près on y voit toutes les faiblesses de l'âme humaine. Si ça ne coutait pas aussi cher aux boites, on pourrait en rire.
      L'un des chapitres les plus drôles est le dépouillement des réponses à appel d'offres, où le Cabinet (tebruc , je ne m'en prend pas aux consultants, car ils font honnêtement leur job) cherche à savoir quel est le montant facturable susceptible de passer .. sachant que le chiffre retenu par le client sera régulièrement explosé pour cause de Cahier des Charges mal ficelé (cf. les propos de Nicolas).

      Sur ce je vous laissent, je suis en retard pour aller à Rome faire la cloche. ;-)

      Supprimer
  4. Ce billet est nin. Les commentaires intéressants, la discussion chouette à suivre...

    Félicitations sincères pour ta série de billet sur le sujet professionnel...

    RépondreSupprimer

La modération des commentaires est activée. Je vous lis, voire vous publie, après la sieste.