Contrat de prestation web : les clauses essentielles pour protéger votre investissement

Introduction

Vous venez de signer un devis avec une agence web pour créer votre site e-commerce. Le devis précise le prix, les fonctionnalités, les délais. Tout semble clair. Vous payez l'acompte de trente pour cent, le projet démarre. Quelques mois plus tard, le site est livré, il fonctionne, vous êtes globalement satisfait. Vous payez le solde. L'histoire devrait se terminer là, non ?

Sauf que six mois après, vous voulez faire évoluer une fonctionnalité. Vous contactez une autre agence pour avoir un devis comparatif. Et là, surprise : cette agence vous explique qu'elle ne peut pas travailler sur votre site parce qu'elle n'a pas accès au code source, et que juridiquement, elle n'a pas le droit de le modifier même si vous lui donnez les accès techniques. Vous contactez votre agence initiale pour comprendre. Ils vous expliquent poliment que le code leur appartient, que vous n'avez qu'une licence d'utilisation, et que toute modification doit passer par eux aux tarifs qu'ils décident. Vous êtes piégé.

Cette situation, je la vois régulièrement. Des entrepreneurs qui découvrent des mois ou des années après la livraison qu'ils ne possèdent pas vraiment leur site. Qu'ils sont dépendants d'un prestataire qui peut les prendre en otage. Qu'ils ont payé des dizaines de milliers d'euros pour un outil dont ils ne sont pas propriétaires. Et le pire, c'est que c'est parfaitement légal si ce n'est pas spécifié autrement dans le contrat.

Dans cet article, je vous explique en langage clair pourquoi un simple devis signé ne suffit jamais à protéger vos intérêts, quelles sont les clauses contractuelles absolument essentielles que vous devez exiger avant de signer quoi que ce soit, et comment vous assurer que vous serez vraiment propriétaire de votre code source et de vos données. Je détaille la clause de cession des droits d'auteur qui est la plus critique, la clause de recette qui vous permet de valider la conformité du livrable, et la clause de réversibilité qui vous protège contre le vendor lock-in. Pas de jargon juridique inutile, juste ce que vous devez absolument comprendre pour protéger votre investissement.

Si vous ne codez pas, c’est précisément le contrat qui devient votre principal outil de contrôle. Vous ne relirez jamais chaque ligne de code, mais vous pouvez très bien exiger une cession de droits complète, une procédure de recette claire, une réversibilité encadrée et des sauvegardes régulières. Pensez ce texte comme un mode d’emploi pour discuter d’égal à égal avec une agence ou un développeur : vous leur laissez la liberté technique, mais dans un cadre juridique précis qui vous garantit que, quoi qu’il arrive, le site et les données restent votre actif, pas le leur.

Pourquoi un devis ne suffit jamais

La différence entre un devis et un contrat

Beaucoup d'entrepreneurs pensent qu'un devis signé constitue un contrat suffisant pour encadrer une prestation web. C'est une erreur dangereuse qui peut vous coûter très cher. Un devis, même accompagné de Conditions Générales de Vente, n'est qu'un document commercial qui décrit les services proposés et leur prix. Il ne couvre généralement pas les aspects juridiques complexes comme la propriété intellectuelle, les garanties, ou les conditions de rupture.

Un vrai contrat de prestation de services, c'est un document juridique complet qui formalise l'accord entre vous et votre prestataire. Il identifie les parties avec précision juridique, détaille l'objet de la prestation et ses limites, définit les obligations réciproques, précise les modalités de paiement et les délais, et surtout, il règle les questions de propriété intellectuelle, de garantie, et de réversibilité. C'est ce document qui aura une valeur probante en cas de litige devant un tribunal.

Le piège classique, c'est quand le prestataire vous envoie un devis avec ses Conditions Générales de Vente en tout petit en bas de page ou dans un PDF séparé. Vous signez le devis sans lire les CGV parce que vous faites confiance, ou parce que c'est écrit en jargon juridique incompréhensible. Et dans ces CGV, il y a des clauses défavorables que vous n'avez pas vues : le prestataire conserve tous les droits sur le code, il n'y a aucune garantie après la livraison, les pénalités de retard ne s'appliquent qu'à vous et pas à lui, etc.

La loi française permet aux professionnels d'imposer leurs CGV dans les relations B2B, à condition qu'elles soient portées à la connaissance du client avant la signature. Le simple fait que les CGV soient mentionnées sur le devis suffit juridiquement pour qu'elles s'appliquent, même si vous ne les avez jamais lues. C'est pour ça que vous ne devez jamais signer un devis sans avoir lu et compris toutes les conditions qui y sont attachées, et sans avoir négocié les clauses qui ne vous conviennent pas.

L'idéal, c'est d'avoir un vrai contrat de prestation détaillé, rédigé en langage clair, qui reprend toutes les clauses essentielles que nous allons détailler dans cet article. Ce contrat doit être signé par les deux parties avant le début des travaux, idéalement avant même le versement de l'acompte. Si votre prestataire refuse de signer un contrat détaillé et prétend qu'un devis suffit, méfiez-vous. Un professionnel sérieux comprend l'importance de sécuriser la relation contractuelle et acceptera de formaliser les choses correctement.

Ce qui doit absolument figurer dans le contrat

Avant même de parler des clauses spécifiques de propriété ou de garantie, votre contrat doit contenir des éléments de base essentiels pour sa validité juridique et son opposabilité en cas de conflit. Ces éléments semblent évidents, mais leur absence ou leur imprécision peut poser de gros problèmes.

L'identification complète des parties contractantes est le premier élément indispensable. Pour vous, client, ça signifie votre dénomination sociale exacte si vous êtes une société, ou vos nom et prénom si vous êtes en entreprise individuelle, votre forme juridique, votre numéro SIRET, votre adresse de siège social complète, et votre numéro de TVA intracommunautaire. Pour le prestataire, les mêmes informations. Cette identification précise permet d'identifier sans ambiguïté qui sont les parties à l'accord, ce qui est crucial si vous devez un jour faire appliquer le contrat devant un tribunal ou en cas de contrôle fiscal.

