Plus de 80 % des projets de transformation numérique échouent. Pourquoi ? Parce que beaucoup avancent sans méthode, à l’aveuglette, sans une vision claire de leurs objectifs et sans plan d’action. Aujourd’hui, du haut de mes 30 ans d’expérience en direction de projets d’infrastructure à travers le monde, je m’inspire des pratiques de la construction pour vous dévoiler une approche terrain qui structure votre transformation numérique en entreprise. Intitulée U do, mouv !, cette méthode permet d’obtenir une transformation profonde, productrice de valeurs.

Décryptage!

L’histoire U do, mouv !

De la construction à la transformation numérique

Durant des décennies, les métiers de la construction ont su accumuler des compétences en conduite de projets : création de pyramides, de cathédrales, d’immeubles… Des compétences qui se cristallisent en des méthodes éprouvées.

Dans la première partie de ma vie professionnelle, j’ai baigné dans l’univers de la construction. Tantôt confronté aux lots techniques d’immeubles de grande hauteur et de bâtiments techniques complets, tantôt à la tête de projets d’infrastructures avec une part croissante de systèmes (autoroutes interurbaines et tunnels). De cette expérience a émergé une approche intitulée U do, mouv ! etqui a pour ambition de vous aider à réussir votre transformation numérique en entreprise.

Pourquoi et comment le numérique dans les transformations des entreprises ?

Cette interrogation n’est pas de moi, mais bel et bien de Patrice Lerouge du cabinet Reliences à Tours. Ainsi, son questionnement se construit en trois étapes : la vision d’une entreprise, la façon dont elle exerce son métier pour parvenir à cette vision et enfin la place du numérique dans cette perspective.

En partant des usages, il semblerait donc que la transformation vienne en réponse à un manque ou une insatisfaction. Le numérique outille cette transformation et se place alors comme un moyen et non pas comme une finalité.

U do, mouv !, c’est quoi ?

Pour répondre à cette question, je vous invite à regarder cette courte vidéo de synthèse de trois minutes.

U do, mouv ! réussir la transformation numérique from Rousseau Frédéric on Vimeo.

Maintenant que vous en savez plus sur la méthode et sur son histoire, découvrons tout d’abord la structure orientant l’action U do (Usages, Données et Outils). Puis, nous verrons les modalités d’ancrage du projet Mouv (Métiers, Organisation, User experience, Visual management). Enfin, nous terminerons par l’identification des liens et des interactions entre l’ensemble des composants.

« U do », ou comment structurer votre projet pour préparer le passage à l’action ?

Les causes des projets de transformation numérique qui échouent

Comme évoqué en introduction, plus de 80 % des projets de transformation numérique échouent. 83 % plus exactement, selon le Standish Group dans son dernier « Chaos report ».

Jean-Michel Palagos, acteur du projet Louvois de paie des militaires, évoque alors comme cause en 2016 :

« On avait mélangé tous les objectifs – réduction des effectifs du service de la paye, remise à plat des primes, etc. – dans un contexte d’extrême division du travail, d’entités qui ne communiquaient pas entre elles et de grande dilution des responsabilités. Le tout couplé avec une volonté farouche d’avancer le plus vite possible pour remplir les objectifs fixés au ministère par la révision générale des politiques publiques. Quand on y ajoute la foi incroyable dans les capacités imaginaires d’un logiciel à gérer les problèmes, on comprend qu’on en soit arrivé à une catastrophe de cette ampleur. On n’en avait pas pris conscience, malgré les alertes lancées en interne dès 2010. »

En sus, la diversité des cas traités (chaque militaire ou presque est un cas à part : opérations, primes, terrain…) n’avait pas été prise en compte. Cette complexité native expliquait le nombre important d’agents consacrés à ces tâches de paye. Mais, encore une fois, l’expertise de ces agents n’avait pas été prise en compte.

Les causes d’un échec sont donc multiples. Cependant, trois facteurs principaux s’imposent de manière récurrente : le manque d’implication des utilisateurs, des spécifications incompréhensibles et incomplètes, ainsi que des changements apportés en cours de projet.

Que faire pour réussir un projet informatique ?

