Du cahier des charges à la mise en ligne : comment éviter les malentendus pendant un projet web

Les mots abstraits sont une première source de confusion :

• moderne ;
• professionnel ;
• intuitif ;
• dynamique ;
• rapide ;
• complet.

Ces termes expriment une ambition, mais ne définissent pas ce que le site doit permettre de faire.

Une entreprise peut demander un « espace client ». Pour elle, cela signifie peut-être consulter des factures, télécharger des documents et suivre une commande. Pour l’équipe technique, cette expression soulève immédiatement d’autres questions : faut-il créer des comptes, gérer des mots de passe, définir plusieurs rôles, stocker des données personnelles ou connecter un logiciel externe ?

Le malentendu apparaît lorsque ces questions restent implicites.

Les différences de vocabulaire jouent également un rôle. Le client décrit son activité avec ses mots métier. Le designer pense en parcours, en contenus et en hiérarchie visuelle. Le développeur pense en données, règles, intégrations et cas d’erreur. Chacun détient une partie de la solution, mais aucun document ne remplace les échanges nécessaires entre ces points de vue.

Une exigence utile ne décrit pas seulement une page. Elle associe une personne, une action et un résultat.

Au lieu d’écrire :

Le site comportera une page de contact professionnelle.

Il vaut mieux préciser :

Un visiteur doit pouvoir sélectionner le sujet de sa demande, fournir ses coordonnées, écrire un message, recevoir une confirmation et permettre à l’équipe concernée de recevoir la demande.

Cette formulation fait apparaître plusieurs décisions :

• les champs nécessaires ;
• les champs obligatoires ;
• les destinataires ;
• la confirmation après envoi ;
• la protection contre le spam ;
• le traitement des données ;
• le fonctionnement sur téléphone ;
• la personne responsable du suivi.

Le Government Digital Service recommande de relier chaque besoin à l’utilisateur concerné, à l’action attendue et à son objectif. Il conseille également de définir des critères d’acceptation qui expliquent concrètement quand le besoin est satisfait. GOV.UK — Writing user stories

Cette logique peut être appliquée aux principaux éléments d’un projet :

• pages et navigation ;
• recherche ;
• formulaires ;
• paiement ;
• espace membre ;
• prise de rendez-vous ;
• catalogue ;
• multilingue ;
• infolettre ;
• CRM ;
• statistiques ;
• rôles d’administration ;
• maintenance.

Le but n’est pas de transformer le client en technicien. Il s’agit de rendre les attentes assez concrètes pour que chaque intervenant puisse vérifier le même résultat.

L’alignement doit se construire par étapes.

Elle détermine les pages, leur hiérarchie et les principaux chemins de navigation. C’est le moment de vérifier si les visiteurs pourront trouver les services, les réalisations, les coordonnées ou les informations importantes.

Il montre ce qu’une page doit contenir avant que les couleurs et les images attirent toute l’attention :

• titre ;
• introduction ;
• preuve ;
• présentation de l’offre ;
• formulaire ;
• appel à l’action ;
• contenus complémentaires.

Un wireframe permet de discuter de structure sans confondre cette discussion avec la décoration.

La maquette introduit les couleurs, les typographies, les images, les espacements et la hiérarchie. Elle doit être évaluée par rapport au besoin initial : le visiteur comprend-il l’offre ? Le bouton principal est-il visible ? La lecture reste-t-elle claire sur mobile ?

Une maquette peut représenter un formulaire sans préciser son routage, un bouton sans destination ou un espace membre sans règles d’accès. Le développement doit traduire les éléments visuels en comportements fonctionnels.

Les prototypes sont particulièrement utiles pour partager une compréhension commune et tester des interactions avant de s’engager dans la réalisation définitive. Le guide du Government Digital Service rappelle toutefois qu’un prototype n’est pas encore un produit prêt pour la production : sécurité, performance et robustesse doivent être traitées dans la version finale. GOV.UK — Making prototypes

Une validation finale unique concentre trop de risques. Si le client découvre à la fin que l’arborescence ne correspond pas à son activité, tout ce qui dépend de cette structure peut devoir être repris.

