D'artisan à infra pro : comment Apify transforme mon scraping

Pourquoi transformer chaque mission client en actor Apify au lieu de garder des scripts sur son PC ? Après 3 ans de freelance en scraping et 424+ projets réalisés, j'ai basculé d'une approche artisanale (scripts locaux) vers une vraie infrastructure. En 2026, dès qu'une mission est validée, je transforme chaque script en actor Apify. Dans ce guide, je partage pourquoi j'ai fait ce virage, comment ça fonctionne concrètement, les résultats obtenus (100$ générés en 3 mois), et ce que tu peux en retenir si tu fais du scraping ou du freelance sur des missions de données.

💡 Résumé rapide : Freelance scraping depuis 2023, j'ai accumulé pendant 2 ans des scripts locaux qui devenaient ingérables. Passage à Apify en 2026 pour scalabilité, organisation et monétisation. Résultat : 100$ générés en 3 mois avec 243 utilisateurs totaux, 47 utilisateurs mensuels actifs et 33 actors publiés.

Pourquoi ce virage vers Apify ?

Pendant plus de deux ans, j'ai enchaîné le même schéma : un client arrivait avec un besoin précis, j'écrivais le script, je le faisais tourner sur ma machine, je récupérais le CSV et je lui envoyais le fichier. Avec une vingtaine à une trentaine de demandes par mois, les scripts se sont accumulés, l'organisation a dégringolé, et j'ai pris conscience d'un vrai problème de scalabilité.

Le déclic : une mission à 200 000 lignes

Mon premier vrai blocage est arrivé avec une mission pour Mastercard Services : extraire 200 000 lignes de données publiques sur des entités gouvernementales. J'ai lancé mon script local un vendredi soir. Lundi matin, mon PC avait planté deux fois, le script tournait depuis 48h et j'étais seulement à 40% de l'extraction.

Problèmes rencontrés :

• Ma machine saturait (RAM à 95%, CPU à 100%)
• Les proxies résidentiels 4G que j'utilisais ne suffisaient plus
• Impossible de scaler au-delà d'un certain seuil
• Aucune réutilisation possible pour d'autres clients

C'est ce jour-là que j'ai compris qu'il fallait une vraie infrastructure si je voulais grandir. Si tu veux en savoir plus sur mon parcours et mes 424+ projets réalisés, tu peux consulter ma page À propos.

Les limites de « tout sur ma machine »

Tant que tout tournait sur mon ordinateur, plusieurs choses ont plafonné.

Un fouillis impossible à maintenir

Les scripts s'empilaient dans des dossiers, les noms de fichiers ne suivaient plus, et retrouver un script pour le réutiliser ou le faire évoluer pour un client devenait de plus en plus coûteux.

Exemple concret : Un client me demande d'extraire à nouveau des données Doctolib 6 mois après une première mission. Je passe 2 heures à retrouver le bon script parmi les dizaines de dossiers "doctolib_v1", "doctolib_final", "doctolib_v2_client_XYZ". Une fois trouvé, le script ne fonctionne plus car Doctolib a changé sa structure HTML entre-temps.

Chaque nouvelle mission donnait lieu à un nouveau script quelque part sur mon disque, sans vraie réutilisation ni capitalisation. Pour le client, le livrable restait un fichier temporaire : une fois le CSV envoyé, il n'y avait pas d'actif réutilisable, ni pour lui ni pour d'autres.

La scalabilité qui plafonne

Dès que le volume montait — des centaines de milliers de lignes, des sites un peu protégés —, ma machine saturait. Le temps d'exécution explosait, et je me heurtais aux limites du CAPTCHA et des proxies.

Tableau comparatif : Local vs Apify

Si tu as déjà fait tourner un scraper Playwright ou Puppeteer sur des dizaines de milliers de pages, tu sais que ça finit par manger la RAM et le CPU ; sur ma machine, c'était la limite.

Le moment où j'ai dit « stop »

À un moment, il était clair que ça ne pouvait plus continuer comme ça si je voulais grandir. Je ne voulais plus être un simple artisan du script : on venait me voir, je produisais la valeur et je renvoyais le fichier. Je voulais pouvoir scaler, réutiliser ce que je construisais, et éventuellement en faire un complément de revenus. Pour ça, il fallait une vraie infrastructure.

