Appel d'offres pour une refonte de site web : cadre pour une marque mondiale

Un appel d'offres fonctionne lorsqu'il donne aux agences un problème qu'elles peuvent résoudre et une limite qu'elles peuvent chiffrer. Commencez par la décision derrière la refonte : entrez-vous sur de nouveaux marchés, repositionnez-vous la marque, améliorez-vous le recrutement, soutenez-vous les ventes, regroupez-vous des sites régionaux ou remplacez-vous une plateforme devenue difficile à gouverner?

Énoncez le problème actuel en termes observables. « Notre site web paraît désuet » est un mandat faible. « Les équipes de marque de cinq marchés publient le même récit de produit de façons différentes, et aucun responsable ne peut approuver un changement mondial » donne à une agence quelque chose à investiguer.

Ajoutez les mesures d'affaires qui comptent. Il peut s'agir de demandes qualifiées, de candidatures amorcées, de découverte de produits, d'actions de recrutement, du temps de publication du contenu ou de la proportion de pages qui respectent les cibles d'accessibilité et de performance. Ne promettez pas une hausse que vous n'avez pas mesurée. Donnez aux soumissionnaires la référence de départ si vous l'avez, et indiquez les inconnues comme telles.

Votre appel d'offres n'a pas besoin d'un budget final, mais il lui faut un cadre commercial. Indiquez la fourchette budgétaire ou les tranches de financement que vous comparez, ce qui doit entrer dans les honoraires et ce qui devrait figurer comme phase facultative. Demandez aux agences de présenter leurs hypothèses plutôt que de dissimuler la portée dans un seul total.

Découpez le travail en unités de coût utiles :

• découverte, recherche et stratégie de contenu
• traduction de la marque, direction artistique et travail sur le système de design
• architecture de l'information, UX et prototypage interactif
• modélisation du contenu, migration et localisation
• implémentation front-end et back-end
• intégrations, analytique, accessibilité et assurance qualité
• lancement, formation, soutien et optimisation continue

Donnez aux soumissionnaires une fenêtre de lancement cible, les dates de décision, les périodes d'interdiction, les dépendances liées aux marchés et la date à laquelle l'équipe retenue peut commencer. Une refonte mondiale prend souvent du retard parce que la révision juridique, la traduction, les données de produits ou les approbations régionales arrivent tard. Faites de ces dépendances une partie de la réponse, et non une surprise après l'attribution.

Décrivez le parc numérique avant de décrire la nouvelle page d'accueil. Énumérez les domaines, les sous-domaines, les sites régionaux, les langues, les gabarits, les volumes de contenu, les zones authentifiées, les pages de campagne et les expériences tierces. Précisez ce qui est dans la portée, ce qui en est exclu et ce qui pourrait devenir une option après la découverte.

Demandez une carte de portée proposée en trois couches :

1. La fondation mondiale commune : règles de marque, jetons de design, composants, modèles de contenu, gouvernance et normes techniques.
2. La couche des marchés : contenu local, exigences réglementaires, traductions, campagnes et parcours propres à chaque marché.
3. La couche d'expérimentation : récits interactifs, prototypes, modules de campagne et fonctionnalités qui exigent une décision distincte.

Cela évite qu'un site mondial devienne soit un gabarit rigide unique, soit un ensemble de sites locaux sans lien. Cela permet aussi de comparer les propositions selon les mêmes limites.

Intégrez la réalité du contenu. Indiquez qui est propriétaire des textes, des images, des vidéos, des données de produits et des mémoires de traduction existants. Demandez à l'agence de préciser ce qui devrait être conservé, réécrit, regroupé, redirigé ou retiré. Une refonte qui ignore le contenu n'est qu'un rafraîchissement visuel avec un problème de migration qui l'attend en coulisses.

Un prototype interactif devrait montrer l'expérience aux moments où une maquette statique ne peut pas répondre à la question. Demandez un parcours réaliste à travers la navigation mondiale, un changement de marché, un parcours de conversion principal, une page éditoriale de longue forme et au moins une interaction animée ou immersive si le concept en dépend.

Définissez ce que le prototype doit exposer :

• la hiérarchie et le but de chaque écran clé
• le comportement adaptatif sur les fenêtres étroites et larges
• le focus au clavier, le mouvement réduit et les états d'erreur
• les changements de contenu entre les marchés et les langues
• les états de chargement, de vide et d'échec
• le lien entre le contenu éditorial et les actions de conversion

Ne demandez pas seulement des écrans soignés. Demandez aux soumissionnaires d'expliquer ce qu'ils mettent à l'épreuve, quelles preuves changeraient l'orientation et quelles parties sont illustratives plutôt que prêtes pour la production. Le prototype est un outil de décision. Il devrait aider votre équipe à rejeter une belle idée qui ne peut pas passer à l'échelle avant que l'ingénierie ne commence.

Énoncez d'abord les contraintes : hébergement, révision de sécurité, identité, analytique, recherche, commerce, CRM, information sur les produits, localisation, consentement, déploiement et propriété. Demandez ensuite une architecture recommandée, avec des solutions de rechange et leurs compromis.

Une pile découplée (headless) sépare l'interface de gestion de contenu de la couche de présentation. Cela peut aider une équipe mondiale à réutiliser du contenu structuré sur différents marchés et surfaces numériques, mais cela crée aussi plus de travail d'intégration et de gouvernance. Ne choisissez pas une architecture découplée parce qu'elle semble moderne. Demandez au soumissionnaire de démontrer pourquoi cette séparation convient à votre modèle de publication, aux compétences de votre équipe, à votre processus de mise en production et à votre budget.

Exigez que la réponse nomme :

