Transformer l’exploitation derrière une API de capture en activité : ScreenshotOne

Une alerte que les clients n’ont jamais vue

Le 17 juillet 2025, une alerte inhabituelle est parvenue à Dmytro Krasun, qui exploitait ScreenshotOne. Elle signalait un dépassement de délai dans une vérification qui charge une page web dans un vrai navigateur et en capture l’écran. Les autres sondes ne montraient aucun problème et les requêtes des clients étaient traitées comme d’habitude. Krasun a perdu le sommeil pendant plusieurs jours pour trouver un problème qu’aucun client ne voyait.

Il a vérifié le volume de requêtes et la charge des serveurs, annulé les modifications de code récentes et même testé la connexion réseau. En resserrant les recherches, il a constaté que l’accès au site externe utilisé comme cible de vérification était instable. En remplaçant la cible de capture par la page de présentation de son propre service, tout fonctionnait normalement. Cet incident lui a confirmé la nécessité d’un environnement de vérification qu’il contrôlait directement, et il a amélioré ses outils de diagnostic.

Le traitement derrière une seule capture

ScreenshotOne, que Krasun a lancé en mai 2022, était une API qui renvoyait des résultats comme des captures d’écran ou des PDF quand un autre programme lui envoyait une adresse web ou du HTML. Avant de créer son entreprise, il avait passé plus de dix ans à développer des systèmes qui traitaient des serveurs et de gros volumes de requêtes. Il a choisi un marché de la capture d’écran où les gens payaient déjà pour ce service et a pris en charge les problèmes liés à l’exploitation de navigateurs et à la génération d’images. Les clients pouvaient demander les images dont leur propre produit avait besoin et confier à ScreenshotOne le travail qui se déroulait derrière.

Les outils pour créer soi-même une fonction de capture existaient déjà. Piloter un navigateur automatiquement avec Puppeteer ou Playwright permettait d’ouvrir une page web et d’enregistrer une image. Pour capturer une page entière, il fallait ensuite charger les images qui n’apparaissent qu’après le défilement et gérer les fenêtres de consentement aux cookies qui recouvrent le contenu. Une fois qu’il a fallu adapter aussi la taille de l’écran et l’emplacement de stockage aux demandes des clients, le court code du départ est devenu un service qui gère de nombreuses conditions.

ScreenshotOne a accumulé dans son produit l’expérience de la gestion de ces conditions. Selon la présentation officielle du produit, les règles et les méthodes de détection utilisées pour nettoyer les bannières de cookies sont plus de 50 000. Les clients peuvent masquer les publicités ou les fenêtres de discussion et, si nécessaire, ajuster les styles et le comportement d’une page. Au lieu que chaque équipe de développement résolve séparément des problèmes similaires, les méthodes de traitement accumulées par un service spécialisé étaient mises en commun.

Le cas de BugSmash, un outil de retour d’expérience pour le travail en équipe, montre à quel moment les équipes de développement acceptent de payer. Lorsqu’un utilisateur saisissait l’adresse d’un site web à examiner, BugSmash devait générer une image d’aperçu pour son tableau de bord et ses liens de partage. Cette image étant visible immédiatement par l’utilisateur, il était important qu’elle ne soit pas masquée par un pop-up et qu’elle ne tarde pas à se générer. BugSmash a utilisé ScreenshotOne pour ce travail. Pour sa fonction distincte d’évaluation de sites web, il utilisait Puppeteer et, dans un cas publié en avril 2025, il expliquait que la gestion des serveurs et le traitement simultané de plusieurs captures représentaient une charge.

Pour enregistrer l’écran au moment où un utilisateur laissait un commentaire, BugSmash utilisait une autre méthode. Comme il fallait capturer la position d’éléments en mouvement ou les pop-ups ouverts, il capturait dans le navigateur de l’utilisateur ou avait recours à une extension. Dans un même produit, la génération d’une image d’aperçu et l’enregistrement de l’écran courant de l’utilisateur répondaient à des exigences différentes. Le domaine dont ScreenshotOne avait la charge consistait à ouvrir des pages web de façon répétée sur un serveur et à produire de manière fiable les images destinées au produit.

