Propriété d’un site web : ce que votre entreprise doit posséder

VousVotre site vous appartient ?

L’entrepriseBien sûr. Nous l’avons payé.

VousVous pouvez renouveler le nom de domaine ?

L’entrepriseC’est l’agence qui s’en occupe.

VousEt récupérer le code ? Restaurer une sauvegarde ? Donner les accès à une autre équipe ?

L’entrepriseIl doit être quelque part.

…Puis vient le silence.

La propriété d’un site web ne se prouve pas avec une facture. Elle se prouve le jour où vous devez reprendre la main.

Ce scénario ne suppose aucune mauvaise volonté. Une collaboration peut très bien se passer et rester fragile si personne n’a décidé qui devait détenir les comptes, les livrables et les moyens de reprise.

Imaginez simplement que votre prestataire soit indisponible demain matin.

Pouvez-vous renouveler le domaine, administrer les comptes, récupérer les contenus et les données, publier une correction, restaurer une sauvegarde et confier le site à une autre équipe ?

Si la réponse est oui, votre entreprise maîtrise son site.

Si la réponse est « normalement », « je pense » ou « il faudrait demander », vous venez de trouver un risque.

Vous repartirez avec un inventaire exploitable, un test de sortie et une liste d’actions à attribuer. Pas avec une promesse abstraite.

Une précision avant de commencer : il s’agit d’une méthode opérationnelle, pas d’un avis juridique. Les droits de propriété intellectuelle et les clauses de sortie doivent être relus selon votre contrat et votre situation.

Comment savoir si votre site vous appartient vraiment ?

Commencez par oublier l’expression « le site ».

Elle est trop vague.

Un site rassemble un nom de domaine, des DNS, un hébergement, du code, des textes, des images, des données, des licences, des outils de mesure et plusieurs comptes tiers. Vous pouvez contrôler certains de ces éléments et dépendre entièrement d’un prestataire pour les autres.

Vous pouvez, par exemple, être titulaire du domaine sans posséder le dépôt de code. Recevoir une archive sans savoir la déployer. Administrer le CMS sans contrôler l’hébergement. Consulter Analytics sans être propriétaire de la propriété.

Voilà pourquoi il faut séparer trois choses :

• la propriété juridique : ce que le contrat vous autorise à utiliser, modifier ou transmettre ;
• l’accès technique : les comptes, rôles et moyens d’authentification dont vous disposez ;
• la capacité de reprise : ce qu’une autre équipe peut réellement remettre en route.

Ne mélangez pas ces trois sujets.

Pour chaque élément du site, posez quatre questions très simples :

1. Le droit : que pouvons-nous utiliser, modifier ou transférer ?
2. Le compte : qui détient le rôle propriétaire et la facturation ?
3. Le livrable : que pouvons-nous récupérer, et dans quel format ?
4. La reprise : une personne qui n’a pas construit le site peut-elle s’en servir ?

Le Code de la propriété intellectuelle prévoit que les droits cédés soient mentionnés distinctement et que leur exploitation soit délimitée.

Autrement dit, la phrase « le site appartient au client » ne règle pas tout.

Quels éléments ? Quels droits ? Pour quels usages, territoires et durées ? Le contrat prévoit-il une cession ou une licence ?

Vous n’avez pas besoin de transformer chaque livraison en cours de droit. Vous avez besoin de savoir ce que votre entreprise peut faire — et de pouvoir le faire sans demander une permission nouvelle.

Payer le site suffit-il pour posséder le code et le design ?

Non.

Le paiement prouve qu’une prestation a été réglée. Il ne décrit pas, à lui seul, les droits attachés à chaque création.

Prenez une page web ordinaire. Elle peut réunir du code développé pour vous, une bibliothèque open source, une police sous licence, des photographies achetées, un CMS, des illustrations originales et des textes fournis par votre équipe.

Qui possède quoi ?

La réponse ne tient pas dans un « oui » global. Le contrat doit distinguer ces éléments.

