Ajouter un utilisateur dans Search Console : gérer les accès

Pour ajouter un utilisateur dans Search Console, il faut être propriétaire de la propriété : ouvrez Paramètres, puis Utilisateurs et autorisations, cliquez sur Ajouter un utilisateur, saisissez l'adresse du compte Google de la personne et choisissez un niveau d'autorisation. Le geste prend trente secondes. La vraie décision est ailleurs : quel niveau accorder, à qui, et comment garder la main le jour où quelqu'un part.

Cet article ne refait pas le tour de l'outil. Il traite uniquement de la gestion des accès : la différence concrète entre propriétaire, propriétaire délégué, utilisateur complet et utilisateur restreint, ce qu'il est raisonnable de donner à une agence ou à un freelance, la manière de retirer un accès proprement, et le scénario que presque personne n'anticipe, celui où le propriétaire vérifié quitte l'entreprise.

Les quatre niveaux d'accès et ce qu'ils permettent vraiment

Search Console distingue quatre rôles. Ils se ressemblent dans la liste déroulante, mais leurs conséquences sont très différentes, surtout sur la question de la vérification de propriété.

Le propriétaire vérifié a prouvé qu'il contrôle le site, par un fichier HTML, une balise meta, un enregistrement DNS, ou un lien avec Google Analytics, Google Tag Manager ou le fournisseur de domaine. C'est le seul rôle qui repose sur une preuve technique, et c'est lui qui ancre tous les autres accès. Il peut ajouter et retirer des utilisateurs, modifier les paramètres, demander des suppressions d'URL, soumettre des sitemaps et gérer l'association avec d'autres services Google.

Le propriétaire délégué reçoit un niveau de contrôle proche de celui du propriétaire, mais sans avoir lui-même vérifié le site. Un propriétaire vérifié le désigne depuis la liste des utilisateurs. Sa particularité est la dépendance : son statut repose sur la vérification d'un propriétaire existant et ne vit pas de façon autonome. C'est pratique pour donner de larges droits sans faire installer un jeton sur le site, mais c'est une béquille fragile si la vérification d'origine disparaît.

L'utilisateur complet peut consulter presque toutes les données de la propriété et effectuer certaines actions, comme demander une indexation ou interagir avec les rapports. Il ne peut pas gérer les utilisateurs ni toucher aux réglages structurants de la propriété.

L'utilisateur restreint est en lecture seule sur la plupart des rapports. Il voit les performances, l'indexation et les problèmes, mais ne peut pas agir sur les demandes qui modifient l'état de la propriété, et certaines données sensibles ou certains outils lui restent fermés. Les libellés exacts évoluent avec l'interface : vérifiez le tableau d'aide officiel de Google avant de promettre un droit précis à quelqu'un.

• Propriétaire vérifié : preuve technique, gestion complète des utilisateurs et des paramètres.
• Propriétaire délégué : droits étendus, mais statut adossé à un propriétaire vérifié.
• Utilisateur complet : lecture large et actions courantes, sans gestion des accès.
• Utilisateur restreint : lecture seule pour l'essentiel, idéal pour consulter sans risque.

Ajouter un utilisateur pas à pas

Connectez-vous avec un compte propriétaire et sélectionnez la bonne propriété dans le sélecteur en haut à gauche. Cette étape compte plus qu'il n'y paraît : les accès sont attachés à une propriété précise. Si vous gérez à la fois une propriété de type domaine et plusieurs propriétés de type préfixe d'URL, donner l'accès à l'une ne donne rien sur les autres.

Ouvrez ensuite Paramètres, puis Utilisateurs et autorisations. Cliquez sur Ajouter un utilisateur, saisissez l'adresse e-mail et choisissez l'autorisation. L'adresse doit correspondre à un compte Google. Une adresse professionnelle qui n'est pas un compte Google peut fonctionner si elle a été associée à un compte, mais la solution la plus simple est de demander à la personne quelle adresse elle utilise réellement pour se connecter à Google. Une faute de frappe ne provoque pas d'erreur visible : vous donnez l'accès à la mauvaise adresse, ou à personne.

