Deux façons de stocker les réglages d’une extension reviennent sans cesse dans les projets que j’accompagne : tout regrouper dans une unique option sérialisée (un tableau PHP encodé automatiquement par WordPress), ou déclarer une option distincte pour chaque réglage. Aucune des deux n’est universellement supérieure ; le bon choix dépend du nombre de réglages, de leur fréquence de modification, et de la façon dont ils seront lus par le reste du code.
Voici un comparatif mesuré des deux stratégies, sur des critères concrets plutôt que sur une préférence de style.
Option unique : tout dans un tableau sérialisé
update_option( 'kaolin_reglages', array(
'devise' => 'EUR',
'delai_livraison' => 5,
'notifications' => array( 'email' => true, 'sms' => false ),
) );
$reglages = get_option( 'kaolin_reglages', array() );
$devise = $reglages['devise'] ?? 'EUR';
Cette approche, très répandue dans les extensions distribuées sur WordPress.org, s’accorde naturellement avec la Settings API et son mécanisme de groupe d’options unique. Un seul appel à get_option() suffit à récupérer l’ensemble des réglages, ce qui limite le nombre de requêtes en base pour une extension qui consulte plusieurs réglages dans la même page.
Options multiples : une entrée par réglage
update_option( 'kaolin_devise', 'EUR' );
update_option( 'kaolin_delai_livraison', 5 );
update_option( 'kaolin_notification_email', true );
update_option( 'kaolin_notification_sms', false );
$devise = get_option( 'kaolin_devise', 'EUR' );
Chaque réglage devient une ligne indépendante dans wp_options, ce qui permet de mettre à jour un seul réglage sans jamais avoir à relire puis réécrire l’ensemble du tableau, et sans risque d’écraser une modification concurrente sur un autre réglage.
Comparatif sur les critères qui comptent vraiment
| Critère | Option unique | Plusieurs options |
|---|---|---|
| Nombre de requêtes en lecture | Une seule, quel que soit le nombre de réglages | Une par réglage consulté, sauf préchargement group |
| Risque d’écrasement concurrent | Réel si deux processus modifient des réglages différents en même temps | Nul, chaque réglage est indépendant |
| Compatibilité avec la Settings API | Native et directe, un seul groupe d’options | Demande une déclaration explicite par réglage via register_setting |
| Autoload et performance | Un seul enregistrement à charger ou exclure de l’autoload | Autoload à gérer réglage par réglage, plus de contrôle mais plus de rigueur requise |
| Facilité de migration de schéma | Simple : on modifie la structure du tableau dans une seule fonction | Plus verbeux : chaque réglage renommé ou restructuré demande sa propre migration |
| Ciblage par un plugin tiers | Difficile : un filtre externe doit connaître toute la structure du tableau | Facile : un filtre peut cibler un unique get_option par son nom |
Le risque d’écrasement concurrent, en pratique
Ce risque, souvent théorique dans la documentation, s’est révélé bien réel sur un projet de billetterie en ligne : deux écrans d’administration distincts, ouverts simultanément par deux membres différents de l’équipe, modifiaient chacun un sous-ensemble différent du même tableau de réglages sérialisé. Le second enregistrement écrasait systématiquement les modifications du premier, invisibles jusqu’à ce qu’un client signale la disparition d’un réglage pourtant bien modifié quelques minutes plus tôt.
Le correctif a consisté à migrer les réglages les plus sujets à modification concurrente (les statuts d’activation de chaque type de billet) vers des options individuelles, tout en conservant les réglages rarement modifiés (les mentions légales, le texte des courriels de confirmation) dans le tableau sérialisé existant. Une approche hybride, plus pragmatique qu’un choix strictement binaire.
Le nombre de réglages comme critère décisif
- Moins de dix réglages, rarement modifiés indépendamment : l’option unique reste largement suffisante et la plus simple à maintenir
- Plusieurs dizaines de réglages, ou des réglages modifiés fréquemment et de façon isolée les uns des autres : les options multiples réduisent les risques et facilitent le ciblage externe
- Un cas mixte, comme sur ce projet de billetterie : rien n’empêche de faire cohabiter les deux stratégies au sein de la même extension, tant que la logique de séparation reste documentée et cohérente
Le vrai critère n’est pas le nombre de réglages en soi, mais la probabilité que deux d’entre eux soient modifiés indépendamment, par deux personnes ou deux processus différents, au même moment.
Notre verdict
Pour une extension simple, avec une poignée de réglages consultés ensemble et modifiés rarement, l’option unique reste le choix le plus économique en code et en requêtes. Dès qu’un projet grandit, que plusieurs personnes interviennent en parallèle dans l’admin, ou qu’un réglage doit être exposé à d’autres extensions via un simple get_option, la bascule vers des options individuelles, au moins pour les réglages concernés, devient la décision la plus robuste sur la durée.
