Si on parlait des migrations ?

Je sais ce que vous allez me dire: ca va les migrations on sait … faut faire un plan de redirection , en profiter pour nettoyer … etc etc oui, mais pas seulement  ! Ce n’est pas réellement de cela dont je veux vous parler. Ce sont ces projets de migration qui vont dans le mur, qui coutent 3 ou 4 fois plus d’argent que prévu au départ et qui mettent en péril une société.

Au cas où une liste non exhaustive des points à ne pas oublier dans une migration

Rien de nouveau, beaucoup de bon sens. Si ça vous intéresse, je pourrai faire un article pour détailler chaque point et en ajouter quelques-uns.

Etape 1 : le projet

Nous allons commencer par séparer les projets de migration en deux grandes familles

Les “coups de peinture” – Comprendre changement de thèmes, de logo … ceux là ne doivent normalement pas poser trop de souci. Ils sont en général rapides, le SEO est rarement bousculé. Il faut juste penser à vérifier que dans les nouvelles maquettes, la structure des pages est similaire et que les blocs de contenu ne disparaissent pas au profit de l’UX ou du temps de chargement ou que des blocs prévus pour le maillage interne disparaissent comme par magie.

Les “replateformings” – Comprendre changement de CMS ceux là c’est un délire ! tant par les délais (entre 6 et 36 mois ) que par l’augmentation du budget qui va découler de ces retards sans fin.

En général, ces projets commencent par un constat (toujours le même ) la solution actuelle ne convient plus. Trop lente, trop lourde à gérer, manque de souplesse pour ajouter de nouvelles fonctions etc etc

On entre donc dans la première phase, une ébauche de cahier des charges qui va être transmise en interne au service dédié ou dans des appels d’offre à des agences spécialisées. Quand je parle d’ébauches de cahier des charges, c’est que dans la majorité des cas, c’est un service qui s’occupe de lister les fonctionnalités nécessaires dans la nouvelle solution. Facile à repérer, si les 3/4 des features demandées concernent du marketing et de la conversion, vous savez qui a fait le cahier des charges. Cependant, même avec la meilleure volonté du monde, une partie des fonctionnalités est oubliée ou le plus souvent minimisée par méconnaissance du service rendu.

Un exemple : le module de gestion des stocks — Le cahier des charges mentionne qu’il en faut un mais il ne sera pas fait mention des commandes semi-automatiques vers les différents fournisseurs que les gestionnaires utilisent au quotidien et qui leur permet de passer les commandes en deux clics au bon format et au bon prix 🙂  — une chose simple qui récupère les catalogues des fournisseurs avec les prix actualisés quotidiennement en gérant les différents formats de flux entrants et sortants : un détail qui demandera plusieurs jours de plus de développement.

Et imaginez ca pour la quasi-totalité des fonctionnalités

On ne jette pas la pierre aux services marketing, si ce sont les devs qui s’en occupent, ils vont faire de même sur d’autres points.

Etape 2 : les réponses

Une fois ce cahier des charges envoyé, les agences ou les services en interne vont qualifier le projet et annoncer un budget et un retro-planning. Cependant, n’ayant pas forcément les bonnes informations, on se doute bien que cela ne va bien se passer… mais continuons

• En interne, les équipes sont souvent moins naïves et vont assez vite voir que certains points ont été oubliés ou minimisés et ils vont éviter une partie des galères à venir.
• En externe, impossible de prévoir les postes de l’appel d’offre oubliés ou réduits comme peau de chagrin

Pour rester sur la gestion des stocks, ils vont se dire que c’est un ajout de modules, ils vont se prévoir un peu de marge et vont proposer 2 ou 3 jours pour mettre en place quand il en faudrait au moins 15 …

Etape 3 : le choix

Que ce soit en interne ou en externe, il va y avoir une proposition chiffrée qui comprendra les licences, le nombre d’heures et un tarif. Rien de foufou ! On passe sur les étapes des appels d’offre, des audits et des entretiens, ce n’est pas le plus important.  Il y aura deux sortes de réponses

FACILE  ! Un budget raisonnable et une faisabilité du projet au beau fixe ! Avec de magnifiques promesses pour prendre le lead – Promesses réalisées en toute franchise à ce moment-là du projet !

COMPLIQUÉ ! un budget élevé, beaucoup d’alertes sur des points ! et une durée de projet beaucoup plus longues que ce que l’on pouvait imaginer – et peu de promesses tant sur les délais que sur la faisabilité.

