Est-ce que les montées de version de WordPress sont trop fréquentes ?
Question posée sur le forum, et qui a soulevé une discussion intéressante.

A ma gauche, l’équipe de WordPress, Lumière de Lune, et d’autres : les mises à jour de WordPress sont pour la plupart indolores, les changements de structure ne sont pas « très fréquents » (en général une fois tous les 12 à 18 mois), les autres mises à jour sont là pour ajouter des fonctionnalités supplémentaires ou pallier des failles de sécurité.

A ma droite, des utilisateurs, amateurs ou professionnels, et notamment quelqu’un qui travaille dans une agence web : le temps nécessaire pour vérifier la compatibilité des thèmes et des plugins est trop lourd, il n’est pas possible de mettre un site inaccessible pendant plus de six heures parce qu’une montée de version se passe mal.

A ma gauche, (enfin moi) : quand on programme correctement (sous entendu les développeurs de plugin et de thème), WordPress assure la compatibilité ascendante, les plugins sont en général (sauf exception, les joies du libre) rapidement mis à jour, et le contrat de maintenance que nous proposons aux clients est justement là pour leur éviter ce genre de problème.

A ma droite la webagency : oui mais bon, pendant que quelqu’un travaille la dessus il ne fait pas autre chose, et puis je croyais que cela ne se faisait plus, ce genre de contrats ? Moi je propose à mes clients de devenir « web-indépendants », en évitant surtout de leur parler technique, dont ils se foutent.

Je viens d’un monde autre que celui des agences web et des petits projets WordPress, celui des gros projets et des grosses applications, qui ne pouvaient même pas se permettre d’être down une demi-heure (juste pour donner une idée à ceux qui connaissent, un SAP entier, avec en plus 40% de fonctionnalités spécifiques, et avec plus de 5.000 utilisateurs), celui où on étudiait une montée de version pendant un mois avant de se décider à la faire, celui où il y a des systèmes de développements, des systèmes de bac à sable (rien à voir avec la sandbox de Google), des systèmes de test, des systèmes d’intégration, un système de prod et des back-up, celui où on établit un versionning précis, et où on gère son parc d’installations pour qu’il soit cohérent.

Alors avec cette expérience, voilà ce que nous proposons à nos clients, et pourquoi la fréquence des mises à jour de WordPress ne nous pose pas de problèmes.

Des sites faits sur la meilleure solution qui puisse leur convenir

Des outils simples

Soit WordPress, pour des sites évolutifs, soit pour les sites statiques, un framework maison sans base de données.
WordPress a été choisi comme étant une des meilleures solutions, à la fois pour ses fonctionnalités et sa diffusion. En clair, c’est un bon soft, et le jour où ils veulent nous quitter, ils peuvent toujours trouver quelqu’un pour gérer à leur place. Et ils ont une base de données claire, et facile à utiliser le jour où ils voudraient changer de solution.
Certains disent que chez WordPress « code is ugly« , c’est possible, mais « data structure is beautiful ».
Le framework maison permet de générer des sites entièrement statiques, ils nous quittent, ils ont la version HTML de leur site, et rien n’est perdu.

Plugin et thèmes : le conseil commence

Les thèmes que j’utilise pour les sites sous WordPress sont des thèmes assez standards, largement utilisés, et personnalisés maison. Je les ai sélectionnés selon plusieurs critères :

• Graphisme, ergonomie de la grille de lecture
• Qualité du développement (en évitant autant que possible le codage en dur dans le thème, par exemple, j’ai entièrement réécrit les bases de Mimbo)
• Propreté du code, absence de code caché, de liens forcés…
• Souplesse du graphisme, pour arriver à personnaliser un tant soit peu sans qu’on ait l’impression de toujours avoir le même site
• Appréciation (très pifométrique) de la permanence du développeur, et revue du code : facile à comprendre, facile à modifier, si besoin est

De même pour les plugins, un plugin largement utilisé, mis régulièrement à jour depuis longtemps, un forum ou un blog avec des réactions rapides.
De toute façon, je suis assez contre la plugite aïgue. Plus ils sont nombreux, plus les interactions peuvent être complexes, et plus la page peut être longue à charger. J’ai assez tendance à insérer directement dans le thème des fonctionnalités de base, à développer mon propre formulaire de contact, ma propre blogroll plutôt que d’utiliser des plugins.

Un service en briquettes

La plupart de nos clients sont des TPME, c’est à dire des gens qui n’ont pas facilement la possibilité de dégager un poste pour sensibiliser quelqu’un à l’informatique. Si cette personne existe déjà, tant mieux, sinon on ne va pas l’embaucher pour un site.

Hébergement

Nous ne faisons pas d’hébergement nous mêmes. Mais étant donné la situation au Maroc, et la « facilité » d’effectuer des paiements à l’étranger, nous pouvons leur sous-traiter un hébergement en Europe, soit un mutualisé pour eux mêmes, soit une part dans un gros mutualisé. Ou leur conseiller un prestataire.
Maintenant, il m’est déjà arrivé d’avoir des problèmes spécifiquement liés à la configuration de l’hébergeur (Lycos et Host Europe), et maintenant j’en tient compte dans le contrat de maintenant.

