Faut-il créer ses champs personnalisés plutôt qu'installer une extension ?

Ajouter trois champs à un type de contenu conduit presque toujours à installer une extension de gestion de champs personnalisés, solution éprouvée, documentée et connue de tout le monde. Elle apporte une interface de configuration, une bibliothèque de types de champs, une gestion des conditions d'affichage et des fonctions de lecture confortables. Elle apporte aussi une dépendance, un modèle de stockage qu'on ne maîtrise pas et, pour certaines fonctions, une licence à renouveler. La question de créer ses champs personnalisés soi même mérite donc d'être posée honnêtement, avec ses vrais critères, qui ne sont pas ceux que l'on invoque habituellement.

Ce que fait une extension de champs personnalisés

Avant de décider de s'en passer, il faut savoir précisément ce qu'elle apporte, car la liste est plus longue qu'on ne l'imagine en regardant une simple boîte de saisie. Le fonctionnement de la solution la plus répandue est présenté dans notre article sur la manière d'utiliser le plugin ACF sous WordPress.

Une interface de configuration

Le premier apport est de permettre à une personne non technique de créer et de modifier des champs depuis l'administration, sans écrire une ligne. Sur un projet où le client fera évoluer sa structure de contenu lui même, cet argument est décisif et clôt le débat. Sur un projet où la structure est figée et définie par le développeur, il ne pèse rien, ce qui explique que les avis divergent autant selon les contextes. La bonne question à poser au client est simple : compte t il ajouter des champs lui même, et si oui, à quelle fréquence.

Une bibliothèque de types de champs

Sélecteur de date, sélecteur d'image avec médiathèque, éditeur de texte enrichi, relation vers un autre contenu, carte, groupe répétable. Chacun de ces composants représente des heures de développement et surtout des heures de mise au point sur les cas particuliers. Réécrire un sélecteur d'image correct, avec la médiathèque et la prévisualisation, prend une journée à quelqu'un qui connaît le sujet, et c'est probablement le meilleur argument en faveur de l'extension. Ce coût est invisible tant qu'on ne s'y est pas frotté, ce qui explique les mauvaises estimations.

La logique conditionnelle

Afficher un champ selon la valeur d'un autre, selon le gabarit choisi ou selon le rôle de l'utilisateur relève d'une mécanique que les extensions gèrent nativement. L'écrire soi même demande du code côté navigateur et un contrôle côté serveur, ce qui double le travail. Cette fonction est rarement indispensable et devient très pénible à reproduire dès qu'elle l'est, ce qui en fait un bon critère de décision. Un cahier des charges qui mentionne des affichages conditionnels doit orienter vers l'extension sans discussion.

La lecture des valeurs

Les fonctions fournies masquent la complexité du stockage et retournent des objets exploitables plutôt que des identifiants bruts. Cette commodité a une contrepartie : le code des gabarits devient dépendant de l'extension, et son retrait suppose de tout réécrire. C'est le point qui rend une migration ultérieure coûteuse, et il mérite d'être pesé au moment du choix plutôt que découvert trois ans plus tard. Une couche d'abstraction, même sommaire, isolant les appels de lecture dans quelques fonctions du projet, réduit considérablement ce risque.

Le stockage

Les valeurs sont enregistrées dans les métadonnées de contenu, généralement sous deux entrées par champ, l'une pour la valeur et l'autre pour la référence à sa définition. Ce doublement gonfle la table des métadonnées et pèse sur les requêtes qui filtrent sur ces valeurs. Sur un site comportant beaucoup de contenus et beaucoup de champs, cet effet devient mesurable et constitue l'argument technique le plus solide en faveur d'une solution maison. La table des métadonnées de plusieurs millions de lignes est un symptôme fréquent des sites où cette question n'a jamais été posée.

Le coût réel

La version gratuite couvre l'essentiel des besoins courants. Les fonctions avancées, groupes répétables, blocs personnalisés, options globales, relèvent d'une licence annuelle par site ou par agence. Ce coût est modeste rapporté à un projet, il devient significatif sur un parc de plusieurs dizaines de sites, et il constitue une dépendance commerciale qu'il faut assumer consciemment. Le renouvellement doit figurer dans le budget d'exploitation du site, faute de quoi il devient un incident à l'échéance.

Quand le faire soi même

Les cas où une solution maison se justifie sont plus nombreux qu'on ne le pense, et ils se reconnaissent à quelques signes assez précis pour être listés.

Un petit nombre de champs figés

Trois à cinq champs simples, définis une fois et jamais modifiés, ne justifient pas une extension complète. Une centaine de lignes suffit à déclarer une boîte de saisie, à afficher les champs, à les enregistrer et à les lire. Le code obtenu est lisible, sans dépendance, et il ne pèse rien sur les performances. C'est le cas de figure le plus fréquent sur les sites vitrines et il est presque toujours traité par une extension par habitude. L'habitude n'est pas un mauvais réflexe en soi, elle mérite simplement d'être questionnée une fois.

