Le client dit avoir besoin d'un site web. Cela ressemble à une demande précise, mais ce n'en est pas une. On ne sait pas encore pourquoi le site existe, à qui il devrait être utile, ce qu'il devrait changer au sein de l'entreprise, ni comment on saura qu'il a atteint ses objectifs. « Je veux un site web » marque le début d'une discussion, pas un cahier des charges.

Le client n'a pas besoin d'être développeur web. Il connaît son activité, ses clients et ses problématiques, mais il n'a pas besoin de comprendre les liens entre contenu, ergonomie, accessibilité, performance, référencement (SEO), infrastructure et maintenance. Et il ne devrait pas faire semblant. Le rôle du développeur n'est pas de transformer machinalement chaque demande en code. Il s'agit de comprendre l'objectif commercial, de le traduire en exigences et d'expliquer au client les implications des différentes options.

Par conséquent, l'entretien préalable à la création du site web n'est pas une simple formalité commerciale. C'est la première étape du processus de conception.

Le client décrit la solution, mais c'est à vous de découvrir le problème

J'ai souvent constaté ce principe : le client ne sait pas encore précisément ce qu'il veut. Parfois, il n'a qu'une idée générale. Parfois, il montre le site web d'un concurrent et demande un élément similaire. D'autres fois, il présente une exigence très spécifique qui s'avère être un anti-modèle : une solution courante ou familière qui ne remplit pas sa véritable fonction.

Ce n'est pas la faute du client. Personne ne peut lire dans les pensées d'autrui. Tant que les attentes ne sont pas formulées clairement, il est impossible d'y répondre honnêtement. Même une attente exprimée doit être liée à la question : « Quel est l'objectif pour l'utilisateur ou l'entreprise ?» Les méthodes de conception de services éprouvées dissocient également le besoin de la solution proposée et recommandent de commencer par bien comprendre le contexte utilisateur (GOV.UK, « Apprendre à connaître les utilisateurs et leurs besoins »).

