# Antipatterns : des horaires de restaurant codés en dur dans le template > Coder les horaires d'ouverture directement dans header.php semble anodin, jusqu'au premier changement saisonnier qui oblige à rouvrir le code du thème. - Auteur : WordPress Développement - Publié le : 2020-07-15 - Mis à jour le : 2020-07-15 - Catégorie : Thèmes - URL : https://www.wpmoderne.fr/themes/antipattern-horaires-restaurant-codes-en-dur-template/ ## L’essentiel - Un horaire codé en dur devient un ticket de développeur à chaque saison - Un champ personnalisé transfère cette responsabilité à l'équipe du restaurant - La logique d'affichage reste dans le thème, seule la donnée change de place « On peut juste écrire les horaires directement dans le header, ça ira plus vite. » Cette phrase, prononcée en fin de projet quand le budget de développement touche à sa fin, revient plus souvent qu'on ne le pense. Elle semble raisonnable sur le moment : les horaires d'un restaurant ne changent pas tous les jours, alors pourquoi construire un système de champs personnalisés pour trois lignes de texte ? Le problème apparaît quelques mois plus tard, au premier changement de saison. Le restaurant passe à des horaires d'été, puis revient aux horaires d'hiver, ajoute une fermeture exceptionnelle pour congés, et chaque changement nécessite de rouvrir `header.php`, de modifier le HTML à la main, puis de redéployer le thème. Ce qui semblait être un gain de temps initial se transforme en charge de maintenance récurrente, à la fois pour le développeur et pour le restaurant qui dépend de lui. ## Ce qu'on observe sur le terrain Le motif se répète presque à l'identique d'un projet à l'autre. Le template `header.php` contient un bloc HTML du type : ```

Lundi - Vendredi : 12h - 14h30, 19h - 22h30

Samedi : 19h - 23h

Dimanche : fermé

``` Ce fragment est écrit une fois, au moment du développement, puis oublié jusqu'au jour où le restaurant appelle pour signaler que ses horaires ont changé et demande une mise à jour du site. ## Pourquoi c'est un problème Le souci ne tient pas à la complexité technique du changement lui-même, généralement trivial, mais à la dépendance qu'il crée. Chaque modification d'horaire, même mineure, nécessite l'intervention d'une personne capable de modifier du code PHP et de redéployer le site. Pour une information aussi volatile que des horaires d'ouverture, cette dépendance ne correspond à aucun besoin réel de contrôle technique : il ne s'agit que d'un contenu éditorial, au même titre qu'un texte de présentation. > L'essentiel à retenir : Un horaire codé en dur devient un ticket de développeur à chaque saison ; Un champ personnalisé transfère cette responsabilité à l'équipe du restaurant ; La logique d'affichage reste dans le thème, seule la donnée change de place Cette confusion entre donnée et présentation se retrouve dans de nombreux antipatterns de thèmes WordPress : un numéro de téléphone codé en dur dans le pied de page, une adresse postale écrite directement dans un template, une citation d'ouverture saisonnière figée dans le code. Dans tous ces cas, une information qui appartient au contenu se retrouve enfermée dans la logique du thème. ## Ce qu'on préfère à la place La correction ne demande pas un système complexe : un ou plusieurs champs personnalisés, saisis depuis l'écran d'options du thème ou directement sur une page dédiée, suffisent à séparer la donnée de sa présentation. Le template continue de définir la structure et le style d'affichage ; seule la valeur des horaires devient modifiable sans toucher au code. ``` function restaurant_get_horaires() { return get_option( 'restaurant_horaires_semaine', '' ); } ``` Cette fonction d'accès centralise la récupération de la donnée. Le template `header.php` n'affiche plus de texte codé en dur, mais appelle cette fonction et affiche son résultat, avec une valeur de repli si le champ n'a pas encore été renseigné. - Le restaurant modifie ses horaires depuis l'administration, sans intervention technique - Le format d'affichage (mise en forme, structure des jours) reste garanti par le thème - Un changement de dernière minute (fermeture exceptionnelle) se fait en quelques secondes - Le développeur n'est plus sollicité pour une simple mise à jour de contenu ## Le cas des horaires saisonniers multiples Pour un restaurant avec plusieurs jeux d'horaires selon la saison, un unique champ texte reste limité : il faudrait alors basculer manuellement entre les versions à chaque changement de saison. Une structure un peu plus élaborée, avec un champ par période et une date de bascule, répond mieux à ce besoin sans pour autant justifier un plugin de réservation complet, hors sujet ici. ## Ce qu'on ne préfère pas non plus Il serait tentant de pousser la logique jusqu'à confier cette information au Customizer natif de WordPress, avec un panneau dédié aux horaires. Cette option existe et fonctionne, mais elle rattache la donnée aux réglages du thème plutôt qu'au contenu du site, ce qui pose ses propres questions lors d'un changement de thème. Le choix entre champ personnalisé et Customizer dépend du contexte du projet et mérite d'être pesé séparément, sans qu'aucune des deux solutions ne domine systématiquement l'autre. > La question à se poser avant d'écrire une information dans un template n'est pas « est-ce que ça va changer souvent ? » mais « est-ce que la personne qui doit modifier cette information sait écrire du PHP ? ». La réponse tranche généralement le débat. ## En résumé Coder des horaires en dur dans un template ne pose aucun problème technique immédiat, mais transforme une simple mise à jour de contenu en ticket de développement récurrent. Un champ personnalisé, même rudimentaire, redonne l'autonomie à l'équipe du restaurant et libère le développeur d'une sollicitation qui n'a pas lieu d'être. Ce réflexe de séparation entre donnée éditoriale et logique de présentation vaut pour bien plus que des horaires : il mérite d'être appliqué à toute information susceptible de changer sans intervention technique.