Envoyez à un fondateur un cahier des charges de quarante pages et un lien vers quelque chose qu’il peut cliquer. Je sais lequel des deux revient avec des questions avant la fin de la journée, et ce n’est jamais le PDF.

Ce n’est pas un reproche fait aux fondateurs. C’est simplement notre façon de fonctionner. Un document vous demande d’imaginer le produit, puis de juger votre propre imagination. Une démo vous demande de l’utiliser et de remarquer ce qui cloche. La seconde est beaucoup plus facile, et elle fait émerger de bien meilleures questions.

Sur les projets matériels en phase de démarrage, j’ai donc remplacé l’essentiel de la phase de « documentation » par quelque chose sur quoi on peut appuyer.

Ce qu’un cahier des charges oublie

Un cahier des charges matériel décrit bien ce qu’un produit possède : un bouton, un anneau de DEL, le Wi-Fi, une pile, une application. Il décrit beaucoup moins bien ce que fait le produit quand les choses se compliquent.

Que se passe-t-il si on appuie deux fois sur le bouton pendant que le moteur tourne déjà ? Qu’affiche l’application quand l’appareil n’a pas donné signe de vie depuis dix minutes ? Si une action est prévue et qu’Internet est coupé, l’appareil la lance-t-il ou attend-il ? Qui a raison quand l’application et l’appareil ne sont pas d’accord ?

Rien d’exotique là-dedans. Ce sont les questions qu’un utilisateur rencontre dès la première semaine. D’après mon expérience, elles figurent rarement dans le cahier des charges, parce que personne ne pense à les poser devant une liste de fonctionnalités.

Sur un schéma électronique, ces comportements semblent gratuits. Sur un produit livré, chacun d’eux est une décision de firmware, un écran d’application, un billet de soutien, et parfois une contrainte matérielle : un moyen de détecter un moteur bloqué, une horloge qui garde l’heure sans le réseau, assez de mémoire pour stocker des événements hors ligne.

Ce que change un aperçu

Un aperçu du prototype est une simulation du comportement du produit dans le navigateur : l’appareil, l’application et la logique qui les relie. Ce n’est ni un rendu 3D figé ni une maquette. Les boutons réagissent, les minuteries tournent, la connexion peut tomber, on peut provoquer une panne. La logique est celle que le firmware implémentera.

J’en ai construit un la première fois pour qu’un client puisse appuyer sur les boutons, observer les séquences lumineuses et parcourir les modes du produit avant l’envoi du prototype physique. Cela a assez bien fonctionné pour devenir la règle : l’aperçu arrive maintenant en premier, dès la première semaine, avant toute commande de pièces.

Trois choses se produisent quand un fondateur en reçoit un.

Il teste au lieu d’approuver. En relisant un cahier des charges, on vérifie que ses fonctionnalités sont listées. En cliquant sur un aperçu, on essaie de le prendre en défaut. C’est exactement la revue que l’on souhaite.

Les discussions deviennent concrètes. « Il doit bien gérer le mode hors ligne » devient « continuer à nourrir selon l’horaire, garder les événements, synchroniser au retour et afficher “hors ligne” dans l’application plutôt qu’une valeur périmée ». Cette phrase passe directement dans les exigences du firmware.

D’autres personnes s’en mêlent. Un lien circule. Les cofondateurs, les investisseurs et quelques utilisateurs cibles peuvent tous l’essayer sur leur téléphone. Personne n’envoie un cahier des charges à ses utilisateurs cibles.

Moins de papier, pas zéro papier

Je ne suis pas contre la documentation. Je suis contre la documentation qui sert à prouver qu’on a travaillé.

Ce qui reste de la phase d’aperçu est court et utile : les comportements approuvés par le client, rédigés sous forme de scénarios. « Quand le réservoir passe sous 20 %, l’appareil passe à l’ambre et l’application reçoit une seule alerte. » Ces scénarios deviennent le cahier des charges du firmware, puis le plan de test du prototype physique. Les mêmes phrases, trois usages.

Ce qui disparaît, c’est la longue description d’un produit que personne n’a encore touché.

Ce qu’il ne fait pas

Un aperçu modélise le comportement, pas la physique. Il ne vous dira pas que la pile tient un an, que la radio porte jusqu’au garage ou que le moteur a assez de couple pour une croquette récalcitrante. Tout cela se mesure encore sur l’établi, avec de vraies pièces, et les réponses font parfois mal.

Mais à ce moment-là, nous mesurons un produit dont le comportement est déjà convenu. Quand une mesure impose un changement, nous savons exactement quels comportements elle touche, parce qu’ils sont écrits sous forme de scénarios plutôt qu’enfouis à la page 23.

Pour voir à quoi cela ressemble, j’ai construit un exemple fictif : Munch, une mangeoire connectée pour animaux avec son application mobile, coupures de Wi-Fi et moteur bloqué compris. Essayez l’aperçu du prototype.

Ce qui compte pour moi

J’aime les surprises. Mais pas sur le projet d’un client.

Chaque projet matériel en réserve quelques-unes, et la seule vraie question est de savoir quand elles apparaissent. En semaine 1, une surprise coûte un menu déroulant et une phrase dans un cahier des charges. En semaine 8, elle coûte une révision de carte, quelques semaines et un peu de confiance. L’aperçu est tout simplement l’endroit le moins coûteux que j’aie trouvé pour les vivre.