Sans surprise, c’est souvent la solution 1 qui est choisie. Ce qui se traduit en interne par ignorer la partie de devs qui explique que “Non ! Ça ne prendra pas deux jours de mettre la gestion des stocks en place”  — ils savent … ils ont galéré à l’intégration des flux de tous les fournisseurs. Et, en externe, l’agence qui prévoit des difficultés, “ils ne savent pas faire” “nous n’allons pas les prendre … ” Sans compter bien sûr, l’aspect financier, les actionnaires ou ceux qui tiennent les cordons de la bourse d’une entreprise vont plus facilement vers la solution la moins onéreuse ou la plus rapide.

Etape 4 : le cahier des charges détaillé

Au début, le cahier des charges est souvent succinct et il va falloir aller dans le détail pour commencer à travailler vraiment.

Début du bordel ! et oui ! toutes les fonctionnalités réduites à une puce dans une liste, il va falloir expliquer ce que l’on veut absolument conserver, améliorer et ajouter. Pour les 3/4 cela va aller vite et il n’y aura pas de mauvaises surprises. Pour le dernier quart, c’est un délire ! N’oubliez pas que généralement le point de départ ce sont des vieux CMS qui ont été remodelés dans tous les sens au fil des années par de l’ajout de briques ou des modifications dans le code non documentées pour la plus grande partie.

Imaginez un vieil OS Commerce, qui a subi des modifications pendant une bonne dizaine d’années et dont la plupart des développeurs ont quitté la société depuis bien longtemps. C’est simple, on ne se souvient même plus du nom de la personne qui avait fait ca (si si véridique) donc de là à comprendre ce qui a été fait, ce que cela implique et où, c’est peine perdue ! Cela va être surtout une perte de temps énorme !

Il va falloir auditer, aller interviewer les utilisateurs de cette fonction pour tenter de comprendre ce que ça fait et quelles sont les implications. C’est aussi le moment où l’on s’aperçoit que ce “truc” tourne sur 3 pattes depuis on ignore quand et que probablement des remontées d’infos sont fausses depuis… allez savoir.
Si on reste sur l’exemple des stocks, c’est le moment d’aller faire un tour physiquement dans l’entrepôt pour s’apercevoir de l’ampleur des dégâts et des palettes cachées au fin fond d’un coin sombre dont personne ne semble s’émouvoir depuis très longtemps (encore véridique)

A ce stade, le temps perdu se situe entre 3 et 6 mois. C’est aussi le temps où personne n’a plus de nouvelles de ce projet. Une information vague dans les réunions de type CODIR, ca avance … Sauf qu’au bout de 6 mois, la direction commence à demander des comptes. Que ce soit en interne ou en externe, un projet qui coute du temps et de l’argent depuis 6 mois, on espère commencer à voir des avancées. Et les budgets commencent déjà ne plus être respectés. Ce qui va vite avoir des incidences non négligeables.

Etape 5: Découpage de projet

Maintenant que tout le monde a conscience que ce projet n’avance pas ou pas assez vite, il faut se remettre le nez en urgence dans les rétroplannings pour tenter de respecter les délais initiaux. Donc, on découpe le projet en lot

Suite du bordel ! Quelle que soit la découpe, il va y avoir des décisions surréalistes ! Quelques exemples tirés d’histoires vraies :

• Reporté dans le lot 2 : Commande aux fournisseurs ( ils peuvent envoyer des mails ou des fax)
• Reporté dans le lot 2 : le contenu des pages (SEO en PLS)
• Reporté dans le lot 3 : la récupération des comptes clients
• Reporté dans le lot X+1 : le module de maillage interne
• Reporté dans le lot X+1 : Les titles personnalisables
• Reporté dans un lot non listé : la gestion des stocks par magasin
• etc etc

Chaque service est touché, et chacun se voit amputer d’une fonctionnalité qu’il utilisait régulièrement.

Et bien sûr, on demande à tout le monde le maintien du CA, le respect des marges, le respect des dates de livraison etc etc

et donc le délai de livraison de ce projet vient de prendre entre 6 et 12 mois de plus. (le lot 1 n’aura que quelques mois de retard mais les autres … pfff … )

La fin de projet vient de prendre une bonne année de retard dans le meilleur des cas ! Youpi !

Etape 6: Première livraison preprod et premiers tickets

Forcément, le découpage en lot et la pression imposée aux équipes prend de l’ampleur. C’est dans cette partie du projet que l’on se heurte à des changements. Ce sont les chaises musicales qui commencent ! Les équipes sous pression (en interne ou en externe) commencent à se modifier. Les conditions exigées mettent à mal les humains qui s’en vont ou qui demande à ne plus travailler sur ce projet. Et c’est complètement normal ! 

