Aller au contenu
Retour
  • Design System
  • Outil métier
  • 2024

RTBF Construire un design system from scratch pour des outils internes

En moins de 6 mois, avec une équipe pluridisciplinaire (design, dev, PO), nous avons posé les fondations d’un système de design complet — tokens, composants, documentation — pour unifier les interfaces métier de la RTBF.

Rôle
Product Designer — design system
Équipe
Design · Dev · Product Owner
Durée
Moins de 6 mois
Périmètre
Interfaces internes / outils métier
Design system Ingest de la RTBF : logotype, couleurs et typographie appliqués aux écrans mobiles
Icônes du design system Ingest : icônes Material et icônes dédiées de la barre de navigation
Formulaires et boutons du design system Ingest : champs, modales et états des boutons
Graphiques et mode sombre du design system Ingest sur mobile
Illustrations du design system Ingest, aux couleurs de la RTBF

01 — Contexte

Un parc d’outils internes sans cohérence visuelle ni technique

La RTBF dispose d’un ensemble d’applications métier utilisées quotidiennement par ses équipes internes — production, diffusion, gestion de contenu. Ces outils avaient été développés indépendamment, sans référentiel visuel commun. Résultat : des interfaces hétérogènes, des composants redéveloppés plusieurs fois, et des coûts de maintenance en hausse.

La demande initiale était claire : créer un design system from scratch capable de servir de base unifiée pour tous les futurs développements internes, tout en étant adopté rapidement par les équipes en place.

Le défi principal

Créer un système suffisamment structuré pour garantir la cohérence, suffisamment flexible pour couvrir la diversité des outils métier — et le faire en moins de 6 mois avec une équipe réduite.

02 — Mon rôle

Lead designer du système, en collaboration étroite avec dev et PO

Au sein de l’équipe pluridisciplinaire, j’ai pris en charge l’intégralité de la dimension design du système : de la définition des fondations jusqu’à la documentation finale. Mon travail s’articulait en permanence avec les contraintes techniques des développeurs et les priorités produit du PO.

  • Tokens & fondations

    Définition des variables de base — couleurs, typographie, espacement, ombres, border-radius — structurées pour être directement consommables par les développeurs.

  • Bibliothèque Figma

    Construction de la librairie de composants dans Figma — avec variants, états interactifs et auto-layout — alignée sur les patterns d’usage des outils métier RTBF.

  • Documentation & gouvernance

    Rédaction des guidelines d’usage, règles de contribution, et processus de mise à jour — pour que le système soit maintenu dans le temps sans dépendre d’une seule personne.

03 — Processus

Discovery rapide, fondations solides, itération continue

Avec une contrainte de 6 mois, le processus a été conçu pour livrer de la valeur tôt tout en posant des bases durables.

  1. Audit & discovery (semaines 1–2)

    Recensement des interfaces existantes, identification des patterns récurrents et des incohérences critiques. Entretiens avec les équipes dev et PO pour cadrer les priorités et les contraintes techniques.

  2. Fondations & tokens (semaines 3–5)

    Définition des design tokens en lien direct avec les développeurs — nommage, structure, export. Validation de la palette, de la typographie et du système d’espacement avec le PO et les parties prenantes.

  3. Bibliothèque de composants (semaines 6–14)

    Construction itérative des composants dans Figma — des plus atomiques (boutons, champs, badges) aux plus complexes (tableaux, formulaires, navigation). Chaque composant validé avec dev avant passage au suivant.

  4. Documentation & gouvernance (semaines 12–18)

    Rédaction en parallèle des guidelines d’usage pour chaque composant. Mise en place d’un processus de contribution et de versioning pour assurer la pérennité du système après la mission.

04 — Résultats

Un système opérationnel, adopté et maintenu en autonomie

À l’issue des 6 mois, le design system était en production et utilisé activement par les équipes. Sans données chiffrées formelles, les résultats les plus visibles ont été :

  • Cohérence visuelle immédiate

    Sur les nouveaux développements — les interfaces produites après le système sont reconnaissables comme appartenant au même produit.

  • Réduction du temps de design

    Sur les nouvelles fonctionnalités — les équipes assemblent des écrans avec la librairie Figma plutôt que de repartir de zéro.

  • Autonomie des équipes

    La documentation et les règles de gouvernance permettent aux développeurs de contribuer et de faire évoluer le système sans dépendre du designer.

  • Base technique solide

    Les tokens sont directement consommés par le code, ce qui réduit les écarts entre maquette et implémentation.