Qui est propriétaire de mon site web ?

Qui est propriétaire de votre site web ? En principe vous, en tant que client qui le paie, mais dans la pratique cela dépend entièrement de ce qui a été fixé au contrat et du nom sous lequel les comptes sont enregistrés. Un site web n’est en effet pas un bien unique, mais un ensemble d’éléments distincts, et chacun peut se retrouver chez une autre partie ou dans un autre compte. Dans cet article, vous découvrez quels sont ces éléments, où naît le lock-in et ce que vous devez précisément sécuriser pour rester libre de déménager, de renouveler ou de changer de prestataire.

C’est délibérément un récit sobre et pratique. Non pas parce que la plupart des agences ont de mauvaises intentions, mais parce qu’une propriété que personne ne règle explicitement se retrouve souvent par accident au mauvais nom. Et vous ne le remarquez qu’au pire moment possible : quand vous voulez partir. Si vous voulez le tableau plus large autour d’une construction professionnelle, lisez notre guide pour faire créer un site web B2B ; la propriété en est un volet à part entière.

Que signifie réellement “être propriétaire de votre site web” ?

Être propriétaire de votre site web signifie que vous pouvez accéder, sans l’autorisation d’un tiers, à chaque élément nécessaire pour faire tourner le site, le modifier ou le déménager. Ce n’est donc pas une question à réponse unique. Un site web se compose d’au moins cinq couches distinctes, et la propriété doit s’examiner couche par couche :

Le nom de domaine. L’adresse à laquelle on vous trouve, ainsi que les réglages DNS associés.
Le code source et les fichiers de design. Le HTML, le CSS et l’éventuel code sur mesure, ou le fichier de projet dans une plateforme comme Webflow ou WordPress.
Le contenu et la structure du CMS. Vos textes, vos images, vos pages et la manière dont ils sont construits.
L’hébergement. Les serveurs ou l’abonnement à la plateforme sur lesquels le site est en ligne.
Les comptes liés. Analytics, Search Console, e-mail, outils de formulaires et de marketing, plugins payants ou licences.

Le piège réside dans le fait que ces couches sont indépendantes les unes des autres. Vous pouvez posséder le code source sans avoir accès à l’hébergement. Ou avoir le domaine à votre nom, alors que le contenu du CMS se trouve dans un compte auquel seule l’agence a accès. La vraie propriété signifie que vous contrôlez les cinq, ou que vous pouvez au moins y accéder sans entrave.

Quel élément est le plus important à sécuriser ?

Commencez par le nom de domaine, car c’est l’élément où le lock-in fait le plus mal et qui, en même temps, est le plus facile à éviter. Un domaine a un titulaire enregistré (le registrant), et ce titulaire est juridiquement le propriétaire, pas celui qui le gère. Si votre agence enregistre le domaine “vite fait pour vous” à son propre nom ou dans son propre compte de registrar, vous êtes coincé. Lors d’un déménagement, vous avez besoin de sa collaboration pour le code de transfert, et sans cette collaboration vous n’allez nulle part.

La règle est simple : le domaine est au nom de votre entreprise, dans un compte de registrar dont votre entreprise détient les identifiants. Vous laissez votre agence le gérer, très bien, mais comme titulaire enregistré et propriétaire du compte, c’est votre organisation qui figure. Le même principe vaut pour vos données de mesure les plus importantes. Placez Google Analytics et Search Console sur un compte de votre entreprise et donnez à l’agence un accès en tant qu’utilisateur, pas l’inverse. Si le travail déménage, vous ne perdez pas votre historique. C’est précisément ce qui fait la différence lors d’une migration de site sans perte de référencement ultérieure.

Où se situe le lock-in selon la plateforme ?

Le lock-in n’est pas une caractéristique d’une mauvaise plateforme, mais d’un accès mal réglé. La forme qu’il prend diffère pourtant selon le type de construction, et il est honnête de nommer ces différences sans désigner un choix comme vainqueur.

Avec un CMS ouvert comme WordPress, vous avez en théorie tout en main : c’est votre base de code, votre base de données, vos fichiers, tournant sur un hébergement que vous pouvez choisir vous-même. Le lock-in ne réside pas là dans la plateforme, mais dans les comptes qui l’entourent. Qui détient l’identifiant admin, sur quel compte d’hébergement le site est-il enregistré, et qui possède les licences des plugins payants et du thème ? Sans ces éléments, vous possédez un site que vous ne pouvez pas déplacer.

Avec une plateforme visuelle comme Webflow, vous obtenez de la facilité d’usage et une infrastructure hébergée, mais la propriété est répartie autrement. Vous pouvez exporter le code du front-end (sur les abonnements prévus à cet effet), mais cet export ne contient pas le contenu du CMS, les formulaires ni les fonctionnalités d’hébergement ; ceux-ci restent liés à la plateforme. La “question de propriété” pratique est ici surtout : le projet se trouve-t-il dans un workspace au nom de votre entreprise, de sorte que vous puissiez en transférer la gestion sans reconstruire l’ensemble du site ?

