L'ingénierie de Vowly Event : faire-part numériques et RSVP en ligne

Vowly Event fait quelque chose qui paraît simple jusqu'à ce qu'on le construise : envoyer des faire-part de mariage numériques et recueillir les réponses en ligne. Un couple, une liste d'invités, des centaines de personnes qui doivent chacune recevoir quelque chose de personnel et renvoyer quelque chose. Nous construisons et exploitons ce produit ; voici comment nous abordons les parties plus difficiles qu'elles n'en ont l'air.

Le produit, c'est la liste d'invités

La plupart des gens pensent que le produit, c'est le faire-part. Ce n'est pas le cas. Le faire-part est la surface visible ; la liste d'invités porte tout le poids. Elle est modifiée en permanence, jusqu'à la semaine du mariage. Des noms sont corrigés, des accompagnants apparaissent, une famille entière est ajoutée après un appel avec un parent, et quelques personnes sont discrètement retirées.

Le modèle de données ne peut donc pas traiter un invité comme une ligne écrite une seule fois. Un invité est une petite histoire : invité, a ouvert, a répondu, a changé d'avis, est revenu en arrière. Ne modéliser que l'état courant, c'est renoncer à répondre à la question que les couples posent vraiment — non pas « combien viennent », mais « qui n'a pas encore répondu, et a-t-il seulement ouvert le message ».

Des foyers, pas des individus

La deuxième décision de modélisation qui se rentabilise est le regroupement. Les invitations partent vers des foyers, pas vers des personnes. Une famille de quatre reçoit une invitation et répond une fois, mais le plan de table, le nombre de couverts et les régimes alimentaires exigent des individus. Se tromper tôt oblige chaque fonctionnalité suivante à contourner l'erreur : l'entité invité et l'entité invitation doivent être séparées dès le premier commit.

Un trafic qui arrive par vagues

Le trafic d'un mariage n'est pas une courbe lisse. Un couple envoie les faire-part un dimanche soir et une grande partie de la liste ouvre le lien dans les deux heures. Puis il ne se passe presque rien pendant une semaine. Puis vient un second pic au moment du rappel.

Cette forme récompense des choix précis. La page du faire-part doit être statique ou quasi statique et servie depuis un cache en périphérie, car elle est identique pour tous les invités d'un foyer et c'est elle qui encaisse la vague. Le chemin d'écriture — l'envoi du RSVP — est la seule partie qui doit réellement atteindre une base de données, et il représente une fraction des requêtes. Séparer les deux permet de dimensionner l'infrastructure coûteuse pour les réponses, pas pour les consultations.

La partie ingrate : la délivrabilité

Envoyer quelques centaines de messages est facile. Faire en sorte qu'ils arrivent tous ne l'est pas. Les invitations empruntent des canaux que l'expéditeur ne contrôle pas, et un message tombé dans les indésirables est, du point de vue du couple, indiscernable d'un invité qui les ignore.

• Authentifier correctement le domaine d'envoi — SPF, DKIM et DMARC ne sont pas facultatifs quand tout le produit dépend de la délivrabilité.
• Suivre ouvertures et clics par invité, afin que le couple voie qui n'a réellement pas vu l'invitation plutôt que de deviner.
• Chaque lien doit fonctionner sans compte. Un mur d'authentification entre un invité et un formulaire RSVP coûte des réponses.
• Partir du principe que certains invités appelleront le couple. La saisie manuelle doit être un chemin de première classe, pas un bricolage d'administration.

La place de l'application

Vowly Event existe aussi en application sur l'App Store et Google Play. La répartition utile : la surface web appartient à l'invité, l'application au couple. On ne doit jamais demander à un invité d'installer quoi que ce soit ; il reçoit un lien et un formulaire. Le couple, qui ouvrira le produit des dizaines de fois sur plusieurs mois, obtient la surface plus riche où vit la liste d'invités.

Ce que nous dirions à une autre équipe

Construisez d'abord la liste d'invités, les maquettes ensuite. Traitez la délivrabilité comme un problème d'ingénierie assorti de mesures, pas comme un réglage effectué une fois. Et dimensionnez pour la vague de lecture, pas pour la moyenne — la moyenne n'a aucun sens quand le trafic arrive par vagues de deux heures.