Geneva Drupal Meetup September 2011

Désolé de la réponse tardive, mais j'avais déjà écrit quelque chose vendredi ou jeudi avant que Drupal.org ne plante et qu'on message ne soit pas inséré. Du coup je réécris et avec plus au moins les mêmes idées, mais j'ai sûrement oublié des détails.

Je ne dirais pas qu'il faut attendre jusqu'à Drupal 9 pour proposer un nouveau site. Il faut savoir que Drupal ne propose pas de version avec LTS (Long Term Support). Concrètement ça veut dire que quand Drupal 8 sera disponible, Drupal 6 ne sera oublié et même plus du tout maintenu. De plus, si on attend Drupal 9 pour refaire/migrer un site, il faudra de toute façon passer par Drupal 7 puis 8 et après on peut migrer vers Drupal 9.

Quant à la migration, c'est effectivement un des problèmes de Drupal et ils tentent de résoudre ça au mieux sur la prochaine version. Et l'une des initiatives est donc de séparer plus clairement les modules, etc. Mais les dernières versions, et plus précisément la version 7 de Drupal a apporté un gros module dans le core, (qui permet à Drupal de concurrencer Wordpress) CCK. Forcément, standardiser tout cela n'a pas facilité la migration.

Qu'est-ce qui fait qu'une migration coute cher sur Drupal ?
C'est simplement leur philosophie, après on aime ou n’aime pas. De mon point de vue, je trouve relativement pratique. Bref, la philosophie de Drupal veut que le schéma de base de données reste identique d'une version majeur à une autre (nouvelles tables, clefs primaires changement, etc.), mais l'idée c'est qu'on retrouve les mêmes tables à chaque nouvelle version. Cela a une grande influence dans le développement, puisque si on ne peut pas organiser la base de donnée comme on veut, on doit organiser le contenu à la sortie. Et de ce fait, on préfère ne pas maintenir une pérennité entre avec les différentes versions.

Quelle stratégie à adopter ?
Voici comment je procède avec les clients et ainsi évité une migration. Premièrement je n'attends pas que le client vienne vers moi pour demander une mise à jour du site, etc. Je lui propose directement un rendez-vous pour faire un bilan du site !

Cela possède plusieurs avantages, dont le plus important à mon sens la fidélisation du client. Le fait de l'appeler et de lui rappeler qu'il a un site et qu'il est intéressant de voir s'il atteint toujours son objectif surprend le client et trouve l'idée très bien. Le second avantage c'est également le meilleur moyen pour introduire au client la nécessité de "refaire" son site, soit pour une des raisons qu'il a évoqué (design trop vieux, fonctionnalités plus adaptées, etc.) ou alors on lui explique le cas (site sous un Drupal trop vieux) et donc qu'il est mieux de le mettre à jour.

Disons que dans 80% des cas les clients acceptent volontiers de refaire le site, surtout si on saupoudre cela avec une touche de "dans les circonstances économiques actuelles, il est bien de montrer à vos clients et concurrents que votre société est prospère par un renouvellement de votre site Internet", il en va de même pour le référencement, etc. Bref, il y a pas mal d'arguments (si on est vendeur) pour amener le client à refaire son site (bien entendu en Win-Win hein :)).

Dans le 20% restant (soit les clients qui ne veulent pas investir), vous pouvez faire signer une décharge au client, comme quoi dès la sortie du nouveau Drupal, vous n'êtes pas responsable des éventuels problèmes/trous de sécurités/dysfonctionnement du site (souvent le client devient un 80% :) après ça. En gros son contrat de maintenance échu.

Maintenant parmi les 20% de clients, il y a qui ne veut pas refaire le site, mais souhaite une migration. Dans ce cas, il faut re-catégoriser les fonctionnalités par importance. "Qu'est-ce qui est impérativement nécessaire au fonctionnement du site."

Migrer
Cette catégorisation va permettre de créer une liste des modules critiques. Avec cette liste, il va falloir regarder s'il y a une version Drupal 7/8 ou un équivalent (avec une importation des données de l'ancien module). Si sur cette liste vous avez une lumière rouge (un module non disponible, quelque soit le moyen) il faut repousser la migration. (Je repousse en général de 2 à 4 semaines).

Voilà, votre liste est OK, vous pouvez donc commencer la migration, comme indiqué dans le fichier UPGRADE.txt de Drupal et forcément configurer et convertir thème et custom modules en Drupal 7 ou 8.

Les modules qui ne sont pas sur cette liste critique peuvent être convertis (selon le besoin du client) et évidemment on partage avec la communauté :)

En conclusion
La meilleure stratégie reste tout de même la refonte, et je pense que ce n’est pas réellement nécessaire de faire une migration puisque par expérience une migration est presque aussi chère qu'une refonte du site.