App Hybride v Natif

Lorsque l’on doit faire un choix entre un développement natif et un développement hybride il y a plusieurs facteurs qui rentrent en compte : 

La quantité et la complexité des règles business

La complexité de l’interface souhaitée

L’utilisation de certaines fonctionnalités du téléphone comme le GPS, l’appareil photo, etc.

Le budget disponible

Les règles business

Une des raisons principales d’opter pour un développement hybride est la quantité et la complexité des règles business.

En effet, les règles business sont très souvent identiques pour toutes les plateformes (Android, iOS, web). 

Par exemple, dans une application de réservation de vols, s’il existe une règle stipulant qu’un utilisateur ne peut pas réserver un vol plus d’un an à l’avance, il est parfaitement logique que cette règle s’applique à tous les utilisateurs sur toutes les plateformes.

De ce fait, si une application comporte beaucoup de règles de ce type (et de surcroît si ces règles sont complexes), il est très intéressant de pouvoir les partager entre toutes les plateformes. De cette façon, il ne sera nécessaire de les écrire et de les tester qu’une seule fois. Et lorsqu’une nouvelle règle doit être ajoutée ou qu’une règle existante doit être corrigée, il ne faudra le faire qu’une seule fois pour toutes les plateformes.

Cela permet aussi de s’assurer que les règles sont bien identiques pour tous les utilisateurs.

L’interface utilisateur

L’interface graphique de l’utilisateur est propre à chaque plateforme. Chaque système a ses propres bonnes pratiques en terme d’interface et d’expérience utilisateur.

Il peut être déroutant pour un utilisateur d’une certaine plateforme de constater qu’une application utilise des règles appartenant à une autre plateforme.

Les frameworks de développement hybride utilisent différentes techniques pour l’interface utilisateur : 

Laisser au développeur la possibilité de créer son interface graphique propre à la plateforme. Il n’y a donc pas de partage de code pour l’interface graphique. C’est le cas de Xamarin par exemple qui propose uniquement de partager le code business mais pas le code de l’interface (sauf Xamarin Forms qui permet de faire les deux).

Permettre d’écrire l’interface une seule fois et laisser le framework faire la « traduction » pour utiliser des composants natifs en exécution. Cette méthode est toutefois assez gourmande au rayon performance. C’est le cas de React Native par exemple.

Permettre d’écrire l’interface une seule fois mais au lieu de « traduire » ensuite en composants natifs, le framework va dessiner lui-même les composants avec son propre moteur graphique. C’est nettement plus intéressant d’un point de vue performance mais par contre il y a moins de composants disponibles. C’est le cas de Flutter par exemple.

L’utilisation d’un framework de développement hybride peut être une bonne idée si l’interface graphique de l’application est très simple et que sa qualité n’est pas une priorité.

Fonctionnalités propres au téléphone

En fonction du framework de développement hybride choisi, il peut être plus ou moins compliqué d’accéder à certaines fonctionnalités propres au device utilisé (GPS, appareil photo, gyroscope, etc.).

Si l’application doit utiliser un grand nombre de fonctionnalités natives, il est probablement préférable de ne pas recourir au développement hybride.

Budget

En théorie, le budget nécessaire pour réaliser une application hybride est moins élevé que celui d’une application native comparable. Cela s’explique par le fait que le code est partagé entre les différentes plateformes et qu’il n’est donc pas nécessaire de créer la même chose plusieurs fois.

Toutefois, ce n’est pas toujours le cas. Si le développement hybride a été choisi à tort, le budget nécessaire peut se révéler plus élevé que pour un développement natif.

Par exemple, s’il a été décidé d’utiliser un framework de développement hybride alors que l’application a des interfaces graphiques complexes, il risque d’y avoir beaucoup de bugs propres à certaines plateformes et à certains devices. De ce fait, beaucoup de temps risque d’être investi dans la correction des bugs et le budget nécessaire risque de monter rapidement.

Conclusion

En conclusion, nous pouvons dire qu’il peut être intéressant de développer une application hybride quand celle-ci contient beaucoup de règles business complexes et que l’interface graphique voulue est relativement simple et que sa qualité n’est pas une priorité.

Dans tous les autres cas, il sera préférable de développer des applications natives car leur qualité sera généralement toujours meilleure.