Vous avez une idée d'application géniale, vous savez coder mais comment choisir une technologie ? Il existe tellement de frameworks et d'IDE que moi-même je m'y perds. J'ai décidé alors de découper le monde applicatif en deux catégories : d'un côté, les logiciels, qui s'installent sur un ordinateur, et de l'autre, les applications web. J'ai délaissé un peu la notion d'application mobile native car le projet que j'ai en tête actuellement ne s' y prête guère…
SOMMAIRE
Logiciels
Applications web
Préambule : En général, les entreprises font développer leur application sur-mesure, par une agence, lorsque les progiciels (applications achetées dans le commerce) ne répondent plus aux besoins spécifiques
Les avantages du développement d'une application métier sur-mesure : maintenance évolutive, économique, réduire vos coûts, augmenter vos revenus, et être adapté aux besoins de votre entreprise
Pour résumer, une application métier s'adapte à votre activité, contrairement aux progiciels
https://www.vertuoz.fr/fr/blog/13950-quels-benefices-tirer-un-logiciel-metier-specifique.html
Logiciels
L'un des avantages notables des logiciels dit clients lourds réside dans leur capacité à fournir une interface utilisateur graphique riche, mais certaines phases de la maintenance comme le déploiement et la montée de version représentent une charge de travail non-négligeable
Avantages
L’application native est développée spécifiquement pour chaque système d’exploitation (langage Java/Kotlin pour Android, et Objective-C/Swift pour iOS..).
C’est une solution idéale lorsque vous cherchez les performances les plus optimales et que vous souhaitez proposer des fonctionnalités complexes de type jeux, 3D, réalité virtuelle, algorithmes de calculs avancés…
https://www.novaway.fr/notre-expertise/que-choisir
A l’époque du client serveur, les plateformes de programmation implémentant le principe du client lourd ont été très rapidement adoptées par les entreprises. Ainsi le C++, le VB et plus tard le C# ou bien côté Java le Swing ont permis de développer facilement grâce aux studios de développement intégrés ou IDE et à leur éditeur graphique intégré des applications offrant de nombreux avantages :
Ergonomie : étant exécutée sur le poste client le développeur a accès à l’ensemble des fonctionnalités de l’OS ainsi que toutes les ressources et évènements matériels
Performance : pour le C++ par exemple, l’application étant compilée pour génération d’un code assembleur adapté à l’architecture processeur les instructions sont optimisées. Ceci n’est plus vrai sur les technologies comme le Java Swing ou le C# en client lourd où le principe de machine virtuelle a fait son apparition
Répartition : en mode client serveur, le code d’affichage côté IHM et de gestion de l’interaction utilisateur est exécuté au niveau du poste client ce qui offre l’avantage de solliciter les ressources serveurs uniquement pour la restitution des données et/ou traitements centralisés
Interconnecté : ayant accès aux ressources matérielles les solutions de type client lourd permettent le pilotage et/ou la réception d’informations de périphériques matériels connectés au poste client. Ces périphériques peuvent être des produits grands publics comme une douchette à code barre ou bien un scanner mais également des périphériques conçu sur mesure comme une chaîne de production, un réseau ferroviaire ou bien un ensemble pyrotechnique. Ces besoins sont d’ailleurs toujours couverts par des solutions de type client lourd avec si besoin des systèmes d’exploitation temps réel (on parle alors selon les cas d’informatique industrielle et non d’informatique de gestion)
Connectivité : même lorsqu’elle est implémentée en architecture client / serveur, une solution de type client lourd peut facilement disposer d’un mécanisme de base temporaire permettant de fonctionner en mode déconnecté. A l’inverse, ce mode de fonctionnement est très difficile à mettre en œuvre sur une architecture client léger
https://blog.axopen.com/2013/01/les-avantages-et-inconvenients-du-client-riche
Dans une application utilisant des clients lourds, on utilise bien souvent le même langage que sur la partie serveur (Java, VB.NET, C#, voir même C++) et pour les plus fantaisistes du XML et du CSS
Pour communiquer avec le serveur, on utilise des protocoles comme RMI, WCF ou SOAP. Et c'est tout !
Dans une application utilisant des clients lourds, on n'est pas dépendant du navigateur. Vous me direz que ces mêmes applications dépendent souvent de plates-formes d'exécution (JVM, CLR etc.), je vous répondrais que ces plates-formes sont bien souvent rétrocompatibles. Et mieux, dans le cas de Java, on peut faire en sorte à ce que chaque application utilise sa propre JVM, afin que les évolutions d'une application n'aient aucun impact sur les autres applications installées sur le même ordinateur
https://www.journaldunet.com/web-tech/developpeur/1142976-osez-le-client-lourd
Les applications natives pour un système d’exploitation précis permettent toujours une utilisation optimale des capacités de l‘appareil ou des ressources du système utilisées
Les clients lourds peuvent effectuer un traitement de données ou de programme gourmand en ressources
L'indépendance des serveurs ou d'un environnement réseau est un avantage des clients lourds
Client riche Internet : un concept hybride
Le Client Riche est en fait un client lourd, auquel on à greffé des capacités à se connecter sur un réseau. Cela permet d'une part de rendre l'affichage des informations dynamique, mais aussi, dans certains cas d'alléger le traitement fait sur le poste client. En effet le serveur peut exécuter des traitements à la place du poste client
Dans le traitement des données par exemple, on aura tendance à déporter des calculs sur le serveur et à n'envoyer que le résultat au poste client. Cette infrastructure à l'avantage de repousser l'obsolescence du matériel des postes client, vu qu'on leur demande moins de puissance, tout en conservant un look & feel en accord avec le système d'exploitation de la machine
De plus cela permet toujours de demander au poste client d'exécuter des calculs lourds, comme des rendus 3D, ou des animations. Le client Riche s'impose donc lorsque l'on a un besoin de connectivité et de puissance et que l'on souhaite stocker des données sur le poste client
http://gronoblog.blogspot.com/2011/01/informatique-client-leger-riche-ou.html
Avec le client riche Internet, le logiciel client est toujours réduit au navigateur mais celui-ci télécharge et exécute un ou plusieurs programmes qui engagent avec le serveur un dialogue générant un flux de messages XML. Seules sont alors rafraîchies les zones du navigateur qui ont besoin de l'être. Le confort d'utilisation est donc grandement amélioré
L'objectif des clients riches est de combler les limites des clients lourd et léger, lourdeur de la maintenance pour le client lourd et lenteur et pauvreté pour le client léger. Il y a eu deux approches : Les Rich Desktop Application (RDA, on améliore le client lourd) et les Rich Internet Application (RIA, on améliore le client léger)
Les RIA ont de plus grandes possibilités grâce au mode déconnecté et des interfaces plus riches, les échanges entre le navigateur et le serveur sont limités aux données
Les RDA ont l'avantage de la facilité de mise en œuvre (déploiement et maintenance automatisés)
L'avantage des RIA est que le fait d’exécuter la couche « Présentation » du modèle 3 tiers sur les postes client permet une grande distribution de l’application et ainsi limiter la consommation de ressources au niveau du serveur d’applications mais aussi la limitation des flux réseaux aux données métiers (pour beaucoup de technologies client léger les échanges avec le serveur contiennent l’ensemble du code HTML d’affichage de la page)
https://blog.axopen.com/2013/01/les-avantages-et-inconvenients-du-client-riche
Client riche autonome : le meilleur des deux mondes
Avec le client riche autonome, le navigateur reste le point d'entrée de l'application mais il ne sert qu'à télécharger et lancer une application qui est ensuite autonome ou presque. Celle-ci s'exécute en effet dans un run-time tel que la plate-forme Microsoft .Net ou Java, qui doit être préalablement installée, de même qu'un moteur de chargement et de mise à jour automatique de l'application et du run-time
Pour l'utilisateur, un client riche se comporte exactement comme un client lourd. L'ergonomie est la même, toutes les interactions avec les applications Windows sont possibles et les périphériques locaux sont gérés. De plus, l'application reste opérationnelle off-line, dès lors que les données consultées sont stockées en local
Si l'utilisateur n'y voit que du feu, l'administrateur se trouve pour sa part déchargé des tâches de déploiement et de mises à jours, entièrement automatisées. D'autre part, contrairement au client lourd, il n'est pas nécessaire de configurer le poste, par exemple afin de spécifier les droits d'accès qui lui sont attachés. Autrement dit, n'importe quel PC équipé d'un navigateur permet de lancer une application. Toutefois, la taille importante du run-time à télécharger initialement en réserve l'usage aux applications d'entreprises
Au moins trois technologies concurrentes cherchent à s'imposer sur le créneau du client riche autonome : Eclipse RCP (décliné par IBM avec l'offre Workplace Client Technology Rich Edition), Windows Smart Client chez Microsoft, ainsi que Swing et Java Web Start chez Sun
Inconvénients
Les solutions client lourd ont perdues progressivement de leur intérêt au yeux des décideurs informatiques dès le début des années 2000 en raison de quelques inconvénients complexifiant la phase de maintenance comme le déploiement et la montée de version : étant installée sur chacun des postes clients, le déploiement d’une solution de type client lourd est un projet en soi qui peut devenir très complexe lorsque l’on fait face à un parc informatique hétérogène
Il y a aussi le problème de compatibilité : étant compilé pour une architecture processeur et faisant appel à des fonctionnalités au niveau OS, une solution de type client lourd offre une compatibilité restreinte à une configuration matérielle et un système d’exploitation donné
Cette problématique a été résolu notamment avec Java et C# par la mise en place de la notion de machine virtuelle. Le code Java par exemple n’est pas compilé en assembleur mais dans un code intermédiaire (bytecode) compréhensible par la machine virtuelle Java installée sur le poste et qui va alors faire la traduction en code assembleur : ce principe permet la compatibilité du code à tout système d’exploitation et processeur permettant l’installation d’une machine virtuelle Java. Cependant ce nouveau mode de fonctionne limite les performances des applications compilée en bytecode de part la mise en place d’une couche intermédiaire, de plus il devient très difficile de dialoguer avec des périphériques extérieurs car la machine virtuelle Java n’a qu’un nombre très limité d’interactions possible avec l’OS et ses périphériques
A noter que le client riche lourd est plutôt adapté pour des applications de type Intranet pour lesquelles il est possible de gérer le déploiement de composants sur les postes clients. Par la suite, à chaque montée de version il est nécessaire de redéployer la nouvelle version sur chacun des postes
https://blog.axopen.com/2013/01/les-avantages-et-inconvenients-du-client-riche
Optimisation des ressources matérielles plus difficiles qu'avec client léger/web
Surface de faille de sécurité plus vaste qu'avec un client léger/web
Les clients lourds doivent encore s’interfacer avec leurs serveurs, notamment pour partager ou synchroniser des données avec l’ensemble du réseau
Les RIA sont complexes à programmer, ont une abondance de technologies concurrentes et requièrent un changement dans la façon de naviguer
Les technologies client riche disponibles sur le marché rompent avec les canons de développement des technologies client lourd ou client léger. Ceci est dû principalement au caractère graphique de ces technologies. Ainsi il n’est pas évident pour un développeur Web ou client lourd de développer en client riche. Enfin ces solutions étant propriétaires, elles sont plus facilement délaissée par les entreprises au profil des solutions Open Source foisonnantes dans le monde du client léger
Les inconvénients principaux des solutions client riche sont l'indépendance : ces solutions étant propriétaires la maintenance et les évolutions des machines virtuelles correspondantes dépendent des Road Map des éditeurs concernées. Par exemple, Microsoft a décidé d’abandonner la plateforme Silverlight ; les licences, ces solutions étant propriétaires il est nécessaire d’acquérir des licences à minima pour le studio de développement ; les langages de développement, ces solutions ayant été pensée sur la base de solution graphique (le Flash pour Flex) les langages de développement varient beaucoup des langages pour client lourd ou léger
https://blog.axopen.com/2013/01/les-avantages-et-inconvenients-du-client-riche
Avec les clients riches on reste loin de l'ergonomie et de la richesse fonctionnelle du client lourd. D'autre part, le trafic réseau reste important car XML est un langage plutôt verbeux. Il est en outre extrêmement difficile de faire interagir l'application avec le système ou les outils bureautiques. Ces inconvénients font dire à certains que le client riche Internet est en fait un client léger amélioré qu'il faudra cantonner aux seuls sites Web. Mais des éditeurs de progiciels ayant misé sur HTML auraient peut-être intérêt à l'adopter afin de réduire l'effort de migration. Les technologies candidates se nomment Ajax et Flash/Flex
On ne peut pas remettre en cause aujourd'hui la nécessité de faire évoluer les technologies clientes. Les solutions proposées demeurent techniquement différentes et à des degrés de maturité inégaux. Un frein risque d'apparaître sous peu pour le développement d'applications véritablement performantes : le sacro-saint protocole HTTP qui, de par son mode déconnecté, ne favorise pas (voire limite) la mise en œuvre d'application fortement transactionnelle et/ou sécurisée !
https://valtech.developpez.com/tutoriels/javaweb/clients-riches
Sur un client lourd, l'accès physique vous donne accès aux informations personnelles sur processeur de l'ordinateur. Dans le cas d'un client léger il est impossible de « récupérer » des données, étant données qu'elles sont stockées sur le serveur TSE
Certains modes de travail comme le développement ne se prêtent pas au client léger car ils nécessitent du client "très lourd", mais cela ne concerne finalement que peu de secteurs d'activité
Electron est constitué d'un navigateur Web (Chromium) qui héberge votre application Web comme s'il s'agissait d'une application de bureau. Cela vous permet d'utiliser la pile Web pour développer des applications de bureau multiplateformes
L'un des points qui dérangent le plus à propos d'Electron est qu'il va empaqueter un runtime Web complet dans chaque application, même si un runtime convenable existe déjà sur le système d'exploitation
Applications web
Une appli web n'est pas soumis à un système de notation comme sur les stores, mais est totalement inutilisable sans connexion internet…
Avantages
C'est moins cher
Un accès plus rapide
Fonctionne sur tous les systèmes d'exploitation
Accessible de partout
Travail en simultané dans le « Cloud »
Sécurité des contenus
https://fr.yeeply.com/blog/developpement-d-application-web-pour-votre-site
Aucune installation pour les utilisateurs
Mises à jour simplifiées
Mises à jour plus fréquentes
Une meilleure expérience utilisateur : l'interface graphique d'une application web est bien plus facile à personnaliser
Calcul de données capable de monter en charge
Sécurité
Un coût de développement et de maintenance restreint
https://www.synbioz.com/blog/avantages-application-web-metier
Le budget est prévisible par un abonnement mensuel fixe
La facturation est proportionnelle à votre consommation réelle
La circulation et le partage des données entre utilisateurs sont optimisés
Sauvegardes automatiques
Vous bénéficiez toujours de la version la plus récente
https://www.ideematic.com/dictionnaire-digital/application-web
Progressive web app
Une progressive web app est une version optimisée d’un site mobile intégrant des fonctionnalités d’applications natives (normalement indisponibles sur un navigateur). Aucun téléchargement sur les stores n'est nécessaire.
La progressive web app est en quelque sorte la version enrichie d’un site responsive. Elle a pour vocation d'optimiser l’expérience utilisateur sur mobile notamment grâce à des fonctionnalités similaires à celles d’une application native. L’effort de développement est minime par rapport à une application mobile ou native une fois que la plateforme web responsive est développée
Les fonctionnalités disponibles sont par exemple :
Créer un raccourci du site ou de l'application directement sur l'écran d'accueil du visiteur
Recevoir des notifications push (par exemple, à chaque nouvel article, à chaque nouveauté sur le site, comme pour une application)
Accéder aux fonctionnalités du téléphone telles que l’appareil photo, la géolocalisation, le micro, la boussole…
Atteindre les contenus hors-connexion grâce à un mode hors-ligne
https://www.novaway.fr/blog/tech/3-exemples-pwa
Les applications PWA pourraient connaître le succès grâce à leur structure technique ainsi qu’une forte compatibilité
Les fonctions d’une PWA se développent donc au rythme des fonctions des navigateurs et appareils utilisés
Si vous ouvrez une PWA sur un ordinateur de bureau ou un Notebook, elle se comporte comme une application Web habituelle
Mais si vous chargez une application Web depuis un Smartphone ou une tablette, l’interface ressemble à celle d’une application native
Il est possible, en fonction des caractéristiques de votre appareil mobile, que l’application recourt à des fonctions natives de l’appareil (comme la caméra, le microphone, les notifications Push ou GPS par exemple)
Il existe également des solutions permettant d’encapsuler des pages web enrichies à l’intérieur de «coquilles» natives et ainsi,
d’accéder à des fonctionnalités normalement non disponibles via HTML5 (accéléromètre, caméra, NFC, …) puis de les déposer sur les différents magasins d’applications. Il s’agit d’«applications hybrides»
Les API HTML5 rendent possible un bon nombre de choses auparavant uniquement disponibles sur une application native le stockage des fichiers de l’application et la gestion du mode hors-ligne
Une appli web n'est pas soumis à un système de notation comme sur les stores, où il est nécessaire d'effectuer une maintenance assidue qui, dans le cas contraire, génèrera de mauvais commentaires et augmentera le risque de désinstallation
Pas de commission prélevé par le store sur les ventes
Pas de retard suite au délai de publication imposé parfois par les stores
https://tymate.com/articles/choisir-entre-application-web-application-mobile
Ajax (Asynchroneous JavaScript and XML) est une technologie basée sur du Javascript réalisant des échanges XML avec le serveur permettant de réaliser des traitements assez impressionnants du côté client. De nombreux frameworks font leur apparition pour encapsuler la complexité de développement et de maintenance du langage Javascript. Cette solution possède l’énorme avantage de ne nécessiter aucune installation spécifique sur le poste client (si ce n’est que le client doit accepter l’utilisation de Javascript) mais le volume des composants Javascript peut parfois atteindre des valeurs importantes. Il faut par ailleurs bien prêter attention au fait que le langage Javascript diffère légèrement selon les navigateurs
https://www.osaxis.fr/faut-il-a-tout-prix-sorienter-vers-le-client-riche
Les avantages d'une application développée avec Electron :
Belles interfaces graphiques grâce à la diversité des frameworks web. Ceux-ci intègrent de nombreux composants : alertes, boutons, tableaux…
Et si cela ne suffit pas, créez les vôtres en HTML/CSS/Javascript. Vous pouvez coder avec React, Angular, Vue
https://fr.jeffprod.com/blog/2017/developpement-d-applications-multiplateforme-avec-electron
Inconvénients
On s'est rendu compte que l'ergonomie des applications web n'étaient pas aussi bonne que celle des applications basées sur des clients lourds, donc on a crée les RIA, l'AJAX etc.
Certains se sont rendu compte que contrairement aux applications basées sur des clients lourds, les applications web (celles qui sont basées sur HTML4) n'étaient pas adaptées au fonctionnement hors-ligne (sic!), donc HTML5 a du prendre en charge cette fonctionnalité
Dans une application web il faut maîtriser plusieurs langages pour la partie cliente
Le problème, c'est que les navigateurs web évoluent, et il faut faire évoluer en conséquence les applications web, et ça, c'est très coûteux, parce que cela implique des développements et surtout des longs tests de recette sur la quasi-totalité de l'application
https://www.journaldunet.com/web-tech/developpeur/1142976-osez-le-client-lourd
Difficulté de pouvoir estimer avec précision tout le travail qui va y avoir
L'expérience utilisateur demande une expertise que vous ne trouverez pas forcément en interne ou dans une agence
https://www.synbioz.com/blog/avantages-inconvenients-application-web-sur-mesure
L’application web est totalement inutilisable sans connexion internet
L’application web peut être mal reçue par son public à cause de problèmes d’affichages liés au responsive design
https://www.oniti.fr/blog/1870-creation-application-mobile-web-avantages-inconvenients.html
Les applications Web progressives manquent encore un niveau suffisant de compatibilité avec les fonctions natives des appareils mobiles :
au niveau fonctionnel, elles entrent seulement en compétition avec les applications natives si ces PWA ont la possibilité d’accéder aux fonctions natives d’appareils mobiles
Apple a cependant de bonnes raisons de continuer à se concentrer sur le format des applications natives et de ne pas introduire les PWA dans ses systèmes d’exploitation. L’App-store représente une grande source de revenus pour Apple et il lie les utilisateurs au service et donc à la marque. Même les données récoltées via l’App-store et les applications natives sont cruciales
Un inconvénient réside dans la commercialisation de l'application. Convertir un utilisateur en client est plus facile sur les stores Apple et Google une simplification de la procédure de souscription inApp. En un clic, l’achat est réalisé sans devoir ressortir sa carte bancaire
Adhérence au navigateur Web : bien qu’étant basé sur des standards comme l’HTML, le CSS ou bien le JavaScript le code envoyé au navigateur Web peut entrainer des différences de fonctionnement selon le navigateur (IE, Chrome, Mozilla…).
Il est alors nécessaire pour les développeurs de s’assurer de la compatibilité de leur application avec les versions majeures des navigateurs disponibles sur le marché
Le serveur se chargeant de calculer l’ensemble des pages pour tous les utilisateurs, les performances de l’application peuvent être très dégradé lorsqu’un nombre important d’utilisateurs sont connectés. Ces architectures nécessitent des tests de performances systématiques
https://blog.axopen.com/2013/01/les-avantages-et-inconvenients-du-client-riche
L'ergonomie d'une application HTML est déplorable car à chaque accès aux données ou à chaque modification, il faut faire un aller-retour avec le serveur. Ces allers-retours induisent un trafic réseau certes modéré mais permanent
De plus, ils reportent la charge sur les serveurs, qui doivent être dimensionnés en conséquence, tandis que les ressources des PC sont sous-exploitées
Inconvénients du client léger web :
IHM pauvre
Bande passante
Mode connecté
Performances
Comparatif UI client Windows / client web :
https://slideplayer.fr/slide/1298770