La décision entre PWA et application native est généralement prise de la manière la plus risquée possible : par préférence. L'équipe aime une technologie, le fondateur a lu un article, quelqu'un a eu une bonne expérience avec un natif dans son emploi précédent. Et le choix qui définit les mois budgétaires est fait par inclination et non par analyse.
Lorsque l’erreur apparaît, cela coûte cher. Découvrir, après six mois de construction native, qu'une PWA aurait suffi, ou l'inverse, c'est du temps, de l'argent et de l'énergie qui ne reviendront pas. Dans des décisions comme celle-ci, le coût d’une erreur justifie les efforts déployés pour prendre une bonne décision.
Ce texte s’adresse à ceux qui sont sur le point d’engager des ressources et qui souhaitent décider avec discrétion et non avec intuition. Je ne vais pas expliquer en quoi consiste chaque approche ; Je suppose que vous le savez déjà. Je vous proposerai une liste de contrôle de décision, des questions qui, répondues honnêtement, indiqueront la bonne voie pour votre cas.
Pourquoi décider par liste de contrôle, pas par intuition
L’intuition échoue dans les décisions de plateforme car elle est biaisée par l’expérience récente et les préférences personnelles. Ceux qui dominent les autochtones ont tendance à y voir des raisons d'être autochtones. Ceux qui viennent du Web ont tendance à voir les raisons de PWA. Les préjugés sont humains et invisibles.
Une liste de contrôle neutralise une partie de ce biais en imposant des questions que la préférence ne poserait pas. Cela déplace la conversation de « je pense » à « ce que le produit et l'entreprise exigent ». Et surtout, cela rend la décision défendable : lorsqu'il faut justifier son choix auprès d'un partenaire, d'un conseil d'administration ou d'un sponsor, un raisonnement structuré vaut plus qu'un avis.
Je préconise que chaque décision de plateforme passe par cette structure, même lorsque la réponse semble évidente. C’est précisément dans les cas « évidents » qu’une erreur coûteuse se produit, car personne n’a pris le temps de la remettre en question.
Liste de contrôle des capacités techniques
Le premier front est le plus objectif : le produit nécessite-t-il des capacités que seul le natif offre bien ?
Demandez : Le produit repose-t-il sur un traitement lourd, des graphiques intensifs ou des performances que le Web a du mal à égaler ? Besoin d'un accès approfondi aux capteurs, à une caméra avancée ou à des fonctionnalités matérielles spécifiques ? Nécessite-t-il une intégration avec des fonctionnalités du système d'exploitation que PWA ne réalise pas de manière cohérente ?
Si la réponse à ces questions est un oui clair et central au produit, la liste de contrôle pointe déjà vers le natif et les autres fronts pèseront moins. Dans le cas contraire, ou si les capacités natives sont secondaires, PWA est toujours en jeu avec force.
Le souci ici est de séparer ce dont le produit a besoin de ce qui serait « agréable à avoir ». De nombreuses décisions prises par les autochtones sont justifiées par une ressource que, finalement, presque personne n’utilise. Énumérez uniquement ce qui est essentiel à la proposition de valeur.
Liste de contrôle de portée et de distribution
Le deuxième front concerne la manière dont les utilisateurs accéderont au produit.
Demandez : votre public utilise-t-il une variété d'appareils, y compris des appareils modestes, sur lesquels la friction liée au téléchargement d'une application est difficile ? La découverte de recherches sur le Web est-elle un canal pertinent pour vous ? La présence sur l’App Store est-elle stratégique pour la crédibilité ou l’acquisition, ou est-elle indifférente ?
Si une large portée et de faibles frictions à l’entrée sont des priorités, situation courante dans les services publics de masse, y compris les services publics, PWA gagne des points. Si le magasin est un canal d’acquisition central et que le public s’attend à y trouver le produit, le natif gagne.
Il y a aussi la rapidité de distribution. Dans quelle mesure est-il important de pouvoir mettre à jour et corriger immédiatement, sans attendre un avis en magasin ? Pour les produits qui évoluent beaucoup et doivent être corrigés rapidement, la diffusion immédiate de PWA est un avantage opérationnel concret.
Liste de contrôle des coûts et de la capacité de l'équipe
Le troisième front est celui qui détermine le plus la viabilité et le plus ignoré dans les conversations techniques.
Demandez : quelle est la taille de l'équipe et combien de plates-formes peut-elle gérer avec qualité ? La maintenance d'applications natives pour plusieurs systèmes ainsi qu'un site Web est un coût récurrent et non ponctuel, chaque nouvelle fonctionnalité étant multipliée par plate-forme. Le budget soutient-il cela au fil du temps, ou juste au lancement ?
Tenez compte du coût total de possession, et non de la construction initiale. Un natif peu coûteux à lancer peut être coûteux à entretenir. Une PWA plus limitée peut permettre à l'équipe de se concentrer sur le produit plutôt que sur la parité multiplateforme.
Pour les petites équipes et les startups, ce front est souvent décisif. La ressource rare est l’attention, et diviser l’attention entre les plateformes est rarement rentable à un stade précoce. La liste de contrôle doit donner un réel poids à cette restriction et non la traiter comme un détail.
Liste de contrôle des risques et de la réversibilité
Le quatrième front concerne ce qui se passe si vous vous trompez, car vous pouvez vous tromper.
Demandez : Dans quelle mesure cette décision est-elle réversible ? Commencer en tant que PWA et migrer les fonctions vers le mode natif plus tard est généralement moins pénible que l'inverse. Quel est le coût d’un changement de cap dans un an si les hypothèses changent ?
Pensez également au risque de dépendance. Les applications natives dépendent des politiques du magasin, qui changent et peuvent affecter votre produit. Les PWA dépendent de la prise en charge par les navigateurs de certaines fonctionnalités, qui varient selon les plates-formes. Chaque chemin comporte son risque externe, et il vaut la peine de savoir lequel vous êtes prêt à supporter.
Dans les décisions prises sous incertitude, qui sont majoritaires, l’approche la plus réversible a de la valeur en soi. Il permet d'apprendre à partir d'une utilisation réelle et de corriger le cap à moindre coût. Lorsque l’incertitude est élevée, il est souvent plus judicieux de s’engager sur la voie qui préserve les options plutôt que de se lancer à fond sur la supposition initiale.
Lecture du résultat de la liste de contrôle
Aucun front ne décide seul. La liste de contrôle est utilisée pour voir l'ensemble. Si la capacité technique crie native, cela pèse cher, cela ne sert à rien d'économiser sur une plateforme qui ne peut pas gérer le produit. Si la technique ne nécessite pas de natif, alors la portée, le coût et la réversibilité ont tendance à favoriser PWA, en particulier pour les équipes réduites.
Le schéma qui émerge généralement est le suivant : les produits fortement dépendants du matériel et les publics qui vivent dans le magasin ont tendance à se tourner vers les produits natifs ; les produits à large portée, à faible friction et avec de petites équipes tendent vers PWA ; et de nombreux cas nécessitent une combinaison au fil du temps, en commençant par la lumière et en approfondissant là où l'utilisation le justifie.
L’intérêt de la liste de contrôle n’est pas de fournir une réponse automatique. Il s'agit de s'assurer que la décision a été prise en fonction de ce qui compte, et non en fonction des préférences de la personne présente dans la salle. Un choix défendable, basé sur la capacité, la portée, le coût et le risque, résiste mieux à la pression et au temps.
Si vous prenez cette décision et souhaitez structurer l'analyse de votre produit, il existe d'autres textes ici sur le blog sur PWA, la stratégie native et de plateforme, y compris des exemples et des détails d'exécution. Et si vous souhaitez discuter de votre cas particulier avant de vous engager dans l’investissement, il vous suffit d’appeler pour en discuter.
A lire aussi
- PWA vs application native : comprendre la différence qui compte -PWA vs native : ce que des cas réels enseignent sur le choix
- PWA : qu'est-ce que c'est et pourquoi cela a du sens pour les petites équipes -Le design émotionnel dans les applications : cas réels et ROI de l'investissement dans l'émotion
- PWA vs native en pratique : comment délivrer des performances dans chacune
- Solution digitale sur mesure : la check-list avant l'embauche