Application Web sur mesure : dans quels cas la choisir ?

Qu’est-ce qu’une application Web ?

Une application Web est un logiciel dont l’interface est accessible à travers les technologies du Web, généralement depuis un navigateur.

Elle peut proposer des fonctionnalités beaucoup plus avancées qu’un simple affichage de contenus : création et modification de données, gestion de dossiers, tableaux de bord, workflows, espaces utilisateurs ou communication avec d’autres logiciels.

Une interface adaptée à un usage

Contrairement à un logiciel installé localement sur chaque poste, une application Web peut être accessible depuis une adresse Web selon les conditions d’accès prévues par le projet.

L’utilisateur peut alors se connecter et retrouver les fonctions correspondant à son profil et à son activité.

Une application peut par exemple servir à :

• gérer des dossiers ;
• suivre l’avancement d’un processus ;
• centraliser des informations ;
• administrer des utilisateurs ;
• consulter des tableaux de bord ;
• déclencher certaines actions ;
• échanger des informations avec d’autres logiciels.

Quelle différence entre un site Web et une application Web ?

La frontière n’est pas toujours totalement rigide, mais les deux types de projets répondent généralement à des objectifs différents.

Un site Web est principalement orienté vers la consultation

Un site d’entreprise sert notamment à présenter une activité, des services, des réalisations ou des ressources et à permettre aux visiteurs de prendre contact.

Il peut évidemment comporter des fonctionnalités interactives : formulaires, recherche, espace client ou prise de rendez-vous.

Une application Web est davantage orientée vers l’action

L’utilisateur y effectue généralement des opérations directement liées à un processus :

• créer un dossier ;
• modifier une information ;
• valider une étape ;
• affecter une tâche ;
• consulter des données personnalisées ;
• gérer des droits ;
• suivre une activité.

Un même projet peut associer les deux

Un site public peut présenter l’entreprise tandis qu’une application Web distincte permet aux collaborateurs, clients ou partenaires autorisés d’accéder à certaines fonctionnalités métier.

La différence doit donc être définie selon les usages plutôt qu’à partir de l’apparence graphique.

Dans quels cas envisager une application Web sur mesure ?

Un développement spécifique devient pertinent lorsqu’un besoin important n’est pas suffisamment couvert par les solutions disponibles.

Un processus métier est géré avec plusieurs outils dispersés

Les équipes peuvent être amenées à consulter successivement plusieurs fichiers, applications ou bases pour traiter un même dossier.

Une application peut alors proposer une interface commune permettant de regrouper certaines informations utiles au processus.

Les fichiers Excel deviennent difficiles à maintenir

Un tableur peut progressivement devenir un outil métier sans avoir été conçu pour gérer des utilisateurs, des droits, des workflows ou de nombreuses règles.

Lorsque cette situation apparaît, il peut être pertinent d’étudier un outil plus structuré.

Notre article sur le sujet explique plus précisément quand remplacer Excel par un outil métier.

Les logiciels standards nécessitent trop de contournements

Un logiciel peut proposer de nombreuses fonctions sans correspondre exactement au fonctionnement de l’entreprise.

Lorsque les équipes utilisent régulièrement des procédures parallèles pour compenser ses limites, un développement complémentaire ou spécifique peut être étudié.

Plusieurs profils doivent intervenir dans le même processus

Une application peut proposer des écrans et actions différents selon le rôle de l’utilisateur.

Des règles métier spécifiques doivent être appliquées

Validations, calculs, statuts ou conditions particulières peuvent être intégrés dans l’application lorsque ces règles sont clairement définies.

Quelles fonctionnalités une application Web peut-elle intégrer ?

Il n’existe pas de liste standard. Le périmètre dépend du processus que l’application doit accompagner.

Selon les besoins, une application peut notamment proposer :

• un espace de connexion ;
• plusieurs profils utilisateurs ;
• des formulaires métier ;
• des fiches clients, dossiers ou projets ;
• des tableaux et listes filtrables ;
• une recherche ;
• des workflows et changements de statut ;
• des validations ;
• des tableaux de bord ;
• des notifications ;
• la génération de certains documents ;
• des imports et exports ;
• des connexions avec d’autres applications ;
• des traitements automatisés.

Éviter la liste de fonctionnalités sans priorité

Un projet peut rapidement devenir difficile à cadrer si toutes les idées sont considérées comme indispensables dès la première version.

Chaque fonction doit pouvoir être rattachée à :

• un utilisateur ;
• un besoin ;
• une étape du processus ;
• un résultat attendu.

Cette approche permet de distinguer le socle nécessaire des améliorations qui peuvent être envisagées ensuite.

Comment gérer les utilisateurs et leurs droits ?

Une application métier peut être utilisée par plusieurs catégories de personnes ayant des responsabilités différentes.

Il faut donc déterminer dès la conception qui peut accéder à chaque donnée et à chaque fonctionnalité.

Définir des rôles

Selon le projet, on peut par exemple distinguer :

