Cahier des charges d’un site web : le modèle, section par section

Trois devis pour un même site, et trois montants sans commune mesure : la scène est banale, et elle ne dit presque jamais qu’un prestataire est cher ou qu’un autre est bon marché. Elle dit que chacun a chiffré un site différent, parce que personne ne lui a écrit lequel. Le cahier des charges sert à cela : décrire le site attendu assez précisément pour que les offres répondent à la même question, et assez tôt pour que les points qui fâchent soient tranchés avant la signature, pas après la mise en ligne.

Le modèle s’adresse aussi bien à une entreprise qu’à une association ou à un organisme public. Il reprend la trame classique d’un cahier des charges et y ajoute ce qu’un modèle générique ne couvre pas : le domaine en .tn, la loi tunisienne sur les données personnelles et, pour les acheteurs publics, la passation sur TUNEPS. Il insiste aussi sur trois clauses souvent absentes : la remise des accès, la propriété du code et la version de PHP. Les textes cités ont été consultés le 8 novembre 2026 ; la liste est en fin d’article.

Ce qu’il faut retenir

• Un cahier des charges décrit un besoin, pas une solution technique. Il dit ce que le site doit permettre ; le prestataire propose comment.
• Les fonctions se classent en indispensables, souhaitables et options, sinon tout est chiffré au prix fort.
• Les contenus ont un responsable et une date : c’est la cause de retard la plus fréquente.
• Domaine, hébergement, comptes et code reviennent au client, et le document le dit avant que les offres arrivent.
• L’accessibilité se fixe par une référence : WCAG 2.2, niveau AA.
• Les critères de choix s’écrivent avant de lire les offres, pas après.

Télécharger le modèle

Le modèle compte une fiche du projet et seize sections, jusqu’aux annexes. La plupart des sections portent une consigne en italique, que votre texte vient remplacer ; beaucoup ont des tableaux ou des listes prêts à remplir : arborescence, fonctions, contenus, comptes remis, planning, critères de choix.

• Télécharger le modèle au format Word (.docx, 42 Ko) : à remplir dans Word, LibreOffice ou Google Docs.
• Télécharger le modèle au format PDF (180 Ko, 7 pages) : pour le lire, l’imprimer ou l’annoter à la main.

Ce qu’il est, et ce qu’il n’est pas. C’est un modèle indicatif : supprimez ce qui ne vous concerne pas, ajoutez ce qui manque. Il décrit un besoin et ne remplace pas un contrat ; la partie qui engage les deux signataires (cession des droits, remise des accès, pénalités, données personnelles) est à faire relire par un juriste ou un avocat. Vous pouvez le copier, le modifier, le diffuser et le réutiliser librement, y compris dans un cadre commercial, sans rien nous demander ni nous citer.

Pourquoi l’écrire, même pour un petit site

Un site vitrine de cinq pages ne demande pas un document de quarante pages. Il demande en revanche que quelques réponses soient écrites quelque part, parce qu’elles changent le prix et le résultat : combien de langues, qui écrit les textes, faut-il un formulaire de rendez-vous, à quel nom sera le domaine. Deux pages bien remplies valent mieux qu’un long document recopié.

Le document sert trois fois. Avant le choix, il rend les offres comparables : chacun chiffre la même liste. Pendant le projet, il tranche les désaccords : « ce n’était pas prévu » se vérifie. À la livraison, il devient la liste de contrôle de la recette : on coche ce qui était demandé.

Les acheteurs publics n’ont d’ailleurs pas le choix. La réglementation des marchés publics demande que les spécifications techniques soient déterminées avant tout appel à la concurrence (article 10 du décret n° 2014-1039 du 13 mars 2014). Une entreprise privée n’y est pas tenue, mais la logique est la même : on ne compare bien que ce qu’on a décrit avant.

Le besoin d’abord : contexte, objectifs, publics

Les trois premières sections du modèle ne parlent pas de technique, et c’est voulu. Un prestataire qui comprend pourquoi le site est commandé propose mieux qu’un prestataire à qui l’on dicte un outil.

Le contexte tient en quelques lignes : l’activité, la taille, les clients ou les usagers, et ce qui déclenche le projet. Un cabinet comptable de Sousse qui veut cesser de répondre au téléphone aux mêmes questions n’a pas le même besoin qu’une association qui doit rendre compte à ses bailleurs.

