Construire une roadmap quand le produit n'existe pas encore

Cinq entretiens avant de toucher à un wireframe

J'ai mené cinq entretiens avec des parties prenantes avant de produire un seul écran. Elles ont été choisies non pour leur hiérarchie mais pour leur connaissance : deux administrateurs informatiques responsables du déploiement de l'infrastructure dans les établissements, un directeur académique gérant la relation entre la Région et les chefs d'établissement, un enseignant ayant utilisé des machines virtuelles dans un contexte professionnel antérieur, et un élève de terminale participant à un programme technologique pilote. Ce n'étaient pas des entretiens utilisateurs au sens UX classique. C'étaient des sessions d'extraction d'hypothèses. Je suis entré avec une liste de ce que je croyais vrai sur le produit et j'ai testé chaque élément contre leur expérience.

Le livrable n'était ni un persona ni une carte de parcours. C'était une carte d'hypothèses conflictuelles. Les administrateurs IT supposaient que la mise à disposition des machines virtuelles serait centralisée et invisible pour les enseignants. Le directeur académique supposait que les enseignants configureraient leurs propres environnements. Ces deux hypothèses ne pouvaient pas être toutes les deux vraies, et aucune n'avait été soulevée lors de la réunion de direction où le produit avait été approuvé.

La matrice de risques comme véritable document de planification

J'ai cartographié chaque hypothèse sur une matrice à deux axes : probabilité d'être fausse versus coût de la découvrir tardivement. Ce n'est pas une technique nouvelle, mais l'utiliser comme document de planification principal plutôt que comme analyse de fond change considérablement le résultat. Le quadrant à haut risque (probablement fausse, coûteuse à découvrir tard) est devenu la logique de séquençage de la roadmap.

La première phase du MVP ne visait pas à construire le produit. Elle visait à résoudre les trois hypothèses dans le quadrant à haut risque : si l'infrastructure réseau des établissements pouvait supporter des sessions de machines virtuelles simultanées à l'échelle d'une classe, si le système d'exploitation de la tablette SQOOL pouvait faire tourner le logiciel client sans modification, et si les enseignants accepteraient un flux de travail nécessitant de provisionner les sessions à l'avance. Chacune était une inconnue technique ou comportementale qui, si elle s'avérait fausse, invaliderait des mois de travail aval.

La deuxième phase se concentrait sur l'expérience enseignant : l'interface de configuration, la gestion des sessions, et les modes d'échec qu'un environnement de classe rend inévitables (la session d'un élève qui plante pendant un examen, une coupure réseau en pleine session). La troisième phase était le déploiement écosystème : les outils pour les administrateurs IT gérant des parcs de machines virtuelles dans des centaines d'établissements, le reporting pour les directeurs académiques, et l'intégration avec la plateforme SQOOL plus large.

Le calendrier scolaire comme contrainte immuable

Une contrainte a tout structuré : le calendrier scolaire. Un produit manquant la rentrée de septembre resterait inutilisé pendant dix mois. Cette échéance n'était pas négociable, et elle a comprimé tout l'horizon de planification. Quatre mois du lancement au premier pilote dans cinq établissements.

Cette contrainte s'est révélée utile. Elle a forcé une priorisation radicale : la phase un devait être assez petite pour être livrée en quatre mois, et les cinq établissements pilotes devaient être choisis pour la diversité de leurs conditions d'infrastructure plutôt que pour leur réceptivité. L'objectif du pilote était de casser le produit dans des conditions réalistes, pas de le valider dans des conditions favorables.

La première version a été livrée dans les délais. L'hypothèse sur l'infrastructure réseau s'est avérée partiellement fausse : des sessions simultanées à pleine échelle de classe causaient une latence inacceptable en pratique. Cette découverte, faite à la deuxième semaine du pilote, a conduit à une fonctionnalité de planification des sessions qui ne figurait dans aucune des spécifications initiales. C'était le bon correctif, et il est venu de l'observation du comportement réel plutôt que du design initial.

À quoi servait réellement la roadmap

Avec le recul, la roadmap en trois phases servait un objectif au-delà de la planification : elle créait un langage commun pour gérer l'incertitude avec l'équipe de direction. Au lieu de promettre un produit complet en quatre mois, je promettais la résolution d'inconnues spécifiques dans l'ordre. Ce cadrage donnait au comité de direction quelque chose à évaluer à chaque jalon qui n'était pas « le produit est-il prêt ? » mais « avons-nous appris ce que nous devions apprendre ? »

La différence est importante parce que le développement produit en phase zéro-un est avant tout un processus d'apprentissage. Un diagramme de Gantt lui donne l'apparence d'un processus d'exécution. Le cadrage par matrice de risques maintient l'apprentissage explicite et facilite le changement de direction quand les preuves pointent ailleurs, sans que ce changement ressemble à un échec.