Comment savoir si vous êtes vraiment propriétaire de votre site web?

Payer un site ne veut pas toujours dire l’acheter

Quand une entreprise me demande si elle sera propriétaire de son site, la question arrive rarement dans ces mots-là. Elle prend une forme très concrète. « Est-ce que je vais avoir mes accès? » « Qu’est-ce qui arrive si je change d’agence? » « Si j’arrête la gestion mensuelle, est-ce que je peux conserver le site et reprendre l’hébergement ailleurs? »

Ce sont d’excellentes questions. Elles révèlent une confusion normale entre trois réalités : acheter un site, louer l’accès à une plateforme et payer quelqu’un pour gérer un site qui vous appartient.

Un site doit toujours reposer sur une infrastructure pour rester accessible. Cela peut être un hébergeur web classique, un serveur, un service infonuagique ou une plateforme de déploiement comme Cloudflare Pages, Vercel, Netlify ou AWS Amplify. La technologie change. Le principe reste le même : il y a toujours une infrastructure à payer et à gérer. Ce coût d’infrastructure peut être facturé chaque mois, aux six mois ou à l’année. La question n’est donc pas de ne plus payer aucun frais récurrent.

Un paiement récurrent peut couvrir l’hébergement, le soutien, la gestion ou l’accès à une plateforme. Il peut aussi acheter un simple droit d’usage. C’est le principe du bail : vous payez pour occuper, pas pour posséder. Rien de malhonnête là-dedans, et c’est souvent avantageux. Le problème commence quand l’entreprise croit avoir acheté un produit fini alors que l’entente lui donne accès à un service.

Raisonnable, ça veut dire quoi? Quelques heures de travail professionnel, des frais que vous connaissiez d’avance, et un site qui redémarre ailleurs à peu près tel quel. Ça ne veut pas dire instantané, gratuit ni faisable seul. Ça veut dire possible, chiffrable et prévu au contrat.

Vous pouvez donc continuer à payer de l’hébergement tout en étant pleinement propriétaire de votre site. Ce qui devrait être clair avant de signer, c’est ce qui peut être transféré, le travail que cette transition demande et les frais que vous devrez reprendre.

Les éléments qui font fonctionner votre site

Ce que vous voyez dans votre navigateur n’est que la surface. Dessous, il y a des actifs, des comptes et des services. Chacun peut être détenu par une personne et géré par une autre, sans que ça paraisse nulle part.

Voici les principaux éléments à clarifier :

• le nom de domaine et son renouvellement;
• les réglages DNS qui relient le domaine au site et parfois aux courriels;
• l’hébergement et le déploiement;
• le code, le thème ou les gabarits;
• le CMS et ses contenus;
• les textes, photos, vidéos et autres médias;
• les formulaires, bases de données et renseignements recueillis;
• Google Analytics, Search Console et les autres outils de mesure;
• les licences, extensions, automatisations et services externes;
• les accès administratifs et les coordonnées de récupération.

Posséder les textes et les photos est essentiel. Ce n’est pas posséder le site pour autant. Si un nouveau professionnel doit tout refaire pour reprendre le vôtre, vous avez récupéré des morceaux, pas un site transférable.

Attention, tout n’a pas à se retrouver dans un seul compte à votre nom. Une agence a ses propres outils de développement, et elle mutualise parfois certains services. C’est légitime. L’entente doit simplement dire ce qui vous appartient, ce qui est sous licence et ce que vous devrez reprendre en partant.

Pour un domaine .CA, je préfère un mot plus précis que « propriétaire » : titulaire. Votre entreprise devrait être le titulaire inscrit, et contrôler l’adresse courriel du contact administratif.

