La réponse dépend d'un seul critère : où tourne votre code. Pour une résolution ponctuelle dans un vrai navigateur, une extension suffit ; dès que vous automatisez côté serveur ou à fort volume, l'API prend l'avantage. Le prix, lui, ne tranche pas la question : la facturation CaptchaAI se fait par thread, quel que soit le chemin emprunté.
Ce qui vous départage vraiment, ce sont trois facteurs : le volume à traiter, l'environnement d'exécution (poste, serveur, conteneur, CI) et le degré de contrôle dont vous avez besoin sur la logique de résolution.
Voici comment les deux approches se comportent sur chacun.
Comparaison en un coup d'œil
| Critère | Extension de navigateur | Solveur via API |
|---|---|---|
| Mise en place | Installer l'extension, ajouter la clé API | Intégrer les appels HTTP dans votre code |
| Navigateur requis | Oui | Non (sauf pour injecter le token) |
| Passage à l'échelle | Faible : un navigateur par instance | Élevé : requêtes parallèles quasi illimitées |
| Vitesse | Rapide (détection + résolution auto) | Dépend du type de CAPTCHA (5 à 30 s) |
| Contrôle | Limité | Contrôle programmatique complet |
| Prise en charge headless | Limitée | Complète |
| Usage côté serveur | Non | Oui |
| Coût | Facturation par thread, identique | Facturation par thread, identique |
| Langages | Navigateur uniquement (JavaScript) | N'importe quel langage |
Retenez la ligne « Passage à l'échelle » : c'est elle qui fait basculer la plupart des décisions dès que le volume dépasse quelques résolutions à la fois.
Quand privilégier l'API
| Cas d'usage | Pourquoi l'API est plus adaptée |
|---|---|
| Scraping web à grande échelle | Résolution parallèle, sans surcharge de navigateur |
| Automatisation côté serveur | Aucun navigateur disponible sur la machine |
| Tests CI/CD | Environnements headless par défaut |
| Microservices | Appels HTTP depuis n'importe quel service |
| Plusieurs types de CAPTCHA | Détection et routage par type dans le code |
| Gestion fine du retry et des erreurs | Contrôle total sur la reprise après incident |
| Optimisation des coûts | Suivi de l'usage, mise en cache, résolutions redondantes évitées |
Prenez une équipe QA à Lyon qui exécute ses tests de bout en bout dans un pipeline GitHub Actions : les runners n'ont aucun navigateur graphique, l'extension y est inutilisable, alors que l'appel API s'intègre directement dans la suite headless. Même logique pour un worker déployé sur OVHcloud ou dans une fonction serverless.
Quand privilégier l'extension
| Cas d'usage | Pourquoi l'extension convient |
|---|---|
| Navigation manuelle avec CAPTCHA occasionnels | Confort d'usage, aucun code requis |
| Prototypage rapide | Valider une idée avant de coder une intégration API |
| Tâches sur un seul navigateur | Remplissage de formulaire, faible volume |
| Utilisateurs non-développeurs | Aucune programmation nécessaire |
Comment fonctionne une extension de navigateur
Une extension surveille le chargement des pages à la recherche de widgets CAPTCHA connus (reCAPTCHA, Turnstile, CAPTCHA image). Dès qu'elle en repère un, elle extrait les paramètres, les envoie à l'API de résolution puis réinjecte le token dans la page, sans que vous écriviez une ligne de code.
| Ce qui joue pour l'extension | Ce qui la freine |
|---|---|
| Prise en main sans code : on installe, on colle sa clé API | Un navigateur, visible ou headless, requis en permanence |
| Détection et injection du token automatiques | Une instance = une résolution à la fois |
| Résolution dans le contexte réel de la page | Montée en charge coûteuse (multiplier les navigateurs) |
| Compatible avec les sites riches en JavaScript | Empreinte d'extension repérable par les anti-bot |
| — | Inexécutable sur un serveur sans navigateur |
| — | Gestion des erreurs et retry réduits au minimum |
| — | Une mise à jour de l'extension peut casser le flux |
Comment fonctionne un solveur via API
Ici, vous envoyez des requêtes HTTP à l'API : vous soumettez les paramètres du CAPTCHA (sitekey, URL de la page, données d'image), vous interrogez le résultat, puis vous utilisez le token dans votre application.
Aucun navigateur n'est nécessaire.
| Ce qui joue pour l'API | Ce qui reste à votre charge |
|---|---|
| Contrôle programmatique complet du flux | Coder l'intégration |
| Fonctionne dans n'importe quel langage (Python, Node.js, PHP, Go) | Gérer vous-même l'injection du token |
| Monte jusqu'à des milliers de résolutions en parallèle | Extraire les sitekeys et paramètres |
| Tourne sur serveurs, conteneurs et fonctions serverless | — |
| Gestion des erreurs, retry et supervision sur mesure | — |
| S'utilise avec ou sans navigateur | — |
| Pas d'empreinte d'extension exposée | — |
Passage à l'échelle
| Métrique | Extension | API |
|---|---|---|
| 1 CAPTCHA | Même vitesse | Même vitesse |
| 10 CAPTCHA simultanés | 10 navigateurs à lancer | 10 requêtes HTTP parallèles |
| 100 CAPTCHA simultanés | Peu praticable | Charge de travail courante |
| Plus de 1 000 CAPTCHA simultanés | Non réaliste | File d'attente + workers |
| RAM par instance | 200 à 500 Mo (Chrome) | ~10 Mo (client HTTP) |
| CPU par instance | Élevé (rendu du navigateur) | Faible (HTTP uniquement) |
L'écart se creuse avec le volume. Un navigateur mobilise 200 à 500 Mo de RAM ; un client HTTP se contente d'une dizaine de mégaoctets.
Côté facture, rien ne change : CaptchaAI facture par thread simultané, avec des résolutions illimitées par thread. Le plan BASIC ($15/mois, 5 threads) autorise déjà cinq résolutions en parallèle.
Approche hybride : le navigateur pour naviguer, l'API pour résoudre
Sur les sites les plus complexes, rien n'oblige à choisir. Vous pouvez piloter un vrai navigateur pour le rendu et ne déléguer que la résolution à l'API.
from selenium import webdriver
import requests
import time
driver = webdriver.Chrome()
driver.get("https://example.com/login")
# Detect CAPTCHA
sitekey = driver.find_element("css selector", "[data-sitekey]").get_attribute("data-sitekey")
# Solve via API (not extension)
submit = requests.post("https://ocr.captchaai.com/in.php", data={
"key": "YOUR_API_KEY",
"method": "userrecaptcha",
"googlekey": sitekey,
"pageurl": driver.current_url,
"json": 1
}).json()
task_id = submit["request"]
time.sleep(15)
for _ in range(24):
result = requests.get("https://ocr.captchaai.com/res.php", params={
"key": "YOUR_API_KEY", "action": "get", "id": task_id, "json": 1
}).json()
if result.get("status") == 1:
token = result["request"]
# Inject token via JavaScript
driver.execute_script(
f'document.getElementById("g-recaptcha-response").value = "{token}";'
)
driver.find_element("css selector", "form").submit()
break
time.sleep(5)
Vous gardez le rendu complet du navigateur pour les pages gourmandes en JavaScript, tout en conservant le contrôle programmatique de l'API sur la partie résolution.
Fiabilité en production
| Facteur | Extension | API |
|---|---|---|
| Détection du CAPTCHA | Automatique (peut manquer un widget personnalisé) | Manuelle (vous maîtrisez la logique) |
| Gestion des erreurs | Au niveau de l'extension (limitée) | Dans votre code (contrôle total) |
| Mises à jour | Une mise à jour peut tout casser | API versionnée, rétrocompatible |
| Plantage du navigateur | Session perdue | Aucun navigateur à faire planter |
| Détection anti-bot | L'empreinte de l'extension peut être repérée | Pas d'empreinte d'extension |
FAQ
Le coût par résolution change-t-il selon l'approche ?
Non. Les deux chemins passent par la même infrastructure CaptchaAI et la même facturation par thread. Chaque CAPTCHA résolu sur un thread actif est inclus, sans frais par CAPTCHA, que la demande vienne de l'extension ou de l'API.
Une extension peut-elle tourner sur un serveur sans interface graphique ?
En théorie oui, via Chrome headless, mais la prise en charge reste fragile et certains CAPTCHA détectent le mode headless. Pour un serveur, un conteneur ou un runner CI, l'API est nettement plus fiable puisqu'elle ne dépend d'aucun navigateur.
Combien de résolutions simultanées un plan à 5 threads permet-il ?
Cinq. Chaque thread traite une résolution à la fois mais en enchaîne un nombre illimité ; pour aller plus vite, vous ajoutez des threads, pas des navigateurs. C'est là tout l'écart avec l'extension, plafonnée à un navigateur par résolution.
Quelle approche choisir pour du scraping multi-langages ?
L'API, sans hésiter. Elle s'appelle depuis Python, Node.js, PHP ou Go de la même manière, alors que l'extension vous enferme dans l'écosystème du navigateur en JavaScript. Pour un parc de services hétérogène, l'appel HTTP reste le dénominateur commun.
Obtenez votre clé API CaptchaAI
Construisez une résolution CAPTCHA qui passe à l'échelle sur captchaai.com.
Guides associés
- Le guide de démarrage rapide CaptchaAI
- Résoudre reCAPTCHA v2 via l'API
- Piloter un navigateur ChromeDriver avec CaptchaAI
- Piloter Chrome via le protocole DevTools