Base de connaissances

Travailler sur un site que quelqu'un a partagé avec vous

Le propriétaire d'un site peut confier un site à un développeur par e-mail — pas son compte, pas sa facturation, pas ses autres sites. Les deux volets : le partage et la révocation depuis le tableau de bord, et le téléchargement du site avec zinnector login, clone et dev, base de données incluse — ainsi que ce que chaque rôle peut et ne peut pas faire.

Un propriétaire de site peut vous donner accès à l'un de ses sites — et non à son compte, ni à sa facturation, ni à ses autres sites — et vous y travaillez avec votre propre identifiant Zinn Digital® et l'outil CLI gratuit Zinnector®. Ce guide aborde ces deux aspects : ce que fait le propriétaire et ce que vous faites.

Si vous n'avez jamais utilisé Zinnector® auparavant, l'article Commencer avec Zinnector® permet de l'installer en deux minutes environ. Rien ici ne vous oblige à acheter un hébergement.

Pour le propriétaire du site — partager un site

  1. Ouvrez le site dans votre tableau de bord et allez dans Sécurité.
  2. Sous Qui d'autre peut accéder à ce site, choisissez Partager ce site.
  3. Saisissez l'adresse e-mail du développeur. Il n'a pas encore besoin de compte : s'il ne s'est jamais connecté, il reçoit une invitation et l'accès prend effet dès qu'il l'accepte.
  4. Choisissez un rôle :
  • Lecteur — peut consulter, mais ne peut rien modifier.
  • Éditeur — le rôle dont un développeur a généralement besoin. Il peut modifier les fichiers du site, utiliser wp-admin et télécharger une archive du site pour travailler en local. Cette archive comprend la base de données.
  • Gestionnaire — tout ce qu'un éditeur peut faire, plus la restauration d'une sauvegarde.
  1. Indiquez un motif et, si le travail a une date de fin, une expiration. L'autorisation cesse simplement d'être active à cette date ; vous n'avez pas besoin de penser à la supprimer.
  2. Enregistrez.

Quoi que vous choisissiez, un collaborateur ne pourra jamais supprimer le site, voir votre facturation ou accéder à vos autres sites.

Ce que signifie « l'archive comprend la base de données »

Un éditeur ou un gestionnaire peut récupérer une copie du site pour travailler, et la copie d'un site comprend ses fichiers ainsi que sa base de données. Une base de données WordPress contient tout ce que vos visiteurs ont transmis au site : noms et adresses e-mail des commentateurs, comptes clients, commandes et adresses de livraison WooCommerce, soumissions de formulaires.

C'est généralement exactement ce dont un développeur a besoin : sans cela, il contemple votre thème sur un site vide. Il est bon de le savoir, car il s'agit de données personnelles réelles et les personnes à qui elles appartiennent sont vos clients, et non les nôtres.

Deux conséquences en découlent, et la plateforme s'occupe des deux pour vous :

  • Chaque exportation figure dans votre journal d'audit. Ouvrez le Journal d'audit et recherchez site.backup.exported. Chaque ligne indique qui l'a effectuée, quand, et si cette archive contenait la base de données. Vous n'avez pas besoin de demander.
  • Vous pouvez y mettre fin à tout moment. La révocations est immédiate — voir ci-dessous.

Si vous préférez qu'ils travaillent sans la base de données, dites-leur d'ajouter --no-database lors du téléchargement (pull) ; il s'agit d'un seul indicateur et le reste fonctionne de la même manière.

Pour le développeur — installer le site sur votre machine

1. Installer Zinnector®

npm install -g zinnector
zinnector --version

Vous avez besoin de Node 24 ou d'une version plus récente. node --version doit afficher v24 ou une version supérieure.

2. Vous connecter avec vos identifiants

zinnector login

Cette commande ouvre votre navigateur et vous connecte avec votre propre compte Zinn Digital® — celui auquel l'invitation a été envoyée. Vous n'avez jamais besoin du mot de passe du propriétaire, et celui-ci n'a jamais besoin de vous en donner un.

Vérifiez ce qui vous a été attribué :

zinnector sites

Vous verrez exactement les sites qui vous ont été partagés, et rien d'autre. Si la liste est vide, l'invitation n'a pas encore été acceptée, ou l'autorisation a été révoquée ou a expiré.

3. Télécharger le site (pull)

zinnector clone client-domain.com
cd client-domain.com

La commande clone crée un projet local à partir du site hébergé. Elle récupère :

  • wp-content — les thèmes, extensions, extensions indispensables (mu-plugins), langues et médias qui constituent le travail propre au site ;
  • la base de données, enregistrée dans database.sql au sein du projet.

Elle laisse volontairement de côté le cœur de WordPress (votre environnement local fournit la bonne version), wp-config.php (qui contient le mot de passe de la base de données du site en direct), ainsi que tous les médias qui ont été déchargés vers un stockage d'objets.