Avec du sur mesure ou du headless, vous avez généralement le plus de contrôle sur le code, mais vous dépendez d’une bonne documentation et d’un accès au dépôt et aux différents services. Sans le dépôt Git, les variables d’environnement et une transmission lisible, un code sur mesure coûteux reste malgré tout une boîte noire. Si vous envisagez de découpler les différentes couches, notre explication sur le fonctionnement d’un CMS headless aide à voir où se situent exactement la propriété et la dépendance.

La conclusion n’est donc pas “choisissez la plateforme X pour éviter le lock-in”. C’est : sur chaque plateforme, c’est votre accès, pas la technologie, qui détermine si vous êtes libre. L’option qui convient le mieux dépend de votre équipe, de vos plans de croissance et de la fréquence à laquelle vous voulez pouvoir modifier les choses vous-même. C’est aussi ainsi que nous envisageons le développement de sites web de manière indépendante de la plateforme : le bon outil pour votre cas précis.

Que doit contenir le contrat ?

Fixez la propriété et l’accès par écrit avant la première facture, car négocier après coup sur quelque chose que vous avez déjà payé vous place en position de faiblesse. Un bon accord ne doit pas être long, mais il couvre ces points :

Propriété du travail livré. Rendez explicite que le code source, les fichiers de design et le contenu deviennent votre propriété après paiement (cession des droits d’utilisation), et non simplement “sous licence”.
Comptes à votre nom. Domaine, hébergement, CMS, analytics et outils payants sont sur des comptes de votre entreprise. L’agence travaille en tant qu’utilisateur disposant d’un accès, pas en tant que propriétaire.
Une clause de sortie. Que récupérez-vous à la fin de la collaboration, sous quelle forme et dans quel délai ? Pensez à un export du contenu, à la base de code complète, à un dump de la base de données et à une liste de tous les comptes et licences.
Documentation et transmission. Convenez qu’une brève transmission technique sera prévue : où se trouve quoi, comment déployer, quels services sont liés.
Aucune prise en otage en cas de litige. Fixez que vous conservez l’accès à votre site en ligne et à vos données, même en cas de discussion sur une facture.

Une agence qui réfléchit avec vous n’y voit aucun problème. Des accords clairs sur la propriété sont justement un signe de confiance, et c’est là-dessus que repose une bonne relation B2B. En plus de la propriété externe, réglez aussi en interne qui gère le site : une bonne gouvernance de site web fixe qui, au sein de votre propre entreprise, est propriétaire du site. C’est la même logique qui détermine si les visiteurs vous croient : voyez inspirer confiance sur votre site web B2B.

Comment récupérer votre propriété si les choses ont mal tourné ?

Si vous êtes déjà coincé, commencez par un inventaire calme plutôt que par un conflit. Dressez une liste des cinq couches et cherchez, couche par couche, à quel nom et dans quel compte chacune se trouve. Souvent, ce n’est pas si grave et il s’agit simplement de faire transférer l’accès, ou de vous faire ajouter comme propriétaire d’un compte.

Pour le domaine, vous demandez le code de transfert (le code auth ou code EPP) et vous le déménagez vers un registrar au nom de votre entreprise. Pour analytics et Search Console, vous vous faites ajouter comme administrateur tant que vous obtenez encore de la collaboration. Pour le contenu, la règle est la suivante : même si vous ne pouvez pas exporter l’ancien site, vous pouvez le plus souvent encore récupérer les textes et les images pour les reconstruire ailleurs. Et si un déménagement devient inévitablement une nouvelle construction, planifiez-la alors correctement d’emblée, afin de ne pas perdre vos positions. Un processus de refonte de site web réfléchi tient compte précisément de cette continuité.

Ce que vous pouvez perdre de plus précieux, ce n’est pas le code, qui peut être reconstruit, mais votre domaine et vos données de mesure accumulées. Protégez ces deux-là en premier et le reste suivra.

Le résumé en bref

Être propriétaire de votre site web signifie que vous pouvez accéder sans entrave à cinq éléments : le domaine, le code source et les fichiers de design, le contenu du CMS, l’hébergement et tous les comptes liés. Le lock-in naît rarement de la mauvaise foi, mais d’un accès qui se retrouve par accident au nom de l’agence. Placez votre domaine et votre analytics en premier sur des comptes de votre propre entreprise, fixez la propriété et une clause de sortie par écrit avant le démarrage, et prévoyez une transmission soignée. Si vous faites cela, vous restez libre de croître, de renouveler ou de changer, sans que cela ne devienne jamais un combat.

Vous voulez avoir la certitude que votre site nouveau ou existant est entièrement à vous, avec des accords qui ne vous coincent nulle part ? Planifiez votre entretien de découverte gratuit et nous passons en revue ensemble votre propriété et vos options.