La méthode RACHE

Je parlais récemment des méthodes Agile. En commentaire d'un autre billet, un copain a laissé un lien vers le site de la méthode RACHE. Comme une andouille, j'ai commencé par approuvé avant de comprendre que c'était une farce. 

Tiens ! Je leur pique une illustration pour montrer le résultat de l'application de cette méthode par un fabriquant de solutions informatiques bien connu. 

J'en retrouve tous les jours au travail.

Il y a trois ou quatre mois, je reçois la liste des actions décidées au cours d'un Comité de pilotage. Je vois une nouvelle tâche, attribuée à moi. Je comprends qu'il s'agissait de rédiger une spécification et de la faire valider par des clients. C'est donc normal qu'elle me soit attribuée mais je n'avais pas vraiment d'idée du besoin. Je vais voir ma chef qui était au Comité de pilotage. Je lui demande ce que c'est, elle me dit : je ne sais pas mais on a décidé qu'il fallait le faire. 

J'ai donc attendu un Comité projet (celui qui est "en dessous" le Comité de pilotage) pour poser la question aux braves gens. Ils étaient comme moi, incapables de comprendre ce que voulaient les instances supérieures. On discute et un type me propose une méthode : voila, tu vas nous envoyer un mail, récapitulant le contexte, la description de la demande, notre compréhension du dossier et ton avis, au nom de ta structure. On pourra ensuite faire circuler en interne.

Je le fais, l'équivalent d'un A4. Mon avis était que les développements allaient coûter un bras pour un truc totalement inutile. Je l'envoie.