Un besoin de performance sur le filtrage

Filtrer ou trier des contenus sur la valeur d'un champ personnalisé produit des requêtes lourdes, la table des métadonnées n'étant pas conçue pour cet usage. Une solution maison peut stocker ces valeurs dans une table dédiée, correctement indexée, ce qui change complètement les performances. Sur un site où ce filtrage est central, annuaire, catalogue, base documentaire, cet argument à lui seul justifie le développement. Une table dédiée avec un index sur la colonne filtrée transforme une requête de plusieurs secondes en une requête instantanée.

Une extension distribuée

Une extension destinée à être installée sur des sites que l'on ne maîtrise pas ne peut pas dépendre d'une autre extension, sous peine de ne pas fonctionner. Elle doit donc déclarer ses champs elle même. C'est un cas où la question ne se pose même pas, et il concerne également les thèmes destinés à être diffusés, qui ne doivent jamais supposer la présence d'un module tiers. La règle vaut également pour les thèmes enfants livrés à un client, dont l'autonomie doit être garantie.

Une volonté de réduire les dépendances

Chaque extension installée est une surface de mise à jour, une source potentielle d'incompatibilité et un risque de sécurité. Sur un site où l'on cherche à minimiser ce nombre, remplacer une extension par cent lignes de code est un gain net. Ce raisonnement doit toutefois être appliqué avec mesure, car cent lignes écrites à la va vite représentent aussi un risque, comme nous le rappelons dans notre article sur la manière de bien choisir une extension pour WordPress. Une extension établie et maintenue est souvent plus sûre qu'un développement rapide non relu.

Un stockage particulier

Certains besoins ne se satisfont pas des métadonnées : données volumineuses, valeurs partagées entre plusieurs contenus, historique de modifications, relations complexes. Une solution maison permet de choisir la structure adaptée plutôt que de contorsionner un mécanisme prévu pour autre chose. Ce cas se rencontre dès que le site s'éloigne de la publication éditoriale pour se rapprocher d'une application. Il justifie alors une modélisation propre, avec ses tables et ses contraintes, plutôt qu'un empilement de métadonnées.

Quand ne pas le faire

À l'inverse, il ne faut pas se lancer si le projet comporte des groupes répétables, des relations entre contenus, des sélecteurs d'image nombreux, ou si la structure doit évoluer sans intervention technique. Dans ces cas, l'extension apporte largement plus qu'elle ne coûte, et vouloir la réécrire est une erreur classique de développeur qui sous estime le travail de mise au point des composants d'interface. Le temps passé à reproduire un sélecteur d'image serait bien mieux employé ailleurs sur le projet.

Construire une solution maison correcte

Une solution maison mal écrite est bien pire qu'une extension, sur tous les plans à la fois. Quelques principes suffisent à obtenir un résultat propre et durable.

Déclarer une boîte de saisie

Une boîte de saisie s'enregistre auprès du système en indiquant les types de contenu concernés, sa position et sa priorité. La fonction d'affichage produit le formulaire, en reprenant les classes de l'administration afin que le résultat s'intègre visuellement. Ce point cosmétique compte davantage qu'il n'y paraît : un formulaire qui ne ressemble pas au reste de l'administration donne une impression de bricolage et gêne réellement les personnes qui l'utilisent. Reprendre les classes existantes coûte quelques minutes et suffit à obtenir un rendu cohérent.

Nommer les champs avec un préfixe

Les clés de métadonnées doivent porter un préfixe propre au projet, afin d'éviter toute collision avec une extension installée ultérieurement. Un préfixe commençant par un caractère de soulignement rend en outre la métadonnée invisible dans l'interface générique des champs personnalisés, ce qui évite qu'elle n'y soit modifiée par erreur. Ces deux conventions coûtent quelques caractères et évitent des incidents difficiles à diagnostiquer. Le préfixe doit également être choisi une fois pour toutes et documenté, afin que les développements ultérieurs le respectent.

Valider avant d'enregistrer

Chaque valeur reçue doit être contrôlée selon son type avant enregistrement : entier converti, adresse validée, texte nettoyé, choix comparé à une liste autorisée. Cette validation est exactement celle que l'on applique à n'importe quelle donnée reçue, et son absence est le défaut le plus courant des développements maison. Elle ne prend que quelques lignes par champ et rend le stockage fiable. Un champ mal validé produit des données que les gabarits devront ensuite traiter défensivement, ce qui déplace le problème sans le résoudre.

Vérifier le nonce et la capacité

