Bienvenue sur Double Slash, le podcast dédié aux outils et aux techniques pour le développement
web.
Bonjour, je vous remercie et à tous, bienvenue sur ce nouvel épisode de Double Slash, comme
d'habitude, on est avec Alex.
Salut Alex, comment ça va ?
Salut Patrick, salut tout le monde.
Écoute, je suis super content de devenir pour cet épisode-là.
Avant de commencer et de taper directement dans le cœur du sujet, on voudrait remercier
tous ceux qui nous soutiennent et qui contribuent à nous aider sur Double Slash à travers
le sponsoring, les commentaires, parler du podcast à vos collègues.
Ça fait toujours plaisir et donc vous pouvez nous soutenir directement depuis le site
ou à travers une action de communication.
On vous en remercie.
Bien, carrément.
Et donc aujourd'hui, épisode spécial email.
Donc j'ai envie de dire email, c'est un peu pour ceux qui en ont déjà fait, c'est
un petit peu limite le cauchemar des développeurs parce que c'est un autre monde en fait par
rapport à ce qu'on connaît.
Et donc on va parler de tout ça.
On va passer par le template, les types d'emails, les outils disponibles pour avoir les emails,
comment faire en sorte que les gens reçoivent les emails aussi.
Ça c'est important quand même.
Qui puissent les lire aussi.
Que ça soit visible.
Il y a plein d'outils, il y a plein de pratiques.
Donc on va faire le tour de tout ça.
On va passer par toutes les étapes.
Et puis comme ça, ça vous permet d'avoir un petit peu les bases pour les gens qui
n'ont jamais vraiment fait.
Et puis pour ceux qui en font déjà, peut-être découvrir des outils pour s'améliorer.
Voilà, c'est parti.
Et carrément, je pense que c'est important de commencer par vraiment les bases et de
bien distinguer deux types d'emails.
Il y a vraiment les emails qu'on dit en fait transactionnels.
Là, c'est un email qui est envoyé en one shot à une seule personne.
Donc typiquement, ça va être le reset password.
Ça va être la validation de commande.
Ça va être toutes ces choses là.
Là, pour le coup, il y a une personne, un email.
Et il y a un autre type d'email où là, c'est plus des newsletters ou vraiment de
l'envoi en masse.
Et là, c'est un email qui est envoyé à plusieurs personnes.
Et donc ça, en fait, c'est vraiment des campagnes ou des actions de promotion, de
communication.
Il faut bien distinguer du transactionnel vraiment de l'envoi en masse.
Souvent, le transactionnel, c'est plutôt notre rôle de développeur de s'occuper de
ces emails là parce que c'est souvent automatique.
On met en place la structure, tous ça, les outils pour le rendre automatique.
Quelqu'un passe une commande sur e-commerce automatiquement sur une confirmation, etc.
Après, tout ce qui est email de promotion, tout ça, newsletter.
Là, on passe du côté un petit peu.
Il faut collaborer avec le market souvent.
Donc on se retrouve à collaborer avec des personnes qui ne sont pas forcément techniques,
tout ça, qui avaient des outils faciles à utiliser.
Donc voilà, il y a vraiment ces deux aspects différents.
Et donc on va parler de ça.
Yes.
Et après, souvent, le plus facile, souvent, c'est ce qu'on va recommander pour des toutes
petites boîtes où ils ne sont pas structurés.
Il n'y a pas encore une marque très forte ou pour aussi en vitesse d'implémentation.
C'est des solutions un peu toutes prêtes à être utilisées.
Oui, il y a plein d'outils qui sont hyper complets.
Des plateformes, maintenant, elles sont même, elles se vendent à la base.
C'est vrai que si tu prends, pour citer, Send in Blue qui est devenu Brevo, à la base,
c'était vraiment un système d'envoi d'emails.
Aujourd'hui, c'est plus des plateformes de marketing.
Ils se vendent comme ce temps, en fait.
Donc même Mailchimp, tout ça, Mailchip, tout ça, c'est vraiment des plateformes qui
sont tout en un où ça gère.
Tu gères tes listes d'abonnés, etc.
Tu relances et tout.
Et souvent, c'est vachement plus adapté parce que déjà, sur Brevo, par exemple,
tu as une offre gratuite qui est assez généreuse, 300 emails par jour, je crois.
Donc c'est quand même assez fat pour les associations, tout ça.
C'est assez large, en général.
Ça peut couvrir largement les besoins à savoir que sur l'offre gratuite,
il me semble que tu n'es pas en marque blanche, tu es obligé de partager leur logo.
Mais sur Mailjet ou Mailchip, c'est quasiment la même chose.
Quand c'est gratuit, il faut bien que le mec mette son logo quelque part.
C'est le jeu, c'est normal.
Moi, ça ne me choque pas du tout, ils ont bien raison de faire ça.
Mais du coup, ça, c'est vraiment des outils qui sont...
Alors moi, je donne l'exemple parce que je suis dans des associations où je fais de la voile,
tout ça, machin.
Typiquement, ils utilisent Brevo et voilà, la personne qui n'est pas du tout technique,
mais alors pas du tout.
Elle fait ses emails, machin, tout ça.
Elle envoie, elle-même, donc c'est nickel.
Je ne peux pas bien me l'occuper.
C'est vraiment pour les emails de newsletters, c'est par là.
C'est nickel.
Et par contre, c'est bien au-delà, en fait, ce que tu disais.
C'est bien au-delà d'une simple envoie de newsletters.
Tu as vraiment...
Ils mettent vraiment leur plus-value sur la gestion, on va dire, du marketing,
parce que tu vas pouvoir faire aussi des emails, tu vas pouvoir faire de l'automation,
tu vas pouvoir faire plein de choses tout autour de l'email.
Aujourd'hui, c'est ça, ces plateformes, elles proposent vraiment tout un écosystème marketing.
Ça part du formulaire que tu vas mettre sur ton site ou son application pour récolter
les emails, parce que c'est quand même important d'avoir des emails pour pouvoir envoyer
des newsletters.
Ça, c'est clair.
Et ensuite, tu vas gérer ta liste, tu vas faire des automatisations en fonction de l'événement,
etc.
Donc, si c'est l'anniversaire de la personne, tu vas envoyer l'email.
Enfin, voilà, il y a plein de trucs comme ça.
Donc là, on est vraiment dans la partie outil facile à prendre en main.
Un tarif quand même souvent raisonnable quand même et surtout pour les non-techs.
Donc hyper accessible.
Oui, hyper accessible.
Alors, par contre, ce qui est souvent complexe, c'est quand on veut commencer à interfacer
entre ton application, ton site et ces services-là, là, ça se complexifie parce que, voilà,
il faut utiliser leurs API, tout ça.
Là, on se...
Voilà, on devient sur des trucs spécifiques pour envoyer des emails.
Pour l'exemple de Sendin Blue, enfin, bref, j'ai du mal à dire bref, parce que je suis
tellement habitué à Sendin Blue.
Ouais.
C'est un peu comme X, et Twitter.
C'est les anciens.
C'est les anciens.
En fait, eux, ils ont...
Ouais, pardon.
Ça a changé de nom.
Ça fait quoi ? Ça fait six mois, même pas ?
Ouais, c'est récent.
Ça fait vraiment pas longtemps.
Mais il me semble, à la base, c'était purement français, non ?
C'est franco-indien, je crois.
OK.
Une équipe en Inde et puis une équipe en France.
Mais ouais, ouais, c'était à la base, il y avait des fondateurs français.
Du coup, c'est pour ça d'ailleurs que j'avais utilisé dès le début.
Ouais, il y a un truc qui est pas mal, mais ils sont pareil sur maitjish.
Pour maitjish, tu penses, il y a la même chose.
C'est que tu peux utiliser le SMTP aussi de bref.
Et donc, utiliser ça pour envoyer des emails de ton site.
Donc, ça, c'est pas mal aussi.
Et ça fait partie de l'offre free.
Donc, tu peux envoyer des emails SMTP gratuit.
Directement de bref.
Donc, ça, c'est pas mal aussi.
Et voilà, c'est vraiment des outils qui sont quand même bons à utiliser.
Simple.
Et puis, voilà, il ne faut pas les négliger dans un premier usage.
Yes.
Par contre, si on arrive sur un site un petit peu plus élaboré ou on veut
justement customiser un petit peu l'expérience, on veut mettre sa marque.
Souvent, c'est en lien avec la marque pour développer la valeur, une marque forte.
On est obligé, en fait, de faire ça, d'avoir un niveau de précision beaucoup
plus précis.
Est-ce qu'il y a possibilité de faire des choses hyper précises avec ces
plateformes-là ou on est quand même limité ?
C'est...
Bah, en fait, après, c'était contraint quand même.
T'as forcément un cadre qui est propre à la plateforme.
Mais du coup, c'est limité.
En fait, tu ne peux pas plus pousser comme tu veux.
Tu peux utiliser le SMTP uniquement et faire ton template toi-même,
mais à ce moment-là, à quoi bon passer par eux.
Peut-être si.
Alors, je dis ça, mais si il y a quand même un avantage, c'est quand le SMTP
brevot envoie un email de la plateforme que tu as, tu utilises la
paye pour envoyer un email.
T'as quand même des stats derrière parce que ils rajoutent des petits trucs
dedans et tu sais s'il l'email est arrivé, s'il a été ouvert, etc.
Donc quand même des trucs, des petits avantages, tu vois,
des petits analytics.
Mais à un moment donné, il faut peut-être, voilà,
si ça devient un peu plus personnalisé, sortir de là.
Et comment on fait pour créer nous-mêmes nos propres emails?
Parce que c'est quand même super dur.
On sait que, en fait, dans les navigateurs,
on a des contraintes parce qu'il faut que le navigateur puisse
interpréter le code CSS.
Là, dans un email, c'est le client email qui va devoir
interpréter le CSS.
Et donc le HTML et le CSS, mais ils sont encore plus exigeants
que le plus vieux des navigateurs.
Alors là, oui, c'est...
Alors, on attaque le dur.
On attaque dans le dur.
Là, on va partir dans la partie qui va intéresser les devs.
C'est cette problématique, en fait, de templating d'emails, en fait.
Alors, je vais prendre ma petite canne et je vais parler comme un petit vieux.
Alors, les emails, c'est très complexe parce qu'autant aujourd'hui,
on a, en termes de navigateurs quand tu fais des sites,
ça se devient assez simple depuis quelques temps.
En fait, tu as Chrome, enfin, Chromium, WebKit et puis GECO.
Voilà, t'as trois principaux moteurs et on a à peu près leur rendu.
La problématique des emails, et c'est ça, et ça existe depuis hyper longtemps.
C'est pas de deux d'aujourd'hui, ça s'améliore avec le temps,
avec les outils qui sortent, tout ça, des outils aussi qui sont plus web
comme Gmail, tout ça.
Mais même si Gmail, ça déconne un peu.
La problématique, c'est qu'on a une multitude de clients
que ce soit web et de versions, que ce soit web,
que ce soit des clients qu'on installe sur l'Ordi, sur l'OS,
Outlook, tout ça.
J'en passe des meilleurs, il y en a des tonnes.
Et le rendu est jamais le même entre les différents clients.
Donc, on a une grosse problématique à cause de ça.
C'est un peu du code des années demi, en fait.
Quand, alors pour les anciens développeurs, très, très vieux développeurs,
les sites web étaient à base de tableaux, de table à la base,
pour avoir un rendu identique en fonction des navigateurs au début du web.
Front page, Dreamweaver, là.
Heureusement, ça évoluait pour le web en général.
On utilise plus de tableaux, heureusement, on a même flex, grid, tout ça.
Par contre, dans les e-mails, ça n'a pas changé.
Et ouais.
Donc, on revient à l'ancienne, en fait.
Voilà, on code encore les e-mails, en fait, comme dans les années 2000,
comme début du web, pour avoir un rendu d'e-mail à peu près correct
dans tous les clients e-mails.
C'est ça la problématique.
Et qui a déjà, la personne qui a déjà codé du table HTML,
un briquet dans tous les sens, des tables dans des tés des tables,
enfin, une section.
Il connaît l'enfer.
Il connaît l'enfer du table.
C'est ingérable, c'est ingérable.
T'oublie toujours une balise n'importe et ça te pète tout le truc.
Enfin, bref.
Voilà.
Et pour le coup, limite, en fait, la création graphique,
en fait, le fait de visuellement construire ton site avec un WeezyWeeG,
avec des tables, c'est plus facile qu'avec ton code.
Parce que si tu le fais en pure code, c'est beaucoup plus compliqué à visualiser.
C'est vraiment l'enfer.
Et c'est pour ça que mine de rien, il y a eu tout un écosystème de framework
HTML, on va dire, qui vont créer une surcouche entre le code
qu'on va utiliser en dev et ça va transpiler ou transcoder,
ou je ne sais pas exactement, avec du HTML compatible pour les emails.
Et c'est là où on a vu fleurir tous les frameworks.
Oui, c'est ça.
Ouais, depuis quelques ans, on a des outils qui nous permettent,
voilà, un peu à la vue, réacte, tout ce qu'on a dans les web apps.
On a un tag qui représente, en fait, qui est transformé derrière
et qui va te monter un table sans que nous, on le voit.
Donc tu vas faire ton template avec les balises du framework
et après, ça sera compilé et transformé en table compatible email.
Alors, je ne sais pas si c'est le plus vieux,
mais en tout cas, c'est celui que moi, je connais depuis le plus longtemps.
C'est MJML, c'est le plus connu.
Ouais, c'est le plus connu.
Peut-être que c'est celui qui a été peut-être le plus implémenté,
parce que le plus ancien, peut-être, je ne sais pas.
Je crois que c'est un des premiers.
Je crois que c'est un des premiers, depuis.
Il me semble que c'est le premier qui est sorti comme ça.
C'était une révolution et il a quelques années, quand même, maintenant.
Mais il est super utilisé, il est pratique à utiliser.
Ils ont une API qui est gratuite en plus,
où tu peux envoyer ton code et te renvoi le code transformé.
Enfin, voilà, c'est...
Il y a vraiment...
Enfin, l'outil est bien fait et d'ailleurs, je crois que c'est français aussi.
En fait, c'était poussé par Meljet.
Meljet était français à la base, après, ils sont faits racheter tout ça.
Mais ouais, c'est super bien implémenté
et les composants sont plutôt propres.
Et la syntaxe, surtout, c'est beaucoup plus facile à lire.
C'est pas du table dans tout l'essence.
Ouais, c'est un peu un mode...
Comme React, tu fais des tags et t'as des tags.
Et tu peux même pousser, je sais que tu peux même pousser à faire des sortes de carousel dans ton email.
Ça va assez loin, en fait.
Ok.
Pour des emails, parce que tu peux pas faire tout ça.
Bien sûr.
Après, moi, je ne connaissais pas du tout ce tripot.
Tu as déjà utilisé ça ou pas du tout ?
Non, je n'ai jamais utilisé, mais pareil, je ne connaissais pas.
J'ai vu cette plateforme, c'est un outil en ligne pour designer ton template.
Et ils ont aussi des templates déjà disponibles
que tu vas exporter et utiliser pour envoyer des emails.
C'est une plateforme vraiment pour designer des jolis templates d'email.
Et les exporter, les utiliser.
Donc, tu vois, en plus, il y a des rendus assez sympa quand même.
Oui, carrément.
Et là, pour le coup, c'est plus je prends le template et je modifie.
Oui, là, on est sûr du...
Comme je l'avais marqué, c'est des outils un petit peu de nos codes, en quelque sorte, entre guillemets.
Ok.
Ou une personne lambda qui n'est pas du tout technique va aller sur la plateforme,
va créer son template en WeezieWeezie, en drag and drop, tu vois.
Et va exporter ce que elle a intégré dans son client d'envoi.
Ça marche.
Et pour les hardcoder, les mecs qui veulent vraiment gérer ça,
non, non, mais moi, je le fais à la main à l'eau.
Bodgeler, c'est aussi une possibilité.
Ouais, après, il y en a plusieurs.
Il y en a en listé plusieurs.
Mais j'ai pris les plus récents parce que certains ont disparu ou sont plus trop maintenus.
Mais Bodgeler, ça va être un récent qui est maintenu, en tout cas,
d'après les dernières réalises, il est encore maintenu.
Donc, voilà, c'est des outils tout en un pour développer des templates.
Il y en a un qui a sécondu ces fondations,
email qui était, tu sais, il y avait un équivalent de bootstrap
qui s'appelle les fondations.
Ah, oui, exactement.
Voilà, qui existe toujours, mais qui n'est plus...

