12. Rédiger un cahier des charges web utile sans jargon technique

Un cahier des charges web utile aide une PME ou un indépendant à cadrer les pages, contenus, parcours et validations avant de choisir une solution.
1. En bref
Un cahier des charges web utile n’est pas un document rempli de termes techniques. C’est un accord simple sur le problème à résoudre, les personnes à servir, les pages à prévoir, les contenus à fournir et la manière de valider le résultat.
Pour une PME ou un indépendant du Valais, le plus important est de décrire ce que le site doit permettre de comprendre et de faire. La technologie vient ensuite, quand le périmètre est assez clair pour être comparé.
2. Commencez par le but du site
Avant de lister des fonctionnalités, écrivez la décision que le site doit aider à prendre. Par exemple : comprendre une offre, demander un devis, prendre contact, réserver un rendez-vous ou trouver une information précise.
Cette phrase évite de transformer le cahier des charges en catalogue d’idées. Elle donne aussi un repère pour écarter les demandes qui ne servent pas le projet.
Ajoutez ensuite trois éléments concrets :
- l’activité présentée ;
- les personnes qui visiteront le site ;
- l’action attendue après la lecture.
Le site de création de site internet en Valais suit cette logique : la structure, les contenus et le niveau de personnalisation sont cadrés à partir de l’offre et des publics concernés.
3. Décrivez les visiteurs avec leurs questions
Évitez les portraits trop généraux comme « tout le monde peut être intéressé ». Notez plutôt les questions auxquelles une personne doit obtenir une réponse :
- Que proposez-vous exactement ?
- Pour quel type de besoin êtes-vous la bonne personne ?
- Où intervenez-vous et comment vous contacter ?
- Quelles informations faut-il fournir pour commencer ?
Pour un indépendant ou une PME locale, le contexte peut aussi inclure la zone desservie, les langues utiles, les horaires ou les contraintes de prise de rendez-vous. Ne retenez que ce qui correspond réellement à l’activité.
4. Listez les pages avant les fonctions
Commencez par une arborescence courte. Pour chaque page, indiquez son rôle et les informations qu’elle doit contenir :
- accueil : expliquer l’offre et orienter vers l’action principale ;
- services : détailler les prestations et leurs limites ;
- à propos : présenter la personne ou l’équipe avec des faits vérifiables ;
- réalisations : montrer uniquement les projets dont le contenu peut être publié ;
- contact : préciser les informations nécessaires pour répondre ;
- mentions légales et confidentialité : prévoir les pages adaptées au projet.
Une page utile n’a pas besoin d’être longue par principe. Elle doit surtout répondre à une question identifiable. La page de refonte de site web en Valais distingue par exemple l’audit, les priorités, la migration et les limites d’une refonte.
5. Séparez contenu disponible et contenu à produire
Pour chaque page, indiquez ce qui existe déjà et ce qui doit encore être préparé : texte, photo, logo, document, témoignage ou information légale.
Cette distinction rend le planning plus réaliste. Elle évite aussi de promettre une page dont le contenu n’est pas encore validé.
Vous pouvez utiliser une table simple :
| Page | Contenu disponible | À préparer | Responsable | Validation |
|---|---|---|---|---|
| Accueil | description de l’activité | texte final et visuels | client | client |
| Service principal | notes existantes | périmètre et limites | client + prestataire | client |
| Contact | adresse et formulaire souhaité | champs et message de confirmation | client | client |
Le responsable n’est pas forcément la personne qui rédige. Il s’agit de la personne qui peut confirmer que l’information est exacte.
6. Décrivez les parcours importants
Une fonctionnalité est plus facile à comprendre quand elle est liée à un parcours. Décrivez les étapes avec des phrases simples :
- La personne arrive sur une page de service.
- Elle comprend si l’offre correspond à son besoin.
- Elle ouvre le formulaire de contact.
- Elle transmet les informations nécessaires.
- La demande arrive au bon endroit et un retour est possible.
Ajoutez les cas qui peuvent bloquer le parcours : champ obligatoire manquant, pièce jointe trop lourde, demande incomplète ou absence de réponse automatique. Vous n’avez pas besoin de choisir le nom d’un outil pour décrire ces situations.
7. Cadrez les contraintes sans choisir la technologie trop tôt
Un cahier des charges peut mentionner des contraintes réelles : langue, mobile, accès administrateur, hébergement, migration, calendrier, budget ou services externes déjà utilisés.
Il doit éviter de présenter une solution technique comme une obligation si le besoin n’a pas encore été comparé. Décrivez d’abord le résultat attendu, puis les contraintes qui peuvent influencer le choix.
7.1 Suisse : LPD, transparence et cookies
En Suisse, un site qui traite des données personnelles doit notamment respecter la Loi fédérale sur la protection des données (LPD) et son ordonnance (OPDo). Le cahier des charges doit donc préciser quelles données sont collectées, dans quel but, qui y accède, combien de temps elles sont conservées et comment elles sont protégées. Il faut aussi prévoir une information claire des personnes concernées et limiter la collecte aux données réellement nécessaires.
La protection des données doit être intégrée dès la conception et activée par défaut. Pour un formulaire de contact, cela implique par exemple de ne demander que les informations utiles, de sécuriser leur transmission et de définir qui recevra les demandes.
Pour les cookies et technologies similaires, le cadre suisse repose notamment sur la LPD et l’article 45c de la Loi sur les télécommunications. L’utilisateur doit recevoir une information claire et disposer d’un moyen de refuser lorsque le traitement le permet. Un bandeau de consentement identique au modèle européen n’est pas automatiquement obligatoire dans tous les cas en Suisse : la solution dépend des traceurs utilisés, de leur finalité et du niveau de risque. Un consentement explicite peut notamment être nécessaire pour certains traitements sensibles, inattendus ou présentant un risque élevé.
7.2 Union européenne : quand le RGPD s’applique
Le Règlement général sur la protection des données (RGPD) ne s’applique pas à un site suisse uniquement parce qu’il peut être consulté depuis l’Union européenne. Il peut toutefois s’appliquer si l’activité possède un établissement dans l’Union, propose intentionnellement des biens ou services à des personnes qui s’y trouvent, ou suit leur comportement dans l’Union.
Lorsque le RGPD s’applique, le cahier des charges doit notamment prévoir une base juridique pour chaque traitement, une information transparente, la minimisation des données, une durée de conservation, l’exercice des droits des personnes ainsi que l’encadrement des sous-traitants et des éventuels transferts de données.
Pour les cookies et traceurs non essentiels, les règles européennes relatives à la vie privée en ligne exigent en principe un consentement préalable. Les traceurs strictement nécessaires au service demandé peuvent être exemptés. Le refus doit être possible et le retrait du consentement aussi simple que son acceptation.
Ces règles dépendent de la situation concrète, des publics visés et des outils installés. Cette présentation fournit des repères de cadrage et ne remplace pas un avis juridique adapté au projet.
8. Définissez une validation observable
Remplacez « le site doit être professionnel » par des critères que l’on peut relire :
- les pages prévues existent ;
- les textes validés sont présents ;
- le formulaire reçoit une demande de test ;
- les accès convenus sont remis ;
- les liens principaux fonctionnent ;
- les pages sont lisibles sur mobile et ordinateur ;
- les éléments à corriger sont listés avant la mise en ligne.
Un critère peut être simple sans être vague. Le but est que le client et le prestataire puissent regarder le même résultat et décider ce qui est terminé.
9. Prévoyez les responsabilités après la mise en ligne
Le cahier des charges doit dire qui fournit les contenus, qui valide, qui gère les accès et qui répond aux demandes après le lancement. Il peut aussi préciser ce qui n’est pas inclus dans le périmètre initial.
Cette partie est particulièrement utile pour une refonte. La page dédiée à la refonte distingue déjà l’audit, les corrections retenues, la migration et le suivi après la mise en ligne : ce sont des étapes différentes, qui ne doivent pas être confondues.
10. La checklist avant d’envoyer le document
Avant de demander une offre, relisez votre cahier des charges avec ces questions :
- Le but du site tient-il en une phrase ?
- Les publics et leurs questions sont-ils identifiés ?
- Chaque page a-t-elle un rôle ?
- Les contenus disponibles sont-ils séparés des contenus à produire ?
- Les parcours importants sont-ils décrits du début à la fin ?
- Les données, accès, langues et intégrations nécessaires sont-ils mentionnés ?
- Les critères de validation sont-ils observables ?
- Les responsabilités après la mise en ligne sont-elles claires ?
S’il reste une question importante, écrivez-la dans le document au lieu de la cacher derrière un terme technique.
11. Faut-il un document long ?
Non. Un document court et précis vaut mieux qu’une longue liste de fonctionnalités non reliées à un objectif. Pour un premier cadrage, quelques pages bien structurées peuvent suffire si elles permettent de comparer le périmètre, les responsabilités, les contenus et les validations.
L’essentiel est de pouvoir distinguer ce qui est indispensable au lancement, ce qui peut attendre et ce qui relève d’une autre étape.
12. Conclusion
Un bon cahier des charges web aide surtout à prendre de meilleures décisions avant le développement. Il met le besoin, le contenu, les parcours et les responsabilités au même endroit, avec des mots que toutes les personnes du projet peuvent relire.
Pour préparer votre projet, partez de l’offre à expliquer, des questions de vos visiteurs et du résultat attendu. Vous pourrez ensuite demander une structure et un périmètre adaptés, sans imposer de jargon technique avant d’en avoir besoin.
13. Sources
- Création de site internet en Valais — Antoine Quarroz
- Refonte de site web en Valais — Antoine Quarroz
- Déclaration de protection des données sur Internet — PFPDT
- La nouvelle Loi fédérale sur la protection des données — PFPDT
- Cookies : conseils pratiques — PFPDT
- Loi fédérale sur la protection des données — Fedlex
- À qui s’applique le droit européen de la protection des données ? — Commission européenne
- Règlement général sur la protection des données — EUR-Lex
- Vie privée et communications en ligne — Your Europe