Un projets de refonte est souvent périlleux, notamment quand un grande nombre de contenus est à reprendre. Pendant cette conférence nous traiterons de cette problématique en mettant en exergue les bonnes pratiques et les points de vigilance pour réussir sa migration. Cette conférence s'adresse autant à un prestataire souhaitant éviter les multiples embuches qu'à un chef de projet client souhaitant mettre toutes les chances de réussite de son coté. Nous baserons nos conseils sur un cas client : une migration pour le ministère de l'Agriculture.

1. Reprendre un projet avec Drupal
quand on a des centaines de milliers
de contenus

2. Au programme
> La reprise des contenus c’est casse g***
> L’importance de définir la reprise dès le cahier des
charges
> Les méthodes possibles avec Drupal
> Retour sur le projet du Ministère de l’Agriculture

3. La reprise des
contenus c’est
casse g****

4. Les erreurs les plus courantes
• « Oh, on verra ça à la fin, après les développements »
• « on va embaucher des stagiaire payées au lance-pierre »
• « Ca prendra pas beaucoup de temps »
• « on reprend tout à l’identique »
• « on réécrit tout de toute façon »
• A la fin du projet : « Mais, ???!!! On croyait que vous vous en chargiez ??!! »
• « On va faire tourner une moulinette, et puis ça ira tout seul ! »

5. Et puis, avec Drupal,
c’est facile, non ?

7. Les points de vigilance
Le client ou l'équipe métier n'anticipe souvent pas suffisamment
ou ne sait pas ce que ça implique :

8. Ca prend du temps et de l’argent

9. Il faut dire et répéter
que ce n'est que eux
qui pourront piloter
ce chantier, car c'est
eux qui connaissent
leur contenu

10. Il faut faire un projet
à part, le paralléliser
avec la conduite
technique du projet
et identifier les
adhérences.

11. Il faut sensibiliser aux
différences de l’avant
– après : la méthode
de gestion des
contenus ne sera
évidemment pas la
même et cela aura un
impact sur la façon
dont on va reprendre
les contenus !

12. Les grandes lois de la reprise de
contenu
1. Il n’y a pas de méthode universelle.
2. Il faut construire à chaque fois une méthode, et savoir
qu’on devra revenir dessus.
3. Il faut procéder par itérations successives.

13. La reprise des contenus, ça se
définit dès le cahier des
charges

14. Décider d’une reprise manuelle ou
automatique ?

15. Faire une matrice de reprise des
contenus
Titre de la page URL de la page Etat du contenu
Niveau de
retraitement souhaité
Positionnement cible dans
futur site
Type de contenu
cible
Titre 1 www.test.fr trop détaillé illustrations à fournir thématique article
Titre 2 www.test.fr inadapté pour la cible A simplifier actualité
Titre 3 www.test.fr Difficile à comprendre A réécrire agenda
Titre 4 www.test.fr inexistant illustrations à fournir FAQ
Acceptable …

16. Faire une matrice à partir :
• De Google
• Du back-office existant
• Du parcours du site existant (ou plan du site)

17. Reclassifier les contenus en « types de
contenus » made in Drupal
• Actu ?
• Evènement ?
• Page éditoriale ?
• Glossaire ?
• Rubrique ?
• Fiche métier
• …
Cette « re-classification » est plus ou moins facile selon les sites pré-existants.

18. 1. Evaluer la capacité de reprise
automatique – une mission à part
• Reprendre depuis un ancien Drupal ?
• Exploiter les modules de la communauté Drupal
• Connexion possible à la base de données ?
• Quelle est la structure de la base de données ?
• Quelle est la qualité des données stockées en base de données ?
• Un / des exports XML sont-ils possibles ?
• Un crawler est-il envisageable ?

19. Les « n »
méthodes
automatiques
de reprise des
contenus

20. Reprendre depuis un ancien Drupal ?
Il existe des logiques de migration D5 – D6 – D7 qui embarquent les
contenus.
Mais cela dépend très très fortement de la qualité du développement
original.
Très souvent, c’est aussi compliqué que dans un projet d’un autre CMS.

