Cahier des charges pour un site web : modèle et checklist

« Nous avons besoin d'un site Web moderne qui intègre des applications » est un objectif compréhensible, mais il est difficile d'évaluer l'ampleur du développement. Un entrepreneur présentera une page avec un formulaire, l'autre présentera un catalogue, un compte personnel et une intégration avec CRM. Les offres différeront par leur prix et il sera difficile de les comparer.

Les termes de référence pour le développement d'un site Web doivent décrire pour qui le site Web est créé, quelles tâches il résout, quelles pages et fonctions sont nécessaires et comment le client vérifiera le résultat. Vous trouverez ci-dessous un exemple de site Web de service, les exigences de référencement et un modèle qui peut être transféré dans votre document.

Il s'agit d'un cadre pratique pour discuter d'un projet, et non d'un cahier des charges universel pour toute entreprise. La boutique en ligne aura besoin de scénarios de paiement, de livraison et de retour supplémentaires ; pour un service complexe - rôles d'utilisateur et une description détaillée de l'utilisation des données.

En quoi les spécifications techniques diffèrent-elles du brief et de la conception ?

Le brief vous aide à connaître l'entreprise : ce que nous vendons, à qui, dans quelles régions, avec quel budget et quelles restrictions. La spécification technique transforme ces réponses en un périmètre de travail spécifique. La conception montre à quoi ressembleront les pages et les états de l’interface.

Par exemple, dans le brief vous pouvez écrire : « Les clients envoient des dessins pour les calculs ». Les spécifications techniques doivent préciser où se trouve le formulaire, quels fichiers sont acceptés, quelle est leur taille limite, qui reçoit la demande et ce que voit le visiteur après l'envoi. La mise en page affiche ce formulaire, des info-bulles et des messages d'erreur.

Pour un petit site, tout cela peut être rassemblé dans un seul document avec des liens vers des mises en page. Ce qui est important n'est pas le volume de spécifications techniques en pages, mais l'absence d'interprétations différentes entre le client et l'entrepreneur.

Commencez par le problème métier et les limites du projet

Décrire le service et l'action principale du visiteur. « Connaître les conditions d'installation et envoyer une demande de calcul » est plus utile que « augmenter la notoriété de l'entreprise » : le premier scénario peut être vérifié sur le site Web terminé.

Enregistrez cinq conditions initiales :

Public : qui choisit l'entrepreneur et de quelles informations il a besoin pour prendre une décision.
Géographie : où l'entreprise opère réellement et quelles sont les restrictions de départ ou de livraison.
Suggestions : quels services sont lancés immédiatement, lesquels restent en dehors du périmètre de la première version.
Messages : formulaire, appel, lettre, rendez-vous ou autre méthode de communication principale.
Développement : quelles sections et fonctions sont prévues ultérieurement, mais ne sont pas encore incluses dans l'évaluation.

La section « Non inclus dans le projet » est particulièrement utile. Par exemple : compte personnel, paiement en ligne, transfert de l'ancien catalogue et multilinguisme ne sont pas inclus dans la première version. Il ne s’agit pas d’une interdiction du développement, mais d’une manière de se mettre d’accord sur les mêmes attentes.

Si le format n'a pas encore été sélectionné, comparez d'abord de quel type de site Web une entreprise a-t-elle besoin : page de destination, site Web d'entreprise ou service Web.

Faites une liste des pages et du matériel

Répertoriez les pages non seulement par titre, mais aussi par objectif. Pour un site de service, la structure initiale peut inclure la page principale, des domaines de travail individuels, des projets, des informations sur l'entreprise et des contacts. Une section d’articles a du sens s’il est clair qui préparera et mettra à jour les documents.

Ne créez pas de page distincte pour chaque permutation de mots dans la requête. « Installation de climatiseur » et « installation de climatiseur » peuvent décrire le même service. Et l'installation dans un appartement fini et la maintenance d'un système industriel nécessitent de vérifier : l'offre, le processus, le coût et les questions du client sont-ils suffisamment différents pour séparer les pages.

Pour chaque page, indiquez :

tâche du visiteur et action principale ;
contenu : composition de la prestation, limites, étapes, coût ou principe de calcul ;
photographies, documents et exemples de travaux nécessaires ;
responsable de la préparation et de l'approbation des matériaux ;
méthode de mise à jour après le lancement.

Par exemple, pour la page « Entretien du climatiseur », le client soumet une liste de travaux et des photographies des équipements, le rédacteur prépare le texte, et le responsable vérifie la rédaction technique. Les termes de référence indiquent séparément si ces travaux sont inclus dans le coût de développement.

Demandez également de séparer le nombre de pages et le nombre de modèles. Dix services peuvent utiliser un seul modèle de conception, mais remplir dix pages prend quand même du temps.

Décrire les fonctions à l'aide de scripts, pas de noms

La formulation « formulaire de commentaires » n'explique pas ce qui se passe si le numéro de téléphone est incorrect, si le serveur n'est pas disponible ou si le bouton est à nouveau enfoncé. Pour chaque fonction importante, décrivez les données d'entrée, le résultat positif et les erreurs.

