Si la grande majorité des applications sont aujourd'hui des applications web, c'est qu'elles ont des bénéfices non négligeables. En voici quelques-uns.
Pas d'installation. Avec des logiciels classiques, vous devez les installer sur chaque ordinateur de votre parc informatique et espérer que tous les ordinateurs soient compatibles. Cela se complique encore plus lorsque vous avez besoin de faire la même chose pour les tablettes et les mobiles à cause, entre autres, de la fragmentation de l'écosystème Android.
Peut être utilisée sur n'importe quel ordinateur, tablette ou mobile. Windows a été pendant très longtemps un système d'exploitation en position de monopole, mais ce n'est plus le cas. L'utilisation croissante en entreprise de macOS, iOS et Android demande un investissement plus important si l'application métier doit être native.
Les mises à jour se passent sans intervention. Aucune maintenance n'est donc nécessaire et l'application peut être mise à jour plus régulièrement. De plus, cela permet de réagir plus rapidement aux bugs et aux évolutions du marché.
Tous ces points sont des bénéfices très importants pour votre entreprise. Le bénéfice principal qui en résulte est le coût.
En effet, la maintenance du parc informatique est considérablement réduite et les économies sont donc très importantes.
De plus, des mises à jour régulières vous permettent de bénéficier des dernières innovations rapidement. Vous n'avez plus à attendre interminablement la nouvelle version d'un logiciel et vous pouvez mettre à jour vos solutions sur-mesure sans devoir laborieusement mettre à jour chaque ordinateur.
Le processus de conception d’une application web est très varié, alliant des compétences très diverses et peut, selon le périmètre de l’application visée, faire intervenir plus d’une dizaine de compétences très différentes.
La première des questions à se poser consiste à repartir de l’existant : l’application web visée est-elle l’amélioration d’une application existante ou bien s’agit-il de repartir d’une page blanche ?
Les problématiques opérationnelles seront tout à fait différentes selon le cas.
Une fois ce positionnement clair, la seconde étape consiste à définir les fonctions majeures souhaitées, de définir la roadmap globale de l’application, afin de prendre les bonnes orientations dès l’initialisation de la plateforme et éclairer les futurs choix à l’aune de la projection de l’application.
Une fois une roadmap claire définie, il conviendra de se positionner dès le début du projet sur les éléments non fonctionnels : impact du time to market, importance des éléments de sécurité, éléments de volumétries attendues (nombre de connexions, quantités d’informations type images ou fichiers à échanger), importance de l’UX (selon le type d’audience visée), etc.
L’étape suivante concerne l’architecture de l’application, quels seront les contenus à favoriser selon l’audience visée, quelle stratégie multi-device déployer (besoin de viser des tablettes, mobiles? Via des applications dédiées tirant parti spécifique de ces appareils, ou uniquement via du “responsive design” ?).
Les choix technologiques peuvent ou non faire partie des choix et partis pris avant démarrage des travaux de conception de l’application; il conviendra de s’interroger sur la disponibilité des ressources aptes à déployer ces technologies, la qualité de celles-ci et la complexité à monter des équipes le cas échéant.
L’équipe technique aura à cœur de gérer le cycle de développement de cette application. L’équipe aura pleinement conscience qu’elle n’est qu’intermédiaire dans la mise en œuvre, même si la relation avec le commanditaire, vous, est prévue pour durer. Le processus de mise en œuvre du code de l’application devra prendre en compte les meilleures pratiques.
Nous recommandons l’exécution régulière de tests de performance et de tests de pénétration; les besoins sur ces dimensions évoluent au fil du temps et de l’usage de l’application.
Comme évoqué plus haut, une veille particulière doit être mise en place sur les frameworks et langages utilisés, sur les composants outillant l’infrastructure hôte, sur la surveillance de la sécurité de l’application, comme le cycle de vie des certificats par exemple.
Aussi surprenant que cela puisse paraître, le développement web et même plus généralement le développement logiciel est un domaine relativement récent et peu industrialisé.
Là où on imagine bien que la fabrication d'une voiture suivra sensiblement le même processus d'une marque à une autre, ce n'est pas exact lorsqu'il s'agit de développer une application web.
C'est pour cela que pour choisir les technologies à utiliser pour son application web, il est recommandé de prendre en compte les critères suivants :
Un dernier point important est l'écosystème. Les outils et la communauté d'un langage sont essentiels dans le choix de la technologie à adopter.
Une fois tous ces critères pris en compte, il ne vous reste plus qu'à les adapter à votre situation.
Adapter ses outils. Aucune technologie n'est parfaite. Mais le plus important à l'heure de l'arbitrage est de trouver l'outil le plus à même de résoudre votre problématique.
Adapter à ses équipes. Si vous décidez de lancer un projet avec des outils que personne n'a jamais utilisés dans votre équipe de développement, vous courrez à votre propre perte.
Adapter aux risques du projet. Si votre projet est critique pour l'entreprise, limitez vos risques au maximum. Au contraire, pour un projet de R&D où l'innovation est importante, prendre plus de risques sur le choix des technologies est possible.
Dépasser le budget peut avoir des conséquences importantes pour la santé d'un projet. Le coût de développement d'une application web dépend de plusieurs facteurs dont il faut être conscient pour garder le contrôle de son budget.
La première chose qu'il faut comprendre est la complexité du projet. Toutes les fonctionnalités ne vont pas forcément tenir dans le budget alloué.
De plus, chaque fonctionnalité a une complexité spécifique particulière. Un formulaire avec quelques champs est bien plus rapide à développer qu'une fonctionnalité de statistiques avec un traitement des données particulier.
Pour se prémunir de cela, il faudra veiller à découper le projet en plusieurs versions avec la première contenant les fonctionnalités les plus importantes. Dans ce cas, il sera plus simple quand vous recevrez les estimations de développeurs ou d'agences de savoir ce qui peut être fait dans le budget et ce qui est hors budget.
La conception d'une application web n'implique pas uniquement des développeurs. C'est le travail combiné de designers, développeurs, chefs de projets et testeurs (QA). De plus, l'écart de salaire peut être important en fonction du niveau de compétence. En France, il y a un écart de 50% ou plus entre un développeur junior et un sénior.
Bien sûr, l'option de choisir une agence dans des pays où les salaires sont moins importants est tentante. Mais dans les faits, beaucoup d'obstacles existent en cas de problèmes. Juridique par exemple. Et vous ne savez absolument pas qui fait quoi et comment.
Ce n'est pas parce que la mise en production a été réalisée et que l'application web fonctionne, qu'il n'y a plus de dépenses. Avant tout, il faut penser aux dépenses pour l'hébergement.
De plus, une application n'est jamais terminée. D'un côté, même en passant beaucoup de temps sur les tests, il y aura des bugs que personne n'aura détectés. C'est une dépense qu'il faut prévoir et qui représente entre 10% et 25% du budget initial. Et de l'autre côté, il y a les fonctionnalités qui n'ont pas pu être mises dans le développement initial pour pouvoir respecter le budget sur lesquelles il va maintenant falloir s'atteler.
La complexité des applications web a grandement augmenté ces dernières années. Avec la croissance du nombre d'utilisateurs d'Internet, les applications web doivent pouvoir tenir la charge et la multiplication des services externes demande une architecture claire pour une maintenance et évolution simple et rapide.
La première chose à faire pour une bonne architecture est de séparer le code de l'interface utilisateur de la logique métier et de l'accès aux données. Cette séparation a donné lieu, entre autres, au modèle MVC (Model-View-Controller).
Ces trois couches sont séparées mais des dépendances existent toujours, qui rendent la réutilisation et le test du code compliqué. L'étape suivante est donc de pouvoir avoir une architecture indépendante des frameworks, bases de données et autres facteurs externes. Cette architecture a comme nom "Clean Architecture".
Malgré cette indépendance, tout le code est au même endroit. Si on change une ligne de code quelque part, il faut redéployer toute l'application web. Cela peut poser problème si le travail en cours sur une partie bloque la mise en production de la correction d'un bug.
Pour répondre à ce problème, on va utiliser une architecture orientée service. Deux modèles pour cette architecture sont devenus populaires, les microservices et le serverless.
Dans les deux cas, l'application est découpée en plusieurs morceaux indépendants, ce qui permet de faire évoluer un module sans toucher à un autre et d'allouer des ressources à certains services qui ont des demandes différentes du reste des services.
Dans la réalité, ces services ne sont que rarement indépendants et cela crée au final une complexité bien plus importante qu'avec une architecture plus traditionnelle. Toutefois, il est possible et même recommandé d'adopter une architecture hybride en extrayant les parties de l'application web réellement indépendantes dans des microservices, si cela permet d'en tirer des bénéfices en termes de performance ou de coût.
Bien architecturer son application web est critique pour le long-terme. Il est important de ne pas suivre les tendances des entreprises comme Facebook, Google ou Netflix discutant publiquement à profusion de leurs architectures mais ne répondant très probablement pas à vos propres besoins.
La sécurité des applications web est un enjeu majeur. Aucune entreprise n'est à l'abri d'une faille. Le vol de données ou l'indisponibilité d'une application peut avoir des conséquences désastreuses.
Il est vital de s'en protéger et cela demande une expertise pointue. Voici un aperçu des solutions à mettre en œuvre pour s'en prémunir.
Authentification. C'est la première défense entre une application et un attaquant. Une faille dans l'authentification peut avoir de graves conséquences.
Sessions. Une fois authentifié, une session est créée et permet de revenir sur l'application web sans se ré-authentifier. Si un individu réussit à voler la session, il pourra utiliser le compte de la victime.
Contrôle d'accès. Toutes les fonctionnalités d'une application ne seront pas accessibles à tous les utilisateurs, il faut donc mettre en place un contrôle d'accès pour éviter l'exposition d'informations sensibles.
Injection. Toutes les applications web permettent à leurs utilisateurs d'entrer des données et d'uploader des fichiers. Si les données et les fichiers ne sont pas validés et filtrés, cela créera de nombreuses failles de sécurité et un individu malveillant pourra injecter du code et manipuler à sa guise la base de données, l'interface utilisateur, et même le serveur.
Transmission des données. Les données transitent entre les serveurs et les navigateurs web des utilisateurs. Ces transmissions peuvent être interceptées et il faut donc les sécuriser.
Comme vous pouvez le voir, la sécurité est un sujet compliqué où chaque détail compte. Avec le RGPD, un vol de données personnelles d'utilisateurs doit être publiquement révélé dans les 72h sous peine d'une amende très importante. Cela ajoute encore plus à l'importance de faire très attention à la sécurité de votre application web.
Avec l'arrivée du Cloud, les solutions d'hébergement se sont multipliées et il peut être complexe de les différencier. Malgré tout, de réelles avancées ont été faites pour rendre l'hébergement plus facile à configurer et à moindre coût.
Avant tout, parlons du on-premise (Auto-hébergement en français). Dans ce cas, vous achetez et utilisez vos propres serveurs. Le seul avantage désormais pour cette solution est de pouvoir avoir le contrôle total si des lois vous y obligent ou si c'est un avantage concurrentiel pour votre entreprise. Dans tous les autres cas, le Cloud est à privilégier.
En effet, l'on-premise a beaucoup de contraintes. Tout d'abord, le coût initial d'achat des serveurs est important. Le délai de livraison de ces serveurs peut être de plusieurs semaines et il est difficile d'estimer correctement le nombre de serveurs nécessaires sur le moyen et long terme. De plus, les pannes peuvent vous coûter cher si vous n'avez pas la pièce de rechange disponible, ou pire s'il faut remplacer un ou plusieurs serveurs en même temps.
Le Cloud n'a pas tous ces problèmes, mais il peut être compliqué de comprendre quelle est la solution adaptée avec une offre assez dense. Voici un récapitulatif.
IaaS. Avec cette solution, vous n'avez que la base de l'infrastructure, des machines virtuelles, le réseau, et le stockage. Vous devez configurer et gérer tout l'environnement pour déployer votre application web.
Exemples : Amazon AWS (EC2), Google Cloud Platform (CE), Microsoft Azure (VM)
CaaS. Cette solution vous offre un moyen standard de joindre le code, les configurations et les dépendances de votre application dans un seul objet, le conteneur. Une fois le conteneur défini, le service s'occupera de gérer les machines virtuelles.
Exemples : Google Container Engine (GKE), AWS (ECS), Azure (ACS)
PaaS. Ici, tout est déjà configuré et les conteneurs sont gérés à votre place. Vous n'avez plus qu'à déployer votre application web.
Exemples : Google App Engine, Heroku, AWS (Beanstalk), Scalingo
Moins d'un tiers des projets d'applications se terminent dans les temps et sans dépasser le budget. C'est une statistique à laquelle il faut faire face et être réaliste à son sujet. Ce n'est qu'en étant conscient de cette réalité que l'on va mettre en place une bonne gestion des risques.
Cela va se faire en 4 étapes :
Pour pouvoir au mieux suivre ce plan, il va falloir comprendre où peuvent apparaître les risques et comment s'en prémunir.
Il y a plusieurs risques associés au périmètre du projet. Ce dernier peut être mal spécifié ou alors dériver sans fin pour devenir ingérable, par exemple avec l'ajout de fonctionnalités qui ne sont pas nécessaires.
Les chefs de projets sont là pour gérer les changements de périmètre. D'un côté pour éviter qu'il ne dérive, mais aussi pour ajouter des éléments urgents et nécessaires, ainsi que de le garder pertinent au fur et à mesure de l'avancement du projet.
De nombreux risques sont présents sur le sujet des ressources humaines : le processus de recrutement, le temps d'adaptation pour être productif sur un nouvel environnement, la mauvaise cohésion des équipes, le désengagement des parties prenantes et les aléas des équipes (vacances, maladie ou démission).
Avoir une solution de redondance quand quelqu'un est malade, en vacances, ou démissionne est essentielle pour ne pas bloquer l'avancement du projet. Le chef de projet est aussi là pour gérer les problèmes de communication avec les équipes.
Enfin, les risques techniques sont eux aussi à assimiler pour pouvoir les éviter. Les problèmes de montée de charge et les bugs peuvent apparaître et il est important de les corriger rapidement pour que les usagers ne perdent pas en productivité.
Avoir un bon système de contrôle de version est essentiel pour éviter les conflits de code entre plusieurs versions et entre les développeurs. Les tests automatisés vont aussi avoir un rôle important dans la prévention des bugs et la stabilité de l'application web. Enfin, avoir des rapports de bugs permettra de les corriger de manière pro-active au lieu d'attendre qu'un utilisateur contacte le support.