21. Le test des modules
Cela suppose d’avoir un CMS connu :
• Avec Typo3
• Avec Spip
• Avec Joomla
• Avec Wordpress
• …
Et que cela prenne en compte toutes les spécificités du projet antérieur.

22. La reprise directe en base de données
Identifier toutes
les tables
contenant des
contenus à
reprendre
Identifier toutes
les entrées des
tables et les
faire
correspondre
avec le
structure de
contenu Drupal
Identifier tous
les besoins de
retraitement du
WYSIWYG
Lancer un script
de reprise par
type de
contenu
Utiliser un ETL ?

23. Les modules de migration avec Drupal
• Avec Migrate
• Avec Feeds & Feeds Tamper

24. Un crawler ? Oui, mais…
• Il faut être certain de pouvoir parcourir toutes les pages
• Disposer d’un sitemap
• Ne pas avoir de pages orphelines
• Le balisage HTML doit être cohérent
• Il faut associer ce crawler au traitement de la matrice des contenus

25. Dans tous les cas, il faut retraiter le
HTML
• Identifier les balises à retraiter
: styles, tableaux, balises
propres au CMS initial
• Identifier les images et les
fichiers pour les importer
• Recréer les liens relatifs entre
les pages

26. Quelques trucs et astuces
• Utiliser un module / développement adhoc, permettant de basculer
d’une structure de contenu à une autre
• Permettre de « flagguer » des contenus qui ne doivent pas être
réimportés / écrasés lors des itérations

27. Importer, tester, recommencer,
importer, tester, modifier les scripts,
recommencer, importer, recommencer,
Importer, tester, recommencer,
importer, tester, modifier le script,
recommencer, importer, recommencer,
Importer, tester, recommencer,
importer, tester, modifier le script,
recommencer, importer, recommencer,

28. Et finir par la reprise manuelle :
- Exceptions qui ne peuvent être traitées
automatiquement
- Réécriture nécessaire

29. Les facteurs déterminants d’une
reprise manuelle
• Le temps de réalisation
de la moulinette
automatique est
supérieur au temps
évalué de reprise
manuelle
• Le contenu généré en
HTML n’est pas propre
du tout
• Indicateur 1 : multiplier par 10 le temps
évalué pour la reprise automatique ;-)
• Indicateur 2 : réintégrer une page de
contenu de 800 caractères, avec deux
images et trois fichiers à télécharger, ça
prend 30 minutes !!

30. Retour sur le projet du
Ministère de l’Agriculture

31. Contexte
• Un site sous Spip
• Un site avec plusieurs couches de développement successives
• Un volume de contenus non identifiés
• De multiples collaborateurs et rédacteurs aux pratiques hétérogènes

32. On a tenté de normer le périmètre de
reprise…
• Redéfinition d’une charte éditoriale complète
• Tableur de 20 000 lignes de repositionnement des contenus
• Identification des types de contenu cible
• …
 ~20 jours / homme d’accompagnement

33. Des scripts très compliqués ont été mis
en place pour repositionner les
contenus
• Exploitation du tableur Excel pour les scripts Migrate
• Positionnement dans l’arborescence
• Regroupement de contenus
• Association automatique de vocabulaires
• …
• Retraitement des contenus HTML pour supprimer les styles et balises
de SPIP
~30 jours / homme pour la V1

34. Mais au final, on avait oublié
plein de contenus !

35. On a donc fait machine arrière
• V2 avec tous les contenus sans exclure des éléments
• Retraitement de scripts pour simplifier les retraitements de
positionnement
• Rajout d’une fonction de transfert d’une structure à une autre
• Rajout d’un flag sur chaque contenu pour autoriser / refuser son
import
Puis une V3, V4, …
Et, reprise manuelle !
~20 jours / homme pour la
finalisation

36. Merci
Questions?
Marine Soroko – Core-Techs