Cahier des charges : ce

qu'il doit contenir pour

ne pas vous coûter cher

Le document ne sert qu'une fois : le jour où vous n'êtes plus d'accord

Tant qu'un projet se passe bien, personne ne rouvre le cahier des charges. Il est lu le jour où une demande est refusée parce qu'elle est « hors périmètre », le jour où une livraison est contestée, le jour où vous changez de prestataire. Écrivez-le pour ce jour-là.

Cela change complètement ce qu'on y met. Ce qui compte n'est pas la finesse de la description, c'est la capacité d'un tiers à trancher en le lisant. Faites le test avant de signer : donnez le document à quelqu'un qui n'a assisté à aucune réunion, et demandez-lui si telle demande précise est comprise dans le prix. S'il ne sait pas répondre, c'est vous qui paierez la différence.

Le prestataire rédige souvent ce document à votre place. C'est confortable, et ce n'est pas neutre : celui qui écrit le périmètre écrit aussi ses propres limites. Laissez-lui la partie fonctionnelle si vous le souhaitez, gardez la main sur le périmètre, la recette, les droits et les accès. Ce sont les quatre endroits où vos intérêts et les siens cessent de coïncider.

Le périmètre se compte, et il dit surtout ce qui n'est pas compris

Un périmètre écrit en adjectifs ne vaut rien. « Un site moderne et évolutif » n'engage personne. Un périmètre se compte : nombre de gabarits de page distincts, nombre de langues, nombre de formulaires, nombre d'intégrations tierces avec le nom de chaque service.

Précisez ce qu'est un gabarit, parce que c'est là que les malentendus commencent. Un gabarit est une mise en page, pas une page : vingt actualités partagent un gabarit, alors qu'une page de contact et une page d'offre en font deux. Un devis établi sur des gabarits et une attente exprimée en pages produisent un écart qui n'apparaît qu'au moment de la facture.

La seconde moitié du travail consiste à écrire les exclusions. Une exclusion n'est pas un aveu de faiblesse du prestataire, c'est ce qui rend son prix comparable à celui d'un autre. Ce qui n'est pas écrit sera facturé en avenant, au tarif du moment, à un instant où vous n'avez plus la possibilité de consulter ailleurs.

• Les contenus : qui écrit les textes, qui fournit les photos, qui paie les traductions. C'est la cause de glissement la plus banale, parce qu'elle est presque toujours implicite.
• La reprise de l'existant : combien de pages sont migrées, par qui, et dans quel format elles arrivent.
• Les redirections des anciennes adresses, sur quel périmètre et à la charge de qui. Oubliées, elles se paient en visibilité perdue pendant des mois.
• La formation à l'outil d'administration : sa durée, son format, et s'il en reste un support écrit après.
• La suite de la livraison : mises à jour de sécurité, corrections de défauts et évolutions fonctionnelles sont trois engagements différents, à ne jamais regrouper sous le seul mot « maintenance ».

Sans critères de recette, « c'est terminé » n'est qu'une opinion

La recette est le moment où vous acceptez la livraison. Sans critères écrits, elle se joue au ressenti, et c'est toujours le prestataire qui a le dernier mot : lui seul sait ce qu'il avait prévu de faire.

Écrivez aussi la procédure, pas seulement les critères. Combien de jours ouvrés avez-vous pour émettre vos réserves, combien de temps le prestataire a-t-il pour les lever, combien d'allers-retours sont compris dans le prix. Prévoyez surtout le cas d'une réserve non levée : si rien n'est écrit, la seule issue est le rapport de force, et le solde reste bloqué des deux côtés pendant que le site attend.

Un critère de recette est une phrase vérifiable par quelqu'un qui n'a pas écrit le code. Au minimum, faites-y figurer ceci.

• Les navigateurs, leurs versions et les tailles d'écran sur lesquels le site doit fonctionner.
• Le niveau d'accessibilité visé et l'outil qui servira à le constater, faute de quoi le mot « accessible » ne se vérifie pas.
• Le seuil de performance attendu, l'outil de mesure et la page mesurée : une page d'accueil et une fiche produit chargée de médias ne se comparent pas.
• Les parcours métier écrits comme des scénarios : je remplis ce formulaire, je reçois cet e-mail, l'information arrive dans cet outil.
• Le comportement attendu quand quelque chose échoue — c'est exactement ce qui n'est jamais testé avant la mise en ligne.

La propriété du code ne se déduit pas de la facture

Payer un développement ne vous en rend pas propriétaire. En droit français, les droits d'auteur sur un logiciel restent à celui qui l'a écrit tant qu'une cession n'a pas été consentie par écrit, et cette cession doit préciser les droits cédés, leur étendue, leur destination et leur durée. Un devis mentionnant « développement sur mesure », une facture acquittée ou un accès au dépôt de code ne valent pas cession.

Tout le code ne peut pas vous être cédé, et c'est normal. Un site repose sur des briques sous licence libre, parfois sur un thème acheté, souvent sur un socle interne au prestataire. Ce qu'il faut exiger, c'est que le document distingue trois catégories : ce qui vous est cédé, ce qui vous est concédé sous licence avec ses conditions et sa durée, et ce qui appartient à un tiers.