Apify : une bibliothèque de scripts et une boutique en ligne

Apify, pour ceux qui ne connaissent pas, c'est à la fois une bibliothèque de scripts — un peu comme un GitHub où les développeurs échangent du code — et une sorte de boutique : n'importe qui peut utiliser un script pour quelques euros et récupérer des données.

Comment ça fonctionne ?

Tu cherches un script Google Maps pour extraire des restaurants ou des avis ? Tu le trouves, tu le lances, tu récupères les données. Tous les cas d'usage ne sont pas couverts, loin de là.

Le marché français : un angle différenciant

Le marché français a des besoins très spécifiques — Doctolib, Le Bon Coin, des plateformes gouvernementales, Hellowork, APEC — sur lesquels je développe des scripts. L'idée est d'alimenter Apify avec ces besoins que je valide déjà via mes clients.

Mes 33 actors publics sur Apify :

• Airbnb Pro Host Business Email Scraper (83 utilisateurs) — lead generation B2B immobilier
• Airbnb Property Scraper (16 utilisateurs) — extraction données propriétés
• Airbnb Property Details Scraper (16 utilisateurs) — 30+ champs par propriété
• Airbnb Reviews Scraper (15 utilisateurs) — collecte avis clients
• Capeb Scraper (2 utilisateurs) — artisans du bâtiment français
• Drhouse Conseillers Scraper (2 utilisateurs) — conseillers immobiliers
• Startupticker Investors Scraper (2 utilisateurs) — investisseurs suisses
• Et 26 autres actors sur des plateformes françaises et internationales

Mon cas d'usage concret : une mission Doctolib devenue actor

Prenons un exemple concret. Un client voulait extraire les données des professionnels de santé sur Doctolib — noms, spécialités, zones d'exercice, etc. — pour une étude de marché. Avant, j'aurais développé le script sur ma machine, je l'aurais fait tourner en local, et j'aurais envoyé le CSV. Cette fois, j'ai développé le script puis je l'ai poussé directement sur Apify.

Le besoin client

Extraire les données publiques des professionnels de santé sur Doctolib, avec une mise à jour possible si le client voulait rafraîchir les données plus tard. Le volume pouvait monter à plusieurs milliers de lignes ; en local, ça aurait pris des heures et saturé ma machine.

Le développement et la mise sur Apify

J'ai développé le script comme d'habitude (Playwright pour naviguer, extraction des données structurées), mais au lieu de le garder sur mon PC, je l'ai envoyé sur Apify.

Stack technique utilisée :

• Playwright pour la navigation
• Apify SDK pour la gestion de l'infra
• Proxies résidentiels gérés par Apify
• Export CSV/JSON automatique

L'actor tourne sur l'infra Apify : proxy, mémoire et calcul sont gérés côté plateforme. J'ai récupéré les données sur Apify et je les ai envoyées au client.

Ensuite, j'ai publié l'actor : aujourd'hui, mon actor Doctolib peut être utilisé par d'autres, et si mon client veut être autonome, je peux lui proposer un accès en abonnement pour relancer l'extraction quand ses données évoluent.

Le résultat

Un livrable pour le client, un actif réutilisable pour moi et pour les autres, et une base pour d'éventuels revenus complémentaires via Apify. C'est exactement le schéma que je reproduis pour chaque mission validée.

Bénéfices concrets :

• ✅ Client satisfait avec des données propres et structurées
• ✅ Actor réutilisable pour d'autres clients santé
• ✅ 15 utilisateurs ont utilisé l'actor depuis sa publication
• ✅ 25$ générés en 2 mois sur cet actor seul

Mon workflow aujourd'hui : étape par étape

Voici comment je procède désormais pour chaque mission client :

Étape 1 : Validation du besoin avec le client (J+0)

Le client arrive avec une demande précise (extraction de données sur une plateforme, volume estimé, fréquence éventuelle). On valide ensemble le périmètre et le livrable. Si la demande est claire et que je peux y répondre avec un script dédié, je m'engage sur la mission.

Étape 2 : Développement du script (J+1 à J+3)

Je développe le script comme avant — en local ou directement dans l'environnement Apify selon les cas. J'utilise Playwright ou Puppeteer pour les pages dynamiques, ou Cheerio et des requêtes HTTP pour les pages plus simples.

La différence : dès que le script est stable, il part sur Apify.