• utilisateur ;
• responsable ;
• administrateur ;
• client ;
• partenaire ;
• autre profil spécifique au fonctionnement de l’organisation.

Ces catégories sont uniquement des exemples. Les rôles doivent correspondre au fonctionnement réel du projet.

Limiter les droits au besoin réel

Un utilisateur qui doit seulement consulter une information n’a pas nécessairement besoin de pouvoir la modifier.

De même, certaines fonctions d’administration ou de suppression doivent pouvoir être réservées à des profils précis.

Prévoir le cycle de vie des comptes

Le projet doit également déterminer comment sont gérées :

• la création des comptes ;
• leur modification ;
• la réinitialisation des accès ;
• leur désactivation ;
• les changements de rôle.

Comment organiser les données de l’application ?

La conception de l’interface ne doit pas précéder entièrement la réflexion sur les données.

Il faut identifier les informations utilisées par le processus et comprendre leurs relations.

Déterminer les données réellement nécessaires

Un nouvel outil ne doit pas systématiquement reproduire tous les champs présents dans les anciens fichiers ou logiciels.

La création de l’application est l’occasion de vérifier :

• quelles informations sont réellement utilisées ;
• lesquelles sont obligatoires ;
• qui les crée ;
• qui peut les modifier ;
• combien de temps elles doivent être conservées ;
• avec quels autres éléments elles sont liées.

Identifier les données de référence

Lorsqu’une information existe déjà dans un ERP, un CRM ou une autre application, il faut éviter de créer une nouvelle source indépendante sans raison.

Le projet doit déterminer quel système constitue la référence et comment l’application Web récupère ou transmet les informations nécessaires.

Une application Web peut-elle communiquer avec les logiciels existants ?

Oui lorsque les possibilités techniques des différents systèmes le permettent.

Une application Web peut notamment être conçue comme une interface complémentaire autour de plusieurs logiciels déjà présents dans l’entreprise.

Conserver les outils qui fonctionnent

Un ERP ou un CRM n’a pas besoin d’être remplacé simplement parce qu’un nouveau processus doit être développé.

Il peut rester responsable de certaines données tandis que l’application Web prend en charge une fonction spécifique.

Utiliser les API disponibles

Une API peut permettre de récupérer, créer ou modifier certaines informations dans les systèmes connectés.

Notre guide sur l’intégration API détaille les principaux points à examiner avant de faire communiquer plusieurs applications.

Prévoir les règles de synchronisation

Une intégration doit notamment préciser :

• quel système constitue la source ;
• quelles informations sont échangées ;
• dans quel sens elles circulent ;
• à quel moment ;
• comment les erreurs sont traitées.

Lorsque l’API utilisée suit une architecture REST, notre article API REST présente également les notions utiles pour comprendre son fonctionnement.

Application Web et mobile : que faut-il prévoir ?

Le fait qu’une application utilise des technologies Web ne garantit pas automatiquement une bonne expérience sur smartphone.

Les interfaces doivent être pensées en fonction des appareils réellement utilisés.

Identifier les usages mobiles

Les besoins peuvent être très différents selon le contexte :

• simple consultation ;
• saisie ponctuelle ;
• utilisation quotidienne ;
• consultation sur tablette ;
• utilisation depuis un poste fixe uniquement.

Il n’est pas nécessaire de concevoir chaque écran prioritairement pour le smartphone lorsqu’un processus sera exclusivement utilisé sur de grands écrans.

En revanche, lorsqu’un usage mobile existe, il doit être prévu dès la conception.

Adapter les composants

Navigation, tableaux, filtres, formulaires et actions doivent être utilisables avec l’espace disponible et les interactions tactiles.

Les grandes tables de données constituent notamment un point à étudier attentivement : leur simple réduction peut rendre les informations illisibles.

Faut-il transformer l’application Web en PWA ?

Une Progressive Web App, ou PWA, utilise des technologies Web mais peut proposer certaines caractéristiques habituellement associées aux applications installées.

Selon les possibilités du navigateur, de l’appareil et du projet, une PWA peut notamment être installable ou proposer certains usages hors connexion.

MDN décrit les PWA comme des applications construites avec les technologies de la plateforme Web mais capables d’offrir une expérience proche de certaines applications spécifiques à une plateforme.

Ce n’est pas une obligation

Une application Web métier n’a pas besoin d’être transformée en PWA pour être pertinente.

Cette approche doit répondre à un usage réel, par exemple lorsqu’un accès simplifié depuis l’appareil ou certaines fonctions hors connexion présentent un intérêt pour les utilisateurs.

Il est préférable de commencer par les besoins plutôt que d’ajouter la technologie parce qu’elle est disponible.

Quels enjeux de sécurité prévoir ?

Une application Web métier peut traiter des informations importantes pour l’organisation et, selon les projets, des données personnelles.

La sécurité doit donc être intégrée dès la conception plutôt qu’ajoutée uniquement après le développement.

Les principaux sujets à étudier

Selon le contexte, ils peuvent notamment concerner :

