Créer une application mobile avec l’IA : choisir entre web, Android et iPhone

Une application utilisable sur téléphone n’a pas forcément besoin d’un passage par les stores. Voici comment choisir son format, décrire un premier parcours et préparer un essai sur les vrais appareils de vos utilisateurs.

Vous voulez créer une application mobile avec l’IA. Avant de demander des écrans à un assistant, choisissez comment les gens vont l’ouvrir. Un lien reçu par message, une icône installée depuis le navigateur et une application distribuée dans un store impliquent des travaux différents. Le bon choix dépend de l’usage, du téléphone et de ce que vous devrez maintenir après la première version.

Prenons un cas fictif : Nora coordonne les visites d’une petite association. Trois bénévoles consultent une adresse, ajoutent une note et signalent une visite terminée. Ils utilisent des téléphones différents. Ce guide déroule les décisions de Nora ; il fournit un protocole à essayer, pas le compte rendu d’une application déjà déployée.

Commencer par les conditions d’utilisation

Demandez à deux futurs utilisateurs de vous montrer leur téléphone et leur dernier trajet. Ont-ils du réseau ? Peuvent-ils ouvrir un lien facilement ? Doivent-ils prendre des photos ? Utilisent-ils un appareil personnel ou partagé ? L’application sera-t-elle ouverte chaque jour ou une fois par trimestre ? Notez les réponses, sans transformer chaque possibilité en exigence.

Pour Nora, consulter les visites et saisir une note suffisent au premier essai. Le suivi de position en continu et les notifications ne sont pas nécessaires. Elle choisit donc d’abord une application web adaptée au téléphone. Si l’essai révèle une contrainte que le navigateur ne couvre pas correctement sur les appareils concernés, elle réexaminera le format.

Vous pouvez suivre le même raisonnement avec un artisan, un club ou un petit SaaS. Une fonction indispensable doit être testée tôt : par exemple, scanner une étiquette avec un appareil ancien. Une fonction seulement agréable peut attendre. Cela évite de découvrir une incompatibilité après avoir fait dessiner toute l’interface.

Trois formats qui ne se remplacent pas toujours

Une application web responsive s’ouvre par une adresse et adapte son affichage à la largeur de l’écran. Elle reste simple à partager. Elle peut cependant être pénible si les boutons sont trop petits, si le clavier masque la validation ou si les formulaires oublient ce que vous venez de saisir. « Responsive » décrit une adaptation de mise en page, pas une preuve de confort.

Une PWA ajoute à une application web des possibilités d’installation et, si elles sont développées, de fonctionnement avec une connexion dégradée. Les conditions dépendent des navigateurs et des systèmes. MDN présente ces capacités ; le guide PWA du journal détaille les vérifications. Une icône installée ne garantit pas que les données restent accessibles hors ligne.

Une application native ou multiplateforme distribuée dans les stores ajoute une chaîne de préparation, de signature, de soumission et de mise à jour. Elle peut être appropriée quand certaines fonctions du téléphone ou les habitudes de distribution l’exigent. Le générateur de code ne remplace ni les comptes éditeurs ni les conditions de publication. Consultez les étapes Apple et la préparation Android avant d’annoncer une date.

• Choisissez un premier essai web si l’utilisateur accomplit l’action utile avec un lien et une connexion normale.
• Explorez une PWA si l’installation ou un usage avec réseau intermittent apporte une valeur vérifiable.
• Étudiez une application distribuée dans les stores si une contrainte observée le justifie, avec une personne capable d’accompagner sa publication et sa maintenance.

Pour comprendre · illustration du guide

Décrire quatre écrans plutôt que toute une plateforme

Nora prépare quatre vues : les visites du jour, le détail d’une visite, la saisie d’une note et la confirmation. Elle écrit pour chacune l’information indispensable et l’action principale. Le détail contient une adresse et une consigne. Il ne contient pas toutes les informations historiques de l’association. Le bénévole doit comprendre où aller et quoi faire.

Le dernier écran mérite autant de soin que le premier. Une note saisie peut être enregistrée sur le téléphone, envoyée au serveur ou encore en attente. Affichez le bon état. Dans le premier périmètre de Nora, l’enregistrement exige une connexion : la page indique clairement un échec et conserve le texte pour réessayer. Elle ne montre jamais « Visite terminée » sur la seule base d’un clic.

Écrivez aussi les états moins séduisants : aucune visite aujourd’hui, dossier retiré, accès expiré, note trop longue, pièce jointe refusée. Votre assistant peut produire une belle liste avec des données imaginaires sans avoir prévu ces situations. Les décrire avant la construction rend les corrections plus simples et les essais plus courts.

Donner un brief que l’IA peut faire vérifier

