Certains logiciels d'analyse ont une complexité telle qu'obtenir des résultats complets peut être très long. D'un point de vue usage, on peut les re-découper en 2 classes : ceux dont on a absolument besoin qu'ils finissent leur travail pour utiliser les résultats, et ceux dont on peut utiliser les résultats partiels. Un exemple des premiers sont les SAT-solvers utilisés en microélecronique car leur réponse est binaire : soit on peut, soit on ne peut pas couvrir les équations. Comme exemple des seconds, les simulateurs temporels (en électronique analogique par exemple), ils travaillent à temps croissant et donc on peut lire le début des résultats pendant qu'ils calculent le reste. Les logiciels de la première catégorie s'utilisent à la machine à café : 2min de modification des données d'entrée et 2h à la machine à café à attendre les résultats (quand un un algorithme pareil tourne sur la machine, même Word est inutilisable).
La machine à café
Je suis intervenu sur une application issue de la recherche universitaire ayant une forte composante "machine à café", elle délivrait une série de résultats dont chaque fragment était potentiellement très long à calculer. Un des problème est que le logiciel peut renvoyer un résultat 2s, 2h, 10h ou jamais après le résultat précédent. Le "jamais" venant d'une contradiction dans les données d'entrée (aider l'utilisateur à ne pas en faire ou à trouver d'où elle vient est un sujet de thèse). Le problème de ce "jamais" est qu'après un certain temps l'utilisateur n'a plus d'espoir de trouver le reste des résultats, il peut donc arrêter le calcul et aller analyser ses données d'entrée pour comprendre pourquoi. Il suffit d'un seul "jamais" pour que toute la session de calcul laisse l'utilisateur perplexe. Une excellente question est de savoir si le système tourne sans espoir ou s'il est simplement sur un point difficile à trouver mais qu'il peut y arriver.
Le timeout
La solution classique est celle du "timeout" : il s'agit de donner un temps maximal à l'algorithme. Une fois le temps écoulé, on considère qu'il n'y a plus d'espoir de trouver d'autres résultats. Et on laisse l'utilisateur choisir son timeout car il connait ses données d'entrée et sait à quoi s'attendre. Dans l'application, quand une stratégie de calcul ne fonctionne pas, on peut changer de stratégie de calcul. On défini "ça ne fonctionne pas" par : "la moitié du timeout est écoulée". Puis on ajoute une autre stratégie de calcul ce qui donne par : 10% du timeout avec la stratégie 1, 45% avec la stratégie 2 puis 45% avec la stratégie 3. Quand le timeout est passé on arrête de s'acharner et on stoppe tout. Le seul problème est que ce bel édifice repose sur un prémisse faux, l'utilisateur n'a aucune idée à l'avance du temps normal d'analyse de ses données d'entrée, surtout pas avec un algorithme dont certains cas peuvent devenir explosifs (très chaotique).
La suppression du timeout
Probablement la décision tactique la plus chère que j'ai initiée dans ma carrière (je n'ai eu vent du coût qu'après) a été de supprimer le champ texte du timeout de l'interface. L'objectif était simple : plus de timeout, l'utilisateur cliquera sur "stop" quand il pensera qu'il n'y a plus d'espoir de trouver de nouveaux résultats. Et s'il part en vacance en laissant le logiciel tourner, tout ce qu'il risque est une bonne surprise en rentrant. La définition un peu plus formelle est la suivante : il faut que plus le temps s'écoule et plus la probabilité d'obtenir un résultat complet augmente. La stratégie du timeout ne permet pas ceci. Par exemple, si je mets 3j de timeout, certaines stratégies de calcul ne seront testée qu'au bout du 2ème jour. Ceci met un temps minimum à l'obtention de certains résultats faciles. La paralèllisation du calcul étant un autre dossier, elle n'était pas envisageable sur ce sujet. La technique utilisée a donc été de faire tourner toutes les stratégies de calcul pendant un temps croissant : 10s de stratégie 1, 10s stratégie 2, 10s stratégie 3, 1min stratégie 1, 1min stratégie 2, 1min stratégie 3, puis 5min chaque stratégie, etc. Dans l'espoir de toujours trouver le plus facile d'abord.
En revenant de la machine à café
... J'ai trouvé une machine à genoux qui ne répond pas au bouton "stop". Le comportement naturel, c'est d'appuyer sur "stop", puis de retourner prendre un café le temps que la machine répondre, ce qui n'est pas très productif. Un des grand combats techniques a été d'obtenir un bouton "stop" qui réagit immédiatement, même après 3j de calcul. Le scénario désiré était le suivant : l'utilisateur prend son café pendant le calcul, revient, clique sur "stop" et regarde ses résultats. Cela a pris un peu de temps pour expliquer l'intérêt de la chose. Puis, une fois l'intérêt plus ou moins acquis, le combat technique contre le swap, le scheduler ligués contre l'objectif fût long et difficile, mais je pense qu'il a été largement gagné par des développeurs acharnés.
C'est ainsi que les développeurs ont été mobilisés des semaines sans produire de nouveau point sur la liste des fonctionnalités de l'équipe marketing. J'espère aussi vaguement que c'est ce qui a permis à l'entreprise de sortir du secteur très étroit où elle était coincée.
