Que faut-il penser d’AMP for email, le nouveau langage dédié à l’email ?

En avril 2018, Google a lancé AMP for email, une déclinaison de son langage AMP dédiée à l’email et dont le principe reste le même : s’adapter aux usages en permettant plus d’interactivité et une meilleure expérience en restant un maximum dans l’email.

En avril dernier, la firme de Mountain View a annoncé le recrutement de trois autres webmails importants pour soutenir son initiative : Outlook.com, Yahoo! et Mail.ru. La révolution semble en en marche car Google a annoncé dans la foulée que les « mails interactifs » seront activés par défaut sur son interface GMail dès juillet 2019.

Il se passe donc quelque chose dans le monde de l’email, sans que l’on sache précisément quels bénéfices peuvent être tirés ni quels freins peuvent être rencontrés dans ce nouveau champ des possibles pour les campagnes email.

AMP for email : quels usages ?

Lorsque Google a officiellement déployé AMP (Accelerated Mobile Pages, ou pages mobiles accélérées) en 2015, sa promesse était d’offrir une technologie grâce à laquelle les développeurs pourraient créer des pages web qui se chargent plus rapidement sur les smartphones et tablettes.

AMP for email ambitionne de dépasser cette promesse en incluant de l’interactivité au sein même des emails. Cette interactivité existe déjà (lire notre article « 7 idées créatives pour augmenter l’interactivité de vos emails ») mais elle correspond aujourd’hui davantage à de la débrouillardise : pour faire un slider dans un emailing aujourd’hui, il faut jouer avec des boutons en HTML que l’on va transformer avec du CSS dans un contexte où le JavaScript – qui permet généralement l’interactivité sur le web – n’est pas accepté dans les emails pour des raisons de sécurité.

Dès lors, l’AMP propose de résoudre ce problème en autorisant un nombre limité d’actions JavaScript pour des expéditeurs dûment identifiés. Par exemple, AMP for email permet d’intégrer un slider pour faire défiler des produits en quelques lignes de code et sans devoir bricoler avec l’HTML ou le CSS.

En somme : faire mieux avec moins de code. Et une dimension plutôt vertueuse en bonus qui oblige l’envoyeur à s’authentifier, permettant de lutter indirectement contre le spam ou le phishing.

Des freins à l’adoption de l’outil

Si la profession de foi de l’AMP for email semble présenter un monde idéal, il existe en réalité de nombreux freins à l’adoption de l’outil.

Le premier d’entre eux est le faible niveau de compatibilité avec les messageries : si GMail, Outlook.com, Yahoo! et Mail.ru permettent de couvrir – selon les cibles – quasiment 50% des emails commerciaux envoyés en France, ce chiffre représente à l’heure actuelle toujours une probable minorité de vos destinataires.

Par ailleurs, côté routage, la majorité des ESP (fournisseurs de services email) n’ont pas intégré AMP for email. Hormis Sparkpost, Sendgrid, Mailgun, Amazon SES et eSputnik qui l’ont intégré à l’heure où nous publions cet article, la plupart des acteurs majeurs n’ont pas pris le pli : AMP for email requiert en effet d’une part de gros investissements, auxquels ne consentiront pas les ESP avant de pouvoir évaluer le niveau d’adoption – donc de rentabilité – d’AMP.

D’autre part il nécessite une approbation de Google pour être autorisé à l’utiliser, ce qui n’est pas neutre en termes de configuration et d’interfaçage pour les éditeurs. Le fait de s’authentifier et donc de montrer patte blanche auprès de Google pour avoir des emails compatibles AMP4EMAIL permet à la firme de Mountain View d’assoir son emprise sur l’email, une technologie au sein de laquelle elle n’est pas encore monopolistique. D’un point de vue éthique, cela pose nécessairement question.

Enfin, côté utilisateur, il y a une réalité qui ne reflète pas réellement la promesse du « moins de code » : si cette affirmation se vérifie strictement pour AMP, il faut considérer que cette portion de code s’ajoute à celles du texte et de l’HTML, qui subsistent. Dès lors, les concepteurs d’e-mail sont confrontés à un problème de temps d’intégration et de maintenance du code.

Une tendance à observer sur le temps long

Il est encore trop tôt pour émettre des conclusions à propos d’AMP for email : surveiller son évolution et son adoption sur le marché de l’emailing semble essentiel pour pouvoir avoir la bonne mesure de ce que cette technologie peut apporter (ou non) à vos emails.

Sa prise en charge par les principaux acteurs du marché sera un élément déterminant, tant en termes de routage que de délivrabilité et de support par les webmails. Enfin, la question des cas d’usage se posera nécessairement : proposer un slider à des clients est une bonne chose, mais comment intégrer cette étape dans le tunnel de conversion ? Le parcours d’achat se fera-t-il exclusivement dans l’email ? Si ce n’est pas le cas, à quel moment la bascule s’opère-t-elle vers le navigateur ?

Des annonceurs comme Booking ou Pinterest ont déjà développé des cas d’usage, mais il faut observer si ceux-ci vont se répandre ou se cantonner à une petite part de l’email marketing. Cela dépendra impliquera notamment pour les annonceurs de trouver un ESP qui supporte l’AMP for email et de pouvoir l’expérimenter sur les plateformes qui l’autorisent.

Sur le temps long, si tous les freins précités sont levés, l’AMP for email pourra tenir toutes ses promesses et achever la révolution de l’emailing qu’il prépare.