Évitez « Fais-moi une application mobile moderne ». Donnez le public, les quatre écrans, les informations fictives de départ et les règles de réussite. Demandez une première livraison limitée à un parcours. Faites expliquer où les données sont enregistrées et ce qui reste simulé. Vous gardez ainsi la possibilité de refuser une fausse confirmation derrière une jolie animation.

Pour Nora, une consigne utile serait : « Sur un écran étroit, affiche trois visites fictives. En ouvrant une visite, je peux rédiger une note. La confirmation doit dépendre de l’enregistrement effectif. Si celui-ci échoue, garde mon texte et propose une nouvelle tentative. Liste les étapes qui nécessitent un service extérieur. » Aucun nom d’outil ne dispense de cette précision.

Dans Maestro, vous pouvez commencer par décrire ce besoin, puis relire le plan et les tâches proposés avant de construire. Le produit n’est pas présenté ici comme un bouton de publication automatique vers l’App Store ou Google Play. Le parcours de livraison dépend du projet, de ses services et du format choisi.

Préparer le premier essai sans données sensibles

Créez trois dossiers inventés et deux comptes de test autorisés. Préparez un téléphone Android et un iPhone représentatifs des utilisateurs visés lorsque les deux publics comptent. Un aperçu réduit sur ordinateur aide à détecter un débordement, mais il ne reproduit pas tout : clavier virtuel, autorisations photo, interruption par un appel ou comportement d’installation.

Faites accomplir le parcours sans commenter chaque écran. Notez où la personne hésite et le texte qu’elle interprète mal. Demandez-lui ensuite où elle pense que sa note se trouve. Si elle répond « sur le téléphone » alors que la note a été partagée avec toute l’équipe, le problème porte aussi sur la compréhension du service.

• Ouvrir une visite depuis le lien reçu : le dossier correct apparaît sans recherche supplémentaire.
• Saisir une note avec le clavier affiché : le bouton reste atteignable et la saisie ne disparaît pas.
• Fermer puis rouvrir : une note confirmée se retrouve dans le même dossier.
• Couper la connexion avant validation : un état explicite remplace toute confirmation trompeuse.
• Retirer l’accès au compte : le dossier ne reste pas accessible par son ancienne adresse.

Organiser la publication comme une étape séparée

Pour une application web, préparez une adresse de production, une configuration de données séparée de vos essais et un moyen de revenir à une version précédente. Vérifiez les courriels, les liens de connexion et les fichiers depuis cette adresse. Une application qui fonctionne uniquement dans l’environnement de construction n’est pas encore celle que vos utilisateurs vont ouvrir.

Pour les stores, prévoyez les comptes, les informations demandées, les captures fidèles à la version envoyée et les éléments nécessaires à son examen. La présence dans un store n’efface pas les responsabilités de l’exploitant. L’examen et ses délais ne doivent pas être confondus avec le temps nécessaire à produire le code.

Ne choisissez pas une distribution uniquement parce qu’elle paraît plus sérieuse. Nora gagne d’abord à observer si les bénévoles terminent une visite sans assistance. Le besoin d’installation pourra être réel ensuite. Le format retenu doit résoudre une difficulté identifiable, pas ajouter un travail de publication à une utilisation encore incertaine.

Penser aux changements après le premier lancement

Une application mobile vit sur plusieurs appareils et parfois plusieurs versions. Décidez ce que vous faites si une personne garde une ancienne version : le service continue-t-il à accepter ses notes ? Affiche-t-il une demande de mise à jour ? Une évolution du format des données peut toucher des utilisateurs qui n’ont pas encore rouvert l’application.

Dans l’exemple de Nora, ajouter un champ obligatoire « résultat de la visite » peut empêcher l’envoi d’une ancienne note. Une meilleure évolution explique la nouvelle règle et prévoit le traitement des notes déjà en cours. Cette situation doit figurer dans la fiche de livraison, même si elle ne se voit pas dans une capture.

Gardez un petit registre des appareils essayés, des problèmes observés et de la version correspondante. Ne promettez pas « compatible avec tous les téléphones » après un seul test. Une liste précise de conditions vérifiées vous aide à décider où concentrer les corrections.

Votre prochaine action

Ouvrez la fiche de choix et d’essai mobile. Remplacez le cas de Nora par une seule action de votre public, puis complétez les contraintes de téléphone, de réseau et de partage. Vous pouvez commencer avec ces quelques réponses avant de choisir votre outil de création.

Si le résultat utile tient dans un navigateur, construisez ce parcours et essayez-le. Si une capacité indispensable manque, documentez le blocage avant de changer de format. La décision devient alors un choix fondé sur un usage, avec une preuve à produire, plutôt qu’une préférence pour le mot « application ».