Le processus d’intégration était lui aussi conçu pour faire gagner du temps aux développeurs. Le guide de démarrage présente un exemple de requête avec une adresse web et une clé d’accès, et fournit du code d’intégration pour chaque langage de programmation. Les clients peuvent modifier les options sur l’écran d’essai du tableau de bord et vérifier le résultat. En cas d’erreur, l’API renvoie à la fois un code que le programme peut distinguer et une description lisible par un humain, ce qui facilite la prise en charge de la cause de l’échec par l’équipe de développement du client.

Une infrastructure qui aligne usage et coûts

Les tarifs ont été conçus pour commencer avec un petit volume d’usage et augmenter selon les besoins réels. En septembre 2026, le service offre 100 captures gratuites par mois ; la formule de base à 17 dollars par mois en inclut 2 000 et la formule de croissance à 79 dollars par mois en inclut 10 000. Au-delà de l’usage inclus, le client paie un supplément au tarif de sa formule. La formule de base donne aussi accès à la capture de page entière, au blocage des publicités et des bannières de cookies ou encore à la génération de PDF, ce qui permet aux clients de décider de leurs dépenses en fonction du débit dont ils ont besoin.

Les règles de facturation tiennent compte des échecs et de la réutilisation. Les requêtes échouées à cause d’une erreur réseau ou de navigateur ne sont pas déduites de l’usage, et les réponses mises en cache qui renvoient un résultat déjà stocké ne sont pas comptées comme de nouvelles captures. Dans cette structure, le travail qui réduit le taux d’échec et réutilise les images déjà produites agit à la fois sur la satisfaction des clients et sur les coûts de l’exploitant. Krasun a dû apprendre cette relation dans l’exercice réel du service.

Au début, les requêtes passaient par Cloudflare et les captures déjà générées étaient stockées dans un cache pour être réutilisées. Mais lorsqu’une image stockée disparaissait du cache, il fallait relancer le navigateur pour traiter la même requête. Les requêtes de cache, alors offertes gratuitement aux clients, entraînaient un vrai coût de génération d’écran, et Krasun expliquait qu’il perdait de l’argent pour cette raison. Il a ajouté le service de stockage de fichiers R2 comme seconde couche de stockage afin qu’une image absente du cache le plus proche puisse être retrouvée dans le stockage et renvoyée.

Ensuite, le rôle des Cloudflare Workers, qui traitent les requêtes en amont, s’est élargi. Ils vérifiaient d’abord les requêtes erronées et les clés d’accès invalides, puis contrôlaient si le volume autorisé était dépassé, afin qu’un travail inutile n’atteigne pas les serveurs qui exécutent les navigateurs. Si le serveur principal était surchargé ou échouait à générer un écran, les requêtes partaient vers un autre centre de données. Pendant qu’un client envoyait une seule adresse web, un travail se déroulait à l’intérieur du service pour décider où traiter la requête et quel résultat réutiliser.

Une API intégrée au travail des clients

Sur une telle base, la relation avec un même client pouvait se poursuivre pendant des années. RepliQ, qui crée des vidéos personnalisées pour la vente, a indiqué dans un cas publié en juillet 2026 qu’il utilisait ScreenshotOne depuis environ quatre ans. L’usage consistait à transformer le site web ou le profil d’un prospect en images et en GIF animés pour les placer en arrière-plan de ses vidéos. RepliQ expliquait avoir pu réduire la gestion de son propre système de capture et se concentrer sur la personnalisation des vidéos, et avoir maintenu l’intégration pendant la croissance de son service.

Krasun a aussi publié la méthode pour construire soi-même une API de capture. Son guide de développement couvre la validation des requêtes, la gestion des bannières de cookies, la capture de page entière, puis l’envoi vers le stockage et le déploiement. Le lecteur y voit à la fois le périmètre qu’il peut implémenter lui-même et le travail qu’il devra gérer en plus. Ce type de documentation explique la technique aux clients potentiels tout en leur donnant les éléments pour juger s’ils doivent l’exploiter eux-mêmes ou le confier à un service spécialisé.

