Créer une application mobile pour une PME commence par une tâche à rendre possible, pas par le choix d’un framework. Consulter un dossier sur un téléphone, saisir une intervention sans réseau et recevoir une alerte sont des besoins différents. Ils ne demandent pas nécessairement la même solution.
Avant de comparer les propositions, décrivez les utilisateurs, leurs appareils, les données nécessaires et le résultat attendu. Une interface qui ressemble à une application ne prouve ni son fonctionnement hors ligne ni sa compatibilité avec votre matériel.
1. Décrire une tâche sur le terrain
Choisissez un parcours concret, du début à la confirmation. Qui l’effectue, dans quelles conditions et avec quelles informations ? Notez les interruptions habituelles : réseau instable, appareil partagé, document manquant ou validation par un responsable. La première version doit couvrir un besoin suffisamment précis pour être testée.
Exemple fictif. Une équipe prépare des comptes rendus d’intervention. Un technicien ouvre un dossier autorisé, saisit une observation neutre et retrouve son compte rendu après reconnexion. Ce n’est pas un cas client et aucun gain de temps n’est annoncé. L’exercice sert à définir les états qui devront être visibles.
Ne confondez pas le résultat de cette tâche avec les fonctions disponibles. Une caméra accessible n’assure pas que la photo rejoint le bon dossier. Un bouton « Envoyer » ne confirme pas que le serveur a reçu le compte rendu. Pour chaque étape, définissez une preuve consultable par le rôle concerné.
2. Vérifier appareils, droits et fonctions nécessaires
Établissez une liste des appareils et versions réellement ciblés. Ajoutez le navigateur, la politique de gestion des téléphones et les accessoires indispensables. Une fonction testée sur un poste de développement ne suffit pas à valider le parc de l’entreprise.
- Distinguez les comptes personnels, les comptes de travail et les appareils partagés.
- Précisez qui peut consulter, créer, corriger et valider une information.
- Testez la caméra ou le lecteur nécessaire avec les autorisations acceptées puis refusées.
- Identifiez la personne qui peut révoquer un accès ou remplacer un appareil perdu.
Une solution web, une application distribuée par une boutique et une réalisation partageant du code entre plateformes ne sont pas interchangeables par principe. Retenez la solution après un essai des fonctions critiques. N’exigez pas une application native si une page adaptée suffit, mais ne présentez pas non plus une page web comme capable de tout faire.
3. Séparer lecture hors ligne et enregistrement confirmé
Un écran déjà chargé peut rester visible sans connexion alors qu’une nouvelle saisie ne peut pas être transmise. Définissez séparément la consultation locale, la sauvegarde sur l’appareil et la confirmation serveur. L’utilisateur doit reconnaître un brouillon en attente et une donnée réellement partagée.
La documentation Android sur les applications conçues pour fonctionner hors ligne distingue les sources locales et réseau ainsi que plusieurs stratégies d’écriture. Pour votre projet, cela impose de choisir ce qui attend la connexion, ce qui est enregistré localement et ce qui doit être refusé sans réseau.
Prévoyez également le cas où deux personnes modifient le même dossier. Une synchronisation qui remplace silencieusement une correction ne respecte pas nécessairement le besoin métier. Définissez la règle de résolution et le message à montrer. Vérifiez les reprises après fermeture de l’application, reconnexion et expiration des droits.
4. Préparer l’installation et les notifications
Décrivez comment l’utilisateur accède au service pour la première fois et reçoit ses mises à jour. Une application interne et une application destinée au public peuvent avoir des contraintes de distribution différentes. Attribuez les comptes techniques et la responsabilité du suivi avant la livraison.
Les règles de revue App Store d’Apple demandent notamment une application testée, des informations exactes et un accès permettant la revue. Préparer ces éléments n’est pas une garantie d’acceptation ni de délai. Une publication en boutique ne doit pas être annoncée comme acquise avant sa confirmation.
Les notifications ne sont pas une simple propriété visuelle. Dans son annonce de 2023 sur Web Push pour les applications web sur iOS et iPadOS, WebKit décrit un contexte d’ajout à l’écran d’accueil et une permission liée à une interaction de l’utilisateur. Cette référence historique ne remplace pas un test actuel des appareils et versions retenus.
5. Construire une recette observable
Préparez des données neutres et des comptes de test autorisés. Pour chaque scénario, notez l’état initial, l’action et le résultat attendu. Contrôlez à la fois l’écran de l’utilisateur et la donnée effectivement enregistrée. Un message de succès seul n’est pas une preuve suffisante.
- Première connexion, accès refusé et compte dont les droits ont changé.
- Réseau coupé avant la saisie puis pendant l’envoi.
- Envoi répété sans création involontaire de doublons.
- Reprise d’un brouillon et conflit entre deux modifications.
- Texte agrandi, champs utilisables et actions accessibles sur les appareils ciblés.
Conservez les résultats de recette et les anomalies restantes. Si une fonction ne passe que sur une partie du parc, indiquez cette limite dans la remise. Une démonstration réussie ne vaut pas validation de toutes les situations de production.
6. Délimiter la livraison et l’entretien
La proposition doit distinguer construction, hébergement, distribution, abonnements éventuels et maintenance. Faites préciser les accès remis, les données exportables, la sauvegarde et les responsabilités après livraison. Ne supposez pas que l’export des données comprend le code de toute plateforme utilisée.
Le cahier des charges d’un projet web aide à attribuer contenus, validations et contrôles. Si le besoin concerne un outil accessible en ligne, la page création et évolution de SaaS permet de cadrer cette partie, sans promettre par défaut une application native ou une publication en boutique.
Présentez d’abord la tâche et vos contraintes. La bonne décision est celle dont les fonctions nécessaires peuvent être vérifiées et dont la remise est claire, pas celle qui ressemble le plus à une application connue.
