Je vais écrire ces "journaux de build" de temps en temps — de courts comptes rendus honnêtes de quelque chose que j'ai réellement construit récemment et des décisions qui sous-tendent. Pas des tutoriels, pas de grands discours d'expert. Juste le vrai raisonnement, y compris les parties que je ferais différemment. Si vous êtes une entreprise belge qui se demande à quoi ressemble vraiment l'"ingénierie senior" en pratique, c'est ce qui se rapproche le plus de regarder par-dessus mon épaule.
Celui-ci porte sur le parcours de capture de leads de ce site même : le test de préparation à l'IA, les ressources gratuites, le calculateur de ROI, et les inscriptions à la newsletter. Tous aboutissent au même endroit. Voici comment, et pourquoi j'ai fait les choix que j'ai faits.
L'objectif, énoncé clairement
Je voulais trois points de conversion "doux" différents — un quiz, des téléchargements protégés, un calculateur — déposant tous une adresse e-mail dans une liste de diffusion, et je voulais savoir de quelle surface venait chaque inscrit. Sans ajouter une plateforme marketing, sans exposer de clés d'API au navigateur, et sans ralentir le site.
C'est tout. Une portée volontairement réduite.
Décision 1 : un outil, pas trois
La version tentante consiste à prendre un outil dédié par tâche — une plateforme de quiz, un widget de formulaire, un service d'e-mail. Trois abonnements, trois intégrations, trois choses qui peuvent casser.
Le site utilisait déjà Brevo pour le formulaire de contact (e-mail transactionnel). Brevo gère aussi les listes de contacts et les automatisations. Donc le geste honnête était : utiliser ce qui est déjà là. Un compte, une clé d'API, une intégration à raisonner.
C'est le genre de décision qui n'apparaît pas dans une démo mais qui apparaît dans la facture et la charge de maintenance dix-huit mois plus tard. Moins de pièces mobiles est une fonctionnalité.
Décision 2 : les identifiants ne touchent jamais le navigateur
Chaque formulaire de capture du site envoie vers une petite route serveur (/api/newsletter), et celle-ci parle à Brevo. La clé d'API vit uniquement côté serveur — elle n'est jamais dans le bundle client.
Cela semble évident, mais le raccourci courant consiste à appeler le fournisseur d'e-mail directement depuis le navigateur avec une clé "publique". Ça marche jusqu'à ce que ça ne marche plus : les clés publiques sont récupérées et détournées. Une route serveur fine, c'est quelques lignes de plus et cela supprime toute cette catégorie de problème.
La route valide l'entrée avec un schéma, puis appelle Brevo. Si Brevo n'est pas configuré, elle renvoie une erreur propre et le formulaire affiche un message convivial — pas de stack traces, pas d'état à moitié cassé.
Décision 3 : dégradation gracieuse plutôt que fallbacks astucieux
En voici une petite dont je suis content. La route newsletter a besoin de deux choses : une clé d'API et un identifiant de liste cible. Si l'un des deux manque, la route renvoie une réponse "non configuré" et l'UI affiche son état d'erreur normal.
Pas de fausses données qui font semblant de marcher. Pas de succès silencieux qui perd l'e-mail. Si ce n'est pas branché, ça le dit. Quand le vrai identifiant de liste est mis dans l'environnement, ça se met simplement à marcher — sans changement de code.
Cette honnêteté compte plus qu'il n'y paraît. Le pire mode de défaillance pour un formulaire d'inscription, c'est celui qui semble avoir marché et abandonne silencieusement l'adresse. Je préfère qu'il échoue visiblement plutôt qu'il mente silencieusement.
Décision 4 : taguer la source, pour que les données valent la peine
Chaque capture transmet une source — quiz, roi-calculator, lead-magnet:ai-policy, footer, et ainsi de suite — stockée comme attribut sur le contact dans Brevo.
C'est un champ de plus. Mais cela transforme "on a eu quelques inscriptions" en "le quiz convertit, le pied de page non, écrivons davantage comme le quiz." L'instrumentation que vous ajoutez à la construction ne coûte presque rien ; celle que vous essayez d'ajouter plus tard signifie que vous avez déjà perdu les données que vous auriez voulues.
Décision 5 : garder les calculs honnêtes et séparés
Le calculateur de ROI aurait pu être une boîte noire qui crache un chiffre impressionnant. À la place, le calcul vit dans une petite fonction pure — pas d'UI, pas de framework — et il est délibérément prudent : il tient compte des semaines de travail, plafonne la part d'une tâche que l'IA peut raisonnablement reprendre, et déduit un coût approximatif de construction et de fonctionnement. Il dit même, sur la page, "à titre indicatif, pas un devis."
Deux raisons. D'abord, un chiffre que vous pouvez défendre vaut plus qu'un chiffre simplement grand. Ensuite, la logique pure est testable et facile à modifier — quand je veux ajuster les hypothèses, je touche un seul fichier, pas un enchevêtrement de code de composant. Séparer le "ce qu'il calcule" du "à quoi il ressemble" est une de ces habitudes qui paie à chaque fois.
Ce que je reverrais
Quelques notes honnêtes. Le parcours de capture ajoute actuellement le contact directement ; pour une posture RGPD plus stricte, je déplacerais probablement la newsletter vers un double opt-in (e-mail de confirmation) avant le lancement — Brevo le prend en charge, c'est un petit changement, et pour un public de l'UE c'est la valeur par défaut la plus propre. Et l'état du quiz vit uniquement dans le navigateur ; si je voulais envoyer aux gens le détail complet de leur résultat, je transmettrais les réponses à l'e-mail transactionnel. Les deux sont des choix délibérés "plus tard, si ça mérite sa place", pas des choses que j'ai oubliées.
Pourquoi je vous montre ceci
Parce que l'écart que WDC comble est exactement celui-ci : beaucoup de gens vous conseilleront sur l'IA et les projets numériques, mais bien moins s'assiéront pour construire la chose correctement — avec les identifiants gérés comme il faut, les modes de défaillance réfléchis, et les données instrumentées pour que vous appreniez réellement quelque chose.
Aucune des décisions ci-dessus n'est tape-à-l'œil. C'est justement le point. La bonne ingénierie pour une vraie entreprise est surtout une série de petits choix ennuyeux et corrects qui s'additionnent en quelque chose en quoi vous pouvez avoir confiance et que vous pouvez modifier plus tard sans crainte.
J'écris ces journaux de build et une newsletter courte et pratique pour les entreprises belges — de la vraie ingénierie, le règlement IA européen, et l'intégration de l'IA, en langage clair. Abonnez-vous ci-dessous si vous voulez le prochain.
Et si vous avez un projet que vous préféreriez voir construit correctement du premier coup plutôt que conseillé sans fin, c'est ce que fait WDC — commencez par une conversation.