YourTrend — une plateforme de messagerie par email, SMS et notifications push

01Aperçu du projet

VotreTendance est une plateforme de messagerie pour les entreprises : e-mails transactionnels et marketing, SMS et notifications web depuis une seule API. Le slogan du produit se lit comme une promesse — "Les e-mails que vos clients reçoivent réellement". Derrière cette promesse se cache une ingénierie très concrète : chaque domaine connecté est signé DKIM, les enregistrements SPF et DMARC sont générés automatiquement, l'envoi se fait via une IP dédiée, et les désabonnements, plaintes et rebonds sont gérés par la plateforme elle-même, sans effort de l'expéditeur.

L'idée est née d'une observation familière à quiconque a lancé des produits en ligne : envoyer un e-mail depuis une application est facile, mais faire en sorte qu'il atterrisse dans la boîte de réception de manière cohérente est un métier à part entière. Année après année, les fournisseurs de boîtes aux lettres renforcent leurs exigences en matière d'authentification et de réputation des expéditeurs, et "SMTP simple" sans DKIM, SPF et DMARC signifie de plus en plus le dossier spam — ou un rejet silencieux. Pendant ce temps, l'entreprise accumule un zoo de services : un pour le courrier transactionnel, un autre pour les campagnes marketing, un troisième pour les SMS, un quatrième pour les notifications push. Chacun a sa propre API, ses propres contacts, ses propres statistiques — et aucune image cohérente nulle part.

YourTrend regroupe tout cela en une seule plateforme : un relais SMTP et une API HTTP propre pour l'envoi, des campagnes et des automatisations pour le marketing, des SMS et des notifications web sur la même base de contacts, une boîte de réception unifiée pour le courrier entrant sur chaque domaine, et une boîte aux lettres chiffrée à accès zéro pour la correspondance privée. Nous avons conçu et construit le produit de bout en bout — depuis le pipeline de livraison et le modèle d'événements jusqu'au tableau de bord, la documentation et les pages d'atterrissage trilingues (EN/UK/RU).

Comme les autres produits écosystémiques du studio, YourTrend n'a jamais été conçu comme un service ponctuel mais comme une couche de communication partagée: connectez un domaine une fois, et tous les mails de vos projets — des reçus aux campagnes — passent par un seul pipeline avec une réputation, une vue analytique et un modèle d'événements. Ci-dessous, nous décomposons comment le système fonctionne en interne et quelles décisions d'ingénierie font de la délivrabilité une propriété de l'architecture plutôt qu'un accident heureux.

02Contexte et le problème

Il y a un paradoxe concernant les mails envoyés depuis votre propre application : cela "fonctionne" jusqu'au moment où cela compte vraiment. Tant que les volumes sont faibles, tout semble en ordre ; à mesure qu'ils augmentent et que les règles des fournisseurs se resserrent, un ensemble de douleurs émerge :

• Spam au lieu de la boîte de réception. Sans DKIM, SPF et DMARC corrects, même les messages transactionnels honnêtes finissent dans le spam ou sont rejetés. Configurer ces enregistrements correctement du premier coup est une tâche qui fait trébucher même les équipes expérimentées.
• Réputation IP partagée. Sur une infrastructure partagée, votre délivrabilité dépend de vos voisins : l'envoi agressif de quelqu'un d'autre nuit à la réputation de l'IP pour tous ceux qui l'utilisent.
• Doublons lors des nouvelles tentatives. Le réseau clignote, l'application répète la demande — et l'utilisateur reçoit deux reçus identiques. Sans idempotence du côté de l'API, cela est inévitable.
• Canaux déconnectés.Email dans un service, SMS dans un autre, push dans un troisième : les contacts et segments ne correspondent pas, et la "vue unique du client" n'existe que dans des présentations.
• Hygiène manuelle des listes.Les rebonds et les plaintes doivent être détectés et exclus des envois futurs. Presque personne ne le fait manuellement — et la réputation se dégrade silencieusement à chaque campagne.
• Courrier entrant éparpillé partout.Une entreprise avec plusieurs domaines a des réponses clients dispersées à travers des boîtes aux lettres et des onglets, et répondre depuis l'adresse exacte à laquelle ils ont écrit est une quête en soi.