L'objet du contrat doit être défini avec une clarté absolue. "Création d'un site web" est beaucoup trop vague. Le contrat doit préciser : création d'un site e-commerce sur WooCommerce avec telles et telles fonctionnalités, intégration de tel système de paiement, livraison de tel nombre de pages, formation de tel nombre d'heures, etc. Plus c'est précis, mieux c'est. Et tout aussi important, le contrat doit préciser ce qui n'est pas inclus dans la prestation. Par exemple : "La prestation n'inclut pas la rédaction des contenus textuels, qui restent à la charge du client" ou "La prestation n'inclut pas l'intégration avec l'ERP du client, qui fera l'objet d'un devis séparé si nécessaire".

Les modalités financières doivent être détaillées sans ambiguïté. Le montant total de la prestation hors taxes et toutes taxes comprises. Le calendrier de paiement précis : tant de pour cent d'acompte à la signature, tant de pour cent à telle étape intermédiaire, tant de pour cent à la livraison, solde à la recette définitive. Les délais de règlement, par exemple trente jours après réception de la facture. Les pénalités de retard en cas de non-paiement à la date prévue, généralement le taux légal plus trois points. Et surtout, la procédure en cas de demandes de modifications ou de travaux supplémentaires hors périmètre initial : facturation sur la base d'un tarif journalier ou d'un devis complémentaire, avec accord écrit préalable obligatoire.

Le calendrier prévisionnel du projet avec les grandes étapes et leurs dates est essentiel, même s'il est entendu que ces dates sont indicatives et peuvent être ajustées si nécessaire. Un projet web dépend de nombreux facteurs, dont beaucoup sont de votre côté : la rapidité à laquelle vous fournissez les contenus, validez les maquettes, testez les fonctionnalités. Le contrat ne peut pas imposer des délais absolument rigides, mais il doit définir un cadre temporel réaliste et prévoir les conséquences en cas de retard important imputable à l'une ou l'autre partie.

La clause la plus critique : la cession des droits d'auteur

Pourquoi vous ne possédez pas automatiquement le code

Voici le point juridique que la majorité des entrepreneurs ignorent complètement, et qui peut les ruiner : le code source de votre site web est une œuvre de l'esprit protégée par le droit d'auteur, au même titre qu'un livre, une chanson ou un tableau. Le Code de la propriété intellectuelle français est très clair là-dessus. Et selon ce code, l'auteur d'une œuvre, c'est-à-dire le développeur ou l'agence qui a créé le code, conserve par défaut tous les droits sur cette œuvre.

Le simple fait que vous ayez payé la prestation ne transfère pas automatiquement les droits d'auteur. C'est contre-intuitif, mais c'est la loi. Quand vous payez un développeur pour créer votre site, par défaut, vous n'achetez qu'un droit d'usage de ce site. Vous pouvez l'utiliser pour votre activité commerciale, mais vous ne pouvez pas légalement le modifier vous-même ou faire appel à quelqu'un d'autre pour le modifier sans l'autorisation explicite de l'auteur original. Et vous ne pouvez certainement pas le revendre ou le redistribuer.

Cette règle peut sembler absurde dans le contexte d'un site web créé sur-mesure pour votre entreprise, mais elle existe pour protéger les créateurs dans d'autres contextes. Un graphiste qui crée un logo pour vous conserve ses droits moraux sur cette création. Un photographe qui prend des photos de vos produits conserve les droits sur ces photos. La loi ne fait pas de distinction selon le type d'œuvre ou le contexte commercial. Le principe général est que les droits restent à l'auteur sauf cession explicite.

Il y a une exception importante : si le code a été créé par un salarié dans le cadre de son contrat de travail, les droits patrimoniaux appartiennent automatiquement à l'employeur. C'est l'article L113-9 du Code de la propriété intellectuelle. Mais cette exception ne s'applique qu'aux salariés, pas aux prestataires externes comme les agences web ou les freelances. Si vous travaillez avec un prestataire externe, vous devez absolument avoir une clause de cession des droits dans votre contrat, sinon vous ne possédez rien juridiquement.

Les conséquences pratiques de cette situation sont dramatiques si vous n'avez pas de clause de cession. Vous voulez faire évoluer votre site et changer de prestataire ? Vous devez demander l'autorisation à votre prestataire initial et potentiellement lui payer des droits pour que le nouveau prestataire puisse légalement modifier le code. Votre prestataire initial disparaît ou fait faillite ? Vous êtes techniquement dans l'illégalité si vous modifiez le code ou faites appel à quelqu'un d'autre. Vous voulez vendre votre entreprise avec son site web ? L'acheteur n'acquiert pas les droits sur le code si vous ne les avez pas vous-même. Vous voyez le problème.

Comment rédiger une clause de cession solide

Pour que vous deveniez véritablement propriétaire du code source de votre site, votre contrat doit contenir une clause de cession des droits patrimoniaux explicite et complète. Cette clause doit respecter plusieurs exigences légales pour être valable et opposable.

Premièrement, la cession doit porter sur chacun des droits cédés de manière détaillée. L'article L122-6 du Code de la propriété intellectuelle liste les droits patrimoniaux de l'auteur d'un logiciel. Votre clause de cession doit mentionner explicitement que le prestataire vous cède le droit de reproduire le logiciel de façon permanente ou provisoire, en totalité ou en partie, par tout moyen et sous toute forme. Ça couvre les sauvegardes, les copies sur différents serveurs, etc. Elle doit aussi vous céder le droit de traduire, d'adapter, d'arranger ou d'apporter toute autre modification au logiciel, et d'en reproduire les résultats. C'est la clause la plus importante, celle qui vous permet de faire évoluer votre site en faisant appel à n'importe quel développeur. Et enfin, elle doit vous céder le droit de mettre sur le marché à titre onéreux ou gratuit, y compris la location, du logiciel original ou de copies.

Cette liste peut sembler technique, mais chaque point correspond à un droit spécifique. Si un seul de ces droits n'est pas explicitement cédé, vous ne l'avez pas. J'ai vu des contrats qui cédaient le droit de reproduction mais oubliaient le droit d'adaptation. Résultat : le client pouvait utiliser le site et faire des copies, mais ne pouvait pas légalement le modifier ou le faire modifier sans repasser par le prestataire initial. C'est exactement le piège que vous voulez éviter.

