MiniGun de Ran Aroussi : la vraie innovation, c'est le skill qui apprend au modèle quand dire non

L’écosystème agent-ready compte désormais des dizaines de produits qui se présentent ainsi “on ship un serveur MCP, c’est utilisable depuis Claude”. La plupart s’arrêtent là, ils exposent un set d’outils, laissent à l’agent le soin de les composer correctement, et appellent ça de l’intégration. MiniGun, l’envoyeur d’emails open-source que Ran Aroussi vient de publier, fait quelque chose que je n’avais vu nulle part ailleurs : il ship aussi le skill, c’est-à-dire la couche au-dessus qui apprend à l’agent dans quel ordre utiliser quels outils, quand passer en mode test d’abord, et, c’est la partie qui mérite d’être écrite, quand refuser. C’est cette discipline qui distingue “agent-ready” comme étiquette marketing de “agent-ready” comme propriété opérationnelle.

J’ai pris le temps de tester la chose et de lire le repo. Voici ce qui s’y passe, et la leçon de design que ça contient pour tout devtool qui veut être conduit par un agent.

Ce que MiniGun fait, et n’est pas

D’abord, le projet en deux phrases pour ceux qui découvrent. MiniGun est un envoyeur d’emails self-hosted qui tourne sur Cloudflare Workers + D1, par-dessus Mailgun pour la livraison. Il expose un CLI Go, un serveur MCP, et quatre SDKs single-file (TypeScript, PHP, Python, Go). Tout est sous licence MIT. La facture marginale est celle de Mailgun, sans markup.

Ce que ce n’est pas : un Mailchimp open-source. MiniGun ne ship pas d’éditeur WYSIWYG, pas de dashboard d’analyse, pas de templates “glissez-déposez”. Vous écrivez vos emails en Markdown, vous les commitez dans un git, vous les pipez dans minigun send. C’est une infrastructure, pas un produit consommateur. Le public cible est très précis : développeurs et indie-makers qui préfèrent un terminal à un dashboard, et qui veulent qu’un agent puisse conduire la chose sans qu’on ouvre un navigateur.

Ran Aroussi le pose lui-même clairement dans le repo : “if you’re not in a SaaS dashboard by choice, MiniGun is for you”. C’est une déclaration de cible, et c’est honnête.

La vraie innovation : un skill qui enseigne le jugement

C’est le détail qu’il faut isoler. Le repo contient un fichier skill/minigun/SKILL.md, 240 lignes qui forment un playbook opérateur. Pas un fichier de doc, pas un fichier d’aide. Un playbook qui enseigne au modèle le savoir d’un ingénieur email-ops expérimenté.

Le contenu de ce skill couvre des choses qu’aucune doc d’API ne mentionne :

Le mode test obligatoire sur tout nouveau template avant un send réel.
Une matrice de dispatch : quand utiliser send_single (transactional) versus send_bulk (campagne), se tromper casse les en-têtes List-Unsubscribe et la conformité Gmail bulk-sender.
Un calendrier de warming d’IP : combien d’emails envoyer le jour 1, jour 2, jour 7 sur une IP froide.
Une timeline de graduation DMARC : quand passer de none à quarantine à reject.
Une table d’anti-patterns sur lesquels l’agent est explicitement entraîné à pousser back.

L’effet pratique vaut la peine d’être décrit. Vous donnez à un agent, Claude Code ou Cursor ou n’importe quel client MCP, une instruction de haut niveau : “Envoie la mise à jour d’août à la liste newsletter en utilisant ./drafts/aug.md. Test mode d’abord.” L’agent vérifie que le worker répond, cherche la liste, lit le Markdown, vérifie l’adresse expéditrice, lance le test send, poll jusqu’à terminaison, demande confirmation, puis seulement lance le vrai send. Cette chorégraphie n’est pas dans le serveur MCP ; elle est dans le skill. Sans le skill, l’agent compose maladroitement les appels, saute le test, et envoie une campagne avec un from mal configuré.

C’est exactement le pattern dont j’écrivais à propos des skills qu’un agent va vraiment utiliser : un skill utile est un playbook positif qui montre le bon réflexe, pas une liste d’interdits. MiniGun en est l’instanciation la plus aboutie que j’aie vue dans un projet open-source.

Pourquoi cette séparation outils / skill compte

C’est le point que les “agent-ready” superficiels manquent.

Un serveur MCP qui expose dix outils donne à l’agent dix verbes, sans grammaire. Il sait que list_create, contact_add, et send_bulk existent, mais il ne sait pas qu’on commence toujours par un test send sur une nouvelle template, ni qu’envoyer en bulk sans warming d’IP sur une IP fraîche garantit le placement spam. Ces règles ne sont pas dans la signature des outils, elles sont dans la tête de l’opérateur. Si elles ne sont pas dans le skill, elles sont nulle part.

Le résultat, dans l’écosystème actuel : la majorité des serveurs MCP existants se traduisent en agents capables mais désorientés. Ils peuvent appeler n’importe quelle fonction du système, mais ils n’ont pas la grammaire d’usage. MiniGun ship les deux couches dans le même repo, et le skill évolue avec le code, ce qui réduit le risque de dérive doc/réalité qu’on voit partout ailleurs.

