# Organiser une bibliothèque de 80 patterns : catégories, nommage et mots-clés

> Passé la trentaine de patterns, l'inserter devient illisible si personne n'a pensé la structure. Voici l'arborescence et les conventions qui tiennent à l'échelle.

- Auteur : Clément Hadrot
- Publié le : 2024-03-21
- Mis à jour le : 2024-03-21
- Catégorie : FSE
- URL : https://wpmoderne.dev.wordpress-developpement.fr/fse/organiser-bibliotheque-80-patterns/

## L’essentiel

- Une catégorie personnalisée par usage, pas par type de bloc
- Un fichier par pattern, avec un en-tête complet
- Séparer les patterns visibles des patterns de démarrage

Le thème sur mesure d'un client e-commerce a fini par contenir un peu plus de quatre-vingts patterns : bandeaux promotionnels, blocs de réassurance, grilles de produits, variantes de témoignages, sections de landing page. Sans organisation, l'inserter de blocs devient une liste interminable où personne ne retrouve rien — et où les rédacteurs recréent à la main des mises en page qui existaient déjà, faute de les avoir vues passer.

Voici l'arborescence de fichiers et les conventions de nommage qui ont permis de garder ce catalogue exploitable, projet après projet.

## Un fichier par pattern, avec un en-tête complet

Chaque pattern déclaré dans le dossier `patterns/` d'un thème bloc est reconnu automatiquement par WordPress, sans appel PHP explicite, à condition que le fichier commence par un en-tête de commentaire structuré :

```
<?php
/**
 * Title: Grille de trois produits mis en avant
 * Slug: mon-theme/grille-produits-trois
 * Categories: mon-theme-produits
 * Keywords: produit, grille, mise en avant
 * Block Types: core/query
 * Viewport Width: 1400
 * Inserter: true
 */
?>
<!-- wp:group {"layout":{"type":"grid","columns":3}} -->
...
<!-- /wp:group -->
```

Le champ **Slug** doit être préfixé par le nom du thème (ou de l'extension) pour éviter toute collision avec un pattern d'une autre extension portant un nom proche — un piège fréquent une fois plusieurs extensions à patterns actives sur le même site.

> L'essentiel à retenir : Une catégorie personnalisée par usage, pas par type de bloc ; Un fichier par pattern, avec un en-tête complet ; Séparer les patterns visibles des patterns de démarrage

## Des catégories personnalisées organisées par usage, pas par type de bloc

La tentation initiale est de classer par type de bloc dominant (« Groupes », « Colonnes »). Elle ne survit jamais à l'échelle : un rédacteur ne cherche pas « un pattern en colonnes », il cherche « une section héros » ou « un bloc de témoignages ». Les catégories personnalisées se déclarent via `register_block_pattern_category()`, généralement dans le fichier `functions.php` du thème ou un fichier dédié inclus depuis celui-ci :

```
register_block_pattern_category(
    'mon-theme-heros',
    array( 'label' => __( 'Sections héros', 'mon-theme' ) )
);
register_block_pattern_category(
    'mon-theme-reassurance',
    array( 'label' => __( 'Réassurance et confiance', 'mon-theme' ) )
);
```

Sur le projet en question, la liste finale comptait neuf catégories métier (héros, réassurance, produits, témoignages, appels à l'action, équipe, tarifs, FAQ, pied de page), chacune contenant entre six et douze patterns — une taille qui reste parcourable sans faire défiler l'inserter pendant une minute.

## Arborescence retenue

```
mon-theme/
├── patterns/
│   ├── heros-simple.php
│   ├── heros-avec-image.php
│   ├── produits-grille-trois.php
│   ├── produits-carrousel.php
│   ├── temoignages-carte-unique.php
│   ├── temoignages-slider.php
│   ├── reassurance-icones.php
│   ├── cta-newsletter.php
│   ├── cta-telechargement.php
│   └── ... (jusqu'à 80 fichiers)
├── inc/
│   └── pattern-categories.php
└── functions.php
```

Le fichier `inc/pattern-categories.php` centralise tous les `register_block_pattern_category()`, chargé une seule fois depuis `functions.php`. Chaque nom de fichier de pattern reprend, dans l'ordre, la catégorie puis la variante — ce qui rend le dossier lui-même lisible dans un explorateur de fichiers, indépendamment de l'inserter.

## Mots-clés : penser au vocabulaire du rédacteur, pas du développeur

Le champ **Keywords** alimente la recherche de l'inserter. Un rédacteur qui tape « avis » doit retrouver le pattern de témoignages même si son nom technique ne contient pas ce mot. Sur ce projet, chaque pattern porte systématiquement trois à cinq mots-clés couvrant les synonymes courants du métier (« avis », « témoignage », « client » pour un même pattern), en plus de son intitulé technique.

## Séparer les patterns visibles des patterns de démarrage

Certains patterns ne sont utiles qu'au moment de créer une nouvelle page (des mises en page complètes de type « page de destination ») et n'ont pas vocation à être insérés bloc par bloc dans un contenu existant. Le champ **Inserter: false** les masque de la liste standard tout en les gardant disponibles comme modèles de démarrage de page (déclarés séparément via `register_block_pattern()` avec la propriété `blockTypes` ciblant `core/post-content`, ou proposés dans le sélecteur de patterns à la création d'une page).

- Patterns de section (héros, CTA, grille) : visibles dans l'inserter, utilisables partout.
- Patterns de page complète : masqués de l'inserter, proposés uniquement à la création d'une nouvelle page.
- Patterns d'essai ou en cours de conception : dans un sous-dossier `patterns/_brouillons/` non chargé par WordPress (le renommage en dehors du dossier reconnu suffit à les exclure), le temps de les valider.

## Notre verdict

Passé la trentaine de patterns, l'organisation cesse d'être un détail cosmétique : elle détermine si l'équipe éditoriale réutilise réellement le catalogue ou recrée ses propres mises en page en doublon. La combinaison catégories métier, mots-clés orientés utilisateur et séparation claire entre patterns de section et patterns de page complète a, sur ce projet, ramené le temps de recherche d'un pattern à quelques secondes plutôt qu'à un défilement sans fin.
