Design system prêt pour l'IA et centrage CSS : ce que vos in

Votre design system est-il vraiment prêt pour l’IA ?

Un client nous a appelé il y a quelques semaines. Son agence précédente lui avait livré un site “moderne”, avec un design system bien documenté, des composants Figma propres, une charte graphique irréprochable. Sauf qu’au moment d’intégrer un outil de génération de code par IA, tout s’est cassé la figure. Les tokens n’étaient pas nommés de façon cohérente, les espacements n’obéissaient à aucune logique systémique, et le centrage vertical de ses blocs était fait à coups de margin-top: 47px hardcodés.

Résultat : l’IA générait du code inutilisable. L’intégrateur repassait derrière à la main. Trois semaines de perdu.

Ce n’est pas un cas isolé. C’est la règle.

Deux sujets en apparence distincts — rendre un design system compatible avec les outils IA, et maîtriser le centrage vertical en CSS — racontent en réalité la même histoire : ce qu’on n’a pas industrialisé correctement finit par nous coûter du temps, de l’argent, et des nerfs.

Voici ce qu’on a appris sur ces deux fronts, et comment on l’applique chez GDM-Pixel.

---

Pourquoi les design systems actuels font planter l’IA

L’IA ne lit pas entre les lignes. Elle ne “comprend” pas qu’un #1A2B3C est votre couleur primaire si vous ne l’avez pas nommé color-primary-600. Elle ne devine pas que votre espacement de 24px correspond à votre base de grille si vous l’avez tapé en dur à chaque composant.

Les outils de génération de code — que ce soit Claude Code, Copilot, Cursor ou n’importe quel agent branché sur votre codebase — fonctionnent par pattern recognition. Ils cherchent de la cohérence, de la prévisibilité, des conventions explicites.

Un design system “prêt pour l’IA” n’est pas un design system plus complexe. C’est un design system plus propre.

Voici ce que ça change concrètement dans notre workflow :

Des tokens sémantiques, pas des valeurs brutes

La différence entre --color-blue-500 et --color-action-primary, c’est la différence entre une valeur et une intention. L’IA comprend les intentions. Elle ne sait pas quoi faire d’une valeur orpheline.

Chez GDM-Pixel, on a migré l’ensemble de nos tokens vers une nomenclature sémantique en trois couches :

