Le problème : 20 applications, 20 marques, des centaines de screenshots

Il y a quelques années, je travaillais comme développeur dans une startup où nous construisions une application mobile whitelabel. Une seule base de code, mais 20 clients différents — chacun avec sa propre identité visuelle, ses couleurs, ses logos, et ses fiches App Store. Chacun d'entre eux avait besoin de son propre ensemble de screenshots soignés pour l'App Store et Google Play.

Si vous avez déjà publié une application, vous connaissez la routine : Apple veut des screenshots pour chaque taille d'appareil (6.7', 6.5', 5.5', iPad Pro, iPad...), Google Play veut son propre set, et si vous supportez plusieurs langues, multipliez tout à nouveau. Maintenant multipliez ça par 20 clients.

On parle de milliers de screenshots à générer, encadrés dans des maquettes d'appareils, brandés avec les bonnes couleurs, et uploadés — à chaque cycle de release.

Ce que nous avions : des screenshots automatisés dans le pipeline

Les screenshots bruts eux-mêmes n'étaient pas le problème. Nous avions résolu cette partie. Nos tests UI, s'exécutant dans notre pipeline GitLab CI, lançaient chaque variante de l'application, naviguaient dans les écrans clés, et capturaient des screenshots automatiquement. snapshot de Fastlane (iOS) et screengrab (Android) géraient la partie lourde.

Nous avions donc des centaines de fichiers PNG bruts qui atterrissaient dans nos artefacts de pipeline après chaque build. Super. Mais les screenshots bruts ne vont pas sur l'App Store. Ils doivent être traités — placés dans des cadres d'appareils, dotés d'un arrière-plan correspondant à la marque du client, surmontés de textes marketing, et exportés aux dimensions exactes en pixels requises par chaque store.

Les points de douleur

1. Le goulot d'étranglement du designer

Notre designer était talentueux, mais lui demander de mettre à jour manuellement les fichiers Figma pour 20 marques à chaque release était absurde. Il passait des jours à simplement échanger les screenshots et ajuster les couleurs. Et si un client changeait son identité visuelle en milieu de cycle ? Tout reprendre à zéro.

2. Pas le temps de construire des outils internes

Nous étions une startup. Chaque sprint était chargé de fonctionnalités, de corrections de bugs et de demandes clients. Construire un service interne de traitement de screenshots — avec un système de templates, le rendu de cadres d'appareils, la superposition de texte, et l'export spécifique au store — était un projet de plusieurs mois que nous ne pouvions tout simplement pas justifier. Nous devions livrer du produit, pas des outils.

3. Du travail manuel qui ne passait pas à l'échelle

Pendant un moment, nous avons essayé une approche semi-manuelle : le designer créait des templates, un script les traitait en lot, et quelqu'un vérifiait et uploadait manuellement. Mais ça cassait constamment. Une police serait mauvaise, un cadre ne s'alignait pas, le texte débordait en allemand mais semblait correct en anglais. Chaque cas limite devenait une urgence.

4. L'intégration dans le pipeline était la pièce manquante

Nous voulions un flux entièrement automatisé : le code est poussé, le pipeline exécute les tests, les screenshots sont capturés, les screenshots sont traités avec le bon branding, et Fastlane les uploade vers les stores. La pièce manquante était toujours l'étape de traitement. Il n'existait aucun service qu'on pouvait simplement appeler depuis notre pipeline CI avec une API.

Comment nous avons résolu le problème

Cette frustration est exactement pourquoi Screenshots Live existe. L'idée était simple : un service de traitement qui prend des screenshots bruts, applique des templates créés par des designers avec des cadres d'appareils et du branding, et retourne des images prêtes pour les stores — tout via un simple appel API qui s'intègre dans n'importe quel pipeline CI/CD.

L'intégration GitLab + Fastlane

Voici à quoi ressemblait notre pipeline après l'intégration de Screenshots Live :

Étape Build & Test : GitLab CI build l'application pour chaque variante whitelabel. Les tests UI s'exécutent et capturent des screenshots bruts avec Fastlane snapshot / screengrab.
Étape Traitement des Screenshots : Un simple script boucle sur les screenshots capturés, appelle Screenshots Live avec le bon ID de template et les paramètres de branding pour chaque client, et télécharge les images traitées.
Étape Upload : Fastlane deliver (iOS) et supply (Android) uploadent les screenshots traités vers les stores respectifs.

L'ensemble du flux — du push de code aux screenshots prêts pour les stores — est devenu entièrement automatisé. Pas d'implication du designer pour les releases de routine. Pas de QA manuelle des mises en page de screenshots. Pas d'urgences quand un client demandait une release de hotfix à 17h un vendredi.

Ce qui a changé

Gain de temps

Ce qui prenait 2 à 3 jours à notre designer par cycle de release prend maintenant zéro temps humain. Le pipeline gère tout. Pour 20 applications se releasant toutes les deux semaines, c'est environ 40 à 60 jours-designer économisés par an — du temps que notre designer pouvait consacrer à la vraie conception de produit plutôt qu'à l'assemblage répétitif de screenshots.

Cohérence

Chaque screenshot, pour chaque client, pour chaque taille d'appareil, suit exactement le même template. Plus de problèmes du type « la version iPhone 15 Pro Max a le texte légèrement mal aligné ». Les templates sont parfaits au pixel près, et ils sont appliqués de manière cohérente à chaque fois.

Indépendance du designer

Notre designer pouvait mettre à jour les templates quand il le voulait — nouveaux cadres d'appareils, textes marketing mis à jour, designs saisonniers — sans avoir besoin d'implication des développeurs. Il mettait à jour le template dans l'éditeur visuel, et le prochain run du pipeline le récupérait automatiquement.

Onboarding de nouveaux clients

Ajouter un nouveau client whitelabel est passé de « planifier 2 jours de travail de design » à « créer une nouvelle variante de template avec leurs couleurs et logo ». Le pipeline s'occupait du reste.

Pourquoi nous le rendons disponible

Après l'avoir utilisé en interne et avoir vu combien de temps il économisait, nous avons réalisé que ce n'était pas un problème unique. Chaque développeur d'application qui publie sur l'App Store ou Google Play fait face à la génération de screenshots. Les développeurs whitelabel en souffrent le plus, mais même une équipe mono-app avec support multi-langues fait face au même problème de multiplication.

Nous l'avons donc nettoyé, construit une vraie API avec de la documentation, ajouté un éditeur de templates que les non-développeurs peuvent utiliser, et l'avons ouvert. Si vous passez des heures à créer manuellement des screenshots App Store, ou si votre pipeline a un manque entre « capturer les screenshots » et « uploader vers le store », Screenshots Live comble ce manque.

Nous l'avons construit parce que nous en avions besoin. Nous le partageons parce que nous savons que vous en avez besoin aussi.