Dev Log : MCP, suivi des e-mails et structure des menus

J'ai passé la journée à construire des serveurs MCP, un suivi automatisé des e-mails et des menus d'administration évolutifs.

Voici les principales leçons tirées de ce travail.

Sécurité des serveurs MCP

J'ai livré une boîte à outils MCP générique et déployé des serveurs sur plusieurs applications d'entreprise. Lorsque vous construisez des agents capables d'interagir avec vos systèmes, suivez ces règles :

  • Donnez librement des outils de lecture aux agents.
  • Donnez les outils d'écriture avec parcimonie.
  • Forcez chaque action d'écriture à passer par un runbook soumis à une validation humaine.
  • Hachez les mots de passe dans vos outils de création d'utilisateurs. Ne stockez jamais de texte brut.
  • Utilisez des UUID publics pour les journaux d'audit. Ne divulguez jamais les identifiants internes de la base de données.
  • Utilisez une solution de repli pour le contexte utilisateur. Un agent peut utiliser HTTP ou STDIO. Assurez-vous que votre code gère les deux.

Suivi des e-mails sans travail manuel

J'ai conçu un système qui suit automatiquement l'ouverture et les clics des e-mails. Ne demandez pas aux développeurs d'ajouter des pixels de suivi à chaque e-mail. Utilisez plutôt un écouteur d'envoi de courrier.

  • L'écouteur intercepte le message.
  • Il injecte le pixel de suivi dans le HTML.
  • Il encapsule tous les liens pour le suivi des clics.
  • Il ajoute un hash de métadonnées pour faciliter la corrélation.

Deux notes importantes :

  • Évitez Mail::raw(). Cela contourne le processus de réécriture HTML. Utilisez de véritables Mailables HTML pour garantir le fonctionnement du suivi.
  • Activez le suivi par défaut. Si les utilisateurs doivent l'activer eux-mêmes, ils oublieront de le faire.

Menus d'administration évolutifs

Lorsque vous gérez des menus sur plusieurs applications, n'utilisez pas un seul fichier géant. Utilisez de petites classes de construction pour chaque groupe.

  • Créez une classe par groupe (ex : Paramètres, Gestion des utilisateurs).
  • Chaque classe déclare ses propres éléments et les permissions requises.
  • Cela permet de garder une navigation déclarative.
  • Tronquez les libellés longs à l'intérieur du composant, et non pour chaque élément individuellement.
  • Verrouillez l'accès aux outils via deux vérifications : les permissions de l'utilisateur et l'édition spécifique de l'application.

La vision d'ensemble

L'objectif est de rendre le filet de sécurité automatique.

Si un outil de diagnostic est utile, activez-le par défaut. Si vous devez vous souvenir de l'activer, vous ne l'aurez pas lorsqu'un système tombera en panne à 2 heures du matin. Encodez vos leçons directement dans vos outils pour ne pas avoir à les réapprendre.

Source : https://dev.to/nasrulhazim/dev-log-2026-06-19-mcp-