01 · Périmètre et statut
Les règles ont une provenance.
On distingue les propriétés réellement observées, les conventions harmonisées pour la production et les composants encore au stade de maquette. Une interface documentée n'est pas une fonctionnalité disponible.
Couleurs, Public Sans, grille de la maquette, géométries et structure de composants.
Nom des variables CSS, échelle d'espacement et adaptation responsive proposée.
Annuaire, cartes acteurs, chiffres clés dynamiques et services futurs du site.
La documentation est dérivée de la maquette Figma AURA Esport, des logos officiels et du site actuel. Le fichier Figma consulté ne disposait pas d'un jeu complet de variables ou styles de texte publiés. Les tokens sont donc une normalisation exploitable, pas une affirmation sur l'état interne du fichier Figma.
02 · Couleurs et rôles
Une palette sémantique.
Le bleu installe l'identité institutionnelle, l'orange signale l'action. Le blanc, le canvas clair et le bleu nuit structurent les surfaces sans multiplier les couleurs décoratives.
#040C48#000D70#E53500#FFFFFF#F6F6F6#010227Couleurs de catégories
Sémantique de contenu seulement. Ces teintes ne remplacent jamais les trois couleurs principales de la marque.
L'orange original #E53500 avec du texte blanc reste inférieur au seuil 4,5:1 pour du texte normal. Adapter les états accessibles dans les composants sans changer arbitrairement le logo officiel.
03 · Typographie
Public Sans. Une seule famille.
Les changements de niveaux passent par la taille, la graisse et le rythme. La police variable est hébergée sur le même domaine, sans service externe.
| Usage | Taille | Graisse | Règle |
|---|---|---|---|
| Hero | 40 px à la référence | 900 | Une idée forte, 2 à 3 lignes |
| H2 section | 34 px | 900 | Structure principale |
| Titre de carte | 22 à 24 px | 700 | Concis, précis |
| CTA / Label | 16 à 18 px | 700 | Verbe d'action |
| Corps | 16 à 18 px | 400 | Texte lisible, 110 à 140 % |
| Informations | 12 à 14 px | 500 | Secondaire mais accessible |
Ces tailles sont observées dans la maquette et doivent être adaptées au contexte responsive. La landing de production utilise elle-même des tailles fluides.
04 · Espacement & layout
De l'air, du rythme, des limites.
La maquette desktop est construite sur 1728 px, avec 1378 px de contenu et 175 px de marges. En code, utiliser un max-width et des gouttières fluides.
En production, ne pas multiplier les rayons sans justification.
Échelle normalisée d'espacement
Responsive recommandé
| Écran | Largeur | Principe |
|---|---|---|
| Mobile | ≤ 719 px | 1 colonne, liens et contrôles utilisables au doigt |
| Tablette | 720 à 1179 px | 2 colonnes quand pertinent, lecture prioritaire |
| Desktop | ≥ 1180 px | Grilles modulaires et contenu max. 1378 px |
Seuils normalisés, non définis directement dans la maquette. Les règles responsive de la landing restent prioritaires pour ses éléments existants.
05 · Bibliothèque de composants
Réutiliser avant de recréer.
Composants existants et familles présentes dans la maquette. Les exemples ci-dessous sont des démonstrations visuelles et ne représentent ni une inscription réelle, ni un événement, ni des données statistiques.
Contrôle : 8 px de rayon, hauteur 46 à 48 px minimum.
Label permanent, contraste lisible, validation serveur si réellement utilisé.
Comment exploiter les règles ?
Lire les fondations, choisir les composants disponibles puis vérifier les états et le responsive.
Inventaire avec état réel
| Composant | Source | Statut | Règle |
|---|---|---|---|
| Header / Footer | Site actuel | Implémenté | Navigation, logo, thèmes, pied de page |
| Boutons / CTA | Maquette + site | Implémenté | Primaire, secondaire, lien textuel, états accessibles |
| Conseil d’administration | Site actuel | Implémenté | Trois fiches actuellement publiques |
| Accordéons FAQ | Maquette + site | Implémenté | Contenu accessible et navigation clavier |
| Champs / questionnaire | Formulaire actuel | Implémenté | Libellé persistant, validation serveur distincte |
| Carte de chiffres clés | Maquette Figma | Prévu | Nécessite sources vérifiables et période explicite |
| Carte acteur / annuaire | Maquette Figma | Prévu | Validation de chaque fiche publique avant diffusion |
| Carte événement / classement | Maquette Figma | Prévu | Données d’opérateur, date, règlement, traçabilité |
| Cartouche partenaire | Maquette Figma | Prévu | Accord et autorisation de logo préalables |
| Carte ressource / cartographie | Maquette Figma | Prévu | Taxonomie, source, mise à jour, contrôle humain |
Aucun indicateur, événement, acteur ou partenaire fictif du design system ne doit être repris dans les communications publiques comme un fait.
06 · États & thèmes
Deux thèmes. Des comportements stables.
Le fond clair est proposé par défaut. Le thème sombre n'est pas une inversion des couleurs : chaque surface conserve son rôle sémantique et son contraste.
Thème clair / canevas
Bleu sur blanc.Cartes lisibles et orange en accent.
Thème sombre / nuit
Blanc sur bleu.Surfaces et bordures adaptées.
Chaque interaction applicable doit prévoir
Le thème est un choix d'affichage local conservé dans le navigateur. Aucun outil tiers de mesure n'est utilisé par ces pages de documentation.
07 · Accessibilité et robustesse
Une interface lisible par tous.
Le respect de l'identité AURA ne doit jamais être utilisé comme excuse pour négliger le clavier, le contraste ou la compréhension des formulaires.
- Objectif de mise en œuvre : WCAG 2.2 AA, selon le contexte.
- Contrôle interactif d'au moins 44 × 44 px lorsque pertinent.
- Focus clavier nettement visible, jamais transmis par la couleur seule.
- Label explicite et permanent, message d'erreur compréhensible.
- SVG décoratifs masqués, icônes seules correctement nommées.
- Respect de la préférence de réduction du mouvement.
- Rendu testé en clair et sombre, au clavier, avec contenu long et zoom 200 %.
- Un composant de démonstration ne doit pas traiter des données personnelles.
08 · Contrat d'exécution pour les IA
Ce qu'une IA doit suivre.
La documentation textuelle et le JSON évitent d'interpréter à la main les maquettes. Les étapes ci-dessous définissent la chaîne attendue avant toute génération d'interface.
- Lire les fichiers JSON, Markdown et la charte avant de produire du code.
- Identifier le type de page, les composants existants et leur statut.
- Appliquer les tokens de couleur, typographie, espace, rayon et grilles sans improvisation.
- Utiliser les logos fournis sans les recréer, et les icônes disponibles.
- Respecter le HTML sémantique, la navigation clavier et les états interactifs.
- Tester mobile, tablette, desktop et les deux thèmes.
- Ne jamais présenter un exemple de maquette comme résultat réel, membre publié ou partenariat signé.
- Documenter les écarts, les parties seulement envisagées et les validations restantes.
Exemple minimal de structure HTML
<section class="section" aria-labelledby="section-title">
<div class="container">
<p class="eyebrow">AURA Esport</p>
<h2 id="section-title">Titre explicite</h2>
<p>Contenu factuel, vérifié et lisible.</p>
<a class="button button-primary" href="/vision/">
Découvrir notre vision
</a>
</div>
</section>Le design system décrit des composants futurs, mais le site public actuel demeure une landing en développement. L'annuaire et les ressources ne doivent pas être décrits comme opérationnels. La liste publique du conseil d'administration reste limitée à Romain Caso, Stéphan Euthine et Matthias Meriguet.
09 · Documents et API statique
Une documentation vraiment exploitable.
Une IA peut lire directement le JSON complet, le texte Markdown et les tokens CSS, avec leur provenance, leurs conventions et leurs restrictions de publication. Aucune API ni authentification n'est nécessaire pour ces ressources publiques.
Documentation V1.0 du 27 octobre 2026. Les sources internes non publiques ne figurent pas dans le paquet.