Pour les projets d’aménagement du territoire, associer les citoyens au projet est impératif. Et cela se voit très clairement : lorsque les citoyens s’y opposent, le projet ne peut se faire.

Pour ce qui est des projets informatiques, c’est souvent l’inverse. Si un recueil des besoins initiaux auprès des utilisateurs est généralement effectué en amont, ces derniers sont ensuite tenus à l’écart jusqu’à la mise en production. Pour faire face à ces difficultés, la notion de « Maîtrise d’Usage » vient compléter le duo millénaire « Maîtrise d’Ouvrage » et « Maître d’Œuvre ».

Pour les lecteurs peu familiers avec ces notions, voici quelques définitions :

• Le Maître d’Ouvrage définit le projet, le finance et en fixe le calendrier. Il représente les utilisateurs finaux à qui l’ouvrage est destiné.

• Le Maître d’Œuvre a pour mission de faire réaliser l’ouvrage prévu dans des conditions de coût et de délais préalablement définies.

Pour prendre un exemple de la vie courante : si vous souhaitez construire une maison, vous êtes le Maître d’Ouvrage. L’architecte, qui dessine les plans et dirige les entreprises, est, quant à lui, le Maître d’Œuvre.

La notion de « Maîtrise d’Usage », importée depuis les années 2000 par le professeur Michel Germain, vient alors préciser le duo « Maîtrise d’Ouvrage » et « Maître d’Œuvre » dans la conduite de projets de transformation numérique. Le terme « Maîtrise d’Usage » pointe en effet l’importance des utilisateurs et de leurs usages dans la réalisation des différentes tâches du projet. Une importance variable en fonction de leurs formations, de leurs compétences et de leurs pratiques du métier.

Pour réussir un projet informatique, ces trois notions entrent donc en jeu.

« U do » : Usages, données et outils pour structurer votre projet

Un tas de briques empilées en vrac ne forme pas un mur solide. Il manque le ciment et les jointures. En transformation numérique, c’est la même chose. Il ne suffit pas d’appliquer un ensemble de pratiques pour avoir une transformation efficace. Il faut assembler ces pratiques pour créer une démarche : la méthode « U do » (= Usages, données et outils).

Ici, le « U » est écrit en capitale, car tout part des Utilisateurs et des Usages. Le « d » pour données et le « o » pour outils sont, quant à eux, écrits en minuscules, car ils servent les Usages.

Les utilisateurs et les usages : les workflows

À l’origine de l’analyse des usages, se situe le sens du projet : quel est le but de cette transformation ?

L’établissement de cette problématique est la première pierre à l’édifice et se situe bien en amont de l’application de la méthode « U do, mouv ! ». Je présuppose que le problème est ici bien posé, mais si ce n’est pas le cas, je vous invite à vous pencher sur la question avant de continuer.

Une fois ce but défini, la mise en place du projet doit partir de l’analyse des utilisateurs et de leurs usages. Cette analyse de la diversité des utilisateurs permettra de délimiter les tâches à informatiser et celles à ne pas informatiser, car, comme le dit si bien Michel Volle, à vouloir tout automatiser, on peut aussi se perdre.

« La plupart des systèmes d’information sont défectueux qu’il s’agisse de la définition des données, de l’ingénierie des processus ou de l’alignement stratégique. Les entreprises sont tentées de trop informatiser, de trop programmer. Les projets informatiques sont souvent voués à l’échec parce qu’ils sont d’une complication monstrueuse : on a prétendu automatiser le traitement de tous les cas particuliers, il aurait mieux valu les confier à la sagacité des êtres humains. »

La description de ces usages est alors faite dans des « Use case » ou « Cas utilisateurs », eux-mêmes articulés dans des workflows (= processus de formalisation des tâches à réaliser et avec quelle part d’informatisation).

Cette cohabitation entre tâches informatisées et non informatisées, orientée par les usages, a permis à Michel Volle de définir le concept de « cerveau d’œuvre » au lieu de « main-d’œuvre » :

« L’action productive se partage entre l’automate et l’être humain, ce dernier possédant pour interpréter les cas particuliers et répondre à des incidents imprévisibles un discernement que l’automate ne peut pas exercer. »

Les données : le modèle de données

