Faire visiter sans donner les clés

Montrer un outil de gestion pose un problème qu'aucune capture d'écran ne résout.

Ou bien on ouvre son vrai compte — et on fait défiler devant un inconnu ses clients, ses factures, ses marges et sa messagerie d'équipe. Ou bien on montre des images, et l'interlocuteur regarde poliment quelque chose qu'il ne peut pas manipuler. Dans les deux cas, ce qu'on cherche à démontrer — qu'une console tient debout, que tout y communique — ne se démontre pas.

Un bouton « Voir la démo » ouvre maintenant la console entière, sans inscription et sans mot de passe à faire circuler.

Ne pas simuler : dupliquer

La tentation était d'écrire un mode « démo » dans l'application : des données en dur, des écrans qui font semblant. C'est la solution qui paraît simple et qui vieillit mal — chaque écran ajouté demande ensuite son faux-semblant, et le jour où on oublie, la démo montre une page vide.

Nous avons pris l'autre voie : un schéma séparé dans la même base, avec les mêmes tables. Le serveur bascule dessus pour le compte de démonstration, et l'application ne sait rien de tout ça. Aucun écran n'a eu besoin d'apprendre qu'il pouvait être regardé par un visiteur.

Ce qui est réel y reste réel : les sites du portfolio, leurs pages, leurs articles, notre journal des changements — secrets retirés. Ce qui ne peut pas l'être est fictif, et assumé : clients, factures, devis, tâches, agenda, messages, demandes de service, prospects, boutique, statistiques.

Un verrou, puis un second

Une console de démonstration en lecture seule tient sur une règle : rien n'écrit. Tout le travail consiste à s'assurer qu'aucun chemin ne la contourne.

Le premier verrou est dans l'application : toute requête qui modifie quelque chose est refusée au compte de démonstration, avant d'atteindre la moindre route. Pas écran par écran — en amont de tous, parce qu'une liste d'exceptions se périme au premier écran ajouté.

Le second est dans la base elle-même. Il ne sert à rien tant que le premier fonctionne, et c'est exactement pour ça qu'il existe : le jour où une route nous échappe, elle tombera sur un mur au lieu d'écrire.

S'y ajoutent les conséquences qu'on oublie facilement. Aucun e-mail ne part. La boîte mail est fictive. La messagerie d'équipe en temps réel est coupée — un visiteur ne doit pas apparaître dans nos salons. Et se déconnecter depuis la démo ne ferme que sa propre session, pas celle des autres visiteurs.

Le compte se remet d'aplomb tout seul

Un compte partagé publiquement finit par être bousculé. Son mot de passe est dérivé d'un secret serveur : s'il a été changé, il est rétabli au passage suivant. Il n'y a rien à surveiller, donc rien à oublier de surveiller.

Le bandeau, et le téléphone

Un bandeau permanent rappelle que les données sont fictives et la console en lecture seule. Nous l'avions posé, satisfaits, avant de l'ouvrir sur un téléphone : il mangeait le haut de chaque page, sur l'appareil où l'écran est déjà le plus rare.

Il porte désormais une croix. Fermé, il le reste pour l'onglet. L'avertissement doit être lu une fois, pas subi toutes les trois minutes.

Et tant qu'à regarder les bords

La page d'erreur par défaut de notre cadre de développement est restée en place bien plus longtemps qu'elle n'aurait dû. Une console soignée dont la moindre erreur affiche une page anglaise et grise perd, en un écran, ce qu'elle a gagné en dix.

Elle est remplacée pour toute l'application : le chat du chargement y prend une pose selon le code — il fouille sur une page introuvable, il dort sur un service indisponible — le message est en français, et les boutons proposent la sortie qui convient plutôt qu'un « retour à l'accueil » qui ne convient presque jamais.