📍 Article principal : Google Workspace pour PME : architecture et gouvernance
Ce tutoriel détaille la mise en service d’un tenant Workspace : domaine, MX, OU, utilisateurs, groupes, SPF, DKIM.

Objectif

Configurer un tenant Google Workspace fonctionnel pour une organisation de 5 à 80 utilisateurs : domaine vérifié, mail entrant fonctionnel, structure organisationnelle initiale, premiers comptes, authentification email correcte (SPF + DKIM).

Prérequis

Nom de domaine acheté chez un registrar, accès administrateur à la zone DNS (ajout d’enregistrements TXT, MX, CNAME).
Carte bancaire internationale Visa/Mastercard ou carte virtuelle prépayée acceptant les abonnements récurrents (Mixx by Yas, Orange Money pour la zone CEDEAO).
Adresse email de récupération externe au domaine à configurer (un super-admin ne peut pas recourir à une adresse hébergée sur le domaine qu’il administre).
Niveau : intermédiaire — DNS, console d’administration web.
Temps : 60 à 90 minutes hors propagation DNS.

Étape 1 — Réunir les informations administratives

Le formulaire de souscription Google demande : raison sociale, adresse complète, numéro de téléphone joignable (vérification SMS ou appel), pays, nombre d’utilisateurs prévu, identité du super-administrateur, email de récupération externe. Réunir ces éléments avant de commencer permet de compléter le formulaire en une session sans interruption.

Étape 2 — Création du tenant

Sur https://workspace.google.com/business/signup/welcome, sélectionner le plan, renseigner la raison sociale, le pays, le nombre d’utilisateurs, le domaine principal (sans www ni https://). Définir le compte super-administrateur initial — l’adresse admin@<domaine> est plus pérenne qu’une adresse nominative pour transmission ultérieure.

Choisir un mot de passe long et le stocker immédiatement dans un gestionnaire (Bitwarden, 1Password, KeePass). À la création, l’accès à admin.google.com est actif mais le tenant est en mode dégradé tant que le domaine n’est pas vérifié.

Étape 3 — Vérification du domaine via TXT

Dans Compte → Domaines → Gérer les domaines, cliquer Ajouter le code de vérification. Google fournit une chaîne du type google-site-verification=AbCdEf1234567890.

L’enregistrement à publier dans la zone DNS du domaine :

Type  : TXT
Hôte  : @
Valeur: google-site-verification=AbCdEf1234567890
TTL   : 3600

Coller la chaîne sans guillemets. Sauvegarder dans la zone DNS, puis cliquer Vérifier côté Workspace. La validation prend de quelques secondes à 30 minutes selon la propagation. Pour confirmer la publication côté DNS :

dig +short TXT mondomaine.tld
# Windows
nslookup -type=TXT mondomaine.tld 8.8.8.8

La sortie attendue contient la chaîne google-site-verification=.... Si elle est absente, l’enregistrement a probablement été créé sur un sous-domaine au lieu de la racine — corriger l’hôte (@) côté registrar.

Étape 4 — Configuration des MX

Dans Applications → Google Workspace → Gmail → Configuration MX, Google publie l’enregistrement à utiliser. Depuis 2023, Google a unifié les MX en un enregistrement unique :

Type     : MX
Hôte     : @
Priorité : 1
Valeur   : smtp.google.com
TTL      : 3600

Avant de sauvegarder, supprimer tous les anciens MX (typiquement mx.<registrar>). La cohabitation des MX répartit les emails entrants entre Google et l’ancien serveur, ce qui produit des emails délivrés au mauvais endroit.

Vérification une fois la propagation effectuée :

dig +short MX mondomaine.tld
# Sortie attendue : 1 smtp.google.com.

Tester en envoyant un email depuis un compte externe (Gmail personnel, Yahoo) vers admin@mondomaine.tld. Réception attendue dans la boîte Workspace en moins de 2 minutes.

Étape 5 — Création des Organizational Units

Dans Annuaire → Unités organisationnelles, cliquer Créer une unité organisationnelle. Une OU = une politique différenciée. Sans politique différente, créer une OU n’a pas d’effet pratique.

Structure initiale fonctionnelle pour une PME :

OU racine (créée automatiquement) — politique par défaut.
OU Externes — politique restrictive (Drive limité, partages externes restreints).
OU Comptes service — politique excluant la 2SV obligatoire (préparée pour comptes non humains).

D’autres OU s’ajoutent quand un besoin de politique différenciée apparaît. Hiérarchie maintenue à 2 niveaux maximum pour la maintenance.

Étape 6 — Création des utilisateurs

Dans Annuaire → Utilisateurs → Ajouter un nouvel utilisateur : prénom, nom, adresse principale, OU de destination, mot de passe initial, option Demander à l’utilisateur de modifier le mot de passe à la prochaine connexion cochée.

Pour la création en masse, l’import CSV est accessible via Annuaire → Utilisateurs → Plus → Importer des utilisateurs. Le modèle CSV impose les colonnes :

