Créer une application Android avec l'IA : ce qu'on obtient
Créer une application Android avec l'IA : ce qu'on obtient
L'IA construit une application web : elle s'ouvre par un lien dans le navigateur du téléphone, s'ajoute à l'écran d'accueil en une pression et se comporte comme n'importe quelle autre application. Ce qui n'apparaît pas par ce chemin, c'est un fichier APK pour le Google Play, qui exige un compte développeur et une démarche à part. Dans la plupart des usages personne ne voit la différence, et voici quand elle se voit.
Que veut dire au juste «une application Android» ?
La phrase est la même, mais trois besoins distincts se cachent derrière, et les confondre coûte des semaines.
Le premier : quelqu'un veut un outil que lui et quelques proches utiliseront depuis leur téléphone. Suivi des dépenses, liste de tâches, fichier clients, un calculateur propre à son métier, un mémo interne pour l'équipe. La boutique ne joue aucun rôle ici, il faut simplement quelque chose qui marche par un lien.
Le deuxième : quelqu'un veut figurer sur le Google Play parce que c'est ainsi que des inconnus le trouveront. Cela ne relève pas de la construction mais de la distribution, et se règle indépendamment de qui a écrit le code.
Le troisième : quelqu'un a besoin de ce qui n'existe qu'en natif. Fonctionnement complet hors connexion, traitements en arrière-plan, intégration profonde au système, graphismes tridimensionnels lourds.
L'IA règle le premier entièrement, le deuxième à moitié et par des étapes supplémentaires, le troisième pas du tout. Les textes qui promettent «votre application Android en une phrase» sans poser cette limite promettent à votre place une chose dont ils ne répondent pas.
Application web et APK : ce qui change en pratique
La comparaison ne porte pas sur la technique, mais sur ce que vous constaterez comme responsable et ce que constatera la personne qui s'en sert.
| Ce qu'on compare | Application web par lien | Application native du Google Play |
|---|---|---|
| Comment elle arrive aux gens | un lien en messagerie, s'ouvre aussitôt | recherche dans la boutique, installation, mises à jour |
| Icône sur l'écran d'accueil | oui, depuis le menu du navigateur | oui, par l'installation |
| De l'idée au fonctionnel | des heures | des semaines plus l'examen de la boutique |
| Compte développeur | inutile | obligatoire, payant, avec vérification |
| Mettre à jour | vous modifiez, tout le monde l'a déjà | compiler, publier, attendre l'examen |
| Hors connexion | limité | complet |
| Caméra, notifications, paiement | accessibles via le navigateur, avec des réserves | pleinement accessibles |
| À qui cela convient | outil pour soi, son équipe, ses clients | produit pour un public large et inconnu |
La ligne à relire est la troisième. La différence ne tient pas à la qualité du résultat, mais au fait qu'un chemin se mesure en heures et l'autre en semaines, et que le second commence par de la paperasse, pas par du code.
Comment procéder, étape par étape ?
Tout se passe dans le navigateur, le chemin est donc identique depuis un ordinateur et depuis un téléphone.
- Ouvrez zugo.dev et connectez-vous avec Google ou GitHub. Les crédits de départ apparaissent immédiatement et aucune carte n'est demandée.
- Décrivez l'application en langage ordinaire. Pas un cahier des charges, mais comme vous l'expliqueriez à un collègue : qui l'utilise, ce qu'il voit sur le premier écran, ce qui doit être conservé entre deux visites.
- Attendez la construction. La vérification se fait en exécutant réellement l'application dans un environnement isolé, pas en regardant si elle a l'air terminée.
- Ouvrez l'aperçu et servez-vous en comme un vrai utilisateur. Remplissez le formulaire, appuyez au mauvais endroit, rechargez la page et vérifiez que vos données sont toujours là.
- Corrigez en écrivant le message suivant : «ajoute une recherche au-dessus de la liste», «la suppression doit demander confirmation», «la date doit être préremplie au jour du jour».
- Publiez. L'application reçoit une adresse qui s'ouvre sur n'importe quel téléphone.
- Sur le téléphone, ouvrez cette adresse et choisissez «Ajouter à l'écran d'accueil» dans le menu du navigateur. Une icône apparaît, et le lancement ouvre l'application sans barre d'adresse.
L'étape sept est précisément ce que la plupart des gens cherchent en posant la question d'Android. Après elle, distinguer le résultat d'une application installée est presque impossible à l'oeil nu.
Comment formuler pour que la première version tombe plus juste ?
Presque tout l'écart entre «c'était bon du premier coup» et «je refais depuis quatre heures» se joue dans le premier message. Trois choses le portent.
Dites qui utilise l'application et ce qui se passe sur le premier écran. «Une application de dépenses» est un sujet, pas une commande. «J'ouvre, je vois un champ montant et une liste de catégories, je saisis le montant, je choisis la catégorie et la ligne apparaît dans la liste du jour» est une commande.
Dites ce qui doit être conservé. C'est le point le plus coûteux à changer ensuite. Si les saisies doivent survivre à la fermeture de l'onglet et que chacun voit les siennes, dites-le dès le début : cela se construit sur une autre base. À quoi ressemble cette base est expliqué dans l'IA peut-elle créer une app avec base de données.
Dites ce qui ne doit pas exister. Une contrainte fait gagner plus de temps qu'une exigence. «Sans inscription, accès par lien» ou «une seule page, sans menu» coupent des branches entières de décisions qu'il faudrait sinon défaire.
Ce qui n'aide pas, c'est un cahier des charges d'une page. Vingt exigences dans un seul message donnent une version où la moitié est traitée approximativement, et démêler cela prend plus de temps que d'ajouter les mêmes vingt points un par un.
Peut-on la publier sur le Google Play ?
Oui, et il vaut mieux dire clairement que c'est un projet distinct.
Une application web peut être empaquetée et soumise comme une autre. Cela demande un compte développeur avec des frais uniques et une vérification d'identité, et pour les nouveaux comptes Google ajoute un test fermé : plusieurs testeurs doivent utiliser l'application plusieurs jours d'affilée avant la publication. Viennent ensuite la fiche de la boutique, les icônes, les captures et une politique de confidentialité.
Rien de cela n'est de la construction. C'est de la distribution et de l'administratif, et cela prend au minimum une semaine. L'ordre raisonnable est de diffuser d'abord le lien, de vérifier que les gens s'en servent vraiment, et seulement ensuite de décider si la fiche vaut cette semaine.
Quelles applications réussissent et lesquelles non ?
Réussissent bien celles qui sont au fond des formulaires, des listes et des règles entre les deux : suivi des dépenses, fichier clients, prise de rendez-vous, liste de contrôle de poste, calculateurs internes, collecte de demandes, catalogue avec filtre, un CRM simple.
Réussissent moyennement celles qui demandent plusieurs rôles aux droits différents, des validations ou des rapports par segments. Elles se construisent, mais le premier résultat est une base, et la mise au point dure plus longtemps que la construction.
Réussissent mal celles qui dépendent du matériel du téléphone : fonctionnement continu hors connexion, synchronisation en arrière-plan, traitement vidéo sur l'appareil, graphismes tridimensionnels lourds.
Et si le code me revient plus tard ?
Cette question se pose au début, pas à la fin. Beaucoup de constructeurs ne livrent le résultat qu'à l'intérieur de leur plateforme : tant que vous payez, cela tourne, et l'emporter est impossible.
Ici le code part dans votre propre dépôt GitHub, et ensuite il est à vous : le lire, le modifier à la main, le confier à un développeur ou l'héberger ailleurs. Le détail se trouve dans peut-on exporter le code d'un générateur avec IA.
L'intérêt pratique n'est pas idéologique. Une application faite en une soirée cesse d'être une impasse : quand dans six mois surgira quelque chose que le constructeur ne sait pas faire, vous remettrez un projet qui tourne au lieu de repartir de zéro.
Combien cela coûte-t-il ?
Les crédits de départ sont de 2400 et ne demandent pas de carte. Une construction ordinaire coûte environ 600 crédits, une correction environ 300. Cet «environ» n'est pas de la prudence mais de la précision : ce qui est décompté, c'est la dépense réelle du modèle sur votre tâche, si bien qu'une correction courte revient moins cher qu'une longue. Quand les crédits de départ ne suffisent plus, il existe l'abonnement Pro à $25 par mois avec 20000 crédits.
Publier sur une adresse ne coûte rien de plus. Le compte développeur du Google Play, si vous finissez par aller en boutique, se paie directement à Google et n'a rien à voir avec la construction.
En bref
L'IA vous donne en une soirée une application qui fonctionne par un lien, pas un fichier pour le Google Play. Pour un outil utilisé par vous, votre équipe ou vos clients, cela suffit entièrement : l'icône arrive sur l'écran d'accueil depuis le navigateur, et l'utilisateur ne voit pas la différence. La boutique reste une tâche à part, faite de distribution et de formalités, et il est sensé de s'y attaquer une fois que des gens utilisent déjà l'application. Tout ce qui dépend du matériel du téléphone reste hors de ce chemin, et c'est une limite raisonnable, pas un défaut.