Pour réaliser les tâches qui lui sont confiées, l’utilisateur manipule des données. Par exemple, pour entretenir une machine, l’opérateur a besoin de connaître la documentation attachée au modèle de la machine, les éléments propres à la machine et les tâches à y accomplir.

La structure des données est définie dans le modèle de données qui sera le miroir des usages. Données et usages forment donc un couple indissociable.

Les données et leurs modèles sont l’actif le plus pérenne du système. Les usages vont évoluer, les outils devenir obsolètes, la structure des données, quant à elle, restera inchangée.

Les outils : plateformes et applicatifs

Les outils permettent la manipulation des données au service des usages. Il s’agit donc de moyens et non pas d’une finalité. Autrement dit, l’outil n’est pas le projet. Nommer son projet par le nom de l’outil informatique (projet « SAP », par exemple), comme c’est souvent le cas, est donc une garantie d’échec. Et pour cause, on perd de vue la finalité pour ne plus voir que l’outil.

Les outils sont alors de deux natures : les applicatifs et les plateformes. De multiples méthodes permettent de définir et de développer ces outils : développement agile, cycle en V, cycle en W, cycle en multi V, incrémental… L’essentiel n’est pas la méthode utilisée, mais l’intention de l’équipe de conduite du projet de maintenir au premier plan les Usages et les données.

Un facteur de réussite : la représentation des Usages et des données

J’ai vécu un projet où l’offre d’un maître d’œuvre avait été sélectionnée sur sa promesse de « réaliser l’analyse profonde des usages pour définir un projet adapté ». J’ai déchanté lors du lancement. En effet, lors du premier atelier, le maître d’œuvre demandait aux utilisateurs de décrire leurs besoins directement en langage UML. À savoir que l’UML est un langage graphique de modélisation des données et des traitements. Dans ce but, le maître d’œuvre avait prévu de consommer deux jours de formation UML par agent de maîtrise utilisateurs avant de commencer à exprimer leurs besoins. Nous avons cassé le contrat !

La connaissance fine des usages et des données à la source du projet est importante, leur représentation est essentielle. De façon pragmatique, il est indispensable d’établir la représentation des usages dans des workflows et la description d’un modèle de données. Mais l’équipe projet doit animer l’appropriation par tous les acteurs du projet de représentations graphiques partageables permettant l’intercompréhension. C’est au maître d’œuvre de s’assurer que les usages et données soient compréhensibles par tous et à tous les niveaux du projet, et non pas aux utilisateurs de se former pour pouvoir être partis prenants de la transformation.

Maintenant que vous avez une structure « U do » pour votre projet, explorons ses interactions avec le contexte.

« mouv » : accentuez l’ancrage du projet dans le réel vécu de l’entreprise et des utilisateurs

Après la structure « U do », décryptons ensemble le « mouv » : métiers, organisations, user experience et visuel management.

En effet, si la structure « Usages, Données, Outils » définit le contenu du projet, elle ne traite pas de son ancrage. Et en aménagement du territoire, quand un projet est hors-sol, on parle de projet « porte-avions ». Le porte-avions est hors d’échelle, seul au milieu de l’océan hostile. Le projet d’aménagement doit être ancré dans les territoires et leurs pratiques. Il en est de même pour le projet informatique, d’où l’importance du « mouv » !

MO : les métiers et les organisations

Le process d’ancrage du projet dans l’entreprise part de la connaissance fine des métiers et des organisations. Cette connaissance s’obtient par l’analyse des usages mis en œuvre par les utilisateurs (on y revient encore !).

En effet, il existe toujours un grand écart entre le travail réel et le travail prescrit. Par exemple, j’ai examiné les usages réels d’une équipe de 4 mainteneurs dotés d’un outil de suivi depuis une dizaine d’années terrain. Pour optimiser l’efficacité de leurs tâches selon leurs compétences, un des membres de l’équipe s’occupait alors des saisies pour tous, alors qu’une proposition d’une dotation de terminal individuel imposait à chacun de faire sa propre saisie.

La réussite de la transformation numérique s’applique au travail réel, pas au travail prescrit. L’examen sur le terrain des pratiques métiers et l’association effective des utilisateurs tout au long du projet sont indispensables pour bien traiter du réel.