Un client pourrait dire qu'il a besoin d'un blog. Cependant, un blog n'est qu'un outil de publication de contenu. Il ne génère pas automatiquement d'expertise de marque, de trafic ou de ventes. Il exige un contenu de qualité, un travail systématique et une communication active avec l'audience. Google précise que même le respect des exigences techniques et des bonnes pratiques ne garantit pas l'indexation ou l'affichage d'une page dans les résultats de recherche (Google Search Essentials). Il recommande également de créer du contenu utile et d'informer activement les communautés concernées au sujet du site (Google, « Créer un contenu utile, fiable et centré sur l'humain »).

Un blog est pertinent lorsqu'il aide un client potentiel à mieux comprendre son problème, à évaluer les compétences de l'entreprise et à prendre une décision d'achat plus éclairée. Si une entreprise n'a pas l'intention de créer ou de promouvoir du contenu, elle doit le préciser avant d'établir un devis, et non des mois après le lancement d'une section « Actualités » vide.

Un seul entretien ne suffit pas, car le site comporte de nombreux aspects.

Je divise l'entretien en plusieurs phases. Premièrement, il est essentiel de comprendre les besoins généraux et de déterminer le type de solution : site web simple, site personnel, site d'entreprise, boutique en ligne, ou encore une application plus complexe. Parallèlement, il faut appréhender l'environnement numérique du client : nom de domaine, hébergement, base de données, messagerie, certificat SSL, CDN et systèmes existants avec lesquels la solution sera intégrée.

Les phases suivantes abordent les fonctionnalités, le design, le contenu, le coût et le calendrier. Chaque phase répond à une question différente. Les fonctionnalités décrivent les actions que l'utilisateur et l'administrateur doivent pouvoir effectuer. Le design combine l'interface, l'expérience utilisateur et l'identité de marque. Le contenu inclut les textes, photos, graphismes, vidéos, fichiers audio, traductions et la responsabilité de leur préparation. Le budget et le calendrier indiquent ce qui peut être mis en œuvre immédiatement, ce qui doit être revu à la baisse et ce qui doit être reporté à l'étape suivante.

Le concept de « normes les plus élevées » doit également être décliné en exigences spécifiques. Le W3C élabore de nombreuses normes web, et les WCAG définissent des critères d'accessibilité testables aux niveaux A, AA et AAA (W3C, « Accessibility Standards Overview »; W3C, « WCAG 2 Overview »). La mention « Conforme aux normes W3C » est insuffisante. La spécification doit indiquer la norme utilisée, le niveau de conformité adopté et la méthode de vérification. La réactivité, les performances, la sécurité, les sauvegardes, la confidentialité et les critères d'acceptation doivent être traités de la même manière.

Un client peut ignorer qu'un formulaire de contact implique des obligations en matière de données, l'affichage de messages après soumission, la gestion des erreurs et l'intégration de liens de bas de page appropriés. Il ne devrait pas découvrir ces dépendances après la mise en œuvre. Le rôle de ce processus est de relier les contributions du client aux éléments découlant de la conception de la solution et à la norme convenue.

Une décision doit être prise après chaque étape, et non un simple mémo.

Une conversation sans synthèse se transforme rapidement en un amas de souvenirs épars. Le client se souvient d'une chose, le prestataire d'une autre, et l'agent d'IA peut en recevoir une troisième interprétation. Par conséquent, un document concis doit être créé pour chaque domaine : une description des conclusions, des hypothèses, des décisions en suspens et des implications sur le coût et les autres aspects du projet.

Le client reçoit ce document, formule des commentaires et confirme sa compréhension du résultat attendu. Il ne s'agit pas de lui fournir un ensemble de règles à suivre. L'acceptation doit confirmer une compréhension partagée : ce qui sera fait, ce qui ne sera pas fait à ce stade, les éléments que le client doit fournir et comment les deux parties reconnaîtront le résultat correct.

Une validation précoce n'élimine pas toutes les erreurs, mais elle permet de les détecter lorsque les modifications restent relativement peu coûteuses. Le manuel d'ingénierie des systèmes de la NASA recommande de valider les attentes et les exigences le plus tôt possible et de manière itérative, car la détection tardive d'une solution incorrecte entraîne d'importantes reprises (NASA, « Manuel d'ingénierie des systèmes »). Le site web d'une petite entreprise n'est pas un vaisseau spatial, mais le mécanisme d'erreur reste le même : plus on tarde à se rendre compte qu'on a construit la mauvaise chose, plus il faut jeter ou refaire de travail.

Les couches approuvées constituent le cahier des charges. Ce même cahier des charges sert à estimer le travail, le temps et le coût, et devient ensuite le contexte pour les personnes ou les agents qui mettent en œuvre le projet. Au lieu d'un ordre général de « créer le site web », le prestataire reçoit des objectifs, des fonctionnalités, un contenu, une apparence, des contraintes, des normes et des critères d'acceptation convenus.

La majeure partie du travail peut être effectuée en quelques clics.

L'établissement du budget est une étape délicate car le client ne voit que le résultat final. Il peut supposer qu'un site web se crée à partir de blocs prédéfinis et en quelques clics. Or, même le titre de la première section de la page nécessite une réflexion. Il doit inspirer confiance, attirer la bonne cible, expliquer la valeur de l'offre et s'intégrer au design global. Une phrase comme « nous sommes excellents » peut s'écrire en un clin d'œil, mais elle n'incite généralement pas le visiteur à poursuivre sa lecture.

Il existe des dizaines d'éléments de ce type, en apparence insignifiants. Chacun peut influencer d'autres parties du site. Par conséquent, une estimation fiable ne se base pas sur le nombre de sous-pages ou de blocs. Elle repose sur le travail nécessaire pour atteindre le résultat convenu, en tenant compte des dépendances et en vérifiant le bon fonctionnement de l'ensemble.

Une bonne évaluation n'a pas pour but de garantir l'immuabilité du projet. Elle vise à garantir que toute modification soit réfléchie. Si, après le début du développement, le client souhaite ajouter une boutique à un blog initialement prévu, il ne s'agit pas d'une simple modification. Il s'agit d'une nouvelle étape avec ses propres spécificités : modalités de paiement, commandes, contenu, risques, coûts et échéancier. Un entretien distinct devrait être mené, même si les prestataires utilisent le même site web et entretiennent la même relation avec le client.

Les objections des prestataires peuvent faire partie intégrante d'un service de qualité.

Il arrive que les exigences d'un client soient incompatibles avec ses objectifs, son budget ou ses propres critères de qualité. Dans ce cas, un prestataire ne devrait pas se retrancher derrière l'expression « le client est roi » ni imposer arbitrairement ses goûts. Un dialogue s'impose, présentant les deux aspects de la décision : les avantages pour le client, les concessions qu'il devra faire, les risques qu'il acceptera et l'alternative qui répond le mieux à ses objectifs.

Il s'agit aussi d'un échange pédagogique. Le client n'a pas besoin de maîtriser le jargon du secteur, mais il doit comprendre ce pour quoi il paie et pourquoi la proposition est présentée ainsi. Ce n'est qu'à cette condition qu'il pourra approuver une solution en toute connaissance de cause ou accepter les conséquences d'un autre choix.

Cependant, tous les conflits ne peuvent être résolus. Je préfère ne pas commencer un projet plutôt que d'être payé pour un site web dont je sais d'avance qu'il ne sera pas utile au client. À court terme, cela signifie perdre le contrat. À long terme, cela protège les deux parties de la déception, des conflits et d'un projet que je ne serais pas fier de présenter comme le mien.

La qualité peut engendrer la confiance, des recommandations et des collaborations ultérieures, mais elle ne garantit rien automatiquement. Le marché, la visibilité, l'offre et l'activité client qui en découle restent essentiels. C'est pourquoi je ne prétends pas vendre un site web comme une machine magique à acquérir des clients. Je peux concevoir un outil performant et expliquer clairement son utilisation. En revanche, je ne peux garantir un résultat sans tenir compte de l'ensemble de l'entreprise.

La spécification marque la fin de l'entretien et le début de la responsabilité

Le résultat de ce processus n'est pas un simple fichier contenant les réponses du client. Il s'agit d'un manuel d'implémentation validé : une synthèse de l'objectif commercial, des besoins des futurs utilisateurs, des exigences du client, de l'expertise du prestataire, des normes, du budget, du calendrier et des critères d'acceptation.

Grâce à ce manuel, les tâches peuvent être lancées, les rapports d'avancement établis, le projet mené, la validation du projet effectuée, le client formé et le support, les mises à jour et les sauvegardes planifiés. Sans ce manuel, l'implémentation repose sur des conjectures. Avec lui, cela peut rester complexe, mais au moins nous savons quel problème nous résolvons et qui a validé la méthode employée.

Le client doit recevoir tout ce qu'il a spécifiquement demandé, ainsi que les éléments nécessaires au bon fonctionnement du système dans son ensemble, conformément aux normes convenues. Il ne s'agit pas d'ajouter des fonctionnalités inutiles. L'objectif est de s'assurer qu'après la mise en service, le client ne se rende pas compte qu'il a acheté une partie du système sans avoir été informé des autres composants.

Un site web créé uniquement pour le plaisir d'avoir un site web n'a aucun intérêt. Un outil n'a de sens que si son objectif, sa portée et son utilisation prévue sont clairement définis d'un commun accord avant le début des travaux. ## Bibliographie

— NASA, « Manuel d’ingénierie des systèmes de la NASA » (https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf), 2016, consulté le 2 septembre 2026.

— Initiative pour l’accessibilité du Web du W3C, « Présentation des normes d’accessibilité » (https://www.w3.org/WAI/standards-guidelines/), consulté le 2 septembre 2026.

— Initiative pour l’accessibilité du Web du W3C, « Présentation des WCAG 2 » (https://www.w3.org/WAI/standards-guidelines/wcag/), consulté le 2 septembre 2026.

✦Construire des systèmes pour plus d’autonomie.