Le brief était le suivant : construire une plateforme où la délivrabilité n'est pas le résultat d'une configuration laborieuse mais une propriété par défaut. Le développeur connecte un domaine, publie les enregistrements DNS générés et envoie ; tout le reste — signature, réputation, listes de suppression, désabonnements — la plateforme s'en occupe.

Une couche distincte de la tâche concernait le pipeline lui-même. Un email de réinitialisation de mot de passe doit partir en quelques secondes et n'a pas le droit de se perdre ; une campagne marketing à des milliers d'adresses ne doit pas interférer avec le flux transactionnel ; et pour chaque message, l'expéditeur doit voir ce qui lui est arrivé : accepté, livré, ouvert, rejeté, signalé. Tout cela avec deux chemins d'intégration également pris en charge : le bon vieux SMTP pour les applications existantes et une API HTTP propre pour les nouvelles.

03Objectifs du projet

Du brief ont émergé des objectifs concrets en matière de produit et d'ingénierie que nous avons gardés en focus à chaque étape :

• Livrabilité par défaut.Signature DKIM pour chaque domaine, génération automatique de SPF et DMARC, une IP d'envoi dédiée, listes de suppression automatiques et désinscription en un clic.
• Deux points d'entrée — un pipeline.Un relais SMTP pour les applications qui savent déjà comment envoyer des e-mails, et une API REST pour tout le reste. À l'intérieur — le même pipeline avec les mêmes garanties.
• Idempotence et regroupement.Une demande répétée ne produit jamais un deuxième e-mail ; les envois en masse se font par lots, et non en milliers d'appels individuels.
• Trois canaux sur une seule base.L'e-mail, le SMS et les notifications web fonctionnent avec les mêmes contacts et segments — pas d'exportations CSV entre les services.
• Observabilité.Chaque événement — livraison, ouverture, clic, rebond, plainte — est visible dans le tableau de bord et diffusé vers les webhooks de l'expéditeur.
• Courrier entrant au même endroit.Une boîte de réception unifiée à travers tous les domaines avec des réponses de l'adresse de réception exacte, plus une boîte aux lettres chiffrée à accès zéro pour la correspondance privée.

Comme dans nos autres produits, ces objectifs ont fonctionné comme des contraintes qui ont éliminé les options inappropriées à l'étape de conception. L'exigence des "deux points d'entrée — un pipeline" interdisait de faire du relais SMTP une "façade" avec sa propre logique séparée : à la fois SMTP et l'API déposent des messages dans le même pipeline avec les mêmes vérifications. L'exigence d'observabilité nous a forcés à concevoir le modèle d'événements avant que le premier gestionnaire ne soit écrit. Et "livrabilité par défaut" signifiait quelque chose de simple : aucun chemin d'intégration ne peut jamais permettre d'envoyer depuis un domaine sans une authentification correcte.

04Ce que nous avons construit

YourTrend organise la messagerie en quatre piliers qui couvrent ensemble l'ensemble du cycle de communication d'une entreprise :

Au-dessus du cœur se trouve un tableau de bord avec des analyses et la gestion de domaine, un client webmail, de la documentation, une page de statut et des pages d'atterrissage en trois langues. Commencer est gratuit : connectez un domaine, publiez les enregistrements DNS générés et envoyez votre premier email — tout le parcours s'inscrit en trois étapes.

Il est crucial que les quatre piliers n'existent pas en isolation. Le pipeline d'envoi alimente les analyses, les analyses alimentent les listes de suppression, la base de contacts alimente les trois canaux, et la boîte de réception unifiée boucle le processus en ramenant les réponses des destinataires sur la plateforme. L'intégrateur ne travaille pas avec un ensemble de services mais avec un système où chaque message partage un cycle de vie unique : accepté → préparé → signé → livré → événement.

05Architecture de la solution

Logiquement, YourTrend se compose de six blocs, chacun avec son propre domaine de responsabilité et des limites claires :