Deuxièmement, la cession doit préciser son étendue géographique et sa durée. Pour un site web commercial, vous voulez une cession mondiale et illimitée dans le temps. "Le Prestataire cède au Client les droits patrimoniaux mentionnés ci-dessus pour le monde entier et pour toute la durée de protection des droits d'auteur." Si la durée n'est pas précisée, la cession est limitée à cinq ans par défaut selon la jurisprudence. Vous ne voulez pas devoir renégocier vos droits tous les cinq ans.

Troisièmement, la cession doit être à titre exclusif ou non exclusif selon vos besoins. Une cession exclusive signifie que le prestataire ne peut plus utiliser ce code pour personne d'autre. Une cession non exclusive signifie qu'il peut réutiliser tout ou partie du code pour d'autres clients. Pour un site créé spécifiquement pour vous, la cession devrait généralement être exclusive pour le code sur-mesure. Par contre, pour les composants génériques ou les extensions tierces, la cession sera nécessairement non exclusive puisque ces éléments peuvent être réutilisés légalement par tout le monde.

Enfin, le contrat doit préciser que la cession est définitive et ne peut être révoquée, sauf manquement grave de votre part comme le non-paiement. Vous ne voulez pas qu'un prestataire mécontent puisse révoquer la cession des droits parce que vous avez écrit un avis négatif sur lui ou parce que vous êtes parti chez un concurrent. La cession doit être acquise définitivement dès le paiement intégral de la prestation.

Voici un exemple de rédaction de clause de cession solide, en langage clair : "Le Prestataire cède au Client, à titre exclusif pour le code développé spécifiquement pour le présent projet, l'intégralité des droits patrimoniaux sur le code source du site web, incluant notamment les droits de reproduction permanente ou provisoire du logiciel en totalité ou en partie par tout moyen et sous toute forme, les droits de traduction, d'adaptation, d'arrangement ou de toute autre modification du logiciel et de reproduction des résultats, et les droits de mise sur le marché du logiciel original ou de copies. Cette cession est consentie pour le monde entier et pour toute la durée de protection des droits d'auteur. Elle prend effet dès le paiement intégral du prix de la prestation et est irrévocable."

Le cas particulier des composants tiers et open-source

Un point important à comprendre, c'est que votre site web n'est jamais composé uniquement de code écrit spécifiquement pour vous. Il incorpore nécessairement des composants tiers : le CMS lui-même comme WordPress, les extensions et plugins, les bibliothèques de code open-source, les frameworks, etc. Ces composants ont leurs propres licences que ni vous ni votre prestataire ne pouvez modifier.

Pour ces éléments, la clause de cession ne s'applique pas parce que votre prestataire n'en est pas l'auteur et ne peut donc pas vous en céder les droits. Par contre, le contrat doit préciser que le prestataire vous garantit avoir respecté toutes les licences de ces composants tiers, et que vous avez le droit d'utiliser ces composants dans le cadre de l'exploitation de votre site. C'est une garantie contre le risque que votre prestataire ait utilisé du code propriétaire sans licence valable, ce qui vous exposerait à des poursuites.

Pour les logiciels open-source comme WordPress ou les plugins gratuits, les licences sont généralement très permissives. La licence GPL de WordPress vous autorise à utiliser, modifier, et redistribuer le code librement. Vous n'avez pas besoin qu'on vous cède des droits sur WordPress, vous les avez déjà via la licence GPL. Le problème ne se pose que pour le code personnalisé développé spécifiquement pour votre projet, c'est là que la clause de cession est absolument indispensable.

Le contrat devrait contenir une clause de garantie qui dit quelque chose comme : "Le Prestataire garantit au Client qu'il détient l'intégralité des droits de propriété intellectuelle sur le code développé spécifiquement pour le présent projet, ou qu'il dispose des autorisations nécessaires pour les composants tiers utilisés. Le Prestataire garantit que l'utilisation du site par le Client ne portera pas atteinte aux droits de propriété intellectuelle de tiers. Le Prestataire s'engage à garantir et indemniser le Client contre toute action, réclamation ou poursuite d'un tiers à ce titre."

Cette garantie vous protège. Si un an après la livraison, un éditeur de logiciel vous poursuit parce que votre prestataire a utilisé son code propriétaire sans licence, vous pouvez vous retourner contre votre prestataire sur la base de cette clause de garantie. C'est lui qui devra assumer les conséquences financières et juridiques de son manquement, pas vous.

La clause de recette : validez avant de payer le solde

Qu'est-ce que la recette et pourquoi c'est essentiel

La clause de recette, c'est le mécanisme contractuel qui vous permet de vérifier que le site livré correspond bien à ce qui était prévu dans le cahier des charges avant de valider définitivement le travail et de payer le solde. C'est votre protection contre les livraisons non conformes ou de mauvaise qualité. Sans clause de recette, vous êtes coincé : soit vous acceptez le site même s'il ne correspond pas exactement à ce que vous attendiez, soit vous refusez de payer et vous rentrez en conflit avec votre prestataire.

Le principe de la recette, c'est qu'il y a une période de test après la livraison pendant laquelle vous vérifiez minutieusement que tout fonctionne comme prévu. Vous testez toutes les fonctionnalités, vous vérifiez que le design correspond aux maquettes validées, vous contrôlez que les performances sont correctes, vous essayez de casser le site en faisant des actions inhabituelles. Si vous découvrez des problèmes, vous les signalez au prestataire qui doit les corriger. Ce n'est qu'une fois que tous les problèmes bloquants sont résolus que vous acceptez définitivement le livrable et payez le solde.

La recette protège les deux parties. Elle vous protège en vous donnant le temps de vérifier avant de payer définitivement. Elle protège le prestataire en définissant clairement ce qui doit être vérifié et comment, évitant ainsi les contestations floues après plusieurs mois d'utilisation. Un bon prestataire est favorable à une clause de recette précise parce qu'elle cadre la relation et limite les risques de litiges interminables.