Qui n'est pas trop maintenu, je pense.
Ouais, il y a une version email,
et en fait, qu'ils avaient sorti pareil avec tout un écosystème,
avec des classes, tout ça, machin, tu vois.
C'est un peu le même principe.
Et celui-là, je crois qu'il est maintenu par la communauté normal.
Par contre, alors on ne va pas refaire l'épisode sur le Tywin,
si c'est bien, si c'est mal.
Mais de la même manière, en fait,
il y a un framework qui est sorti pour utiliser Tywin
pour générer ces emails.
Et ce framework, c'est Maisel.
Ouais, Maisel.
Alors celui-là, pareil, je ne connaissais pas.
C'est marrant, j'en ai découvert plein en préparant les notes.
Ouais, j'ai pas compris comment ça marchait,
j'ai pas regardé en détail, mais c'est pareil,
ça va transformer, en fait, il doit compiler.
Alors moi, j'étais les classes, en fait.
Ouais, alors moi, je l'ai utilisé parce que...
Ouais, en fait, je l'ai testé et je n'ai pas utilisé celui-là.
Ah !
Parce que j'ai testé, c'était bien,
mais l'autre solution me plaisait encore plus.
Ouais.
Par contre, c'est toujours avec...
Tu peux l'utiliser avec Tywin aussi.
Mais mais mais direct, dis-moi.
Mais Maisel, c'est des components, c'est comme MjML,
c'est des components propres que tu sortes de tags
parce qu'en plus de Tywin.
Exactement, en fait, tu vas pouvoir en fait
construire ton propre template,
mais tu dois quand même écrire...
C'est si tu veux.
Ouais, voilà.
En fait, tu...
Tu dois quand même, en fait,
si tu veux, l'expérience que j'avais avec l'autre solution
qu'on va présenter tout de suite était beaucoup plus intéressante
parce qu'elle est beaucoup plus proche du code vue ou réacte
et pour le coup, tu n'as pas à apprendre leur propre système.
C'est...
Alors, ce n'est pas le reproche qu'on pourrait faire, c'est normal.
Chaque framework, en fait, il faut rentrer,
il faut utiliser ce paradigme-là,
donc il faut que tu apprennes les balises,
il faut que tu apprennes leurs comportements,
OK, quelles sont les attributs que tu peux utiliser
sur cette balise et un de six suites.
Et là, en fait, la courbe d'apprentissage,
bah, j'avais pas trop envie de la faire.
J'avoue, j'étais un peu fainéant.
Mais surtout, en fait, c'est quand j'ai vu la suite,
c'est-à-dire un framework qui s'appelle React Email
et les gars, ils ont sorti la même chose avec vue email.
Ah, j'ai eu peur, j'ai cru que tu avais utilisé direct.
Non.
Ça va pas du tout.
Non, ouais, non, ouais.
Non, mais en fait, c'est exactement le même concept.
L'idée, en fait, c'est d'utiliser des composants réactes spécifiques
et à la fin, ça sort un render en HTML propre avec les tables et tout ça.
Et donc, en fait, le gros avantage de ça,
c'est qu'on a une batterie de composants qui est déjà toute prête.
Et surtout, on est proche de ce qu'on utilise au quotidien.
Alors moi, je fais beaucoup de vues, toi, tu fais plus de React.
Mais voilà, on va dire, la courbe d'apprentissage est beaucoup plus facile
parce qu'on se retrouve tout de suite dans notre élément et notre univers.
Et donc, c'est beaucoup plus facile sur l'implémentation
et surtout, tu peux l'intégrer facilement dans ton applicatif.
C'est-à-dire que tes composants, ils sont dans ton applicatif.
Tu génères tes emails dans ton applicatif et tu fais ton rendu.
En fait, c'est ton applicatif qui va mouliner et qui va générer le HTML.
Donc, en fait, ton HTML rendu, il sort de ton applicatif.
Et donc après, il suffit de prendre ton HTML de ton email construit
avec toutes les variables que tu veux et utiliser un service pour l'envoyer.
Et je t'avoue que ce concept de React Email et de Vue Email,
en fait, c'est super propre parce que tout est intégré à ton framework.
Et ça, c'est...
Moi, je trouvais ça vachement enthousiaste.
C'est pas mal.
C'est pas mal d'autant que...
Ce qui est intéressant aussi, c'est qu'à un moment donné,
tu sais, dans les emails de nos aiteurs ou n'importe que tu vas envoyer,
tu as souvent un lien voir dans le navigateur.
Oui.
Et c'est intéressant d'avoir ce type de système
parce qu'en fait, tu vas pouvoir faire le rendu dans l'email
et aussi dans le navigateur parce que ça sera forcément compatible.
Oui.
Du coup, ça te fait les deux en même temps.
Donc, c'est pas mal de vous pourrir une cette intégration au niveau de ta plateforme.
Exactement.
Et donc ça, c'est plutôt bien parce que tu deviens un peu autonome.
C'est-à-dire, en fait, tu viens réduire un peu ta dépendance aux outils,
on va dire, tout près out of the box,
qui amène plein de possibilités et plein de fonctionnalités.
Par contre, pour nous, tech, on peut avoir...
On a moins la main et donc, c'est moins intéressant.
Enfin, je trouve que c'est moins poussé.
Par contre, il y a vachement d'exemples.
Ce qui fait que là, pour le coup, je prends l'exemple de vue email.
Il y a beaucoup d'exemples où ils ont refait les emails
qu'on a l'habitude de recevoir des crossboites,
donc de GitHub, de Stripe, de Twitter, de Twitch, de Vercel, des choses comme ça.
Et tu vois comment ils ont réintégré le truc
et tu as une possibilité d'intégrer ça directement.
Tu as les sources, non ? C'est ça ?
Oui, absolument.
Tu es dessus des emails, là, tu as la source.
C'est quoi, c'est la source en vue ?
Donc, en fait, tu as la source en vue,
comment il a intégré ça,
il a fait un composant vu avec des props.
Et pour le coup, c'est la même chose en React.
Avec, il est venu tipper ses props,
il est venu mettre son design,
il peut mettre Tailwind s'il a envie.
Et après, on voit le rendu, c'est-à-dire après le render,
là, on voit le rendu HTML avec,
où on voit bien l'utilisation de toutes ces tables,
les T-Body, les T-Ed et tout ça.
Pop, pop, pop, pop.
Et il te fait...
Ah oui, il avait rendu texte aussi.
Ah, c'est bien ça.
Parce qu'en fait, il faut toujours un fallback,
enfin, c'est préférable d'avoir un fallback
si ton client email ne peut pas interpréter le HTML,
on peut utiliser le texte.
Donc, la méthode de render,
en fait, au moment où tu vas balancer ton composant
et tu vas lui demander de générer ton HTML,
tu peux lui faire la même chose de générer le HTML
et générer le plein texte.
Bah, écoute, c'est pas mal,
parce qu'en fait,
il y a ces deux outils, il y a l'MJML qui est proche,
mais qui n'est pas exactement pareil,
mais qui je kiffe.
Et c'est pas mal, en fait, parce que tu peux même,
si tu veux pousser un peu...
Alors, j'ai déjà fait un petit peu avec des clients,
tu peux pousser le truc, en fait.
Imaginons que la personne a un CMS,
un CMS moderne qui fonctionne
avec des blocs, tu vois,
tu peux faire des blocs,
et bah tu peux éventuellement faire un système
pour construire des e-mails.
Et chaque bloc serait représenté
par un component de vue, e-mail,
et derrière, en fait,
la newsletter serait rendue, compilée,
et envoyée, donc tu pourras vraiment
aller pousser le truc à ce que la personne
puisse éditer ces e-mails, en fait.
Ah ouais, là tu...
Bah, c'est des choses que j'ai déjà fait, en fait.
C'est des choses qu'on a déjà fait avec MJML,
en fait, où...
D'accord.
ou Craft CMS, qui est à base de blocs
comme ça où tu vas définir les champs et des blocs.
Derrière, le rendu,
c'est MJML, et après, tu compiles et t'envoies.
Et ça marche plutôt pas mal.
Tu peux le faire pareil avec React ou Vue,
là, avec...
avec certains clients sur le nom, en fait.
Et ouais, parce que...
parce que, en fait...
Bah, le rendu, tu le maîtrises, en fait.
Exactement.
Et pour le coup,
moi, je l'ai implémenté sur Vue,
mais...
c'était vraiment...
moi, je veux un truc full custom,
et je veux pas
éditer dans Brevo,
mais ça part de l'applicatif,
ça va dans Brevo,
il faut que moi, je fasse le design,
mais après, il faut que je variable
le nom, la commande,
le prix de la commande et tout ça.
Et en fait, ouais, tu commences à balancer
un paquet de variables
sur Brevo.
Ça se fait, tu peux utiliser un template dans Brevo.
Moi, je l'ai eu fait dans le passé.
Là, en fait, la flexibilité
de pouvoir tout contrôler,
c'est 10 000 fois plus facile.
Et il y avait un truc qui était aussi intéressant,
c'est que le site était
en français, en anglais, en espagnol,
en allemand et machin.
Et donc, il y avait une intégration...
il y a une intégration de I18N,
qui est pour l'internalisation,
ce qui fait que, on va dire,
out of the box, alors,
modulo toute la config, on est d'accord,
mais les clients espagnols
reçoivent les e-mails en espagnol,
les clients anglais, en anglais
et les français en français.
Et donc ça, ça amène
à un niveau de précision
et de... on va dire,
d'individualisation de l'expérience
qui est quand même plutôt acceptable
pour l'utilisateur final, quoi.
Et pour nous, en fait,
c'est crème, quoi,
parce que l'utilisation de ça, c'est vraiment crème.
Ça marche vraiment bien.
Ouais, de toute façon, après, c'est...
quand t'es dev vu ou réacte,
l'écosystème qu'il connaît,
donc tu retrouves rapidement, t'es petit...
Exactement.
C'est pour ça que tout à l'heure, je parlais
de courbes d'apprentissage.
Là, en fait, un développeur réacte
ou un développeur vu, il intègre ça
en... je vais pas dire en deux deux,
mais la prise en main est vraiment facile.
Vraiment facile.
Ok, super. Non, c'est... c'est
de très bons outils, clairement.
Faucite, la vie pour...
email transactionnel, ou email marketing,
les deux, hein. Là, ça...
ça fonctionne pour les deux, sans problème.
Yes.
Néanmoins, on peut pas
faire confiance totalement
à ces frameworks-là.
Ça peut être intéressant de tester
et d'être sûr que
la viabilité
de ce qu'on envoie, en fait,
est-ce que c'est bien interprété, quoi.
Alors, eux, ils nous disent oui, c'est valable,
mais c'est pas mal de tester, quand même.
Ouais, et tu avais un outil,
j'ai vu que tu avais un outil pour tester
à base d'intelligence artificielle, c'est ça.
Alors, alors pour le coup,
l'hythmus, c'est...
c'est super vieux, ça fait
super longtemps que ça existe. Ah ouais ?
Ouais, je connais ça pas. Ah ouais ouais ouais ouais.
J'ai jamais utilisé. Non non, ça fait...
ça fait vraiment super longtemps. Alors maintenant,
ils mettent de l'IA, ok.
Est-ce que c'est bullshit ?
J'en sais rien du tout.
Sur les recommandations de l'IA, ça, j'en sais rien.
Par contre,
c'est une solution, en fait, qui va vraiment,
en fait,
tu vas pouvoir tester, en fait,
tes previews.
C'est-à-dire, voir
si ton accessibilité est bonne, si tes liens,
tes tracking, tes images,
le... est-ce que
tu vas aussi être considéré comme spammeur ?
On va peut-être... Ah oui. On va sans doute parler
de tes spams. Ah oui, oui.
En fait, sur l'utilisation des mots,
euh...
Donc en fait, c'est à la fois
sur la forme, mais aussi sur le fond,
en fait, où ils vont tester
l'intégralité
de... de...
de ton email. Et donc,
ils vont tester, bah ouais, plein de...
plein de caractéristiques
pour voir si t'es propre,
si tu fais ça bien, quel est le
rendu que l'utilisateur
final va avoir dans son navigateur,
enfin, dans son client email, pardon.
Parce qu'ils testent dans différents clients ?
Ouais, en fait, ils ont des
simulateurs de...
Bah c'est pas ça.
Ouais, ils ont des simulateurs de clients emails.
Mais c'est pas... c'est eux qui font, en fait.
Tu fais quoi ? T'envoies ton email, enfin,
tu places un E-test et ils te disent, c'est bon ou pas ?
Ouais, tu te connectes, en fait.
Tu lui donnes ton html
brut, donc là, pour le coup,
on serait dans le rendu. Donc, si
on a utilisé Vue Email, bah, on...
après avoir rendu, on sort l'HTML,
on le colle chez eux, et là, ils disent
ok, comment ça va se comporter ?
Et là, bim, ils regardent.
D'accord. Ok,
mais t'as... il y a un API ou tu peux... par exemple, toi,
tu... tu t'envoies le système ?
Alors, je l'ai pas fait...
je l'ai pas fait via l'API,
j'avoue, j'ai fait...
Je sais pas du tout
s'il y a un API, mais je pense qu'il y a un API
pour tester. Ah bah oui, je pense.
Mais pour le coup, ça fait très longtemps
que c'est en place, hein.
C'est vraiment des... des outils
qui sont...
assez anciens.
Et ils sont sur ce créneau
déjà depuis pas mal de temps, quoi.
Bah, je connais ça pas. Bah, écoute, on a apprend
tous les jours, tu vois. Bien sûr, il faut.
J'espère, les auditeurs aussi, en écoutant le podcast.
Et... et alors, après,
ok, là, ils mettent en avant, aujourd'hui,
leur... leur système
d'IA, tout. Bon, ok,
j'en sais strictement
rien.
La plus-value que ça amène, tout.
Bah, ils annoncent que ça
te donne des conseils de marketing, je pense.
Mais après, bah, il faut voir.
Il faudrait tester, en fait. Il faudrait tester, je sais pas.
Il faut tester dessus, ou...
Aucune idée.
Oui, oui, tu peux... tu peux tester
au pire.
Tu as un... un...
un laps de temps, où c'est
frip, et après, tu dois payer.
Pareil, tu peux... Mais pour faire un diagnostic
de ton e-mail, pour le coup,
le retour d'expérience que j'ai là-dessus,
c'est sur l'e-mail de transaction.
Voilà, on vient juste de
variabiliser. Après, j'ai
mis les variables en dur.
Et... et après, on le teste,
parce que moi, ce que je voulais tester, c'était la structure
d'HTML. Est-ce qu'elle était propre ?
Après, la typologie,
pareil, dans les... dans les titres.
Non, pardon, dans le sujet
du mail. Voilà, s'il...
Décombait de l'argent,
il faut faire attention.
Si on met des montants
là-dedans, il faut... il faut faire attention.
Voilà, il y a plein de solutions.
Et même à titre informatif,
pour... ouais, on...
on apprend quand même pas mal de trucs en utilisant
cet outil-là, quoi.
Ok. Non, non, c'est intéressant, on
pourrait peut-être faire une vidéo pour
tester le truc en live ou autre comme ça.
Ouais, carrément. J'ai bien envie de découvrir le truc.
Carrément. Ok, on va
continuer sur... vu qu'on est partis sur le test
d'email, machin, tout ça, s'il est valide. On va
passer directement à faire en sorte que les
emails arrivent. Comment...
parce qu'on envoie des emails, on passe par les
cmpp, tout ça, mais comment on fait aussi... alors
des petites manies, pas faire pour faire en sorte
que... qu'on soit pas
blightlisté, qu'on soit à la limite white-listé,
mais qu'on soit pas... considéré comme un
spammer, parce que du coup, ouais, quand on envoie
plusieurs emails, tu peux être considéré comme un
spammer. Il y a... les...
les emails, ça, c'est assez complexe, en fait, à
comprendre comment ça fonctionne, à quel moment tu passes
en spam, tout ça, il y a des gens, plutôt que
de désinscrire du newsletter, ils vont te
mettre en spam, du coup, si plein
de personnes te mettent en spam, j'aimais, je
vais te considérer comme spammer.
C'est assez complexe, hein.
Mais il y a quand même des manies, des manies
pas faire. Ouais.
Et donc,
qu'est-ce qu'on...
à l'émiteur, on les envoie
et après, on configure, qu'est-ce qu'il y a...
le mieux, c'est de configurer dans notre
propre serveur. Si... si nous, en fait,
on envoie des... des emails,
si nous, on... on décide d'envoyer
nous-mêmes nos emails, comment on fait ?
Mais déjà, il faut toujours,
enfin, la plupart du temps, il faut passer
par un sntp. Ok. Passer par un service.
Soit que vous avez mis en place, soit un
serveur, soit un service type brevo, tout ça,
et ne pas utiliser les fonctions. Alors, je prends
l'exemple de PHP, mais la PHP, il y a une fonction
mail qui permet d'envoyer un email. Et...
Et... Et... Ne passez pas par ça,
vous avez 50% de chance que ça passe
en spam. Donc, ça arrive,
ça, c'est sûr, parce que c'est souvent mal
réglé, tout ça. Donc,
sntp,
envoyer avec votre domaine, évidemment,
un domaine qui ne soit pas considéré comme
spammeur. Ouais, évidemment.
Attention, est-ce que vous achetez comme domaine ?
Un domaine propre, quoi.
Un domaine propre. Et ensuite, il y a pas mal
de réglages au niveau des DNS, alors c'est...
c'est un peu plus complexe, mais heureusement,
il y a... Alors, je parle toujours brevo,
parce que c'est un outil que je connais bien,
mais il te... Quand brevo, tu attaches
un domaine à ton
compte email,
il te...
te donne des étapes, en fait, pour régler
correctement tout ce qui est SPF,
des IIM, etc.
et puis, il te valide
que c'est bien rempli
dans le DNS, donc les...
réglages DNS, c'est ce que vous avez sur votre serveur
de nom, sur votre révergeant.
Et pour le coup, ça c'est super important.
Ouais, et pour le coup, si vous faites pas ça,
c'est sûr que ça passe pas,
et donc c'est hyper important
de vraiment prendre le temps
de bien paramétrer
ces serveurs DNS.
C'est un peu, comme tu dis, c'est touchy.
Par contre, toutes les plateformes
qui, justement, c'est leur métier
d'envoyer des emails, ont plutôt
des tutos, ils...
ils accompagnent énormément, et ils viennent
valider entre des alertours,
entre ton panneau de config
de ton DNS et la solution
pour valider que tout est
tout est propre, parce que,
justement, eux derrière, ils vont
c'est eux le facteur, c'est eux qui vont
délivrer le message. Et donc
et donc, en fait, ils ont aussi
tout intérêt, en fait, c'est
dans leur intérêt que toi, tu sois clean
et que tu fasses ça bien, pour que eux,
ils se fassent pas blacklister en disant
vous, vous êtes le facteur des spammers, quoi.
Ouais, exactement, c'est ça, en fait,
c'est que... ils ont...
ils ont des serveurs qui vont envoyer les emails, donc ils ont
une IP qui est accrochée aux emails, en quelque sorte,
et en fait, si... ils ont des clients
qui envoyent des spam, tout ça, ils vont avoir
leurs serveurs qui vont être blacklistés, et ça devient
problématique pour leur business. Donc c'est clair
que eux, ils font plutôt attention, et j'ai déjà
reçu des emails... d'alerte,
comme quoi j'envoyais trop d'emails, et je suis
ça, enfin moi ça m'a déjà arrivé, mais c'est
attention, je veux dire. T'es pas super clean, Patrick, aussi.
Tu envoies d'un email, hein.
Et il y a aussi un outil
que j'utilise souvent, quand je fais
ce type de réglage, c'est MailTester.
MailTester.
MailTester.com,
qui est MailTireTester.com, c'est un outil
qui est vraiment pas mal.
Donc en fait, tu envoies...
une fois que t'as paramétré ton bordel,
tu prends l'adresse email
qui te donne, là. Quand tu rentres sur la page,
en fait, il te donne un adresse email, tu envoies
l'email à cet adresse-là,
et ensuite, là, il t'affiche le score, et il te dit
t'as une note sur 10, en fait,
et après, il t'indique ce qui va pas,
si le décaillis n'est pas bien rempli, etc.
Et en fait, lui, le objectif, c'est
que tu te rapproches le plus du 10 sur 10
pour que tes emails, en fait, arrivent
correctement dans les bot-mails.
Ça, tes clients étaient propes, quoi.
Ça n'empêchera pas de
passer en spam, mais en tout cas,
t'auras tout fait pour que ça arrive, correctement.
Parce qu'en fait,
souvent, quand on fait ça, on a
des clients en face. Il suffit
qu'une fois le client reçoive
l'email de sa newsletter dans les spam,
et alors là, je peux te garantir
qu'il te lâche plus.
Mais une seule fois, non, c'est pas un client
une seule fois.
Si la personne te dit, je reçois
les newsletters de ma boîte dans mes spam,
c'est pas normal. Alors là, c'est
les mecs qui te lâchent plus.
Pour, les emails n'arrivent plus.
Ça décrédibilise totalement le truc.
Donc, il faut vraiment
faire les réglages correctement le plus possible.
C'est pas
super-pationnant, ce type de réglages, c'est clair.
Non, c'est super-chiant, c'est
relou, c'est...
Mais faut passer par là.
Voilà. Et c'est ce qui fait la différence
entre un bon Dab et
un mauvais Dab.
Ça marche. Alors, on va dire qu'on a fait
tous les réglages, on a bien testé
notre...
Voilà, le test est bon.
Notre nom de domaines est bien paramétré.
Les EMX,
les SPF, les Denmark, tout ça.
Ok.
Maintenant,
on doit envoyer nos emails.
Comment on fait ?
Alors, comment on fait ?
Il y a différentes solutions.
Il y a différentes solutions.
Alors, déjà,
tout ce qui est framework,
tout ce qui est
symphonie, la ravière, tout ce qui est CMS,
WordPress, etc.
La plupart, on a déjà un système
intégré
d'enrôl email qui gère SMTP, tout ça.
Si tu prends
l'exemple de symphonie mailer,
tu peux paramétrer différents clients,
SMTP, machin, tout ça.
Il y a plein de réglages et à partir de là,
tu peux envoyer des emails directs.
Et donc, tu vas utiliser tes SMTP
de ton facteur ?
De brevaux ou n'importe où, ce que tu veux.
Ok.
Donc là, à partir de là, tu as déjà des outils de dispo.
Dans l'écosystème PHP, il y a déjà beaucoup d'outils.
PHP, mailer, enfin, voilà.
Il y a plein. Mais tous les frameworks,
tous les SMTPs,
tous les CMS, sont directs au dispo.
Par contre, si tu fais
tout ce qui est node,
donc le PHP mailer,
tout ce qui est node,
le plus connu, c'est node mailer.
Que tu as déjà utilisé, j'imagine ?
Node mailer, non,
je n'ai pas utilisé node mailer.
Je n'ai jamais utilisé nulle mailer.
Ah, toi, tu as utilisé un service,
une plateforme, j'imagine.
Exactement.
Ok.
Donc là, si vous êtes
bidouilleur et vous aimez faire les choses vous-même,
voilà, c'est tous ces outils là, donc
node mailer,
PHP mailer, symphony mailer,
c'est larvel mail, enfin, voilà. Il y en a
des tonnes.
Vous les paramétrez, vous règlez
vos clé-drets de SMTP, tout ça,
adresse, domaine, tout ça, et ça marche.
Et après, vous t'envoyez pas.
Et par contre, là,
là, on voit très bien,
je vais envoyer mon mail
à, donc, de telle adresse,
à telle adresse, avec tel sujet,
le texte et le HTML.
Et c'est dans
ce HTML là où je vais mettre
l'intégralité
de mon HTML qui a été
générée par les frameworks
qu'on a cités juste avant.
Voilà, mjml,
email.
Ok. Top.
Généralement, ça marche bien.
C'est plutôt, c'est plutôt propre.
Ouais, ouais. Généralement, c'est bien
quand tu as vraiment
un développement spécifique avec
une admine, par exemple, où tu vas cliquer sur un bouton
pour envoyer une notification à quelqu'un.
Ce genre d'outil marche plutôt pas mal.
Ok.
Et
de la même manière,
ouais, moi, j'ai
utilisé d'autres plateformes.
Je sais laquelle.
Qui sont, en fait,
brevaux,
en fait, ou mailjet,
ou mailchip.
C'est des packages, comme on l'a dit, un peu
globales. C'est-à-dire, il y a tout.
Il y a les envois, le design,
la gestion des
mails en liste, la gestion
d'un autoresponder, de l'auto-marché de marketing
et tout ça. Et là, en fait, il y a
d'autres boîtes qui se sont
mis sur ce secteur-là
où, pour eux, leur
concept, c'est très simple. Eux, ils ne sont
que le facteur. Ils ne font que
envoyer l'email. C'est tout.
Et c'est
les plateformes type Recend
et MailPace,
qui, pour le coup, en fait,
c'est exactement la même chose.
Eux, ils ne font que envoyer les e-mails.
Donc, il faut construire notre e-mail.
Il faut construire
notre base
d'utilisateur. Et, en fait, ils vont
avoir une API ultra
mais ultra facile à implémenter.
Ils ont plein,
ils ont plein d'exemples.
Mais pour le coup, on va...
Prégnent tous les langages, tous les frais morts.
Exactement. Et leur API
est hyper, hyper simple.
Je viens utiliser leur SDK
et j'en vois, pareil,
de la part 2,
à le sujet
et le HTML,
terminé.
Donc, c'est plutôt,
c'est assez facile
et ils viennent maintenant
de plus en plus intégrer cette notion
où tu parlais tout à l'heure d'analytics
pour en fait...

