Un concept devenu viral
Le design thinking a suivi une trajectoire familière dans le monde du management. Un concept solide, issu de décennies de pratique professionnelle du design, a été formalisé par des institutions respectées (IDEO, Stanford d.school), puis vulgarisé à grande échelle, avant de se retrouver dilué dans un usage approximatif où le terme désigne à peu près n’importe quelle activité impliquant des post-its et un tableau blanc.
Cette trajectoire n’est pas propre au design thinking. L’agilité a connu le même cycle: des principes exigeants (le Manifeste Agile de 2001) transformés en rituels mécaniques où l’on fait des daily standups sans comprendre pourquoi, et des sprints sans livraison incrémentale réelle. Le lean, la transformation digitale et la gestion du changement ont subi des simplifications similaires. Le design thinking tel que décrit par Tim Brown dans la Harvard Business Review en 2008 était une proposition intellectuelle ambitieuse. Ce qu’on observe souvent sur le terrain ressemble davantage à un exercice de brainstorming rebaptisé.
Ce que le design thinking n’est pas
La première confusion porte sur la nature même de la démarche. Le design thinking n’est pas une méthodologie au sens où PRINCE2 ou HERMES sont des méthodologies, c’est-à-dire un ensemble structuré de processus, de rôles et de livrables. C’est un ensemble de principes de travail, une posture face aux problèmes complexes, qui peut s’intégrer à n’importe quelle méthodologie mais n’en remplace aucune.
La cible constitue une deuxième source de malentendu. Le design thinking ne s’applique pas à tous les projets. Il est particulièrement pertinent quand le problème est mal défini ou quand les parties prenantes ont des visions divergentes du besoin, situations que le PMI regroupe sous le terme de “wicked problems”. Pour un projet dont le périmètre est clair et les exigences stabilisées, les principes du design thinking apportent peu de valeur ajoutée par rapport à un cadrage classique.
Reste enfin la confusion sur le format. Un atelier de deux jours n’est pas du design thinking, c’est un exercice d’idéation collective. Le design thinking suppose une démarche dans la durée: observer le terrain, formuler des hypothèses, prototyper, tester, reformuler. Comprimer ce cycle en un workshop ponctuel revient à simuler la démarche sans en récolter les bénéfices.
Ce qui reste utile pour un chef de projet
Quand on retire le jargon et les workshops à la mode, le design thinking propose des principes dont la valeur en gestion de projet est bien établie.
L’observation terrain d’abord. Aller observer les futurs utilisateurs d’un livrable avant de rédiger les spécifications produit des résultats systématiquement différents de ceux obtenus en salle de réunion. Les besoins que les utilisateurs n’expriment pas spontanément, parce qu’ils ne les identifient pas comme des besoins, ne se révèlent que par l’observation directe. Ce principe est valable quel que soit le référentiel utilisé.
Le prototypage comme outil de validation ensuite. Présenter une maquette tangible, même rudimentaire, à des parties prenantes génère un feedback de qualité supérieure à celui obtenu par la revue d’un document de spécifications. Les personnes réagissent plus efficacement à ce qu’elles voient et manipulent qu’à ce qu’elles lisent et imaginent. L’Interaction Design Foundation documente largement cette différence.
La reformulation du problème enfin. La question “comment pourrions-nous…” (How Might We), développée par la d.school de Stanford, force à exprimer le problème du point de vue de l’utilisateur plutôt que du point de vue technique. Un chef de projet qui reformule “il faut migrer le système de facturation” en “comment pourrions-nous réduire le temps de traitement des factures pour l’équipe comptable?” ouvre un espace de solutions plus large et mieux centré sur la valeur réelle du projet.
Les conditions pour que cela fonctionne
Ces principes ne fonctionnent pas dans le vide. Ils nécessitent un environnement projet qui les rende possibles, ce qui représente souvent un défi plus important que la maîtrise des techniques elles-mêmes.
La gouvernance du projet doit prévoir des interactions directes avec les utilisateurs finaux, pas uniquement avec leurs représentants hiérarchiques. Le planning doit inclure des phases d’exploration et d’itération avant la fixation définitive du périmètre, ce qui implique de négocier avec le sponsor un espace d’incertitude en début de projet. L’équipe elle-même doit accepter que les premières semaines produisent de la compréhension plutôt que des livrables visibles, un investissement difficile à défendre dans les organisations orientées résultats immédiats.
Sans ces conditions préalables, les outils du design thinking se réduisent à ce que leurs détracteurs leur reprochent: un théâtre participatif agréable mais sans impact sur le résultat du projet. Avec elles, les principes d’observation, de prototypage et de reformulation deviennent des pratiques concrètes qui améliorent la pertinence des livrables.
Adopter les principes sans adopter le label
La question pour un chef de projet n’est pas de savoir s’il faut “faire du design thinking”, mais de reconnaître que certains de ses principes répondent à des problèmes récurrents: des cahiers des charges qui ne correspondent pas aux besoins réels, des parties prenantes qui valident des spécifications qu’elles n’ont pas comprises, des solutions techniques qui résolvent le mauvais problème.
Intégrer l’observation terrain au cadrage, prototyper avant de spécifier et reformuler les problèmes du point de vue de l’utilisateur sont des pratiques accessibles à tout chef de projet, indépendamment de sa méthodologie de référence. Elles ne nécessitent ni atelier dédié ni vocabulaire spécialisé, mais une discipline d’écoute et une tolérance à l’incertitude initiale que l’organisation doit être prête à soutenir.