Un administrateur Google Workspace peut-il définir les signatures mail de tous les utilisateurs ?

Nativement, en partie seulement. Dans la console d’administration Google, le paramètre Ajouter un pied de page applique un seul pied de page par unité organisationnelle, limité à 10 000 caractères, sans champs de l’annuaire ni HTML (une image uniquement par URL publique). Pour des signatures aux couleurs de la marque qui reprennent le nom, la fonction et le numéro de téléphone de chaque utilisateur, les administrateurs passent par l’API Gmail, qui écrit la signature comme propriété côté serveur de l’alias d’envoi.

Pourquoi mes utilisateurs se retrouvent-ils avec deux signatures ?

Parce que le pied de page de la console d’administration s’ajoute sous ce que l’utilisateur a déjà défini dans Gmail. Google ne remplace pas la signature de l’utilisateur, il ajoute le pied de page en dessous. Si vos collaborateurs ont leur propre signature et que vous activez un pied de page pour toute l’organisation, chaque message porte les deux.

Puis-je définir des signatures différentes par service dans Google Workspace ?

Nativement, pas au-delà des unités organisationnelles. Le pied de page est attribué à raison d’un modèle par UO : les services qui ne sont pas modélisés comme des UO distinctes ne peuvent donc pas recevoir de pieds de page différents. Restructurer votre arborescence d’UO pour l’adapter aux règles de signature est généralement un mauvais compromis, car les UO régissent aussi l’héritage des règles pour tout le reste.

Les signatures définies via l’API Gmail arrivent-elles sur les téléphones ?

Oui, dans le cas général. La signature est stockée côté serveur, sur l’alias d’envoi, et non comme un paramètre client propre à chaque appareil : elle s’applique donc sur le web et dans les applications mobiles Gmail sans rien installer. Seule exception : un utilisateur qui a défini dans l’application Gmail une signature mobile au niveau de l’appareil, laquelle prévaut sur cet appareil.

Gestion des signatures mail dans Google Workspace

Google Workspace offre les contrôles de signature natifs les plus faibles de toutes les grandes plateformes de messagerie, et l’API la plus propre pour y remédier. Comprendre quelles limites sont réelles et lesquelles sont mal contournées, c’est l’essentiel de la décision.

En bref : la console d’administration Google vous donne un pied de page par unité organisationnelle, limité à 10 000 caractères, sans champs de l’annuaire, sans HTML (une image uniquement par URL publique), et ajouté sous tout ce que l’utilisateur a déjà défini — d’où les doubles signatures. L’API Gmail écrit une vraie signature comme propriété côté serveur de chaque alias d’envoi : elle atteint le web et le mobile sans rien installer. C’est cet écart qui explique l’existence d’outils de signature pour une plateforme qui semble déjà inclure la fonctionnalité.

Ce que fait réellement la console d’administration

Les administrateurs Google Workspace disposent d’un seul et unique mécanisme natif : Ajouter un pied de page, dans les paramètres de conformité de Gmail. Il vaut la peine d’en préciser les contours, car son nom laisse espérer davantage que ce qu’il fait réellement.

Contrainte	Ce que cela signifie en pratique
Un modèle par unité organisationnelle	Ventes et Support ne peuvent pas avoir de pieds de page différents s’ils ne sont pas des UO distinctes. Restructurer les UO pour les signatures, c’est laisser une exigence cosmétique dicter l’arborescence qui régit toutes les autres règles dont vous héritez.
Pas de HTML	Texte mis en forme et une image par URL publique, mais ni mise en page ni identité visuelle. Des mentions légales, pas une signature.
Limite de 10 000 caractères	Rarement contraignante à elle seule, mais avec des mentions légales multi-entités ou multilingues, elle le devient plus vite que prévu.
Aucun champ de l’annuaire	Le pied de page est un texte statique. Il ne peut indiquer ni le nom de l’expéditeur, ni sa fonction, ni sa ligne directe, ce qui est pourtant toute la raison d’être d’une signature.
Ajouté sous la signature de l’utilisateur	Le problème de la double signature, ci-dessous.
Appliqué en transit	Les utilisateurs ne le voient jamais pendant la rédaction, et il est absent de la copie de leurs messages envoyés.
Dépouillé dans les réponses en texte brut	La mise en forme et les liens ne survivent pas : le pied de page se dégrade précisément là où les fils de discussion s’allongent.

Le problème de la double signature

