Plutôt que des tables imbriquées et du CSS inline, utilisons MJML*.

ManoMano a fait ce choix pour générer des e-mails responsive. Le contexte : un projet de modernisation du système assurant l’envoi de ces messages.

Auparavant, il y avait un monolithe en PHP. Désormais, il y a une plate-forme Node.js/Kotlin.

L’ancien service était basé sur des bibliothèques obsolètes, d’autant plus difficiles à mettre à jour que l’expertise PHP s’était progressivement perdue en interne. Il était par ailleurs étroitement lié à des services tels que RabbitMQ, donc impossible à maintenir de manière indépendante. Des années de correctifs avaient plus globalement alourdi la codebase, compliquant les changements et les rendant plus risqués. L’écriture des templates en Twig et en HTML brut posait de plus des problèmes de compatibilité en fonction des clients de messagerie.

Une approche configuration over code

Le service d’origine était déclenché par des appels API ou par des événements RabbitMQ. Avant d’envoyer un e-mail, il fallait l’enrichir en récupérant des éléments sur plusieurs services externes. Des dépendances qui tendaient à fragiliser l’ensemble.

Pour favoriser le décommisionnement, ManoMano a isolé cette logique en un composant email-merger. Ses requêtes sont centralisées sur la nouvelle plate-forme au côté des requêtes « modernes » – qui ne passent plus par le monolithe – par un service Kotlin (email-sender). Celui-ci suit une approche configuration over code : toute la configuration est gérée via le back-end central, sans avoir à écrire de code.

La passerelle réceptionnant les requêtes s’appuie sur PostgreSQL pour le stockage d’état et de configuration. Elle transmet les événements à un nœud de travail qui récupère un template et fait la liaison avec le service SMTP. Le bus de messagerie RabbitMQ a été remplacé par du Kafka, pour l’élasticité, la résilience et le retry intégré.

Une séparation plus claire des responsabilités

Le fournisseur de templates (email-templates) est écrit en Node.js. Il évite aux développeurs front-end d’avoir à évoluer dans un environnement PHP. La bibliothèque react-mjml leur permet de créer des templates comme ils créent des composants React.

Épargner aux développeurs React le travail en environnement PHP a déchargé l’équipe back-end de nombre de requêtes. Dans le même temps, la centralisation des templates assure une plus grande cohérence des e-mails. Et les responsabilités sont plus claires : le back n’est plus impliqué dans les changements visuels, le front ne l’est plus dans la logique de delivery.

Mi-novembre 2025, ManoMano avait migré environ 80 % de son trafic mail sur la nouvele plate-forme. Dont ses communications les plus critiques (confirmations de commandes, notifications d’envois, réinitialisations de mots de passe).

* Mailjet Markup Language, publié en source ouverte (licence MIT) en 2016 par Mailjet. Ce langage déclaratif est transpilé en HTML responsive.

Illustration générée par IA

The post Comment ManoMano a modernisé son système d’envoi d’e-mails appeared first on Silicon.fr.

Le déploiement instantané, c’est pratique, mais rarement indispensable.

Cloudflare contextualise ainsi sa décision d’appliquer aux changements de configuration le même processus de contrôle que pour le code.

Lors de mises à jour logicielles, chaque version binaire a plusieurs étapes de validation à franchir. Toute équipe possédant un service doit définir un plan de déploiement, des indicateurs de réussite/échec et les actions à entreprendre en cas de problème. Un système automatisé exécute ce plan et déclenche si nécessaire une restauration, en alertant éventuellement l’équipe.

Ce mécanisme sera également appliqué aux changements de configuration d’ici à fin mars sur toute la prod, nous promet-on.

En toile de fond, les deux pannes importantes survenues le 18 novembre et le 5 décembre 2025. L’un et l’autre furent déclenchées par un changement de configuration (dans le classificateur de bots pour la première ; dans un outil de sécurité pour la seconde).

Isoler les défaillances

Cloudflare a un autre engagement d’ici à fin mars : réviser les contrats d’interface entre chaque produit et service critique, pour mieux anticiper et isoler les défaillances.

L’incident de novembre est un exemple en la matière. Deux interfaces-clés auraient pu être gérées différemment, estime Cloudflare. D’une part, celle qui lisait le fichier de configuration (il aurait dû exister un ensemble de valeur par défaut validées permettant au trafic de continuer à circuler). De l’autre, celle située entre le logiciel central et le module de gestion des bots (en cas de défaillance de ce dernier, le trafic n’aurait pas dû être bloqué par défaut).

Éliminer – ou contourner – les dépendances circulaires

Cloudflare entend aussi supprimer les dépendances circulaires, ou tout du moins permettre de les « contourner » rapidement en cas d’incident. Exemple : lors de l’incident de novembre, l’indisponibilité de Turnstile (alternative aux CAPTCHA) a empêché les clients d’accéder au tableau de bord à moins qu’ils eussent une session active ou un jeton d’API.

En parallèle, il est question de faire évoluer les procédures internes de type break glass (élévations temporaires de privilèges) pour avoir accès aux bons outils le plus rapidement possible.

Un « code orange » pour la deuxième fois

Pour mettre en place ce plan de résilience, Cloudflare a décrété un « code orange ». Cette procédure permet de réorienter la plupart des ressources techniques vers la résolution d’un incident. Elle a été mise en œuvre une fois par le passé. C’était fin 2023, après une panne de courant dans un des principaux datacenters de Cloudflare (PDX01, dans l’Oregon), hébergeant le plan de contrôle de nombreux services. Le déclencheur : des opérations de maintenance réalisées par l’exploitant du réseau électrique et qui avaient entraîné un défaut de terre dans l’installation.

Illustration générée par IA

The post Cloudflare engage un plan de résilience : les grands axes appeared first on Silicon.fr.