Meilleurs outils gratuits pour votre application mobile, août 2026

Des outils gratuits pour préparer, publier et faire connaître une application mobile : compteurs ASO, générateurs de visuels et d’icônes, calculateurs de budget et de rentabilité. Chacun s’exécute à 100 % dans votre navigateur : rien n’est envoyé sur un serveur, rien n’est enregistré.

La collection s’enrichit régulièrement : chaque outil est accompagné d’un guide complet qui explique la méthode, les règles officielles des stores et les erreurs courantes.

Quinze outils, 100 % dans le navigateur

Rien n’est envoyé sur un serveur : ni icône, ni texte de fiche store, ni politique de confidentialité. Le navigateur calcule, vous récupérez le fichier. C’est volontaire. Un porteur de projet n’a pas à déposer son brief dans un outil tiers pour compter 30 caractères de titre App Store.

ASO et stores

Compteur de caractères App Store (titre 30, sous-titre 30, mots-clés 100), analyseur de fiche Play Store, aperçu iPhone, générateur d’icônes 1024, encadreur de captures, QR code de téléchargement, lien intelligent iOS/Android, notes de version. Les limites de caractères sont celles d’Apple et de Google en 2026. Si elles bougent, la revue hebdomadaire de cette page le dira.

Budget et modèle économique

Le calculateur de budget reprend les fourchettes du guide (MVP 15 000 à 40 000 € HT). Le calculateur LTV, CAC et ARPU pose les formules à l’écran : pas de magie, le ratio se lit. Utile avant de signer un devis « acquisition comprise ».

Cadre légal et technique

Générateur de politique de confidentialité (questionnaire RGPD, texte à faire relire), validateur de deep links, générateur de manifest PWA, compresseur d’images. Aucun de ces outils ne remplace un avocat ou un architecte. Ils empêchent de partir d’une page blanche.

Le drip publie les outils restants aux mêmes règles que les villes : 2 000 mots d’éditorial minimum, interface prête, sinon la page reste programmée. Les cartes ci-dessus ne lient que ce qui est déjà en ligne.

Dans quel ordre les utiliser

1. Cahier des charges (Word) et trame budget (Excel), avant tout devis.
2. Calculateur de budget, pour voir si votre Must rentre dans le palier MVP, moyen ou complexe.
3. Calculateur LTV / CAC / ARPU, si le modèle économique est l’objet du projet (marketplace, abonnement, livraison).
4. Compteur ASO et icônes, quand la publication store approche.
5. Politique de confidentialité et deep links, avant la soumission Apple / Google.

Un outil n’est pas un prestataire. Il ne signe pas, il ne recette pas, il ne porte pas la responsabilité du store. Il vous évite d’arriver chez l’agence avec une page blanche. L’agence, elle, se choisit sur les classements ville et sur un CDC que deux structures au moins ont chiffré.

Limites de caractères, revérifiées : App Store titre 30, sous-titre 30, mots-clés 100. Play Store titre 30, description courte 80. Icône Apple 1024×1024. Compte développeur Apple 99 USD/an, Google Play 25 USD une fois. Commissions stores 15 % ou 30 % sur le chiffre d’affaires, pas sur le budget de fabrication.

Atelier de cadrage pour un outil de cadrage

Avant d’écrire à une agence au sujet de un outil de cadrage, tenez l’atelier suivant. Seul, avec un associé, ou avec nous en 30 minutes. L’objectif n’est pas un roman. C’est douze réponses assez nettes pour que deux devis portent sur le même objet.

1. Phrase de vision. « Notre application permet à [cible] de [bénéfice] sans [friction] ». Si elle coince, le projet n’est pas mûr.
2. Trois à cinq objectifs chiffrés, et les non-objectifs. Ce que la V1 ne cherchera pas à faire.
3. Personas : deux à quatre. Désignez le prioritaire. Téléphone, fréquence, situation d’usage.
4. Must / Should / Could / Won’t. Le MVP, c’est la colonne Must. Rien d’autre.
5. Trois à cinq parcours, écran par écran, y compris hors réseau, sans compte, panier vide.
6. Contraintes : stores, langues, pays, hébergement UE, RGPD, EAA, comptes développeur.
7. Back-office : qui administre utilisateurs, contenus, commandes, exports. Souvent 30 à 40 % du budget.
8. Recette : jeux de tests, délai de retour, nombre d’allers-retours, recette stores.
9. Fourchette de budget, affichée. MVP 15 000 à 40 000 € HT, moyenne 40 000 à 120 000 €, complexe 120 000 à 300 000 €.
10. Maintenance : 15 à 20 % par an comme ordre de grandeur, à faire chiffrer à part.

Le détail, avec les captures d’écrans réels, est dans le cahier des charges. La lecture des réponses est dans le guide des devis. Les paliers sont dans le guide des prix. Pour un outil de cadrage, n’inventez pas un cinquième document : remplissez celui-là.