Demander « tous les droits sur tout » semble rassurant, mais ce n’est pas toujours réaliste. Une agence ne peut pas vous céder une bibliothèque open source ou une police qui appartient à un tiers. Elle peut en revanche inventorier les dépendances, préciser leurs licences et vérifier que leur usage reste compatible avec votre projet.

Pour le code développé spécifiquement, obtenez une réponse claire sur :

• l’accès au dépôt et à son historique ;
• le droit de faire maintenir et modifier le code par une autre équipe ;
• les éléments antérieurs au projet qui restent exclus ;
• les composants tiers et leurs licences ;
• les scripts de construction et de déploiement ;
• le moment où les droits et les livrables sont transmis.

Ne vous arrêtez pas au dossier ZIP.

Un ZIP prouve qu’un fichier a été envoyé. Il ne prouve pas que le site peut être reconstruit, testé, déployé et maintenu.

Faites le test.

Les 12 éléments à contrôler avant la livraison

Voici la checklist.

Pour chaque ligne, cherchez une preuve. Pas une formule rassurante. Pas « l’agence a tout ». Une preuve que votre entreprise peut accomplir l’action essentielle.

Élément	Contrôle attendu par l’entreprise	Preuve de livraison
1. Nom de domaine	L’entreprise est titulaire et peut renouveler ou transférer le domaine	identité du titulaire, bureau d’enregistrement, date d’expiration, facturation et double authentification
2. DNS	Elle peut modifier les enregistrements ou déléguer cet accès	compte administrateur, export de zone et contact de secours
3. Hébergement et CDN	Elle connaît l’offre, les coûts, les régions et les limites	compte propriétaire, rôle du prestataire, procédure de déploiement et de résiliation
4. Code source	Elle peut consulter, cloner et confier le dépôt	dépôt sous une organisation contrôlée, historique, branches et instructions de construction
5. Déploiement	Une nouvelle version peut être publiée sans poste personnel caché	pipeline, variables documentées, environnements et procédure de retour arrière
6. Données	Les données peuvent être exportées dans un format exploitable	export testé avec schéma, pièces jointes, historiques et règles de conservation
7. Contenus et médias	Les fichiers sources et droits d’usage sont identifiés	bibliothèque, originaux, crédits, licences et formats modifiables disponibles
8. Analytics et SEO	L’entreprise est propriétaire des propriétés de mesure	rôles Google Analytics, Tag Manager, Search Console et historique conservé
9. Formulaires et e-mails	Les demandes arrivent sur un canal contrôlé et testable	fournisseur, expéditeur, destinataires, journaux, procédure d’erreur et test de réception
10. Sauvegardes	Une sauvegarde peut être localisée et restaurée	fréquence, rétention, emplacement distinct et compte rendu d’un test de restauration
11. Accès et secrets	Les droits sont nominatifs, révocables et traçables	inventaire des rôles, double authentification, coffre de secrets et procédure de départ
12. Documentation	Une autre équipe comprend le système et les responsabilités	architecture courte, dépendances, coûts, alertes, contacts et procédures essentielles

Maintenant, rangez cet inventaire dans un espace détenu par l’entreprise.

N’y copiez pas les mots de passe.

Indiquez plutôt, pour chaque ligne, le compte propriétaire, l’administrateur opérationnel, le responsable de la facturation, la date du dernier contrôle et la procédure de récupération. Les secrets restent dans un gestionnaire adapté. L’inventaire dit où ils sont gérés et qui peut autoriser leur renouvellement, jamais ce qu’ils contiennent.

Puis fixez une règle : la liste est revue à chaque départ, changement de prestataire ou évolution importante du site.

Sinon, vous n’avez pas une procédure. Vous avez une photographie qui vieillit.

Qui doit être titulaire du nom de domaine ?

Imaginez que vous possédiez le code, les textes et toutes les images.

Mais pas le domaine.

Le site existe encore. Pourtant, si le domaine expire ou si son titulaire refuse le transfert, vos visiteurs ne le trouvent plus. Les adresses e-mail de l’entreprise peuvent également être perturbées.