Chaque métier a sa culture, chaque organisation a son identité. Pour un même métier, bien des pratiques différentes sont possibles. Et elles sont toutes efficaces en fonction de chaque organisation. Il est donc primordial d’analyser la réalité du terrain propre à votre structure.

La connaissance fine de ces différentes cultures et identités permet d’outiller efficacement la transformation numérique. Car, tout comme un projet territorial s’ancre dans les identités locales, un projet de transformation numérique s’ancre dans les identités métiers et organisationnelles. Un projet calqué sur l’extérieur déclenche des anticorps qui le rejettent. Le projet périclitera au mieux en quelques années.

L’objectif d’une transformation numérique n’est donc pas de raser l’existant pour tout reconstruire. Comme l’affirme Florent Menegaux, patron de Michelin : « Contrairement à une idée reçue, il ne s’agit pas de casser les silos. Le silo est une structure nécessaire pour optimiser l’activité. C’est la connexion entre les silos qu’il faut renforcer. »

En termes urbains, il ne s’agit pas de raser les quartiers pour construire une ville nouvelle, mais bien de favoriser les échanges démultipliant l’usage des réseaux. De même dans les rapprochements d’organisations, il est utile de laisser des structures en place en développant des interactions et ramifications croisées multiniveaux. Pour Philippe Lerouge du cabinet Reliences :

« Dans un environnement perpétuellement évolutif, l’organisation vit en décalage de la stratégie. On n’a pas le temps de la faire évoluer pour répondre à des considérations stratégiques qui bougent sans cesse. Dès lors, ce sont les interconnexions créées au sein de l’organisation qui deviennent la variable d’ajustement. »

Il existe d’ailleurs une méthode d’utilisation d’« objets médiateurs » ou d’« objets frontières » qui permet d’explorer finement les divers métiers et organisations. Un article qui détaille la mise en œuvre de ces pratiques en entreprise est en cours de rédaction.

U de « User experience » : l’ancrage dans l’expérience des personnes

Quand on parle d’UX, la définition se limite souvent à la qualité graphique de l’interface entre un homme et une machine. Au-delà de l’interface, le sujet est plus vaste : il s’étend aux interactions Hommes Machine, individuellement et collectivement. Là encore, l’interaction doit être testée dans son contexte réel d’usages : les tests sur table ne sont pas représentatifs.

Un exemple d’erreur classique ? L’ergonomie défaillante des bornes de tickets de parkings payants. En arrivant devant la barrière, le conducteur s’arrête pour prendre un ticket et ouvre sa fenêtre. Surprise ! Le bouton d’appel, à utiliser exceptionnellement, tombe juste sous la main, alors que le bouton d’émission du ticket, trop bas, est masqué par la portière…

Les conditions d’usages sont tout aussi essentielles. Le plein usage d’une tablette en extérieur, et donc exposée aux intempéries, peut être limité par le froid réduisant l’autonomie de la batterie, par les reflets du soleil rendant la lecture compliquée et/ou par une connexion inexistante.

La profondeur des projets de transformation numérique moderne touche toutes les populations de l’entreprise, même les moins à l’aise avec les outils numériques. Il est d’ailleurs fréquent que 20 % des utilisateurs cibles ne possèdent ni ordinateur, ni smartphone. Ainsi, les observations sur le terrain révèlent des solidarités : « Pendant que je règle ton moteur, merci de saisir mon bordereau ».

Si les applications grand public fixent des normes de faits et un niveau de référence d’excellence ergonomique, ce n’est pas souvent le cas des logiciels professionnels. Choisir et construire ces derniers dans une démarche ergonomique, le tout accompagné d’une formation adaptée, permettra leur efficience d’usage.

Un exemple classique de logiciels professionnels bien pensés ? L’application « Slack » et ses raccourcis claviers qui multiplient la productivité.

V : l’intercompréhension par le « visuel management »

Le management visuel est un des outils d’une démarche de « Lean Management ». Je m’explique !

Chaque projet de transformation numérique rassemble une grande diversité de personnes et de cultures. L’intercompréhension entre ces personnes est un des défis majeurs de la transformation. En effet, il ne s’agit pas de discours de sens d’un dirigeant, mais de permettre l’intercompréhension d’un projet vaste, et par nature invisible, dont la compréhension détaillée doit entrer dans plusieurs têtes. Ce pour quoi, la direction de projet doit impulser une démarche de management visuel (= management par les schémas et dessins) pour répondre à cet enjeu.