Pièges, toujours les mêmes, aussi pour un outil de cadrage : tout mettre en Must ; spécifier le bouton au lieu du besoin ; oublier le back-office ; taire le budget ; figer le Word comme un contrat alors que les bonnes agences le challengent. Celle qui n’a aucune question n’a pas lu. Celle qui a trop de questions hors cadre n’a pas le même projet que vous.

Ce qui fait rater un cadrage fait trop vite

Les projets qui dérapent, pour un cadrage fait trop vite comme ailleurs, se ressemblent. Ce n’est presque jamais « Flutter ou natif ». C’est un périmètre mou, un devis fusionné, une recette sans fin, et un store découvert à la dernière semaine.

1. Le brief oral

Une visio de 45 minutes, trois agences, trois projets différents dans la tête des commerciaux. Sans Word commun, vous comparez des sacs. Le modèle de ce guide existe pour ça : 12 sections, Must / Should / Could / Won’t, recette. Gratuit, téléchargeable, ou envoyé par e-mail si vous laissez une adresse.

2. Le devis en un poste

« Forfait application : 42 000 € ». On ne sait pas ce qui est dedans. Conception, design, iOS, Android, backend, tests, stores, suivi : six à huit lignes, ou ce n’est pas un devis, c’est une enchère. Le TJM × jours doit retomber sur le total. L’acompte usuel est 30 à 40 % à la commande. TVA 20 % en sus.

3. Le back-office oublié

L’écran que voit l’utilisateur est la partie émergée. Utilisateurs, contenus, commandes, exports, rôles, journaux : 30 à 40 % du budget, souvent. Un CDC qui décrit seulement l’app visible est sous-chiffré par construction. La recette le prouve à la première semaine de production.

4. Les stores comme une formalité

Apple et Google rejettent. Comptes développeur, captures, politique de confidentialité, âge, pays, accessibilité depuis juin 2025, modération dès qu’un humain en voit un autre. Si ce n’est pas dans le CDC, c’est un avenant, collé contre la date de lancement. Les commissions 15 % ou 30 % taxent le chiffre d’affaires, pas le build.

5. La maintenance niée

OS, stores, correctifs, petites évolutions : 15 à 20 % du budget de fabrication par an, ordre de grandeur de ce guide, pas un tarif d’agence. Un devis sans cette ligne vous vend un logiciel qui commence à pourrir le jour de la mise en ligne.

Pour un cadrage fait trop vite, la parade tient en trois objets : un CDC, deux devis sur la même grille, un avis technique de 30 minutes si le périmètre dérape. Téléphone 06 32 64 24 80. Classements Sirene ensuite, pas avant.

Un calendrier réaliste pour un outil utilisé trop tôt

Un MVP se compte en mois. Voici un ordre, pas un engagement de délai. Le devis doit dater les jalons. S’il ne le fait pas, ce n’est pas un planning, c’est un souhait.

1. Semaines 1-2. CDC, personas, Must, parcours. Atelier interne ou 30 minutes d’avis. Modèle Word rempli. Pas une ligne de code.
2. Semaines 3-4. Consultation de deux à quatre structures, même Word, même date limite. Grille de devis. Choix. Contrat, cession de code, comptes stores.
3. Mois 2. Conception, maquettes, architecture, choix de stack argumenté. Recette des maquettes. Gel du Must.
4. Mois 3-4. Développement du Must, backend, back-office. Environnements. Jeux de tests. Pas de Could qui se glisse.
5. Mois 5. Recette interne, allers-retours prévus au contrat, correctifs. Préparation des fiches stores, politique de confidentialité, captures.
6. Mois 6. Soumission Apple et Google, rejets possibles, resoumission. Lancement. Début de la maintenance (15 à 20 % par an comme ordre de grandeur).

Un devis « six semaines tout compris, deux stores, paiement, back-office » a oublié la recette stores, les comptes, ou les deux. Un devis « dix-huit mois pour trois écrans » n’a pas lu le Must. Le calendrier suit le CDC, pas l’inverse.

Pour un outil utilisé trop tôt, gardez ce calendrier comme question aux agences : « datez ces six jalons, ou dites lequel disparaît si on coupe le Could ». La réponse renseigne plus que le total en euros.

Les comptes développeur se créent tôt : Apple peut prendre plusieurs jours, Google est plus rapide mais la fiche se prépare. Les permissions (GPS, caméra, notifs) se testent sur appareil réel, pas seulement sur simulateur. La politique de confidentialité se rédige avant la soumission, pas après un rejet. Tout ça tient dans le CDC, section contraintes et section recette.

Si le Must ne tient pas dans six mois, ce n’est plus un MVP. Recoupez. La colonne Won’t existe pour ça. Un lancement tardif avec un Must trop gras coûte plus cher qu’un lancement à date avec un Must honnête, puis une V1.1 financée par la maintenance.