Un mois après, sans réponse, à un autre Comité projet (d'un autre projet mais avec les mêmes participants), je les relance. Ils étaient tous bien emmerdés. D'accord avec moi, ça se voyait, ils tergiversaient. J'ai vite compris qu'ils n'avaient pas osé faire remonter à leur chef un document voulant dire qu'ils étaient de sombres abrutis. Alors, j'ai monté le ton : bon, les gars, vous êtes bien sympathiques mais si vous ne donnez pas de réponse, comme je suis "responsable de l'action", je vais être obligé de faire remonter les causes du blocage au Comité de pilotage. Ah bon ben c'est pas exactement ce qu'on t'avait demandé. Ah ben si. Ben oui. Mais non. Mais si. Le même gars que la précédente fois : ce qu'on voulait c'est une étude technique rapide des possibilités et des enjeux. Moi : je ne peux pas faire une étude technique si je n'ai aucun besoin exprimé. Bon ! Ce qu'on va faire : tu (moi) vas organiser un Groupe de travail dédié au sujet (sous-entendu : pour l'enterrer). 

Je l'ai fait. Il a duré un quart d'heure (ça me rappelle un autre exemple, tiens !) et j'ai pu fournir une réponse au Comité de pilotage.

Un bon exemple de la méthode RACHE, où le post it a été remplacé par une action dans un tableau.

Mon autre exemple.

J'avais, cette fois, un vrai sujet. J'avais dit à une collègue chef de projet : on a un truc à faire et, logiquement, il doit être mené par tes équipes. Rassure-toi, ce n'est pas urgent et tu auras du budget. Je lui explique et elle me répond que c'est beaucoup plus lourd que je ne le pensais et qu'il fallait un vrai chantier. J'en réfère au Comité de pilotage qui comprend bien mes arguments, prend acte que j'allais lancé une étude dont le résultat allait être une somme à six chiffres alors que trois ou quatre étaient inscrits à notre budget. Le Comité de pilotage était lui-même bien emmerdé : c'est lui qui avait fait le budget et il allait devoir chercher du pognon dans les hautes sphères de la hiérarchie.

Je me mets à fond dedans et, en deux ou trois jours, j'avais une fiche avec quatre solutions possibles pour répondre au besoin et je pouvais donc lancer un Groupe de travail. J'envoie le document.

Quinze jours plus tard, la réunion commence. J'ouvre la séance en présentant le débat. Voilà, il faut faire ça. J'ai quatre scénarios, le premier est présenté pour la forme (c'était ne rien faire), ne l'étudions pas.

Une intervenante fait ce qu'elle a à faire : elle intervient. Elle dit ; mais je ne comprends pas on le fait déjà comme ça. Cela correspondait à mon deuxième scénario, celui que j'avais présenté à ma collègue qui m'avait répondu qu'elle ne savait pas faire simplement. Elle répond : ben oui, on fait comme ça. Je rentre ma colère : elle m'avait fait bosser pour rien et convoqué un groupe de travail. Dans les blogs, je suis un peu bourru mais dans la vraie vie, je suis diplomate. Je réponds : "ah ben c'est mon scénario 2, si on sait le faire, il coûtera bien moins cher que les autres, ce n'est pas la peine de continuer. La réunion est close, on a été vachement efficace, cinq minutes pour un tel sujet !, je vous remercie pour votre participation."

A ce stade, ce n'est pas totalement de la méthode RACHE, c'est la connerie d'une personne qui ne savait pas que son service faisait déjà un truc. Dans le fond, ce n'est pas très grave mais ce que je lui reproche c'est d'avoir été formelle dans sa réponse au point de ne pas réfléchir cinq minutes, de regarder ses dossiers.

Mais le plus drôle est la suite de la réunion. Alors que j'allais raccrocher, la participante a dit : "ben non, tu as présenté quatre scénarios, il faut les étudier". J'ai répondu que ce n'était pas utile, elle a insisté et eu le dernier mot.

Et on a passé une demi heure à étudier chacun des scénarios, y compris le premier qui consistait à ne rien faire (il fallait donc étudier les conséquences), y compris le second qu'on maîtrisait,... Deux heures de réunion alors que la conclusion avait été tirée dans les cinq premières minutes.

J'ai fait un compte rendu de cinq lignes que j'ai envoyé par mail pour validation. L'intervenant m'a rapidement répondu pour me dire que mon mail ne retranscrivait pas l'intégralité des échanges.

Alors, j'ai modifié mon compte rendu. J'ai ajouté une ligne : "La décision était prise dès l'exposé du problème mais unetelle nous a demander d'étudier à fond chacun des scénarios pendant une bonne demi-heure, elle se tient à votre disposition pour vous expliquer". Et je l'ai envoyé à tout le monde.

Depuis, elle est beaucoup plus sage en réunion.

Le client

Je parlais avec ma copine @undessinparjour (suivez son blog, c'est un bonheur), j'ai eu une journée de merde. Un client a refusé une livraison parce qu'elle ne contenait pas une évolution d'une application demandée en début de semaine. Il a fallu que je le recadre mais n'étant pas dans mon blog politique je n'ai pas pu lui sortir ce que j'avais sur le cœur : "hé ! Connard ! Quand tu demandes une évolution, il faut que je la fasse chiffrer par les services concernés, que j'établis se un devis et j'obtienne un accord officiel et formel (donc que je fasse valider un contrat par le service juridique et la direction financière) pour le financement". 

Hier, un client nous a engueulé. On leur avait proposé de partir en méthode Agile dont je parlais récemment. Ils ont accepté. Ils ont eu quinze jours de retard et nous accusent d'avoir laissé un salarié d'un fournisseur aller travailler sur un autre truc pendant le temps en question, donc de répondre en retard. Ils auraient voulu qu'on bloque les ressources (comme on dit) pendant la période en question. 

D'un autre côté si le type bloqué est payé à ne rien foutre le temps que le client de son client bouge tout en étant payé à ne rien foutre, je lui refile mes blogs. 

Ainsi, toutes mes journées sont occupées à gérer ce genre de conneries. Ce soir, pour répondre à la copine en question, j'ai analysé ma journée. J'avais une réunion de 14 à 16 heures. On a été efficaces, elle a duré 30 minutes. J'ai commencé à attaquer sérieusement le travail de la journée à 17h45 tant j'ai été occupé par la gestion des merdes. J'ai fini à 20h15, je crois (mais au bistro, les smartphones sont magiques). 

Disons le franchement : si la révolution numérique est mal barrée, c'est parce que ses acteurs sont en plein délire. 

Mails professionnels à 23 heures ou le burn out pour les nuls

Nous avons accès à notre messagerie professionnelle depuis le web depuis peu. Du coup, on l'a tous mise sur notre smartphone parce que c'est bien pratique et que cela diminue la charge de travail et augmente l'efficacité. J'en ai fait un billet récemment. 

Néanmoins, hier soir, à 23 heures, je papotais avec ma chef et "nos" chefs de projet, de manière intelligente et constructive. Et surtout plaisante. Chacun a sa vie. Les uns ont couché leurs gamins et s'apprêtent à rejoindre leurs conjoints pour tirer un coup ou dormir. On se retrouve entre copains alors qu'on devrait être entre collègues. 

Alors, vers minuit, j'ai poussé un coup de gueule. Arrêtons nos conneries. En dehors des heures de boulot, on ne parle pas de boulot. On va finir fous et dépendants. Le plus drôle dans l'histoire est que je suis le seul à vraiment connaître les réseaux sociaux et que la firme est en train de mettre en place un réseau social d'entreprise. Voir les billets à ce sujet. 

Quand on quitte le boulot, avec une heure de transport en commun, il est normal de continuer à bosser. Moi-même, en rentrant à la maison avec deux grammes, je continue à produire. Sauf si un troisième gramme m'attend. 

Je diffuse donc des documents vers 23 heures (sans être con, si je suis hips, je ne le fais pas, n'insulte les gens sur mon annexe mais sans rapport avec le boulot). 

Rien de grave. Je pars du boulot à 19 heures. J'ai une idée. Je rédige dans le métro. J'arrive au bistro. Je déconne avec mes potes. Je vais pisser et rentre à la maison et diffuse ce que j'ai rédigé. 

 

Le burn out provient du fait qu'on 

se sent obligé de répondre aux mails à toute heure, pas au fait qu'on en reçoive. Google Inbox et Microsoft Outlook nous permettent de le gérer. On reçoit un mail, on dit au machin : renvoie le moi demain matin. 

Bref. 

Une seule consigne . S'astreindre à ne jamais répondre à un mail professionnel hors des heures de travail. On peut l'utiliser pour rédiger des mails mais pas pour en lire. 

Le RSE, ce n'est pas gagné !

Dans la boite, nous avons depuis très peu un réseau social d’entreprise. Il y a eu une journée de présentation aujourd’hui. Visiblement, je suis à peu près le seul à causer sur « le mur principal » et, sans présager de l’usage qui en sera fait, j’ai l’impression que tout le monde se pose la même question : à quoi cela sert ? L’utilité des autres fonctions de l’outil semble relativement apprécié mais ce volet « réseau social », genre Facebook ou Twitter, laisse dubitatif.

Du coup, je suis allé voir les comptes Facebook de certains de mes honorables collègues, non pas dans le but de les espionner, ils font ce qu’ils veulent de leur vie privée mais pour faire un vague sondage sur l’usage qu’ils en avaient. 

A noter que je n’ai pas été voir leur compte Twitter : j’avais déjà la réponse, c’est-à-dire qu’ils n’ont pas de compte Twitter et ne savent pas à quoi cela sert, comment cela fonctionne. Avec l’animateur, on a essayé d’expliquer des notions comme les mentions et les hashtags mais je ne suis pas persuadé que le public ait compris quelque chose… Il y a une différence énorme entre la perception de Twitter que nous pouvons avoir ou que peuvent avoir les médias et l’usage courant par les braves gens.

Leur utilisation de Facebook est normale (publication de photos privées, de lolcats et autres conneries dont il faudrait tuer les créateurs) mais beaucoup moins intensives que celles des gens que je connais via les blogs.

Il va donc falloir leur démontrer qu’il peut être utile de diffuser des informations dans un RSE…

Par exemple, hier soir, j’ai diffusé une publication en citant un chef de projet pour lui dire que je validais sa prose. Cela me permet :

-          Petit 1 : d’économiser un mail tout en étant sûr qu’il reçoive une notification pour avoir une trace de ma validation,

-          Petit 2 : de le féliciter en public,

-          Petit 3 : d’informer la hiérarchie que l’on va pouvoir diffuser le texte dans les délais,

-          Petit 4 : d’informer le reste de l’équipe qu’on avait franchis un pas.

Aujourd’hui, j’ai diffusé un article de presse parce que je suis abonné à « des alertes » Google News et Talkwalker. J’ai ainsi pu éviter un mail à ma hiérarchie (la "veille" fait aussi partie de mon boulot) et en faire profiter tous ceux potentiellement intéressés.

D’ailleurs, je vais conclure mon billet avec ces alertes en étant un peu hors sujet : les collègues sont toujours stupéfaits que je sois le premier informé (ou presque, les gens en charge de la sécurité et du marketing ayant aussi de bonnes sources). Il suffit de mettre des alertes… Ils ne savent pas que cela existe, comme ils ne savent pas à quoi pourrait servir un réseau social d’entreprise et savent à peine que c’est à cela qu’ils ont affaire.

Burn out, burn in ?

Depuis quelques jours, j'ai accès à ma boîte mail professionnelle depuis mon iPhone. J'ai ouvert l'accès pour des raisons précises : voir si cela fonctionne. C'est le cas ! Évidemment. 

Toujours est-il que je voulais la virer après le test mais, finalement, je trouve cela bien agréable. Concrètement, je viens de recevoir un mail d'un collègue alors que j'étais en copie pour info "par réflexe". Si je l'avais lu demain matin en arrivant au bureau, je l'aurais jeté immédiatement en vidant les mails de service alors qu'en le voyant à 20 heures, en vidant mon demi post travail, j'ai eu une idée pour contourner le problème. De même, ce matin, j'ai pu papoter avec ma chef avant qu'on soit pris dans l'engrenage du boulot. 

D'un autre côté, vu le temps que je passais au bureau à bloguer, je peux bien travailler pendant les heures de loisir. 

Quand j'aurais migré toutes les messageries pro vers la nouvelle, que l'on peut consulter par internet et pas seulement sur un client lourd, j'aurai une source de stress en moins, celle qui vous fait arriver au bureau avant les heures normales de réunion pour avoir le temps de s'informer. 

Quant au burn out, il n'arrive que lorsque l'on reçoit des mails qui génèrent du travail. 

La méthode, un frein au numérique ? Soyons Agiles !

Un vrai projet numérique doit être mené rapidement : il est fait pour révolutionner les processus, le rapport avec les clients,… L’informatique et l’organisation ou les opérations (en tant que « directions ») doivent montrer l’exemple. Néanmoins, les méthodes utilisées dans les DSI ne permettent pas cette célérité car elles répondent à d’autres besoins : couverture du projet, maintenabilité, exploitabilité, cohérence de l’architecture technique et de l’architecture applicative. En outre, de nombreux acteurs interviennent à différents stades et prendre en compte leur disponibilité n’est pas compatible.

En phase de développement, on choisira des méthodes de type agiles. Je ne vais pas faire une thèse sur le sujet, seulement un aparté. Les DSI ne sont pas nécessairement adaptées à ces méthodes et j’ignorais leurs existences jusqu’à il y a quelques mois quand un fournisseur nous a proposé de travailler ainsi car un de nos projets n’avançait pas. Ce qu’il nous a présenté collait parfaitement à ma vision du travail et j’étais enthousiasmé. Pour vous dire, j’ai repris une bière. Me documentant rapidement sur le sujet (il ne m’intéresse pas beaucoup et je suis tenu de respecter les méthodes de ma boite), j’ai découvert que pour mon boulot je pratiquais toujours cette méthode sans m’en rendre compte.  D’ailleurs, la page Wikipedia m’a fait rigoler. Par exemple : « Un responsable fonctionnel définit et ordonne la production des composants de l'application. »  Je me suis découvert comme étant « responsable fonctionnel » faisant la chose.

D’une manière générale, je me suis rendu compte que, dans la boite, on pratiquait beaucoup un dérivé des méthodes agiles sans le savoir. Je vais donc citer une large partie de cette page.

« Pratiques communes à l'ensemble des méthodes agiles

·         Les pratiques communes liées aux ressources humaines :

o   Participation de l’utilisateur final aux groupes de travail.

o   Groupes de travail disposant du pouvoir de décision.

o   Autonomie et organisation centralisée de l’équipe (motivation).

o   Spécification et validation permanente des Exigences.

·         Les pratiques communes liées au pilotage du projet

o   Niveau méthodologique variable en fonction des enjeux du projet.

o   Pilotage par les enjeux et les risques.

o   Planification stratégique globale basée sur des itérations rapides.

o   Réalisation en jalons par prototypage actif itératif et incrémental.

o   Recherche continue d’amélioration des pratiques.

·         Les pratiques communes liées à la qualité de la production

o   Recherche d’excellence technique de la conception.

o   Vision graphique d’une modélisation nécessaire et suffisante.

o   Vision de la documentation nécessaire et suffisante.

o   Normes et techniques raisonnables de qualité du code (métrique).

o   Architecture à base de composants.

o   Gestion des changements automatisés. »

Nous y sommes presque ! Je vais en parler à mes chefs. Je vais néanmoins faire deux ou trois critiques. Par exemple, les groupes de travail ne doivent pas avoir de pouvoir de décision : le responsable fonctionnel doit pouvoir s’y opposer et faire remonter les désaccords aux instances dirigeantes, pour des raisons que j’exposais récemment dans mon blog (les braves gens ont tendance à prendre des décisions inutiles qui coûtent cher, notamment parce que dans le feu de l’action, ils perdent le recul nécessaire). Mais de tous ces points, c’est le premier qui est le plus important : l’utilisateur final doit participer aux groupes de travail, ou, plus exactement, celui qui le représente.

A cette liste, j’ajouterais bien qu’il faut un PMO (bureau de gestion de projet), éventuellement externe à l’équipe et indépendante du responsable fonctionnel pour gérer tout le bordel, les plannings, les actions, le reporting,… En plus d’un chef, également.

Supprimer les vieilles méthodes

Comme je le disais, il ne s'agit pas pour moi de faire la critique des méthodes utilisées mais de rappeler le constat : elles ne sont pas adaptées à des projets numériques. Il faut donc en utiliser d'autres, plus souples,... Il faut en finir avec les "dossiers d'architecture technique" et autres "documents de conception détaillée". Tant pis !

Mais pour que cela fonctionne, que le numérique s'applique à certains projets, tous les projets doivent prendre les nouvelles méthodes. C'est une révolution qui doit se faire dans les DSI.

Avant-projet

Je parlais récemment de Moneo et d'une des raisons de l'échec : les PME ne sont pas rechargeables sur les distributeurs automatiques.

Aussi, on ne répétera jamais que dans tout projet informatique (numérique ou pas), la phase la plus importante est la conception initiale, le cadrage. Il ne suffit pas dire : on veut ça, mettez-vous autour d'une table pour le faire. Il faut que l'avant-projet définisse toutes les briques impactées et que le responsable fonctionnel puisse distribuer les copies dès le lancement.

Pensez-y bien !

Twitter et la révolution de la citation de tweet

Twitter a introduit aujourd'hui une nouvelle manière de citer un tweet, vous l'avez probablement découvert. Auparavant, ils préparaient un tweet en mettant entre guillemets le tweet que l'on voulait citer. 

Ils ont remplacé cette fonction par celle qui permettait de citer un tweet. En faisant les citations ainsi, le "citeur" dispose de 140 caractères pour ajouter des bêtises. C'est la révolution et c'est très bien. Je tenais à le dire et faciliter cette honorable société américaine.

French Tech

Cette nuit, six personnes m'ont ajouté à une liste avec un nom du genre "French Tech". Serait-ce le début de la gloire ? Qu'ont-ils tous ? Où m'ont-ils repérés ?

Les treize syndromes de la décomposition numérique

« Quelles seraient les étapes de la décomposition numérique ? » demande l'ami Pierre, s'interrogeant toujours comment les entreprises et administrations françaises vont passer à côté du numérique. Si l'on est d'accord sur le fond, je serais moins formel que lui sur les étapes en question. Je parlerais plutôt de syndromes de la décomposition numérique.

Premier syndrome : quand on est satisfait des technologies utilisées

Qu'on soit à la pointe de la technologie utilisée ou qu'on utilise des technologies obsolètes, on peut trouver des motifs de satisfaction. Par exemple, les vieilles machines peuvent être beaucoup plus robustes que les nouvelles avec des applications beaucoup plus simples à concevoir.

Les technologies de pointe ne sont utiles que pour ce qu'elles apportent. Elles ne servent à rien en tant que telles.

Il faut toujours se demander si les choix sont bons.

Deuxième syndrome : quand on cherche le progrès technologique pour le progrès technologique

Au bureau, nous avons encore des serveurs en Windows Server 2003. Je discutais avec un collègue. Du genre : « fait chier, il faut qu'on passe à Windows Server 2008 », ça va nous faire un chantier complémentaire. Il m'a répondu : « ah mais faut passer directement à Windows Server 2012, c'est génial et tout ça. » Ce à quoi je lui ai rétorqué ce qui voulait dire, en gros : « hé ! Connard, qu'est-ce qu'on en a à cirer ? Les applications développées par notre fournisseur le sont pour Windows Serveur 2003 et 2008. Si on change, c'est parce que maintenir les versions pour 2003 à un coup d'autant que Microsoft a annoncé l'arrêt de la maintenance. »

Troisième syndrome : quand on est réfractaire au progrès technologique pour le progrès technologique

A ce stade, vous noterez que ce point est l'exact contraire du précédent. Il n'empêche que si on devait faire des grosses évolutions de nos applications WS 2003 à passer à WS 2008, on aurait tout intérêt à en profiter pour passer à WS 2012 pour tirer profit des évolutions et ne pas être emmerdés lors de l'arrêt de WS2008 en 2020.

Mais laissons tomber ces considérations technologiques...

Quatrième syndrome : quand on déploie de nouvelles applications et que les utilisateurs demandent une formation ou une documentation

Je parle bien entendu pour ce qui concerne l'application et pas les processus qui vont avec. A partir du moment où vous sortez des applications qui nécessitent une formation ou une documentation pour les utilisateurs ou que vous n'arrivez pas à convaincre le représentant des utilisateurs que ce n'est pas nécessaire, c'est que vous avez foiré la transformation numérique.

Récemment, on a mis en place un système tout à fait moderne pour consulter les historiques des transactions faites sur nos machines. Un type du « métier » m'envoie un mail : « dis-donc, Nicolas, quand est-ce que vous organiser la formation et livrez la documentation. » Je lui ai répondu : « tiens, voilà un lien, tu cliques dessus, tu tapes ton identifiant et ton mot de passe, tu valides, un nouvel écran arrive, tu tapes le numéro de client et la date de la transaction et elle s'affiche. Pour passer à un nouveau client, tu tapes sur « nouvelle recherche », voilà, lis l'écran. »

Je ne plaisante pas. J'en ai déjà parlé et la plupart des cabinets de « conseil en numérique » proposent une offre « d'accompagnement du changement ». Ce sont des loosers.

Cinquième syndrome : quand vous assistez à des conférences sur la transition numérique parce que vous n'osez pas ne pas y aller.

Si vous êtes informaticiens, allez plutôt à des conférences sur les technologies. Si vous êtes décideurs, n'oubliez pas que ces conférences sont souvent commerciales. Allez y pour le cocktail final.

Sixième syndrome : quand vous prenez des consultants pour vous aider à choisir une stratégie pour la transformation numérique.

Vous pensez vraiment que des consultants « en stratégie » ont la moindre idée de ce qu'est la transformation numérique appliquée à votre métier ou à votre filière ? Faites-vous inviter à déjeuner par leurs commerciaux et écoutez ce qu'ils ont à vous dire et vous en saurez assez.

Ensuite, prenez des consultants normaux, parce que vous avez une surcharge d'activité et que c'est toujours utile d'avoir une vision extérieure.

Septième syndrome : quand vous pensez faire une transformation numérique sans modification des processus.

Cela signifie que vous confondez transformation numérique avec une transformation informatique qui peut être utile pour de nombreuses raisons : obsolescence technologique, coût de maintenance, performances, nouvelle offre commerciale,...

Méditez bien sur la locution : « modification des processus ». Quand votre banque met votre relevé de compte à disposition sur votre serveur web, c'est une transformation numérique car ils n'ont plus besoin de l'imprimer et de l'expédier et vous n'avez plus besoin de l'archiver dans un classeur. Par contre, c'est une relativement petite transformation informatique (la banque sait envoyer un fichier pour que l'imprimeur... l'imprime, il n'y a plus qu'à en faire un pdf et le stocker en ligne, dans le cloud, comme on dit).

Huitième syndrome : quand vous restez persuadés que la transformation numérique est un truc du 21ème siècle.

Cela fait trente ans, à peu près, que je consulte mes comptes bancaires en ligne. C'était grâce au Minitel. Le Minitel a permis une transformation numérique parce qu'il a permis une modification des processus.

Pour en revenir au syndrome précédent : quand internet est arrivé et que les banques ont pu faire des sites web pour permettre aux clients de faire des opérations de base, c'était une gigantesque transformation informatique mais pas du tout une transformation numérique : les processus étaient possibles avec le Minitel.

Le seul aspect un peu « numérique » est que les banques ont été obligées d'y passer pour ne pas être à la traîne par rapport à leurs concurrents.

S'il y a aujourd'hui une volonté d'accélérer la transformation numérique, c'est parce que les conditions technologiques la rendent indispensable.

Neuvième syndrome : quand vous accompagnez vos évolutions de processus de formulaires papier sans valeur contractuelle.

Je ne plaisante pas ! Tiens ! Même au sein des DSI, on croule sous les paperasses même si elles sont transmises en pdf par mail.

Dixième syndrome : quand vous n'avez pas fait votre transformation numérique au sein de vos services internes.

C'est directement l'exemple du point précédent qui m'inspire celui-ci... Dans les DSI, nous sommes des acteurs de la transformation numérique de l'entreprise mais on ne se l'applique pas à nous. L'autre jour, on avait un client qui voulait une copie du procès verbal d'homologation d'une version de logiciel sans même se rendre compte que les outils modernes permettent de gérer tout ce bordel sans produire de PV.

C'est malin d'ajouter un syndrome en cours de rédaction d'un billet structuré à l'avance, ça va me faire 13 points. Ca porte malheur.

Onzième syndrome : quand vous faites des expérimentations vouées à l'échec

Tiens ! Je parlais hier de Monéo. Une expérimentation grandeur nature. Le numérique est un truc relativement compliqué, pas simple du tout à mettre en œuvre et on ne sait jamais ce qui marchera ou pas. On est donc incités à faire de l'innovation technologique pour montrer qu'on est modernes et pour être sûrs de ne pas louper une vague.

Il faut voir le nombre d'heures perdues pour des trucs qui seront peut-être des formidables percées technologiques mais qui n'auront aucune retombée commerciale.

Douzième syndrome : quand vous pensez que la normalisation et le respect des standards n'est pas important.

C'est probablement le point le plus important. Un des syndromes, par exemple, est de tolérer une application qui ne fonctionne qu'avec la dernière version de Chrome mais pas la dernière d'IE ou de Firefox... J'aurais plusieurs autres exemples à donner mais j'ai la flemme.

Le respect des standards est ce qui permet de garantir l'évolutivité.

Treizième syndrome : quand vous avez une liste fermée de fournisseurs

La plupart des grosses entreprises ont des listes fermées de fournisseurs de logiciel, de prestations informatiques ou de prestations de conseil. Comment voulez-vous innover dans ce contexte ? Comment travailler avec des « start up » ? Comment voulez-vous mettre en concurrence ?

C'est la première erreur des DSI... Comment faire de la transformation numérique si les achats et les RH verrouillent tout ? Et j'aurais pu ajouter "la sécurité".

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 !