La veille de la mise en ligne, on rouvre un ancien functions.php
Une liste de réglages que personne ne chiffre
Le site est prêt. Reste la partie que personne ne montre en réunion : rendre l’administration utilisable par la personne qui va s’en servir.
Il faut retirer les commentaires, dont ce site vitrine n’a aucun usage. Masquer les Articles, puisque le client ne bloguera pas. Sortir de l’écran d’édition les blocs qui n’ont jamais servi — les extraits, les révisions, les champs personnalisés. Nettoyer un tableau de bord couvert de widgets que plus personne ne lit. Et surtout, faire disparaître la douzaine d’entrées de menu sur lesquelles il n’a aucune raison de cliquer.
Rien de compliqué, pris un par un. Chaque point se règle en quelques lignes. Le problème, c’est qu’on les a déjà écrites — sur le projet précédent, et sur celui d’avant.
Rouvrir le dépôt d’un ancien site pour y prendre le bon bloc
Alors on va les chercher. On ouvre le dépôt d’un ancien site, on repère le bon bloc au milieu du reste, on copie, on colle. Parfois le code date de deux ans et ne fait plus ce qu’il annonce. Parfois on en oublie un, et on ne s’en aperçoit qu’après la mise en ligne. Parfois un collègue l’a modifié dans son coin sur son propre projet, et les deux sites de la même agence ne se comportent plus pareil.
Le tout se passe rarement au calme en début de projet. Ça se passe la veille, entre deux relectures, quand il reste trois autres choses à finir.
Une heure que personne ne paie
Une heure par site, vingt sites dans l’année
Comptez le temps réel : environ une heure par site. Sur vingt sites dans l’année, cela fait trois journées de travail.
Une heure invisible, donc la première sacrifiée
Ce n’est pas le plus gênant. Le plus gênant, c’est que cette heure est invisible. Le client ne l’a pas demandée, il ne la voit pas, il ne saurait pas la nommer. Elle ne figure sur aucune ligne de devis, et personne ne peut la défendre en négociation. C’est du temps qui sort de votre marge, silencieusement, à chaque projet.
Et quand elle saute — parce que la journée a été trop courte — la facture arrive plus tard. Le client repart avec un compte administrateur et l’intégralité des menus. Un matin, WordPress lui propose une mise à jour, il clique, et le site tombe. L’appel, lui, est bien pour vous.
Le copié-collé ne suffit pas, et c’est là que ça coince
Une base de départ commune, et ses limites
La réponse évidente serait de se constituer une base de départ, une fois pour toutes, et de la déployer partout.
Ce qui se décide à chaque livraison ne se duplique pas
Sauf que chaque client a ses particularités. Celui-ci publie des actualités, celui-là non. L’un a besoin des catégories, l’autre les trouve encombrantes. Sur ce projet, la personne qui met à jour le site est à l’aise et peut garder la main sur les extensions ; sur le suivant, elle ne doit voir que deux menus.
Ces choix se réfléchissent à chaque livraison. Ils ne se dupliquent pas. C’est précisément pour ça qu’une base figée ne règle rien : ce qui se répète, ce n’est pas la configuration, c’est le travail de configuration.
Régler une fois, réimporter ensuite
Sortir les réglages du code pour les mettre dans une interface
C’est ce constat qui a donné l’Extension WordPress « Toolkit oaka ». L’idée n’est pas de décider à votre place, mais de sortir ces réglages du code pour les mettre dans une interface, où ils se cochent au lieu de se réécrire.
Vous choisissez les menus et sous-menus à retirer, en les prenant dans la liste de ceux réellement présents sur ce site. Pour un bouton ou une colonne sans option dédiée, un champ accepte des sélecteurs CSS, un par ligne. Vous retirez par type de contenu les blocs d’édition inutiles, vous masquez ou détachez les catégories et étiquettes, vous coupez les commentaires ou les Articles quand le site n’en a pas l’usage. Vous décidez enfin quels widgets du tableau de bord disparaissent, et si les notifications de mise à jour restent visibles.
Tout cela s’applique à l’ensemble des comptes sauf les administrateurs : vous continuez de voir le site complet, la personne à qui vous le livrez voit ce que vous avez décidé — à condition de ne pas lui laisser un compte administrateur, ce qui règle au passage l’histoire de la mise à jour cliquée un lundi matin.
Exporter la configuration, la réimporter au site suivant
Et sur le site suivant, vous ne repartez pas de zéro. La configuration s’exporte et se réimporte, puis s’ajuste aux particularités du nouveau client. C’est là que l’heure disparaît : elle devient dix minutes d’arbitrage, au lieu d’une heure de recopie.
Chez nous, c’était une heure par site
Nous ne citerons pas de client sur ce sujet, parce que le cas, c’est nous.
Ce que ça a changé sur nos propres mises en ligne
À l’agence, nous sortons un à deux sites par mois. Pendant longtemps, chaque mise en ligne passait par la même manœuvre : rouvrir un ancien projet, y récupérer les blocs de code, les recoller dans le thème enfant du nouveau. Environ une heure à chaque fois, toujours au mauvais moment. Avec, en prime, ce que produit une équipe où chacun garde sa propre version des mêmes réglages : deux sites livrés à quelques semaines d’intervalle, configurés différemment, sans que personne ait décidé quoi que ce soit.
Nous avons construit cet outil pour nous, avant d’en faire une extension. C’est aussi pour ça qu’il ne contient rien de spectaculaire : uniquement ce qui revenait à chaque livraison.
La formule Boîte à outils couvre l’ensemble de ces réglages : masquage des menus et des éléments d’écran, retrait des blocs d’édition par type de contenu, coupure des commentaires et des Articles, nettoyage du tableau de bord, et export-import de la configuration d’un site à l’autre.
La formule Boîte à outils de l’Extension WordPress « Toolkit oaka » couvre cet export des réglages d’un site vers le suivant, pour ne plus les reprendre un par un.