Freelance et site web

Le devis est signé, le site est en ligne, la facture est réglée. Le client pense évidemment être propriétaire de ce qu’il vient de payer. Dans bien des cas, juridiquement, il ne l’est pas.

Un site livré n’est pas un site possédé

Payer une prestation transfère la propriété d’un fichier, d’un accès, d’une installation. Cela ne transfère pas les droits d’auteur qui portent sur ce qui a été créé. Ce sont deux opérations distinctes, et la seconde n’a lieu que si le contrat l’organise.

Un site web sur mesure met en jeu trois objets qu’on a tendance à traiter comme un seul. Les litiges naissent presque toujours à l’endroit exact où ils ont été confondus : un client qui veut changer de prestataire découvre que le nom de domaine est au nom de l’ancien ; un indépendant qui n’est pas payé apprend que son travail a été repris par un autre à partir de son propre code.

La cession des droits d’auteur

la clause dont l’absence coûte le plus cher

Le code écrit sur mesure, les maquettes graphiques, les gabarits et les illustrations produites pour le projet relèvent du droit d’auteur dès lors qu’ils portent l’empreinte de leur auteur. Le premier titulaire de ces droits est la personne qui les a créés — l’indépendant, pas celui qui commande. Pour qu’ils passent au client, il faut une cession, et la loi française en encadre étroitement la forme.

Ce que le texte impose exactement

L’article L131-3 du code de la propriété intellectuelle pose des exigences cumulatives. Chaque droit cédé doit faire l’objet d’une mention distincte dans l’acte. Le domaine d’exploitation des droits cédés doit être délimité quant à son étendue, quant à sa destination, quant au lieu et quant à la durée.

Traduit en langage de projet : le contrat doit dire quels droits sont transmis — reproduction, représentation, adaptation, modification —, pour quel usage, sur quel territoire et pour combien de temps. Une cession muette sur l’un de ces points s’expose à être privée d’effet, en tout ou partie, l’appréciation revenant au juge.

La conséquence pratique se mesure au moment où le client veut faire évoluer son site. Sans clause valable, il ne peut pas démontrer qu’il détient le droit de faire modifier, décliner ou reprendre la création par un tiers. Une refonte confiée à un autre prestataire, la revente d’un fonds de commerce incluant le site, l’intégration des gabarits dans une application deviennent alors juridiquement fragiles — pour une raison qui n’a rien à voir avec la qualité du travail livré.

Les formules vagues qui ne cèdent rien

« Le client devient propriétaire du site à réception du paiement » n’est pas une clause de cession. Elle ne mentionne aucun droit, ne délimite ni destination ni durée, et laisse entière la question de savoir ce que le client peut faire du site.

Le réflexe inverse existe aussi, et n’est pas meilleur. Une cession « de tous droits, sur tous supports, pour le monde entier et pour la durée légale de protection » a le mérite d’être large, mais elle doit rester cohérente avec le prix et l’objet réels de la prestation. Un contrat rédigé sérieusement énumère, plutôt qu’il n’englobe.

Code source, licences, comptes

trois propriétés qu’on confond

La cession ne règle qu’une partie du sujet. Reste la question, très concrète, de savoir ce que le client détient physiquement le jour où il change d’interlocuteur.

Le code source sur mesure peut être cédé, à condition que le contrat le dise et que la livraison le prévoie. Un site accessible en ligne n’implique pas la remise de ses sources : sur un développement sur mesure, la livraison des fichiers, de la base de données et de la documentation doit figurer noir sur blanc parmi les livrables, avec son format et son échéance.

Les composants tiers obéissent à une autre logique. Une licence n’est pas cédée avec le site : elle est acquise par quelqu’un, pour un périmètre donné, et elle expire. La vraie question n’est donc pas de savoir à qui elle appartient, mais qui paiera son renouvellement une fois le projet terminé, et ce qu’il advient des fonctionnalités concernées si personne ne le fait. Une réponse écrite évite de découvrir le problème le jour où l’extension cesse d’être mise à jour.

Le nom de domaine mérite un traitement à part. Il doit être enregistré au nom du client, avec ses coordonnées comme titulaire, même si c’est l’indépendant qui gère techniquement l’enregistrement. Un domaine déposé au nom du prestataire place le client en situation de dépendance : changer de fournisseur suppose alors une démarche de transfert que rien n’oblige juridiquement l’ancien prestataire à accélérer. La même règle vaut pour l’hébergement, le compte de statistiques et les accès aux outils d’analyse.

Données personnelles

le prestataire devient sous-traitant

