📚 Cours SCSS (Sass) 📍 Chapitre 17 / 21

Architecture SCSS professionnelle

Une bonne architecture SCSS est ce qui fait la différence entre un petit projet agréable et un projet ingérable au bout de quelques mois. Ce chapitre t'apprend à structurer ton code de manière scalable, lisible et maintenable, en t'appuyant sur des conventions éprouvées (dont la méthode 7-1) et les outils modernes de Sass.

Objectifs du chapitre

  • Comprendre pourquoi l'architecture SCSS est essentielle.
  • Découvrir la méthode 7-1 et ses variantes.
  • Organiser correctement variables, mixins, composants et layouts.
  • Utiliser @use et @forward dans une architecture propre.
  • Mettre en place des conventions professionnelles.
À retenir

Une bonne architecture n'accélère pas seulement le développement : elle réduit surtout les erreurs et le stress à long terme.

Explications théoriques détaillées

Pourquoi une architecture est indispensable

Sans structure claire, un projet SCSS finit souvent avec :

  • Un seul fichier énorme (style.scss)
  • Des règles dupliquées
  • Des effets de bord imprévisibles
Conseil terrain

Si tu hésites sur "où mettre ce code", c'est souvent que l'architecture n'est pas assez claire.

Principes d'une bonne architecture SCSS

  • Un fichier = une responsabilité claire.
  • Pas de styles globaux cachés.
  • Les composants ne dépendent pas du contexte.
  • Les décisions de design sont centralisées.

Exemples simples

Découper un projet en fichiers partiels

En SCSS, les fichiers partiels commencent par un underscore (_).

Structure de dossiers :

STRUCTURE
scss/
├─ base/
│  ├─ _reset.scss
│  ├─ _typography.scss
│
├─ components/
│  ├─ _button.scss
│  ├─ _card.scss
│
├─ layout/
│  ├─ _header.scss
│  ├─ _footer.scss
│
├─ settings/
│  ├─ _colors.scss
│  ├─ _spacing.scss
│
└─ main.scss

Chaque dossier a un rôle précis. On évite les fichiers "fourre-tout".

Importer correctement avec @use

SCSS :

SCSS
// main.scss
@use "settings/colors";
@use "base/typography";
@use "components/button";
@use "layout/header";
À retenir

@use remplace @import et évite les collisions de variables.

Exemples concrets et professionnels

La méthode 7-1 (architecture classique)

La méthode 7-1 est une convention très répandue :

STRUCTURE
scss/
├─ abstracts/   // variables, fonctions, mixins
├─ base/        // reset, typographie globale
├─ components/  // boutons, cartes, modales…
├─ layout/      // header, footer, grid…
├─ pages/       // styles spécifiques à des pages
├─ themes/      // thèmes (dark, light…)
├─ vendors/     // libs externes
└─ main.scss
À retenir

7-1 n'est pas une règle absolue, mais une base solide. Tu peux l'adapter selon la taille du projet.

Centraliser les tokens (settings / abstracts)

Toutes les décisions de design vivent dans abstracts :

SCSS :

SCSS
// abstracts/_colors.scss
$colors: (
  primary: #7aa7ff,
  bg: #0b1020,
  text: #ffffff
);
SCSS
// abstracts/_functions.scss
@function color($key) {
  @return map-get($colors, $key);
}

Exposer proprement avec @forward

@forward permet de créer une API claire pour un dossier.

SCSS :

SCSS
// abstracts/_index.scss
@forward "colors";
@forward "functions";
@forward "mixins";
SCSS
// main.scss
@use "abstracts" as *;

body {
  background: color(bg);
  color: color(text);
}
Conseil terrain

Utilise as * avec parcimonie, uniquement pour les tokens globaux.

Architecture orientée composants

Chaque composant est autonome :

STRUCTURE
components/
├─ _button.scss
├─ _card.scss
├─ _modal.scss

Les composants utilisent les tokens, mais ne définissent jamais de valeurs "magiques".

Bonnes pratiques

  • Découper le code par responsabilité, pas par type de propriété.
  • Centraliser toutes les décisions de design.
  • Utiliser @use / @forward systématiquement.
  • Documenter l'architecture pour l'équipe.
  • Refactoriser régulièrement (ne pas laisser la dette s'installer).
À retenir

Une architecture n'est jamais "finie" : elle évolue avec le projet.

Erreurs courantes

Erreur 1 : trop de fichiers sans logique

Trop de découpage sans règles claires est aussi néfaste qu'un seul gros fichier.

Erreur 2 : dépendances cachées entre fichiers

Un composant ne devrait jamais dépendre d'un autre composant "par accident".

Erreur 3 : ignorer @use / @forward

Continuer à utiliser @import conduit à des collisions et à un code fragile.

Exemple à éviter :

SCSS
// ❌ Ancienne méthode (obsolète)
@import "variables";
@import "mixins";
@import "components";

// ✅ Nouvelle méthode (recommandée)
@use "variables" as vars;
@use "mixins";
@use "components";

Résumé du chapitre

Ce que vous avez appris
✓
Une architecture SCSS est indispensable pour les projets durables.
✓
La méthode 7-1 est une base éprouvée et adaptable.
✓
@use et @forward rendent le code plus sûr et lisible.
✓
Les composants doivent rester autonomes et basés sur des tokens.

Prochain chapitre : Bonnes pratiques et performances

Dans le prochain chapitre, nous verrons les bonnes pratiques et performances : comment écrire du SCSS propre, éviter les pièges de performance et livrer un CSS efficace.

  • Écriture de SCSS propre et maintenable
  • Optimisation des performances CSS
  • Éviter les pièges courants
  • Outils d'analyse et de mesure
← Chapitre 16 – Responsive design avec SCSS Chapitre 18 – Bonnes pratiques et performances →