Réponse directe
Commencez par une application web si la tâche centrale profite d’un accès par lien, d’une saisie sur ordinateur, d’un déploiement contrôlé ou d’une large couverture, sans exiger de capacités natives profondes. Commencez par une application mobile si l’usage décisif se déroule sur téléphone et dépend du comportement appareil, de l’interaction mobile, du hors-ligne, des notifications ou d’une diffusion en store à tester. Une séquence peut valider le workflow sur le web avant le natif, mais seulement si la première surface produit une preuve pertinente. Décrivez le contexte réel, testez la contrainte appareil ou distribution la plus risquée et choisissez le plus petit parcours complet.
Ancrer le choix dans le moment d’usage réel
Décrivez lieu, appareil, connectivité, durée de session, mode de saisie, confidentialité et risque d’interruption. Un outil de back-office utilisé à un bureau appelle une autre surface qu’une tâche terrain impliquant caméra, capteur, réseau intermittent ou geste à une main. Ne déduisez pas un besoin mobile du simple fait que les utilisateurs possèdent un téléphone, ni une adéquation web du seul affichage dans un navigateur.
Définissez le plus petit résultat complet et les hypothèses propres au canal. Si la question porte sur la compréhension et la valeur d’un workflow, un parcours web responsive peut suffire. Si elle porte sur permissions mobiles, limites en arrière-plan, hors-ligne ou découverte en store, une simulation web risque de répondre à côté. La surface du MVP doit correspondre à l’incertitude testée.
Intégrer systèmes de publication et compétences spécifiques
Le web exige compatibilité, accessibilité, déploiement sécurisé, supervision et récupération. Le mobile ajoute identités de signature, builds, couverture appareils et systèmes, permissions, métadonnées de store, règles de revue et pistes de publication. Ce ne sont pas des raisons d’éviter le mobile, mais des travaux et responsabilités à inclure dans l’estimation lorsque le produit en dépend.
Nommez qui teste les vrais appareils, diagnostique client et backend, prépare les soumissions et répond aux changements de plateforme. Un framework multiplateforme peut mutualiser une partie de l’implémentation sans supprimer les obligations propres aux plateformes. Une PWA peut utiliser des standards d’installation tout en différant d’une application native. Vérifiez le support actuel dans les navigateurs et systèmes réellement visés.
Posséder les identités de diffusion et services partagés
L’entreprise contrôle domaine, DNS, hébergement, analytics et backend du web, ainsi que programmes développeur et identités de store du mobile lorsqu’ils s’appliquent. Documentez modèles de données et API partagés indépendamment d’un client. Ajouter ou remplacer une surface devient alors une évolution planifiée, pas une migration urgente depuis le compte personnel d’un intervenant.
Gardez dépôts, domaines, stores, analytics, organisations cloud et identifiants de production sous une propriété explicite de l’entreprise. Accordez des accès limités et révocables, puis répétez la transmission avant la dernière facture. L’étiquette du prestataire compte moins que la capacité d’une autre personne autorisée à inspecter, déployer, reprendre et poursuivre le produit.
Tester les pannes propres à chaque canal
Pour le web, testez navigateurs supportés, responsive, clavier, interruption réseau, authentification et récupération sur appareils cibles. Pour le mobile, ajoutez refus de permissions, passages arrière-plan et premier plan, hors-ligne, mise à jour, liens profonds et builds publiables. Mesurez l’accomplissement du résultat central. Un build valide ou une approbation de store ne prouve ni demande ni rétention.
Définissez la recette par des preuves observables, par exemple un parcours testé, un build approuvé, des contrôles reproductibles, un runbook d’incident et une transmission vérifiée. Rien de cela ne prouve rétention, revenu ou adéquation marché. Séparez preuve de livraison, approbation d’un fournisseur externe et résultat business.
Séquencer seulement si chaque étape répond à une question
Choisissez le web d’abord s’il atteint le contexte réel et crée une boucle d’apprentissage pertinente sans masquer un risque natif décisif. Choisissez le mobile d’abord si le comportement du téléphone appartient à la proposition de valeur. Ne lancez les deux que si le premier produit les exige et si l’équipe peut maintenir deux clients, pas pour donner une impression de couverture.
Écrivez le déclencheur d’un changement de canal: friction bureau observée, capacité appareil nécessaire, limites répétées du navigateur mobile, demande de distribution en store ou preuve issue du support. Préservez contrats partagés et parcours de recette pour introduire un autre client volontairement. Aucun canal ne garantit acquisition, approbation, usage ou performance commerciale.
Critères de décision
Posez les mêmes questions à chaque option avant de choisir.
| Option | Utile lorsque | À vérifier avant de choisir |
|---|---|---|
| Commencer par une application web responsive | La tâche centrale fonctionne par lien, profite de la portée ou du bureau et ne dépend pas d’un comportement natif non prouvé. | Tester vrais appareils, accessibilité, identité, récupération et limites navigateur, pas seulement une prévisualisation desktop. |
| Commencer par une application mobile | Le résultat exige contexte téléphone, capacité native, hors-ligne, notification ou diffusion en store dès le premier cycle. | Inclure signature, permissions, appareils réels, contenus de store, validation et exploitation après publication. |
| Faire le web puis le mobile | Le web peut tester le workflow, tandis que la surface mobile reste une hypothèse séparée et explicitement différée. | Définir la preuve web qui débloque le mobile sans promettre une réutilisation automatique du code. |
| Prototyper d’abord le contexte décisif | L’incertitude principale reste le problème utilisateur, une contrainte réglementaire ou une intégration critique. | Acheter un cadrage borné ou une revue spécialiste avant de choisir un modèle de réalisation complet. |
Questions fréquentes
Un MVP web est-il toujours moins cher ou plus rapide ?
Non. Le résultat dépend du parcours, des intégrations, des appareils, du niveau de publication, de l’équipe et des systèmes existants. Comparez la même frontière de recette.
Un MVP mobile doit-il couvrir iOS et Android ?
Non. Choisissez selon les utilisateurs et la distribution. Si une seule plateforme est retenue, documentez la preuve, les utilisateurs exclus et la condition d’ajout de l’autre.
Qui doit posséder les comptes de store ?
L’entreprise ou l’entité juridique pertinente contrôle programmes développeur, identités de store, récupération et signature. Les intervenants reçoivent des accès limités.
Quel est le meilleur premier test ?
Testez le contexte réel le plus risqué: parcours navigateur complet sur appareils cibles ou build exerçant permissions, hors-ligne et diffusion. Utilisez le résultat pour décider, pas pour prétendre prouver la demande.
Sources primaires et preuves
- À propos d’IVRYN 2026-08-15
- Travaux et preuves IVRYN 2026-08-15
- Méthodologie produit IVRYN 2026-08-15
- Guide France Num pour un projet numérique 2026-08-15
- Cadre NIST de développement logiciel sécurisé 2026-08-15
- Manifeste d’application web du W3C 2026-08-15
- Règles de validation de l’App Store 2026-08-15
- Exigences Google Play pour l’API cible 2026-08-15