• Intégration — le relais SMTP (mail.yourtrend.online : authentification, STARTTLS) et l'API HTTP : validation, vérification de l'expéditeur, idempotence.
• Pipeline de traitement — files d'attente : rendu de modèles, personnalisation, vérification des destinataires par rapport aux listes de suppression, signature DKIM.
• Livraison — envoi depuis une IP dédiée, gestion des connexions aux serveurs récepteurs, réessais en cas d'échecs transitoires.
• Boucle d'événements — les livraisons, rebonds, plaintes, ouvertures et clics sont collectés dans un seul flux ; le tableau de bord et les webhooks lisent une seule source.
• Boucle entrante — réception de courriers pour les domaines de l'utilisateur, la boîte de réception unifiée, réponse depuis l'adresse exacte ; la boîte aux lettres à accès zéro fonctionne comme une piste séparée.
• Graphique de contacts — adresses e-mail, numéros de téléphone et abonnements push vivent sur un seul contact ; les segments sont partagés sur tous les canaux.

Cette division nous a permis de séparer les flux avec des exigences différentes. Le courrier transactionnel est sensible à la latence — son chemin à travers le pipeline est aussi court que possible. Les campagnes sont sensibles au débit — elles voyagent par lots et ne se bousculent jamais dans la même file d'attente que les reçus et les réinitialisations de mot de passe. La boucle d'événements est délibérément maintenue à part : le tableau de bord et les webhooks ne sont que des lecteurs du même flux d'événements, donc leurs lectures ne divergent jamais.

Les rôles sont également séparés au niveau de l'hôte : le site de destination avec la documentation, le tableau de bord, le webmail et le relais SMTP vivent chacun à leur propre adresse avec leurs propres politiques d'accès et de mise en cache — le site public ne partage pas un environnement avec les interfaces où les utilisateurs travaillent avec leur courrier. Cloudflare gère DNS, TLS et protection périmétrique ; une intégration avec cela permet également de publier les enregistrements DNS d'un domaine avec une seule commande directement depuis l'intégration.

06Comment un message voyage

Du point de vue de l'intégrateur, le parcours d'un message s'inscrit dans cinq étapes, et la plupart d'entre elles se déroulent sans leur intervention :

• 1. Réception. L'application remet l'e-mail — une requête SMTP au relais ou un POST à l'API. Le temps d'acceptation médian de l'API est inférieur à deux secondes : la requête est validée, dédupliquée par clé d'idempotence et mise en file d'attente.
• 2. Préparation.Le pipeline rend le modèle, remplit les données du destinataire et vérifie l'adresse par rapport à la liste de suppression : toute personne qui s'est désabonnée ou a porté plainte ne recevra pas le message.
• 3. Signature.L'email est signé avec la clé DKIM du domaine de l'expéditeur ; SPF et DMARC ont été publiés dans le DNS depuis que le domaine a été connecté. Pour le serveur récepteur, le message est cryptographiquement lié au domaine.
• 4. Livraison.L'envoi se fait via une IP dédiée ; les échecs transitoires — greylisting, un destinataire surchargé — sont gérés par des nouvelles tentatives avec des intervalles croissants.
• 5. Événements.Accepté, livré, rejeté, ouvert, cliqué, plaint — chaque événement est enregistré, apparaît dans le tableau de bord et est diffusé vers les webhooks de l'expéditeur.

Il y a un détail de principe ici que nous avons promu dans le modèle de données : "accepté" et "livré" sont des événements différents. L'API peut accepter un email en une fraction de seconde, mais son sort est décidé plus tard, du côté du serveur récepteur. La plateforme ne cache pas cette différence derrière un seul statut "envoyé" ; elle montre tout le parcours : l'intégrateur voit à la fois l'accusé de réception instantané et le résultat de la livraison réelle, ainsi que tout ce qui s'est passé entre les deux.

Le deuxième détail est l'idempotence. Les erreurs réseau sont inévitables, et la réaction correcte d'un client à un délai d'attente est de réessayer la demande. Si les deux demandes atteignent la plateforme, elle reconnaît par la clé d'idempotence qu'il s'agit du même e-mail et l'envoie une seule fois. Le même principe protège les lots : renvoyer un lot ne duplique jamais les messages. Pour le courrier transactionnel, ce n'est pas une commodité mais une exigence de précision : deux reçus pour un achat sapent la confiance plus qu'un reçu perdu.

07Fonctionnalités clés

Examinons ce qui fait que YourTrend n'est pas un "blaster d'e-mails" mais une plateforme de communication de qualité professionnelle.

E-mail transactionnel