Étape 3 : Mise sur Apify et exécution (J+4 à J+5)

Je pousse le script sur Apify et je le fais tourner sur l'infra de la plateforme. Je peux tester la scalabilité tout de suite : plus de puissance de calcul, plus de tabs, proxy et mémoire gérés par Apify. Je récupère les données (CSV, JSON) directement sur Apify et je les envoie au client.

Étape 4 : Publication de l'actor et livraison (J+6 à J+7)

Une fois la mission livrée, je transforme le script en actor public (ou privé, selon le cas). L'actor devient un actif réutilisable : d'autres peuvent l'utiliser, et je peux proposer à mon client un upsell en abonnement s'il veut être autonome pour des mises à jour régulières.

En résumé : besoin validé → script développé → exécution sur Apify → livraison au client → actor publié. Un actor = une mission = un actif.

Tableau récapitulatif du workflow

Ce que ça change concrètement

Pour moi

Scalabilité : plus de limite machine ; proxy, serveur et mémoire sont gérés par Apify. Je peux traiter des volumes bien plus importants sans saturer mon PC.

Organisation : un actor = une mission = un actif. Plus de scripts perdus dans des dossiers ; tout est versionné et accessible sur Apify.

Réutilisation : les actors peuvent être utilisés par d'autres, ce qui valide la demande et peut générer un complément de revenus.

Évolution possible : je peux packager des actors plus tard — par exemple en SaaS ou en produit à part entière — sans tout reconstruire depuis zéro.

Pour le client

Livrable : il reçoit ses données (fichier temporaire ou accès aux exports) comme avant.

Autonomie possible : s'il veut rafraîchir ses données régulièrement, je peux lui proposer un accès à l'actor en abonnement. Double avantage pour lui, et ça complète mon offre de valeur.

Des exemples d'actors créés à partir de missions

Au-delà de Doctolib, j'ai mis en ligne des actors issus de missions recrutement, immobilier, e-commerce, etc. Par exemple :

• Scraping Hellowork : extraction des offres d'emploi en temps réel, pour des clients qui font de la veille recrutement.
• Scraping APEC : extraction des offres cadres, très demandé sur le marché français.
• Airbnb (professionnels) : un script très utilisé pour extraire les données des professionnels sur Airbnb ; les données publiques ne concernent que l'Europe, mais ça intéresse déjà beaucoup de monde.

Tu peux découvrir l'ensemble de mes cas d'usage et actors sur ma marketplace.

Apify comme complément de revenus

Je n'ai pas aujourd'hui l'ambition de vivre uniquement sur Apify. Il me faudrait encore beaucoup plus d'actors pour ça. Mais en trois mois, j'ai déjà généré environ 100 dollars, avec une visibilité encore faible et environ 200 utilisateurs mensuels actifs.

Les chiffres après 3 mois

Mes résultats en 3 mois

Ça me permet de valider qu'il y a une demande, et de me rendre compte que si je continue à développer des scripts de meilleure qualité et à améliorer ma pratique, ça peut devenir un complément de revenus très intéressant.

Ma projection pour 2026

Projection : Si je maintiens ce rythme et améliore la qualité de mes actors, je vise 500-1000$/mois d'ici fin 2026. Ce n'est pas énorme, mais c'est un revenu passif qui valide l'approche.

Je développe une fois, et je peux encaisser ensuite — avec bien sûr de la maintenance et des évolutions (sites qui changent, anti-bot, etc.), mais c'est déjà suffisamment scalable pour avoir généré 100 dollars et potentiellement bien plus sur les mois et les années à venir.

Les limites et ce que je ferais différemment

Soyons honnêtes : ce n'est pas parfait.

Les défis actuels

Challenges techniques et business

Visibilité faible : La visibilité sur Apify reste faible si on ne travaille pas le référencement et la qualité des fiches actors.

Maintenance continue : Il faut maintenir les scripts quand les sites cibles évoluent. Doctolib a changé sa structure HTML 3 fois en 6 mois.

Tous les cas d'usage ne sont pas rentables : Certains actors très spécifiques au marché français n'auront que peu de passage.