L'enregistrement se déclenche à chaque sauvegarde de contenu, y compris lors des sauvegardes automatiques et des modifications rapides depuis la liste. Le traitement doit donc vérifier le nonce, vérifier que l'utilisateur a le droit de modifier ce contenu précis, et écarter les sauvegardes automatiques. Ces trois contrôles sont détaillés dans notre article sur la manière de sécuriser une extension WordPress. Leur oubli est le défaut de sécurité le plus fréquent des développements maison de ce type.

Échapper à l'affichage

Les valeurs affichées dans le formulaire d'administration comme dans le gabarit public doivent être échappées selon leur contexte. Une valeur enregistrée par un administrateur reste une valeur à traiter, et le raisonnement selon lequel une donnée saisie en interne serait sûre ne tient pas. Cette systématicité coûte quelques caractères par affichage et ferme définitivement une catégorie de défauts. Le formulaire d'administration est d'ailleurs le premier endroit où une valeur non échappée casse la page, ce qui la rend visible immédiatement.

Prévoir la suppression

Un champ vidé doit voir sa métadonnée supprimée plutôt qu'enregistrée avec une valeur vide, ce qui évite d'accumuler des entrées inutiles dans la base. De même, la désinstallation de l'extension doit proposer le nettoyage des données, opération que la plupart des développements maison omettent et qui laisse des traces indéfiniment. Ces deux points relèvent de la propreté élémentaire et se traitent en quelques lignes. Ils font la différence entre un développement dont on est satisfait trois ans plus tard et un développement que l'on regrette.

Ce qu'il ne faut pas sous-estimer

Le développement initial est la partie facile. Il représente rarement plus d'un quart du coût total sur la durée de vie du site. Ce qui suit détermine si la décision était bonne, et il se juge sur plusieurs années.

L'interface pour les rédacteurs

Un champ sans libellé explicite, sans texte d'aide et sans indication de format produit des saisies incohérentes et des questions répétées. Le soin apporté à ces détails représente une part importante du travail et il est systématiquement négligé dans les développements maison, alors que les extensions le fournissent gratuitement. Une demi journée consacrée aux libellés et aux aides se rentabilise dès le premier mois d'utilisation. Elle se rentabilise surtout en qualité de saisie, ce qui se répercute directement sur le contenu publié.

La documentation

La liste des champs, leur clé, leur type et la façon de les lire dans un gabarit doit être écrite quelque part. Sans cette note, la personne qui reprendra le site devra lire le code pour comprendre la structure, ce qui prend dix fois plus de temps. C'est le principal avantage pratique des extensions établies : leur documentation existe et n'est pas à écrire. Une page dans le fichier de description du projet suffit à combler cet écart, à condition d'y penser au moment du développement.

L'évolution du besoin

Un besoin de trois champs figés devient régulièrement un besoin de douze champs avec conditions et répétitions, en deux ans. Le code maison écrit pour le premier cas ne convient plus au second et devra être remplacé. Anticiper cette évolution, en évaluant honnêtement la probabilité qu'elle survienne, est le vrai critère de décision, bien plus que la comparaison des fonctionnalités du moment. Poser la question au client, en lui demandant ce qu'il imagine faire dans deux ans, donne généralement une réponse utilisable.

La compatibilité avec l'éditeur

L'éditeur de blocs modifie la façon dont les boîtes de saisie sont affichées, et certaines constructions anciennes s'y intègrent mal. Une solution maison doit être testée dans l'éditeur réellement utilisé, et adaptée si nécessaire. Ce point évolue avec les versions de WordPress, ce qui constitue une charge d'entretien récurrente que l'on n'avait pas prévue en écrivant le code. Les extensions établies absorbent cette charge à votre place, ce qui fait partie de ce que l'on paie.

La reprise par un tiers

Un prestataire intervenant sur le site connaîtra l'extension établie et devra apprendre votre solution maison. Ce coût, réel, se paie à chaque intervention extérieure et doit être compté dans la comparaison. Il se réduit fortement si le code suit les conventions habituelles et s'il est documenté, ce qui ramène la question à la qualité du travail plutôt qu'au choix lui même. Un code maison propre et documenté se reprend sans difficulté, un code maison obscur coûte plus cher qu'une migration.

La décision raisonnable

En pratique, la règle qui se vérifie le mieux consiste à écrire soi même en dessous de cinq champs simples et figés, et à installer une extension au delà ou dès qu'un composant d'interface un peu élaboré est nécessaire. Cette limite paraît basse et correspond pourtant à ce que l'on constate en reprenant des sites : au delà, les développements maison finissent par réimplémenter une extension, en moins bien et sans documentation. Cette limite se révise évidemment selon les compétences disponibles et selon la nature du projet, mais elle constitue un point de départ honnête. Elle mérite aussi d'être posée par écrit au début du projet, car la même question reprise en cours de route, une fois le développement engagé, ne reçoit jamais de réponse objective.