Le domaine n’est donc pas un détail administratif. C’est l’adresse de votre activité sur le web.

L’entreprise doit en principe être clairement identifiée comme titulaire et conserver un moyen direct de gérer le domaine. Le prestataire peut rester contact technique ou recevoir un accès délégué. Il n’a pas besoin de détenir l’actif pour faire son travail.

Pour les domaines en .fr, l’Afnic distingue le titulaire du contact administratif : le titulaire détient les droits et responsabilités associés au domaine, contrairement à un simple contact administratif tiers.

Ne vérifiez donc pas seulement l’adresse qui reçoit les notifications. Vérifiez l’identité enregistrée.

Puis contrôlez :

• l’adresse e-mail utilisée pour les alertes et la récupération ;
• le renouvellement automatique et le moyen de paiement ;
• la date d’expiration ;
• la double authentification ;
• les serveurs DNS utilisés ;
• la procédure de transfert vers un autre bureau d’enregistrement.

Que faut-il récupérer pour le code et le déploiement ?

Demandez : « Où est le code ? »

Si la réponse est le nom d’un ordinateur, vous avez un problème.

Si la réponse est « nous vous enverrons le ZIP à la fin », continuez à poser des questions.

Le dépôt doit idéalement appartenir à une organisation contrôlée par l’entreprise. L’agence y reçoit le rôle nécessaire pour travailler. Lorsque le dépôt a été créé ailleurs, un transfert est souvent préférable à une simple copie finale : il conserve l’historique, les tickets, les versions et une partie des réglages.

La documentation GitHub sur le transfert d’un dépôt détaille ce que le nouveau propriétaire administre après l’opération.

Mais attention.

Voir le code ne signifie pas savoir le reprendre.

Choisissez une personne qui n’a pas construit le projet. Donnez-lui la documentation. Puis demandez-lui de :

1. cloner le dépôt ;
2. installer les dépendances ;
3. démarrer le site dans un environnement de test ;
4. exécuter les contrôles essentiels ;
5. produire une version ;
6. comprendre comment la déployer et revenir en arrière.

Si elle bloque à la deuxième étape, remerciez-la.

Elle vient de révéler ce que la documentation seule cachait.

Corrigez le processus pendant que l’équipe qui a construit le site est encore disponible. Les secrets ne doivent être copiés ni dans le code ni dans la documentation. En revanche, leur emplacement, leur propriétaire et leur procédure de renouvellement doivent être connus sans exposer leur valeur.

Votre site utilise une plateforme hébergée ou du no-code ? La livraison change de forme, mais le principe reste identique.

Vous ne récupérerez pas toujours un code autonome. Vous devez toutefois contrôler le compte principal, la facturation, le domaine, les données exportables, les intégrations et les rôles accordés aux collaborateurs. Notre comparaison entre solution standard, no-code et sur mesure vous aide à décider si ce niveau de dépendance est acceptable. Lorsqu’un IaaS, un PaaS ou un SaaS porte l’activité, complétez ce contrôle par le test de réversibilité cloud : il vérifie le changement de fournisseur, la reconstruction et la continuité.

Comment vérifier la propriété des données et des comptes ?

Cliquez sur « Exporter ».

Puis ouvrez le fichier.

C’est ici que beaucoup de contrôles s’arrêtent trop tôt. Un bouton existe. Un fichier est téléchargé. Tout le monde respire.

Mais les champs sont-ils compréhensibles ? Les relations entre les données sont-elles conservées ? Les pièces jointes, consentements, identifiants, horodatages et historiques utiles sont-ils présents ? Une autre solution peut-elle vraiment les réutiliser ?

Un accès à une interface n’est pas une preuve de portabilité. Un export exploitable, oui.

Lorsque le prestataire traite des données personnelles pour le compte de l’entreprise, le contrat doit également encadrer ses instructions et la fin de la prestation. La CNIL propose des clauses de sous-traitance et rappelle notamment la nécessité de choisir entre destruction et renvoi des données à l’issue du service.