Exemple conditionnel d'exigence relative à un formulaire de candidature :

Champs : nom, téléphone, commentaire. Champ obligatoire - téléphone ; d'autres règles sont convenues avant le développement.
Avant de soumettre, le visiteur prend connaissance de la finalité du formulaire et des explications nécessaires au traitement des données. Les textes et les exigences relatives aux consentements sont convenus séparément avec la personne responsable de cette question.
Si vous le remplissez mal, une erreur claire apparaît à côté du champ ; les données déjà saisies ne disparaissent pas.
Lors d'une requête, un nouvel appui ne crée pas d'autre requête. Le traitement répété d'une requête sur le serveur ne doit pas non plus créer de doublon.
Le message de réussite apparaît après que le serveur ait confirmé que la demande a été enregistrée, et non immédiatement après avoir cliqué sur le bouton.
Si le transfert vers CRM échoue, la requête n'est pas perdue : le stockage, la notification d'erreur et la retransmission sont assurés.
L'événement de demande réussie dans Analytics est envoyé une fois pour une demande acceptée avec succès. Le téléphone, le nom et le commentaire ne sont pas transmis dans les paramètres de cet événement.

Ceci est un exemple de solution de conception et non une description de l'architecture requise pour tous les sites. Pour un projet simple, le mécanisme peut être différent, mais la manière de stocker les hits et la livraison des chèques doit être déterminée à l'avance.

Pour les intégrations, précisez le système spécifique, le sens du transfert, la liste des champs et le responsable de l'accès. « Intégration avec CRM » sans ces détails ne fournit pas une estimation comparable des coûts de main-d'œuvre.

Inclure les exigences SEO avant le début du développement

Le SEO dans les termes de référence, c'est avant tout des exigences en matière de structure, de contenu et d'accessibilité des pages. La promesse « le site sera au sommet » ne peut pas être utilisée comme critère d'acceptation technique : la sortie d'un site en elle-même n'apporte pas de positionnement et d'attrait.

Inclure des points vérifiables dans le document :

Les pages commerciales ont des URL permanentes cohérentes et des liens vers les sections pertinentes du site.
Chaque page indexée a le sien title, description et rubrique principale claire H1.
Le contenu principal est accessible au robot de recherche ; la description du service n'existe pas uniquement à l'intérieur de l'image ou après la soumission du formulaire.
Il n'y a pas d'interdiction accidentelle d'indexation sur les pages de travail, et canonical indique l'adresse principale convenue.
Le plan du site XML comprend des pages canoniques consultables ; les adresses techniques sont traitées selon des règles convenues séparément.
Les pages inexistantes renvoient une réponse 404 valide plutôt que de se faire passer pour des pages de travail avec une réponse 200.

Google recommande une organisation claire du site, des titres descriptifs et des liens accessibles entre les pages. Cela aide la recherche à trouver et à comprendre le contenu, mais ne garantit pas un classement spécifique. Voir Guide de Google sur les bases du référencement.

Google recommande également de lier les documents avec des liens HTML classiques et de réfléchir à la structure des adresses. Il est donc préférable de remplacer l’élément « faire du référencement » par une liste de vérifications spécifiques. Voir Recommandations Google sur la structure du site.

Si un site existant est en cours de remplacement, ajoutez une carte des anciennes et nouvelles adresses, transférez le contenu utile et vérifiez les redirections. Il y a une section distincte dédiée à cela. liste de contrôle de refonte sans perdre le référencement. Pour un nouveau projet, vous pouvez utiliser un commun Plan d'optimisation SEO.

Exemple de spécifications techniques pour le site internet d'une entreprise d'installation de climatisation

Ci-dessous un projet fictif qui montre le niveau de spécificité. Les noms des services, les termes et la composition des fonctions doivent être remplacés par les vôtres.

Tâche : aider le propriétaire de l'appartement à choisir une prestation et demander un devis d'installation. L'entreprise opère dans une ville et une zone de sortie convenue. La boutique d'équipement en ligne n'est pas incluse dans la première version.

Structure : accueil, installation, maintenance, exemples de travaux, présentation de l'entreprise, contacts et documents d'informations convenus. Les deux services utilisent un seul modèle avec un contenu différent. Sur chaque page il y a une transition vers le formulaire de calcul.

Contenu de la page de service : quels travaux sont inclus, ce qui est payé séparément, de quoi dépend le prix, comment se déroule la visite, de vraies photographies et réponses aux questions. Le client fournit des faits et des photographies originales ; la préparation du texte est une tâche distincte.

Applications : le formulaire enregistre le numéro de téléphone, le service sélectionné et le commentaire. Le gestionnaire reçoit une notification. En cas d'erreur de livraison, il est toujours possible de restaurer la demande depuis le stockage convenu. La réussite de la soumission est vérifiée par une application test depuis le début jusqu'à sa réception par le gestionnaire.

