Extraire les signatures e-mail
sans se tromper de signataire
Un numéro de téléphone, c'est la partie facile. Une expression régulière en trouve un dans une signature en quelques millisecondes. La vraie question est de savoir à qui appartient ce numéro, si la ligne au-dessus est un intitulé de poste ou un service, et si la valeur est toujours d'actualité.
C'est cet écart qui explique pourquoi les démos d'extraction de signatures e-mail semblent meilleures que les boîtes aux lettres réelles. Une démo a un expéditeur, une signature, une langue et aucun historique cité. Une boîte de réception active en a plusieurs de chaque, souvent dans le même fil de discussion. Ce guide couvre ce que contient le bloc, les quatre points où l'extraction échoue, quels champs survivent selon les clients et les langues, et un flux de travail pour transformer les messages en table de contacts sans fusionner deux personnes en une seule ligne.
Points clés
- La signature peut être parfaitement lue et appartenir malgré tout à la mauvaise personne.
- Talon de Mailgun a trié correctement 92 % des lignes de signature et s'est tout de même trompé sur environ une ligne sur douze.
- Définissez d'abord le propriétaire de la ligne : l'adresse qui a envoyé le message, pas le nom de famille dans le corps.
Ce que contient réellement le bloc de signature
Une signature est un court bloc de contact à la fin d'un message, et presque rien dans sa disposition n'est normalisé. Un e-mail comporte six parties qui importent à un extracteur : l'en-tête, le nouveau message, la formule de politesse, le bloc de signature, l'historique cité et ce qui suit. Cette dernière partie est celle que l'on oublie. Il peut s'agir d'un avertissement de confidentialité, d'une bannière image, d'une réponse citée d'une autre personne, ou de rien du tout.
| Partie | Ce qu'elle contient | Pourquoi elle perturbe l'extraction |
|---|---|---|
| En-tête | De, À, Date | Le nom affiché peut être une initiale ou un intitulé de poste au lieu d'un nom complet |
| Corps | Le message lui-même | Il peut mentionner d'autres personnes, d'autres numéros de téléphone et d'autres entreprises |
| Formule de politesse | « Cordialement », « Merci », un nom | Elle ressemble au début d'une signature même lorsqu'aucun bloc de contact ne suit |
| Signature | Nom, poste, entreprise, téléphone, liens | L'ordre des lignes varie selon la personne, le client et la langue |
| Historique cité | Messages antérieurs et leurs signatures | Il ajoute les blocs d'autres personnes sous le bloc actuel |
| Pied de message | Avertissement, adresse du siège, bannière publicitaire | Il ajoute des chaînes ressemblant à des raisons sociales et une seconde adresse sous la vraie |
Un seul marqueur peut prétendre au statut de standard : une ligne contenant deux tirets et un espace, le séparateur de signature Usenet documenté dans la RFC 3676 de 2004. C'est une convention, pas une obligation, et de nombreux clients composent des signatures sans lui. Le HTML rend la frontière encore plus floue. Une signature présentée sous forme de tableau peut placer le nom dans une cellule, le poste dans une autre et le logo dans une troisième. Le texte est bien là ; l'ordre de lecture est celui du code HTML, qui n'est pas toujours celui que voit un humain.
Une signature n'a aucun marqueur d'ouverture obligatoire. Chaque extracteur doit deviner où commence le bloc.
L'échec est une question d'attribution, pas de correspondance de motifs
L'échec le plus problématique dans l'extraction de signatures d'e-mail est une signature correcte qui appartient à quelqu'un d'autre. Quatre situations produisent ce résultat, et toutes quatre sont assez courantes pour être anticipées.
Une chaîne de réponses avec deux signatures. Alice répond à Bob. Son message figure en haut ; le message cité de Bob et sa signature figurent en dessous. Un parseur qui prend le dernier bloc renvoie Bob. Un parseur qui prend le premier bloc renvoie Alice uniquement si elle a écrit au-dessus de la citation ; si elle a répondu en dessous, le premier bloc est aussi celui de Bob. Les deux règles sont positionnelles, et un fil de discussion ne donne à aucune des deux une position stable.
Une boîte aux lettres partagée ou adresse de rôle. Une adresse comme sales@ ou info@ peut être signée par une personne, par un bloc d'équipe en mentionnant deux, ou par un assistant écrivant pour un dirigeant. Si votre clé d'enregistrement est l'adresse de l'expéditeur, deux personnes deviennent un seul contact. Si votre clé est le nom dans la signature, une personne devient deux contacts lorsque le format du nom change. Dans un fil de discussion de la HubSpot Community de 2021, des utilisateurs de CRM décrivent le même enchevêtrement : un e-mail de demande arrive d'une adresse générique, les vraies coordonnées se trouvent dans le corps du message, et quelqu'un dissocie manuellement la personne de la boîte aux lettres (HubSpot Community).
Le même schéma apparaît dans les boîtes de réception de leads immobiliers par e-mail, où une alerte de portail et une feuille de présence à une journée portes ouvertes décrivent le même acheteur dans deux formats.
Un message transféré. « Pour info, voir ci-dessous » ne comporte aucune signature de la part de l'expéditeur du transfert. La seule signature dans le corps appartient à l'expéditeur d'origine. Une ligne associée à l'adresse de l'expéditeur du transfert porte désormais le numéro de téléphone de quelqu'un d'autre.
Aucune de ces situations n'est résolue par un meilleur motif. Elles se résolvent en décidant le propriétaire de la ligne avant l'extraction : l'adresse du message en cours de traitement, et non le dernier nom dans le corps. Lorsque l'entrée est un fil de discussion, vous avez aussi besoin de la limite du message, pas seulement de la limite de la signature. Les formats de nom créent une version plus réduite du même problème : un en-tête indiquant « J. Rivera » et une signature indiquant « Jordan Rivera, VP of Sales » désignent une seule personne dans deux formats, et la règle de fusion doit le savoir.
Un parseur qui prend le dernier bloc dans un fil de discussion renvoie la dernière personne qui a écrit, pas la personne qui a envoyé le message que vous traitez.
Là où la regex échoue : quatre cas concrets
La regex est fiable sur les champs ponctués et peu fiable sur les champs porteurs de sens, c'est-à-dire la majeure partie d'une signature. Les équipes qui analysent les signatures e-mail avec des règles commencent généralement par les numéros de téléphone, les adresses e-mail et les URL, car ces motifs fonctionnent. Les échecs apparaissent sur les lignes qui les entourent.
L'avertissement juridique sous la signature. Un avis de confidentialité, une raison sociale enregistrée et un siège social se trouvent souvent sous le vrai bloc. Une règle qui collecte tout après la formule de politesse lit l'avis comme une adresse, et un suffixe tel que LLC ou GmbH qu'il contient peut être capturé comme l'entreprise. Un lecteur sémantique peut distinguer un avis juridique de « Acme GmbH, Musterstrasse 1 », car l'avis est une phrase sur le message et l'adresse est un lieu.
Le numéro de téléphone qui apparaît deux fois. Une ligne du corps peut dire « appelez mon mobile » avec un numéro, tandis que la signature porte un téléphone fixe, un fax et un mobile. Une regex renvoie la première correspondance, qui peut être un numéro de fax ou un numéro client cité dans le message. Le libellé est le champ : Tel, Mobile, Fax ou 携帯 (mobile en japonais). Supprimez le libellé et l'extracteur renvoie un numéro sans savoir ce que c'est.
La signature qui ne suit pas l'ordre anglais. Les signatures anglaises ont tendance à suivre nom, intitulé de poste, entreprise. Les signatures japonaises suivent entreprise, service, intitulé de poste, nom, souvent sans espaces entre les mots. 部長 (chef de service) est un intitulé de poste, mais il ne figure pas dans un dictionnaire d'intitulés anglais, et le nom peut être écrit avec le nom de famille en premier. L'allemand Geschäftsführer (directeur général) et le français Directeur général créent le même décalage en sens inverse. Une règle qui attend des majuscules initiales et une virgule entre l'intitulé et l'entreprise n'a rien à quoi se raccrocher.
Le bloc sans texte, ou presque. Une signature uniquement composée d'une image ne contient aucun texte. Une réponse depuis un téléphone peut ne porter que « Sent from my iPhone », qui a la forme d'une signature d'une ligne et aucun des champs. Un tableau HTML peut inverser l'ordre visuel du nom et de l'intitulé lorsque les balises sont supprimées.
Une regex plus astucieuse ne résout pas cela. Lorsque Mailgun a ouvert le code source de sa bibliothèque Talon en 2013, elle utilisait un classifieur d'apprentissage automatique pour trier les lignes de signature des lignes non-signature. Sur un jeu de test de 2 912 lignes, le classifieur a correctement classé 92 % des lignes, ce qui laisse encore environ une ligne sur douze erronée (Mailgun). Il s'agit d'une classification de lignes, pas d'une affectation de champs. Les chercheurs qui ont annoté le corpus e-mail HPI en 2018 ont divisé les messages en cinq zones, dont la signature, car la tâche est d'abord une segmentation avant d'être une extraction (Hasso Plattner Institute).
La regex lit les formes, pas les rôles. Un numéro de fax et un numéro de mobile ont la même forme.
Quels champs survivent selon les clients et les langues
L'adresse e-mail, le nom complet, l'entreprise et l'intitulé de poste survivent dans la plupart des signatures ; le téléphone et l'adresse postale ne survivent que si l'extracteur conserve le libellé qui les identifie.
| Champ | D'où il provient | Ce qui le casse | Règle pratique |
|---|---|---|---|
| Adresse e-mail | En-tête | Alias de rôle, adressage plus, courrier transféré | La mettre en minuscules, retirer le tag plus et traiter les adresses de rôle séparément |
| Nom complet | Nom affiché de l'en-tête et signature | Initiales, ordre des noms, conventions de noms chinoises, japonaises et coréennes, titres de civilité | Préférer la forme la plus longue sans initiale ; conserver la valeur de l'en-tête comme repli |
| Intitulé de poste | Signature | Langue, abréviations, service versus intitulé | Stocker la chaîne d'origine ; mapper l'ancienneté plus tard |
| Entreprise | Signature et domaine e-mail | Marque versus entité juridique, suffixes, traductions | Prendre la raison sociale dans la signature ; n'utiliser le domaine que comme vérification |
| Téléphone | Signature | Plusieurs numéros, libellés, indicatifs pays | Une colonne par libellé : fixe, mobile, fax |
| Adresse postale | Signature | Ordre des lignes, position du code postal | La conserver comme bloc multiligne ; ne la découper que si vous avez besoin d'un champ pays |
| Site web et réseaux sociaux | Signature | Liens raccourcis, paramètres de suivi | Stocker l'URL brute et normaliser après extraction |
Le schéma est simple : un champ survit lorsque son sens provient d'un en-tête ou d'un libellé, et non de sa position dans le bloc. Un numéro de téléphone a besoin de son libellé ; une adresse postale a besoin que ses retours à la ligne restent groupés.
La langue est le second filtre. La FAQ de SigParser classe l'anglais en premier, l'allemand en deuxième, puis l'espagnol, le français, le portugais, le russe et le néerlandais (SigParser). C'est un aveu utile : de nombreux parseurs sont pensés pour l'anglais d'abord, et plus une signature s'éloigne des conventions anglaises, plus l'outil s'appuie sur un modèle de langage général plutôt que sur une liste d'intitulés.
Conservez la chaîne d'intitulé d'origine. Traduire Geschäftsführer par « Managing Director » pendant l'extraction est une décision irréversible, et elle peut être erronée pour le rôle juridique de la personne. Stockez l'original et mappez-le plus tard.
Un champ d'en-tête est stable parce que le client l'écrit. Un champ de signature n'est stable que si son libellé survit.
D'une boîte aux lettres à une table de contacts
La table se construit en deux passes : un message devient une ligne, puis les lignes sont fusionnées par adresse e-mail selon une règle de conflit explicite. Faire les deux à la fois, c'est ainsi que deux personnes deviennent un seul contact. La plupart des équipes qui extraient des coordonnées depuis les e-mails commencent par la seconde passe et découvrent que la première était erronée. Ce travail revient généralement à un responsable des opérations commerciales ou à un administrateur CRM, et il doit tenir pour le commercial qui transfère le message comme pour le contact dont les coordonnées sont stockées.
Choisir la clé d'enregistrement
Utilisez l'adresse e-mail complète de l'expéditeur, en minuscules et sans les balises plus. Donnez aux adresses de rôle telles que sales@ et info@ leur propre ligne ou une table d'entreprise distincte ; fusionner une personne dans une adresse de rôle masque les deux.
Définir la portée des messages
Commencez par les messages entrants sur une fenêtre fixe et excluez les expéditeurs automatisés avant l'extraction. Les réponses de calendrier, les notifications no-reply et les systèmes de ticketing portent rarement une signature humaine.
Nommer les colonnes comme champs
Nom complet, Intitulé de poste, Société, Téléphone fixe, Mobile, Pays, Date source. Évitez « Coordonnées », qui est un bloc informe, et « Téléphone », qui est ambigu. Si l'attribution compte, mettez-la dans le nom de la colonne : Nom de l'expéditeur de ce message.
Extraire un message par ligne
Conservez la date source et l'identifiant du message dans la ligne ; ces détails déterminent laquelle de deux valeurs est la plus récente lorsque la même personne réapparaît. Un parseur d'e-mails construit autour de colonnes nommées gère cette passe plus fiablement qu'un ensemble de règles par client.
Fusionner par clé
La valeur non vide la plus récente l'emporte pour l'intitulé de poste et le téléphone. Conservez la forme la plus longue du nom sans initiale. Conservez la raison sociale issue de la signature et n'utilisez le domaine que comme vérification. Lorsque deux valeurs entrent en conflit et qu'aucune n'est clairement plus récente, signalez la ligne au lieu de choisir en silence.
Vérifier avant l'import
Contrôlez les lignes comportant une adresse de rôle, un nom manquant, plus d'une signature dans la source, ou un intitulé dans une écriture que le relecteur ne peut pas lire. L'import est le mauvais moment pour découvrir qu'une ligne appartient à un collègue. La même discipline s'applique au mappage des colonnes analysées dans HubSpot.
| Champ | Règle de fusion | Pourquoi |
|---|---|---|
| Nom | Forme la plus longue non initiale | « J. Rivera » et « Jordan Rivera » désignent une seule personne |
| Intitulé de poste | Valeur non vide la plus récente | Les personnes changent de rôle, et les anciens e-mails conservent l'ancien intitulé |
| Société | Raison sociale issue du bloc de signature | Les noms de marque et les domaines e-mail s'écartent de l'entité enregistrée |
| Téléphone | Valeur la plus récente par libellé | Téléphone fixe et mobile sont des champs distincts, pas des valeurs concurrentes |
| Adresse | Bloc complet le plus récent | Une adresse partielle ne doit pas écraser une adresse complète |
La résolution silencieuse des conflits rend une table de contacts peu fiable. Signalez plutôt la ligne.
Où ImageToTable.ai intervient, et où il s'arrête
ImageToTable.ai peut exécuter la passe d'extraction sur les messages transférés et s'arrête avant les parties qui nécessitent un crawler de boîte aux lettres ou un CRM. Le mode de traitement est ce qui détermine si cela fonctionne.
Email Inbox attribue une adresse dédiée à chaque compte. Vous y transférez un message, ou vous configurez une règle dans Gmail ou Outlook pour transférer les e-mails correspondants. La boîte de réception propose trois modes de traitement : pièces jointes uniquement, corps uniquement, et pièces jointes plus corps. Pour le travail sur les signatures, le mode corps uniquement est le pertinent, car la signature se trouve dans le message, pas dans un fichier.
Ce qui se passe ensuite est l'Extraction de colonnes personnalisées : vous saisissez les noms de colonnes souhaités, et l'IA localise chaque valeur par son sens. Les noms deviennent les en-têtes de la table de sortie. Pour une signature, cela signifie Nom complet, Intitulé de poste, Société, Téléphone fixe et Mobile, le nom de colonne indiquant que la valeur doit provenir du bloc de l'expéditeur, et non d'un bloc cité. Chaque message devient une ligne. Les résultats s'exportent en Excel, CSV ou JSON, et l'add-on Google Sheets écrit les lignes dans la feuille ouverte, de sorte que la fusion se fait là où la liste se trouve déjà.
Le mode Révision vous permet d'ouvrir une ligne, de vérifier une cellule, de voir la valeur d'origine de l'IA et d'annuler une modification. C'est le contrôle manuel des lignes signalées par les règles de fusion, et c'est moins coûteux que de découvrir l'erreur après un import.
Trois limites comptent. Il n'y a pas de connexion à une boîte aux lettres ni d'exploration historique : l'outil lit ce que vous lui envoyez, pas les dix dernières années d'un compte Gmail. Il n'y a pas de détecteur de bloc de signature garanti : il lit le message et remplit les colonnes que vous avez nommées, ce qui signifie qu'un fil transféré avec trois signatures reste un seul document et que l'attribution peut être erronée. Et il n'y a pas de déduplication ni de synchronisation CRM : deux messages de la même personne produisent deux lignes, sauf si vous les fusionnez. La sortie est une table, pas une fiche de contact.
Le même problème de champs apparaît sur papier : une photo de carte de visite est un bloc de signature sans l'e-mail autour.
Les règles de confidentialité que vous héritez
Une adresse e-mail professionnelle, un intitulé de poste et une ligne directe sont des données personnelles dans l'UE et au Royaume-Uni, la table de contacts hérite donc d'une obligation de base légale et de conservation. Le fait que ces données étaient visibles dans un e-mail professionnel ne signifie pas qu'elles peuvent être conservées librement.
De nombreuses équipes s'appuient sur les intérêts légitimes pour les données de contact professionnelles. Les recommandations de l'ICO indiquent que les contacts professionnels s'attendent davantage à ce que leurs coordonnées professionnelles soient traitées, mais la base n'est pas automatique : vous avez besoin d'une analyse d'intérêt légitime documentée, d'un test de nécessité et d'un test de mise en balance. Le droit d'opposition est absolu pour le marketing direct, ce qui signifie qu'une opposition doit atteindre la table, pas seulement le lien de désabonnement d'une campagne (ICO).
La minimisation des données est la partie pratique. Collectez les champs que vous utiliserez, pas tous les champs que la signature propose. Un numéro de mobile personnel et un profil social ne sont pas nécessaires pour router un contact B2B, et les stocker augmente le coût d'une demande de suppression. Conservez la date source, fixez une durée de conservation et assurez-vous que le propriétaire de la boîte aux lettres sait que la table existe. Si vous traitez des contacts pour un client, le contrat et la politique de confidentialité doivent le couvrir. Ceci est une liste de contrôle, pas un avis juridique.
Collectez les champs que vous utiliserez, enregistrez leur provenance et supprimez-les lorsque la raison a disparu.
FAQ
Peut-on parser les signatures e-mail avec une regex ?
Pour les adresses e-mail, les numéros de téléphone et les URL, oui. Pour les noms, les intitulés de poste et les noms d'entreprise, pas de manière fiable. Une regex peut correspondre à la forme d'une valeur, mais elle ne peut pas déterminer si une ligne est un intitulé de poste ou un service, si un numéro est un fax ou un mobile, ou si le bloc appartient à l'expéditeur ou à une personne citée plus bas.
Pourquoi un parseur choisit-il la mauvaise personne dans un fil de discussion ?
Parce qu'un fil de discussion contient plusieurs signatures et qu'une règle positionnelle n'a aucune notion de propriété du message. Le dernier bloc appartient généralement à la dernière personne qui a écrit, qui peut être la personne citée, et non celle dont vous traitez le message. Transférez un message par ligne lorsque l'attribution compte.
Quels champs puis-je extraire de manière fiable d'une signature e-mail ?
L'adresse e-mail, le nom complet, la société et l'intitulé de poste constituent le noyau fiable. Le téléphone n'est fiable que si le libellé est conservé, utilisez donc des colonnes distinctes pour le téléphone fixe, le mobile et le fax. L'adresse postale est le champ le moins fiable, car l'ordre des lignes et la position du code postal varient selon les pays.
L'extraction de signatures fonctionne-t-elle pour le japonais, l'allemand ou l'arabe ?
Cela dépend si l'outil lit le sens ou correspond à des motifs anglais. Les signatures japonaises suivent souvent l'ordre société, service, titre, nom sans espaces, et des titres tels que 部長 sont absents des listes de titres anglais. Les titres allemands et français posent le même problème en sens inverse, et les écritures de droite à gauche brisent les hypothèses d'ordre des lignes. Un modèle sémantique gère mieux ces cas qu'une liste de mots-clés, mais le résultat doit tout de même être vérifié.
ImageToTable.ai peut-il analyser toute ma boîte aux lettres ?
Non. Il traite les messages que vous transférez à l'adresse de votre boîte de réception e-mail, ou les e-mails qui y sont acheminés par une règle de transfert. Il n'y a aucune connexion à la boîte aux lettres, aucune exploration historique et aucun accès aux e-mails que vous n'avez pas transférés.
Est-il légal de stocker les coordonnées issues des signatures e-mail ?
Dans l'UE et au Royaume-Uni, généralement au titre des intérêts légitimes si vous documentez l'évaluation, ne collectez que ce dont vous avez besoin, fixez une durée de conservation et respectez les objections. Les objections au marketing direct sont absolues. Les règles diffèrent hors de l'UE et du Royaume-Uni, vérifiez donc la juridiction de vos contacts.
La signature est une convention, pas un formulaire
Une signature a été conçue pour terminer un message avec politesse, non pour alimenter une base de données. C'est pourquoi le bloc n'a aucun marqueur fiable et pourquoi la même personne peut apparaître comme deux enregistrements sur cinq e-mails. L'étape d'extraction peut être automatisée ; la décision de savoir à qui appartient une ligne et quelle valeur est à jour reste un jugement sur la boîte de réception.
Envoyez un e-mail transféré avec une signature que vous connaissez, nommez les colonnes dont vous avez réellement besoin et vérifiez si la ligne appartient à la personne attendue. Le premier signataire erroné est plus facile à repérer ici que dans un import CRM.