Quand les réunions reproduisent les problèmes qu’elles tentent de résoudre
Les équipes projet fonctionnent avec un handicap rarement identifié: leurs propres réflexes cognitifs. Le biais de confirmation (tendance à interpréter l’information de façon à valider ses croyances existantes) pousse un responsable technique à défendre la solution qu’il connaît plutôt qu’à explorer celles qu’il ignore. Le biais de statu quo (préférence systématique pour la situation actuelle) freine toute remise en question d’un processus établi. Le suroptimisme conduit à sous-estimer la complexité réelle d’un livrable.
Ces biais ne sont pas des défauts individuels: ce sont des mécanismes universels, documentés depuis des décennies par la psychologie cognitive. Le problème survient quand une réunion de projet réunit dix personnes dont chacune arrive avec ses propres biais, et que le format de la discussion les amplifie au lieu de les atténuer. Le plus expérimenté parle en premier, les autres s’alignent, et le groupe converge vers une solution qui rassure tout le monde sans nécessairement répondre au problème.
Ce que Liedtka a observé pendant sept ans
Jeanne Liedtka, professeure à la Darden School of Business de l’Université de Virginie, a analysé 50 projets recourant au design thinking dans des secteurs aussi variés que la santé, les services publics et l’industrie. Son étude publiée dans Harvard Business Review en 2018 aboutit à une conclusion qui déplace le débat: le design thinking ne fonctionne pas parce qu’il génère de meilleures idées, mais parce qu’il constitue une “technologie sociale”, un système de pratiques qui modifie les comportements collectifs et neutralise les biais qui paralysent les équipes. On présente souvent le design thinking comme une méthode de créativité ou d’innovation, mais Liedtka démontre que son apport principal est ailleurs: il restructure la manière dont un groupe humain aborde un problème.
Comment les exercices contournent les biais
Chaque phase du design thinking correspond, dans cette lecture, à un mécanisme correctif précis.
L’immersion terrain contre le biais de confirmation
Quand une équipe va observer des utilisateurs dans leur contexte réel (la phase dite d’empathie), elle ne collecte pas simplement des données: elle se confronte à des situations qui contredisent ses hypothèses de départ. Un chef de projet convaincu que le problème est technique découvre que les utilisateurs contournent l’outil non pas parce qu’il dysfonctionne, mais parce que le processus administratif qui l’entoure est incompréhensible. Ce type de découverte ne se produit pas en salle de réunion, où chaque participant arrive avec un cadre d’interprétation déjà formé et tend à filtrer les informations qui le contredisent.
Le prototypage rapide contre l’attachement aux idées
Construire un prototype en carton ou en wireframe en trente minutes change fondamentalement la relation à l’idée. On ne défend plus “sa” solution, on teste une hypothèse jetable. Le coût psychologique de l’abandon est faible, ce qui permet à l’équipe d’itérer sans les batailles territoriales qui accompagnent habituellement les phases de conception. Les psychologues appellent ce phénomène l’escalade d’engagement: plus une équipe a investi de temps dans une direction, plus elle résiste à l’abandonner, indépendamment de la qualité des résultats obtenus. Le prototypage rapide court-circuite cette dynamique en maintenant l’investissement initial à un niveau si bas que pivoter ne coûte rien.
Les exercices structurés contre les dynamiques de groupe
Le Gallery Walk (exercice où les participants circulent silencieusement devant des affichages de résultats et y ajoutent leurs annotations) illustre un principe clé: produire une base de données commune sans passer par la négociation verbale. Chaque participant contribue à partir de la même matière première visuelle, ce qui évite que les personnalités dominantes orientent la discussion. Le groupe converge naturellement vers les points saillants, sans qu’un compromis ait été négocié.
L’effet miroir sur les équipes elles-mêmes
Un aspect que Liedtka souligne et que les praticiens mentionnent rarement: le design thinking transforme autant les équipes que les solutions qu’elles produisent. L’immersion dans les contextes utilisateurs reconfigure la manière dont les membres du groupe formulent les problèmes. Un ingénieur qui a passé une journée à observer comment des patients naviguent dans un hôpital ne pose plus les mêmes questions en réunion de cadrage.
Dans le cas de Monash Health en Australie, une équipe hospitalière a utilisé le design thinking pour repenser la prise en charge des patients chroniques. Le résultat mesurable (une chute de 60% des rechutes) est spectaculaire, mais Liedtka note que le changement le plus durable a été la transformation de la culture d’équipe. Les soignants ont continué à utiliser les méthodes d’observation et de prototypage bien après la fin du projet formel, intégrant ces pratiques dans leur manière quotidienne d’aborder les problèmes complexes. Ils avaient acquis un réflexe: aller voir sur le terrain avant de formuler un diagnostic en salle de réunion.
Quand le design thinking apporte réellement de la valeur
Comprendre ces mécanismes permet de savoir quand le design thinking est pertinent et quand il ne l’est pas. Il produit ses meilleurs résultats face à ce que Horst Rittel et Melvin Webber ont nommé des “wicked problems” (problèmes mal définis dont les paramètres changent à mesure qu’on tente de les résoudre): des situations où le périmètre est flou, où les parties prenantes ont des visions divergentes, où la solution n’est pas déductible des données disponibles.
En revanche, quand le problème est clairement défini, que la solution technique est connue et que l’enjeu principal est l’exécution, les exercices de design thinking deviennent un formalisme superflu. Organiser un atelier d’empathie pour un projet dont le scope est verrouillé depuis six mois relève du rituel, pas de la méthode.
Le Design Council britannique propose d’ailleurs un modèle utile pour opérer cette distinction. Le Double Diamond sépare explicitement les phases de divergence (explorer le problème, remettre en question les hypothèses) des phases de convergence (sélectionner une direction, livrer une solution). En pratique, cette grille aide un chef de projet à identifier dans quel type de phase se trouve son équipe: si le problème est encore mal compris, les outils de divergence du design thinking (immersion, idéation libre) sont pertinents. Si le problème est défini et que l’équipe doit converger vers une solution, d’autres approches (analyse structurée, priorisation, planification) seront plus efficaces.
De la méthode mécanique à l’outil de diagnostic
La différence entre un chef de projet qui “fait du design thinking” et un autre qui en tire réellement parti tient souvent à cette compréhension des mécanismes. Le premier applique les cinq phases dans l’ordre parce qu’on lui a appris à le faire. Le second sait pourquoi l’immersion terrain fonctionne (elle court-circuite le biais de confirmation), pourquoi le prototypage rapide débloque les équipes (il réduit le coût psychologique de l’échec), et pourquoi les exercices silencieux produisent de meilleurs résultats que les brainstormings classiques (ils neutralisent les effets de dominance).
Cette connaissance des ressorts permet d’adapter les exercices au contexte plutôt que de les reproduire mécaniquement. Elle permet aussi de savoir quand s’en passer, ce qui est peut-être la compétence la plus utile.