Contrôle : un employé peut modifier les prix et les descriptions des services sans modifier le code. Pour mettre à jour la structure, contactez le développeur. Si une édition indépendante n'est pas requise, au lieu d'un CMS, vous pouvez convenir d'un calendrier de mise à jour - il s'agit d'une quantité de travail différente.

Acceptation : toutes les pages, la version mobile, la soumission du formulaire, les erreurs de remplissage, la livraison de l'application et les événements d'analyse sont vérifiés. L'accès, les instructions de mise à jour et de sauvegarde sont transmis au client. Les textes et photographies des pages de travail n'ont pas été remplacés par des espaces réservés temporaires.

Modèle de termes de référence à remplir

Recopiez les éléments dans le document et complétez avant de demander un devis définitif. Marquez les solutions inconnues comme « à déterminer » plutôt que de les laisser à la discrétion implicite de l’entrepreneur.

Entreprise et offre : [ce que nous vendons, à qui, dans quelles régions].
Objet du site : [quelle action le visiteur doit-il entreprendre].
Première version : [ce qui est inclus ; qui n'est clairement pas inclus].
Pages : [liste, objectif, blocs principaux, modèles].
Matériaux : [qui prépare les textes, les photographies, les tarifs ; délais de transfert].
Conception : [exemples avec explications ; matériaux de marque; mises en page de la version mobile].
Fonctions : [scripts, champs, contrôles, réussites et erreurs].
Intégrations : [systèmes, données transmises, gestion des pannes, accès].
SEO et analyses : [adresses, métadonnées, indexation, compteurs et événements mesurés].
Fonctionnement : [qui met à jour le site ; domaine, hébergement, sauvegardes et récupération].
Vérification et transmission : [appareils et navigateurs, scripts de test, instructions, sources et accès].
Étapes et changements : [ce qui est soumis à chaque étape, qui est d'accord, comment les nouveaux souhaits sont évalués].

Une liste de pages, de mises en page et de descriptions d'intégrations peut être jointe à ce document. Spécifiez les versions de l'application afin que l'entrepreneur n'utilise pas une mise en page obsolète après la prochaine approbation.

Comment vérifier l'état de préparation et éviter les exigences controversées

Remplacez les mots évaluatifs par des conditions vérifiables. Au lieu de « version mobile pratique », énumérez les principaux scénarios sur le téléphone : ouvrez le service, lisez les conditions, appuyez sur le numéro, remplissez le formulaire, voyez le résultat. Coordonner les appareils et navigateurs sur lesquels la réception est effectuée.

Au lieu de « site rapide », définissez des pages, des conditions de test et des cibles. Mesurer une page d'accueil vide sur un ordinateur puissant ne décrit pas le comportement d'une page avec des photos et des analyses connectées sur un réseau mobile. Un point de test automatisé ne remplace pas non plus la révision du script.

Au lieu de « clé en main », listez les résultats du transfert : version de travail sur le domaine, sources, accès, instructions de mise à jour, configuration de la sauvegarde et contrôle de la récupération - dans la mesure convenue pour le projet.

Déterminez à l'avance l'ordre des modifications. Si un calculateur apparaît après approbation, ses scénarios, son coût et son impact sur les délais sont d'abord évalués. Cela permet de différencier une nouvelle fonctionnalité d'un correctif pour quelque chose qui a déjà été promis dans la spécification.

Questions fréquemment posées sur les spécifications techniques

Est-il possible de commander un site internet sans spécification technique toute faite ?

Oui. Pour la première conversation, une description de l’activité et de la tâche suffit. Ensuite, le client et l'entrepreneur clarifient les exigences et fixent l'étendue des travaux. La préparation des spécifications techniques détaillées peut constituer une étape distincte ; son résultat et son coût doivent être discutés à l'avance.

Avez-vous besoin de spécifications techniques pour une landing page ?

Oui, mais c'est peut-être court. Nous avons besoin de blocs de pages, de contenu, de formulaire, d'états mobiles, d'analyses et de critères de préparation. Une URL ne signifie pas aucune intégration ou scénarios complexes.

Qui doit rédiger les spécifications techniques : le client ou le développeur ?

Le client est responsable des faits commerciaux, des contraintes et des priorités. L'entrepreneur propose des solutions techniques, clarifie les scénarios et les méthodes de vérification. Un document est utile lorsque les deux parties le comprennent de la même manière, plutôt que lorsqu’il contient simplement de nombreux termes techniques.

Est-il possible d'obtenir immédiatement un prix exact en utilisant ce modèle ?

Cela permet de préparer les données initiales, mais le prix dépend des fonctionnalités, des matériaux, de la conception et des intégrations. Comparez les offres pour une même liste d’œuvres. Plus de détails dans l'article sur en quoi consiste le coût de développement d'un site internet ?.

Si vous préparez un projet, rassemblez une liste de pages et de tâches à l'aide d'un modèle. Il peut être utilisé lors de la demande de développement de site internet dans SEOLIFT: cela permet de discuter plus facilement de la portée de la première version et des exigences pour une promotion ultérieure.