Ce deuxième point a l’air anodin. Il ne l’est pas. Pour déplacer un .CA vers un autre registraire, il faut un code d’autorisation, et CIRA exige que la demande parte de l’adresse du contact administratif(s'ouvre dans une nouvelle fenêtre). Le registraire a cinq jours pour le fournir. Si cette adresse est celle d’un employé parti ou d’une agence que vous venez de quitter, vous êtes coincé. Et une fois le domaine rendu en période de rachat, cette adresse ne peut plus être changée.

Votre fournisseur peut très bien gérer le DNS et la configuration technique. C’est le nom au registre et l’adresse de récupération qui doivent rester chez vous.

Les plateformes fermées ne sont pas le problème

Wix, Webflow, Squarespace, Shopify et les autres plateformes hébergées peuvent être d’excellentes solutions. Elles regroupent plusieurs fonctions et réduisent la configuration technique. Le lancement devient plus simple et plus rapide. Pour une entreprise qui démarre avec un budget serré, c’est parfois exactement le bon choix.

Elles peuvent aussi réduire la friction si l’entreprise utilise déjà les autres outils du même écosystème. C’est utile pour les paiements, les réservations, le commerce ou les communications.

Elles n’offrent pas toutes la même transférabilité, et l’écart entre elles est plus grand qu’on pense.

Wix(s'ouvre dans une nouvelle fenêtre) l’écrit noir sur blanc : un site Wix doit tourner sur les serveurs de Wix. Le contenu vous appartient, mais le site ne s’héberge pas ailleurs. Webflow(s'ouvre dans une nouvelle fenêtre) exporte le vrai HTML, le CSS et le JavaScript, à deux conditions : être sur un forfait Workspace payant, et accepter que le CMS, le commerce, les formulaires, la recherche et les pages traduites restent derrière. Squarespace(s'ouvre dans une nouvelle fenêtre) génère un fichier XML destiné à WordPress, pas votre site. Shopify(s'ouvre dans une nouvelle fenêtre) laisse télécharger le thème sans les produits ni les contenus, et précise qu’un thème acheté est sous licence pour la boutique où vous l’avez acheté.

Ces possibilités d’export et de transfert ont été vérifiées dans les documentations officielles le 29 juillet 2026. Les plateformes peuvent modifier leurs politiques, leurs forfaits et leurs fonctions. Vérifiez toujours les conditions en vigueur avant de choisir une solution ou de planifier une migration.

Quatre plateformes, quatre réponses différentes à la même question. Aucune ne triche : elles écrivent toutes ce qu’elles font. Encore faut-il l’avoir lu avant de bâtir trois ans de contenu dessus.

Il faut donc éviter deux raccourcis. Le premier serait de dire que toute plateforme vous rend prisonnier. Le second serait de croire que pouvoir télécharger quelques fichiers garantit une migration identique.

Avant de choisir, posez deux questions. Est-ce que cette plateforme répond bien aux besoins actuels de votre entreprise? Comprenez-vous ce qui devra être repris si ces besoins changent?

Une limite acceptable au lancement peut devenir importante plus tard. Il peut s’agir d’une intégration impossible, d’une structure HTML non modifiable ou d’un modèle trop rigide. Une hausse de prix ou un changement de conditions peut aussi réduire vos options. Le risque augmente quand le site devient essentiel.

Un professionnel n’élimine pas les risques. Il les rend visibles avant que vous signiez : les compromis de chaque option, la solution qui colle vraiment au besoin, et la sortie prévue si les besoins changent. Vous décidez accompagné plutôt que seul devant des choix techniques.

Pourquoi j’ai bâti une solution adaptée à ce projet

J’ai rencontré cette frustration en développant la plateforme de réservation d’un projet de photographie immobilière que j’exploite en parallèle de mon travail en développement web.

Au départ, ce projet utilisait une plateforme externe de réservation par abonnement. La plateforme répondait à un besoin réel et m’avait permis de commencer. Je payais toutefois pour certaines fonctions de base, dont une expérience en français. Malgré cela, je n’obtenais pas le niveau de finition et de contrôle que je voulais.

Certaines étapes importantes ne réagissaient pas comme prévu. Le choix du client, la sélection des services et plusieurs interactions manquaient de cohérence. Je voyais les problèmes, mais je ne pouvais pas les corriger à la source.

J’ai donc bâti une solution de réservation adaptée à ce projet. J’ai pensé l’expérience complète pour les courtiers, du premier choix jusqu’à la confirmation. Chaque étape suit maintenant la même logique. L’ensemble ne donne plus l’impression d’avoir été assemblé avec des blocs disparates.

Cette solution a demandé un investissement plus important au départ. En retour, j’ai gagné du contrôle et du temps. L’image est plus cohérente. J’ai aussi davantage confiance dans cet outil lié directement à mes opérations.

Je ne raconte pas cette expérience pour dire que chaque entreprise devrait développer son logiciel. Ce serait souvent inutile.

Je la raconte parce qu’elle arrive avant la question de la propriété.

Une solution pratique au départ devient parfois trop étroite. L’architecture sur mesure se justifie le jour où les contraintes qu’elle vous évite valent plus cher que ce qu’elle coûte.

Les comptes et les données à garder sous votre contrôle

Je recommande de garder les comptes importants avec l’entreprise. Ils portent son identité ou son historique. Pensez au domaine, aux outils de mesure, aux services de courriel et aux données de formulaires.

Google Analytics est le meilleur exemple. Créez la propriété dès le départ dans un compte contrôlé par votre entreprise, et donnez ensuite à l’agence les permissions dont elle a besoin. Si la relation se termine, vous gardez vos données et vous modifiez les accès. C’est tout.

Google documente aussi le déplacement d’une propriété GA4 d’un compte à l’autre(s'ouvre dans une nouvelle fenêtre) quand elle a été créée au mauvais endroit. Ça fonctionne, mais il faut les droits d’administrateur sur les deux comptes, et l’historique des modifications, lui, reste dans le compte d’origine. Partir du bon compte le premier jour vous évite tout ça.

Même logique pour Search Console, pour une plateforme d’envoi de courriels, pour n’importe quel service essentiel au fonctionnement. En partant, vous reprenez la facturation et les responsabilités. Vous ne perdez pas votre historique.

Un outil de surveillance, de sauvegarde ou de déploiement, lui, se mutualise très bien entre plusieurs clients. Là, le compte complet n’a pas à être transféré. Ce qui doit être écrit noir sur blanc : ce que vous recevez, ce qui s’arrête avec la gestion et comment le site continue ailleurs.

Bref, les outils internes de l’agence restent à l’agence. Vos actifs et vos données, eux, doivent demeurer récupérables, avec une solution de remplacement possible à des conditions que vous connaissez d’avance.

Être propriétaire ne veut pas dire tout gérer soi-même

Plusieurs propriétaires de PME n’ont aucune envie d’administrer un hébergement ou de vérifier des sauvegardes. C’est parfaitement normal. Quelqu’un qui fait ça tous les jours règle en quinze minutes ce qui leur prendrait un après-midi de recherche.

Selon le forfait, la gestion couvre l’hébergement, le SSL, la surveillance, les sauvegardes, les mises à jour, la sécurité et un soutien léger par courriel. Un site statique et un WordPress chargé d’extensions ne demandent évidemment pas le même entretien.

Chez Patoine Studio, je propose cette gestion parce que je connais l’architecture que j’ai bâtie. Je peux donc l’entretenir soigneusement. Ce service offre de la tranquillité d’esprit. Il n’a pas à devenir une condition pour conserver le site.

Arrêter la gestion ne rend pas le site gratuit pour autant. Vous ou votre nouveau fournisseur reprenez l’hébergement et les services nécessaires, ce qui suppose une migration, des vérifications et souvent du travail professionnel.

Autre chose à distinguer : une nouvelle section, une fonctionnalité ou une refonte ne sont pas de la maintenance. Ça se comprend, ça se chiffre, ça se valide. L’entretien garde le système en santé. Il ne transforme pas chaque idée en livrable inclus.

Cette distinction protège les deux parties. Si la gestion cesse, le contrat explique ce qui continue, ce qui doit être repris et quels frais passent au client.

Un bon transfert se prépare avant le départ

Changer d’agence web ne devrait jamais obliger la nouvelle équipe à repartir de zéro. Ça ne veut pas dire pour autant que l’ancienne doive livrer gratuitement une documentation exhaustive.

Je trouve raisonnable de prévoir une transition de base dès la soumission ou le contrat :

• remettre les accès et les fichiers prévus;
• transférer le projet ou le dépôt de code lorsque le modèle le permet;
• fournir un README ou une documentation courte sur l’architecture, les réglages et les conventions;
• expliquer les grandes lignes lors d’un bref appel;
• préciser les licences et les services qui devront être repris;
• distinguer un transfert du même système d’une migration vers une autre technologie.

Une collaboration plus longue peut devenir un mandat facturable. L’objectif minimal reste simple. Le prochain professionnel doit pouvoir comprendre le projet sans deviner son fonctionnement.

Il faut aussi clarifier ce que « transférer le site » signifie. Déplacer le même projet vers un autre compte ou un autre hébergeur peut être assez direct. Quitter une plateforme pour une technologie différente est plutôt une migration. Elle demande souvent du travail, même si tous les contenus sont accessibles.

Un transfert possible n’est pas toujours gratuit ou instantané. La propriété protège la possibilité de faire ce travail. Elle ne l’élimine pas. Vous devez connaître cette réalité avant de signer. Vous évitez ainsi de découvrir trop tard que la seule option est une reconstruction urgente.

Le contrat peut encadrer le processus de transfert. Il ne peut pas figer son coût pour toujours. La technologie, les outils, les abonnements, les licences et les besoins du site évoluent. Une estimation peut être donnée à l’avance. Le coût réel doit toutefois être évalué au moment où le transfert est demandé, selon ce qui est en place à ce moment-là.

Les questions à poser avant de signer

Vous n’avez pas besoin de devenir développeur pour protéger votre entreprise. Vous avez surtout besoin de réponses compréhensibles.

Avant d’accepter une proposition, posez ces questions :

1. Après avoir payé le projet, est-ce que le site demeure à mon entreprise?
2. Si j’arrête la gestion mensuelle, qu’est-ce que je conserve et quels services ou frais dois-je reprendre?
3. Puis-je confier le site à un autre professionnel sans le reconstruire entièrement?
4. Qui sera le titulaire du nom de domaine et qui contrôlera son renouvellement?
5. Quels comptes seront créés au nom de mon entreprise?
6. Quels outils, licences ou services appartiennent au fournisseur ou dépendent de son abonnement?
7. Puis-je récupérer mes contenus, mes médias, mes données et mon historique de mesure?
8. Quels frais continuent après la mise en ligne, et qui les paie?
9. Que comprend la gestion mensuelle, et qu’est-ce qui constitue une amélioration facturée séparément?
10. Que prévoit la transition si je change de fournisseur?
11. Quels droits ai-je sur le code : utilisation, modification, transfert à un autre professionnel et réutilisation?

La dernière question mérite une clause précise. L’Office de la propriété intellectuelle du Canada(s'ouvre dans une nouvelle fenêtre) explique qu’un logiciel peut être protégé par le droit d’auteur. D’autres éléments du site peuvent l’être aussi. Posséder le site pour les besoins de votre entreprise ne permet donc pas automatiquement de revendre son code. Cela ne permet pas non plus de le redistribuer à des tiers. Une licence peut toutefois accorder de larges droits d’utilisation et de modification sans transférer tous les droits de propriété intellectuelle.

Je ne donne pas ici un avis juridique. Mon conseil pratique est simple : ne laissez pas cette question implicite. Si la propriété intellectuelle ou la réutilisation du code compte pour votre projet, faites vérifier la clause par une personne qualifiée.

Ma façon de travailler aujourd’hui

Ma position tient en une phrase. Je veux que mes clients comprennent ce qu’ils achètent, ce qu’ils me confient et ce qu’ils pourront reprendre. Quand je vous vends un site comme un produit, vous devez pouvoir l’utiliser, le modifier et le faire évoluer, avec moi ou avec quelqu’un d’autre, selon les droits prévus à l’entente.

Cette approche peut évoluer avec les technologies, les services et mon expérience. Elle ne constitue pas une règle universelle. Une boutique hébergée, une application sur mesure et un site vitrine statique n’ont pas les mêmes contraintes.

Le principe qui demeure est la clarté. Qui détient quoi? Qui paie quoi? Que se passe-t-il si la gestion cesse? Quelles données restent avec l’entreprise? Qu’est-ce qui doit être migré?

Des réponses simples permettent de combiner accompagnement et autonomie. Vous pouvez déléguer le travail technique. Vous n’avez pas à remettre la continuité de votre entreprise entre les mains d’un seul fournisseur.

J’ai déjà expliqué dans l’article Combien coûte un site web au Québec pour une PME? pourquoi la transférabilité fait partie du prix réel. Ici, le test est plus direct. Après avoir payé, pourriez-vous partir avec votre site dans des conditions raisonnables?