Maintenance et soutien WordPress
Le lancement est le début de la plus longue phase. Nous restons l’équipe de développement des plateformes que nous construisons : mises à jour, correctifs de sécurité, surveillance, et le nouveau travail qui continue d’arriver. C’est pris en charge par les personnes qui ont écrit l’architecture plutôt que par une file d’assistance qui la découvre.
- Les développeurs qui l’ont construit sont ceux qui le maintiennent
- Mises à jour du noyau, des extensions et des dépendances appliquées d’abord en préproduction
- Surveillance, sauvegardes et une procédure de reprise testée
- Du développement continu, pas seulement garder les lumières allumées
La maintenance reportée est la façon dont les plateformes meurent
Presque tous les sites qu’on nous demande de reconstruire ont été maintenus jusqu’à ce qu’ils ne le soient plus. Une mise à jour a cassé quelque chose, alors la suivante a été reportée. Un auteur d’extension a cessé de publier, alors cette extension a été figée. Un an plus tard, le noyau ne peut plus être mis à jour sans casser l’extension figée, et le site est gelé, ce qui n’est pas une stratégie de maintenance. C’est une posture de sécurité non gérée avec une date dessus.
La sortie est peu glorieuse : appliquer les mises à jour selon un calendrier, d’abord en préproduction, avec quelqu’un de responsable du résultat. C’est l’essentiel de ce qu’achète réellement une entente de maintenance, et cela vaut considérablement plus que le rapport mensuel qui l’accompagne d’habitude.
Ce que couvre le soutien continu
Mises à jour du noyau, des extensions et des dépendances
Appliquées en préproduction, vérifiées, puis mises en production, et non appliquées à l’aveugle en production. Quand une mise à jour ne peut être appliquée sans risque, la raison est documentée et un plan existe pour la résoudre plutôt que la reporter encore.
Correctifs de sécurité et durcissement
Correctifs critiques appliqués rapidement, accès et identifiants revus, et surface administrative réduite à ce qui sert réellement. La sécurité dans WordPress est largement une question de gouvernance, alors nous documentons qui a quoi et pourquoi.
Surveillance et disponibilité
Surveillance de la disponibilité et des erreurs, pour que les problèmes soient trouvés par nous plutôt que signalés par un utilisateur, y compris les tâches planifiées et les intégrations qui échouent en silence.
Sauvegardes et reprise
Des sauvegardes vérifiées et une procédure de reprise déjà répétée. Une sauvegarde non testée est une croyance, pas une protection.
Performance dans la durée
Les sites ralentissent à mesure que le contenu grossit. Requêtes, mise en cache et Core Web Vitals revus périodiquement plutôt qu’au seul lancement.
Développement continu
Nouvelles sections, nouveaux blocs, nouvelles intégrations, changements au modèle de contenu. La plupart de nos clients de longue date dépensent davantage ici qu’en maintenance, ce qui est le signe d’une plateforme utilisée plutôt que simplement gardée en vie.
Soutien à l'équipe de contenu
Les personnes qui utilisent le CMS ont aussi besoin de réponses. Les questions sur les blocs, les mises en page et les flux de publication arrivent à la même équipe, pour qu’un problème éditorial n’attende pas derrière une mise en production.
Vous cherchez une équipe de développement qui reste?
Dites-nous ce qu’est la plateforme, à quoi elle s’intègre, et ce qui a été reporté. Nous vous dirons ce qu’il faut pour la remettre à jour et ce qu’il faut pour l’y garder.
À quoi ressemble réellement l’entente
Une maintenance vendue comme un rapport mensuel est surtout un rapport mensuel. Voici les choses qui doivent se produire pour que l’entente vaille son prix, et ce sont celles sur lesquelles nous nous engageons par écrit.
Une évaluation d'abord
Avant toute entente, la plateforme est examinée : versions, dépendances, ce qui ne peut pas être mis à jour actuellement et pourquoi, la surface d’intégration, et la situation des sauvegardes et des accès. Les deux parties savent alors ce à quoi elles s’engagent.
Un cycle de mises à jour planifié
Les mises à jour sont appliquées à une cadence définie, en préproduction, vérifiées, puis publiées. Les correctifs de sécurité critiques passent devant. Rien n’est appliqué à l’aveugle en production parce que c’est apparu dans le tableau de bord.
Un processus de mise en production, pas une suite de retouches
Les changements passent par la gestion de versions et la préproduction, avec une note de ce qui a été publié et quand. La production n’est jamais l’endroit où l’on essaie quelque chose.
Un carnet permanent
Demandes, éléments reportés et problèmes connus vivent dans une seule liste visible, avec la raison de la position de chacun. La maintenance reportée est une décision que quelqu’un a prise, pas une chose qui est arrivée toute seule.
Des rapports sur lesquels agir
Ce qui a été mis à jour, ce qui a cassé, ce qui a été corrigé, ce qui reste en suspens, et ce que nous recommandons ensuite. Court, et écrit pour la personne qui doit justifier le budget.
Un développeur nommé
La personne qui répond connaît l’architecture parce qu’elle l’a écrite. Il n’y a pas de première ligne qui découvre le code pendant qu’un formulaire est hors service.
Quatre ans sur la même plateforme
La preuve la plus claire n’est pas un contrat de maintenance, c’est une relation de développement qui a duré. WPlook Studio a assumé la responsabilité de l’architecture WordPress et systèmes senior pour le groupe M3 Tech pendant un mandat de quatre ans, de 2021 à 2025, couvrant Multi-Prêts, Mortgage Alliance, Invis, Mortgage Intelligence et Intelligence Hypothécaire.
Nous avons repris le code de l’agence précédente et sommes restés avec lui : du développement continu en parallèle des mises à jour, l’infrastructure consolidée de douze serveurs à deux, et le temps de chargement passé de seize secondes à moins d’une. Voilà à quoi ressemble la longue phase quand elle fonctionne. L’essentiel des dépenses dans une relation comme celle-là va au nouveau travail plutôt qu’à garder les lumières allumées, ce qui est le signe d’une plateforme utilisée plutôt que simplement maintenue en vie.
Ce que c’est, et ce que ce n’est pas
C’est une relation de développement, pas un produit d’hébergement. Nous travaillons sur l’infrastructure que le client possède ou que son service des TI a choisie, et nous collaborons volontiers avec un hébergeur géré. Quand une organisation cherche de l’hébergement WordPress géré autonome plutôt qu’un partenaire de développement, c’est un service différent et nous vous en indiquerons un plutôt que de l’inclure.
Nous ne reprenons pas non plus le soutien d’une plateforme que nous n’avons pas évaluée. Hériter d’un code inconnu et être responsable de sa disponibilité dès le premier jour ne sert personne. Une évaluation préalable dit aux deux parties ce à quoi elles s’engagent, et conclut parfois que la recommandation honnête est de reconstruire plutôt que de maintenir.
Questions fréquentes
-
Soutenez-vous des sites que vous n'avez pas construits?
Oui, après une évaluation. Assumer la disponibilité d’un code que personne n’a lu est la façon dont les deux parties finissent mécontentes. L’évaluation est courte, elle vous dit dans quel état se trouve réellement la plateforme, et elle conclut parfois que reconstruire coûte moins cher que maintenir. Nous préférons le dire avant un contrat qu’après.
-
L'hébergement est-il inclus?
Non. C’est une relation de développement, pas un produit d’hébergement. Nous travaillons sur une infrastructure que vous possédez ou que votre service des TI a choisie, et nous collaborons régulièrement avec des hébergeurs gérés. Si ce qu’il vous faut est de l’hébergement WordPress géré autonome, c’est un achat différent et nous vous en indiquerons un plutôt que de l’inclure.
-
Que se passe-t-il si une mise à jour casse quelque chose?
L’essentiel est attrapé en préproduction, et c’est pourquoi les mises à jour y passent d’abord. Quand quelque chose atteint tout de même la production et casse, le correctif est le nôtre et n’est pas facturé comme du nouveau travail. Quand une mise à jour ne peut vraiment pas être appliquée sans risque, la raison est documentée et il existe un plan pour la résoudre plutôt qu’un nouveau report.
-
Pouvez-vous travailler avec notre équipe interne?
Oui, et c’est une entente courante. Le partage habituel est que nous tenons l’architecture, le processus de mise en production et les parties coûteuses à rater, pendant qu’une équipe interne s’occupe du contenu et des changements courants. Une gestion de versions partagée et un carnet partagé comptent davantage que l’endroit où chacun est assis.
-
Et si nous n'avons besoin d'aide qu'à l'occasion?
Cela fonctionne, mais soyez clair sur ce que cela achète. Le soutien ponctuel convient aux changements et aux nouvelles fonctions. Ce n’est pas un substitut à un cycle de mises à jour planifié, et une plateforme sans cycle dérive vers l’état gelé décrit en haut de cette page, généralement en deux ans environ.
-
Quel est votre délai de réponse?
Cela dépend de ce qui est convenu, et nous préférons convenir de quelque chose que nous pouvons tenir plutôt que de publier un chiffre. Les enjeux de sécurité et tout ce qui touche la disponibilité sont traités immédiatement ; les demandes ordinaires suivent le carnet. Ce qu’il faut demander à tout fournisseur, c’est qui répond précisément, et si cette personne a lu le code.