Le fait de publier régulièrement le processus de développement a aussi influencé l’adoption du produit. Orlando Kalossakas, cofondateur du service d’automatisation de tâches par IA Toolhouse, suivait l’activité de Krasun sur X et sur Indie Hackers depuis le début. Il a raconté que ScreenshotOne lui était venu immédiatement à l’esprit lorsqu’il a eu besoin d’une fonction de capture de pages web et qu’il n’avait presque pas ressenti le besoin de comparer d’autres services. C’était le cas d’une personne qui n’avait aucune raison d’acheter sur le moment, qui avait suivi l’évolution du produit et qui l’avait choisi quand son travail l’avait rendu nécessaire.

Lors de l’intégration chez Toolhouse, la documentation et l’écran d’essai ont de nouveau joué un rôle. Kalossakas a fourni la documentation de ScreenshotOne à un outil d’IA pour organiser la procédure d’implémentation et a testé les options dans le tableau de bord. Après l’intégration, les utilisateurs de Toolhouse pouvaient connecter leur propre clé d’accès ScreenshotOne et faire capturer et analyser des pages web par un agent d’IA. La génération d’écrans existante s’est ainsi étendue à l’alimentation d’un service d’IA en supports visuels.

Délimiter ce qu’une seule personne peut exploiter

Même lorsque des gens proposaient de payer, Krasun évaluait le périmètre du produit. Il a testé plusieurs fois une fonction de comparaison de captures dans le temps, mais il a jugé difficile de réduire les erreurs qui interprètent des différences sans importance comme des changements, et estimé que cela relevait plutôt d’un produit distinct. Il n’a pas non plus ajouté de fonction qui parcourt et archive un site web entier, au motif que les besoins des clients et les méthodes d’exploitation varieraient. Il expliquait avoir choisi de se concentrer sur le bon fonctionnement des fonctions existantes.

Dans le processus de vente, comprendre les clients a pris plus de temps que prévu. Dans un entretien de 2026, Krasun a raconté qu’il lui avait fallu deux ans pour cerner à qui il vendait le produit et que cette compréhension avait influencé ses textes promotionnels, ses contenus, ses axes de développement et ses prix. Ensuite, il a examiné par canal d’acquisition comment les visiteurs s’inscrivaient et comment les inscrits devenaient des clients payants. Il expliquait que distinguer le manque de visiteurs des visiteurs qui ne s’inscrivent pas, puis corriger d’abord l’étape où le problème apparaissait, avait aidé le chiffre d’affaires à progresser.

Pour continuer à exploiter le service, Krasun devait aussi réduire ses interventions quotidiennes. Il a raconté qu’en mars 2024, il avait mis en place une carte dédiée aux dépenses de l’entreprise et configuré le versement automatique des règlements sur le compte de paiement de cette carte. Il a mis en place un environnement qui augmente le nombre de serveurs selon le volume de requêtes et préparé un environnement d’exécution de secours sur un autre cloud. Ce travail automatisait les besoins récurrents, comme le règlement des dépenses et l’ajout de serveurs, pour que le service continue de tourner même lorsqu’il s’absentait un moment.

Il a aussi fait appel à une aide extérieure pour les travaux spécialisés. Dans sa présentation officielle actuelle, Krasun explique qu’il développe et exploite le produit lui-même et collabore avec des spécialistes sur certains projets. C’est une méthode d’exploitation centrée sur le fondateur : il garde la direction du produit et la relation avec les clients et ajoute les compétences d’autres personnes aux tâches qui le demandent.

Au moment de l’entretien de mars 2026, ScreenshotOne dépassait 800 clients payants et un revenu récurrent mensuel (MRR) de plus de 25 000 dollars. Les chiffres publiés ensuite pour le quatrième anniversaire du lancement faisaient état de plus de 1 000 clients payants et de 33 000 dollars de revenu récurrent mensuel. Le nombre cumulé d’appels à l’API avait lui aussi dépassé 100 millions. À mesure que la fonction qui transforme les pages web en images s’intégrait au travail quotidien de nombreux produits, l’usage récurrent des clients soutenait l’activité par abonnement.

Dans son bilan du quatrième anniversaire, Krasun a cité comme réussite le fait d’avoir rarement manqué les événements importants de ses enfants. Dans un entretien de cette année-là, il a aussi exprimé l’objectif d’automatiser l’exploitation assez pour partir une semaine en randonnée sans se connecter à internet. Dans une activité qui a rendu à d’autres équipes de développement le temps qu’elles consacraient à un système de capture, obtenir davantage de temps pour lui-même restait désormais la tâche suivante.