Ne laissez pas cette clause flotter dans le contrat. Traduisez-la en opérations : quel format, quel délai, quel coût éventuel, quelles sauvegardes restantes et quelle preuve de suppression ?

Faites ensuite le même exercice avec vos outils de mesure.

Dans la Search Console, seuls les propriétaires peuvent gérer les autres accès. Votre entreprise doit donc conserver au moins un propriétaire vérifié qu’elle contrôle. Le prestataire reçoit ensuite un rôle nécessaire et révocable.

Répétez la vérification pour Analytics, Tag Manager, Merchant Center, les régies publicitaires et les outils de consentement.

Le test de sortie en 90 minutes

Voici le moment important.

Ne relisez pas la checklist une troisième fois.

Testez-la.

Réservez 90 minutes. Invitez une personne de l’entreprise et une personne qui n’a pas configuré le site. Le but n’est pas d’organiser une migration complète. Le but est de découvrir, avant l’urgence, si la reprise promise existe vraiment.

1. Retrouver les propriétaires

Lancez le chronomètre.

En quinze minutes, retrouvez le titulaire du domaine et les propriétaires du dépôt, de l’hébergement, de la Search Console et du compte analytics.

Vous devez fouiller une boîte personnelle ? Demander à une seule personne ? Attendre une réponse extérieure ? Notez-le. Ce n’est pas une condamnation. C’est une dépendance à corriger.

2. Produire deux exports

Exportez la zone DNS et un échantillon représentatif des données ou contenus.

Ouvrez les fichiers.

Vérifiez leur sens. Encore une fois : le bouton « Exporter » n’est pas le résultat. Le résultat, c’est un ensemble de données que quelqu’un d’autre peut comprendre et réutiliser.

3. Donner puis retirer un accès

Invitez un compte de test avec le rôle prévu pour une future agence. Vérifiez ce qu’il peut faire. Puis révoquez-le.

En quelques minutes, vous découvrirez les comptes partagés, les permissions trop larges et les accès impossibles à retirer proprement.

4. Rejouer une opération critique

Choisissez une seule action critique : publier une correction en préproduction, restaurer un contenu, vérifier une sauvegarde, modifier un enregistrement DNS non critique ou suivre une demande de formulaire jusqu’à sa réception.

Faites-la pour de vrai.

Ne touchez pas à la production sans procédure et validation. L’objectif est de vérifier une capacité, pas de créer un incident.

5. Écrire les inconnues

Écrivez trois listes :

• contrôlé ;
• transférable avec une action ;
• inconnu ou bloquant.

N’ajoutez pas un score décoratif. Affectez un responsable et une date à chaque manque.

Voilà votre véritable résultat.

Le test ne remplace pas une reprise complète. Il révèle si la continuité repose sur des actions reproductibles ou sur la mémoire d’une personne.

Quand préparer la réversibilité ?

Avant la signature.

Pas six mois après la mise en ligne. Pas le jour où la relation se tend. Avant la signature.

La réversibilité doit être cadrée au départ, vérifiée pendant le projet et testée à la livraison. Si vous l’abordez seulement au moment de partir, chaque accès manquant devient une négociation urgente.

Avant le devis

Écrivez noir sur blanc les comptes qui seront ouverts au nom de l’entreprise, les droits attendus, les formats de livraison et l’assistance prévue lors d’un transfert.

Notre guide pour comparer un devis de site internet vous aide à rapprocher ces éléments du prix, du périmètre et des autres postes du projet.

Pendant la réalisation

N’attendez pas le dernier jour pour créer l’organisation du dépôt, le compte d’hébergement ou les propriétés analytics.

L’entreprise reçoit progressivement les rôles propriétaires. L’agence travaille avec des accès nominatifs. Chacun sait qui contrôle quoi.

À la recette

Demandez des critères observables : compte propriétaire confirmé, export ouvert, sauvegarde restaurée, dépôt transféré, documentation suivie par une autre personne et licences inventoriées.

