Unifier l'expérience produit et accélérer les cycles de développement pour préparer la plateforme à scaler

Onafis est une scale-up française de la winetech qui développe un SaaS de suivi en temps réel des processus de fermentation, d'élevage et de production pour vignerons, brasseurs et distillateurs.

Dans un contexte de forte croissance, la plateforme avait été construite de façon incrémentale, sans référentiel de design partagé. Onafis a sollicité Lonestone pour poser les fondations d'un design system robuste afin d'unifier l'expérience, accélérer les cycles de conception et préparer la plateforme à scaler.

Le marché des outils SaaS à destination des professionnels de la production agricole et alimentaire est en pleine structuration. Les acteurs qui tirent leur épingle du jeu sont ceux qui réussissent à combiner densité d'information et clarté d'interface, un équilibre rarement atteint sans système de design solide. La concurrence sur la fiabilité perçue du produit est aussi forte que sur les fonctionnalités elles-mêmes.

Les utilisateurs d'Onafis, vignerons, brasseurs, œnologues, gérants de domaine, sont des professionnels exigeants, habitués à des données opérationnelles précises. Ils interagissent avec la plateforme dans des contextes souvent contraints, ce qui rend la clarté de navigation et la stabilité visuelle de l'interface non négociables. L'absence d'un référentiel partagé se traduisait concrètement par une expérience fragmentée et une perte de confiance dans l'outil.

La mission a démarré par une phase de cadrage pour définir ce qui était, de façon réaliste, livrable en un temps contraint : l'inventaire des composants existants, la mise en place des fondations (tokens), la création d'une bibliothèque de composants modulaires, et l'accompagnement à l'intégration côté dev. Les évolutions futures ont été anticipées dans l'architecture, sans être développées dans cette première phase.

J'ai commencé par un audit exhaustif de la plateforme : recensement de tous les écrans, identification des patterns récurrents, des doublons et des incohérences. Cet inventaire a servi de base pour définir l'architecture du design system, non pas comme une bibliothèque de boutons, mais comme un système pensé à partir des vrais usages de la plateforme.

Les fondations typographiques, colorimétriques et les espacements ont été formalisées sous forme de tokens Figma, avec une architecture prévoyant le support du dark mode via les variables Figma. L'objectif était de rendre le système maintenable et évolutif, pas seulement beau au moment de la livraison.

Après la livraison de la première version du design system, nous avons travaillé pendant 15 jours en binôme avec l'équipe de développement pour faciliter l'appropriation. Cette phase de co-construction a été déterminante : elle a transformé une livraison de specs en un référentiel réellement adopté par les devs.

La nouvelle version de l'application est partie en production avec le nouveau thème, le design system intégré et la migration vers les composants Quasar (en remplacement de VueSax). L'équipe Onafis a constaté une réduction sensible de la dette technique et une cohérence client nettement renforcée.

Après la livraison d'une première mouture du design system, nous avons travaillé pendant 15 jours avec l'équipe de développement pour qu'ils se l'approprient, le tester en situation concrète et l'adapter en fonction des besoins identifiés.

L'importance de la documentation est ressortie comme un facteur clé. J'ai livré une bibliothèque documentée, réunissant guidelines, bonnes pratiques et exemples d'usage pour faciliter l'adoption par les designers et développeurs.

Un design system non adopté n'est qu'une belle documentation. Ce projet m'a confirmé que la vraie valeur d'un design system ne tient pas à sa complétude, mais à sa capacité à être utilisé, maintenu et fait vivre par une équipe.