Le « quoi » ou le « comment » : le premier piège des projets de transformation
par Nicolas Henckes, fondateur et CEO
Il y a une erreur que je constate régulièrement dans les projets de développement de produits ou de transformation numérique, tant dans les PME que dans les grandes entreprises : confondre les exigences fonctionnelles avec les solutions techniques.
Ce n'est pas un problème de compétences. C'est un problème de formulation.
« Des chevaux plus rapides »
On attribue souvent à Henry Ford une phrase qui est presque devenue un cliché du monde de l'entreprise : «Si j'avais demandé à mes clients ce qu'ils voulaient, ils auraient répondu : des chevaux plus rapides. » L'authenticité de cette citation est contestée (aucune source primaire vérifiée n'a jamais été trouvée), mais l'idée a perduré car elle reflète une réalité.
Ce que les clients expriment est limité par ce qu'ils savent déjà. Ils décrivent le monde tel qu'il est, et non tel qu'il pourrait être. Ils demandent des améliorations à ce qu'ils connaissent plutôt que des alternatives à ce qu'ils connaissent.
Ce qu'il faut retenir, c'est que cela ne s'applique pas uniquement aux clients.
Cela vaut également pour les personnes au sein de votre organisation.
Lorsque vous demandez à une équipe ce dont elle a besoin, elle vous décrira ce qui lui manque dans les outils qu’elle utilise déjà. Elle demandera davantage de fonctionnalités pour le système actuel. Une automatisation accrue du flux de travail actuel. Une version améliorée de ce dont elle dispose déjà.
Ce n'est pas faux. C'est tout à fait naturel. Mais ce n'est pas la même chose que de comprendre ce qu'ils doivent réellement accomplir.
Pourquoi cela se produit-il ? Et pourquoi s'agit-il d'un problème structurel ?
Les équipes ne décrivent pas leurs besoins en abstrait. Elles les décrivent en fonction de la réalité dans laquelle elles évoluent au quotidien : le système auquel elles se connectent chaque matin, les solutions de contournement qu’elles ont mises en place au fil des ans, les fonctionnalités qui les ont frustrées la semaine dernière.
Il est pratiquement impossible de s'affranchir de ce cadre de référence lorsqu'on se trouve à l'intérieur. Ce n'est pas un manque d'imagination, mais la conséquence normale d'une immersion dans un contexte opérationnel. Plus on est proche du quotidien, plus il est difficile de dissocier ce que l'on cherche à accomplir de la manière dont on s'y prend actuellement.
Cela comporte également une dimension organisationnelle. Dans de nombreuses entreprises, les demandes de fonctionnalités ne sont pas seulement des préférences techniques : ce sont des prises de position politiques. Une équipe demande une fonctionnalité spécifique parce qu’elle reflète sa vision du fonctionnement de l’organisation, des données qui devraient être prioritaires et du flux de travail qui devrait être par défaut. Cette demande recèle des hypothèses sur le pouvoir et les priorités qui sont rarement exprimées ouvertement.
C'est pourquoi le fait de recueillir les exigences lors d'un atelier et d'appeler cela une « analyse des besoins » aboutit souvent à un inventaire détaillé de la situation actuelle plutôt qu'à une image fidèle de ce qui doit changer.
La distinction qui change tout
Le cadre « Quoi vs. Comment » n'est pas une méthodologie. C'est une discipline de la pensée.
Quoi : l'objectif fonctionnel de l'utilisateur, ce qu'il cherche à accomplir, indépendamment de tout outil ou processus.
Comment : la manière dont ils envisagent de le réaliser, l'interface, le flux de travail, la logique technique.
Un exemple simple tiré du secteur public : lorsque les pouvoirs publics ont déployé des services numériques au début des années 2010, les commentaires des citoyens réclamaient systématiquement « une version simplifiée du formulaire papier ». Ce dont les gens avaient réellement besoin, c'était d'accomplir une démarche, de renouveler un permis ou de demander une prestation, sans obstacles inutiles. Le formulaire n'était que le « comment ». Supprimer complètement le formulaire était souvent la bonne solution.
Autre exemple tiré du domaine des logiciels d'entreprise : les équipes qui migrent depuis des systèmes ERP hérités demandent systématiquement à « reproduire les anciens écrans ». Le « comment » est clair. Quant au « quoi » (accéder aux bonnes données au bon moment pour prendre une décision), il peut souvent être satisfait de manière radicalement différente.
Lorsque ces deux aspects sont confondus dans les spécifications, on finit par créer des outils complexes qui répondent aux demandes sans pour autant résoudre les problèmes.
C'est justement au moment où il est le plus difficile de la mettre en pratique que cette distinction revêt toute son importance : au début d'un projet, alors que tout le monde est sur la même longueur d'onde et plein d'enthousiasme, et que personne n'a envie de ralentir pour se demander si la vision commune est réellement partagée par tous.
Concrètement, cela se traduit comme suit
Dans les projets sur lesquels je travaille, je m'efforce de séparer ces deux niveaux dès le départ.
Tout se résume à quelques questions posées directement aux équipes :
« Si le système actuel n'existait pas, comment décririez-vous ce dont vous avez besoin ? »
« Qu'est-ce qui vous ralentit réellement aujourd'hui, non pas au niveau de l'outil, mais dans votre travail ? »
« Si cette fonctionnalité venait à disparaître demain, qu'est-ce que vous ne pourriez plus faire ? »
Cette dernière question est particulièrement utile. Elle permet de faire le tri parmi les demandes accumulées et d'aller droit au cœur du problème.
Mais poser des questions n’est qu’une partie du travail. Le plus difficile consiste à créer les conditions permettant aux gens de répondre en toute honnêteté. Dans de nombreuses organisations, le processus de recueil des besoins sert également à se mettre en avant : les équipes s’en servent pour démontrer leur pertinence, préserver leur budget ou signaler leurs priorités à la hiérarchie. Une question telle que « De quoi avez-vous réellement besoin ? » peut être perçue comme un piège si la culture d’entreprise n’a pas créé un espace propice à ce genre de franchise (voir notre article sur le Servant Leadership).
Cela signifie qu’un travail efficace axé sur le « quoi » plutôt que sur le « comment » ne se limite pas à l’analyse. Il repose sur la confiance, et la confiance prend du temps à s’instaurer. Dans le cadre d’un engagement à long terme, c’est quelque chose que l’on peut développer progressivement. Dans le cadre d’un mandat court, il faut la gagner rapidement – ce qui implique souvent de commencer par les personnes les plus éloignées des jeux politiques et les plus proches du terrain.
Il ne s'agit pas d'un simple exercice théorique. C'est ce qui permet de distinguer les besoins réels des artifices organisationnels – ces fonctionnalités qui existent simplement parce que « nous avons toujours fait ainsi », et qui ont été conservées au fil des migrations de systèmes successives sans que personne ne s'interroge sur leur utilité.
Le prix à payer en cas d'erreur
Lorsque l'on ne fait pas la distinction entre « quoi » et « comment » dès le début d'un projet, on observe généralement l'un des deux scénarios suivants.
Le premier écueil est la surconception : une solution techniquement aboutie, mais inutilisable sur le plan opérationnel. Toutes les exigences ont été satisfaites. Le système fait ce qu’on lui a demandé. Mais les personnes censées l’utiliser le trouvent trop complexe, trop rigide ou tout simplement inadapté à leur façon de travailler. Son adoption est faible. L’investissement échoue en silence.
Le deuxième problème est celui de la dérive des objectifs, en l'absence de principe de résolution clair. Sans une compréhension solide de l'objet du projet, il est impossible d'évaluer les demandes de fonctionnalités concurrentes. Chaque nouvelle demande est potentiellement valable. Le projet prend alors des proportions illimitées, ou bien il est interrompu de manière arbitraire lorsque le budget est épuisé, laissant place à une solution partielle qui ne satisfait personne.
Ces deux issues coûtent cher. Elles pourraient toutes deux être évitées. Et elles trouvent généralement leur origine dans la même erreur commise dès le départ : ne pas prendre le temps de se demander à quoi sert réellement ce travail.
La dimension managériale
Dans les situations de transition, qu'il s'agisse d'une transformation numérique, d'une réorganisation ou d'un changement de système, ce travail de cadrage est rarement mené en interne. Les équipes sont trop impliquées dans le sujet, trop accablées par les exigences opérationnelles et trop exposées aux pressions politiques internes pour pouvoir garder la distance nécessaire.
C'est là l'un des avantages concrets d'un regard extérieur à ces étapes : il ne s'agit pas seulement de « faciliter », mais de poser les bonnes questions au bon moment, avant que les choix techniques ne deviennent irréversibles.
Un responsable externe expérimenté apporte quelque chose qui est souvent sous-estimé dans les processus de transformation : la liberté de poser des questions naïves. Non pas parce qu’il ne comprend pas l’entreprise, mais parce qu’il n’est pas prisonnier de son histoire. Il peut dire : « Je comprends que cela a toujours fonctionné ainsi, mais pourquoi ? » sans menacer la position de quiconque ni raviver de vieilles blessures organisationnelles.
Cela ne signifie pas pour autant que les réponses viennent de l'extérieur. Ce sont toujours les personnes au sein même de l'organisation qui comprennent le mieux son fonctionnement. Le rôle du regard extérieur n'est pas de se substituer à ce savoir, mais de le faire émerger : poser les questions que les acteurs internes ne peuvent pas facilement se poser entre eux, et prendre suffisamment de recul par rapport aux méthodes existantes pour que le véritable objectif devienne visible.
Par où commencer
Si vous vous lancez dans un projet de transformation et que vous souhaitez appliquer cette méthode, la chose la plus utile que vous puissiez faire avant la première séance de recueil des besoins est de convenir d'un principe avec votre équipe : chaque demande sera consignée dans deux colonnes. Ce que l'utilisateur doit accomplir. Comment il envisage actuellement de s'y prendre.
C'est dans l'espace entre ces deux colonnes que se déroule le véritable travail de conception.
Ce que souhaite l'équipe et ce dont l'organisation a réellement besoin sont souvent deux choses différentes. Prendre le temps de faire la distinction entre les deux dès le début d'un projet, c'est ce qui distingue une simple mise en œuvre d'une véritable transformation.
---
Par Nicolas Henckes, fondateur et PDG de Kitsune Advisory. Kitsune Advisory propose des services de direction intérimaire et de CEO Fractionnel à des entreprises au Luxembourg, en France, en Belgique, en Allemagne et en Suisse.