Des points de validation intermédiaires réduisent ce risque :

1. validation du besoin et des objectifs ;
2. validation du périmètre ;
3. validation de l’arborescence ;
4. validation des wireframes ;
5. validation de la direction visuelle ;
6. validation des fonctionnalités principales ;
7. recette avant mise en ligne.

Chaque validation doit répondre à une question précise. « C’est beau » n’est pas une validation suffisante pour une maquette. Il faut aussi confirmer que les contenus, les actions et les parcours attendus sont présents.

La validation doit identifier :

• l’élément examiné ;
• sa version ;
• la personne responsable de la décision ;
• les remarques formulées ;
• la décision prise ;
• les actions restantes.

Cela évite qu’une maquette approuvée soit remise en question plusieurs semaines plus tard sans distinguer un défaut réel d’un changement de préférence.

Toutes les remarques ne représentent pas la même chose.

Le résultat ne correspond pas à ce qui avait été convenu.

Exemple : le bouton devait ouvrir la page de cotation, mais il dirige vers la page d’accueil.

Une exigence existante doit être clarifiée sans transformer substantiellement le travail.

Exemple : préciser quel membre de l’équipe doit recevoir un formulaire dont le routage était déjà prévu.

Un élément absent du périmètre initial est ajouté.

Exemple : demander une connexion avec un CRM qui n’avait jamais été mentionnée.

La demande modifie suffisamment la solution pour affecter l’effort, les dépendances, le calendrier ou le budget.

Exemple : transformer un site vitrine en plateforme multilingue avec comptes utilisateurs et paiement.

Ces distinctions permettent de discuter du changement sans accuser le client d’avoir « mal demandé » ni le prestataire d’être « peu flexible ». La question devient plus constructive : quel est l’impact de la décision et comment souhaite-t-on l’intégrer ?

La documentation Microsoft sur la gestion du changement recommande de consigner les modifications apportées aux exigences, aux critères d’acceptation et aux pièces associées. Elle conseille aussi de rendre les demandes de changement visibles dans le suivi du projet afin d’en mesurer l’effet sur le périmètre. Microsoft Learn — Manage Agile requirements

Un projet n’a pas besoin d’un procès-verbal de vingt pages après chaque échange. Il a toutefois besoin d’une mémoire commune.

Une décision importante ne devrait pas rester uniquement dans :

• un appel téléphonique ;
• une note vocale ;
• une conversation WhatsApp ;
• la mémoire d’une seule personne.

Après une discussion importante, un court compte rendu peut suffire :

• décision ;
• raison ;
• personne qui valide ;
• impact éventuel ;
• action suivante ;
• échéance.

L’outil importe moins que la discipline. Il peut s’agir d’un courriel, d’un document partagé, d’une carte dans un outil de projet ou d’un tableau de suivi.

L’essentiel est que le client et le prestataire puissent retrouver la même décision.

Prenons le cas hypothétique d’une PME qui remplace, pendant le projet, un formulaire de contact par une demande de réservation avec calendrier et paiement. Un simple message « ajoutez la réservation » ne montre pas toutes les conséquences : disponibilité, confirmation, annulation, paiement, remboursement, notifications et protection des données.

Une décision documentée rend ces conséquences visibles avant qu’elles deviennent des surprises.

La recette n’est pas une promenade rapide sur la page d’accueil. C’est la vérification que le site correspond au périmètre validé et fonctionne dans les situations prévues.

Pour chaque fonction, il faut pouvoir répondre à deux questions :

1. Quel résultat attendons-nous ?
2. Comment allons-nous le vérifier ?

Microsoft présente les critères d’acceptation comme une définition claire de ce que signifie « terminé », utilisable pour estimer le travail et préparer les tests. Microsoft Learn — Manage Agile requirements

• ordinateur ;
• tablette ;
• téléphone ;
• navigateurs prévus ;
• absence de débordement horizontal ;
• lisibilité des contenus.

• menu ;
• liens internes ;
• boutons ;
• téléchargements ;
• liens externes ;
• versions linguistiques.

