Coût de la CI/CD mobile : mise en place et exploitation

La CI/CD mobile est généralement vendue sur la vitesse et la qualité. Mais quand un CTO ou un product owner demande un budget, les questions deviennent concrètes : combien coûtera la mise en place, combien coûtera-t-elle chaque mois, et à partir de quand sera-t-elle rentable ?

Ce guide décompose les coûts d’une CI/CD mobile en leurs véritables composantes (effort de mise en place, infrastructure de build, services de test et maintenance), avec des calculs simples que vous pourrez adapter à votre propre équipe.

Les principaux facteurs de coût d’une CI/CD mobile

Il existe quatre grands postes de coût. La plupart des équipes estiment les deux premiers et oublient les deux derniers.

1. L’effort de mise en place initial

Le temps d’ingénierie nécessaire pour concevoir et construire le pipeline dépend du périmètre et de l’état du projet existant.

Pipeline de base

Périmètre : une plateforme, build à chaque pull request, tests unitaires, distribution aux testeurs internes.
Effort type : 20 à 40 heures.
Adapté à : produits en phase de lancement, MVP, applications sur une seule plateforme.

Pipeline standard

Périmètre : Android et iOS, signature de code automatisée, tests unitaires, analyse statique, TestFlight et canaux de test Play, versioning automatique.
Effort type : 40 à 80 heures.
Adapté à : la plupart des équipes produit en croissance.

Pipeline avancé

Périmètre : tout ce qui précède, plus les tests d’interface sur fermes d’appareils, l’automatisation des métadonnées et des captures d’écran des stores, les déploiements progressifs, l’analyse de sécurité, les validations de publication et la piste d’audit.
Effort type : 80 à 160 heures.
Adapté à : la fintech, la santé et les autres applications réglementées ou à fort trafic.

Ce sont des fourchettes types, pas des devis. Un projet dont les builds locaux sont cassés, dont les dépendances sont obsolètes ou dont les clés de signature ont été perdues peut demander beaucoup de temps supplémentaire avant même que l’automatisation commence.

2. L’infrastructure de build

Les minutes de build sont le coût d’exploitation le plus visible, et macOS en représente l’essentiel. Sur GitHub Actions, après le changement de tarifs de janvier 2026, les runners hébergés standard coûtent :

Linux : 0,006 $ la minute
Windows : 0,010 $ la minute
macOS (standard) : 0,062 $ la minute

Les autres fournisseurs spécialisés dans le mobile utilisent une tarification à crédits ou par forfait, mais la logique est partout la même : c’est le temps Mac qui coûte cher.

Exemple de calcul

Prenons une équipe de cinq développeurs qui génère environ 15 exécutions de pipeline par jour ouvré, sur 22 jours ouvrés par mois :

Plateforme	Minutes par exécution	Exécutions par mois	Total des minutes	Tarif	Coût mensuel
Android (Linux)	10	330	3 300	0,006 $	~20 $
iOS (macOS)	15	330	4 950	0,062 $	~307 $

Les minutes incluses dans les forfaits réduisent encore ce montant, mais notez que sur GitHub, les minutes macOS consomment le quota inclus avec un multiplicateur bien plus élevé que les minutes Linux. La leçon est claire : optimiser la durée du pipeline iOS a un impact financier environ dix fois supérieur à celui de l’optimisation du pipeline Android.

3. Les services de test

Les tests unitaires s’exécutent sur les machines de build standard. Les tests d’interface sur appareils réels nécessitent en général une ferme d’appareils comme Firebase Test Lab, BrowserStack ou AWS Device Farm. Les coûts dépendent du nombre d’appareils et de la durée des tests, c’est pourquoi la plupart des équipes :

Lancent une courte suite de smoke tests sur émulateurs ou simulateurs à chaque pull request.
Lancent la suite complète sur appareils réels chaque nuit ou avant les publications.
Choisissent une matrice d’appareils d’après les analytics réelles de leurs utilisateurs, et non en prenant tous les appareils disponibles.

4. La maintenance

Un pipeline est un logiciel, et un logiciel demande de la maintenance. Les tâches récurrentes typiques sont :

Les exigences annuelles des plateformes : depuis le 28 avril 2026, App Store Connect n’accepte que les builds réalisés avec Xcode 26 ou une version ultérieure ; à partir du 31 août 2026, Google Play exige que les nouvelles applications et les mises à jour ciblent Android 16 (niveau d’API 36).
Le renouvellement des certificats et des profils pour la distribution iOS.
Les mises à jour des dépendances et de la chaîne d’outils pour Gradle, Kotlin, CocoaPods, Flutter ou React Native.
La correction des tests instables, qui érodent discrètement la confiance dans le pipeline si on les ignore.

Pour un pipeline standard, une estimation raisonnable est de quelques heures par mois, avec des pics lors des changements annuels de chaîne d’outils chez Apple et Google.

Runners cloud ou Mac auto-hébergés

Critère	Runners cloud	Mac auto-hébergés
Coût initial	Aucun	Achat du matériel
Coût d’exploitation	À la minute ou au forfait	Électricité, hébergement, réseau
Maintenance	Le fournisseur gère les images	Votre équipe gère les mises à jour de Xcode, de l’OS et de sécurité
Scalabilité	Élastique	Limitée par le nombre de machines
Idéal pour	La plupart des petites et moyennes équipes	Un volume de builds iOS élevé et régulier