• le CMS, ainsi que ses permissions de rôles, ses flux de travail, son aperçu et son modèle de localisation
• le cadriciel front-end et l'approche de rendu
• le modèle de contenu et la méthode de migration
• l'hébergement, les environnements, le déploiement et le retour arrière
• les intégrations de recherche, d'analytique, de consentement et d'expérimentation
• la propriété des API, la documentation et les options de sortie
• les contrôles de sécurité, la gestion des dépendances et les responsabilités en cas d'incident
• les budgets de performance et la façon dont les données de terrain seront surveillées

Pour la performance, utilisez des critères d'acceptation mesurables. Les directives de Google sur les Core Web Vitals définissent le LCP pour le chargement, l'INP pour l'interactivité et le CLS pour la stabilité visuelle. Les seuils « bons » actuels sont un LCP d'au plus 2,5 secondes, un INP d'au plus 200 millisecondes et un CLS d'au plus 0,1, mesurés au 75e centile sur mobile et sur ordinateur de bureau. Considérez-les comme des cibles d'ingénierie, et non comme la promesse que chaque page les respectera toujours.

Intégrez l'accessibilité à la portée, au prototype, à la révision du design et à la barrière de lancement. La recommandation WCAG 2.2 du W3C a été publiée le 12 décembre 2024 et fournit des critères de succès vérifiables pour le contenu web. Demandez aux soumissionnaires quel niveau de conformité ils visent, quels critères exigent des tests manuels et comment ils traiteront le contenu, les composants et les outils tiers.

Votre appel d'offres devrait exiger des preuves pour l'utilisation au clavier, la visibilité du focus, le contraste, les alternatives textuelles, les titres, les formulaires, la gestion des erreurs, les préférences de mouvement, le zoom et la réorganisation adaptative. Demandez un plan de tests d'accessibilité qui inclut les technologies d'assistance et une révision humaine. Les analyses automatisées sont utiles, mais elles ne peuvent pas confirmer chaque interaction ou décision de contenu.

Si le concept utilise des widgets personnalisés, demandez comment la sémantique parviendra aux technologies d'assistance. La spécification WAI-ARIA 1.2 précise qu'ARIA complète la sémantique du langage natif plutôt que de la remplacer. Cela donne à votre équipe un test pratique : le soumissionnaire devrait utiliser le HTML natif lorsqu'il exprime déjà l'interaction, et recourir à ARIA pour combler les véritables lacunes.

Exigez des jalons avec des intrants, des extrants, des responsables et des règles d'approbation. Un plan utile passe habituellement de l'alignement et de la recherche à l'architecture, au prototype, au système de design, à l'implémentation, à la migration, à l'assurance qualité et au lancement. La séquence exacte peut changer, mais chaque transfert devrait être associé à une décision.

Demandez à chaque agence de montrer comment elle gérera :

• l'orientation de la direction par rapport aux décisions de produit au quotidien
• la gouvernance mondiale par rapport à l'autonomie locale
• les approbations de contenu et les délais de traduction
• le design et le développement menés en parallèle
• les vérifications d'accessibilité et de performance avant le lancement
• les redirections, la continuité de l'analytique et la préservation du référencement
• la formation, la documentation et la responsabilité après le lancement

Demandez l'équipe proposée par nom, avec le temps alloué et l'emplacement. Demandez qui prend les décisions de design, qui est responsable de l'architecture, qui dirige le contenu et qui est responsable lorsqu'une dépendance bloque l'échéancier. Le logo d'une grande agence ne vous dit pas qui fera le travail.

Communiquez les catégories d'évaluation et leurs pondérations dans l'appel d'offres. Pondérez ce qui peut changer le résultat, et non ce qui est le plus facile à compter.

Indiquez aux évaluateurs comment noter chaque catégorie. Une échelle de cinq points n'est utile que si les repères sont concrets. Par exemple, une note maximale pour l'approche technique pourrait exiger un diagramme, un exemple de migration, une voie de retour arrière et une explication de ce que le client peut exploiter après le transfert.

Demandez un format de réponse court. Exigez les mêmes champs d'étude de cas de la part de chaque soumissionnaire : contexte du client, problème, contribution, livrables, équipe, contraintes et résultat. Demandez un exemple pertinent de gouvernance mondiale et un exemple où l'agence a changé d'orientation après des tests. Cela rend la comparaison plus équitable que de récompenser la présentation la plus longue.

Terminez l'appel d'offres par la structure que vous souhaitez recevoir. Elle devrait inclure :

1. Sommaire exécutif et compréhension du mandat.
2. Approche proposée, chantiers et décisions.
3. Plan de prototype et questions de recherche.
4. Approche en matière de technologie, de contenu et de migration.
5. Plan d'accessibilité, de performance, de sécurité et de qualité.
6. Équipe, rôles, emplacement et disponibilité.
7. Échéancier, jalons, dépendances et apports du client.
8. Prix, hypothèses, options et calendrier de paiement.
9. Réalisations pertinentes et références.
10. Risques, questions ouvertes et exceptions au contrat.

Fixez une limite de mots, un format de fichier, une date limite, une période de questions, un format de présentation et un moyen de contact. Précisez comment les questions tardives seront traitées. Si vous souhaitez une entente de confidentialité, un formulaire d'approvisionnement ou un questionnaire de sécurité, joignez-le avant la date limite de réponse.

• W3C WCAG 2.2 : critères d'accessibilité, modèle de conformité et date de publication.
• web.dev Core Web Vitals : mesures de performance, seuils et mesure sur le terrain.
• WAI-ARIA 1.2 : sémantique pour les composants interactifs personnalisés.
• NIST Cybersecurity Framework : une référence pour discuter du risque de sécurité et des responsabilités organisationnelles.