• Couche primitive : les valeurs brutes (blue-500: #3B82F6)
• Couche sémantique : l’usage (action-primary: blue-500)
• Couche composant : le contexte (button-background-default: action-primary)

Quand Claude Code génère un bouton dans ce contexte, il utilise button-background-default sans qu’on ait à le préciser. Le token porte l’information. C’est ça, un système exploitable par une machine.

Une documentation structurée comme une API

Votre design system doit être lisible par un humain ET parseable par une IA. Ce n’est pas contradictoire — c’est de la rigueur.

Concrètement : des fichiers de tokens en JSON ou en CSS custom properties, des composants documentés avec leurs variantes explicitement nommées, des états (default, hover, disabled, error) toujours présents et cohérents.

“Un design system bien structuré pour l’IA, c’est avant tout un design system bien structuré pour les humains. La machine révèle vos incohérences.”

Ce qu’on voit dans nos audits : des systèmes où le bouton primaire a 4 noms différents selon le fichier Figma, le Storybook et le code. Pour un humain, c’est gênant. Pour une IA, c’est bloquant.

Des espacements basés sur une échelle, pas sur des approximations

margin: 47px. On en voit encore. Trop souvent.

Une IA qui génère du code cherche des patterns. Si votre espacement suit une échelle (4, 8, 12, 16, 24, 32, 48, 64), elle peut inférer. Si vos valeurs sont aléatoires, elle improvise — et l’improvisation d’une IA sur des valeurs magiques, ça donne du code à jeter.

La règle qu’on applique depuis deux ans chez GDM-Pixel : zéro valeur d’espacement hardcodée en dehors des tokens. Tout passe par --spacing-4, --spacing-6, etc. Ça semble contraignant au début. Ça fait gagner des heures à l’arrivée.

---

Le centrage vertical en CSS : l’épisode final (vraiment)

Parlons du sujet qui a torturé des générations d’intégrateurs. Le centrage vertical en CSS.

Ce n’est plus un problème depuis CSS Flexbox et Grid. Mais on continue à voir des hacks dans des codebases livrées en 2024. Des line-height égaux à la hauteur du conteneur. Des position: absolute avec top: 50% et transform: translateY(-50%). Des tables HTML pour centrer du contenu.

Pourquoi ça persiste ? Parce que les équipes n’ont pas de règle partagée. Chaque intégrateur a sa technique préférée. Et une IA qui génère du code dans ce contexte chaotique va reproduire le chaos.

Voici comment on standardise ça.

Flexbox : la solution pour 90% des cas

Pour centrer verticalement dans un conteneur, Flexbox est la réponse par défaut dans notre stack :

.container {
  display: flex;
  align-items: center; /* centrage vertical */
  justify-content: center; /* centrage horizontal si besoin */
}

Deux lignes. Lisibles. Prévisibles. Supportées partout.

Pour les cas où le conteneur doit occuper toute la hauteur disponible, on ajoute min-height: 100dvh (en utilisant dvh plutôt que vh pour éviter les problèmes sur mobile avec les barres de navigation). C’est une décision qu’on a standardisée dans notre design system — un token --height-screen qui pointe vers 100dvh.

CSS Grid : quand on centre dans les deux dimensions

Pour les layouts plus complexes — une hero section, une modal, un splash screen — Grid est plus expressif :

.container {
  display: grid;
  place-items: center; /* raccourci pour align-items + justify-items */
}

place-items: center est probablement la propriété CSS la plus sous-utilisée en 2025. Un mot. Deux axes. Centrage parfait.

Pourquoi standardiser ça dans votre design system

La question n’est pas “quelle technique est la meilleure”. La question est : est-ce que toute votre équipe (et votre IA) utilise la même technique dans les mêmes contextes ?

Dans notre design system, on a documenté trois patterns de centrage :

Pattern center-flex — pour centrer du contenu dans un flux (navigation, cards, boutons) Pattern center-grid — pour centrer dans un espace défini (modals, heroes, overlays) Pattern center-text — pour le centrage typographique pur (text-align: center + margin-inline: auto)

Chaque pattern a son token CSS, sa classe utilitaire dans Tailwind, et sa documentation dans Storybook. Quand on demande à Claude Code de générer un composant, il sait quel pattern utiliser selon le contexte. Zéro ambiguïté.

“La standardisation n’est pas une contrainte créative. C’est ce qui permet à la machine de vous libérer des tâches répétitives.”

---

Ce que ça change vraiment dans la production

On a industrialisé ces principes sur Nova Mind — notre SaaS en production. 21 pages livrées en 10 heures. Ce n’est pas de la magie. C’est le résultat direct d’un design system que l’IA peut consommer sans friction.

Concrètement, voici ce que ça change :

Génération de composants : Claude Code génère un composant cohérent avec notre charte du premier coup, sans itérations correctrices sur les couleurs ou les espacements. Économie : 45 minutes par composant sur un projet standard.

Revue de code : L’intégrateur ne passe plus derrière l’IA pour corriger des valeurs hardcodées ou des techniques de centrage incohérentes. La revue porte sur la logique, pas sur le style.

Onboarding : Un nouveau développeur (ou un agent IA) comprend le système en lisant les tokens. Pas besoin d’un document de 40 pages qui sera obsolète dans six mois.

Le gain n’est pas hypothétique. Sur les trois derniers projets clients intégrant ce workflow, on a réduit le temps d’intégration front-end de 60% en moyenne.

---

Trois actions concrètes pour démarrer

Vous n’avez pas besoin de refondre votre design system en une semaine. Voici par où commencer, dans l’ordre de priorité :

1. Auditez vos valeurs hardcodées. Cherchez dans votre codebase tous les px qui ne sont pas des tokens. C’est votre dette technique la plus visible. Sur un projet de taille moyenne, ce travail prend une demi-journée et révèle immédiatement les zones de friction.

2. Nommez vos tokens par intention, pas par valeur. Renommez --blue-500 en --color-action-primary. Ce changement seul améliore la lisibilité pour votre équipe et la compréhension pour une IA.

3. Standardisez vos patterns de centrage. Choisissez Flexbox ou Grid selon le contexte, documentez la règle, créez les classes utilitaires correspondantes. Interdisez les hacks dans votre guide de contribution.

Ces trois actions ne nécessitent pas de budget. Elles nécessitent de la rigueur et une heure de réunion d’équipe pour aligner tout le monde.

---

La conclusion qui dérange un peu

La plupart des agences vont continuer à livrer des design systems que l’IA ne peut pas exploiter. Pas par manque de compétences — par manque de méthode.

Les clients, eux, vont continuer à payer des heures d’intégration pour des tâches qu’une IA bien configurée ferait en minutes. Et quand ils découvriront que c’est possible autrement, ils changeront d’agence.

Chez GDM-Pixel, on a fait le choix inverse : industrialiser notre méthode, la documenter, l’exposer publiquement. Parce qu’un design system AI-ready n’est pas un avantage concurrentiel qu’on garde secret — c’est un standard qui va s’imposer à tout le monde dans les deux ans qui viennent.

Autant être en avance.

Vous voulez qu’on audite votre design system ou votre stack front-end ? On fait ça en 3 jours. Diagnostic honnête, recommandations actionnables, sans jargon. Contactez GDM-Pixel — on vous dit ce qui bloque vraiment, pas ce que vous voulez entendre.

---

Sources et références : CSS Tricks — A Complete Guide to Flexbox, Smashing Magazine — Design Tokens, documentation MDN Web Docs sur les propriétés Grid et Flexbox.