Les objectifs se vérifient après la mise en ligne, sinon ce sont des souhaits. « Moderniser notre image » ne se mesure pas ; « recevoir les demandes de devis par un formulaire » ou « permettre à l’équipe de publier ses actualités sans passer par le prestataire » se constatent au premier mois. Le modèle place à côté de chaque objectif la question « comment saurons-nous qu’il est atteint ? ».

Les publics décident de beaucoup de choses en aval. Des clients qui viennent depuis leur téléphone, des partenaires qui lisent en arabe, des usagers qui cherchent un horaire et un numéro : chaque public tire la maquette, la langue et les fonctions dans une direction. Écrivez-les avant de parler de couleurs.

Arborescence et fonctions : une liste classée

L’arborescence est la liste des pages, avec pour chacune ce qu’elle contient et qui en fournit le contenu. Elle n’a pas à être définitive : dites seulement si le prestataire peut proposer une autre organisation. Pour une refonte, ajoutez la liste des adresses actuelles qui reçoivent des visites ; chacune doit renvoyer vers sa nouvelle page, faute de quoi le référencement acquis se perd. La méthode est détaillée dans notre article pour changer de site sans perdre ses positions.

Les fonctions, elles, se classent. Une liste sans priorités produit des offres qui chiffrent tout, ou qui retirent en silence ce qui coûte. Le modèle propose trois niveaux :

Deux fonctions demandent une précision de plus. Le paiement en ligne dépend d’une solution de paiement à laquelle l’organisme doit souscrire lui-même ; nommez celle que vous envisagez, ou demandez au candidat de comparer celles qui existent en Tunisie, que décrit notre article sur le paiement en ligne sur un site tunisien. La liaison avec un outil existant (gestion commerciale, facturation, logiciel métier) se chiffre mal sans la documentation de l’outil : joignez-la, ou demandez un chiffrage en deux temps.

Les contenus : qui écrit, qui photographie, pour quand

Un site prêt techniquement attend souvent ses textes pendant des semaines. Le modèle consacre donc une section entière aux contenus, avec un tableau à trois colonnes : le contenu, qui le fournit, et la date de remise. Textes des pages, photos, logo, traductions, documents à télécharger : chaque ligne a un nom en face.

Trois points à trancher par écrit :

• La saisie. Le prestataire met-il lui-même les textes en ligne, ou livre-t-il un site vide que l’organisme remplit ? Les deux se font ; la différence se voit sur la facture et sur le calendrier.
• La rédaction. Si vous la confiez, fixez le nombre de pages rédigées et le nombre de relectures. Un texte commercial écrit par quelqu’un qui ne connaît pas votre métier se réécrit souvent deux fois.
• Les droits des images. Une photo trouvée sur un moteur de recherche n’est pas libre parce qu’elle est visible. Demandez que les images fournies par le prestataire soient utilisables pour votre site, et que leur source soit indiquée à la livraison.

Français, arabe, anglais : décider avant la maquette

En Tunisie, la question des langues arrive presque toujours, et souvent trop tard. Ajouter l’arabe à un site conçu en français ne consiste pas à traduire des textes : l’écriture va de droite à gauche, et c’est toute la page qui se retourne, menus, colonnes, icônes de direction, champs de formulaire. Une maquette pensée dès le départ pour les deux sens coûte bien moins qu’une seconde maquette ajoutée après coup.

Le modèle demande donc d’écrire :

• les langues du site, et si chaque langue a toutes les pages ou une partie seulement ;
• qui traduit, et qui relit ; une traduction automatique publiée sans relecture se remarque vite ;
• pour l’arabe, une police prévue pour cette écriture, et des dates, numéros et prix vérifiés dans les deux sens de lecture ;
• que chaque page déclare sa langue dans son code, et chaque passage dans une autre langue aussi.

Ce dernier point n’est pas un détail de développeur. Les lecteurs d’écran s’en servent pour choisir la bonne prononciation, et les règles d’accessibilité du W3C en font deux critères (« langue de la page », niveau A, et « langue d’un passage », niveau AA).

Identité visuelle et maquettes

Si une charte graphique existe, joignez-la, avec le logo en format vectoriel. Sinon, dites-le : la création d’un logo ou d’une charte est un travail à part, qui ne se glisse pas dans le prix d’un site.