Dès qu’un site comporte un formulaire de contact, un espace client, une inscription à une lettre d’information ou un module de commande, il traite des données personnelles. Cela suffit à faire basculer la relation dans le champ du règlement européen sur la protection des données.

Les rôles y sont définis, et ils ne se choisissent pas. Le client, qui décide des finalités et des moyens du traitement, est responsable de traitement. L’indépendant qui héberge, développe ou maintient le site en accédant à ces données agit pour le compte du premier : il est sous-traitant.

Cette qualification emporte une obligation directe. L’article 28 du règlement impose un contrat, ou un autre acte juridique, sous forme écrite, définissant l’objet et la durée du traitement, sa nature et sa finalité, les catégories de données concernées, les mesures de sécurité, le recours éventuel à d’autres sous-traitants et le sort des données à la fin de la prestation. Une clause de deux lignes laisse par construction la moitié de cette liste de côté ; l’autorité de contrôle française publie des clauses types qui servent de point de départ utilisable.

Accessibilité

une obligation qui a changé de périmètre en 2025

L’accessibilité numérique a longtemps été perçue comme une affaire de secteur public. Ce n’est plus le cas.

La directive européenne relative aux exigences d’accessibilité applicables aux produits et services, transposée en droit français par la loi du 9 mars 2023 et son décret d’application, étend ces exigences à une partie du secteur privé depuis le 28 juin 2025. Sont visés certains services destinés aux consommateurs : commerce électronique, services bancaires, transport de voyageurs, livres numériques, communications électroniques.

Deux conditions commandent l’application concrète, et elles s’examinent au cas par cas : la nature de l’activité, et la taille de l’entreprise, les plus petites structures étant exclues du dispositif au regard de seuils d’effectif et de chiffre d’affaires. Les contenus mis en ligne avant l’entrée en application bénéficient par ailleurs d’un délai plus long que ceux publiés après. Ces seuils et ces délais se vérifient sur les fiches pratiques publiées par la direction générale de la concurrence, de la consommation et de la répression des fraudes, qui est l’autorité compétente sur ce point.

Pour un projet de site, la conséquence est un point de méthode. L’accessibilité se conçoit, elle ne se rattrape pas : contrastes, structure des titres, alternatives textuelles, navigation au clavier et libellés de formulaires relèvent de choix pris au moment des maquettes. Découvrir l’exigence à la recette suppose de refaire une partie du travail. La question mérite donc de figurer dans le cahier des charges, avec une réponse nette : le site entre-t-il dans le champ, et si oui, à quel niveau d’exigence.

Recette, réserves et solde

comment un projet se termine

La plupart des guides s’arrêtent à la mise en ligne. Un projet ne se termine pourtant pas quand le site s’affiche, mais quand la livraison a été vérifiée contradictoirement.

Cette vérification porte un nom : la recette. Elle consiste à contrôler, sur la base du cahier des charges, que ce qui a été livré correspond à ce qui avait été commandé. Elle se conclut par un document daté, listant les éventuelles réserves — les écarts constatés — et fixant un délai pour leur correction.

Le mécanisme protège les deux parties, ce qu’on oublie souvent. Pour le client, il fournit une trace des manquements et évite d’avoir à démontrer plus tard, de mémoire, ce qui avait été promis. Pour l’indépendant, il ferme le projet : une fois les réserves levées, la prestation est acceptée, et les demandes ultérieures relèvent d’une évolution facturable, non d’une correction due. Sans recette formalisée, la frontière entre la correction et la nouvelle fonctionnalité s’efface, et le solde reste impayé au motif que rien n’est jamais tout à fait terminé.

La phase qui suit est la plus longue de la relation, et c’est celle qui a le moins souvent son propre contrat. Un accord de maintenance devrait préciser le périmètre exact des interventions, le traitement des mises à jour de sécurité, la fréquence et la propriété des sauvegardes, les modalités de restitution des accès en fin de relation, et la reconduction de l’acte de sous-traitance des données — puisque c’est précisément pendant la maintenance que le prestataire accède le plus régulièrement aux données réelles des utilisateurs.

Les mentions qu’un devis de site web devrait toujours porter

Rien de tout cela ne suppose un contrat de dix pages. La plupart de ces points tiennent en quelques lignes ajoutées à un devis, et ce sont ces quelques lignes qui séparent une relation qui se termine proprement d’une relation qui se termine devant un tiers.

Aucune de ces clauses n’est une manœuvre défensive contre l’autre partie. Elles décrivent, avant que le projet commence, ce que chacun aura le droit de faire une fois qu’il sera terminé.