La plupart des gens pensent l'email comme un texte avec un bouton à la fin. Un message qui dit quelque chose, et un appel à l'action qui espère un clic.
Je le pense autrement. Un email est une interface. Il a des états. Il a une navigation. Il a une logique de flux. Et surtout — il a un seul objectif : amener l'utilisateur à l'action suivante avec le moins de friction possible.
Ce changement de perspective change tout dans la façon de concevoir ses emails.
L'email comme premier écran
Quand une médiathèque reçoit mon mail de prospection, elle ne reçoit pas un texte. Elle reçoit un écran avec deux actions possibles :
- Oui, envoyez-moi un devis → elle entre dans le tunnel de vente
- Non merci → elle entre dans le tunnel de feedback
C'est exactement la logique d'un écran d'onboarding dans une application mobile. Une question. Deux chemins. Zéro bruit parasite.
La différence avec un email classique : je ne lui demande pas de répondre. Je lui demande de cliquer. Répondre demande de la rédaction, de la réflexion, de l'effort. Cliquer demande une demi-seconde et un index.
La friction tue la conversion. Chaque étape supplémentaire entre l'intention et l'action coûte des utilisateurs.
C'est vrai dans une app. C'est vrai dans un email.
Les boutons comme navigation
Dans une application, les boutons naviguent vers des écrans. Dans mon email de devis, c'est exactement ce qui se passe — chaque bouton amène vers une page dédiée, contextualisée, avec les bonnes informations au bon moment.
Le mail de devis contient quatre actions distinctes :
1. Voir les thématiques → page publique de mon site de conférences. Pour le responsable culturel qui veut affiner le sujet avant de s'engager.
2. Proposer des dates → formulaire de disponibilités pré-rempli avec le numéro de devis. Pour celui qui est convaincu et veut passer à la planification.
3. Signer le devis en ligne → page de signature électronique avec canvas HTML5. Pour celui qui est prêt à valider.
4. Transmettre à ma direction → lien mailto: pré-rempli avec le sujet, le corps du mail, et le lien vers le devis. Pour celui qui n'a pas le pouvoir de signature mais veut faire suivre.
Ce dernier bouton est souvent le plus sous-estimé. Dans une structure culturelle publique, la personne qui reçoit le mail n'est presque jamais celle qui signe. En lui donnant un bouton "transmettre à ma direction" avec un mail pré-rédigé, je supprime une étape entière du processus décisionnel — et je m'assure que le bon message arrive au bon interlocuteur, formulé correctement, sans que mon contact ait à rédiger quoi que ce soit.
mailto:?subject=Proposition d'intervention : Démystifier l'IA
&body=Bonjour,
Je vous transmets ce projet de conférence sur l'IA.
Vous trouverez le récapitulatif et le devis ici : [lien]
Qu'en pensez-vous ?
Un bouton. Un mail pré-rédigé. Zéro effort pour mon contact.
Le kit de communication comme feature
Une app bien conçue anticipe les besoins suivants de l'utilisateur. Quand quelqu'un accepte un devis de conférence, son besoin suivant c'est : communiquer sur l'événement. Affiche, texte de présentation, codes couleurs pour les visuels.
J'aurais pu attendre qu'il me les demande. J'aurais pu les envoyer dans un second mail. J'ai choisi de les inclure directement dans le mail du devis — parce que c'est là qu'il en a besoin, au moment où il vient de décider de signer.
Le mail contient donc :
- Le PDF du devis
- Ma photo de profil
- Une affiche PNG haute définition
- Deux textes de présentation prêts à copier (version courte et longue)
- Les codes couleurs de la charte graphique
- La police typographique utilisée (Montserrat, Google Fonts)
Ce n'est pas un gadget. C'est une réduction de friction. Chaque élément que je fournis proactivement est une relance que je n'aurai pas à gérer, une question à laquelle je n'aurai pas à répondre, un délai que je supprime dans le processus de décision.
Le délai aléatoire comme design d'expérience
Un devis qui arrive 9 secondes après un clic casse l'illusion. Le destinataire comprend immédiatement qu'il est dans un tunnel automatisé — et ça change sa perception de la relation.
J'ai introduit un délai aléatoire entre 3 et 8 minutes entre le clic et l'envoi du devis. C'est suffisant pour que ça ressemble à quelqu'un qui a pris le temps de préparer le document. Pas trop long pour créer de l'impatience.
$delay = rand(180, 480); // 3 à 8 minutes
$sendAfter = date('Y-m-d H:i:s', strtotime('+' . $delay . ' seconds'));
C'est du design d'expérience appliqué à un email automatisé. Exactement comme un skeleton screen dans une app qui simule un chargement pour que l'interface paraisse plus réactive — même si les données sont déjà là.
L'objectif n'est pas de tromper. C'est d'éviter que la mécanique soit visible. Une bonne automatisation ne devrait pas ressembler à une automatisation.
Ce que ça implique dans la conception
Penser l'email comme une app, ça change la façon de le construire :
On ne rédige plus, on conçoit. La question n'est plus "qu'est-ce que je veux dire ?" mais "quelle action je veux déclencher, et comment je supprime les obstacles entre l'intention et l'action ?"
Chaque bouton est un écran suivant. Avant d'ajouter un CTA, je me demande vers quoi il pointe, ce que l'utilisateur trouvera là, et si cette page est prête à le recevoir dans le bon contexte.
On anticipe le besoin suivant. Un utilisateur qui vient de signer a besoin d'assets de communication. Un utilisateur qui vient de s'inscrire a besoin d'instructions claires. Ces besoins sont prévisibles — autant les satisfaire proactivement plutôt que de les gérer en réactif.
La friction est l'ennemi. Chaque champ de formulaire supplémentaire, chaque étape de confirmation, chaque mail qu'on leur demande de rédiger eux-mêmes — c'est une fuite dans le tunnel. On colmate les fuites avant de lancer la campagne.
L'email n'est pas un canal. C'est une surface.
Les grandes apps ont des surfaces : l'écran principal, les notifications push, les widgets. L'email est une surface comme les autres — avec ses contraintes propres (pas de JavaScript, clients mail capricieux, attention limitée) mais aussi ses avantages uniques : il arrive dans un espace personnel, il persiste, il peut être transféré, il peut contenir des pièces jointes.
La plupart des emails d'entreprise traitent cette surface comme un Post-it. Un texte, un lien, une signature. J'essaie de la traiter comme un écran — avec une architecture d'information, une hiérarchie visuelle, et une logique de flux pensée pour l'utilisateur qui est de l'autre côté.
Ce n'est pas plus compliqué. C'est juste une question de perspective.
Top comments (0)