Reçus, réinitialisations de mot de passe, notifications d'événements — des messages que l'utilisateur attend en ce moment. Ils prennent le chemin le plus court à travers le pipeline : signés, suivis et livrés en quelques secondes. Ils n'ont besoin d'aucune campagne ou segment — juste d'un appel API ou d'une requête SMTP depuis le code de l'application.

Relais SMTP et API HTTP

Une application existante n'a pas besoin d'être réécrite pour une nouvelle API : il suffit de pointer son hôte SMTP vers le relais de la plateforme et de fournir des identifiants — tout ce que l'application sait déjà envoyer passe maintenant par le pipeline de YourTrend avec signature et analyses. Les nouvelles intégrations sont plus faciles à construire sur REST : une requête JSON, des réponses prévisibles, des erreurs lisibles par machine. Autour de l'API, la plateforme est conviviale pour l'écosystème : Laravel, Node.js, Python, WordPress, Zapier et React figurent parmi les chemins d'intégration répertoriés.

Idempotence et traitement par lots

Un appel répété avec la même clé ne crée jamais un deuxième e-mail — les réessais sont sûrs par construction. Les envois en masse sont assemblés en lots afin que des milliers de messages ne deviennent pas des milliers de demandes individuelles : moins de bruit réseau, un meilleur débit, un code plus simple du côté de l'intégrateur.

SMS

Lorsque l'e-mail n'est pas le bon canal — un code de confirmation, un avis de livraison urgent — un SMS est envoyé depuis la même base de contacts : messages transactionnels et marketing, les mêmes segments, la même boucle d'événements. Pas besoin de maintenir une deuxième base de données de numéros de téléphone dans un service séparé.

Web push

Les notifications de navigateur ramènent les utilisateurs sur le site : abonnements strictement opt-in, audiences segmentées, livraison instantanée. Pour les produits sans application mobile, c'est le chemin le plus court vers le "push" — pas de magasins d'applications, de SDK ou de cycles de publication.

Analytique et webhooks

Les ouvertures, clics, rebonds et plaintes sont visibles dans le tableau de bord — et diffusés vers des webhooks en parallèle. Le tableau de bord est pratique pour les humains, les webhooks pour le code : vous pouvez construire votre propre logique sur les événements (par exemple, signaler les adresses à rebond dur dans votre propre CRM) sans interroger l'API en boucle.

08Livrabilité en tant qu'ingénierie

La délivrabilité est souvent considérée comme de la magie, ou comme un service de "réchauffement" facturé par abonnement. Nous l'avons abordée comme un problème d'ingénierie avec des composants concrets, chacun d'eux intégré à la plateforme :

• DKIM pour chaque domaine.Chaque domaine connecté obtient une clé, et chaque e-mail est signé : le serveur récepteur vérifie cryptographiquement que le message provient réellement de votre domaine et n'a pas été altéré en transit.
• SPF et DMARC — générés pour vous.La plateforme n'envoie pas l'utilisateur lire des RFC : les enregistrements prêts à l'emploi peuvent être copiés dans le DNS tels quels — ou publiés avec une seule commande via l'intégration Cloudflare.
• Une adresse IP d'envoi dédiée.La réputation n'est pas partagée avec les campagnes d'autres personnes : votre mail part d'une adresse dont l'historique est façonné uniquement par vous.
• Désinscription en un clic (RFC 8058).Liste-Désinscription en un clic : le destinataire se désinscrit avec un bouton dans son client mail, sans ouvrir de site web. C'est une exigence que les grands fournisseurs imposent aux expéditeurs en masse — et le meilleur moyen de transformer une plainte potentielle en une désinscription silencieuse.
• Suppression automatique.Un rebond dur, une plainte, une désinscription — l'adresse atterrit automatiquement sur la liste de suppression et est exclue des envois futurs. Les listes se nettoient d'elles-mêmes ; la réputation ne se dégrade pas.

L'ordre compte ici : l'authentification sans hygiène de liste ne vous sauve pas, et l'hygiène sans authentification est inutile. C'est pourquoi ces mécanismes ne sont pas des "fonctionnalités sur une liste de prix" mais des parties obligatoires du pipeline : la plateforme n'enverra pas depuis un domaine non vérifié et ne laissera pas les plaintes être ignorées. L'expéditeur peut oublier la délivrabilité précisément parce que l'architecture ne lui permettra pas de l'oublier de manière significative.