La procédure de recette se déroule généralement en deux étapes. D'abord, la recette provisoire, aussi appelée recette technique ou phase de tests. Le prestataire livre le site en version de préproduction ou sur un environnement de staging. Vous avez un délai défini, généralement entre une et trois semaines selon la complexité du projet, pour tester exhaustivement et signaler tous les problèmes que vous identifiez. Le prestataire corrige les anomalies relevées. Cette phase peut s'itérer plusieurs fois jusqu'à ce qu'il n'y ait plus d'anomalies bloquantes.

Ensuite, la recette définitive, aussi appelée recette fonctionnelle ou validation finale. Une fois que tous les problèmes majeurs ont été corrigés, vous validez définitivement le livrable par écrit, généralement par email ou par la signature d'un procès-verbal de recette. Cette acceptation déclenche le paiement du solde et marque le début de la période de garantie. À partir de ce moment, vous ne pouvez plus contester le travail livré sauf pour des vices cachés, c'est-à-dire des défauts qui n'étaient pas détectables pendant la phase de recette et qui rendent le site impropre à l'usage prévu.

Ce que doit contenir votre clause de recette

Pour être efficace et éviter les ambiguïtés, votre clause de recette doit définir précisément plusieurs éléments. D'abord, les critères d'acceptation, c'est-à-dire ce qui doit être vérifié et quel est le niveau de qualité acceptable. Ces critères doivent être objectifs et mesurables autant que possible. Par exemple : "Toutes les fonctionnalités décrites dans le cahier des charges doivent être opérationnelles", "Le site doit s'afficher correctement sur les navigateurs Chrome, Firefox, Safari et Edge dans leurs deux dernières versions", "Le temps de chargement de la page d'accueil doit être inférieur à trois secondes en conditions normales", "Le site doit être responsive et fonctionnel sur mobile, tablette et desktop".

Ensuite, la durée de la période de recette provisoire. Pour un site vitrine simple, une semaine peut suffire. Pour un site e-commerce avec plusieurs centaines de produits et des processus de commande complexes, prévoyez plutôt deux à trois semaines. Cette durée doit être réaliste en fonction de votre disponibilité. Si vous savez que vous n'aurez pas le temps de tester sérieusement avant trois semaines, dites-le dès le départ et négociez une durée de recette adaptée. Ne vous engagez pas sur une semaine si vous savez que vous ne pourrez pas tenir.

La procédure de signalement des anomalies doit être définie. Comment devez-vous signaler les problèmes ? Par email avec une liste détaillée ? Via un outil de gestion de projet comme Trello ou Asana ? Quelles informations devez-vous fournir pour chaque anomalie ? Description du problème, étapes pour le reproduire, captures d'écran ou vidéos ? Plus cette procédure est claire, moins il y aura de malentendus et plus les corrections seront efficaces.

Le classement des anomalies par niveau de gravité est également important. Les anomalies bloquantes sont celles qui empêchent l'utilisation du site ou d'une fonctionnalité essentielle, par exemple le paiement ne fonctionne pas ou le site est complètement cassé sur mobile. Ces anomalies doivent être corrigées avant la recette définitive, c'est non négociable. Les anomalies majeures sont des problèmes significatifs mais qui n'empêchent pas l'utilisation, par exemple un dysfonctionnement sur une fonctionnalité secondaire ou un problème d'affichage sur un navigateur peu utilisé. Le contrat doit préciser si ces anomalies doivent être corrigées avant la recette définitive ou si elles peuvent être traitées pendant la période de garantie. Les anomalies mineures sont des détails cosmétiques ou des améliorations souhaitables mais non critiques. Elles peuvent généralement être traitées après la recette définitive, voire pas du tout si elles sortent du périmètre initial.

Enfin, les délais de correction par le prestataire doivent être spécifiés. Par exemple : "Le Prestataire s'engage à corriger toute anomalie bloquante dans un délai de quarante-huit heures ouvrées à compter de sa notification. Les anomalies majeures seront corrigées dans un délai de cinq jours ouvrés. Les anomalies mineures seront traitées dans la mesure du possible avant la recette définitive, ou reportées à la période de garantie si leur correction nécessite des développements non prévus au cahier des charges initial."

Ce qui se passe si le prestataire ne corrige pas les anomalies dans les délais doit aussi être prévu. Généralement, le client peut soit prolonger la période de recette jusqu'à correction, soit accepter le livrable avec des réserves et demander un avoir ou une réduction de prix proportionnelle à la gravité des défauts non corrigés, soit dans les cas extrêmes, refuser définitivement le livrable et demander le remboursement des sommes versées si les anomalies sont si graves que le site est inutilisable pour son usage prévu.

| Élément de la clause de recette | Ce qu'il doit contenir | Pourquoi c'est important | |--------------------------------|----------------------|-------------------------| | Critères d'acceptation | Liste objective et mesurable des points à vérifier (fonctionnalités, compatibilité, performance) | Définit clairement ce qui est acceptable et évite les contestations subjectives | | Durée de recette provisoire | Nombre de jours ouvrés pour tester (7 à 21 jours selon complexité) | Vous donne le temps nécessaire pour tester sérieusement sans bloquer le projet indéfiniment | | Procédure de signalement | Comment et où signaler les problèmes, quelles informations fournir | Assure une communication efficace et des corrections rapides | | Classification anomalies | Bloquante / Majeure / Mineure avec critères de distinction | Priorise les corrections et détermine ce qui doit être fait avant la recette définitive | | Délais de correction | Nombre de jours pour corriger selon la gravité | Évite que le prestataire ne traîne indéfiniment sur les corrections | | Conséquences du non-respect | Prolongation recette, réduction prix, ou refus livrable selon gravité | Donne un levier contractuel si le prestataire ne fait pas son travail correctement |

La clause de réversibilité : évitez le vendor lock-in

Le piège de la dépendance au fournisseur

Le vendor lock-in, qu'on peut traduire par dépendance au fournisseur ou enfermement propriétaire, c'est la situation où vous êtes captif de votre prestataire actuel et où vous ne pouvez pas changer facilement même si vous le voulez. C'est un risque stratégique majeur pour votre entreprise, et c'est malheureusement très courant dans le domaine du web.

