# Patterns FSE ou builder établi : comment composer une page d’accueil en 2024

> Sur un projet récent d'agence, il fallait trancher entre patterns natifs et builder établi pour la page d'accueil. Comparatif concret, sans dogmatisme.

- Auteur : Clément Hadrot
- Publié le : 2024-01-23
- Mis à jour le : 2024-01-23
- Catégorie : FSE
- URL : https://wpmoderne.dev.wordpress-developpement.fr/fse/patterns-vs-builder-page-accueil/

## L’essentiel

- Patterns natifs : rapidité de maintenance, dépendance zéro
- Builder établi : richesse d'effets, courbe d'apprentissage client
- Le choix dépend du profil de l'équipe qui reprendra le site

Une agence pour laquelle j'interviens en sous-traitance devait livrer la page d'accueil d'un cabinet de conseil en janvier, avec une contrainte inhabituelle : le client changerait probablement d'équipe technique dans l'année. La question s'est posée frontalement en réunion de cadrage : partir sur des patterns FSE natifs, ou repartir sur le builder établi que l'agence utilisait depuis des années sur ses projets classiques.

Plutôt que de trancher par habitude, on a construit un prototype de la même page avec les deux approches, en chronométrant le temps de production et en évaluant la facilité de reprise. Voici ce que ce test m'a appris, sans dogmatisme pour l'une ou l'autre solution.

## Le prototype patterns FSE : rapide une fois la base posée

Avec un thème bloc déjà doté d'un `theme.json` soigné et de quelques patterns de section (hero, grille de services, témoignages, appel à l'action), la page d'accueil s'est assemblée en un peu moins de trois heures. Chaque section correspondait à un pattern enregistré côté thème, avec du contenu modifiable directement dans l'éditeur, sans configuration supplémentaire.

```
register_block_pattern(
    'cabinet-conseil/hero-accueil',
    array(
        'title'      => __( 'Hero page d\'accueil', 'cabinet-conseil' ),
        'categories' => array( 'cabinet-conseil' ),
        'content'    => file_get_contents( get_theme_file_path( 'patterns/hero-accueil.html' ) ),
    )
);
```

L'avantage principal tenait à la légèreté : aucune dépendance externe, un site qui reste utilisable même si le plugin de builder venait à disparaître, et un temps de chargement mesuré à 1,1 seconde en Largest Contentful Paint sur un hébergement mutualisé standard.

## Le prototype builder établi : plus long à démarrer, plus riche en effets

> L'essentiel à retenir : Patterns natifs : rapidité de maintenance, dépendance zéro ; Builder établi : richesse d'effets, courbe d'apprentissage client ; Le choix dépend du profil de l'équipe qui reprendra le site

Avec le builder établi utilisé habituellement par l'agence, la même page a demandé environ neuf heures de production. Une partie de ce temps s'explique par la configuration initiale : import de templates du builder, ajustement des styles globaux qui entraient parfois en conflit avec les réglages natifs de WordPress, et calibrage des animations au scroll souhaitées par le client.

En contrepartie, certains effets demandés (parallaxe léger sur le hero, compteurs animés dans la section chiffres clés) auraient nécessité du JavaScript sur-mesure côté FSE, alors qu'ils étaient disponibles nativement dans le builder en quelques clics. C'est un point réel en faveur du builder pour des demandes visuelles sophistiquées.

## Tableau comparatif sur ce projet précis

| Critère | Patterns FSE natifs | Builder établi |
| --- | --- | --- |
| Temps de production mesuré | 2 h 50 | 9 h 10 |
| LCP mesuré (PageSpeed) | 1,1 s | 2,4 s |
| Dépendance à un plugin tiers | Aucune | Forte |
| Effets avancés (parallaxe, compteurs) | Développement sur-mesure requis | Disponibles nativement |
| Reprise par une équipe technique différente | Immédiate, standard WordPress | Nécessite de connaître le builder |

## Le critère qui a fait pencher la balance : qui reprendra le site

Le client ayant explicitement mentionné un possible changement de prestataire, le critère de reprise a pesé plus lourd que la richesse d'effets. Une équipe technique arrivant sur un site en patterns FSE natifs retrouve des structures WordPress standards, documentées par le Core lui-même. Sur un builder établi, même très répandu, la reprise suppose une connaissance spécifique de son fonctionnement interne, de sa syntaxe de shortcodes ou de ses attributs propriétaires.

### Ce que le client a finalement demandé

Face au tableau ci-dessus, présenté tel quel en réunion, le client a choisi les patterns FSE natifs, en acceptant de renoncer au parallaxe pour un dégradé statique plus sobre. Le compteur animé, lui, a été conservé via un petit script d'Interactivity API développé sur-mesure, pour un coût de développement raisonnable au vu du gain en indépendance technique.

> Le builder le plus riche n'est pas toujours le bon choix : posez d'abord la question de qui maintiendra le site dans deux ans, avant celle des effets visuels possibles aujourd'hui.

## Dans quels cas le builder reste pertinent

- Le client possède déjà une licence active et une équipe formée dessus en interne.
- Le projet exige des mises en page très irrégulières, changeant fréquemment, où la vélocité d'édition visuelle prime sur la légèreté du code produit.
- Des animations complexes sont un impératif commercial du projet, sans budget pour du développement sur-mesure en Interactivity API.

## Notre verdict

Sur ce projet précis, les patterns FSE natifs l'ont emporté grâce à leur légèreté, leur absence de dépendance et leur facilité de reprise, au prix de quelques concessions sur les effets visuels les plus sophistiqués. Ce n'est pas un verdict universel : le builder reste un choix défendable dès que la richesse d'interaction prime sur l'indépendance technique à long terme du site.