Les exemples aident davantage que les adjectifs. « Moderne et épuré » ne départage personne ; trois sites que vous aimez, et deux que vous ne voulez pas imiter, avec une phrase sur chacun, donnent au prestataire une direction réelle. Fixez enfin le nombre de propositions de maquette et d’allers-retours compris : c’est la ligne qui fait déraper les calendriers.

Les clauses qui protègent l’organisme

La section 10 du modèle est celle qui protège l’organisme le jour où il change de prestataire. Cinq de ses points touchent à ce qui se dispute le plus souvent quand une relation se termine : à qui reviennent le domaine, l’hébergement, les accès et le code, et qui répond de la sécurité et des données.

Le nom de domaine, au nom de l’organisme

La charte de nommage du .tn appelle « titulaire » la personne qui bénéficie de l’enregistrement d’un nom (article 2), lui en laisse la disposition pendant toute la durée de validité (article 13) et exige à la demande deux contacts, administratif et technique (article 10). Le contact administratif est le titulaire lui-même ou une personne qu’il mandate ; le technique peut être le bureau d’enregistrement ou un mandataire.

Le cahier des charges l’écrit donc sans ambiguïté : le nom est enregistré au nom de l’organisme, qui fournit les pièces demandées pour le .tn, et le prestataire peut tout au plus être contact technique. Notre page pour déposer le domaine à son nom précise ce que nous demandons à l’enregistrement ; le choix entre .tn, .com et .com.tn est traité dans notre article sur les extensions.

L’hébergement et les accès, remis au client

Deux montages sont honnêtes : l’organisme ouvre l’hébergement à son nom et y donne un accès au prestataire, ou le prestataire l’héberge et s’engage par écrit à le transférer sur demande. Ce qui ne l’est pas, c’est l’absence de réponse. Le modèle demande au candidat de dire lequel il propose.

Il contient aussi un tableau des comptes à remettre à la livraison, avec en face le nom du titulaire et la date de remise : administration du site, panneau d’hébergement, zone DNS du domaine, base de données, adresses e-mail, outils de statistiques, licences des thèmes, extensions et polices payants. Chaque compte est au nom de l’organisme ; le prestataire y travaille avec un accès à lui, retiré à la fin de sa mission. Sur nos packs d’hébergement, par exemple, le compte est ouvert au nom du client, qui administre son site depuis Plesk.

La propriété du code et des contenus

Payer un site ne rend pas automatiquement propriétaire de tout ce qui le compose. Trois catégories sont à distinguer dans le document : ce qui est créé pour le projet (code spécifique, maquettes, textes, photos commandées), dont les droits sont cédés à l’organisme ; ce qui appartient à des tiers (thème, extensions, bibliothèques, polices), utilisé sous leur licence, qu’il faut lister ; ce que le prestataire réutilise d’un projet à l’autre, dont il garde la propriété mais concède l’usage.

Le modèle demande la remise du code source complet, ou de l’accès au dépôt où il est versionné, et l’achat des licences payantes au nom de l’organisme. L’étendue et la durée de la cession, elles, se rédigent avec un juriste : c’est la clause où un modèle ne suffit pas.

La version de PHP et la sécurité après la livraison

Une grande partie des sites, dont tous ceux qui utilisent WordPress, tournent sur PHP, et chaque branche de PHP a une date de fin de support publiée par le projet. Un site livré sur une branche proche de cette date oblige à une mise à niveau peu après sa mise en ligne, parfois coûteuse. Le modèle demande que le site fonctionne sur une version encore maintenue au jour de la livraison ; le choix de la version pour WordPress est détaillé dans notre article sur la version de PHP.

Après la livraison, le cahier des charges sépare deux choses : la garantie, qui couvre les défauts du site livré pendant une durée fixée, et la maintenance, qui couvre les mises à jour, correctifs de sécurité et sauvegardes dans la durée. La seconde fait l’objet d’une offre séparée, que le candidat chiffre à l’année. Ce qu’elle doit contenir est l’objet de notre article sur le contrat de maintenance d’un site web ; le cahier des charges se contente d’en demander le chiffrage et le délai d’application d’un correctif de sécurité critique.

Les données personnelles et la loi n° 2004-63