First Name [Required]
Last Name [Required]
Email Address [Required]
Password [Required]
Org Unit Path [Required]

Le chemin OU prend la forme /Commercial avec slash en tête. Tester d’abord avec 2 ou 3 utilisateurs avant l’import en masse pour valider le mot de passe initial transmis et la connexion utilisateur.

Étape 7 — Création d’un groupe Google

Dans Annuaire → Groupes → Créer un groupe : nom, description, adresse email du groupe, propriétaire. Ajouter les utilisateurs comme membres via la fiche du groupe.

Les groupes Google servent simultanément de listes de diffusion email et de listes d’accès aux ressources (drives partagés, calendriers). Partager systématiquement les ressources à des groupes plutôt qu’à des individus rend la maintenance linéaire avec le turnover.

Étape 8 — Authentification email (SPF + DKIM)

Sans SPF ni DKIM, les emails sortants sont marqués suspects par les filtres anti-spam des destinataires. Configurer ces deux mécanismes est obligatoire.

SPF

Publier dans la zone DNS :

Type  : TXT
Hôte  : @
Valeur: v=spf1 include:_spf.google.com ~all
TTL   : 3600

~all = softfail. Les serveurs non listés sont marqués suspects sans rejet strict — c’est la valeur officiellement recommandée par Google (voir Set up SPF dans le centre d’aide Workspace). Le mécanisme -all (rejet strict) existe mais n’est pas la recommandation Google : il provoque des rejets nets si un expéditeur légitime sort du périmètre déclaré (par exemple un outil tiers qui envoie en votre nom). DMARC offre une couche d’application plus souple à mettre en place ensuite.

DKIM

Dans Applications → Google Workspace → Gmail → Authentifier les emails, cliquer Générer un nouvel enregistrement. Google propose deux longueurs de clé : 2048 bits (recommandé si le registrar le supporte) ou 1024 bits (fallback pour les registrars qui ne supportent pas les TXT longs). Le sélecteur par défaut est google ; le TXT se publie sur google._domainkey.mondomaine.tld. Revenir dans la console et cliquer Démarrer l’authentification.

Vérification

Envoyer un email depuis le compte Workspace vers une adresse Gmail personnelle externe. Ouvrir le mail, menu trois points → Afficher l’original. La sortie attendue contient :

SPF:   PASS
DKIM:  PASS
DMARC: (absent ou PASS)

Si SPF ou DKIM affichent FAIL, vérifier que les enregistrements DNS ont propagé (commande dig) et que la console Workspace a bien démarré l’authentification DKIM.

Erreurs fréquentes

Erreur	Cause	Solution
Vérification TXT bloquée > 30 min	TXT publié sur sous-domaine	`dig +short TXT <domaine>` ; corriger l’hôte à `@`
MX cohabite avec l’ancien hébergeur	Anciens MX non supprimés	Supprimer tous les autres MX, ne conserver que `1 smtp.google.com`
Email de récupération inutilisable	Email de récupération sur le domaine du tenant	Définir un email externe (Gmail perso, autre domaine)
Emails sortants en spam	SPF/DKIM non configurés	Procéder à l’étape 8
Import CSV en échec	Colonnes mal nommées ou OU absente	Repartir du modèle officiel téléchargé depuis la console
Compte super-admin verrouillé	Mot de passe oublié + 2SV sur appareil perdu	Récupération via téléphone et email externes (configurés à l’étape 1)

Tutoriels associés

Mettre en place les Drive partagés Google Workspace — étape suivante.
Déployer la 2SV obligatoire dans Google Workspace — à enchaîner dans les 30 jours.

Références officielles

FAQ

Délai officiel de vérification de domaine ?
Délai maximum documenté : 72 heures. En pratique, la majorité des vérifications passe en moins d’une heure ; les délais plus longs viennent en général de l’enregistrement publié sur un sous-domaine plutôt que sur la racine.

Est-il possible de changer le domaine principal après création ?
Oui via la procédure domain swap : déclarer un domaine secondaire, le promouvoir en principal, retirer l’ancien. Toutes les adresses email changent et les utilisateurs doivent migrer vers les nouveaux alias.

Quand configurer DMARC ?
Après stabilisation de SPF et DKIM, en démarrant avec p=none (collecte de rapports sans action), puis bascule progressive vers p=quarantine et p=reject selon l’analyse des rapports.

Combien d’OU créer initialement ?
Le minimum imposé par un besoin de politique différenciée. Une PME démarrant à neuf n’a souvent besoin que de l’OU racine plus une OU Comptes service au moment du déploiement de la 2SV.

Faut-il forcer le changement de mot de passe à la première connexion ?
Recommandé pour tous les comptes utilisateurs créés par l’admin avec un mot de passe initial — l’utilisateur choisit lui-même le mot de passe et l’admin n’en garde pas connaissance.

La 2SV peut-elle être imposée dès la création des comptes ?
Oui via Sécurité → Authentification → Validation en deux étapes, mais le déploiement par opt-in puis enforcement progressif est documenté comme moins risqué que l’imposition immédiate (voir le tutoriel 2SV).