Développement WordPress d’entreprise

Le mot « entreprise » est employé assez librement dans le monde WordPress pour ne plus rien vouloir dire. Il vaut la peine de remplacer l’adjectif par les conditions qu’il désigne, parce que ce sont ces conditions qui changent la façon dont un projet doit être construit. Il est tout à fait possible d’avoir un gros budget et aucune d’entre elles, ou un budget modeste et les six.

Les plateformes complexes échouent dans le plan, pas dans la syntaxe. Les décisions coûteuses à renverser (comment le contenu est modélisé, où chaque donnée fait autorité, comment le site se divise en sites, comment les rédacteurs vont réellement travailler) se prennent toutes dans les premières semaines, et la plupart se prennent implicitement si personne ne les prend délibérément.

Nous commençons par une architecture écrite : le modèle de contenu et ses relations, la carte des intégrations avec le sens et la fréquence de chaque flux de données, le plan d’environnements et de mise en production, les rôles éditoriaux, et les parties du système délibérément hors portée. Elle est courte, elle est lisible par des gens qui ne sont pas développeurs, et c’est ce qu’un second développeur lira dans deux ans pour comprendre pourquoi la plateforme a cette forme.

C’est aussi ce qui rend possible une réponse d’appel d’offres à portée fixe. Une estimation par phases n’a de sens que si les phases correspondent à des décisions que quelqu’un a déjà prises.

La plupart des problèmes WordPress d’entreprise se présentent comme des plaintes éditoriales : le site est long à mettre à jour, personne ne trouve rien, deux équipes ont publié des versions contradictoires de la même chose. Presque tous sont des problèmes de modèle de contenu en dessous.

Dans les plateformes que nous construisons, WordPress est généralement la couche de présentation et d’édition par-dessus des données qui appartiennent ailleurs. C’est une position de conception, pas une limite : l’intégration est ce qui garde le site exact sans demander à personne de tenir deux fois le même enregistrement.

Dans le travail livré, cela a voulu dire des données de courtiers, de bureaux et de franchises issues du CRM du client, des services de calendrier et de prise de rendez-vous, des services de cartographie et de géolocalisation, du traitement de paiement, des flux météo et de données externes, de la gestion du consentement, et de l’analytique et de la gestion des balises, le tout construit sur des API documentées avec mise en cache, journalisation et comportement défini quand le système amont est indisponible.

Cette dernière partie compte plus que l’intégration elle-même. Une intégration qui fonctionne est ordinaire ; une intégration qui se dégrade de façon prévisible quand l’autre système est hors service, limité en débit ou renvoie quelque chose d’inattendu fait la différence entre une plateforme et une démonstration.

La livraison en contexte d’entreprise consiste surtout à rendre les changements ennuyeux. Les plateformes que nous exploitons sont déployées depuis la gestion de versions à travers un pipeline de construction vers des environnements échelonnés (local, préproduction, production), la même construction produisant les mêmes artefacts chaque fois, avec un chemin de retour documenté si une mise en production tourne mal.

Nous avons livré cela sur infrastructure infonuagique, y compris des machines virtuelles Azure avec pipelines CI/CD, et sur de l’hébergement géré conventionnel. L’infrastructure est choisie selon les contraintes des TI du client plutôt que selon nos préférences. Quand une organisation a besoin d’hébergement géré autonome plutôt que d’un partenaire de développement, nous le disons et l’orientons ailleurs plutôt que de le lui vendre.

À grande échelle, les conseils WordPress ordinaires cessent de suffire. Le travail de performance devient un travail de requêtes et de modèle de contenu : une requête de métadonnées non indexée sur cinquante mille enregistrements ne sera pas sauvée par une extension de cache, et une page qui assemble douze appels externes par requête a besoin qu’on corrige sa stratégie de données plutôt que de réchauffer son cache. Nous travaillons les Core Web Vitals à partir de la couche des gabarits et des requêtes, la mise en cache venant en dernier plutôt qu’en premier.

La sécurité à ce niveau est surtout une question de gouvernance. Qui possède un compte administrateur et pourquoi, comment les identifiants sont entreposés, quelles extensions sont permises et qui approuve une nouvelle, à quelle vitesse un correctif critique est appliqué, et quelle est réellement la procédure de reprise. Nous documentons cela dans la passation parce que ce sont les questions qu’un examinateur des TI pose en approvisionnement, et parce qu’une plateforme sans responsable nommé sur ces points est à un départ d’employé de ne plus être maintenue.

Quand une organisation exploite plusieurs sites apparentés, qu’il s’agisse de divisions, de marques, de régions, de campagnes ou d’une présence française et anglaise, un réseau multisite leur permet de partager un code, un système de design et un processus de mise en production tout en gardant contenus et permissions séparés. C’est souvent la bonne réponse, mais pas toujours, et la décision appartient à la phase d’architecture plutôt qu’à la construction.

Une plateforme d’entreprise n’est pas terminée au lancement ; elle entre dans sa plus longue phase. Nous restons l’équipe de développement, couvrant les mises à jour du noyau et des extensions, les correctifs de sécurité, la surveillance, les changements d’intégration quand une version d’API amont évolue, le travail de performance à mesure que le contenu grossit, et le nouveau développement à mesure que les exigences changent. C’est pris en charge par les personnes qui ont construit la chose, en travaillant contre l’architecture qu’elles ont écrite.

Quand une organisation préfère ramener le travail à l’interne ou le confier à un autre fournisseur, la passation est la documentation, le dépôt et le dossier d’architecture. Une plateforme que vous ne pouvez pas transmettre est une plateforme que vous ne possédez pas.