Un formulaire de contact collecte déjà des données personnelles : un nom, un numéro, une adresse e-mail. La loi organique n° 2004-63 du 27 juillet 2004 soumet tout traitement à une déclaration préalable auprès de l’Instance nationale de protection des données personnelles (article 7), pose le principe du consentement exprès et écrit de la personne concernée, hors des cas prévus par la loi (article 27), impose de prendre les précautions nécessaires pour assurer leur sécurité (article 18), et subordonne tout transfert vers l’étranger à l’autorisation de l’Instance (article 52).

Pour le cahier des charges, cela se traduit en un tableau simple : chaque formulaire ou outil, les données qu’il collecte, et leur durée de conservation. Ajoutez la liste des outils situés hors de Tunisie que le site appellera (statistiques, envoi de lettres d’information, prise de rendez-vous), parce qu’ils posent la question du transfert. L’organisme reste responsable du traitement ; le prestataire qui accède aux données le fait pour son compte. Les obligations d’une entreprise sont détaillées dans notre article sur la protection des données personnelles.

Accessibilité : une référence, WCAG 2.2 niveau AA

« Site accessible » ne veut rien dire tant qu’on ne nomme pas une référence. Celle qui fait foi est publiée par le W3C : les Web Content Accessibility Guidelines 2.2, recommandation dont la version en vigueur est datée du 12 décembre 2024. Elles classent leurs critères en trois niveaux, A, AA et AAA ; le niveau AA est celui qu’on demande en pratique, le AAA n’étant pas atteignable pour tous les contenus.

La version 2.2 a ajouté des critères qui touchent directement un site de PME :

• une zone cliquable d’au moins 24 × 24 pixels (« taille de la cible », critère 2.5.8, niveau AA) ;
• un élément qui reçoit le focus du clavier ne doit pas être entièrement caché, par exemple par un bandeau fixé en bas de l’écran ;
• une alternative aux mouvements de glisser ;
• une aide qu’on retrouve au même endroit d’une page à l’autre ;
• une connexion qui n’oblige pas à retenir ou recopier une suite de caractères sans aide possible, comme un copier-coller ou un gestionnaire de mots de passe.

Exiger AA ne suffit pas : demandez au candidat comment il le vérifie, et prévoyez à la recette un contrôle sur quelques pages. Navigation au clavier seul, contrastes, textes alternatifs des images, champs de formulaire étiquetés, taille des boutons sur téléphone : ces points se constatent en une heure, sans outil coûteux.

Acheteurs publics : TUNEPS et les règles qui s’ajoutent

Un ministère, une commune, un établissement ou une entreprise publics ne commandent pas un site comme une PME. Le décret gouvernemental n° 2018-416 du 11 mai 2018 a rendu obligatoire la passation de leurs marchés publics à travers le système d’achat en ligne TUNEPS, sauf empêchement technique, urgent et imprévisible (article 2, qui complète l’article 77 du décret n° 2014-1039). Le même texte fait publier l’avis d’appel à la concurrence sur TUNEPS, dans la presse et sur le site des marchés publics de la Haute instance de la commande publique (article 53 nouveau).

Pour le cahier des charges, trois conséquences :

• La méthode d’évaluation est écrite dans le document. Dans sa rédaction de 2014, le décret prévoit que la commission évalue les offres selon une méthodologie insérée dans les cahiers des charges, en principe en retenant l’offre financière la moins disante dont l’offre technique est conforme, la pondération entre qualité et coût étant réservée à certains marchés (article 63). Une exigence absente du document ne peut donc pas départager les candidats.
• Les exigences techniques doivent être vérifiables. Avec un classement par le prix, la conformité technique fait tout le tri : « site rapide » ne se vérifie pas, « niveau AA des WCAG 2.2 contrôlé à la recette sur dix pages » si.
• L’hébergement et la sécurité suivent des règles propres au secteur public. L’acheteur nomme dans le document les textes qu’il applique, avec leur date ; notre article sur le cloud et son cadre légal en Tunisie résume ceux qui encadrent l’hébergement des systèmes publics.

Les textes et leurs modifications sont publiés par la Haute instance de la commande publique ; vérifiez-y la version en vigueur avant de rédiger, et faites relire le document par le service des marchés de l’organisme.

Planning, recette et livrables

Un planning réaliste se construit à rebours depuis la date de mise en ligne, avec une case « validée par » en face de chaque étape : choix du prestataire, atelier de lancement, maquettes, remise des contenus, site sur une adresse de test, recette, mise en ligne, fin de la garantie. Les retards viennent rarement d’une seule étape ; ils viennent d’une validation que personne n’était chargé de donner.

