« Nous lançons un nouveau site Web! » Dès que ces mots sont prononcés dans une entreprise, on assiste tout de suite à un élan d’enthousiasme et d’anticipation. Cette phrase déclenche également un intense processus d’analyse et d’inventaire des systèmes, des processus et des rapports dans l’esprit de n’importe quel consultant en informatique ou en affaires.
Pour le client, cette démarche peut être intimidante, voire terrifiante. C’est à ce moment que les entreprises se tournent vers une équipe d’experts-conseils pour s’assurer d’obtenir une solution complète et efficace qui leur donnera un avantage par rapport à leur situation initiale.
Trop souvent, cependant, le client ne sait pas vraiment ce qui peut se cacher dans sa solution actuelle. En surface, tout semble bien fonctionner et répondre aux besoins d’affaires, alors qu’en réalité, dès qu’on y regarde d’un peu plus près, on se rend compte que cela ressemble plutôt à une boîte sans fond pleine de câbles entremêlés.
Lorsqu’une organisation choisit de faire migrer son site Web vers une nouvelle plateforme (ce qui est un investissement considérable), les occasions manquées pendant la définition de la portée et la phase de découverte peuvent souvent entraîner plusieurs problèmes en cours de route. Ces pièges peuvent surgir très tard dans le projet, une fois qu’on commence à regarder chaque détail des solutions et des processus existants, sous la surface. Lorsqu’ils se présentent, ces problèmes peuvent entraîner des conséquences sur les délais, les budgets et même l’architecture du projet.
Une équipe de consultants peut réduire cet impact, car ils savent poser les bonnes questions lors des phases initiales de découverte et des requis manqués. Voici les cinq principaux points sur lesquels ils se concentrent :
L’importance d’une exploration détaillée
Dans le cadre de beaucoup de projets, les consultants d’affaires et les développeurs n’ont pas accès aux environnements de la plateforme actuelle du client. Fournir cet accès peut se révéler précieux, car il aide à trouver des fonctionnalités équivalentes sur la nouvelle plateforme, en plus de fournir un aperçu de la structure du contenu. Si le consultant d’affaires ne peut pas explorer la plateforme par lui-même, il doit au moins pouvoir en faire l’expérience au cours d’une journée typique.
À cette étape, il est essentiel que toutes les bonnes personnes participent à la discussion. Si ce n’est pas déjà fait, il faut inviter l’équipe responsable du contenu à y prendre part. Les responsables du contenu sont ceux qui utiliseront la solution au quotidien, et ils connaissent mieux que quiconque les solutions de contournement et les irritants actuels.
L’équipe devrait donc fournir l’ensemble des flux de travail et des processus d’approbation déjà en place. Il est important de demander comment elle crée une nouvelle page et une nouvelle composante. Elle saura également vous dire quelles pages sont modifiées le plus souvent et lesquelles sont plutôt statiques. Enfin, elle pourra vous indiquer quelles pages sont les plus visitées et, par conséquent, sont le plus attentivement examinées par les parties prenantes de l’entreprise ou l’équipe de direction.
En insistant sur ce type de présentation détaillée, le consultant peut mieux comprendre le niveau de maturité numérique du client. Si l’entreprise n’a aucune expérience avec les plateformes CMS, comme Optimizely, elle pourrait avoir besoin d’un peu plus d’encadrement pour comprendre la structure des pages et des blocs utilisée pour bâtir le contenu. À l’inverse, elle pourrait déjà utiliser une plateforme qui repose sur une structure basée sur des modèles de pages et des composantes, mais produire et gérer tout son contenu en HTML. Ce scénario est plus fréquent qu’on pourrait le croire.
Le contenu dynamique
Je demande toujours au client s’il utilise du contenu dynamique, et chaque fois, on me répond : « Qu’est-ce que vous voulez dire par “contenu dynamique”? » On peut définir le contenu dynamique comme suit :
Contenu qui s’affiche automatiquement, dans le « front-end », selon les propriétés d’une composante CMS existante (page ou bloc), sans que l’auteur du contenu ait besoin de le faire manuellement.
En voici quelques exemples :
- Récupérer l’image de profil et le poste d’un membre de l’équipe à partir de la page des biographies pour l’ajouter de manière dynamique à toutes les pages pertinentes de la section « Notre équipe »
- Afficher une liste d’articles préfiltrés en fonction d’un sous-ensemble de catégories ou de mots-clés attribués aux articles
- Afficher, cacher ou modifier le contenu de la page en fonction de conditions données, comme une sélection préalable de l’utilisateur
- Extraire du contenu externe à partir de sources tierces, par exemple des renseignements sur l’équipe dans Azure AD ou des données financières réglementaires comme un graphique du rendement d’une action.
Il faut savoir que le contenu dynamique n’est pas la même chose que le contenu personnalisé. On peut afficher des en-têtes, des pieds de page ou des pages distinctes pour différents groupes ou pays par l’entremise du CMS, comme les fonctions de groupes de visiteurs ou de marchés d’Optimizely.
Le contenu dynamique doit être vu comme plus qu’un simple outil pour faire économiser du temps à l’équipe de création de contenu. C’est un levier pour tirer parti du contenu déjà présent sur un bloc ou une page et le présenter ailleurs, sans avoir à le recréer dans un nouveau bloc ou un nouveau type de page.
Puisque le contenu dynamique accroît l’efficacité de l’équipe responsable du contenu, on pourrait facilement oublier de l’inclure dans la liste des exigences pendant la phase de découverte. C’est comme un tour de magie qui se produit en arrière-plan et qui peut être tenu pour acquis ou appliqué au contenu qui change peu. Puisqu’il ne saute pas aux yeux, on a parfois tendance à l’oublier. Si vous ne demandez pas spécifiquement d’où provient ce contenu, l’équipe risque de ne pas le mentionner avant que vous ayez terminé la création d’une solution qui n’affiche pas le contenu de manière dynamique pour eux.
Les pages souvent oubliées
Ces pages sont souvent celles que l’on configure une fois et qu’on oublie… jusqu’à l’approche de la fin du projet, quand soudain quelqu’un se souvient de leur existence. Elles passent souvent sous le radar, car elles ne sont accessibles qu’à partir d’une série très précise de liens enfouis ou d’une URL directe, mais ce sont presque toujours des pages absolument essentielles.
En général, ce sont les conditions d’utilisation ou des formulaires uniques qui peuvent être gérés à l’aide de pages, de texte et de formulaires standard.
Parfois, la page peut avoir une disposition, une conception ou une fonctionnalité complètement différentes provenant d’une entité héritée que l’entreprise est dans l’obligation de conserver. Ce formulaire « simple » pourrait devenir un formulaire progressif qui requiert le remplissage automatique de champs à partir des données clients soumises dans un formulaire précédent.
Tout comme pour le contenu dynamique, il est important de poser les bonnes questions tôt dans le processus pour rappeler au client l’existence de ces pages qui pourraient lui avoir échappé. Cela aide aussi à guider la conversation autour de la vérification du contenu. Une équipe de consultants peut dénicher du contenu précieux en creusant sous la surface, tandis que le client pourrait ignorer le contenu qu’il possède et, surtout, le contenu à conserver et celui qu’il vaut mieux laisser de côté.
Le commerce électronique national et international
Savoir où les clients de votre client sont situés dans le monde est une information de base à connaître avant le début du projet. Cependant, certains facteurs comme l’industrie, le type d’entreprise (B2B, B2C ou une combinaison des deux) ou le fait que l’entreprise soit à but lucratif ou non peuvent avoir une grande incidence sur le projet.
Renseignez-vous rapidement sur les exigences réglementaires qui s’appliquent au modèle d’affaires de commerce électronique de votre client. Il a sûrement déjà une équipe responsable de la conformité, possiblement intégrée à son équipe des finances ou produits. Celle-ci jouera un rôle clé lors de ces conversations.
Pensez à poser des questions comme :
- Vos produits doivent-ils être étiquetés d’une manière particulière pour certains États des États-Unis? (Un bon exemple serait les avertissements obligatoires en vertu de la Proposition 65 en Californie)
- Quels renseignements devez-vous inclure dans les descriptions de produits?
- Est-ce que certains produits ou certaines marques sont soumis à un embargo ou à des restrictions dans certains pays ou territoires?
- Devez-vous gérer des limites d’achat ou de dons?
- Quels systèmes sont utilisés pour gérer la conformité à la réglementation entourant la gestion fiscale, la facturation ou le traitement des commandes?
La malédiction du « lift and shift »
L’approche « lift and shift », aussi appelée « réhébergement », est une façon extrêmement simpliste de dire que l’on déplace un site d’une plateforme à une autre, dans l’état exact où il se trouve. Le problème avec cette approche, c’est qu’on suppose que les deux plateformes sont des jumelles identiques en tout point, parfaitement compatibles, de la tête aux pieds (ou de l’en-tête au pied de page).
En réalité, une migration ressemble plutôt à un clonage. Les deux sites se ressembleront beaucoup et offriront à l’utilisateur final des fonctionnalités équivalentes, mais chacun aura une personnalité un peu différente.
Si l’on cherche à atteindre une correspondance parfaite, le projet peut très vite dérailler. C’est une conversation qu’il vaut mieux avoir tôt avec le client afin d’établir des lignes directrices claires et possiblement définir ce qui constitue des variations acceptables, par exemple en ce qui a trait aux éléments de remplissage, aux polices de caractères, etc.
Même si le développeur « front-end » fait tout en son pouvoir pour reproduire les spécifications de mise en page aussi précisément que possible, il pourrait y avoir quelques différences, simplement par la façon dont la nouvelle plateforme intègre l’ensemble des composantes sur une page. Il en va de même lors de la refonte complète d’un site Web. Les éléments présentés dans la maquette fonctionnelle pourraient ne pas être reproduits exactement d’une plateforme à l’autre.
En faisant l’expérience de l’utilisation typique de l’ancien site Web, on peut généralement repérer les tâches qui requièrent des solutions de contournement pour bien fonctionner, ou encore les irritants actuels. La migration vers une autre plateforme est aussi l’occasion d’améliorer la solution, les processus, l’efficacité, les flux de travail, etc.
L’idéal est d’offrir des solutions comparables, tout en encourageant le client à abandonner les éléments inadéquats. Il est normal de rencontrer une certaine résistance au changement de la part du client; c’est alors l’occasion de lui faire voir les capacités et la flexibilité que peut offrir sa nouvelle solution et ainsi le rendre plus enthousiaste à l’idée de son nouveau site Web.
Comme mentionné plus haut, le lancement d’un nouveau site Web représente une période stimulante pour une organisation, et c’est le rôle du consultant de guider le client tout au long de l’aventure. Les équipes de consultants excellent réellement lorsqu’elles parviennent à réduire le stress du client en posant immédiatement les bonnes questions afin d’éviter les pièges et les surprises en cours de projet.
Assurez-vous de plonger dans l’univers du client pour bien comprendre son travail au quotidien, en commençant par demander aux équipes qui utilisent réellement la solution de vous présenter le contenu dans son ensemble. Cette approche, jumelée à une vérification approfondie du contenu durant les phases préliminaires du projet, est un outil précieux qui permettra de mieux définir la portée et de faire ressortir la structure du contenu, les pages et les formulaires tombés dans l’oubli qui risqueraient de vous mettre des bâtons dans les roues plus tard.
Évitez les retards pendant le développement et le travail en double en vous attaquant aux problèmes dès les premières phases. En début de projet, demandez les détails concernant la réglementation nationale et internationale applicable à l’industrie de votre client et à son modèle d’affaires afin d’éviter d’éventuelles complications légales. Établissez des attentes claires quant au résultat final, et ne vous lancez pas dans une quête de la perfection qui risquerait de faire traîner le projet indéfiniment. Apportez des améliorations là où elles sont pertinentes et peut-être qu’un jour, qui sait, nous pourrons abandonner le concept du « lift and shift ».
Grâce à son expertise approfondie, Thinkmax se spécialise dans les partenariats avec les entreprises de détail qui souhaitent stimuler leur croissance grâce à leurs plateformes numériques. Si vous avez des questions concernant le lancement du site Web de votre organisation ou sa migration vers une nouvelle plateforme et que vous avez besoin d’une équipe de consultants compétents pour vous guider dans ce processus, n’hésitez pas à communiquer avec nous.
Cet article a été rédigé par Jeanne Marie Shuffler, analyste principale des affaires numériques chez Thinkmax. Jeanne Marie cumule plus de dix ans d’expérience dans l’utilisation et la mise en œuvre des applications CMS et Commerce d’Optimizely. Elle offre sa connaissance approfondie de l’industrie aux entreprises B2B, aux distributeurs de détail, aux institutions financières et aux organismes sans but lucratif de son portefeuille. Lorsqu’elle n’est pas en train de faire des analyses rigoureuses sur le Web au profit de nos clients, elle aime faire du sport, cuisiner, jardiner et dorloter ses chiens provenant d’un refuge.