Le vendor lock-in peut prendre plusieurs formes. La forme technique, c'est quand votre site utilise des technologies propriétaires ou tellement spécifiques qu'il est quasiment impossible de le faire évoluer sans le prestataire initial. Par exemple, un CMS développé spécifiquement par l'agence dont personne d'autre ne connaît le code. La forme contractuelle, c'est quand vous n'avez pas les droits sur votre code source, comme nous l'avons vu dans la section sur la cession des droits. La forme pratique, c'est quand vous n'avez pas accès à vos données dans un format exploitable, ou quand le transfert vers un autre prestataire est techniquement possible mais tellement complexe et coûteux qu'il devient dissuasif.

Les conséquences du vendor lock-in sont graves. Vous n'avez plus de pouvoir de négociation avec votre prestataire. Il peut augmenter ses tarifs de maintenance comme il veut, vous n'avez pas d'alternative. Il peut prendre des semaines pour répondre à vos demandes, vous ne pouvez pas aller voir ailleurs. Si le prestataire fait faillite ou décide d'arrêter son activité web, vous pouvez perdre complètement l'accès à votre site et à vos données. Si vous voulez vendre votre entreprise, l'acheteur sera très méfiant d'hériter d'une dépendance vis-à-vis d'un prestataire spécifique, ça peut faire baisser la valeur de votre entreprise.

La clause de réversibilité, c'est votre protection contractuelle contre ce risque. Elle garantit que vous pourrez récupérer l'intégralité de vos actifs numériques et les transférer à un autre prestataire de votre choix, ou les gérer vous-même, à la fin de la relation contractuelle ou à n'importe quel moment si vous le décidez. C'est votre porte de sortie. Sans cette clause, vous êtes à la merci de votre prestataire.

Ce que doit garantir votre clause de réversibilité

Une clause de réversibilité complète et efficace doit couvrir quatre aspects essentiels : le périmètre de ce qui doit être restitué, le format dans lequel les données et le code doivent être livrés, les délais de transfert, et les coûts associés. Chacun de ces points doit être négocié et précisé contractuellement avant le début du projet.

Le périmètre de la réversibilité doit lister exhaustivement tous les actifs numériques qui vous seront restitués. Ça inclut évidemment le code source complet de votre site, avec tous les fichiers, y compris les fichiers de configuration, les scripts, les templates, etc. Pas juste le code PHP ou JavaScript, mais aussi tous les fichiers CSS, les images, les polices, les documents, absolument tout. Le code doit être fourni dans sa version la plus récente et fonctionnelle, avec tous les commentaires et la documentation technique nécessaire pour qu'un autre développeur puisse reprendre le travail.

Ça inclut aussi toutes les bases de données complètes, pas seulement un export partiel. La base de données des produits avec toutes les informations, descriptions, prix, stocks. La base de données des clients avec toutes leurs données personnelles. La base de données des commandes avec tout l'historique. Toutes les données doivent être exportées dans un format standard et exploitable, généralement du SQL pour les structures de base de données et du CSV pour les données tabulaires.

Le périmètre doit aussi inclure tous les documents de conception et de documentation technique produits pendant le projet. Les maquettes graphiques dans leurs fichiers sources modifiables, généralement des fichiers Figma, Adobe XD ou Photoshop. Le cahier des charges détaillé avec toutes les spécifications fonctionnelles et techniques. La documentation technique du code, si elle existe. Les identifiants et mots de passe de tous les comptes et services tiers utilisés par le site : hébergement, nom de domaine, CDN, services de paiement, outils d'emailing, etc.

Enfin, si vous utilisez des licences de logiciels ou d'extensions payantes, le contrat doit préciser ce qui se passe avec ces licences. Soit elles sont à votre nom depuis le début et vous les conservez, soit elles sont au nom du prestataire et il doit vous les transférer ou vous aider à en acquérir de nouvelles. Ça doit être clair pour éviter de découvrir six mois après la rupture que votre site ne fonctionne plus parce qu'une licence critique a expiré.

Le format de restitution des données est crucial. Vos données doivent être livrées dans des formats ouverts, standards, documentés et non propriétaires, qui peuvent être importés facilement dans n'importe quel système. Du SQL pour les bases de données, du CSV pour les fichiers de données tabulaires, du JSON ou du XML pour les données structurées. Pas de formats propriétaires qu'un seul logiciel spécifique peut lire. Le code source doit être lisible et commenté, pas obfusqué ou minifié d'une façon qui le rend incompréhensible pour un humain.

Les délais de transfert doivent être définis et courts. Vous ne voulez pas attendre trois mois pour récupérer vos données si vous décidez de changer de prestataire. Un délai raisonnable pour la restitution complète des actifs est généralement entre quinze jours et un mois maximum à compter de votre demande formelle. Pour les données critiques comme la base de données clients, vous devriez pouvoir les obtenir dans les quarante-huit heures en cas d'urgence.

Les coûts de la réversibilité doivent être prévus et plafonnés contractuellement. Certains prestataires essaient de facturer très cher la restitution des données pour dissuader leurs clients de partir. C'est inacceptable. Le coût de la réversibilité doit être soit inclus dans la prestation initiale sans supplément, soit facturé sur une base forfaitaire raisonnable, par exemple entre cinq cents et deux mille euros selon la complexité, ou sur une base de tarif journalier plafonné à un nombre maximal de jours. Le contrat doit interdire explicitement au prestataire de facturer la réversibilité de manière excessive pour décourager le client.

Enfin, la clause de réversibilité doit préciser que le prestataire s'engage à vous assister, ou assister le nouveau prestataire que vous aurez désigné, pendant la phase de transfert pour répondre aux questions techniques et faciliter la reprise. Cette assistance peut être limitée dans le temps, par exemple dix heures d'assistance technique comprises, mais elle est essentielle pour éviter que le transfert ne se transforme en cauchemar technique.

Le lien entre réversibilité et sauvegardes

Une clause de réversibilité n'a de valeur que si les éléments à restituer existent réellement et sont maintenus à jour. C'est là qu'intervient la question des sauvegardes. Votre contrat doit imposer au prestataire, pendant toute la durée de votre relation commerciale, de réaliser des sauvegardes régulières et complètes de votre site et de vos données.