C’est la plainte la plus fréquente au sujet des signatures dans Google Workspace, et il s’agit d’un choix de conception, pas d’un bug.

Google ne remplace pas ce qu’un utilisateur a configuré dans ses propres paramètres Gmail. Le pied de page s’ajoute en dessous. Une organisation qui existe depuis quelques années — où les collaborateurs se sont fait leur propre signature, puisque rien ne les en empêchait — active donc un pied de page commun à tous, et aussitôt chaque message sortant porte deux signatures : celle que le collaborateur a improvisée, puis l’officielle en dessous.

Aucun paramètre natif ne supprime la signature de l’utilisateur. Pour effacer les signatures existantes, il faut passer sur chaque compte, et rien n’empêche un utilisateur d’en définir une nouvelle l’après-midi même. C’est à ce moment que la plupart des administrateurs se mettent à chercher un outil, et il faut bien comprendre qu’ils ne cherchent pas une image de marque — ils cherchent un moyen pour que la signature définie par l’utilisateur cesse de compter.

Ce que fait l’API Gmail à la place

Côté API, Google fait nettement mieux que côté console d’administration, et mieux que l’équivalent chez Microsoft.

Une signature Gmail est une propriété côté serveur d’un alias d’envoi, modifiable via users.settings.sendAs.update. L’écrire demande un appel par utilisateur. Comme la valeur réside dans le profil de messagerie et non dans un client, elle s’applique partout où ce compte envoie des messages — le client web et les applications mobiles Gmail — sans logiciel installé, sans complément, sans gestion des appareils et sans modification du routage de la messagerie.

C’est plus important qu’il n’y paraît, car le mobile est l’éternel point faible des déploiements de signatures. Sur Microsoft 365, atteindre les téléphones suppose soit un complément à la prise en charge mobile limitée, soit un relais dans le flux de messagerie. Sur Google Workspace, c’est le même appel d’API que pour tout le reste.

Deux réserves, en toute honnêteté :

Les signatures mobiles définies sur l’appareil l’emportent malgré tout. L’application mobile Gmail possède son propre paramètre de signature, défini appareil par appareil. Un utilisateur qui en a défini une la verra prévaloir sur cet appareil. La plupart ne l’ont pas fait, mais « la plupart » ne veut pas dire « tous », et tout éditeur qui promet une couverture mobile inconditionnelle sur Gmail exagère.
Les utilisateurs peuvent revenir dessus. L’API écrit le même champ que celui que l’utilisateur peut changer dans ses propres paramètres. Rien n’empêche quelqu’un de revenir à sa version préférée dix minutes plus tard. Déployer côté client ne verrouille rien.

Le champ d’application nécessaire

La gestion des signatures nécessite gmail.settings.basic, que Google classe parmi les champs d’application sensibles. Pour une application distribuée à d’autres organisations, cela déclenche la vérification des applications OAuth par Google, et la publication sur Google Workspace Marketplace peut en plus exiger une évaluation de sécurité par un tiers. C’est une vraie barrière, avec de vrais délais, et c’est la principale raison pour laquelle le marché des signatures pour Google Workspace est plus mince que l’ampleur du problème ne le laisserait prévoir.

Pour des scripts internes à une seule organisation, la délégation au niveau du domaine évite entièrement la procédure de vérification. Si vous avez un administrateur compétent et quarante utilisateurs, un script est une réponse légitime, et nous préférons le dire plutôt que de prétendre le contraire.

Comment vérifier ce qui est réellement déployé

Avant de choisir un outil, mieux vaut connaître l’ampleur du problème. Google vous donne tout le nécessaire pour la mesurer, et la réponse est généralement pire que prévu.

1. Vérifier si un pied de page est activé pour toute l’organisation

Dans la console d’administration : Applications → Google Workspace → Gmail → Conformité → Ajouter un pied de page. Vérifiez-le pour chaque unité organisationnelle, pas seulement au niveau supérieur — les paramètres sont hérités, et une UO qui remplace le paramètre hérité est facile à oublier.

Si un pied de page est activé et que vos utilisateurs ont leur propre signature, chaque message qui quitte votre organisation porte actuellement les deux. C’est le problème de la double signature, et mieux vaut le confirmer avant de l’attribuer à autre chose.

2. Relire ce que chaque utilisateur a réellement