• libellés ;
• champs obligatoires ;
• validation des erreurs ;
• CAPTCHA ou protection antispam ;
• destinataires ;
• réponse de confirmation ;
• affichage mobile ;
• respect des données personnelles.

• titres ;
• coordonnées ;
• tarifs lorsqu’ils sont publiés ;
• images ;
• textes alternatifs ;
• documents ;
• traductions ;
• mentions juridiques.

• titre SEO ;
• métadescription ;
• URL ;
• hiérarchie H1/H2/H3 ;
• indexation ;
• redirections ;
• partage social ;
• suivi Search Console.

• chargement des pages ;
• performance de base ;
• sécurité ;
• sauvegardes ;
• droits administrateurs ;
• fonctionnement des intégrations.

• anomalies répertoriées ;
• responsable de chaque correction ;
• éléments explicitement reportés ;
• accord du client sur la version mise en ligne.

Le W3C recommande d’intégrer l’accessibilité dans l’ensemble du processus et d’évaluer le produit tôt et régulièrement. Il précise également que les outils automatiques ne remplacent pas complètement une évaluation humaine. W3C WAI — Planning and Managing Web Accessibility, W3C WAI — Evaluating Web Accessibility

Le Government Digital Service recommande lui aussi de tester régulièrement la facilité d’utilisation, la stabilité, la sécurité et le comportement du service dans différentes conditions. GOV.UK — Quality assurance: testing your service regularly

La publication est une étape, pas la fin de la vie du site.

Avant la mise en ligne, il faut confirmer :

• la sauvegarde ;
• les domaines et certificats ;
• les redirections ;
• les formulaires ;
• les accès ;
• les outils de mesure ;
• l’indexation ;
• le propriétaire des comptes ;
• la procédure de retour arrière ;
• les responsabilités après lancement.

Après la publication, Search Console et les outils d’analyse permettent d’observer comment le site est découvert et utilisé. Google distingue notamment les données de visibilité dans les résultats de recherche des données d’interaction sur le site ; les deux éclairent des aspects différents de la performance. Google Search Central — Using Search Console and Google Analytics data for SEO

Il faut également clarifier les quatre notions suivantes.

Un comportement ne correspond pas au fonctionnement validé.

Une personne a besoin d’aide pour utiliser correctement une fonction existante.

Le site doit rester sécurisé, compatible, sauvegardé et opérationnel.

Une nouvelle capacité ou une modification du besoin doit être conçue, estimée et planifiée.

Cette distinction évite de présenter toute nouvelle idée comme une « petite correction » et toute assistance comme une anomalie technique.

Pour maintenir l’alignement du début à la fin :

1. écouter le besoin métier et le reformuler sans jargon ;
2. définir ce que les utilisateurs doivent pouvoir accomplir ;
3. fixer le périmètre et ce qui en est exclu ;
4. valider l’arborescence et les parcours ;
5. valider la structure avant la direction visuelle ;
6. traduire les fonctionnalités en critères d’acceptation ;
7. consigner les décisions et les demandes de changement ;
8. réaliser une recette structurée sur les appareils concernés ;
9. organiser la mise en ligne, la maintenance et les futures évolutions.

Le cahier des charges fixe un point de départ commun. Les validations et la documentation empêchent ensuite ce point de départ de se perdre pendant l’exécution.

Un projet web ne se protège pas avec un document que tout le monde signe puis oublie. Il se protège avec une chaîne de décisions compréhensibles et vérifiables.

Le besoin guide le périmètre. Le périmètre guide la structure. La structure guide le design. Le design guide le développement. Les critères d’acceptation guident la recette. Les décisions documentées encadrent les changements.

C’est cette continuité qui permet au client et au prestataire de rester dans la même équipe jusqu’à la mise en ligne.

• GOV.UK Service Manual — Writing user stories
• GOV.UK Service Manual — Making prototypes
• Microsoft Learn — Manage Agile requirements
• W3C WAI — Planning and Managing Web Accessibility
• W3C WAI — Evaluating Web Accessibility
• GOV.UK Service Manual — Quality assurance: testing your service regularly
• Google Search Central — Using Search Console and Google Analytics data for SEO