Une fois l'utilisateur ajouté, il apparaît dans la liste avec son rôle. Il peut alors retrouver la propriété dans son propre sélecteur. Si elle n'apparaît pas, le problème vient presque toujours d'un compte Google différent de celui que vous avez saisi : la personne est connectée avec une autre identité dans son navigateur. Demandez-lui de vérifier le compte actif en haut à droite avant de chercher plus loin.

Pour une propriété de type domaine, l'ajout fonctionne de la même manière, mais la vérification initiale exige un enregistrement DNS. Ce détail pèse sur la question du départ du propriétaire, traitée plus bas.

Quel niveau donner à une agence, un freelance ou un collègue

Le principe est celui du moindre privilège : donnez le niveau le plus bas qui permet de faire le travail. Un consultant qui produit un audit et des recommandations n'a besoin que de lire les données. Un utilisateur restreint suffit souvent, et il n'y a aucun risque qu'il déclenche une suppression d'URL par erreur.

Une agence qui suit le référencement au quotidien, surveille l'indexation et soumet des pages après publication est généralement bien servie par l'utilisateur complet. Elle voit tout ce dont elle a besoin et n'a pas la capacité de retirer les autres personnes de la propriété, ce qui protège votre contrôle.

Le propriétaire délégué se justifie dans des cas plus rares : une agence qui doit elle-même gérer les accès de vos équipes, configurer des associations ou intervenir sur les paramètres. Même là, posez la question : est-ce un besoin réel ou une commodité ? Accorder la propriété à une société externe revient à lui confier la clé de la porte et celle du coffre.

Un cas particulier mérite l'attention : les prestataires qui demandent d'être propriétaires au motif que leur outil l'exige. Dans la plupart des situations courantes, un accès complet suffit pour lire les données ou se connecter par l'API. Si un fournisseur insiste, demandez-lui quelle fonction précise requiert la propriété, puis vérifiez dans la documentation de l'outil. Une réponse vague est une information en soi.

Enfin, préférez toujours une adresse nominative à une adresse partagée ou à un mot de passe communiqué. Un accès nominatif se retire en un clic le jour du départ de la personne, sans changer le mot de passe de tout le monde, et laisse une trace claire de qui avait accès à quoi.

• Audit ponctuel ou reporting : utilisateur restreint.
• Suivi SEO régulier et demandes d'indexation : utilisateur complet.
• Gestion des accès ou des paramètres par un tiers : propriétaire délégué, avec une vraie justification.
• Jamais d'adresse partagée ni de mot de passe transmis par message.

Retirer un accès proprement

Pour retirer quelqu'un, retournez dans Paramètres, Utilisateurs et autorisations, repérez la ligne de la personne et utilisez le menu à droite pour supprimer l'accès. Un propriétaire peut aussi modifier le niveau d'un utilisateur au lieu de le supprimer, ce qui permet de rétrograder un ancien partenaire en lecture seule avant une fin de contrat.

Un point de vigilance concerne les propriétaires. Retirer une personne qui figure parmi les propriétaires vérifiés revient à défaire sa vérification, et les accès qui en dépendent peuvent en être affectés, notamment les propriétaires délégués qu'elle avait désignés. Avant de retirer un propriétaire, vérifiez donc qui a été délégué par lui, sinon vous risquez de couper l'accès d'un collègue sans l'avoir voulu.

La suppression dans l'interface ne suffit pas à elle seule pour un ancien prestataire qui avait installé son propre jeton de vérification. Si une agence a vérifié la propriété en ajoutant un fichier HTML, une balise ou un enregistrement DNS, ce jeton reste sur votre site après son départ. Tant qu'il est présent, la vérification peut rester valide. Dans Paramètres, la section Validation de la propriété liste les méthodes en place : supprimez celles qui appartiennent à des tiers et retirez le jeton correspondant du site ou de la zone DNS.

