Writ vs Firecrawl.
Firecrawl lit les pages publiques et les transforme en markdown propre. Writ lit et agit : se connecter, remplir, soumettre, acheter, sur votre propre compte, appelable comme API et comme outil MCP.
Choisissez Firecrawl quand il s’agit de lire des pages publiques et de fournir à un LLM du markdown ou du JSON propre : il excelle à cela. Choisissez Writ quand vous devez agir sur un site, pas seulement le lire : vous connecter, remplir des formulaires, soumettre ou acheter sur votre propre compte autorisé, et quand vous voulez que chaque workflow soit appelable comme endpoint REST et outil MCP.
Ce pour quoi chacun est conçu.
Ce que Firecrawl fait de mieux
Firecrawl excelle à transformer rapidement les pages publiques en texte propre prêt pour un LLM. Il offre une API simple et conviviale pour les développeurs dédiée au crawling en lecture seule, un cœur open source que vous pouvez auto-héberger, et il gère les parties pénibles de l’extraction - suppression du superflu, conversion en markdown - pour que votre modèle reçoive une entrée nette.
Ce que Writ apporte
Writ lit et agit. Il pilote un vrai navigateur sur votre propre compte : il peut se connecter, passer le 2FA, remplir des formulaires, enchaîner des étapes, soumettre et acheter - puis renvoyer une sortie structurée. Chaque workflow est un endpoint REST et un outil MCP, et il peut s’exécuter sur votre propre machine pour atteindre des systèmes qu’une API de crawling n’atteindrait jamais.
Lire la page vs. agir sur la page.
L’unité de Firecrawl, c’est la lecture de page : donnez-lui une URL, obtenez du markdown propre ou du JSON structuré. L’unité de Writ, c’est le workflow authentifié : se connecter en votre nom, naviguer, effectuer une action et renvoyer un résultat. Firecrawl est le bon outil quand les données sont publiques et que la lecture est tout l’objectif. Writ est fait pour quand les données sont derrière une connexion, ou quand la tâche est de faire quelque chose - et que vous voulez l’appeler comme API et outil MCP.
Côte à côte, honnêtement.
Les cases reflètent l’usage principal et documenté de chaque outil. Un tiret signifie que ce n’est pas l’objectif, pas un défaut - le support partiel est indiqué, pas masqué.
| Fonctionnalité | Writ | Firecrawl |
|---|---|---|
| Transformer un site en API REST | Oui | Partiel |
| Outil / serveur MCP | Oui | Oui |
| Fonctionne derrière une connexion | Oui | Non |
| 2FA : TOTP + OTP par e-mail | Oui | Non |
| Vérification sur vos propres comptes | Oui | Non |
| Enregistrer / décrire / découvrir un workflow | Oui | Partiel |
| Plus de 30 types d’étapes | Oui | Non |
| Moniteurs → agir (watch-and-act) | Oui | Partiel |
| Préparer une action pour validation (confirm-gate) | Oui | Non |
| S’exécute sur VOTRE compte et vos identifiants | Oui | Non |
| Exécution sur votre machine, sans frais de compute | Oui | Partiel |
| Atteint intranet / localhost / VPN uniquement | Oui | Partiel |
| Clés IA BYO, stockées localement, non facturées | Oui | Partiel |
| Templates de workflow installables | Oui | Non |
| Optimisation HTTP directe avec repli navigateur | Oui | Partiel |
| Portefeuille $ prépayé, plafonds de dépense, pas de facture surprise | Oui | Partiel |
| Auto-hébergement / voie ouverte | Oui | Oui |
| Conformité entreprise & contrôles des données | Partiel | Partiel |
Revu en juillet 2026. Les faits concurrents sont énoncés au niveau structurel (lire vs. agir, prise en charge de la connexion, où s’exécutent les runs, cœur open source), pas les prix exacts, qui changent souvent.
Là où Firecrawl est le meilleur choix.
Quand Firecrawl est le bon choix.
Si votre objectif est de lire des pages publiques et de fournir un texte propre à un LLM, Firecrawl est conçu pour cela et très bon. Son API de crawling est simple, rapide et conviviale pour les développeurs, et le cœur open source signifie que vous pouvez l’auto-héberger. Vous n’avez pas besoin d’une plateforme d’automatisation de navigateur pour obtenir du markdown propre - et pour cet objectif, Firecrawl est l’outil le plus léger.
Souvent, la réponse est : les deux.
Beaucoup d’équipes gardent Firecrawl pour le crawling en lecture seule et ajoutent Writ pour les actions authentifiées qu’une API de crawling ne peut pas effectuer - en appelant les deux depuis le même code.
Lequel choisir et quand.
Choisissez Writ si
- Vous devez agir sur un site, pas seulement le lire - vous connecter, remplir des formulaires, cliquer, soumettre ou acheter.
- Les données se trouvent derrière une connexion avec 2FA, sur votre propre compte autorisé.
- Vous voulez chaque workflow appelable comme endpoint REST et outil MCP qui agit, pas seulement qui lit.
- Vous voulez exécuter sur votre propre machine sans frais de calcul, ou atteindre un système interne / accessible uniquement par VPN qu’une API de crawling ne peut pas joindre.
- Vous voulez qu’un changement détecté déclenche un workflow (watch-and-act), pas seulement une lecture ponctuelle.
Choisissez Firecrawl si
- —Vous avez seulement besoin de lire des pages publiques et de fournir un texte propre, prêt pour un LLM, à un modèle.
- —Vous voulez une API simple et conviviale pour les développeurs, uniquement pour le crawling en lecture seule à grande échelle.
- —Vous voulez spécifiquement un cœur de crawling open source que vous pouvez auto-héberger.
Utiliser Writ aux côtés de (ou à la place de) Firecrawl.
- 01
Séparez la lecture de l’action
Déterminez quelles tâches relèvent de la pure lecture (Firecrawl les fait bien) et lesquelles nécessitent une action authentifiée.
- 02
Gardez Firecrawl là où il convient
Pour le crawling public en lecture seule qui vous satisfait, inutile de changer - les deux fonctionnent côte à côte.
- 03
Enregistrez les flux d’action dans Writ
Pour tout ce qui se connecte, remplit un formulaire, soumet ou achète, enregistrez-le une fois (ou décrivez-le à l’IA) sur votre propre compte.
- 04
Publiez des endpoints + outils MCP
Exposez chaque workflow Writ sur /v1/firecrawl/run et comme outil MCP, puis appelez-le depuis le même code qui appelle Firecrawl.
Questions fréquentes.
Writ est-il une bonne alternative à Firecrawl ?
Cela dépend de l’objectif. Firecrawl excelle à transformer des pages publiques en markdown/JSON propre pour un LLM. Writ est fait pour quand vous devez agir - vous connecter, remplir, soumettre ou acheter - sur votre propre compte autorisé, et vouloir que ce soit appelable comme API et outil MCP. Beaucoup d’équipes utilisent les deux.
Writ fait-il de l’extraction de données web comme Firecrawl ?
Oui. Les workflows Writ incluent une étape d’extraction qui renvoie des champs typés et structurés depuis une page. La différence, c’est que Writ exécute d’abord tout le flux authentifié - connexion, navigation, formulaires - afin d’extraire des données qu’un crawl en lecture seule ne peut pas atteindre.
Firecrawl peut-il se connecter et effectuer des actions ?
Firecrawl est conçu pour le crawling en lecture seule et reste limité derrière une connexion ; il ne clique pas, ne remplit pas, ne soumet pas et n’achète pas. Writ pilote un vrai navigateur sur votre propre compte : il réalise des actions authentifiées en plusieurs étapes et renvoie une sortie structurée.
Writ s’exécute-t-il sur mon propre compte ?
Oui. Les workflows s’exécutent sur vos propres comptes et identifiants, dans le cloud ou sur votre propre machine sans frais de calcul. Writ s’exécute sur vos propres comptes, avec vos propres identifiants et données, sur des sites que vous êtes autorisé à utiliser.
Lisez la page - puis agissez dessus.
Voyez comment Writ se compare à Firecrawl sur votre propre workflow - commencez gratuitement, ou réservez une démo.