09Sécurité et mail sans accès

Une plateforme qui gère le courrier transactionnel d'autres personnes doit être méticuleuse en matière d'accès. L'envoi via le relais SMTP nécessite une authentification et est protégé par STARTTLS ; l'accès API se fait par des clés d'expéditeur ; tout le trafic passe uniquement par TLS. Le désabonnement en un clic et la suppression automatique fonctionnent également comme des mécanismes de sécurité : ils empêchent la plateforme d'être transformée en source de courrier indésirable, et la politique anti-spam publiée consacre cela dans des règles qui protègent à la fois les destinataires et la réputation des expéditeurs honnêtes.

Une partie distincte du produit est le boîte aux lettres chiffrée à accès zéro. C'est du courrier pour la correspondance privée construit sur un chiffrement de bout en bout : le contenu est chiffré du côté de l'utilisateur, et le serveur ne stocke que du texte chiffré. "Accès zéro" est ici littéral : la plateforme n'a aucune capacité technique pour lire ces messages — il n'y a pas de clés, rien à remettre sur demande, et rien à perdre en cas de compromission.

Nous avons délibérément séparé les deux circuits. Le courrier régulier est accompagné des analyses d'ouverture et de clics dont une entreprise a besoin ; la boîte aux lettres privée n'a pas d'analytique par construction, car le serveur ne voit jamais le contenu. L'utilisateur choisit le circuit pour la tâche au lieu d'accepter un compromis pour tout en même temps.

10Campagnes et automatisations

Le côté marketing de YourTrend est construit autour des campagnes et des automatisations. Une campagne est un envoi à un segment : la plateforme peut segmenter des listes, tester des lignes d'objet en A/B, et envoyer des modèles réactifs qui s'affichent correctement sur les ordinateurs de bureau et sur les clients mobiles. Tout cela à grande échelle : le pipeline est conçu pour des envois en masse qui ne perturbent jamais le flux transactionnel.

Les automatisations suppriment la routine de "un message par événement" : une série de bienvenue après l'inscription, un flux de goutte à goutte après un achat, un message de reconquête après une pause. Les flux sont assemblés sans code : événement → message → intervalle → prochain message. Une fois configurée, une automatisation fonctionne seule, et chaque e-mail qu'elle produit passe par le même pipeline — avec signature, suppression et analyses — que tout le reste.

Il est significatif que le circuit marketing ne soit pas isolé de celui transactionnel : les contacts et les événements sont partagés. Si une adresse se désinscrit ou rebondit durement, les campagnes en tiennent immédiatement compte ; si une campagne amène un utilisateur à un achat, le reçu transactionnel va au même contact via la même plateforme. Pour l'entreprise, cela signifie une base unique et un historique de communications au lieu d'exports CSV entre trois services.

11La boîte de réception unifiée

Les plateformes d'envoi s'arrêtent généralement là où le courrier entrant commence. YourTrend va plus loin : tout le courrier arrivant sur les domaines connectés est collecté dans une boîte de réception unifiée. Une interface au lieu d'une douzaine d'onglets de webmail, une recherche à travers toute la correspondance — et une habitude au lieu d'une roulette de connexion entre les boîtes aux lettres.

Le détail clé : une réponse est envoyée de la même adresse que celle à laquelle le message est arrivé. Un client a écrit à l'adresse de support de l'un de vos domaines — la réponse vient exactement de cette adresse, et non d'une boîte aux lettres "générale" de la plateforme. Pour le destinataire, le fil de discussion semble fluide ; l'expéditeur n'a pas à suivre de quel domaine il répond — la plateforme choisit l'adresse elle-même.

Pour les studios, les agences et les propriétaires de plusieurs projets, c'est un superpouvoir silencieux : chaque produit a son propre domaine et ses propres adresses, mais toute la correspondance vit au même endroit. Le webmail fonctionne comme une application séparée et ne se mélange pas avec le tableau de bord marketing ; la même interface sert également la boîte aux lettres à accès zéro — avec la différence que son contenu est déchiffré uniquement du côté de l'utilisateur.

12Expérience développeur et intégrations

Nous avons conçu YourTrend du point de vue d'un développeur qui veut "brancher l'email et l'oublier". D'où les trois étapes pour la production : ajouter un domaine et publier le SPF, DKIM et DMARC générés (copier-coller ou une commande via Cloudflare), connecter — relais SMTP ou API HTTP — et envoyer. Commencer est gratuit ; l'échelle vient à mesure que vous grandissez.