Ces sauvegardes doivent inclure tous les fichiers du site et toutes les bases de données. Elles doivent être effectuées à une fréquence adaptée à votre activité, généralement au minimum hebdomadaire pour un site vitrine et quotidienne pour un site e-commerce. Et surtout, ces sauvegardes doivent être stockées sur un support distinct et idéalement dans un lieu géographique différent de votre serveur de production, pour éviter qu'une défaillance du serveur principal ne détruise aussi les sauvegardes.

Le contrat devrait stipuler que vous pouvez demander à tout moment une copie des sauvegardes récentes, et que le prestataire doit vous la fournir dans les quarante-huit heures. Ça vous permet de vérifier que les sauvegardes sont bien faites et que vous pourrez effectivement récupérer vos données si nécessaire. Ça permet aussi de préparer sereinement une migration vers un autre prestataire en ayant déjà une copie à jour de tout.

Si le prestataire gère votre hébergement, le contrat doit préciser ce qui se passe avec vos données en cas de résiliation. Vous devez avoir un délai raisonnable, généralement au moins trente jours après la fin du contrat, pendant lequel vos données restent accessibles sur le serveur pour faciliter le transfert vers votre nouvel hébergement. Le prestataire ne peut pas supprimer vos données le lendemain de la résiliation du contrat. Et il doit vous fournir la dernière sauvegarde complète avant de supprimer définitivement vos données de ses serveurs.

Les autres clauses essentielles pour sécuriser votre investissement

La garantie contre les vices et malfaçons

Au-delà de la recette qui valide la conformité initiale, votre contrat doit prévoir une période de garantie après la livraison définitive. Cette garantie couvre les bugs, les dysfonctionnements et les malfaçons qui n'étaient pas détectables pendant la phase de recette et qui apparaissent pendant l'utilisation normale du site.

Il faut distinguer la garantie légale de conformité, qui existe automatiquement par la loi et qui dure deux ans en France pour les biens, et la garantie contractuelle que vous négociez spécifiquement avec votre prestataire. Pour les prestations de services web, la garantie légale s'applique de manière moins évidente que pour l'achat d'un bien physique, d'où l'importance de prévoir une garantie contractuelle claire.

Une garantie contractuelle standard pour un site web couvre généralement entre trois mois et un an après la recette définitive. Pendant cette période, le prestataire s'engage à corriger gratuitement tous les bugs et dysfonctionnements qui apparaissent, à condition qu'ils ne soient pas dus à une mauvaise utilisation de votre part ou à des modifications que vous auriez faites vous-même ou fait faire par un tiers.

La garantie doit définir ce qui est couvert et ce qui ne l'est pas. Elle couvre typiquement les bugs dans le code développé spécifiquement pour vous, les problèmes de sécurité liés à des vulnérabilités dans le code custom, les dysfonctionnements des fonctionnalités livrées. Elle ne couvre généralement pas les problèmes liés aux extensions tierces ou aux évolutions de ces extensions que vous installez après la livraison, les problèmes liés à votre hébergement ou votre infrastructure, ou les nouvelles fonctionnalités que vous demandez après la livraison et qui n'étaient pas prévues au cahier des charges initial.

Le contrat doit aussi préciser les délais d'intervention du prestataire pendant la période de garantie. Par exemple : "Le Prestataire s'engage à répondre à toute demande d'intervention au titre de la garantie dans un délai de quarante-huit heures ouvrées, et à corriger tout bug bloquant dans un délai de cinq jours ouvrés maximum à compter de sa reproduction par le Prestataire." Ces délais donnent un cadre et évitent que le prestataire ne traîne pendant des semaines pour corriger un problème critique.

Les clauses financières : acompte, jalons, paiement final

Les modalités de paiement doivent être structurées de manière équilibrée pour protéger à la fois vous et le prestataire. Le paiement en plusieurs fois avec des jalons liés à l'avancement du projet est la norme dans l'industrie web et le modèle le plus sain pour les deux parties.

Le schéma classique est un acompte de trente à quarante pour cent à la signature du contrat ou au démarrage effectif des travaux. Cet acompte engage les deux parties et permet au prestataire de commencer à travailler avec un minimum de sécurité financière. Ensuite, un ou plusieurs paiements intermédiaires liés à des jalons de projet : par exemple trente pour cent à la validation des maquettes et de l'architecture, ou trente pour cent à la livraison de la version bêta. Enfin, le solde de trente à quarante pour cent à la recette définitive, c'est-à-dire après validation complète du livrable.

Ne payez jamais cent pour cent du montant avant la livraison et la validation. C'est le meilleur moyen de vous retrouver sans recours si le prestataire fait un travail bâclé ou disparaît avant la fin. Garder au minimum vingt à trente pour cent du montant total jusqu'à la recette définitive vous donne un levier pour vous assurer que les éventuels problèmes seront corrigés.

À l'inverse, ne cherchez pas à payer le moins possible à l'avance et tout à la fin. Un prestataire qui doit financer votre projet sur sa trésorerie pendant des mois prend un risque financier qui ne le motivera pas à faire son meilleur travail. Le partage du risque financier doit être équilibré et proportionné à l'avancement du projet.

Le contrat doit aussi prévoir comment sont gérés les travaux supplémentaires qui ne faisaient pas partie du périmètre initial. La règle doit être claire : tout travail hors périmètre nécessite votre accord écrit préalable sur le principe, le délai et le coût avant d'être réalisé. Le prestataire ne peut pas vous présenter une facture surprise pour des travaux non validés, même s'il estime qu'ils étaient nécessaires. Et de votre côté, vous ne pouvez pas exiger des travaux supplémentaires sans accepter qu'ils soient facturés en sus.

La durée du contrat et les conditions de résiliation

Votre contrat doit préciser s'il s'agit d'un contrat à durée déterminée pour la réalisation du projet uniquement, ou d'un contrat qui inclut une période de maintenance continue après la livraison. Ces deux types de contrats n'ont pas les mêmes règles de résiliation.

