Votre problématique, c'est tout le projet : comment la formuler

Une bonne problématique dit qui est concerné, ce qui lui arrive, quand et où cela se produit, et pourquoi c'est important, en deux ou trois phrases simples, sans solution cachée à l'intérieur. Rédigez-la à partir de faits, pas d'opinions, précisez ce qui est hors périmètre, et faites-la relire par des personnes extérieures à l'équipe avant de produire la moindre idée. Si cette étape est solide, toutes les suivantes, des idées aux prototypes jusqu'au business case, reposent sur un socle ferme.

Pourquoi la problématique décide du projet

Les équipes échouent rarement faute d'idées. Elles échouent parce qu'elles ont résolu un problème que personne n'avait, qu'elles ont traité la mauvaise partie d'un vrai problème, ou qu'elles se sont disputées pendant des semaines parce que chacun, sans le dire, travaillait sur un problème différent. C'est dans la problématique que ces échecs commencent, ou s'arrêtent.

Trois raisons lui donnent autant de poids. Elle fixe la limite de ce qui compte comme une bonne idée. Elle indique à qui parler et quoi mesurer. Et c'est la phrase dont la direction se souviendra : elle conditionne donc le soutien que recevra le travail. Une problématique floue ne reste pas floue ; elle est remplie par la personne qui a le plus d'autorité dans la salle.

Les cinq éléments d'une problématique exploitable

Une problématique sur laquelle on peut agir répond à cinq questions :

1. Qui est concerné ? Un groupe précis, pas « les utilisateurs » ni « les parties prenantes ». « Les primo-demandeurs dont le dossier est incomplet » désigne quelqu'un. « Les clients », non.
2. Que leur arrive-t-il ? La situation observable, dans leurs mots. Quelque chose que l'on pourrait voir ou compter.
3. Quand et où cela se produit-il ? Le moment ou le canal. C'est souvent là que se cache la véritable découverte.
4. Pourquoi c'est important, pour eux et pour l'organisation. Le coût de l'inaction : temps, argent, confiance, risque.
5. Ce que l'on sait, et comment. Une ligne sur les preuves : entretiens, données de réclamations, observation. C'est ce qui garde la problématique honnête.

Beaucoup d'équipes ajoutent une sixième ligne tout aussi utile : ce qui n'est pas le problème. L'analyse « est / n'est pas » de Kepner-Tregoe est une manière classique de le faire. Préciser, par exemple, que le problème touche les demandes en ligne mais pas les agences réduit immédiatement le champ de recherche.

Comment la rédiger, étape par étape

1. Écrivez un premier jet, vite et mal. Chacun rédige sa propre version du problème en une phrase, en silence, en trois minutes. Mettez-les côte à côte. Leurs différences sont votre premier constat : elles montrent où l'équipe n'est pas encore d'accord.
2. Retirez les solutions. Soulignez tout mot qui décrit un remède : « application », « portail », « formation », « absence de système ». « Nous n'avons pas de système de réservation » est une solution déguisée. Réécrivez chaque phrase comme la situation que vivent les personnes : « Les clients ne peuvent pas savoir à l'avance si un créneau est libre. »
3. Demandez pourquoi, puis ce qui l'empêche. Utilisez les 5 pourquoi ou un arbre à problèmes pour passer du symptôme à la cause. Arrêtez-vous au niveau sur lequel l'équipe peut réellement agir. Trop profond, vous finissez sur « la conjoncture » ; trop superficiel, vous ne traitez que les symptômes. Pour aller plus loin, lisez comment trouver la cause racine d'un problème.
4. Allez vérifier sur le terrain. Soumettez le brouillon à cinq ou six personnes qui vivent le problème. Menez des entretiens avec les parties prenantes et demandez-leur de raconter la dernière fois où c'est arrivé, pas ce qu'elles en pensent en général. Si leur récit ne correspond pas à votre problématique, changez la problématique.
5. Remplissez les cinq éléments. Réécrivez avec le qui, le quoi, le quand et le où, le pourquoi c'est important, et ce que vous savez. Trois phrases maximum. S'il vous en faut davantage, vous avez probablement deux problèmes.
6. Posez les limites. Ajoutez une ligne sur ce qui est hors périmètre et une sur les contraintes à respecter : réglementation, cycle budgétaire, ou un système que vous ne pouvez pas modifier cette année.
7. Transformez-la en point de vue. Un énoncé de point de vue, le format utilisateur–besoin–insight enseigné par la d.school de Stanford, condense le problème en une phrase humaine : « [Qui] a besoin de [besoin] parce que [insight]. »
8. Ouvrez-la sous forme de questions. C'est seulement maintenant que vous écrivez des questions « Comment pourrions-nous » à partir de la problématique. Pour des exemples de bonnes et de mauvaises questions, voyez 10 questions « Comment pourrions-nous » : cinq bonnes, cinq mauvaises.
9. Testez-la auprès d'un regard extérieur. Lisez-la à quelqu'un d'un autre service. Demandez-lui de vous reformuler le problème et qui le rencontre. S'il n'y arrive pas, elle n'est pas prête.