Le cahier des charges de site internet doit décrire cette recette. Le mot « autonomie », seul, ne suffit pas.

Pendant la maintenance

Refaites le contrôle quand l’hébergement, un fournisseur ou une personne change.

Un bon contrat de maintenance de site internet protège la continuité du site. Il ne transforme pas son accès en verrou commercial.

Quels signaux indiquent une dépendance risquée ?

Un écart isolé se corrige.

Dix écarts racontent une autre histoire.

Voici les signaux qui doivent vous faire ralentir et demander des réponses :

• le domaine est enregistré au nom personnel d’un prestataire ;
• l’entreprise paie sans avoir de compte propriétaire ;
• le code n’existe que sur un ordinateur ou dans un dépôt personnel ;
• aucun export de données n’a été ouvert et contrôlé ;
• l’agence est seule propriétaire de Search Console ou Analytics ;
• les licences et abonnements ne sont pas inventoriés ;
• les sauvegardes existent mais aucune restauration n’a été testée ;
• le formulaire envoie vers une boîte inconnue sans journal d’erreur ;
• la procédure de déploiement dépend d’une action non documentée ;
• le contrat parle de « remise du site » sans nommer les éléments remis ;
• la sortie est possible uniquement avec un forfait ou un délai non défini.

Vous en reconnaissez trois ou quatre ? Ne paniquez pas.

Ne retirez pas non plus tous les accès du jour au lendemain.

Replacez l’entreprise comme propriétaire des comptes essentiels. Puis redonnez au prestataire les rôles dont il a besoin. Une agence doit avoir assez d’autonomie pour travailler vite. Elle n’a pas besoin d’être l’unique point de contrôle.

Faut-il tout posséder pour rester libre ?

Non.

Et chercher à tout posséder peut même vous faire perdre du temps et de l’argent.

La maîtrise ne signifie pas héberger chaque service soi-même ni posséder le code de chaque dépendance. Un service spécialisé peut être plus fiable et plus économique qu’une reconstruction interne. Une licence peut suffire si ses droits, son coût et ses conditions de sortie sont acceptables.

La bonne architecture sépare trois catégories :

• actifs à contrôler directement, comme le domaine, les comptes propriétaires, les données, les contenus et les décisions de mesure ;
• services à déléguer, comme l’hébergement, l’envoi d’e-mails ou la surveillance, avec des rôles et une sortie explicites ;
• composants tiers, comme les bibliothèques et polices, dont les licences doivent rester compatibles avec l’usage.

La réversibilité ne promet pas qu’un changement d’agence sera gratuit ou instantané.

Elle promet quelque chose de plus utile : vous connaissez le coût, le délai, les dépendances et les opérations nécessaires.

Une migration sérieuse demande du travail. Une dépendance normale se gère. Une captivité artificielle vous empêche même d’organiser la sortie.

Faire de la livraison une preuve de maîtrise

La livraison approche.

Tout le monde veut voir la page d’accueil. Vérifier les animations. Relire le dernier titre.

Faites-le.

Puis demandez la démonstration qui compte vraiment.

Retrouvez le domaine. Ouvrez le dépôt. Identifiez le propriétaire de l’hébergement. Exportez les données. Vérifiez une sauvegarde. Suivez la documentation avec une personne qui découvre le projet.

La meilleure livraison n’est pas une réunion pendant laquelle l’agence vous montre un site terminé. C’est le moment où votre entreprise prouve qu’elle peut en reprendre les commandes.

Avant une création ou une refonte de site web, réunissez le contrat, la liste des comptes, les factures récurrentes, les exports disponibles et les personnes qui administrent aujourd’hui le système.

Le site existe déjà ? Commencez par notre grille d’audit. Elle vous aidera à séparer ce qui mérite d’être conservé, corrigé ou reconstruit.

Ensuite, faites le test de sortie.

Pas quand vous voudrez partir.

Maintenant.

Un site simple, documenté et réellement transférable protège mieux votre entreprise qu’un dispositif impressionnant dont une seule personne connaît les commandes.