Pour un contrat de réalisation à durée déterminée, la résiliation anticipée doit être possible mais encadrée. Le contrat doit prévoir les cas de résiliation légitime : par exemple, en cas de manquement grave d'une des parties à ses obligations après mise en demeure restée sans effet, en cas de force majeure, ou de commun accord entre les parties. Il doit aussi préciser les conséquences financières de la résiliation : remboursement de l'acompte si le prestataire n'a pas commencé les travaux, paiement au prorata des travaux effectivement réalisés et validés si le projet est en cours, etc.

Pour un contrat de maintenance récurrent, la résiliation doit être possible moyennant un préavis raisonnable, généralement un à trois mois. Vous ne voulez pas être bloqué dans un contrat de maintenance avec un prestataire dont vous n'êtes plus satisfait. Le contrat doit préciser que la résiliation doit être notifiée par lettre recommandée avec accusé de réception, que le préavis court à partir de la réception de cette lettre, et que vous restez redevable des paiements jusqu'à la fin du préavis mais plus au-delà.

Le contrat doit explicitement prévoir que la résiliation, quelle qu'en soit la cause, ne remet pas en cause votre droit à la cession des droits d'auteur pour les travaux déjà payés, ni votre droit à récupérer vos données et votre code via la clause de réversibilité. Un prestataire ne peut pas garder votre code en otage parce que vous avez résilié le contrat de maintenance. Ce que vous avez payé vous appartient, point final.

Verdict : ne signez jamais sans ces clauses

Créer un site web, que ce soit un site vitrine ou un e-commerce, représente un investissement significatif pour une TPE ou PME. Entre cinq mille et trente mille euros selon la complexité, sans compter les coûts récurrents de maintenance et d'hébergement. Cet investissement ne se justifie que si vous en êtes vraiment propriétaire et si vous pouvez en disposer librement pour faire évoluer votre business.

Un contrat de prestation web solide et équilibré est votre seule protection pour sécuriser cet investissement. Un simple devis signé ne suffit jamais. Les Conditions Générales de Vente standard des prestataires sont presque toujours rédigées en leur faveur et ne protègent pas suffisamment vos intérêts. Vous devez exiger un vrai contrat détaillé qui couvre au minimum les cinq clauses essentielles que nous avons détaillées dans cet article.

La clause de cession des droits d'auteur est la plus critique. Sans elle, vous n'êtes pas propriétaire de votre code et vous êtes juridiquement dépendant de votre prestataire initial pour toute modification. Cette clause doit être explicite, détaillée, et couvrir tous les droits patrimoniaux listés dans l'article L122-6 du Code de la propriété intellectuelle. Elle doit être mondiale, illimitée dans le temps, et irrévocable dès le paiement intégral. Ne signez jamais un contrat qui ne contient pas cette clause de cession complète.

La clause de recette vous protège contre les livraisons non conformes en vous donnant le temps de tester avant de payer le solde et de valider définitivement. La clause de réversibilité vous protège contre le vendor lock-in en garantissant que vous pourrez récupérer tous vos actifs numériques dans des formats exploitables si vous voulez changer de prestataire. La clause de garantie vous assure que les bugs découverts après la livraison seront corrigés gratuitement pendant une période raisonnable. Et les clauses financières équilibrées protègent à la fois vous et le prestataire en répartissant le risque de manière proportionnée à l'avancement du projet.

Si un prestataire refuse de signer un contrat contenant ces clauses, ou essaie de les diluer avec des formulations vagues qui ne vous protègent pas réellement, considérez ça comme un signal d'alarme majeur. Un professionnel sérieux et honnête comprend l'importance de ces protections contractuelles et acceptera de les formaliser. Celui qui refuse a probablement l'intention de vous enfermer dans une dépendance ou de ne pas assumer ses responsabilités en cas de problème.

Le coût de la rédaction ou de la révision d'un contrat par un avocat spécialisé en propriété intellectuelle et en droit du numérique se situe généralement entre cinq cents et deux mille euros. C'est dérisoire comparé au coût de votre projet web et aux pertes potentielles si vous vous retrouvez sans protection contractuelle. Considérez ça comme une assurance indispensable. Vous ne construiriez pas un bâtiment sans assurance, ne créez pas un site web sans protection juridique.

Prochaines étapes : faites réviser votre contrat

Si vous êtes en phase de sélection de prestataire pour un projet web, la première action à entreprendre est d'exiger de voir le modèle de contrat qu'ils utilisent avant même de demander un devis détaillé. Lisez-le attentivement. Vérifiez que les cinq clauses essentielles que nous avons détaillées sont présentes et correctement rédigées. Si elles sont absentes ou trop vagues, demandez explicitement qu'elles soient ajoutées. Comparez les contrats de plusieurs prestataires, c'est un critère de sélection aussi important que le prix ou les références.

Si vous avez déjà signé un contrat avec un prestataire et que vous réalisez maintenant qu'il ne contient pas ces clauses protectrices, vous avez deux options. Si le projet n'est pas encore terminé et que vous n'avez pas encore payé le solde, vous pouvez essayer de négocier un avenant au contrat pour ajouter les clauses manquantes, notamment la cession des droits et la réversibilité. Le prestataire aura plus de motivation à accepter puisque vous n'avez pas encore tout payé. Si le projet est terminé et entièrement payé, vous êtes dans une position plus faible, mais vous pouvez quand même proposer un avenant pour formaliser ces points pour l'avenir, particulièrement si vous envisagez de faire évoluer le site.

Pour comprendre les aspects techniques de la propriété de votre site au-delà des aspects juridiques, relisez notre article sur la transformation d'un site vitrine en e-commerce qui détaille l'importance de contrôler vos accès techniques : administrateur CMS, SFTP, base de données, et nom de domaine. La propriété juridique via la cession des droits n'a de valeur que si vous avez aussi le contrôle technique effectif de vos actifs.

Si vous avez des questions juridiques spécifiques sur votre situation contractuelle, nous vous recommandons de consulter un avocat spécialisé en propriété intellectuelle et en droit du numérique. L'ordre des avocats de votre région peut vous orienter vers des spécialistes. Une consultation d'une heure coûte généralement entre deux cents et quatre cents euros et peut vous éviter des erreurs à plusieurs dizaines de milliers d'euros.

