Souvent, dans des situations très différentes, on se retrouve à devoir mener des analyses. Qu’il s’agisse d’analyse technique sur le choix d’un algorithme, d’une analyse ergonomique concernant un webdesign, ou d’autre chose, il y a deux grandes façons de mener ces études.

L’approche brutale

C’est la démarche la plus courante. Elle consiste à récolter des données brutes sur la chose à analyser, puis d’utiliser ces données pour dégager des tendances, et tenter d’aboutir à une conclusion. À partir de là, il est possible d’envisager une ou plusieurs solutions au problème.

Cela peut être très efficace. Google est notamment connue pour monitorer tout ce qui est possible et imaginable. Quand vous avez de grandes quantités de données brutes, vous pouvez par exemple les faire passer dans une machine à vecteurs de support pour générer un modèle, puis faire des prédictions grâce à ce modèle.
Vous pouvez ainsi apprendre des choses que vous ne soupçonniez même pas. Ce n’est pas de la science-fiction, PHP supporte la libsvm, c’est assez amusant.

Néanmoins, il s’agit là d’une approche « de riche ». Car il faut partir du principe que toutes les données sont utiles ; donc il faut tout monitorer. Et il faut prendre le temps de générer des modèles et de les analyser finement. Tout ça est très chronophage.

L’analyse menée par les hypothèses

L’autre manière de faire, c’est de commencer par définir les quelques hypothèses de départ, qui vont mener à un nombre restreint de scénarios possibles.
Face à un problème donné, il y a rarement une infinité de scénarios possibles. Quand on prend le temps d’y réfléchir, on peut souvent dégager 2 ou 3 tendances principales, ainsi que quelques autres possibilités ayant une très faible probabilité d’apparition.

L’idée est alors de prendre chaque scénario un à un, et de réfléchir à la décision que vous prendrez si ce scénario venait à être vérifié. Il peut alors se passer trois choses :

• Tous les scénarios conduisent à la même décision. C’est beaucoup plus fréquent que ce qu’on pourrait croire. Dans ce cas-là, c’est très simple ; inutile de passer du temps à pousser plus loin l’analyse du problème, vous pouvez mettre directement en œuvre la solution.
• Une majorité de scénarios mènent à la même décision, et un ou deux scénarios dirigent par contre vers un choix « alternatif ». Il faut alors réfléchir un peu. Peut-être que le choix alternatif a au final une probabilité de vérification extrêmement faible, et dans ce cas il faut se préparer le mieux possible au scénario nominal. Ou au contraire, il n’est pas si marginal mais représente un risque important, et alors il vaut mieux y consacrer du temps et de l’énergie.
• Dernière possibilité, il existe une multiplicité d’hypothèses équiprobables. Dans ce cas, on en revient à un besoin d’analyses plus poussées. Mais dans mon expérience passée, ce genre de cas est particulièrement rare.

Évidemment, il ne faut pas s’arrêter au premier scénario que l’on est capable d’imaginer. Et s’il y a un risque patent que des scénarios ne soient pas discernables à l’avance, il vaut mieux partir sur une analyse classique.

Vous n’imaginez pas le nombre de fois où j’ai pu me retrouver dans une discussion, nous préparant à chercher des infos pendant des jours voire des semaines, pour finalement conclure qu’on prendra de toute façon la même décision, quel que soit le résultat de cette étude. Mais si on n’avait pas fait l’effort de pousser la réflexion jusque-là (ce qui n’est pas toujours évident quand on est au cœur d’un problème), le coût pour l’entreprise aurait été conséquent.

Attention, il ne faut pas confondre cette approche avec les résolutions de problème « orientées solution ». Celles-ci partent du principe que vous avez un ensemble de solutions applicables à votre disposition, et que vous allez piocher dedans pour trouver la bonne solution à utiliser pour solutionner le problème auquel vous êtes confrontés.
Pourtant cette méthode peut se révéler très efficace lorsqu’on est confronté à des problèmes déjà rencontrés, pour lesquels les solutions sont connues et leur mise en œuvre bien balisée. Mais elle empêche souvent de trouver une solution novatrice face à des scénarios inhabituels. Pour paraphraser Maslow : quand on n’a qu’un marteau dans sa boîte à outil, on finit par croire que tous les problèmes sont des clous.

Par contre, le test A/B est une certaine forme d’application de l’analyse par hypothèses. Le cas d’utilisation le plus typique est une page web devant présenter un formulaire, et pour laquelle on va chercher à obtenir le meilleur taux de transformation.
On formulera plusieurs hypothèses (ça transformera moins si on rend obligatoire la saisie de tel champ ; il faut une image d’habillage plaisante ou au contraire ne pas distraire le visiteur ; etc.). En regroupant ces hypothèses, on peut faire une analyse fine qui conduire à préparer plusieurs déclinaisons de la page. Sauf que là, on part du principe qu’on ne peut pas savoir laquelle transformera le mieux, et ce sera l’usage réel de la page qui déterminera la solution retenue.