Une application métier sur mesure doit répondre à un besoin très précis : automatiser une tâche, faciliter le suivi d’une activité, centraliser des données, etc. Mais une application techniquement fonctionnelle ne garantit pas pour autant la réussite du projet.
Des difficultés apparaîtront tôt ou tard si le besoin initial est mal défini, si les pratiques réelles des utilisateurs sont insuffisamment prises en compte ou si l’outil s’intègre mal à l’écosystème existant.
La réussite repose donc sur une démarche qui associe compréhension du métier, cadrage fonctionnel, conception, choix technologiques et développement. Elle se poursuit avec les tests, le déploiement et le suivi de l’application une fois celle-ci mise en production. Chaque étape doit permettre de vérifier que la solution reste alignée avec les besoins et les objectifs de l’entreprise. On vous explique !
Avant de réfléchir aux fonctionnalités ou aux choix techniques, il faut comprendre précisément le fonctionnement de l’entreprise, les objectifs, les contraintes, les usages métier et le problème auquel l’application doit répondre. Ce travail de cadrage permet de concevoir une application réellement adaptée.
Une demande formulée par un client ne correspond pas nécessairement à la meilleure solution pour répondre à son besoin. Lorsqu’un client nous demande, par exemple, « un tableau avec 25 colonnes pour un projet X », nous ne partons pas du principe que cette solution est la bonne.
Chez Adimeo, nous préférons d’abord chercher à comprendre ce que le client cherche à accomplir pour identifier le besoin réel : « Quel est votre objectif ? » ou « Quel problème cherchez-vous à résoudre ? ».
Grâce aux explications du client, le besoin réel apparaît plus clairement, par exemple, identifier rapidement les dossiers en retard. À partir de cet objectif, d’autres solutions plus adaptées peuvent être envisagées. Plutôt qu’un lourd tableau de 25 colonnes, la meilleure solution serait un tableau ne présentant que les colonnes essentielles, complété par des filtres, un tri sur le statut des dossiers ou un tableau de bord mettant en évidence les dossiers en retard.
Cette approche permet de ne pas confondre le besoin métier et la solution technique. Elle vise à comprendre les objectifs et les contraintes avant de déterminer la manière d’y répondre.
La compréhension du besoin passe également par l’analyse des méthodes de travail actuelles et l’identification des problématiques métier.
Pour cela, des ateliers avec les équipes métier permettent de reconstituer les différentes étapes d’un processus, mais aussi d’identifier les tâches répétitives, les points de blocage et les possibilités d’amélioration.
L’objectif n’est pas simplement de documenter l’existant pour le reproduire dans la future application. Au contraire, il s’agit aussi de comprendre comment les collaborateurs travaillent réellement au quotidien afin de ne pas transposer des processus déjà inefficaces dans un nouvel outil.
Cette analyse doit également permettre de comprendre les enjeux opérationnels derrière les données manipulées.
Prenons un cas client concret pour lequel le taux de remplissage d’une benne constitue un indicateur clé pour anticiper son remplacement lorsqu’il atteint un certain seuil. Or, le taux de remplissage seul est inutile. Il doit être associé à une date pour avoir une vision plus précise.
De plus, si une benne était remplie à 50 % hier et qu’elle est à 90 % aujourd’hui, la valeur d’hier n’a plus réellement d’intérêt pour les équipes. Ce qui compte réellement est l’information la plus récente, car elle conditionne l’action à mener.
Comprendre ce fonctionnement métier nous permet de concevoir une application qui met en avant les informations réellement utiles, plutôt que d’afficher un historique dont les collaborateurs n’ont pas besoin.
Les futurs utilisateurs doivent être associés au projet suffisamment tôt pour faire remonter leurs besoins, leurs contraintes de terrain et les gains attendus. Leurs retours permettent notamment de confronter les choix envisagés aux pratiques quotidiennes et d’identifier des problématiques ou enjeux qui pourraient ne pas apparaître dans les seuls échanges avec les responsables du projet.
De plus, cette participation facilite aussi l’adoption de l’application lors de sa mise en production et limite les risques d’erreurs de conception. Les applications métiers doivent en effet être pensées pour les personnes qui l’utiliseront concrètement et dans les conditions réelles de leur activité.
L’erreur fréquente est d’impliquer les utilisateurs métiers uniquement lors de la phase de test. Selon nous, ils doivent faire partie du projet dès le cadrage et durant tout le projet (validation de l’interface utilisateur, test de l’application lors des grandes étapes de développement, etc.). Cela permet de recueillir leurs retours en continu, d’ajuster l’outil si nécessaire et de les familiariser progressivement avec son utilisation, plutôt que de leur faire découvrir un outil finalisé de A à Z uniquement en fin de projet.
Une fois le besoin métier identifié, il faut traduire les attentes des utilisateurs en éléments concrets pour concevoir une application adaptée. Cette étape permet de préciser les fonctionnalités, les parcours utilisateurs, les contraintes d’intégration et les choix techniques à prendre en compte.
Le cadrage fonctionnel consiste à définir précisément les fonctionnalités nécessaires, les priorités et les règles de gestion des applications métiers. Il permet également de formaliser le périmètre du projet afin de limiter les dérives de budget et de planning, et ce, avant tout développement.
Il peut être pertinent de découper le projet en plusieurs lots avec un premier lot regroupant les fonctionnalités essentielles, puis des lots complémentaires consacrés aux fonctionnalités secondaires.
Cette approche permet souvent de respecter les délais tout en conservant une vision d’évolution à long terme.
Pour que l’application soit utile et facilement adoptée, son interface doit être intuitive et donc, être conçue en tenant compte des habitudes et des contraintes des utilisateurs.
Les parcours utilisateurs doivent être suffisamment simples pour permettre de réaliser les tâches avec le moins d’actions possible et faciliter la prise en main de l’outil.
De plus, les contraintes du terrain doivent également être intégrées dès la conception. Si des collaborateurs doivent, par exemple, se déplacer dans des zones sans connexion Internet pour remplir un questionnaire, l’application doit pouvoir fonctionner hors ligne et synchroniser les données lorsque la connexion est rétablie.
Il est donc essentiel de créer une maquette fonctionnelle pour valider l’expérience utilisateur, qui intègre simplicité, ergonomie, accessibilité et responsive design pour être utilisable sur différents écrans, ainsi que cohérence graphique pour une meilleure lisibilité et compréhension.
Certaines applications métiers doivent pouvoir s’intégrer dans l’environnement informatique existant. Il faut donc identifier en amont les autres applications avec lesquelles elles devront échanger des données et les éventuelles interfaces nécessaires.
Cette réflexion nous évite de concevoir une application isolée du reste du système d’information et nous permet de prendre en compte les contraintes d’intégration dès la conception du projet.
En matière d’architecture, une approche monolithique est plus simple à mettre en place, mais elle peut être moins flexible à long terme. A contrario, une architecture en microservices offre une meilleure scalabilité, mais elle est plus complexe.
De plus, l’architecture doit pouvoir évoluer dans le temps. Il faut donc anticiper les évolutions futures, comme de nouvelles fonctionnalités, pour éviter de créer une solution rapidement utilisable, mais coûteuse à maintenir ou à faire évoluer par la suite.
Les choix techniques doivent rester au service du besoin métier :
Il faut bien retenir qu’une application métier performante sur le plan technique, mais complexe à utiliser ou difficile à maintenir peut compromettre la réussite du projet.
De même, il faut définir si le support technique et les mises à jour seront assurés en interne par l’entreprise ou externalisés à un prestataire dans le cadre de la maintenance de l’application métier ou encore à la manière de gérer la montée en charge en cas d’augmentation du nombre de collaborateurs.
En fonction du projet d’application métier, il nous faut alors choisir la méthode la plus adaptée : développement avec approche Agile ou avec approche en cycle en V ou en W.
Lorsque les besoins sont susceptibles d’évoluer, nos experts Adimeo privilégient une méthode Agile pour leurs projets d’application métier. Le développement est alors découpé en sprints, avec des réunions de planification, l’ajout de nouvelles user stories si nécessaire et des rétrospectives régulières.
À la fin de chaque sprint, le client découvre une version fonctionnelle de l’application. Il peut ainsi vérifier rapidement que le produit correspond à ses attentes et aux contraintes du terrain, puis ajuster les priorités avant de poursuivre le développement.
Cette façon de travailler est particulièrement adaptée lorsque le client n’a pas encore une vision totalement précise de ses besoins. Les échanges réguliers permettent de préciser certains usages, de faire émerger de nouvelles attentes et de réorienter le développement si nécessaire. Il est ainsi possible de privilégier une fonctionnalité devenue prioritaire ou, au contraire, de reporter une fonctionnalité devenue secondaire.
L’approche demande cependant davantage de temps d’échanges et de suivi, ce qui peut augmenter le coût du projet.
Pour un développement en cycle en V ou en W, les besoins du projet doivent être définis dès le départ et les validations interviennent principalement à des étapes ultérieures. Cette approche est plus rigide, mais convient à certains secteurs réglementés.
Il ne s’agit pas de considérer le développement Agile comme systématiquement préférable, mais de choisir une organisation adaptée au niveau d’incertitude et aux contraintes du projet.
Les tests permettent de vérifier que l’application fonctionne correctement, mais aussi qu’elle répond aux besoins pour lesquels elle a été conçue. La stratégie de test doit être adaptée à la méthode de gestion de projet choisie et tenir compte des usages réels du métier.
Comme nous le disions, en méthode Agile, les tests utilisateurs peuvent être réalisés régulièrement à la fin de chaque sprint. Les fonctionnalités sont ainsi validées au fur et à mesure du développement, ce qui permet d’identifier rapidement les écarts et d’ajuster les développements à venir.
Mais les retours obtenus lors des différents sprints permettent surtout de prendre des décisions plus tôt, avant que le développement ne soit trop avancé, pour concentrer les efforts sur les besoins les plus importants.
Ainsi, l’avantage de la méthode Agile est qu’elle évite de développer pendant plusieurs mois une solution qui ne répond finalement pas ou plus aux attentes. Les modifications sont réalisées progressivement, avant que les choix techniques ne deviennent trop coûteux à remettre en question.
Pour autant, une approche itérative (Agile) ne signifie pas que le périmètre du projet peut évoluer sans limites. Chaque modification doit être confrontée aux priorités, aux contraintes et aux ressources disponibles.
En cycle en V ou en W, les tests utilisateurs interviennent principalement après le développement, lors des phases de recette fonctionnelle. Les utilisateurs vérifient alors que l’application correspond au cahier des charges initial avant sa mise en production.
Cette différence dans le calendrier des tests entraîne une conséquence importante : plus une anomalie ou une erreur de conception est détectée tardivement, plus sa correction peut être coûteuse. Ainsi, en cycle en V, une erreur identifiée lors de la recette peut nécessiter de revoir des choix fonctionnels ou techniques déjà réalisés.
Les utilisateurs clés (référents métier, utilisateurs finaux, responsables d’équipe ou autres profils concernés) doivent bien évidemment être impliqués dans la validation de l’application.
Leur rôle ne consiste pas seulement à signaler des dysfonctionnements techniques. Leur expérience permet également de vérifier que les fonctionnalités correspondent aux pratiques du terrain et que les règles de gestion ont été correctement prises en compte.
À cette fin, les scénarios de test doivent reproduire autant que possible les situations auxquelles les utilisateurs seront réellement confrontés. Il ne suffit donc pas de vérifier que chaque fonctionnalité fonctionne isolément.
Les tests peuvent notamment couvrir :
Cette approche permet de vérifier le comportement de l’application dans des situations proches de son utilisation quotidienne et de détecter des problèmes qui ne seraient pas nécessairement visibles avec des tests uniquement techniques.
De leur côté, les développeurs Adimeo testent l’application au regard des spécifications fonctionnelles définies par le chef de projet à la suite des échanges avec le client afin de vérifier que les différents scénarios et fonctionnalités métier se comportent comme prévu. Ces vérifications peuvent être réalisées manuellement ou être automatisées lorsque, par exemple au moyen de tests unitaires et fonctionnels.
Les anomalies et les demandes d’évolution doivent ensuite être documentées afin de pouvoir prioriser les corrections avant le déploiement. Toutes les demandes ne nécessitent pas nécessairement une modification immédiate, leur traitement doit tenir compte de leur impact et des priorités du projet.
Le déploiement d’applications métiers ne se limite pas à leur mise en production. L’arrivée d’un nouvel outil peut modifier certaines habitudes de travail. Les utilisateurs doivent donc être préparés en amont à son utilisation et disposer des ressources nécessaires pour favoriser l’adoption de l’outil.
La transition peut s’appuyer sur :
Une phase de stabilisation doit également être prévue après le développement. Car, même lorsque l’application a été testée et validée, son utilisation dans les conditions réelles peut faire apparaître des situations qui n’avaient pas été identifiées auparavant : volumes de données plus importants, davantage d’utilisateurs connectés simultanément ou cas métiers particuliers.
Cette période permet donc de traiter rapidement les éventuels problèmes rencontrés et de vérifier que l’application fonctionne correctement dans son environnement réel. Elle facilite aussi l’identification des premiers ajustements à prévoir à partir des retours des utilisateurs.
La mise en production ne marque pas nécessairement la fin du projet. Une fois l’application utilisée au quotidien, il faut vérifier qu’elle est effectivement adoptée, qu’elle répond aux besoins métiers et qu’elle reste adaptée aux évolutions de l’entreprise. Cette phase de suivi est indispensable.
L’organisation de points de suivi avec le client et les utilisateurs après le déploiement permet d’identifier rapidement les difficultés rencontrées. Les indicateurs de satisfaction, les retours adressés au support ou des échanges réguliers avec les équipes métier peuvent faire apparaître des irritants qui n’avaient pas été détectés pendant les tests.
Une fonctionnalité peut être techniquement opérationnelle sans être réellement utilisée si elle ne répond pas suffisamment aux habitudes ou aux besoins du terrain.
Ce suivi permet aussi de déterminer si les bénéfices attendus sont effectivement au rendez-vous et d’identifier les éventuels écarts. L’analyse du retour sur investissement peut ensuite compléter cette évaluation en mettant en regard les gains obtenus et les coûts du projet.
Les besoins d’une entreprise évoluent, tout comme ses processus, ses outils et ses contraintes. Les points de suivi avec les utilisateurs et les équipes métier doivent permettre d’identifier de nouveaux besoins ou des pistes d’amélioration.
Ainsi, l’application métier peut évoluer progressivement plutôt que de devenir obsolète au fil du temps. Cette démarche suppose notamment de prévoir les corrections et les évolutions nécessaires après la mise en production. On entre ici dans le cadre de la maintenance de l’application métier.
Comme vous le comprenez, réussir un projet d’application métier ne consiste donc pas seulement à livrer un outil fonctionnel. La compréhension du besoin, l’implication des utilisateurs, les choix de conception et la façon de conduire le développement conditionnent directement la pertinence de la solution finale. Le suivi après la mise en production permet ensuite de vérifier que les applications métiers continuent de répondre aux réalités du terrain. C’est cette continuité entre les besoins du métier, les choix de conception et les usages qui permet de construire des applications réellement utiles et durables.
Crédit photo : PeopleImages