L'intégration est conviviale pour n'importe quelle pile : Laravel, Node.js, Python, WordPress, Zapier et React figurent parmi les chemins répertoriés. Les applications héritées ont déjà un client SMTP ; les nouvelles ont HTTP ; dans les deux cas, le chemin vers le premier email se mesure en minutes, pas en sprint. La documentation, la référence API et la page d'état sont publiques — vous pouvez intégrer sans un seul appel.

Testé en conditions réelles — sur nous-mêmes.Le formulaire de contact et le mail transactionnel d'ostohlo.com passent par le relais SMTP mail.yourtrend.online — authentifié, via STARTTLS. La plateforme gère le mail de production de l'ensemble de l'écosystème du studio : chaque message que nous envoyons aux clients passe par le même pipeline que le mail de tout utilisateur de YourTrend. C'est la meilleure forme de contrôle qualité qui soit : si le pipeline perdait des messages, nous serions les premiers à le remarquer — sur nos propres prospects entrants.

13Technologie et infrastructure

YourTrend fonctionne dans un environnement dédié où les interfaces web, l'API et les processus de livraison en arrière-plan coexistent — avec des profils de charge différents mais un modèle de données partagé.

• Backend — PHP 8.3 : l'API, le tableau de bord, le pipeline de traitement et la boucle d'événements dans un environnement prévisible.
• Couche de mail — un relais SMTP authentifié avec STARTTLS, signature DKIM, files d'attente avec réessais, listes de suppression automatiques.
• Canaux — une passerelle SMS et un web push sur le même modèle de contact ; la boîte de réception unifiée et le webmail pour les mails entrants.
• Infrastructure — Cloudflare (DNS, TLS, protection périmétrique) avec une intégration pour la publication de l'enregistrement DNS en une commande ; une IP dédiée pour l'envoi.

La structure porteuse de toute la plateforme est les files d'attente. Elles découpent l'entrée de la livraison : l'API répond en une fraction de seconde car elle n'attend jamais le serveur récepteur ; le flux transactionnel ne fait jamais la queue derrière une campagne ; les réessais sont une partie naturelle du modèle plutôt qu'un correctif. Le choix de PHP 8.3 est pragmatique : une plateforme mature et rapide qui héberge confortablement l'API, les interfaces et les processus en arrière-plan dans une seule pile. Cloudflare ferme le périmètre et le DNS — et fournit également cette intégration "une commande" qui transforme l'étape la plus effrayante pour un nouveau venu, la configuration DNS, en une formalité.

14Design et UX

Un produit d'infrastructure vend la confiance, donc la page d'accueil de YourTrend explique la valeur en quelques secondes : "Email que vos clients reçoivent réellement", trois étapes pour lancer, et des chiffres honnêtes — un objectif de disponibilité de 99,9 % et un temps d'acceptation de l'API médian de moins de deux secondes. Le produit est trilingue — EN, UK et RU : les interfaces, la documentation et les pages d'accueil sont écrites dans chaque langue, sans passer par un traducteur.

Le ton du produit est défini par sa mascotte — Trendy, une enveloppe verte amicale. Pour un outil B2B, c'est un choix délibéré : l'infrastructure email est un sujet aride, et un personnage charmant abaisse la barrière d'entrée sans diluer la profondeur technique. À côté de cela sur la page d'accueil se trouvent des cartes de canaux flottantes et un ruban d'intégrations : en quelques secondes, un visiteur comprend à la fois ce que fait la plateforme et avec quoi elle fonctionne bien.

La zone UX la plus importante est l'intégration de domaine. C'est généralement le moment où un nouvel arrivant se noie dans les enregistrements TXT ; YourTrend génère les enregistrements et les présente prêts à être copiés, et avec Cloudflare, les publie en une seule commande. Nous avons traité cet écran de la même manière que nous traitons un paiement dans des projets fintech : c'est l'endroit où l'utilisateur atteint la valeur ou s'en va. Chaque détail — de la formulation à l'ordre des étapes — vise à faire en sorte que le premier email livré avec succès se produise le plus tôt possible.

15Comment nous avons travaillé