OK. Savoir est-ce que j'ai été blacklisté,
est-ce que le mail a été reçu,
voilà, tout ce type
d'information, en fait, maintenant,
on va venir être intégré
directement depuis
depuis le...
depuis ce type de plateforme.
De la même manière, t'as des webbooks aussi
que tu peux configurer.
C'est OK, si j'ai
un report en spam,
tu m'envoies un email
sur cet adresse-là
comme ça, moi, je vais être notifié
que, là, il y a un problème,

Tu vois, et tu...
C'est à toi d'implementer ton système
de...
de...
de notifications via des webbooks.
Donc, ça amène une plus grande liberté.
Par contre,
ça veut dire aussi
beaucoup plus de boulot, quoi.
Ouais, mais après, c'est des outils.
Alors, on a les premiers qu'on a cités,
c'est dans le cas où toi, t'as un serveur, tout ça, voilà.
T'as ton infra, etc.
Là, ce type d'outil,
c'est plus adapté, on va dire,
quand tu utilises des outils cloud,
type Versel, Netlify, tout ça,
t'as pas forcément de serveur
à un dispose, donc, du coup,
tu vas utiliser ces outils-là pour envoyer les emails,
parce que, déjà, c'est plus simple.
Et comme tu dis, t'as des logs, t'as des analytics,
tu sais combien d'emails arrivent,
où sont pas arrivés, etc.
Donc, c'est important aussi de savoir
d'avoir un état d'élu, en fait,
quand on va plein d'emails,
est-ce qu'ils arrivent, parce qu'à un moment donné,
c'est un intérêt, quoi.
Exactement.
C'est complètement l'intérêt.
Donc, on a parlé tout à l'heure de ReCend,
il y a MailPace,
qui a changé de nom avant
qui s'appelait OMAI SMTP.
Et en fait, ils ont changé de nom.
Tu peux faire un ancien.
Ben ouais, carrément.
Oh, OMAI SMTP, c'était vachement bien, je trouve.
Par contre,
il y a cette notion,
en fait, de débergement
et de
de loi,
en fait, qui va s'appliquer
sur l'envoi
des emails,
avec, alors je sais pas si c'est
le cloud act, patriot act,
ou je sais pas quoi, tout.
Mais bon, si ça passe par les États-Unis,
il y a quand même
la loi change.
Donc, il nous faut un service,
enfin, si vous avez besoin
et vous êtes sensible à cette contrainte-là,
qu'elle soit légale
ou purement éthique aussi,
en fait, vous devez
utiliser des services qui sont basés
en France.
Ouais, d'autant que...
En Europe quoi.
Ouais, t'as raison, parce qu'en fait,
généralement dans les emails,
notamment de commerce, tout ça,
il y a souvent des données
sensible, entre guillemets, mais il y a
ton nom, prénom, machin, tout ça, adresse et tout ça.
Et effectivement,
les patriots act qui aux États-Unis,
à tout moment, les États-Unis peuvent venir
sur les serveurs de n'importe quelle entreprise
et prendre des données en fait.
Après, voilà, on n'a rien à cacher, mais bon,
on sait jamais quoi.
Ouais, après, on va pas...
Enfin, ouais, c'est privacy,
c'est quand même important,
donc il faut garder ça en tête.
Si vous utilisez ces services-là,
ils ont des fritières qui sont assez généreux.
Donc ça, c'est plutôt bien.
Par contre, gardez bien en tête que
toutes les données qui passent là-dedans,
qui passent dans le tuyau,
sont possiblement
auditables et récupérables
par qui de droit.
En plus, on en parlera pas trop,
mais tu...
Ce que tu dis, c'est intéressant, parce qu'en fait,
il y a la notion d'RGPD.
Et tout ce qui passe par les États-Unis,
n'est pas compatible avec les RGPD,
même s'il a, dernièrement, ils ont trouvé
un accord entre guillemets.
Et si par hasard, tu travailles
à mettre en place un système de newsletter
d'emails transactionnels pour une grosse société
qui se doit de respecter
les RGPD,
c'est quelque chose qu'il faut faire, vraiment attention.
Ah, non, mais c'est...
C'est primordial.
Et puis, on parle pas de RGPD,
mais en tant que dev,
vous avez aussi une partie à mettre en place
quand c'est des emails transactionnels
ou d'informations,
toute la notion de désinscription aussi.
Ça, c'est hyper important.
On en parlera pas dans cet épisode,
mais ça fait partie de ce paquet d'emails
où, à un moment donné, les gens doivent pouvoir
se désinscrire facilement en un clic, tout ça.
Donc, voilà. C'est une notion là,
quand on a un système de newsletter d'emails,
il y a ça aussi à prendre en compte.
Parce que c'est RGPD et que c'est obligatoire
que les gens puissent se désinscrire.
Après, sur l'email transactionnel,
tu vois, t'as moins besoin de ça, quoi.
T'as pas besoin de...
En termes transactionnels, le RGPD, ça applique moins, ouais.
Parce que c'est juste un one-shot.
Et alors après, t'as la loi,
mais t'as aussi le retour client
où, pour le coup, j'ai validé ma commande.
Alors, si c'est 20 balles, OK,
mais même 20 balles ou 2000 balles,
bah, en fait, j'ai besoin
et j'ai envie d'avoir l'information
comme quoi, OK, ma commande, elle a bien été validée.
Elle est en traitement.
Enfin, voilà, j'ai besoin d'avoir ce retour
d'information. Aujourd'hui, c'est devenu un standard.
Sinon, en fait, je suis sur mon site.
C'est tout bon, mais j'ai pas de validation.
Enfin, voilà, c'est quand même important.
C'est très important.
Je suis le premier et on est tous pareils.
Si je fais une commande, et j'en ai fait une
tout à l'heure avant l'épisode,
si je reçois pas d'email, j'ai l'impression que la commande
n'est pas passée, en fait.
Aujourd'hui, c'est vraiment une confirmation
de commande quand ça ressemble à un email.
Alors, peut-être que je suis un peu vieux, mais...
Maintenant, c'est des trucs sur TikTok, peut-être,
mais je ne sais pas.
Non, mais c'est important
de bien garder ça en tête.
Yes.
Et puis, dernier volet, alors après
les plateformes volées...
Avant de passer,
néanmoins,
il faut quand même garder en tête.
Ah, les blouses.
Parce que, en fait,
tous ces services-là de Risen,
ils ont un fritière
qui est plutôt généreux,
mais pas toujours.
Comme MailPay, c'est par exemple
il n'y a pas de...
il n'y a pas de fritière.
T'as un premier...
Voilà, t'as un modèle qui commence à 3€,
mais c'est payant, quoi.
C'est payant.
Mais les mail par mois, c'est pas énorme non plus.
Oui, c'est pas non plus énorme.
Par contre,
là où c'est cadeau,
enfin, cadeau, c'est Amazon,
là, ils ont un fritière qui est beaucoup,
beaucoup plus généreux.
Donc, à prendre en compte...
Il faut juste comprendre les prix, en fait.
Voilà. C'est à quel moment
tu vas te payer, en fait.
C'est pas...
Mais pour le coup,
il y a possibilité d'envoyer
des emails pour pas très cher.
Rédescend un poil, s'il te plaît.
Il y a mes marquées 3000 fritières.
3000 messages
gratuits chaque mois.
Mais pour le coup,
en fait, si tu ramènes
au prix envoyé par mail,
c'est vraiment dérisoire,
quoi.
Par rapport à n'importe qui,
de Mailjet, Mailchip,
Brevo, machin.
Si tu ramènes ça à l'email envoyé,
c'est imbattable.
En termes de prix, c'est imbattable.
Par contre,
1, c'est aux États-Unis
et 2, c'est à toi de gérer
tous tes emails.
Amazon,
est-ce que c'est en français,
même sur des serveurs français,
est-ce que...
Je sais pas la législation.
Mais est-ce que ça passe
aux États-Unis ?
Pour le coup, c'est hors de mes compétences.
Totalement.
Après, on parle du prix.
C'est vrai que le développement du système
il a un coût, mais il faut savoir que les plateformes,
alors là on parle de Brevo tout ça,
mais il y a des plateformes professionnelles
que les entreprises
utilisent.
Il y en a plein.
Et ça coûte une blinde.
J'ai travaillé dans une boîte il y a longtemps
où on avait un petit, je sais plus comment il s'appelle,
qui avait été racheté par Adobe,
et qui coûtait vraiment une blinde par mois.
Mais pour faire quoi ?
Il faisait quoi ?
Envoyer des newsletter.
Ah ouais, d'accord.
Et tu avais un système d'auto, tu faisais
des automatisations, etc.
Mais ça coûtait très très cher.
Parce que déjà, la mise en place
de l'outil était
extrêmement chère.
Parce qu'il te paramètrait le truc tout ça.
Et après derrière, l'utilisation
d'envoyer des emails, c'était vraiment pas donné.
Je pense que ça a changé depuis avec tous les outils
MailSIM, Brevo tout ça.
Comme donné un petit coup de pied dans la fourmillière,

