Faut-il vraiment onze thèmes distincts pour proposer, à onze distributeurs différents, une page de simulation d’assurance auto à leurs couleurs respectives, alors que le formulaire, les champs et la logique de calcul restent rigoureusement identiques d’un partenaire à l’autre ? La réponse tenait dans les variations de styles, pas dans la multiplication des thèmes.
Le besoin : une identité par distributeur, une logique commune
Chaque distributeur revend le même produit d’assurance auto, avec sa propre charte graphique et son propre nom de marque affiché sur la page. Le formulaire de simulation, en revanche, pose exactement les mêmes questions à l’utilisateur, dans le même ordre, et transmet les données au même service de calcul de prime en arrière-plan.
L’architecture retenue
architecture-simulation/
├── thème unique « simulation-auto »
│ ├── templates/
│ │ └── page-simulation.html (formulaire, structure commune)
│ ├── parts/
│ │ └── en-tete-distributeur.html (logo dynamique)
│ └── styles/
│ ├── distributeur-alpha.json
│ ├── distributeur-beta.json
│ └── ... (une variation par distributeur)
└── résolution de la variation
└── selon un paramètre d'URL ou un sous-domaine dédié
Résoudre la bonne variation selon le distributeur
Chaque distributeur accède à la simulation via un sous-domaine dédié, par exemple simulation.distributeur-alpha.exemple.fr. Un filtre côté PHP intercepte cette information pour appliquer la variation de styles correspondante avant le rendu de la page, sans dupliquer le moindre template.
add_filter( 'wp_theme_json_data_theme', function( $theme_json ) {
$sous_domaine = explode( '.', $_SERVER['HTTP_HOST'] )[0];
$chemin_variation = get_template_directory() . "/styles/{$sous_domaine}.json";
if ( file_exists( $chemin_variation ) ) {
$donnees_variation = json_decode( file_get_contents( $chemin_variation ), true );
$theme_json = $theme_json->update_with( $donnees_variation );
}
return $theme_json;
} );Le logo affiché dans le template part d’en-tête suit la même logique de résolution, via un champ personnalisé associé au sous-domaine plutôt qu’un logo codé en dur dans le template.
Ce que cette architecture évite
- Onze thèmes à maintenir individuellement, avec le risque qu’une correction de bug soit appliquée sur certains sans l’être sur les autres.
- Onze copies du formulaire de simulation, avec le risque de divergence progressive dans la logique de calcul embarquée côté front.
- Une mise à jour de sécurité à répéter onze fois plutôt qu’une seule sur le thème unique.
La limite de cette approche
Les variations de styles couvrent efficacement les couleurs, la typographie et les espacements, mais elles ne permettent pas de modifier la structure même du formulaire pour un distributeur qui demanderait, par exemple, un champ supplémentaire spécifique à son offre commerciale. Dans ce cas de figure, une véritable divergence fonctionnelle apparaîtrait, et l’architecture à thème unique montrerait ses limites face à un besoin réellement différent d’un partenaire à l’autre.
Une variation de styles n’est pertinente que tant que la différence entre deux contextes reste purement visuelle : dès qu’elle devient fonctionnelle, c’est un autre problème à traiter séparément.
Ce qui reste hors périmètre
Le calcul de prime lui-même, effectué par un service externe dédié à l’actuariat, ne relève pas de cette architecture de présentation. Le thème se contente de transmettre les données saisies et d’afficher le résultat retourné, sans jamais porter la logique métier du calcul.
Notre verdict
Face à un besoin de personnalisation purement visuelle répété sur plusieurs partenaires distributeurs, un thème unique combiné à des variations de styles résolues dynamiquement reste largement préférable à la multiplication de thèmes distincts. La maintenance s’en trouve concentrée sur un seul point, ce qui réduit d’autant le risque de divergence non maîtrisée entre les partenaires.