Nous avons donc des tickets qui font des aller-retours sans fin parce que les équipes sont surchargées et qu’une grosse partie est ni faite ni à faire ! Tant dans les vérifications que dans les corrections. Que personne n’a transmis au nouveau que ce truc-là était ok … etc etc – Quand cela fait 10 fois que l’on vous demande de vérifier le H1 dans la page en suivant une procédure de 10 étapes ( si si ) et que vous avez 3 instances de preprod … y’a forcément une fois où vous allez vous rater et ne pas voir que depuis la dernière vérification le H1 a disparu en mobile.

Encore une fois, on perd du temps et de l’argent sur cette étape. Souvent par manque de communications consécutives aux chaises musicales. Et le projet prend allégrement un bon trimestre de retard de plus.

Pendant ce temps: il ne se passe rien !

Le site en ligne, le fameux “legacy” … il est complètement oublié et faire faire une simple modification dessus est refusée ! C’est le moment d’allumer des cierges et de croiser les doigts pour espérer que rien ne casse ! Cela veut également dire que le site va prendre un retard considérable par rapport à la concurrence. Aucune évolution ne sera possible ! au mieux des corrections et encore ! et si bien sûr s’il faut en plus ajouter des fonctionnalités sur le nouveau site prévu… Comment dire … ca va être long !

Un exemple tout bête : tous vos concurrents se mettent à proposer le paiement en 3 fois, vous ne pourrez pas vous le proposer avant le nouveau site. Croisez les doigts que ce ne soit pas prévu dans un lot ultérieur…

Etape 7 : nouveau site en ligne ! enfin

Après 18 à 24 mois de retard parfois plus, le nouveau site est en ligne ! il a été amputé de beaucoup de choses qui seront progressivement mises en place, mais comme il faudra corriger les erreurs de ce lot –  Les retards vont une nouvelle fois s’accumuler. et oui ! Faire une vérification en preprod et travailler au quotidien sur un site ce n’est pas pareil et les tickets post “mise en ligne” sont souvent très nombreux !

La morale de l’histoire

Au départ, tout semble rose et plus le projet avance et plus, on s’enlise… Les délais sont multipliés par 3 ou  4 et les budgets aussi ! Au départ, le projet est chiffré 100 k et à la fin, l’enveloppe est passée à plus de 300 k pour un site bancal ! Qui va nécessiter de dépenser au moins 100 k de plus. .. Les équipes sont usées et démotivées, le fossé avec les concurrents, c’est creusé et la société dans son ensemble est mise à mal !  (révision des budgets, de la masse salariale … ) Les personnes qui partent ne sont pas remplacées, certaines sont licenciées. Rien de réjouissant !

Je sais ce que vous vous dites: c’est un scénario catastrophe et ca n’arrive pas souvent ! Détrompez-vous, cela fait plusieurs cas que je rencontre et pour en avoir parlé avec d’autres consultants c’est un scénario malheureusement classique.
Bien que ce scénario corresponde plutôt à des entreprises de taille moyenne à grande, les petites ne sont pas forcément épargnées.

Quelques conseils

1. Documentez vos modifications : je sais, c’est fastidieux, mais cela va servir un jour et cela permettra de ne pas faire de découverte au moment d’une migration
2. Suivez votre démarrage de projet comme du lait sur le feu, c’est souvent dans cette première partie que commencent les retards et très souvent par manque de suivi réel
3. Valorisez vos équipes, ne collez pas à la tête du projet un gestionnaire de ticket qui ne comprend rien ! Créer une équipe “dirigeante” qui représentera chaque branche de l’entreprise et qui pourra facilement répondre aux questions des devs
4. Ne croyez pas aux belles promesses ! Un changement de plateforme complet ne se fait pas en quelques semaines ! Et plus votre site a de la bouteille, plus le projet risque d’être long. n’écoutez pas les agences ou les devs qui vont vous dire que dans 1 mois c’est bon ( le dernier qui a dit ca, le projet a eu 18 mois de retard pour un site entièrement à reprendre ! )
5. Prévenez les “finances” que le budget initial peut être soumis à modifications et demandez-leur de le prévoir dans les budgets ! Il vaut mieux une bonne surprise qu’un budget multiplié par 3 ou 4.
6. Conservez des ressources pour le “legacy”  !

Sur ce, je vous souhaite de belles migrations sans encombre ! Et n’hésitez pas à venir ajouter des conseils !