La leçon de design est généralisable : un devtool agent-ready, en 2026, ne se limite plus à “voici les endpoints”. Il livre aussi “voici dans quel ordre et avec quelles précautions”. C’est la même séparation conceptuelle que le réflexe de revue cross-session : les outils sont une chose, le jugement sur leur usage en est une autre, et ils méritent d’être codés séparément.

L’architecture Cloudflare-sans-queue, pour qui aime les détails

L’autre angle où MiniGun mérite qu’on l’examine est purement architectural. Le défi technique : faire des bulk sends à plusieurs dizaines de milliers de destinataires sur des Cloudflare Workers, qui n’ont pas de processus long-running, pas de queue managée, pas de Redis disponible.

La solution choisie est élégante : une chaîne d’appels HTTP auto-invoquants. Chaque worker traite un batch, déclare le suivant via ctx.waitUntil(), et meurt. Un claim atomique sur D1 (la base SQLite-edge de Cloudflare) empêche deux workers de prendre le même batch si une race se produit. Un cron balaie périodiquement les chaînes qui se sont tues, ce qui rend le système crash-safe sans monitoring externe.

Le résultat documenté : un envoi à 23 000 destinataires tourne sur le tier gratuit de Cloudflare. Pas de Redis, pas de SQS, pas de processus à monitorer. Pour qui ship des side-projects et trouve l’infrastructure email habituellement disproportionnée pour leur volume, c’est exactement le bon ordre de magnitude.

Ce qui me plaît dans cette approche, c’est qu’elle assume sa contrainte (workers stateless) et en fait un avantage (zéro infra à maintenir). C’est l’antithèse exacte des architectures “on a besoin d’un Redis pour faire du bulk” qu’on copie sans interroger leur prémisse.

La portabilité comme principe : des tokens HMAC qui survivent

Un détail qui mérite d’être nommé parce qu’il révèle une philosophie. Chaque lien d’unsubscribe par destinataire est un token HMAC stateless. Pas de lookup en base pour vérifier. Vérifiable par n’importe quelle instance de worker dans n’importe quelle région.

L’implication, qu’Aroussi explicite : “when (if) you ever migrate away from MiniGun, you keep the tokens. The HMAC scheme is documented, the secret is yours, and you can reimplement the verifier in a hundred lines. Your subscribers’ unsub links outlive any infrastructure decision you make.”

C’est le contraire de ce que font les SaaS newsletter. Quand vous quittez votre fournisseur SaaS, les liens d’unsubscribe générés à l’époque cessent de fonctionner. Les destinataires qui cliquent reçoivent une 404, ou pire, sont silencieusement re-inscrits si vous remontez la liste ailleurs. La portabilité des liens d’unsubscribe n’est pas un raffinement esthétique, c’est une obligation de conformité (RFC 8058, CAN-SPAM, RGPD), et c’est ce que MiniGun préserve par construction.

C’est le même principe que pour le moindre privilège qu’on accorde aux secrets : le système est conçu pour qu’on puisse le quitter sans casser ce qui est public. Vos engagements envers vos abonnés ne sont pas hostages de votre stack.

Ce que cette release dit du devtool agent-ready en 2026

Pour synthétiser. MiniGun n’est pas une révolution de l’email, c’est un cas d’école pour ce que veut dire shipper un devtool destiné à être conduit par des agents en 2026.

Première leçon. Un MCP server seul n’est pas un produit. C’est une surface technique. La couche qui rend l’agent utile, c’est le skill, et le skill doit vivre dans le même repo que les outils qu’il appelle. Si vous concevez un produit “agent-ready” aujourd’hui et que votre skill est dans une doc séparée, vous shippez la moitié de ce qu’il faut.

Deuxième leçon. Le skill doit enseigner le refus. Un agent capable est un agent qui sait dire “je ne vais pas faire ça parce que ce n’est pas le bon moment”. C’est précisément le geste qu’aucun set d’outils ne lui donne par défaut, il faut le coder explicitement.

Troisième leçon. Les contraintes d’environnement (Cloudflare Workers sans long-running) sont des opportunités si on accepte de redessiner. La chaîne d’auto-invocations sur Worker + D1 n’est pas un fallback inférieur à une queue Redis ; c’est une architecture à part entière, plus simple, qui marche.

Quatrième leçon. La portabilité par construction (tokens HMAC documentés) est ce qui distingue une infrastructure que vous possédez d’un service que vous louez. Pour qui a vu un fournisseur SaaS doubler ses prix ou disparaître, c’est l’investissement qui se rentabilise.

Pour qui s’intéresse à ce que devient l’infrastructure agentique au-delà des slogans, le SKILL.md de MiniGun est une lecture utile même si vous n’envoyez jamais un email. C’est un template de ce à quoi ressemble un deep operator skill, pas seulement des outils, mais du jugement.

Si cela vous a parlé, vous aimerez Écrire des skills que votre agent de code utilisera vraiment et La boucle d’agent qui a remplacé mon samedi. Abonnez-vous ci-dessous pour recevoir le billet de vendredi prochain.