Rien ne sert alors de mobiliser des graphistes ou des communicants. Il s’agit plutôt d’inciter chacun à aller au-delà des mots en mobilisant ses capacités à schématiser et dessiner pour renforcer la clarté de son expression et ainsi être mieux compris. Ce peut être une simple photo, un dessin fait à la main sur une feuille de papier, ou encore des schémas réalisés avec PowerPoint ou Excel.

Le management visuel passe aussi par l’usage d’une diversité de supports. Par exemple, pour permettre l’appropriation d’un modèle complexe de données, l’impression au format A0 d’un graphe qui sera ensuite affiché au mur s’avère très efficace. De même, dans une campagne de communication interne, l’usage d’affiches apposées près de la machine à café renforce la publication numérique.

Il est alors préférable que l’impulsion du management visuel incite à la co-construction des outils. En effet, un dessin co-construit est plus efficace qu’un dessin réalisé seul, puis plaqué dans un autre contexte. Et pour cause, le management visuel est un état d’esprit d’ouverture et de création de liens évolutifs avec les autres cultures internes mobilisées dans le projet.

Cette intercompréhension entre des personnes et des métiers hétérogènes nécessite également des médiateurs. Il est possible de mobiliser des personnes extérieures, mais il est plus efficace et moins coûteux de former des médiateurs internes. La posture de médiateur, comme celles de facilitateur ou de manager, n’est pas innée. C’est l’une des soft skills incontournable du futur.

« U do, mouv ! » ou comment maîtriser la complexité par la coopération ?

Un modèle du projet : la balançoire

Au fil de l’article, nous avons exploré chacun des composants « U do, mouv ! ». Désormais, j’aimerais détailler les interactions qui relient chacun des composants grâce au modèle de la balançoire d’enfants à deux sièges.

Nous connaissons tous le principe de la balançoire, cet objet du quotidien à la fois sympathique et familial. Elle nous évoque des souvenirs d’enfance ou bien des moments de bonheur avec nos enfants. Et c’est avec cette balançoire que nous allons assembler dynamiquement les composants du projet « U do, mouv ! ». 

Décryptons ensemble le principe de la balançoire « U do, mouv ! » :

• Les utilisateurs et leurs usages sont installés sur le siège de gauche de la balançoire.
• Les données, très hétérogènes, sont, quant à elles, empilées sur le siège de droite.
• Sachant que la balançoire s’appuie sur un axe qui comporte deux séries de roues :

Sur l’arrière de la photo, les roues de différentes couleurs et de différents diamètres représentent les infrastructures informatiques (plateformes, serveurs, cloud) ainsi que les terminaux (ordinateurs, tablettes de terrain).

• Sur l’avant de la photo, les roues dentées ou à facette représentent les applicatifs à développer et intégrer sur le même axe que les plateformes.

Enfin, les 7 barres de la structure de la balançoire matérialisent les interactions entre chaque composant. Entre les :

• données et les usages
• logiciels et les process
• données, les process et les logiciels
• …

Volontairement, chaque barre de la structure de la balançoire est différente des autres. Ces différences représentent la diversité de nature des liens. En regardant la structure, on constate que chacune des barres est indispensable à la stabilité de l’ensemble. S’il en manque une, ou si une barre est plus faible que les autres, le projet s’effondre.

La main représente l’équipe de management du projet. Elle veille à maintenir en équilibre l’ensemble du projet de transformation numérique. En prenant du champ, la main représente aussi le sens du projet : pourquoi fait-on cela ? Quel est l’objectif ?

Pour mieux comprendre cette représentation, je vous présente le récit partageable attaché au modèle dans la vidéo de 52 secondes ci-dessous :

A190829_lego_test1 from Rousseau Frédéric on Vimeo.

Les interactions et les liens

Sur ce type de balançoire, on ne peut pas jouer seul. Il faut être au moins deux et bien s’entendre sur le rythme. Cette image précise la nécessité de s’accorder en équipe pour entretenir le mouvement.