Chaque exécution affiche exactement ce qu'elle a pris et ce qu'elle a laissé, avec les décomptes. Si vous ne souhaitez que les fichiers, ajoutez --no-database.

Vous possédez déjà le projet et voulez simplement la dernière version ? Exécutez zinnector pull à l'intérieur de celui-ci.

4. L'exécuter localement, avec le contenu réel

zinnector dev --runtime docker

Sur l'environnement d'exécution Docker, cette commande importe database.sql, réécrit l'URL du site vers votre adresse locale et ouvre le site avec le contenu réel du client. Connectez-vous avec les comptes WordPress propres au site.

L'environnement d'exécution par défaut — WordPress Playground, qui ne nécessite pas Docker — est plus rapide à démarrer et n'importe pas la base de données ; il vous en avertira plutôt que de démarrer silencieusement sur un site vide. Utilisez-le lorsque vous travaillez sur du code et n'avez pas besoin du contenu.

5. Gérer la copie qui vous a été confiée

database.sql est la base de données d'un site en production. Zinnector® l'ajoute au fichier .gitignore de votre projet dès qu'il l'écrit, afin qu'un git add -A distrait ne puisse pas publier les clients de quelqu'un sur un dépôt. Ne touchez pas à cette ligne et supprimez le fichier une fois le travail terminé.

Ce qu'un collaborateur peut et ne peut pas faire

| | Lecteur | Éditeur | Gestionnaire | |---|---|---|---| | Voir le site et ses paramètres | ✔ | ✔ | ✔ | | Modifier des fichiers, utiliser wp-admin, déployer | | ✔ | ✔ | | Télécharger le site, base de données incluse | | ✔ | ✔ | | Restaurer une sauvegarde sur le site en direct | | | ✔ | | Supprimer le site | | | | | Voir la facturation ou les factures | | | | | Accéder aux autres sites du propriétaire | | | |

Les trois dernières lignes sont vides pour tous les rôles. Il ne s'agit pas d'un paramètre.

Mettre fin à l'accès

Le propriétaire ouvre la section Sécurité du site et choisit Révoquer à côté du nom de la personne. Cela prend effet immédiatement : la prochaine commande Zinnector® exécutée par ce développeur ne pourra plus voir le site, pas plus que tout autre élément en sa possession.

Une date d'expiration fait la même chose le jour venu, sans que personne n'ait à y penser. Si vous en avez défini une lors du partage du site, c'est déjà réglé.

En cas de dysfonctionnement

  • zinnector sites neaffiche rien. L'invitation n'a pas été acceptée, ou l'autorisation a été révoquée ou a expiré. Demandez au propriétaire de consulter la section Sécurité du site — une invitation en attente y est répertoriée.
  • zinnector pull indique que le site ne dispose d'aucun sauvegarde récente. Le téléchargement en effectue une nouvelle si le forfait le permet, et demande confirmation au préalable. Si le forfait ne comprend pas de sauvegardes à la demande, augmentez la valeur de --max-age pour accepter une sauvegarde plus ancienne.
  • zinnector dev démarre un WordPress vide. Vous utilisez l'environnement d'exécution Playground, qui n'importe pas de base de données. Exécutez zinnector dev --runtime docker.
  • Le site local continue de rediriger vers le domaine en direct. L'importation réécrit l'URL du site ; si cette étape a échoué, la commande le signale et affiche la ligne wp search-replace à exécuter.

Pour plus d'erreurs et leurs solutions : Dépannage de Zinnector®.

Toute la documentation pour développeurs

Derniers articles du blog

Ce que nous écrivons sur l'hébergement, le SEO et la gestion de sites à grande échelle.

SEO et netlinking depuis la couche d'hébergement : la vision d'un opérateur en 2026

Comment l'hébergement façonne l'indexation et la valeur des liens en 2026 : maintenir les pages indexées, auditer les domaines expirés avant de les exploiter, créer des liens sans laisser de traces, et un point de vue honnête sur ce que l'infrastructure peut et ne peut pas faire pour le référencement naturel.

Lire l'article

Rendre WordPress Rapide et Sécurisé : Une Liste de Contrôle des Performances et des Extensions

Une liste de contrôle pratique pour un WordPress rapide et sécurisé : mise en cache au niveau du serveur, cache d'objets par site, la poignée de plugins qui valent la peine d'être utilisés, mise à jour de la pile technique, et les pages WooCommerce à ne jamais mettre en cache.

Lire l'article

Comment choisir un hébergement web infogéré en 2026 : Le guide de l'acheteur

Ce qui distingue réellement un bon hébergement infogéré d'un serveur bas de gamme avec panneau de configuration — migrations, sauvegardes, isolation, véritable mise en cache et mise à l'échelle honnête — et comment l'évaluer avant de vous engager.

Lire l'article

Lire le blogue

Toujours bloqué ?

Le support est inclus dans chaque forfait, le service est ouvert 24 heures par jour et vous pouvez nous écrire dans l'une de nos 58 langues ; nous vous répondons dans la vôtre.

Contacter le support Tous les articles