Chaque PR contenait une nouvelle variante de bouton. Chaque formulaire avait ses propres styles. On passait plus de temps sur le CSS que sur la logique métier.
En regardant la codebase Vue.js, le constat était clair : trois implémentations différentes de modales, quatre styles de tableaux, des dizaines de variations de formulaires. Chaque développeur avait sa propre interprétation de "notre design".
Le problème n'était pas le talent. C'était l'absence de contraintes.
Construire ou adopter
On aurait pu créer notre propre design system. Documenter chaque composant. Écrire des guidelines. Maintenir une bibliothèque interne.
Mais en faisant le calcul : créer un design system solide, c'est 3-4 mois minimum. Le maintenir, c'est une personne à temps partiel en permanence. Le documenter correctement, encore des semaines.
L'alternative : adopter une bibliothèque existante et l'adapter à notre marque.
Le choix s'est porté sur ElementPlus. Pas parce que c'est le meilleur design system du monde. Parce qu'il était mature, bien documenté, et parfaitement intégré à Vue 3.
L'intégration en deux phases
Le thème (première semaine)
La première erreur aurait été d'utiliser ElementPlus tel quel. Les utilisateurs auraient immédiatement vu que c'était "un template".
Il fallait créer une couche de theming. Variables CSS pour les couleurs. Tokens pour les espacements. Surcharges pour les composants les plus visibles.
// variables.scss
$--color-primary: #1a5f4a;
$--color-success: #2d7a5e;
$--border-radius-base: 6px;
$--font-family: 'Inter', sans-serif;
Le résultat : ElementPlus avec notre identité visuelle. Les utilisateurs ne voient pas "un framework". Ils voient "notre application".
Les wrappers (deuxième semaine)
La deuxième erreur aurait été d'utiliser directement les composants ElementPlus partout. Si demain on change de bibliothèque, il faudrait modifier des centaines de fichiers.
D'où l'idée de créer des composants wrapper. AppButton encapsule el-button. AppInput encapsule el-input. Ces wrappers ajoutent nos conventions : tailles par défaut, comportements standards, props simplifiées.
<script setup lang="ts">
defineProps({
variant: { type: String, default: 'primary' },
size: { type: String, default: 'default' },
loading: { type: Boolean, default: false }
})
</script>
<!-- AppButton.vue -->
<template>
<el-button
:type="variant"
:size="size"
:loading="loading"
v-bind="$attrs"
>
<slot />
</el-button>
</template>
Maintenant les développeurs utilisent AppButton, pas el-button. La bibliothèque sous-jacente devient un détail d'implémentation.
Ce qui a changé concrètement
Avant : un junior mettait 2-3 heures pour créer un formulaire avec validation. Il devait gérer les styles, les états d'erreur, les layouts responsives.
Après : le même formulaire prend 30-45 minutes. On assemble des composants. On se concentre sur la logique métier.
- Les PRs de UI sont 60% plus petites (moins de CSS custom)
- Les bugs visuels ont chuté (composants testés par la communauté)
- L'onboarding des nouveaux devs est plus rapide (documentation externe)
- La cohérence visuelle est garantie (contraintes du framework)
Les pièges rencontrés
Quelques erreurs commises en chemin.
Surcharger trop de styles. Au début, on voulait tout personnaliser. Résultat : on perdait les mises à jour du framework. Maintenant on ne surcharge que l'essentiel : couleurs, typographie, border-radius.
Ignorer l'accessibilité native. ElementPlus gère ARIA, focus management, navigation clavier. En créant des composants custom, on oublie facilement tout ça. Les composants standards sont souvent plus accessibles que nos créations.
Ne pas documenter les conventions. Même avec un design system, les devs ont des questions. "Quel variant pour ce bouton ?" "Quelle taille de modal ?" Un guide interne de 2 pages a éliminé 80% des questions.
Ce qu'on en retient
Pendant des mois, on a cru que chaque projet méritait son propre design system sur mesure. Que les frameworks étaient pour ceux qui ne savaient pas faire du CSS.
On avait tort. Un design system, c'est des contraintes productives. Des décisions déjà prises. Du temps économisé pour se concentrer sur ce qui compte : la valeur métier.
Les juniors ne débuggent plus du CSS. Ils livrent des features. Et l'application n'a jamais été aussi cohérente visuellement.