t'as sent envoyé des emails.
En général, quand on voit des emails,
c'est que derrière, il y a de la conversion,
l'aventure, le blog.
Il faut quoi, sinon en fait, ne fais pas ça.
C'est clair.
Sinon, t'as un spammer.
Mais non, mais même le spammer,
il a un objectif derrière.
T'en vois pas des emails pour envoyer des emails.
Il y a toujours un but
volontaire.
Et si
nous, on doit gérer des emails,
c'est qu'on est
sur du business, clairement.
Donc,
il y a un objectif
et donc, très vite,
on va arriver sur de l'argent.
Donc, évidemment, tu peux pas faire de l'argent
sans en dépenser
au moins pour l'aide. Merde.
On n'est pas donné. Il faut bien qu'on gagne le croutis.
Dernier volet,
on était
sur comment envoyer ces emails.
Dernier volet, c'est
envoyer comment on envoie...
T'as une grosse base d'email,
t'as 100 000 emails dans ta base de données.
Le bon sens
veut qu'on n'en voit pas 100 000
emails en un bloc.
Pourquoi ?
Alors pourquoi ?
Première chose, tu vas passer pour un spammer.
J'ai mailed tout ça, ils savent
un peu près ce qui arrive. Il y a une agressie mail
qui est reconnue.
Si t'as beaucoup d'emails qui arrivent d'un coup,
il y a des chances que t'en reconnaisses.
Surtout si beaucoup de gens cliquent sur spam,
ils recevent l'email.
Ça ne va pas bien.
Et ensuite, il y a aussi la
chose qu'on église souvent.
C'est la charge de ton serveur.
Quand on a un email, il y a forcément des liens
qui vont envoyer sur ton app
ou ton site.
Si t'envoies 100 000 emails,
même 20% des gens qui cliquent,
t'as quand même 20 000 personnes qui vont arriver
d'un coup sur ton serveur.
Potentiellement,
si t'as pas un serveur
qui scale ou un truc comme ça,
tu risques de faire tomber ton site.
Ce que j'appelle
l'effet vu à la télé.
Tout le monde va sur ton site.
Pour le coup,
je pense que t'as déjà vu ça
sur des WordPress, sur des serveurs mutualisés.
Petites start-ups,
tout, site Internet WordPress.
Passe à la télé,
à fluence,
le site en PLS,
terminé, dénit de service.
Comment transformer du buzz
en buzz ?
C'est fini, tu peux pas transformer le truc.
C'est ça,
t'envoies des emails pour vendre des choses
sur ton e-commerce, mais derrière,
les gens cliquent, il y a plus de e-commerce qui marchent.
C'est un peu dommage.
Il y a des outils pour ça.
Souvent, les outils,
tout ce qui est plateforme le propose,
normalement, t'envoyer par l'eau,
tous les outils sérieux.
Mais après, si t'es en mode dev,
que t'as tout développé toi-même,
comme pour les systèmes d'email,
d'envoie d'email,
c'est pris en charge par les symphonies,
la ravelle, non-mailer, tout ça.
Sur Node.js,
il y a Q, ils appellent.
J'aime bien le nom, Q, U, E.
C'est pas mal.
De la manière dont c'est écrit, ouais.
Qui permet de gérer les Q.
Ça permet de gérer
des envois d'email par l'eau,
tu définis combien de temps d'envoie à la fois.
Ça s'étend sur le temps.
Et ça t'évite de surcharger ton serveur.
C'est ça, c'est du bon sens.
En fait, tu viens d'essayer ta charge.
C'est ça, tout simplement.
Tu lisses un peu la charge de ton serveur,
les gens vont recevoir au fur et à mesure,
et ils vont cliquer, et ton serveur fonctionnera correctement.
Oui.
Et ça, c'est un truc, tu vois,
il faut y penser, parce que c'est bête,
mais on y pense pas forcément.
Pour éviter, en fait,
d'avoir un Denis de service,
en fait, c'est l'impact de l'envoi de ton email,
l'impact que ça va avoir sur ton infra.
Bon, après,
si tu as une infra
qui scale skyrocket,
tout en automatique,
avec des pods Kubernetes
qui pop automatiquement.
Oui, alors...
Là, tu as des sous, alors.
C'est bon.
Mais on est d'accord.
Mais, oui, intéressant
de pas se faire baiser sur des trucs
un peu à la con comme ça.
Tout basique.
Si on le met en place dès le début,
c'est plutôt serein.
Tu as déjà parlé un petit peu de ton
expérience e-commerce, mais tu veux en parler,
je ne sais pas si tu as oublié de faire des choses.
Non, en fait,
vu...
vu email, c'est assez récent,
quand même.
Donc, il y avait un risque.
Pour moi, le risque que je voyais,
c'était pas assez de recul
sur la maturité de la librairie.
Et pour le coup,
j'en ai discuté avec
mon client
qui, lui, est assez tech, quand même.
Pour te dire, c'est un client
qui fait des requêtes SQL.
Tu vois, donc, c'est pas...
c'est pas n'importe quel client qui fait ça.
Donc, il est...
Sur la base de prod.
Ouais, sur la base de prod, ouais.
Mais...
Mais pour le coup, il est assez tech.
Et je lui ai proposé
de faire ça et je lui ai montré le rendu.
Je lui ai... voilà.
Et en fait, lui, il a...
il m'a donné l'accord.
Donc, on est partis là-dessus,
tenant compte, en fait, de tous les impacts
que ça pouvait avoir, quoi.
Sur le côté un peu touchy
ou vraiment très early stage.
Et au final, ça passe...
ça passe plutôt très bien.
Et le côté I18N
d'avoir un client,
en fait, non, que chaque Ibel
soit envoyé de la langue du client.
Ça, pour le coup, c'est...
c'est super, super appréciable.
Et ça, en fait,
je sais même pas si
la solution type brevaux
le... permet de faire ça, quoi.
Je pense que oui, parce que tu as
un champ, forcément, de langue.
Donc après, tu dois faire...
Ouais, voilà. Donc ça veut dire que tu fais
4 templates différents.
En fait, tu viens
twequer le modèle, en fait. C'est ça.
Tu peux le faire. Mais tu viens
tordre un peu le modèle en disant, ouais, ben
j'ai 4 templates. Donc ce qui... qui veut dire
si tu veux faire une modif, il faut faire ton modif
sur tes 4 emails, tout. Alors
l'espagnol marche, mais pas
l'allemand. Oh, laisse tomber.
Tu pètes des câbles. Tu pètes des câbles.
Et donc, pour le coup,
c'est assez fluide.
Et pour ce client-là, on a utilisé
le client SDK
de chez Brevaux. Donc, en fait,
il a la traceabilité
des envois et de
toute l'information, quoi.
Donc ça, c'était... c'est
plutôt appréciable. Et en tant que Dev
vraiment le fait de tout avoir
dans ma codebase
OK, ça envois, ça compile,
ça... ça... ça...
ça... enfin, je génère la HTML
d'avoir toute la chaîne de production.
Mais en fait, c'est vachement plus facile.
Ça évite des envois,
des retours, des envois, des retours
avec à chaque fois
la possibilité, en fait, d'avoir
d'avoir des pertes de données,
où la donnée est malformatée.
Là, c'est des composants
tout le site
est fait en uxt. L'envoi d'email
est fait avec vue. C'est hyper
facile. Et même,
demain, il y a un Dev
Junior qui se met là-dessus.
Il y arrive tout de suite. Il comprend
comment ça marche, quoi. Donc,
donc c'est... non, vraiment
hyper facile et hyper intéressant à utiliser.
OK.
Donc, OK. Donc, vue e-mail
avec Brevo, la... la P.I.
Ouais. Et une gestion
des langages.
OK. Donc, e-mail
transactionnel de commande principalement,
c'est simple. Exactement. Ouais. En fait,
c'est à chaque fois que... oui,
validation de commande. Et
à chaque étape
aussi de la préparation de la commande,
l'envoi, les choses comme ça.
Ah oui. Donc, un change de statut de la commande
automatiquement. Exactement.
En fait, pour le coup,
il y a
la commande à différents champs,
à différents statuts, pardon. Et
à chaque modification du statut,
en fait, on... ça,
il y a une fonction qui est déclenchée,
où on envoie
un mail au client en disant
votre commande est passée à telle
statue. Votre commande est passée à telle statue.
Pour le coup, c'est un e-commerce pro,
quoi. C'est pour les magasins. Donc,
c'est le... ouais, c'est un pro-shop,
quoi. Donc, ils ont besoin de savoir
où est leur commande
avec toutes les infos et tout.
C'est top. Top.
Et... non, vraiment,
super, et hyper plaisant à utiliser.
Ouais.
J'avais l'impression. Voilà. De toute façon,
c'est clair. Quand tu peux intégrer,
quand tu as déjà une code base qui est en
NUXT soit vue, si tu peux intégrer
un système d'emailings qui est
identique et qui s'intègre parfaitement,
pour pouvoir prêter la main dessus, tu fais les mises à jour,
tu le dis pas. Alors, sans prof, tu déploies.
C'est vachement plus facile à gérer. Téellement plus facile.
Téellement plus facile. Yes.
Oui, nickel. On a
quelques références de liens.
On a une vidéo notamment, je crois, YouTube
sur... j'ai pas vu ce que c'était.
On mettra le lien...
Ouais, je l'ai pas... je l'ai pas la.
Je peux pas la montrer à l'écran, mais
on la mettra en lien
de l'épisode. Et...
C'était...
Alors...
Je suis en train de l'ouvrir.
Général Team Park, Oudini, c'est quoi ce truc?
C'était Kevin Powell qui est un
YouTuber, enfin YouTuber.
Sur le CSS tout ça, qui parle un peu
de newsletter avec un invité Marc Robbins.
Donc, spécialement
dédié à la newsletter. Donc, on mettra le lien.
Personne à suivre, en France.
Il a écrit
un livre, il a écrit...
il a lancé
Can I Email aussi.
C'est HTML...
Attends, c'est dur à dire son pseudo.
HTML.
HTML.
Et pour le coup...
Pour le coup...
Hop! C'est Can I Email.
C'est un peu dans le même délire que
Can I Use en fait.
Le site...
Le site où on vient tester toutes les
balises, les API.
Et par rapport à tel
ou tel navigateur,
est-ce que je peux utiliser
cet élément?
Là, il a sorti
un site qui s'appelle Can I Email
et on peut utiliser
n'importe quelle balise.
Par exemple, Flex, là on peut taper
et on peut voir si c'est supporté ou pas.
Il va te dire qui prend en charge.
Donc on a Apple Email.
J'ai email, ne le prends pas en charge du tout.
Outlook 2020...
Ah, c'est chaud!
Il n'y a pas la Flex, tu vois.
C'est déjà ça oublié.
Ça n'existe pas.
Flex, il ne faut pas utiliser Flex.
Mais...
T'as mis juste l'image. Ah, loading.
Ah oui, loading attribute sur Email.
Ah oui, il y a différents trucs.
Et donc, pour tester...
Là, c'est plus sur la conception.
Intéressant
d'avoir ça.
Et cette personne-là,
c'est le français qui s'appelle
htmele.
On mettra évidemment
son Twitter
dans les notes de Pina.
Et son mastodon, parce qu'a priori, il a migré
sur un mastodon depuis quelques temps.
Apparemment, oui.
Comme un peu ce qu'on va faire tous.
Comme beaucoup.
Et donc...
Ok, très bien.
Et lui, en fait, il a fait pas mal de...
Bah lui, c'est un intégrateur.
Là-bas, c'est un intégrateur
qui est un vrai intégrateur
comme on peut...
Voilà, comme ça existait avant.
Ok. Qui a fait beaucoup de...
Qui a beaucoup d'expérience en termes de newsletter
d'intégration newsletter.
Du coup, il a cumulé beaucoup d'expériences.
Normalement, il me semble qu'il avait fait un livre.
Je sais plus sous quelle édition.
Qui parlait des emails, l'intégration, l'envoi, tout ça.
Et...
Enfin, il a beaucoup écrit là-dessus.
Et puis, voilà, du coup, il a...
Je pense que c'est une des personnes qui a le plus d'expérience
en termes d'intégration d'emails
et qui a épongé beaucoup de problèmes.
En France ?
Oui, en France, monsieur.
Et donc, c'est un outil qui est vraiment pratique,
qui a un email qui est pratique
quand vous voulez intégrer des emails.
Pour dire...
au marketing et au design,
bah non, mais tu vois bien, ça marche pas.
C'est pas possible. On peut pas l'envoyer.
On ne peut pas faire ça.
On ne peut pas faire ça.
Ok, cool.
Parfait.
Patrick, je crois qu'on a un peu fait le tour
de...
de tout ce qu'on pensait
être intéressant pour
gérer les emails en tant que nous,
devs. Et on espère
que, justement,
on a abordé, on va dire,
la vision systémique
de l'emailing pour les devs, quoi.
Ouais, ouais.
J'espère que ça vous a appris beaucoup de choses.
Et puis, il faut pas avoir peur
de faire des emails.
Ouais, il faut y aller. Il faut tester, comme toujours.
Il faut tester.
Ouais, il y a beaucoup de teams maintenant.
C'est plus facile qu'avant.
Ouais, après, si le marketing
ne sait pas exactement ce qu'il veut,
ça peut être très compliqué.
Par contre, s'il y a designer
marketeux qui savent exactement ce qu'ils veulent,
à mon avis, vous avez meilleur temps
de réintégrer, de reprendre le pouvoir
là-dessus. Et là,
c'est crème, quoi.
Aujourd'hui, on a tous les outils pour.
Ouais, carrément.
Le marketing, par contre, ne savent jamais vraiment ce qu'il veut.
C'est un autre CG, Patrick.
On va pas rentrer dans la polémique.
On va pas rentrer dans la polémique.
Oui, c'est clair.
Un grand merci à tous.
Merci d'être restés jusqu'au bout de l'épisode.
On vous dit à bientôt.
Et code email.
Ciao ciao.
Retrouvez Double Slash
sur le plateforme de podcasts préférés
et sur le site internet du podcast
www.slash-podcast.fr
Sur le site, vous allez retrouver
tous les liens de l'épisode, les références
évoquées durant l'émission.