Maintenance

Mon rêve est que mes clients deviennent web suffisants, mais plusieurs années de pratique m’ont prouvé que c’était rarement le cas.
De plus, je vends une expertise, et l’expertise acquise sur la création, la maintenance et le référencement de plusieurs dizaines de sites est sans commune mesure avec celle qu’un client peut obtenir en gérant son propre site.

Si on en revient au sujet des migrations WordPress, tester la montée de version, avec un parc d’une trentaine de plugins demande effectivement un certain temps, et a donc un cout. Simplement, répartir ce cout sur un site ou sur un vingtaine… l’opération est vite faite.

Notre maintenance peut porter sur plusieurs choses :

• le maintien à niveau pour le référencement, avec la modification de la structure du code, pour l’optimisation, si c’est nécessaire
• les montées de versions du CMS
• les « petites modifications » sur le site (numéro de téléphone, tarifs, etc)

Dans le contrat, une charge de travail globale est incluse dans le contrat, et les travaux qui représentent plus font l’objet d’une proposition à part.
Le client peut aussi décider de ne pas prendre cette maintenance, et de venir uniquement en cas de besoin. Dans ce cas, il est évident que c’est nettement plus cher puisque nous appliquons notre tarif horaire. (Et que généralement, nous devons remettre les mains dans un code qui a été modifié).
Enfin, il y a une formule intermédiaire : le support – formation, où nous nous entendons sur une durée de maintenance, avec un transfert de compétence. Ensuite, nous agissons comme une hotline de conseil, mais nous ne faisons plus nous mêmes.

C’est la formule qui me semble la meilleure, mais nos clients préfèrent la première.

Gérer les versions et les mises à jour

J’ai du mal à comprendre comment un site peut être inaccessible pendant six heures suite à une mise à jour – sauf si c’est le client qui a fait lui même et qui appelle ensuite au secours.
Shit happens, donc rien n’est impossible, même pour WordPress, mais dans tous les cas faire une mise à jour sans un backup complet du site (base de données et fichiers) est risqué. En revanche, si ça ne marche pas, on recharge les sauvegardes, et le site refonctionne, et en gros, ça ne doit pas durer plus d’une demi-heure.
Pourquoi ?
La première étape est de tester en local, si possible en avance, avec les Releases Candidates, mais en tout cas en local.
Et sur un « blog test » qui comprends l’ensemble des plugins, et sur lequel on va activer à tour de rôles les différents thèmes en production (d’où l’intérêt d’avoir une base commune; nous travaillons sur trois architectures, Mimbo, Sandbox, et « Home Made »). Normalement, on va voir les principaux problèmes, et notamment tout ce qui touche à la compatibilité des plugins.
La deuxième étape est de tester chez soi. J’ai trois blogs productifs, dont celui de Lumière de Lune, qui passent toujours en premier. J’ai fait ma montée de version en premier.
C’est là qu’on peut voir les impondérables, et notamment des problèmes qui peuvent venir des configurations serveur.
Enfin, on passe en production chez les clients.

Et on ne passe pas les clients en production tout de suite. Il n’y a aucune urgence à faire une montée de version.
Sur la 2.7, la modification de l’interface admin va surprendre certains d’entre eux, il va donc falloir faire une petite documentation (c’était là, c’est ici). Par ailleurs, la mise en place de certaines fonctions, comme l’indentation des commentaires, demande des modifications de thèmes. Enfin certains plugins ne sont pas compatibles.
Normalement, dans les dix jours, une 2.7.1, corrective des petits bugs, et les mises à jour des principaux plugins, seront sorties. C’est à ce moment là que nous passerons nos clients sur la nouvelle version. Enfin on attendra la nouvelle année… quand je bossais sur SAP, j’ai suffisamment souffert des dossiers « an 2000″, maintenant je refuse de me charger à la fin de l’année. Je préfère aller sabler le champagne sous les dunes.

Les montées de version difficiles et les autres

Les montées de version ne sont pas toutes identiques. Certaines touchent au coeur des données, par exemple la modification de la taxonomie, qui a changé toute la gestion des catégories, certaines touchent plutôt aux fonctionnalités (comme la 2.7), enfin certaines sont des mises à jour de sécurité (comme la 2.6.5). Seules ces dernières sont indispensables.
En ce qui concerne les autres, on peut toujours décidé de ne pas progresser au même rythme. De nouveaux plugins seront peut être innaccessibles, mais c »est tout.
Je trouve qu’une des forces de WordPress, c’est sa compatibilité. Les fonctions dépréciées sont supportées pendant assez longtemps, et les migrations « à changement de structure » se passent bien. Quand je fais la comparaison avec Dotclear ou Joomla, je trouve que la stratégie de développement est bien gérée !