Comment réduire les coûts d’une CI/CD mobile

Misez à fond sur le cache : le cache de build Gradle et les caches CocoaPods et Swift Package Manager peuvent réduire sensiblement les temps de build.
N’exécutez que ce qui a changé : sautez les builds iOS quand une pull request ne touche que du code Android, et inversement.
Sortez le travail de macOS : exécutez le linting, les tests du code partagé et les contrôles backend sous Linux.
Hiérarchisez vos tests : contrôles rapides à chaque commit, suites complètes chaque nuit et avant les publications.
Annulez les exécutions obsolètes : quand un développeur pousse à nouveau, arrêtez le pipeline précédent de cette branche.

À partir de quand la CI/CD est-elle rentable ?

Comparez le coût du pipeline à ce que vous coûtent déjà les publications manuelles. Si une publication manuelle prend une demi-journée à un développeur senior et que vous publiez chaque semaine, cela représente environ deux jours-développeur par mois consacrés à un travail mécanique, sans compter les publications ratées, les certificats expirés ou les bugs passés entre les mailles du filet parce que des tests ont été sautés. Pour la plupart des produits actifs, un pipeline standard est rentabilisé dès les premiers mois.

Mobian pour une CI/CD mobile rentable

Chez Mobian, nous dimensionnons les pipelines selon le stade du produit. Pour un MVP, nous mettons en place le minimum qui élimine le risque de publication ; pour les applications réglementées de fintech et de santé, nous ajoutons l’analyse de sécurité, les validations et les pistes d’audit. Nous optimisons les temps de build dès le départ, car en CI mobile, la facture macOS est le poste qui augmente le plus vite.

À titre de référence, sur un projet fintech récent, le premier pipeline SDK au vert a pris 23,7 minutes à froid et environ 1 minute une fois les caches chauds, et le pipeline complet de builds de test de l’application principale s’exécute en moins de 6 minutes sur un seul runner macOS partagé. Que vous partiez de zéro ou que vous héritiez d’un pipeline que personne ne comprend entièrement, nous pouvons auditer la configuration actuelle, estimer des coûts réalistes et la mettre en œuvre sur la plateforme adaptée à votre équipe.

Conclusion

Les coûts d’une CI/CD mobile se répartissent en quatre postes : mise en place, infrastructure de build, services de test et maintenance. Les minutes de build sont visibles, mais ce sont la maintenance et l’usage de macOS qui réservent généralement des surprises aux équipes. Avec un pipeline dimensionné selon votre stade et optimisé autour du temps macOS, l’automatisation devient l’un des investissements les moins coûteux de votre produit mobile, et l’un des plus vite rentabilisés.

Questions fréquentes

Combien coûte la mise en place d’une CI/CD mobile ?

Le coût de mise en place dépend surtout du périmètre. Un pipeline de base sur une seule plateforme (build, tests unitaires, distribution interne) représente généralement 20 à 40 heures d’ingénierie. Une configuration complète sur les deux plateformes, avec signature automatisée, tests d’interface et publications progressives sur les stores, prend en général 80 à 160 heures. Les projets legacy dont les builds sont cassés ou dont les éléments de signature ont été perdus demandent plus de temps.

Pourquoi les builds iOS coûtent-ils plus cher que les builds Android ?

Les applications iOS ne peuvent être compilées que sous macOS, et les machines de build Mac coûtent plus cher à fournir. Sur GitHub Actions, par exemple, les runners macOS standard coûtent 0,062 $ la minute, contre 0,006 $ la minute pour Linux, soit environ dix fois plus. Les builds iOS sont aussi souvent plus lents, ce qui accentue l’écart.

Quels sont les coûts récurrents d’une CI/CD mobile ?

Les coûts récurrents comprennent les minutes de build ou le matériel, les services de test sur appareils si vous en utilisez, et le temps de maintenance : mise à jour des versions de Xcode et de Gradle, renouvellement des certificats, correction des tests instables et adaptation aux exigences annuelles d’Apple et de Google. La maintenance est souvent le coût que les équipes oublient de budgéter.

Héberger soi-même ses machines de build Mac revient-il moins cher ?

Cela peut être le cas avec de gros volumes de builds, car vous payez le matériel une fois au lieu de payer à la minute. Mais l’auto-hébergement ajoute de la maintenance, une responsabilité en matière de sécurité et un risque matériel. Pour la plupart des petites et moyennes équipes, des runners cloud avec un pipeline bien optimisé reviennent moins cher en coût total.

Comment réduire les coûts d’une CI/CD mobile ?

Les plus grosses économies viennent du fait de lancer moins souvent les jobs coûteux : mettez les dépendances en cache, n’exécutez que les tests concernés sur les pull requests, réservez les suites complètes de tests d’interface aux builds nocturnes ou de publication, exécutez les contrôles Android et partagés sous Linux, et évitez de compiler iOS pour des modifications qui ne touchent pas l’application iOS.

Coût de la CI/CD mobile : ce qu’il faut vraiment pour automatiser vos publications Android et iOS