Agents IA marketing : comment fonctionne fog, le stack open source créé par swanbase
Un founder qui cherche ses cent premiers utilisateurs ne devrait pas embaucher. Il devrait pouvoir lancer cinq agents marketing depuis son terminal, lire le résultat dix minutes plus tard, et passer à la prochaine décision. C'est la conviction qui a donné fog.
fog (Founders Growth agents) est le stack open source d'agents IA marketing que swanbase a sorti en 2026 sous license Apache 2.0. Cinq agents, un format de spec partagé (AGENT.md), un toolbelt CLI commun, et la même philosophie partout : un agent fait une seule chose, dans un seul chat, et tu peux le lire en deux minutes. Le pack est portable sur Claude Code, Cursor, Codex CLI et Gemini CLI. Site officiel : fog-agents.com. Playbook technique complet : marketing-agents-playbook.
Ce guide explique ce qu'est devenu un agent IA marketing en 2026 (spoiler : pas un robot, un dossier de markdown), pourquoi le format vertical bat le mega-agent, et comment fog structure chacun des cinq agents qu'on ouvre aujourd'hui à la communauté founder.
Pourquoi on a créé fog (founders, pas marketers)
Le marché des agents IA marketing en 2026 ressemble à ça : des SaaS fermés qui te vendent des "agents prêts à l'emploi" à 200 euros par mois, des agences qui te facturent 5 000 euros pour brancher trois prompts dans un Notion, et quelques frameworks open source pensés pour des ingénieurs IA, pas pour des founders qui veulent juste avancer.
Aucun de ces outils n'a été pensé pour le pattern réel d'un founder early-stage. Le vrai pattern, c'est : "j'ai besoin maintenant de comprendre ce que les utilisateurs disent vraiment de mon segment, je veux lancer cette analyse en deux minutes et lire le résultat avant ma prochaine réunion". Pas "je veux configurer un workflow Zapier pour publier trois posts par semaine".
On a écrit fog parce qu'on voulait, pour swanbase, un stack qui répond exactement à ce pattern. Cinq agents qui couvrent les bottlenecks d'un founder en phase 0 à 1000 utilisateurs. Open source pour que les autres founders puissent les forker, et pour que la spec AGENT.md devienne un standard que personne ne possède.
C'est quoi un agent IA marketing en 2026 (déf opérationnelle)
Forget la science-fiction
Un agent IA marketing en 2026, ce n'est pas un robot. Ce n'est pas un service cloud propriétaire. Ce n'est pas un ChatGPT déguisé.
C'est un dossier de fichiers markdown.
Un dossier de markdown lu par ton harness
Concrètement, quand tu installes un agent fog sur ta machine, tu te retrouves avec une structure comme celle-ci :
agents/
└── market-signal/
├── AGENT.md ← spec lisible humaine + machine
├── README.md ← prérequis, install
├── config.example.json ← template de config
└── assets/
└── output-template.md ← squelette du livrable
Tu pointes ton harness IA (Claude Code, Cursor, Codex CLI ou Gemini CLI) sur le dossier et tu écris en langage naturel :
"Run the market-signal agent at agents/market-signal/.
Market: outils de facturation freelance pour designers."
Le harness lit l'AGENT.md, te demande les inputs manquants en chat, exécute le workflow étape par étape (commandes shell, appels CLI, raisonnement LLM), et écrit le livrable dans le dossier de ton projet. Pas de daemon. Pas de SDK. Pas de runtime à babysitter.
L'agent est portable parce que c'est juste du texte. Pas de vendor lock-in. Tu lances le même AGENT.md sur Claude Code aujourd'hui et sur Cursor demain, sans toucher une ligne.
Différence agent vs chatbot vs prompt vs skill
Quatre concepts souvent confondus, quatre fonctions différentes :
| Concept | Forme | Output | Quand l'utiliser |
|---|---|---|---|
| Prompt | Une phrase | Variable | Question one-shot, réponse instantanée |
| Chatbot | Conversation libre | Variable | Brainstorming, exploration |
| Agent | Workflow structuré (AGENT.md) | Format prévisible, à chaque fois | Tâche répétée avec livrable formaté |
| Skill | Sous-tâche réutilisable (SKILL.md) | Bloc partagé entre agents | Quand 3 agents partagent le même bout de code |
Un agent marketing est ce qui te permet de te dire "je veux ce livrable, dans cette forme, à chaque fois" et d'avoir la garantie de l'obtenir, peu importe qui lance la commande, peu importe le harness, peu importe la météo.
L'anatomie d'un AGENT.md (les 6 parties)
Tout AGENT.md bien construit a six parties. Le format n'a pas été inventé pour fog, il s'est cristallisé naturellement à force de construire des dizaines d'agents internes chez swanbase avant d'open-sourcer la stack.
1. Frontmatter
---
name: market-signal
description: Reads what real users say about a market before you write copy
compatibility: claude-code, cursor, codex, gemini
---
Header machine-readable. Permet à un harness de pré-charger l'agent sans lire le fichier entier. Trois champs suffisent.
2. When to run
Une à trois phrases qu'un founder peut lire en cinq secondes. Avant la validation. Quand le trafic chute. Avant de payer du paid. Chaque ligne est un trigger concret, pas une théorie.
3. Inputs needed
Une table d'inputs requis vs optionnels avec des défauts. L'agent doit refuser de démarrer si un input requis manque. La majorité des défaillances qu'on a vues en wild venaient d'inputs sautés.
| Input | Required | Default | Example |
|---|---|---|---|
| market | yes | — | "freelance invoicing tools for designers" |
| language | no | en | fr |
| depth | no | standard | quick / standard / deep |
4. Workflow
Étapes numérotées. Chaque étape fait ≤ 6 lignes. Chaque étape utilise du shell, un CLI du toolbelt, ou du raisonnement LLM. Pas de magie, pas de fonction opaque.
5. Output
Un squelette markdown, ou un lien vers un template dans assets/. L'agent doit produire cette forme exacte à chaque exécution. La prévisibilité de l'output est ce qui rend le livrable fiable.
6. Failure modes
Quoi faire quand un CLI manque, quand une API ne renvoie rien, quand une étape time-out. Le fallback est explicite. Une dégradation silencieuse est la façon la plus efficace de tuer la confiance dans un agent.
Pourquoi six parties ? La prévisibilité est une feature. Un founder qui n'a jamais vu le stack doit pouvoir scanner n'importe quel AGENT.md en trente secondes et savoir ce qu'il fait, ce qu'il lui faut, ce qui sort. Si tu ne peux pas, l'agent n'est pas terminé.
Vertical agents vs mega-agent (le vrai débat)
Tout le monde parle de skills. Le pattern dominant est un mega-AGENT.md avec cinquante skills bolted-on, tous les helpers, tous les personae, tous les wrappers CLI bourrés dans le même contexte. On pense que c'est faux.
Notre thèse est l'opposé. Chaque agent fog est un dossier vertical, petit, qui fait une seule chose, ouvert dans son propre chat, avec uniquement le contexte dont ce job a besoin. L'agent est assez petit pour être lu en une session, assez focalisé pour que le modèle ne dérive pas, et assez self-contained pour que tu puisses changer de harness sans rebrancher.
La règle. Si deux agents partagent du travail, c'est un candidat pour un skill. Si un agent dépasse quelques centaines de lignes d'AGENT.md, c'est deux agents. Résiste à la gravité naturelle vers le mega-agent. Les agents verticaux restent tranchants. Les agents bloated se perdent dans leur propre contexte.
Voir comparatif Claude Code vs Cursor pour comprendre pourquoi le harness influence la profondeur de contexte gérable.
Les 5 agents du stack fog
Voici les cinq agents qui composent fog aujourd'hui. Chacun résout un bottleneck founder concret. Tu les lances on-demand, au moment où le bottleneck apparaît dans ton parcours.
market-signal
Quand le lancer. Avant d'écrire la moindre ligne de copy ou de code. Lit ce que les vrais utilisateurs disent dans Reddit, X, forums de niche, Hacker News à propos de ton marché cible.
Inputs. market (requis : "freelance invoicing tools for designers"), language (défaut en), geography (défaut global), depth (quick · standard · deep).
Output. Rapport markdown avec breakdown sentiment, top issues par nombre de mentions, profil psychographique, 15 à 20 verbatim quotes sourcées, et trois recommandations actionnables.
Convicction sous-jacente. Don't guess what users feel. Read what they wrote.
first-users
Quand le lancer. Quand tu cherches tes 10 à 50 premiers utilisateurs et que tu ne sais pas où ils traînent.
Inputs. product (requis), target_user (requis), geography (optionnel).
Output. Carte des canaux pertinents (subreddits, communautés Slack/Discord, threads X, forums spécialisés, événements) avec templates de premier message adaptés à chaque canal. CLIs utilisés : exa-cli, firecrawl-cli.
seo-audit
Quand le lancer. Quand le trafic chute. Snapshot SEO en one-shot. Combine les données Google Search Console + un crawl SERP live + une priorisation des fixes.
Inputs. domain (requis), gsc_property (requis), language (défaut en), time_range (défaut 90j).
Output. Liste des pages qui perdent du trafic, les keywords concernés, l'état SERP actuel, et la liste de fixes priorisés (impact × effort). CLIs utilisés : gsc, firecrawl-cli.
landing-page-analyzer
Quand le lancer. Avant de dépenser du paid. Ou après le launch quand la conversion stagne. Audit CRO heuristique contre le framework LEVER (Legibility · Enticement · Value clarity · Evidence · Resistance).
Inputs. url (requis), goal (requis : "book a demo"), target_user (requis : "B2B sales ops leads"), context (optionnel), language (défaut en).
Output. Scorecard LEVER, résultat du 10-second test, 30+ findings heuristiques taggés pass/issue/critical, top 5 fixes ship-this-week classés par impact × ease, trois headlines réécrites, et 3 à 5 hypothèses A/B test.
Conviction sous-jacente. Don't pay for traffic into a leaky bucket.
cold-outreach-builder
Quand le lancer. Quand tu es prêt à passer à l'outbound ciblé. Construit une séquence de 4 à 6 messages avec personnalisation par prospect. Cialdini-grounded.
Inputs. target_audience (requis), value_prop (requis), prospect_list (CSV), tone.
Output. Séquence email complète prête à charger dans Instantly, avec hooks personnalisés par prospect, justification psychologique pour chaque levier de persuasion utilisé, et plan de suivi. CLIs utilisés : exa-cli, firecrawl-cli, instantly-cli.
Plus l'agent template _template-agent que tu peux forker pour construire le tien.
→ Lire The Marketing Agents Playbook sur fog-agents.com/marketing-agents-playbook (la version longue, avec exemples ligne à ligne).
Le toolbelt cli-skills (la vraie infra)
Les agents marketing ont besoin de faire des choses : chercher sur le web, scraper des pages, requêter Google Search Console, pousser des campagnes outreach. La méthode naïve consiste à coder ces appels dans chaque agent. C'est exactement ce qu'il ne faut pas faire.
À la place, fog installe un toolbelt partagé de CLIs et chaque agent y accède via un simple shell-out. Le toolbelt public est cli-skills :
# Installation one-shot, réutilisable par tous les agents fog
git clone https://github.com/the20100/cli-skills.git ~/cli-skills
# Ajout au PATH
export PATH="$HOME/cli-skills/exa-cli/bin:$PATH"
export PATH="$HOME/cli-skills/firecrawl-cli/bin:$PATH"
# Clés API requises par chaque CLI
export EXA_API_KEY="..."
export FIRECRAWL_API_KEY="..."
market-signal peut maintenant shell-out vers exa-cli search … sans bundler le SDK. seo-audit peut appeler gsc query …. cold-outreach-builder peut piper vers instantly-cli push …. Trois agents, un toolbelt, zéro code dupliqué.
C'est le même pattern que le fichier /usr/local/bin sur Unix : tu installes une fois, tout le système l'utilise. Pas de SDK propriétaire dans chaque agent. Pas de duplication. Pas de dérive de version entre agents.
À la sortie du toolbelt, les agents fog écrivent leurs résultats sous forme de fichiers texte dans le dossier de ton projet. Tu commits, tu diffs, tu repasses dessus dans un mois. Pas de UI propriétaire, pas de plateforme qui retient ta donnée — c'est ce qui change tout par rapport aux SaaS d'agents IA marketing classiques.
Comment créer ton premier agent IA marketing (méthode 4 étapes)
Si tu veux construire ton propre agent (au-delà des cinq de fog), voici la méthode qu'on suit chez swanbase.
Étape 1 : fork le _template-agent
Le template est inclus dans le repo fog. Il définit le contrat que chaque agent doit satisfaire : skeleton AGENT.md, README avec prérequis, config.example.json, assets/output-template.md, et references/ pour les docs API. Pas runnable, juste un squelette à copier.
cp -r agents/_template-agent agents/mon-nouvel-agent
cd agents/mon-nouvel-agent
Quand tu construis ton quatrième agent marketing, tu apprécieras que les trois premiers se ressemblent.
Étape 2 : remplis les six parties d'AGENT.md
Frontmatter, when-to-run, inputs, workflow, output, failure modes. Si tu butes sur l'une des six, lis le marketing agents playbook qui détaille chaque partie avec exemples.
Étape 3 : teste sur les quatre harnesses
Lance le même AGENT.md sur Claude Code, Cursor, Codex CLI et Gemini CLI. Si un harness échoue, c'est qu'une règle de portabilité est cassée (voir section suivante). Corrige et relance.
Étape 4 : itère sur l'output
L'output est ce qui rend l'agent fiable ou non. Lance l'agent dix fois sur des cas variés. Compare les outputs entre eux. Si la forme dérive, ton template d'output est trop flou et il faut serrer la spec. Si la forme tient mais le contenu est faible, c'est ton workflow qui est sous-spécifié.
Le cycle itératif typique : 30 minutes d'écriture, 30 minutes de test sur 5 cas, 30 minutes de patch. Trois heures pour un agent de production. À comparer avec les semaines qu'il fallait pour mettre un agent IA en prod il y a un an, voir Claude Managed Agents : guide complet.
Les 3 règles de portabilité (claude code agents marketing)
Un agent marketing est portable quand il marche identiquement sur Claude Code, Cursor, Codex CLI et Gemini CLI. Cette portabilité est fragile. Trois règles la maintiennent intacte.
Règle 1 : aucun appel à une fonction propriétaire d'un harness
Pas de mcp__*, pas de claude-*, pas de fonction qui n'existe que dans un harness. Tout ce que tu ne peux pas exprimer en bash + cli-skills n'a pas sa place dans l'agent.
C'est exactement pour ça que les claude code agents marketing propriétaires (qui dépendent d'un MCP server Anthropic, par exemple) ne fonctionnent que sur Claude Code et nulle part ailleurs. Un vrai agent IA marketing portable doit s'écrire au plus petit dénominateur commun : shell + CLI.
Règle 2 : aucun chemin absolu codé en dur
L'agent travaille toujours depuis la racine du projet utilisateur, qu'il reçoit en input. Il ne sait pas où il vit sur le disque. Pas de /Users/<toi>/Documents/.... Pas de /home/founder/agents/.... Toujours du chemin relatif au project root.
Règle 3 : l'output sort du dossier de l'agent
Les livrables s'écrivent dans <project>/<agent-name>/<label>-<YYYYMMDD>.md. Le dossier de l'agent reste propre et pull-able. Tu peux mettre à jour l'agent sans risquer d'écraser tes livrables.
Trois règles, trois lignes de doctrine. Si elles sont respectées, ton agent tourne pareil sur tous les harnesses. Sinon, tu te lock à un harness et tu casses la promesse de fog.
Les 2 non-négociables qu'on défend
Sous chaque agent du stack, deux convictions plus simples à écrire qu'à incarner.
"Don't guess what users feel. Read what they wrote."
Tue l'envie d'inventer la douleur utilisateur depuis un whiteboard. C'est l'agent market-signal qui matérialise ce principe en lecture systématique de Reddit, X, forums et HN avant la moindre ligne de copy.
"Don't pay for traffic into a leaky bucket."
Tue l'envie de lancer du paid avant que la page le mérite. C'est l'agent landing-page-analyzer qui matérialise ce principe en audit LEVER systématique avant chaque dépense pub.
Construis des agents qui forcent ces deux disciplines, et ton stack fait la majorité du job d'un junior marketer, on-demand, pour le coût d'un appel API. C'est le sens du pari fog. Pour le contexte plus large sur le growth marketing en startup, voir growth marketing pour startups.
fog vs les alternatives (agence, SaaS, DIY)
Comparaison rapide des quatre approches accessibles à un founder qui veut résoudre ses bottlenecks marketing.
| Critère | Agence freelance | SaaS agents marketing | DIY (depuis zéro) | fog |
|---|---|---|---|---|
| Coût mensuel | 2-5K € | 100-500 € | Temps founder | API costs (~50-100 €) |
| Délai au premier livrable | 2-4 semaines | 1 jour | 2-3 semaines | 30 minutes |
| Audit possible | Non | Non (boîte noire) | Oui | Oui (markdown lisible) |
| Modifiable | Non | Limité | Oui | Oui (fork direct) |
| Portable entre harnesses | N/A | Non | Selon implémentation | Oui (par design) |
| License | Contrat | Subscription | Tu possèdes | Apache 2.0 |
| Adapté à un founder en phase 0-1000 users | Surdimensionné | Trop générique | Trop coûteux en temps | Conçu pour ça |
Pour les outils que les founders utilisent quotidiennement chez swanbase au-delà de fog, voir outils gratuits founders et Claude Code vs Cursor.
Comment commencer maintenant
fog est sur fog-agents.com. License Apache 2.0, gratuit, modifiable. Tu peux :
- Lire le marketing agents playbook : la version longue de cet article, avec des exemples concrets sur l'anatomie d'un AGENT.md, le pattern toolbelt, et trois agents détaillés ligne à ligne.
- Installer le toolbelt cli-skills : la couche infra partagée par tous les agents. Quinze minutes de setup.
- Lancer ton premier agent :
market-signalest le plus simple. Choisis un marché que tu connais, lance-le sur Claude Code, lis le rapport. Trente minutes du clone à la première décision.
Si tu construis un agent marketing qui pourrait rejoindre la stack publique, écris-nous. fog grandit au rythme où les bottlenecks founders apparaissent.
FAQ
Qu'est-ce qu'un agent IA marketing concrètement ? Un agent IA marketing en 2026, c'est un dossier de fichiers markdown (AGENT.md, README, config) qu'un harness IA comme Claude Code, Cursor, Codex CLI ou Gemini CLI peut lire et exécuter. Ce dossier décrit en langage clair les inputs requis, le workflow à suivre étape par étape, le format de l'output attendu, et les modes de défaillance. Le harness lit l'AGENT.md, exécute les commandes shell ou les appels CLI listés dans le workflow, et écrit le livrable dans le dossier projet du founder. Il n'y a pas de daemon à faire tourner, pas de SDK propriétaire, pas de runtime à maintenir.
Quelle est la différence entre un agent, un chatbot et un prompt ? Un prompt est une instruction one-shot envoyée au modèle. Un chatbot est une conversation libre où le modèle répond aux messages sans plan préétabli. Un agent suit un workflow structuré, décrit dans un AGENT.md, avec des inputs typés, des étapes ordonnées, et un livrable au format prévisible. La différence clé : l'agent produit la même forme d'output à chaque exécution, peu importe qui le lance. Le chatbot improvise. Le prompt est trop court pour ça.
Faut-il savoir coder pour utiliser fog ? Non. fog est conçu pour être utilisé en langage naturel via un harness IA. Tu ouvres Claude Code, Cursor, Codex CLI ou Gemini CLI, tu pointes l'agent (par exemple : "Run agents/market-signal/ pour le marché des outils de facturation freelance"), et le harness lit l'AGENT.md, te demande les inputs manquants en chat, exécute les commandes, et écrit le livrable. Savoir lire du markdown et installer un CLI suffit. Si tu veux modifier un agent ou en créer un, lire un peu de Bash aide.
Quel est le coût mensuel pour faire tourner fog ? Le code de fog est gratuit (Apache 2.0). Les coûts viennent du harness IA et des CLIs tiers utilisés par le toolbelt cli-skills. Compter une subscription Claude Pro ou un accès API Anthropic pour Claude Code (20 dollars par mois en pro, ou facturation à l'usage), plus les CLIs optionnels selon les agents que tu lances : Exa (recherche web sémantique), Firecrawl (scraping), Perplexity (search Q&A), Instantly (cold email). Un founder qui lance market-signal et landing-page-analyzer une fois par semaine s'en sort à moins de 100 dollars par mois, infrastructure comprise.
Quels harnesses IA sont supportés par fog ? fog est portable par design. Les agents tournent sur Claude Code (Anthropic), Cursor, Codex CLI (OpenAI) et Gemini CLI (Google). La portabilité est garantie par trois règles strictes : aucun appel à une fonction propriétaire d'un harness, aucun chemin absolu codé en dur, et tous les outputs s'écrivent en dehors du dossier de l'agent. Tu peux lancer le même AGENT.md sur Claude Code aujourd'hui et sur Cursor demain sans changer une ligne.
Combien de temps pour intégrer fog dans son flow ? Trente minutes pour le premier setup : cloner le repo cli-skills, exporter trois clés API (Exa, Firecrawl, Serper), pointer le harness sur le dossier de l'agent et lancer une première commande. À partir de là, chaque agent supplémentaire prend dix secondes (point and run). La courbe d'adoption typique : un agent par jour pendant la première semaine, puis intégration dans le rythme de décision (avant validation, avant trafic payant, après lancement, etc.).
Pourquoi fog est en Apache 2.0 et pas en license commerciale ? Trois raisons. D'abord, un agent qui prend la décision marketing d'un founder doit pouvoir être lu, audité et modifié. Une license fermée bloque cette transparence. Ensuite, le format AGENT.md ne devient un standard que si tout le monde peut s'en servir, l'étendre et le forker sans demander l'autorisation. Apache 2.0 autorise l'usage commercial, le fork, la dérivation, sous réserve de garder l'attribution. Enfin, on construit fog pour notre propre usage chez swanbase d'abord. L'open source est un effet de bord vertueux, pas un produit à vendre.
Est-ce que fog remplace une agence marketing ? Pour un founder en phase 0 à 1000 utilisateurs, oui. Les cinq agents couvrent les bottlenecks récurrents de cette phase. Au-delà, quand il faut piloter une équipe content, gérer du paid à six chiffres ou orchestrer un calendrier éditorial annuel, l'agence reste pertinente. fog ne remplace pas un CMO senior. Il remplace l'agence freelance que tu allais payer 3K par mois pour faire ce que tu aurais pu lancer toi-même en quinze minutes.
fog est créé et maintenu par swanbase, l'accélérateur de startups basé à Paris. Nos retours d'usage sur les agents IA viennent de notre propre stack interne et des programmes que nous accompagnons. Pour creuser les concepts liés, voir aussi alternatives open source aux agents IA et Claude Code, c'est quoi.