FAQ : vos questions sur les contrats de prestation web

Est-ce que les Conditions Générales de Vente du prestataire suffisent à me protéger ?

Non, les CGV standard d'un prestataire sont presque toujours rédigées en sa faveur, pas en la vôtre. Elles contiennent généralement des clauses qui limitent sa responsabilité, qui vous imposent des obligations strictes sans réciprocité, et qui souvent ne prévoient pas la cession complète des droits d'auteur. Les CGV sont un point de départ pour la négociation, pas un document que vous devez accepter aveuglément. Vous avez le droit de négocier et de demander des modifications. Un prestataire qui refuse toute discussion sur ses CGV et qui vous impose un contrat à prendre ou à laisser ne respecte pas votre position de client. Dans une relation B2B équilibrée, les conditions contractuelles se négocient pour protéger équitablement les deux parties.

Comment savoir si la clause de cession de droits dans mon contrat est complète ?

Vérifiez qu'elle mentionne explicitement les trois droits patrimoniaux de l'article L122-6 du Code de la propriété intellectuelle : le droit de reproduction, le droit d'adaptation et de modification, et le droit de distribution. Si la clause dit juste "le client obtient les droits d'utilisation" sans détailler ces trois droits spécifiques, ce n'est pas suffisant. La cession doit aussi préciser qu'elle est mondiale, illimitée dans le temps, et irrévocable. Si un seul de ces éléments manque, vous n'avez pas une protection complète. En cas de doute, faites relire votre contrat par un avocat spécialisé avant de signer. Les cinq cents euros de consultation peuvent vous éviter des dizaines de milliers d'euros de problèmes futurs.

Mon prestataire me dit qu'il ne peut pas me céder les droits sur le code WordPress ou WooCommerce, est-ce normal ?

Oui, c'est normal et même logique. WordPress et WooCommerce sont des logiciels open-source dont votre prestataire n'est pas l'auteur. Il ne peut donc pas vous en céder les droits puisqu'il ne les possède pas lui-même. Ces logiciels sont déjà distribués sous licence GPL qui vous autorise à les utiliser, les modifier et les redistribuer librement. Vous n'avez pas besoin qu'on vous cède des droits que vous avez déjà via la licence open-source. Par contre, votre prestataire doit obligatoirement vous céder les droits sur tout le code qu'il a développé spécifiquement pour vous : les thèmes custom, les plugins custom, les fonctionnalités sur-mesure, les intégrations spécifiques. C'est sur cette partie là que la clause de cession doit porter, et c'est souvent la partie la plus importante et la plus coûteuse de votre projet.

Que se passe-t-il si mon prestataire fait faillite ou disparaît avant la fin du projet ?

C'est un risque réel, surtout avec les freelances ou les petites agences. Si vous n'avez pas de clause de réversibilité et de cession des droits, vous pouvez tout perdre. C'est pour ça qu'il est essentiel d'exiger des sauvegardes régulières pendant le projet et de demander à recevoir une copie de l'état actuel du code à chaque jalon de paiement. Si le prestataire disparaît, vous aurez au moins la dernière version du code à laquelle vous avez eu accès. Pour vous protéger davantage, vous pouvez demander que le code soit versé régulièrement dans un système d'archivage sécurisé tiers, qu'on appelle un séquestre logiciel ou code escrow, mais c'est généralement réservé aux gros projets. Pour les projets de moins de cinquante mille euros, la solution pratique est d'avoir des copies régulières du code et la cession des droits formalisée dès le début du projet, pas à la fin.

Est-ce que je peux utiliser un modèle de contrat trouvé sur internet ?

Vous pouvez vous en inspirer, mais ne l'utilisez jamais tel quel sans l'adapter à votre situation spécifique et sans le faire relire par un professionnel du droit. Les modèles de contrats génériques sont souvent incomplets, obsolètes, ou inadaptés au droit français. De plus, chaque projet web a ses spécificités qui nécessitent des clauses adaptées. Un contrat pour un site vitrine simple n'est pas le même qu'un contrat pour un e-commerce complexe avec des intégrations sur-mesure. L'investissement dans la rédaction ou la révision d'un contrat sur-mesure par un avocat spécialisé est toujours rentable. Vous payez entre cinq cents et deux mille euros pour avoir un document solide qui protège réellement vos intérêts, plutôt que de vous retrouver avec un contrat générique qui ne vous protège pas en cas de problème réel.

Mon prestataire veut me facturer très cher la réversibilité, est-ce légal ?

C'est légal si c'est prévu dans le contrat que vous avez signé, mais c'est une pratique abusive que vous devez refuser. La réversibilité ne devrait pas coûter plus cher que le temps réel nécessaire pour extraire et formater vos données, généralement entre une demi-journée et deux jours de travail selon la complexité. Si un prestataire essaie de vous facturer plusieurs milliers d'euros pour la réversibilité, c'est qu'il utilise cette clause comme un moyen de dissuasion pour vous empêcher de partir. C'est exactement le vendor lock-in contre lequel la clause de réversibilité est censée vous protéger. Négociez dès le début du projet, dans le contrat initial, que la réversibilité sera soit incluse sans surcoût, soit facturée sur une base forfaitaire raisonnable plafonnée. Une fois que le projet est terminé et que vous voulez partir, vous avez beaucoup moins de pouvoir de négociation. Anticipez ce point dès la signature du contrat.

Vous voulez un site vitrine statique avec un contrat clair et sans dépendance cachée ?

Si vous souhaitez :

• un site vitrine statique où la cession de droits, la recette, la réversibilité et les sauvegardes sont cadrées dès le départ,
• un prestataire qui vous explique clairement ce que vous possédez (code, contenus, accès) et comment changer de prestataire le jour où vous le voulez,
• et un devis compréhensible qui inclut ces éléments sans clauses pièges,

c’est exactement le cadre dans lequel je travaille avec des TPE, professions libérales et petites PME.

• Découvrir la façon dont je travaille : /services
• Voir les forfaits et prix 2025 : /tarifs-2025
• Me parler de votre projet : /contact