En effet, ces interactions ne sont pas statiques. À mesure du déploiement sur le terrain, la mise en œuvre des usages réels révèlent des manques dans le modèle de données. Plus que l’inventaire, c’est dans les données du workflow que des ajustements sont souvent nécessaires.

Par exemple, il est souvent complexe de consulter des rapports sur la gestion des dates. De quelle date parle-t-on ? De la date de la visite de terrain ? De la date d’émission du rapport ? De la date de réception ? De la date d’approbation ? Et que dire d’une visite annuelle de l’année N réalisée en année N+1 ?

Pour faire face à ce casse-tête, certains gestionnaires créatifs utilisent des dates au format « 5e trimestre 2015 ». Non, je n’ai pas fait de fautes de frappe ; pour ces gestionnaires, c’est bien le 5e trimestre de l’année qui permet de gérer l’attachement à l’année N des visites faites en retard l’année suivante.

Je ne recommande pas cette pratique, mais je l’ai constatée lors du déploiement d’un outil, et vous la raconte pour illustrer la variété des pratiques de terrain pour ajuster le tir.

Les outils de maîtrise de la complexité : architecture système « quasi décomposable »

Pour aller plus loin, il est utile de s’approprier les fondements de la théorie des systèmes et de la complexité. Pour Edgar Morin :

« La complexité est un paradigme qui imposerait de conjoindre un principe de distinction et un principe de conjonction. La complexité demande que l’on essaie de comprendre les relations entre le tout et les parties. Mais la connaissance des parties ne suffit pas à la connaissance du tout ; on doit faire un va-et-vient en boucle pour réunir la connaissance du tout et celle des parties. Ainsi, au principe de réduction, on substitue un principe qui conçoit la relation d’implication mutuelle entre tout et parties. »

Par exemple, la notion de système « quasi décomposable » permet de mieux comprendre ce à quoi on se confronte. Voici ce que dit Philippe Silberzahn à propos de l’Union Européenne :

« Un système est dit quasi décomposable lorsqu’il peut être divisé en sous-systèmes qui sont largement, mais pas totalement, indépendants. Le système possède alors des sous-systèmes qui peuvent évoluer de façon largement indépendante, tout en restant relié à l’ensemble, qui possède donc une identité propre, et cette identité évolue elle-même en conséquence des évolutions dans les sous-systèmes. Un système quasi décomposable s’oppose notamment aux systèmes non décomposables (Universels) dans lesquels le changement ne peut qu’être global et simultané, et aux systèmes complètement décomposables (fédéraux) où les sous-systèmes sont parfaitement indépendants. Qu’est-ce qui définit un sous-système dans un système quasi décomposable ? C’est la fréquence d’interaction. »

Ci-dessous une brève vidéo introductive à l’approche « système » :

projet : l'approche système : homme outils procédures immerges dans un environnement from Rousseau Frédéric on Vimeo.

Conclusion : passez à la pratique « U do, mouv ! »

La méthode « U do, mouv ! », présentée au fil de cet article, permet :

• de bâtir la structure générale d’un projet avec la partie « U do » pour « Usages, données et outils ». Les fondements du projet s’incarnent alors dans des workflows et un modèle de données. Cette structure donne un cadre de référence pour ordonner les actions.

• d’ancrer le projet dans les pratiques réelles de l’entreprise en touchant chacun des utilisateurs avec la partie « mouv » pour « métiers, organisations, user experience et visuel management ».

• de développer les interactions entre chacun des composants pour faire converger les actions des parties prenantes du projet.

Au-delà de la problématique des projets de transformation numérique, la méthode « U do, mouv ! » est une instance d’une méthode plus générale dénommée USO pour « Usage Symbole Ouvrage ». La méthode USO s’applique à la création dans tous les domaines, par exemple pour mieux interpréter une musique ou composer une chanson. Ce sera l’objet d’un prochain article.

En attendant, expérimentez « U do, mouv ! » sur vos projets de transformation numérique et dites-moi en commentaire ce que vous pensez de cette méthode. Quels sont vos retours d’expérience sur des sujets similaires ?

PS : Remerciements à Patrice Lerouge du cabinet Reliences et Sylvain Guilloteau pour leurs suggestions éclairantes