Pensez aussi aux comptes de service et aux outils connectés. Une adresse qui ressemble à un compte technique, ajoutée pour une intégration API ou un outil de reporting, apparaît dans la liste comme n'importe quel utilisateur. Si l'outil n'est plus utilisé, l'accès n'a plus de raison d'exister.

Quand le propriétaire vérifié quitte l'entreprise

C'est le scénario qui transforme une tâche administrative banale en incident. La personne qui a créé la propriété il y a quatre ans, avec son adresse personnelle ou une adresse professionnelle supprimée depuis, était la seule propriétaire. Personne d'autre ne peut ajouter d'utilisateur, et un consultant qui arrive ne voit rien.

La bonne nouvelle est que la perte du compte ne détruit pas automatiquement la vérification. Ce qui compte est la méthode utilisée. Un fichier HTML, une balise meta ou un enregistrement DNS qui reste en place continue de prouver le contrôle du site, que l'adresse du premier propriétaire existe encore ou non. Google revérifie régulièrement ces jetons, donc la validation tient tant qu'ils sont présents.

La marche à suivre est directe. Un membre de l'équipe qui contrôle le site ou le DNS se connecte avec son propre compte Google, ajoute la propriété et la vérifie à son tour avec l'une des méthodes proposées. Il devient alors propriétaire vérifié à part entière, sans avoir besoin de l'ancien compte. Il peut ensuite ajouter les autres utilisateurs et nettoyer ceux qui ne doivent plus y figurer.

Le point de blocage réel apparaît quand personne dans l'entreprise n'a accès au site, à l'hébergeur ni au DNS. Dans ce cas, la récupération de la propriété passe d'abord par la récupération de ces accès techniques auprès du registraire ou de l'hébergeur. C'est pourquoi la gouvernance de Search Console ne se limite jamais à Search Console.

Mieux vaut éviter la situation. Une règle simple suffit : au moins deux propriétaires vérifiés, rattachés à des adresses d'entreprise stables, par exemple une adresse de groupe ou de fonction, et jamais une adresse personnelle. Conservez aussi une méthode de vérification indépendante des personnes, comme l'enregistrement DNS ou le fichier HTML à la racine, plutôt que le lien avec un compte Analytics qui appartient à quelqu'un de précis.

Un audit d'accès à faire deux fois par an

Les accès s'accumulent comme les comptes dans n'importe quel système. Une revue courte, deux fois par an et à chaque changement de prestataire, évite les mauvaises surprises. Elle tient en quelques vérifications.

Ouvrez la liste des utilisateurs de chaque propriété importante et posez trois questions pour chaque ligne. La personne travaille-t-elle encore avec vous ? Son niveau correspond-il à son rôle actuel ? L'adresse est-elle nominative et sous votre contrôle ? Tout ce qui reste sans réponse claire se rétrograde ou se supprime, quitte à le rétablir sur demande.

Vérifiez ensuite la section de validation de la propriété. Combien de méthodes sont actives, et à qui appartient chacune ? Si une seule méthode existe et qu'elle dépend d'un compte individuel, ajoutez une seconde méthode indépendante avant qu'un incident ne vous y oblige.

Notez enfin le résultat dans un document interne : qui est propriétaire, par quelle méthode, et où se trouvent les jetons. Ce registre n'a rien de sophistiqué, mais il épargne des heures à la personne qui reprendra le dossier.

Une dernière vérification concerne la cohérence entre propriétés. Une entreprise qui possède une propriété de domaine et plusieurs propriétés de préfixe d'URL oublie souvent d'appliquer le même nettoyage partout. Un ancien prestataire retiré de la propriété principale peut rester présent sur une propriété secondaire créée pour un sous-domaine ou une version en HTTP.

• Chaque utilisateur est-il toujours actif et justifié ?
• Le niveau d'accès est-il le plus bas possible pour son rôle ?
• Y a-t-il au moins deux propriétaires vérifiés, sur des adresses stables ?
• Les jetons de vérification de tiers ont-ils été retirés du site et du DNS ?
• Toutes les propriétés liées au même site ont-elles été vérifiées de la même façon ?