La recette est la vérification, par l’organisme, que le site livré correspond au document. Elle se fait sur une adresse de test, avant la mise en ligne, et s’achève par un procès-verbal signé, avec ou sans réserves. Le modèle prévoit un classement des défauts en trois niveaux : bloquant (il empêche la mise en ligne), majeur, mineur, et un délai de correction pour chacun. C’est ici que le cahier des charges rend son service : chaque ligne écrite se coche.

Les livrables se listent : le site en ligne sur le domaine de l’organisme, le code source et une sauvegarde complète, la liste des comptes et des licences, les sources des maquettes, un guide pour publier et modifier les contenus, et une formation dont la durée est fixée.

Le budget : une enveloppe et une décomposition

Faut-il annoncer un budget ? Si vous en avez un, oui. Les candidats proposent alors ce qui tient dans l’enveloppe, au lieu de trois offres construites sur trois hypothèses. Le modèle ne contient aucun montant ; il demande en revanche une décomposition : conception et développement, rédaction et photos, licences, nom de domaine et hébergement à l’année, maintenance à l’année en offre séparée, options. C’est cette décomposition qui permet de mettre les offres côte à côte, poste par poste.

Pour estimer l’enveloppe elle-même, notre article sur le budget d’un site web en Tunisie passe en revue les postes et leurs ordres de grandeur. Pour un site très simple, une page de présentation, des horaires et un contact, la question se pose parfois autrement : un outil comme notre Créateur de site permet de le faire soi-même, et le cahier des charges devient alors une liste de contenus à préparer.

Comparer les offres : la grille écrite d’avance

La dernière section du modèle dit ce que chaque candidat remet, et comment les offres seront comparées. Les critères se fixent avant de recevoir les offres ; les choisir après revient à justifier un choix déjà fait.

Le modèle laisse la pondération à remplir : elle dépend de vos priorités, et c’est à vous de la fixer. Un acheteur public, lui, suit la méthode que lui impose la réglementation, rappelée plus haut. Si vous faites appel à un hébergeur basé en Tunisie pour la partie hébergement, demandez-lui les mêmes réponses écrites qu’au prestataire, en particulier sur les sauvegardes et la remise des données en fin de contrat.

Cinq erreurs qui reviennent

1. Décrire la solution au lieu du besoin. « Un site WordPress avec telle extension » ferme la porte à une meilleure proposition. Dites ce que le site doit faire ; demandez au candidat de justifier son choix d’outil.
2. Oublier les contenus. Le site est prêt, les textes ne le sont pas, et le planning glisse de deux mois.
3. Laisser le domaine à la discrétion du prestataire. C’est le point le plus difficile à corriger après coup.
4. Confondre garantie et maintenance. La première est due pour le site livré ; la seconde est un service, avec son prix.
5. Choisir sur le total. Deux offres au même montant peuvent ne pas couvrir la même chose ; c’est la décomposition qui le montre.

Sources

Textes et pages consultés le 8 novembre 2026. Ce que nous disons de nos services est repris de nos pages à la même date.

• W3C — Web Content Accessibility Guidelines (WCAG) 2.2, recommandation, version du 12 décembre 2024 (niveaux de conformité, critères 3.1.1 et 3.1.2 sur la langue)
• W3C, Web Accessibility Initiative — What’s New in WCAG 2.2 (critères ajoutés)
• Loi organique n° 2004-63 du 27 juillet 2004 portant sur la protection des données à caractère personnel, texte publié par legislation-securite.tn (articles 7, 18, 27 et 52)
• INT — Charte de nommage du « .tn », décision n° 141 du 24 juillet 2013 (articles 2, 10 et 13)
• Décret n° 2014-1039 du 13 mars 2014 portant réglementation des marchés publics, décret n° 2014-1039, texte publié au JORT, diffusé par la Haute instance de la commande publique (articles 10, 63 et 77)
• Décret gouvernemental n° 2018-416 du 11 mai 2018 modifiant et complétant le décret n° 2014-1039, décret n° 2018-416, texte publié au JORT, diffusé par la Haute instance de la commande publique (articles 1 à 3 : publication des avis et passation obligatoire sur TUNEPS)
• Haute instance de la commande publique — Législation, liste des textes applicables aux marchés publics
• PHP — Supported Versions (durée de support de chaque branche)