Veritas
Une plateforme de gestion des données, des principes d'API au premier tableau de bord

Veritas édite les logiciels que les entreprises utilisent pour sauvegarder, restaurer et gérer leurs données. Sa plateforme Data Management réunissait sauvegarde, restauration, classification et analyse dans un seul produit, conçu selon une approche API-first. Notre travail a porté sur ce produit à trois niveaux : le programme d'API qui le sous-tend, la première heure qu'un administrateur passe avec lui, et le tableau de bord qu'il retrouve ensuite.
La protection des données en entreprise s'achète avec prudence et s'installe lentement. Un administrateur compare les produits, en teste un, défend l'achat, puis configure le matériel nœud par nœud avant qu'une seule sauvegarde ne s'exécute. Chaque étape était une occasion de le perdre. En interne, le problème était tout autre. Une plateforme API-first exige que de nombreuses équipes conçoivent leurs API de la même manière, et la plupart des personnes qui devaient s'accorder sur ce point n'allaient pas lire une spécification.
Nous avons commencé par les personnes. Une cartographie des personas a suivi l'administrateur de la protection des données, de la découverte à l'usage quotidien, et cette séquence a fixé l'ordre des écrans : un site web qui explique le produit, un parcours de configuration qui le mène du matériel à un cluster opérationnel, et un tableau de bord qui rend compte de son état.
Pour le programme d'API, nous avons transformé les recommandations internes en infographies : une carte de l'écosystème et une page de principes, assez courtes pour être lues et affichées au mur.
L'interface est dépouillée. Les chiffres sont grands et les libellés petits. La couleur est réservée aux données.
La plateforme était API-first : le travail a donc commencé par l'API elle-même. Cette carte présente le programme sur une seule page : le développeur d'un côté, l'équipe API de l'autre, le portail développeurs entre les deux, et les outils dont chaque côté dépend.
Les recommandations de conception d'API vivent souvent dans de longs documents que peu de gens terminent. Nous les avons réduites à dix principes, chacun justifié en une phrase ou deux et formulé pour être retenu. Ne pas concevoir pour une interface précise. Utiliser des noms pour les ressources. Rester minimal.
La cartographie des personas retrace un rôle, l'administrateur de la protection des données, à travers neuf étapes : découvrir le produit, l'essayer, l'acheter, le configurer, connecter les services, rédiger les politiques, protéger les données et donner accès à d'autres utilisateurs. Elle est devenue la trame de tout ce qui a suivi.
La page produit énonce en une phrase ce que fait la plateforme, puis répond aux trois questions qu'un évaluateur pose en premier : en combien de temps on démarre, où se trouvent les données, et ce que les utilisateurs peuvent faire en autonomie.

La configuration commence par indiquer à l'administrateur combien de temps elle prendra et ce qu'il doit avoir sous la main, et par montrer le matériel déjà détecté.

La création d'un cluster se fait en quatre étapes, affichées en haut de chaque écran. Chaque nœud est une carte. L'administrateur sélectionne les nœuds à connecter, puis saisit deux adresses pour chacun. Les nœuds non attribués restent visibles, mais en retrait.


La dernière étape indique en langage clair l'avancement de chaque nœud, et celui du cluster dans son ensemble.

Le tableau de bord
Le tableau de bord répond aux premières questions d'un administrateur dans l'ordre où il les pose. Les sauvegardes de la nuit ont-elles tourné ? Quelque chose n'est-il pas protégé ? Combien d'espace reste-t-il, et pour combien de temps ? Les performances et l'utilisation suivent en dessous. Deux actions restent à portée de main en haut : restaurer, et créer une tâche de protection.
Le tableau de bord est composé de cartes, si bien que son contenu peut s'adapter à l'environnement. Ces variantes testent différentes cartes et formes de graphiques pour le cache cloud et pour l'activité de sauvegarde et de restauration.


Ce travail relie trois publics qui voient rarement les mêmes documents : les équipes qui construisent les API, l'administrateur qui installe le produit, et l'administrateur qui l'exploite un an plus tard.
Vous avez un projet en tête ?
Nous ne prenons qu'un nombre limité de projets par trimestre. Parlez-nous du vôtre.
Nous contacter →