19 Mai 2020, 8:05
Défaut:
by

1 comment

« Wicked Problems », les problèmes fourbes du Design

En 1973, le professeur de Conception et de Planification (Design) Horst Rittel (1930-1990) publie le papier « Dilemna in a general  theory of planning » dans lequel il formule la notion de « wicked problems », qui pourrait se traduire en français par problèmes malicieux ou vicieux.

Ces problèmes ont ceci de malicieux qu’ils ne se prêtent pas à une résolution au sens ou l’on pourrait résoudre un problème de mathématique ou d’ingénierie simple. Pour le dire différemment, il y a déjà un problème interne dans la formulation du problème, une forme d’incomplétude et d’ouverture qui change radicalement la manière dont on peut y faire face. 

Les exemples de problèmes que prend régulièrement Rittel relèvent de ce que nous pourrions appeler l’urbanisme : construction d’autoroutes, planification urbaines, aménagements territoriaux, etc. Cette nature de problèmes fait intervenir un facteur social et collectif qui les complexifie de manière maligne par rapport à la conception d’un artefact simple (aspirateur ou une souris d’ordinateur). Toute la maitrise des problèmes que l’on a pu acquérir dans le domaine scientifique et dans l’ingénierie vole en éclat dès que l’on interagit avec l’ouverture du système social (Open Societal Systems).

On pourrait penser que cette approche d’architecte urbaniste n’a pas grand chose à voir avec la conception des systèmes informatiques mais, même s’ils ont des différences irréductibles, nul ne peut nier les impacts organisationnels et sociaux du logiciel en reprenant le mot de l’homme d’affaire Marc Andreessen dans le Wall Street Journal de 2011 : « Software is eating the world ». Et encore, au-delà de l’aspect « logiciel » en tant que tel, nous pourrions également ajouter les aspects « politiques » et organisationnels que posent les projets informatiques qui contribuent encore à plus à les considérer comme étant des « wicked problems ».

Nous sommes donc tout à fait enclin à reconnaître que nombreux de nos projets de développement de logiciels s’inscrivent pleinement dans la catégorie des « wicked problems ». Mais vérifions tout de même cette hypothèse à partir de la dizaine de caractéristiques que donne Rittel de ces problèmes qui échappent à toute forme de solutionisme.  Dans la liste ci-après nous avons fait le choix de traduire « wicked problems » par « problèmes fourbes » :

  1. Il n’y a pas de formulation définitive des problèmes fourbes.
    • La manière de le formuler dépend de l’interprétation qu’en donne celui qui veut le résoudre et de sa connaissance du champ des solutions possibles qui est toujours partielle et subjective.
    • Ce qui implique que « la formulation du problème est le problème ».
    • Les phases classiques de résolution des problèmes : comprendre le problème – récupérer de l’information – analyser l’information – faire une synthèse « créative », ne vont pas fonctionner avec les problèmes fourbes. Il faut au contraire avoir une approche par argumentation collective progressive entre les parties prenantes afin de faire émerger graduellement une solution.
  2. Les problèmes fourbes n’ont pas de critère d’acceptation de solution clairs
    • Ces problèmes n’ont pas vraiment de fin, on n’arrête la conception que parce que les ressources de résolution sont épuisées : manque de temps, d’argent, de patience, de motivation, etc. A la fin, il y a toujours quelqu’un pour dire « Ça suffit,  » (that’s good enough).
  3. La solution à des problèmes fourbes n’est pas vraie ou fausse mais bonne ou mauvaise
    • La solution prend la forme d’un compromis qui est satisfaisant pour les parties prenantes, on ne cherche pas LA vérité.
  4. On ne peut pas tester immédiatement et de manière définitive une solution à un problème fourbe.
    • S’insérant par nature dans une intrication de systèmes (psychiques, collectifs, technologiques, économiques, etc.), toute implémentation d’une solution a des effets de bord systémiques avec des vagues de conséquences quasi intraçables dans un temps limité.
  5. Toute solution à problème fourbe est une opération définitive ; parce qu’il n’y a pas l’opportunité d’apprendre par essai-erreurs, chaque tentative de résolution compte significativement.
    • C’est probablement le point le plus critiquable si on le regarde depuis le champ des systèmes logiciels où la possibilité de faire des essais et des erreurs est devenue une partie intégrante des méthodes agiles de développement logiciel. Mais que l’on pense à des projets logiciels qui doivent se faire dans un contexte de systèmes existants historiques (legacy systems, brown field) et cette différence de nature tend à s’estomper.
  6. Les problèmes fourbes ne peuvent pas faire l’objet d’une liste exhaustive de solutions potentielles 
    • On ne peut pas s’en sortir par la simple réutilisation de patterns déjà éprouvés, il y a toujours un moment où, collectivement, on va se dire : «  Ok, essayons ça alors ».
  7. Tout les problèmes fourbes sont essentiellement uniques.
    • Ils peuvent avoir de nombreuses ressemblances et similarités avec d’autres problèmes, mais il y a toujours ce petit supplément qui change la donne de manière radicale.
  8. Tout problème fourbe peut être considéré comme le symptôme d’un autre problème.
    • Si un problème peut être décrit comme étant un écart entre une situation existante et une situation espérée, alors la résolution de ce problème commence généralement par la recherche de la cause de cet écart. Cette cause devenant elle-même un nouveau problème pour lequel on va s’enquérir d’un nouvel écart qui donnera lieu à un nouveau problème, etc. Cet aspect fractal et potentiellement infini de l’enchaînement des problèmes n’est pas sans rappeler cette pratique des enfants qui vous demandent « pourquoi ? » à chacune de vos réponses jusqu’à que vous soyez épuisé et leur répondiez : « Parce que !! » . 
    • En remontant ainsi de problème en problème on arrive à des problèmes d’un très grande généralité dont la résolution peut donner le vertige, d’où la tentation inverse d’essayer de résoudre le problème à partir de sous-problème de manière incrémentale. Ce à quoi Rittel répond que des amélioration marginales et locales ne garantissent pas pour autant une amélioration globale du problème. L’exemple donné est celui d’un logiciel qui résout effectivement un problème mais qui surtout le déplace sur les utilisateurs et l’organisation.
  1. L’existence d’un écart représentant un problème fourbe peut être expliquée de nombreuse façons. Le choix d’une explication va déterminer la nature de la résolution du problème.
    • Nous sommes dans un domaine de causalités floues ou il n’y a pas de règles ou de procédures pour déterminer la véracité d’une explication. La raison en est qu’il y a beaucoup plus de façons de réfuter une hypothèse qu’il n’y en a dans les sciences.
  2. Le Designer n’a pas le droit de se tromper.
    • Selon Karl Popper (à qui Ritter reprend le mot « Wicked ») la solution à un problème scientifique n’est qu’une hypothèse en attente de réfutation et, en ce sens là, nul ne fera le reproche à un scientifique de faire des hypothèses et d’élaborer des théories car c’est la règle du jeu dans le domaine scientifique. 
    • Le designer ne jouit pas des même privilège et doit rendre des comptes, attendu qu’il ne recherche pas la vérité mais doit « améliorer le monde dans lequel nous vivons ».

En résumé : Les designers doivent faire face à des problèmes fourbes qui défient leur efforts pour délimiter leur périmètre, leurs frontières et le tissu de leurs causalités.

[…] faciles à reconnaitre : ils préfèrent s’attacher à délimiter les problèmes (les « wicked problems »), plutôt qu’à pousser des solutions toutes […]

 

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.