• l’authentification ;
• les droits et habilitations ;
• la protection des communications ;
• la validation des données ;
• la gestion des sessions ;
• la journalisation ;
• les sauvegardes ;
• les composants logiciels utilisés ;
• les mises à jour ;
• les intégrations avec des services externes.

Intégrer la protection des données dès le projet

Lorsque des données personnelles sont traitées, leur collecte doit correspondre à un besoin identifié et les mesures de protection doivent être étudiées dès la conception.

La CNIL recommande explicitement d’intégrer la sécurité et la protection des données personnelles au plus tôt dans le cycle de développement.

Solution standard ou application Web sur mesure ?

Le développement spécifique ne doit pas être le premier choix par principe.

Une solution standard peut être préférable lorsque :

• elle répond correctement au processus ;
• les utilisateurs peuvent travailler sans contournements importants ;
• les intégrations nécessaires existent ;
• son modèle de fonctionnement correspond à l’organisation ;
• les possibilités d’évolution sont suffisantes.

Le sur-mesure devient intéressant lorsque :

• le processus est réellement spécifique ;
• les logiciels existants imposent trop de contournements ;
• plusieurs systèmes doivent être réunis dans une même interface ;
• des règles métier particulières doivent être appliquées ;
• les utilisateurs ont besoin d’un fonctionnement qui n’existe pas dans les solutions disponibles.

Cette réflexion est proche de celle menée pour un logiciel métier sur mesure : le projet doit partir des usages avant de choisir la technologie.

Comment cadrer un projet d’application Web sur mesure ?

Un cahier des charges technique détaillé n’est pas indispensable pour commencer à étudier le besoin.

Il est en revanche nécessaire de comprendre le contexte.

1. Décrire le problème actuel

Expliquez ce qui est difficile aujourd’hui : doubles saisies, informations dispersées, outil inadapté, manque de suivi ou processus manuel.

2. Identifier les utilisateurs

Listez les différents profils et ce que chacun doit pouvoir effectuer.

3. Décrire le processus

Précisez les principales étapes, validations et exceptions.

4. Inventorier les données

Identifiez les informations nécessaires et leur emplacement actuel.

5. Recenser les logiciels existants

ERP, CRM, site Web, LMS ou autres outils doivent être identifiés lorsqu’ils peuvent interagir avec l’application.

6. Définir la première version utile

Il est souvent préférable de distinguer le périmètre indispensable au lancement des fonctions pouvant être ajoutées ensuite.

7. Prévoir les contraintes

Appareils utilisés, nombre d’utilisateurs, droits, volumes de données, disponibilité attendue ou besoins d’intégration peuvent influencer l’architecture du projet.

AMEGANET accompagne les entreprises dans leurs projets de développement sur mesure, applications Web, outils métier, API, connecteurs et automatisations.

Comment prévoir la maintenance et les évolutions ?

Une application Web utilisée quotidiennement n’est pas un produit figé après sa mise en ligne.

Son environnement peut évoluer : navigateurs, bibliothèques, API externes, règles métier ou besoins des utilisateurs.

Prévoir la maintenance technique

Les composants doivent pouvoir être mis à jour et les éventuelles vulnérabilités corrigées.

Surveiller les intégrations

Lorsqu’une application dépend d’une API externe, les modifications du service connecté peuvent nécessiter une évolution du connecteur.

Faire évoluer le fonctionnement selon les usages

Les retours des utilisateurs peuvent révéler des améliorations réellement utiles après la mise en production.

Il est donc préférable de prévoir un processus permettant de qualifier et prioriser les demandes plutôt que d’ajouter chaque nouvelle idée sans analyse.

Conserver une documentation adaptée

Les règles métier, intégrations et choix importants doivent pouvoir être compris dans la durée afin de faciliter les futures évolutions.

Pour aller plus loin sur les applications et outils métier

Plusieurs ressources AMEGANET peuvent compléter votre réflexion :

• Développement sur mesure & API : découvrez l’accompagnement AMEGANET pour les applications Web, outils métier, API et automatisations.
• Logiciel métier sur mesure : identifiez les situations dans lesquelles un outil spécifique devient pertinent.
• Remplacer Excel par un outil métier : repérez les signes indiquant qu’un tableur atteint ses limites.
• Intégration API : découvrez comment connecter plusieurs applications.
• Automatisation des processus métier : structurez les règles et étapes avant d’automatiser.

Une application Web doit répondre à un usage clairement identifié

Une application Web sur mesure peut devenir pertinente lorsqu’une entreprise a besoin d’un outil accessible depuis le Web et adapté à ses propres utilisateurs, données, règles et processus.

Elle ne doit cependant pas être choisie uniquement parce qu’elle offre davantage de liberté qu’un logiciel standard.

L’analyse des solutions existantes, des intégrations possibles et du processus actuel permet de déterminer si un développement spécifique apporte réellement une réponse plus adaptée.

Lorsque cette décision est justifiée, le cadrage des utilisateurs, données, droits, intégrations, contraintes mobiles et besoins futurs constitue la base du projet.