Demandez à une équipe data ce que leur collecte web coûte et vous entendrez parler de gigaoctets, de nombre de requêtes, de crédits et de taux de succès. Demandez à la finance ce qu’elle veut savoir et la réponse est plus simple : combien coûte un enregistrement exploitable, et cela augmente-t-il ou diminue-t-il ? Les deux conversations se rejoignent rarement, car les chiffres suivis par les ingénieurs décrivent le pipeline, pas ce qu’il produit.
Le coût par enregistrement propre comble cet écart. C’est le coût total d’un job de collecte divisé par les enregistrements ayant passé la validation, ceux que vous mettriez réellement dans un rapport, un modèle ou un produit destiné aux clients. Ce guide le définit correctement, montre où l’argent va vraiment, détaille un exemple, et classe les leviers qui le font bouger.
Points clés à retenir
- Mesurez le coût par enregistrement propre : coût total divisé par les enregistrements ayant passé la validation de contenu, et non par les requêtes ou les succès HTTP.
- Pour les jobs de surveillance, ajoutez le coût par changement utile. La plupart des nouvelles récupérations ne confirment aucun changement, donc un changement peut coûter plusieurs fois plus qu’un enregistrement.
- Le modèle de facturation détermine quel gaspillage fait mal. La facturation à la bande passante pénalise les pages lourdes ; la facturation au succès pénalise les récupérations inutiles.
- Une page d’accueil médiane pèse environ 2,5 Mo, dont seulement 22 Ko de HTML. Ne récupérer que ce que vous analysez est souvent la plus grosse économie possible sur une collecte facturée à la bande passante.
- Rapportez cette métrique mensuellement, par job, avec ses composantes. Un chiffre que la finance peut suivre est un chiffre qui obtient un budget.
Définir la métrique avec précision
Trois définitions font l’essentiel du travail.
Le coût total est tout ce que le job a consommé : bande passante proxy ou crédits d’API, calcul, stockage et, en toute honnêteté, le temps d’ingénierie passé à le maintenir en fonctionnement.
Un enregistrement propre est un enregistrement ayant passé la validation : champs requis présents, valeurs dans des plages plausibles, et une page qui était réellement celle demandée plutôt qu’une page de blocage, un challenge ou une coquille vide. Une réponse avec un code HTTP 200 n’est pas un enregistrement propre tant qu’elle n’a pas passé ces vérifications ; l’écart entre les deux est le sujet du taux d’échec silencieux.
Un changement utile compte pour la surveillance. Si vous récupérez un prix chaque jour et qu’il change deux fois par mois, l’enregistrement payé les 28 autres jours n’a rien confirmé de nouveau. Le coût par changement utile capture ce à quoi sert vraiment la surveillance.
Savoir comment vous êtes facturé
Le même pipeline peut être cher ou bon marché selon le modèle de facturation, car chaque modèle compte des choses différentes.
| Modèle de facturation | Ce que vous payez | Ce qui le rend cher |
|---|---|---|
| Bande passante proxy résidentiel | Octets passant par la passerelle | Pages lourdes, rendu, retentatives qui transfèrent des données |
| Crédits d’API de scraping | Réponses réussies | Récupérations dont vous n’aviez pas besoin |
Sur la passerelle résidentielle de Shifter, chaque octet envoyé ou reçu compte, y compris les en-têtes, et les requêtes échouées comptent si des octets ont été transférés avant l’erreur. Sur le Web Scraping API, une requête réussie coûte un crédit, que le rendu JavaScript soit activé ou non, les requêtes échouées et les erreurs côté cible ne coûtent rien, et les retentatives automatiques au sein d’un même appel sont comptées comme cet unique appel. Ainsi, en facturation à la bande passante, une page rendue qui charge toutes les images et scripts peut coûter bien plus que son HTML ; en facturation au succès, elle coûte la même chose.
L’écart de taille est important. Le Web Almanac 2025 du HTTP Archive a constaté que la page d’accueil médiane pesait 2,86 Mo sur ordinateur et 2,56 Mo sur mobile, tandis que le HTML médian était de 22 Ko dans les deux cas. Si vous n’analysez que le HTML, ou un point d’accès JSON sous-jacent, la plupart des octets d’une page entièrement rendue ne vous apportent rien.
Un exemple détaillé
Considérons un job de surveillance sur un mois. Les chiffres ci-dessous sont illustratifs, choisis pour montrer le calcul, et le taux de 3 $ par Go est un chiffre rond pour l’exemple, pas un devis.
| Entrée | Valeur |
|---|---|
| Requêtes envoyées, retentatives incluses | 120 000 |
| Octets moyens par requête | 450 Ko |
| Succès au niveau HTTP | 108 000 |
| Enregistrements ayant passé la validation | 97 000 |
| Enregistrements valides différant de la dernière copie | 6 800 |
| Taux de bande passante | 3,00 $ par Go |
| Calcul | 40 $ |
En exécutant le calcul ci-dessous, on obtient :
| Métrique | Valeur |
|---|---|
| Coût total | 202,00 $ |
| Coût par requête | 0,0017 $ |
| Coût par enregistrement propre | 0,0021 $ |
| Coût par changement utile | 0,0297 $ |
| Taux d’échec silencieux | 10,2% |
| Octets par enregistrement propre | environ 557 Ko |
Deux choses ressortent. Chaque changement utile coûte environ quatorze fois plus que chaque enregistrement propre, car la plupart des récupérations confirment que rien n’a bougé. Et un succès HTTP sur dix n’a produit rien d’exploitable.
Changeons maintenant une chose : arrêter de rendre les pages complètes et ne récupérer que le HTML ou le JSON dont l’analyseur a besoin, réduisant la moyenne de 450 Ko à 60 Ko par requête. Tout le reste reste identique. Le coût total tombe à 61,60 $, le coût par enregistrement propre à 0,0006 $, et le coût par changement utile à 0,0091 $, soit une réduction de plus des deux tiers pour un seul changement dans la façon de récupérer les pages.
Le calculateur tient en quelques lignes :
from dataclasses import dataclass
@dataclass
class Run:
requests: int # every request sent, including retries
bytes_transferred: int # everything through the proxy, failures included
responses_ok: int # HTTP-level successes
records_valid: int # records that passed content validation
records_changed: int # valid records that differed from the last copy
price_per_gb: float # your plan's rate
compute_cost: float = 0.0
people_cost: float = 0.0 # engineering time spent on this job, if you count it
def unit_economics(run):
bandwidth = run.bytes_transferred / 1e9 * run.price_per_gb
total = bandwidth + run.compute_cost + run.people_cost
return {
"total_cost": round(total, 2),
"cost_per_request": round(total / max(1, run.requests), 5),
"cost_per_clean_record": round(total / max(1, run.records_valid), 4),
"cost_per_useful_change": round(total / max(1, run.records_changed), 4),
"silent_failure_rate": round(1 - run.records_valid / max(1, run.responses_ok), 3),
"bytes_per_clean_record": int(run.bytes_transferred / max(1, run.records_valid)),
}Pour un job facturé au crédit, remplacez la ligne de bande passante par le nombre de réponses réussies multiplié par votre prix par crédit. Le reste du calcul est identique.
Les leviers, dans un ordre approximatif d’impact
1. Arrêtez de récupérer ce qui n’a pas changé. Pour la surveillance, les nouvelles récupérations sans changement constituent généralement le poste de coût le plus important. Planifier les visites selon la fréquence réelle de changement de chaque page, et utiliser des requêtes conditionnelles là où les sites les prennent en charge, réduit les récupérations sans perdre de changements. La méthode est exposée dans la planification de crawl sensible aux coûts, et distinguer les vrais changements du bruit dans la détection de changements à grande échelle.
2. Récupérez moins par page. En facturation à la bande passante, évitez le rendu sauf si les données l’exigent, bloquez les images, polices et médias lorsque vous devez rendre, privilégiez les points d’accès JSON et gardez la compression activée. La liste complète figure dans réduire les coûts de bande passante des proxies.
3. Corrigez les échecs silencieux. Chaque page de blocage, challenge ou coquille vide qui passe pour un succès coûte autant qu’un bon enregistrement et ne produit rien. Validez le contenu, comptez les échecs par cible, et corrigez ou ralentissez les cibles qui en produisent.
4. Extrayez depuis des sources stables. La maintenance est un coût réel. Les sélecteurs qui se cassent à chaque refonte consomment du temps d’ingénierie, ce qui explique pourquoi les données structurées sont moins chères sur un an qu’elles n’en ont l’air sur une seule exécution ; voir arrêtez d’analyser le HTML.
5. Adaptez le modèle de facturation à la cible. Les pages lourdes qui doivent être rendues peuvent être moins chères en facturation au succès ; les cibles HTML ou JSON légères sont généralement moins chères en facturation à la bande passante. Les portefeuilles mixtes utilisent souvent les deux. L’arbitrage plus large est couvert dans construire ou acheter pour l’infrastructure de scraping web.
En rendre compte à la finance
Une métrique ne compte que si elle est rapportée de manière cohérente. Une fois par mois, par job, publiez :
- Le coût total, réparti en bande passante ou crédits, calcul et, si vous le comptez, personnel.
- Les enregistrements propres, et le coût par enregistrement propre.
- Pour les jobs de surveillance, les changements utiles, et le coût par changement utile.
- Le taux d’échec silencieux et les octets par enregistrement propre, comme les deux principaux indicateurs avancés.
- Le principal changement depuis le mois précédent, et pourquoi.
Maintenu sur un trimestre, cela transforme la donnée web d’une ligne d’infrastructure opaque en un coût unitaire pouvant être budgété, comparé à l’achat de la donnée ailleurs, et défendu.
En résumé
Les gigaoctets et le nombre de requêtes décrivent l’effort. La finance se soucie du résultat : ce que coûte un enregistrement exploitable, et pour la surveillance, ce que coûte un vrai changement. Définissez les enregistrements propres par la validation, non par les codes de statut, comptez chaque coût encouru par le job, et rapportez le résultat par job chaque mois.
Les leviers sont rarement exotiques. Récupérez moins souvent là où rien ne change, récupérez moins par page, arrêtez de payer pour des pages qui paraissent réussies sans l’être, et extrayez depuis des sources qui ne se cassent pas. Chacun se reflète directement dans un chiffre que tout le monde dans la salle peut lire.
Sources et références
- HTTP Archive, Web Almanac 2025 : Page Weight. Poids médian des pages et du HTML, crawl de juillet 2025.
- Shifter, documentation Bande passante et facturation des proxies résidentiels et Erreurs et limites du Web Scraping API.