Avant et après

À faire, à éviter

À faire

• Rédiger la problématique dans la langue des personnes concernées, pas dans le jargon interne.
• L'appuyer sur quelque chose que vous avez observé ou entendu, et dire quoi.
• La garder assez courte pour la dire à voix haute en vingt secondes.
• La réviser ouvertement quand de nouvelles preuves arrivent, et conserver les anciennes versions pour que l'équipe voie comment sa compréhension a évolué.
• Utiliser la cartographie des hypothèses pour lister ce que vous croyez encore sans l'avoir vérifié.

À éviter

• Laisser la problématique contenir une solution, une technologie ou le nom d'un service présenté comme la cause.
• La rédiger en réunion, sans aucune preuve, et la déclarer définitive.
• La rendre si large que n'importe quelle idée y entre, ou si étroite qu'une seule idée y entre.
• Employer « le manque de » comme verbe principal. Cela cache presque toujours une solution.
• Sauter la ligne « pourquoi c'est important ». Sans elle, le travail perdra son soutien à la première revue budgétaire.

Exemple illustratif

Illustratif. Une municipalité australienne a demandé à son équipe de service de « créer un portail en ligne pour les permis de construire ». Le premier jet de l'équipe reprenait la commande. Plutôt que de lancer le développement, deux membres de l'équipe ont passé une semaine au guichet des permis et ont parlé avec huit demandeurs et quatre instructeurs.

Ce qu'ils ont entendu était tout autre. La plupart des demandes étaient déjà déposées en ligne. Le retard intervenait après le dépôt : une grande partie des dossiers examinés avait été renvoyée pour pièces manquantes, et les demandeurs ne comprenaient pas les courriers de demande de compléments. Les instructeurs passaient une bonne partie de leur journée au téléphone à les expliquer.

La problématique réécrite disait : « Les particuliers qui demandent un permis pour de petits travaux déposent souvent des dossiers incomplets, parce que les exigences sont réparties dans plusieurs documents et que les courriers de demande de compléments emploient un langage technique. Chaque renvoi ajoute des semaines à la procédure et remplit le temps des instructeurs d'appels d'explication. Cela concerne les petits travaux résidentiels, pas les projets commerciaux. »

Les idées qui ont suivi étaient moins chères et plus rapides qu'un portail : une check-list d'une page par type de projet, des courriers en langage clair et un court appel avant dépôt. L'idée du portail n'a pas été rejetée ; elle a simplement cessé d'être le point de départ.

Les questions que l'on pose souvent

Quel est un bon exemple de problématique ? Une bonne problématique nomme un groupe précis, décrit ce qui lui arrive et quand, dit pourquoi c'est important, et ne contient aucune solution. Par exemple : « Les infirmières de nuit manquent des informations de relève parce que les transmissions sont écrites à trois endroits différents, ce qui entraîne des vérifications à répétition au début de chaque poste. »

Quelle longueur doit faire une problématique ? Deux ou trois phrases, plus une ligne sur le périmètre. S'il vous faut une page entière, soit vous décrivez plusieurs problèmes, soit vous y avez glissé votre solution. Une problématique courte est plus facile à tester, à retenir et à partager avec la direction.

Quelle différence entre une problématique et une question « Comment pourrions-nous » ? La problématique décrit la situation telle qu'elle est, à partir de preuves. Une question « Comment pourrions-nous » la transforme en invitation ouverte à produire des idées. Rédigez d'abord la problématique, puis tirez-en plusieurs questions, chacune sous un angle différent.

Pour aller plus loin

Travaillez avec les guides arbre à problèmes et les 5 pourquoi pour trouver la cause, puis condensez-la avec un énoncé de point de vue et ouvrez-la avec les questions « Comment pourrions-nous ». Pour situer cette étape dans l'ensemble de la démarche, lisez le design thinking, étape par étape et le guide de référence quel outil d'innovation choisir.