Les signatures se lisent avec la même API que celle qui les écrit. Pour chaque utilisateur, users.settings.sendAs.list renvoie tous les alias d’envoi du compte avec leur signature. Le champ d’application est gmail.settings.basic, et au sein d’une seule organisation, la délégation au niveau du domaine le couvre sans aucune vérification d’application.

Si vous préférez ne pas écrire de code, GAM le fait directement :

gam all users show sendas

3. Compter ce qui compte

Une sortie brute n’est pas une réponse. Quatre décomptes en font une :

Signatures vides. Les utilisateurs qui envoient sans rien du tout. Généralement plus nombreux qu’on ne l’imagine, et concentrés parmi les nouveaux arrivants.
URL d’images obsolètes. Cherchez avec grep, dans le HTML, le nom de fichier ou l’hôte de l’ancien logo. C’est la mesure la plus nette de la façon dont une refonte de l’identité visuelle a réellement été déployée.
Mentions légales manquantes. Recherchez une phrase caractéristique du texte imposé. Si vous avez une obligation légale, ce décompte correspond à votre exposition en matière de conformité.
Fonctions qui ne correspondent pas à l’annuaire. Comparez chaque signature à la fiche Admin SDK du même utilisateur. Les promotions sont la source de dérive la plus fréquente, car personne ne considère la signature comme faisant partie du changement.

Deux angles morts à connaître

Les alias ont leur propre signature. sendAs.list renvoie tous les alias d’envoi, pas seulement l’adresse principale. Un utilisateur doté d’un alias de rôle — support@, billing@ — a sur cet alias une signature distincte, qu’un audit naïf ne lisant que la première entrée manquera complètement.

Les signatures mobiles définies sur l’appareil sont invisibles. Le paramètre de signature propre à l’application mobile Gmail est stocké sur l’appareil, et non dans le profil de messagerie : aucune API ne peut donc le lire. Si un utilisateur en a défini une, vous ne pouvez ni la voir ni la compter. Tout audit — le nôtre compris — mesure la signature côté serveur, et mieux vaut le dire que de laisser croire à une couverture totale.

Ce que personne ne mesure

Tous les outils de signature du marché — pour Google Workspace comme ailleurs — imposent la signature au moment de sa création. Un modèle est défini, les signatures sont écrites, le travail est considéré comme terminé.

Aucun ne répond à la question que les administrateurs se posent vraiment six mois plus tard : qui a une signature non conforme en ce moment ?

La même API qui écrit une signature peut la relire. L’écart entre le modèle et la réalité devient donc mesurable — combien de collaborateurs ont encore l’ancien logo, combien n’ont pas de mentions légales, combien affichent une fonction qu’ils n’occupent plus depuis leur promotion l’an dernier. Sur une plateforme où les utilisateurs peuvent revenir sur leur propre signature, cette lecture n’est pas un bonus : c’est le seul moyen de savoir si le déploiement a tenu.

C’est autour de cela qu’Ascripto est construit, et c’est pourquoi notre offre gratuite est l’audit plutôt qu’un éditeur de modèles. Voir que 31 collaborateurs sur 47 ont une signature non conforme est un point de départ plus utile qu’un modèle vierge.

Choisir une approche

Si vous avez besoin de…	Utilisez
Mentions légales sur tous les e-mails sortants, rien de plus	Le pied de page de la console d’administration. Il est gratuit et suffit exactement pour cela.
Signatures aux couleurs de la marque avec les coordonnées de chacun, une seule organisation, du personnel technique disponible	L’API Gmail via la délégation au niveau du domaine. Un script et un modèle.
Règles par service, automatisation des arrivées et des départs, et savoir quand les signatures dérivent	Un outil géré. C’est là que les scripts cessent de passer à l’échelle, généralement le jour où quelqu’un part et où personne ne pense à lancer le script.
Verrouillage garanti, qu’un utilisateur ne peut pas annuler	Relais SMTP sortant. Plus lourd, et une dépendance dans votre flux de messagerie — à retenir uniquement si le verrouillage est vraiment l’exigence.

Si vous utilisez aussi Microsoft 365

Les environnements mixtes sont courants, et les deux plateformes ne sont pas comparables sur ce point. La voie programmatique de Microsoft, Exchange Web Services, est désactivée par étapes entre octobre 2026 et avril 2027, et Microsoft Graph n’a jamais pris en charge la gestion des signatures. Si une partie de votre organisation est sur Exchange Online, ce calendrier mérite d’être lu avant de choisir un outil, d’un côté comme de l’autre.