Le socle interne est le point à surveiller. Un prestataire qui construit tous ses projets sur sa propre base ne vous la cédera pas, et il a de bonnes raisons pour cela. Demandez alors une licence perpétuelle, transférable à un autre prestataire, incluant le droit de modifier. Sans cette clause, vous êtes propriétaire d'une maison dont les fondations appartiennent à quelqu'un d'autre : le jour où vous voudrez changer d'équipe, c'est un devis de reconstruction qui arrivera, pas un devis de reprise. Demandez dans la même phrase ce qu'il advient de cette licence si le prestataire cesse son activité.

Les accès : ouverts à votre nom, dès le premier jour

C'est la clause la plus courte à écrire et la plus chère à oublier. La règle tient en une ligne : le prestataire travaille sur vos comptes, il ne les détient pas.

Un nom de domaine déposé au nom du prestataire n'est pas un vol, c'est un raccourci de mise en route. Il devient un problème le jour où la relation se termine mal, et plus souvent encore le jour où l'interlocuteur qui l'a créé n'est plus dans l'entreprise. Exigez que l'inventaire des accès soit livré, tenu à jour, et que la recette ne puisse pas être prononcée sans lui.

• Le nom de domaine, déposé au nom de votre société, avec une adresse de contact qui vous appartient.
• L'hébergement et la gestion des DNS, à votre nom, le prestataire recevant un accès délégué qui se révoque.
• Le dépôt de code, sur une organisation dont vous êtes propriétaire.
• Les comptes de mesure d'audience et les outils de suivi de référencement, avec leur historique.
• Les services tiers facturés à l'usage : envoi d'e-mails, paiement, stockage, fournisseurs d'API.
• Les secrets et les certificats, consignés dans un coffre partagé — pas transmis au fil d'une conversation.

La réversibilité s'écrit avant, parce qu'après elle ne s'obtient plus

La réversibilité, c'est votre capacité à partir avec le projet. Elle ne se négocie pas en fin de relation : à ce moment-là, le prestataire n'a plus aucune raison d'y consacrer du temps, et vous n'avez plus rien à mettre dans la balance. Elle s'écrit avant la signature, tant que le contrat n'est pas gagné.

Le test qui tranche : un développeur extérieur peut-il remettre le site en ligne sur un serveur vierge avec ce qui vous a été remis, sans appeler personne ? Si la réponse est non, la réversibilité est théorique. Demandez ce test une fois en cours de projet, pas à la fin — à la fin, il n'est plus une vérification, c'est une négociation.

• Le contenu exact de la livraison de sortie : code source complet avec son historique, export de la base dans un format ouvert, fichiers déposés par les utilisateurs, variables d'environnement.
• La documentation de déploiement : comment on remet le projet en ligne sur une machine neuve, en partant de zéro.
• Le délai de mise à disposition après votre demande, écrit en jours ouvrés.
• Le sort des données hébergées chez des tiers et le transfert des abonnements en cours.
• Une assistance de passage de relais, bornée en durée, avec son mode de facturation connu d'avance.

Ce qu'il ne faut pas figer : la technologie et le pixel

Un cahier des charges qui impose un cadriciel précis, une version de base de données ou une architecture se trompe de niveau. Vous achetez un résultat, pas une implémentation. Figer la technique produit trois effets, tous à votre charge : vous écartez des prestataires compétents qui auraient fait mieux autrement ; vous prenez la responsabilité du choix, donc le surcoût le jour où la solution imposée se révèle inadaptée — « c'était votre cahier des charges » est imparable ; vous gravez un état de l'art daté dans un projet qui vivra des années.

L'exception concerne les contraintes qui ont une raison extérieure au projet : un outil que votre équipe sait déjà administrer, un hébergement en Europe imposé par votre conformité, une intégration obligatoire avec un logiciel métier, une compétence que vous devez pouvoir recruter. Écrivez la raison à côté de la contrainte. C'est elle qui permettra d'en discuter, et le cas échéant de la lever sans refaire le document.

Même prudence avec les maquettes. Valider des écrans au pixel avant le développement donne un sentiment de contrôle et produit deux dégâts. Le premier : tout écart constaté ensuite devient un défaut à corriger, y compris quand cet écart est une amélioration. Le second est plus coûteux : les états que la maquette ne montre pas — chargement, erreur, liste vide, titre trois fois plus long que celui du modèle, écran de téléphone — n'ont été ni dessinés ni chiffrés, et ils remontent en fin de projet, quand le budget est déjà consommé.

Écrivez plutôt des exigences de résultat. Une direction artistique validée sur quelques écrans décisifs, des règles d'adaptation aux petits écrans, une exigence de lisibilité, et surtout l'autonomie éditoriale que vous voulez conserver : quelles pages devez-vous pouvoir modifier seul, sans rien demander à personne. Cette dernière ligne décide de votre dépendance après la livraison bien plus sûrement que le choix du cadriciel.