Coût de l'infrastructure : Apify facture à l'utilisation. Pour des gros volumes, ça peut vite monter (même si ça reste largement inférieur au coût d'une infra perso).

Ce que je ferais différemment

Si c'était à refaire, j'aurais peut-être basculé sur Apify plus tôt, dès que le volume de missions a commencé à rendre l'organisation locale ingérable.

Lessons learned :

1. Commencer à publier des actors dès les premières missions
2. Mieux documenter les actors pour faciliter l'adoption
3. Créer une landing page dédiée pour chaque actor (SEO)
4. Automatiser les tests de régression (quand les sites changent)

Mais pour moi, les avantages l'emportent : une vraie infra, une organisation claire, et un début de revenus passifs qui valide l'approche.

Ce que tu peux en retenir

Si tu fais du scraping ou du freelance sur des missions de données, voici ce que je retiens de ce virage :

1. À un moment, les scripts sur ta machine plafonnent

Organisation, volume, proxy, mémoire. Réfléchir à une infrastructure (Apify ou autre) devient nécessaire si tu veux scaler.

Signes que tu dois passer à une infra :

• Tu perds 2h+ par semaine à retrouver tes scripts
• Tes extractions prennent plus de 6h
• Ton PC sature régulièrement
• Tu refuses des missions à gros volume par peur de planter

2. Une mission = un actor (ou un actif réutilisable)

Au lieu d'un script perdu sur ton PC, tu crées un actif que d'autres peuvent utiliser et que tu peux monétiser ou packager plus tard.

3. Une vraie infra = scalabilité + sérénité

Tu ne dépends plus de ta machine pour les gros volumes ni pour la gestion des proxy et des blocages.

4. Les actors peuvent devenir une source de revenus complémentaire

Pas besoin d'en faire ton cœur de métier tout de suite ; même un petit revenu récurrent valide l'offre et motive à améliorer la qualité des scripts.

💼 Besoin d'aide pour passer à Apify ?
Si cette approche te parle mais que tu ne sais pas par où commencer, je peux t'accompagner. Avec 424+ projets réalisés et 33 actors publiés (243 utilisateurs), je peux te montrer concrètement comment transformer tes scripts en actors.

Réservez un appel gratuit de 20 minutes pour qu'on discute de ton projet.

Mon retour d'expérience après 3 ans de freelance

J'ai commencé le scraping en freelance il y a environ 3 ans. Ma façon de travailler a évolué avec mes compétences techniques, les demandes clients, et la nécessité de scaler.

L'évolution de mon approche

2023 : Scripts locaux, tout sur ma machine, organisation artisanale

2024 : Début de structuration, premiers tests avec Apify

2025 : Migration progressive vers Apify

2026 : 100% des nouvelles missions transformées en actors

Aujourd'hui, baser chaque mission sur Apify est le résultat de cette évolution : du script artisanal sur ma machine à une infrastructure qui me permet de livrer, de réutiliser et de commencer à générer des revenus passifs.

Si tu veux découvrir d'autres cas d'usage que j'ai réalisés — immobilier, recrutement, santé, e-commerce — tu peux consulter mes cas d'usage détaillés.

Conclusion

Après deux à trois ans à accumuler des scripts sur mon PC et à livrer des CSV à la main, je base maintenant tout mon développement sur Apify. Chaque mission client validée donne lieu à un actor : scalabilité, organisation, réutilisation, et un début de complément de revenus.

Ce n'est pas encore une vocation à temps plein, mais c'est une évolution logique — du CDI au freelance, puis à une offre freelance qui mûrit et qui commence à générer des actifs réutilisables.

En chiffres :

• 424+ projets réalisés depuis 2023
• 33 actors publiés sur Apify
• 243 utilisateurs totaux (47 actifs/mois)
• 100$ générés en 3 mois (sans marketing)
• 98,1% de taux de réussite des exécutions

Si tu as des questions sur le scraping, l'infrastructure Apify ou si tu as besoin d'accompagnement sur un projet spécifique, n'hésite pas à me contacter. Tu peux aussi consulter mes témoignages clients pour voir comment j'ai aidé d'autres entreprises avec leurs projets de scraping et d'automatisation.

Tu peux découvrir mes actors et bases de données sur ma marketplace, ou des cas d'usage détaillés comme Doctolib, Hellowork ou APEC.

---

Cet article fait partie d'une série sur le scraping et l'automatisation. Si tu veux en savoir plus, consulte mes autres articles sur le blog ou ma marketplace d'outils et bases de données.