Nous avons mené le projet en étapes séquentielles, démontrant un résultat à chaque étape :

• Recherche.Nous avons cartographié les exigences des fournisseurs de boîtes aux lettres pour l'authentification et les expéditeurs en masse (DKIM, SPF, DMARC, RFC 8058), les scénarios d'envoi transactionnel et marketing, ainsi que les canaux SMS et push.
• Architecture.Nous avons conçu le pipeline, le modèle d'événements, le graphique de contacts et les contrats : formats API, sémantique d'idempotence, schéma de liste de suppression.
• Noyau.Nous avons construit l'entrée (le relais SMTP et l'API), les files d'attente, la signature DKIM, la livraison depuis une IP dédiée, la boucle d'événements et le tableau de bord.
• Canaux et boîte de réception.Nous avons ajouté SMS, notifications web, la boîte de réception unifiée avec le webmail, et la boîte aux lettres chiffrée à accès zéro.
• Lancer.Nous avons déployé l'infrastructure derrière Cloudflare, produit les pages d'atterrissage, la documentation et la page de statut en trois langues — et déplacé le mail de notre propre écosystème sur la plateforme.

L'ordre n'est pas accidentel : d'abord, nous avons corrigé les contrats — le modèle d'événements, la sémantique de l'API, les règles de suppression — et seulement ensuite avons-nous construit l'implémentation autour d'eux. Le dogfooding était dans le plan depuis le tout début : le premier "client" de la plateforme était notre propre studio, et certaines décisions produit — comme la manière de faire ressortir la différence entre "accepté" et "livré" — sont nées de notre propre expérience opérationnelle plutôt que d'hypothèses.

16Le résultat

Ce que nous avons obtenu n'est pas "encore un autre expéditeur" mais une plateforme de communication à cycle complet : des enregistrements DNS à l'analyse, d'un reçu à une campagne, de SMS à une boîte aux lettres chiffrée.

• Un domaine se connecte en quelques minutes : SPF, DKIM et DMARC sont générés automatiquement et publiés par copier-coller ou avec une commande via Cloudflare.
• Les mails transactionnels et marketing, SMS et push sont en direct sur une base de contacts avec un ensemble d'analyses.
• Les événements de chaque message sont visibles dans le tableau de bord et diffusés vers des webhooks — l'intégrateur construit sa propre logique par-dessus sans interroger l'API.
• La plateforme gère le mail de production de l'écosystème du studio : le formulaire de contact d'ostohlo.com et les messages transactionnels passent par son relais SMTP.

Le principal changement réside dans le modèle. L'email a cessé d'être un ensemble éparpillé de paramètres par projet et est devenu une couche partagée : un nouveau produit écosystémique se connecte à un pipeline prêt avec une réputation établie, et le premier email d'un nouveau site hérite de toute l'ingénierie que la plateforme a accumulée — de la signature DKIM aux listes de suppression.

17Leçons à retenir

YourTrend est une étude de cas sur la délivrabilité étant une architecture, pas de la chance. Tout ce qui décide du sort d'un email — signature, enregistrements DNS, réputation IP, hygiène des listes, désabonnements — est depuis longtemps connu et consigné dans des normes ; la seule question est de savoir si cela se fait par défaut ou est laissé à l'utilisateur "pour plus tard". Nous avons choisi la première option — et c'est précisément ce qui sépare une plateforme d'un manuel de configuration.

Pour nous, c'était un projet à l'intersection des protocoles, de l'infrastructure et du produit : SMTP et DNS, files d'attente et modèles d'événements, scénarios marketing et cryptographie d'une boîte aux lettres à accès zéro. Si vous avez besoin d'un service avec une API, un pipeline de traitement et des exigences de fiabilité exigeantes — d'une passerelle de paiement à une plateforme de communication — nous savons comment mener cela à bien jusqu'au lancement.

Et une conclusion méthodologique : le meilleur test d'un produit d'infrastructure est de mettre votre propre entreprise dessus. YourTrend gère le courrier du studio et de son écosystème, et chaque incident qui ne s'est pas produit est une conséquence directe des décisions prises au stade de l'architecture : idempotence, modèle d'événements, suppression automatique. C'est exactement ainsi que nous abordons le travail — d'abord les bons contrats et limites, et seulement ensuite tout le reste.