Préparer le développement d’une application métier performante

Une application métier, on en voit naître de deux façons. Soit quelqu’un arrive avec une idée claire et un cahier des charges déjà bien avancé. Soit, plus souvent, avec un fichier Excel devenu ingérable et une phrase : « il nous faudrait un vrai outil ».

Je suis cheffe de projet chez TheCodingMachine, une agence de développement d’application métier qui conçoit des outils sur mesure depuis 2005. Je me suis aussi formée à la gestion de projet avec la méthode PMP. Mon constat est simple : les projets qui se passent bien ne sont pas ceux qui ont le plus gros budget, ce sont ceux qui ont été bien préparés.

Ce guide vous donne une méthode concrète pour préparer le développement d’une application métier, étape par étape. Pour la rendre vivante, on suivra cet exemple :

Qu’est-ce qu’une application métier ?

Une application métier est un logiciel conçu pour répondre aux besoins spécifiques d’une entreprise ou d’un métier : automatiser un processus, centraliser des données ou faire travailler ensemble plusieurs équipes.

Contrairement à un logiciel grand public, elle colle à votre façon de travailler. Elle peut prendre des formes très différentes. Par exemple :

• un Extranet ou un Intranet pour partager des informations avec vos clients, partenaires ou collaborateurs ;
• un outil qui automatise des tâches administratives ou un processus (validation de devis, suivi d’interventions, gestion des demandes d’achat) ;
• un outil de gestion électronique des documents (GED) ;
• une plateforme qui relie plusieurs groupes d’utilisateurs (vos équipes, vos fournisseurs, vos clients) ;
• un back-office connecté à vos autres outils : ERP, CRM, système d’information comptable.

Souvent, c’est un mélange de tout cela.

Le développement d’une application métier s’inscrit d’ailleurs souvent dans un projet plus large de transformation digitale de l’entreprise.

Pourquoi la préparation est cruciale pour votre projet d’application métier ?

Parce qu’une erreur coûte peu à corriger sur un document, et beaucoup à corriger dans du code. Une règle oubliée pendant le cadrage, c’est une ligne à ajouter. La même règle découverte après la mise en production, c’est du développement, des tests, une nouvelle livraison et parfois des données à reprendre.

Les risques d’un projet mal préparé

Un projet mal préparé dérape presque toujours sur au moins un de ces trois points : le budget, le délai ou l’adoption.

• Le budget explose. Les règles métier implicites (« chez nous, une commande urgente passe toujours avant ») apparaissent en cours de route. Chacune ajoute du développement.
• Le délai glisse. Personne n’a prévu qui valide quoi, ni quand. Les retours arrivent en retard, ou se contredisent.
• L’outil n’est pas utilisé. C’est le risque le plus sous-estimé. Une application conçue sans les utilisateurs finaux ressemble souvent à ce que la direction imagine, pas à ce que les équipes font vraiment. Elles retournent alors à leur fichier Excel.

Les bénéfices d’une phase de cadrage réussie

Une phase de cadrage réussie vous donne trois choses : une vision partagée, un chiffrage fiable et un plan d’action.

• Une vision partagée. Direction, utilisateurs, DSI et prestataire parlent enfin de la même application.
• Un chiffrage fiable. Quand le périmètre est clair, le prestataire chiffre ce qui est réellement demandé. Moins de provisions pour risques, moins d’avenants.
• Un plan d’action. Vous savez ce qui sera livré en premier, quand, et comment le valider.

C’est pourquoi nous proposons souvent un accompagnement dans la phase de cadrage avant de lancer les développements. L’objectif est de vous aider à transformer une idée en solution concrète, chiffrée et réaliste.

Définir les besoins et objectifs de votre application métier

La première étape consiste à comprendre ce que l’application doit changer, pour qui, et comment on saura qu’elle a réussi.

La meilleure façon d’y arriver, c’est de réunir les bonnes personnes autour de la table. Chez TCM, cela passe par un atelier de conception : une ou plusieurs réunions de travail avec vos équipes métier, où l’on part du terrain et pas de la technique.

Identifier les utilisateurs cibles et leurs attentes

Listez tous les profils qui utiliseront l’application, puis allez les voir travailler.

Dans une application métier, il y a rarement un seul type d’utilisateur.

Pour chacun, posez trois questions : que fait-il aujourd’hui ? Qu’est-ce qui lui fait perdre du temps ? Qu’attend-il du nouvel outil ? Une heure passée à côté d’un magasinier pendant une réception vaut souvent plus qu’une réunion de deux heures en salle.

Pensez aussi à ceux qui ne l’utiliseront pas mais seront concernés : qui finance, qui valide, qui assure le support. Un acteur oublié au début devient souvent une demande de changement à la fin.

Lister les fonctionnalités essentielles et prioritaires

Décrivez chaque fonctionnalité du point de vue de l’utilisateur, puis classez-les par priorité.

Un format simple et efficace est la « user story » : En tant que [qui], je veux [quoi] afin de [pourquoi]. Ce n’est pas le seul : un tableau par module (fonctionnalité, utilisateur concerné, règles de gestion, priorité) fonctionne très bien aussi. L’essentiel est que chaque besoin soit compréhensible par le métier comme par les développeurs.

Ensuite, triez. Toutes les fonctionnalités ne sont pas indispensables pour la première version. Une méthode simple consiste à les répartir en trois groupes : indispensable pour lancer l’outil, important mais qui peut attendre quelques semaines, confort pour plus tard. Une première version bien ciblée, livrée vite, vaut mieux qu’un outil complet livré dans 18 mois.

Pour décrire le fonctionnement global, deux outils aident beaucoup : un schéma du processus métier (de la demande d’achat au paiement de la facture), et une « product vision box », une sorte de boîte de produit imaginaire qui résume l’application en une image.

Établir les objectifs mesurables du projet

Fixez 3 à 5 objectifs, avec un chiffre et une échéance. Ils peuvent être de trois types :

• fonctionnels : permettre de nouveaux usages (suivi des commandes en temps réel par les fournisseurs) ;
• techniques : lever une limite de l’outil actuel (un fichier partagé qui plante au-delà de 10 utilisateurs) ;
• de rationalisation : gagner du temps et réduire les coûts (supprimer les ressaisies entre achats et comptabilité).

Ces objectifs serviront plus tard à mesurer le succès du projet. Ils servent aussi, pendant le développement, à trancher entre deux options : celle qui sert le mieux l’objectif l’emporte.

Rédiger un cahier des charges efficace pour votre application

Le cahier des charges rassemble tout ce que vous avez défini : contexte, utilisateurs, fonctionnalités, contraintes, budget et planning. C’est le document de référence entre vous et votre prestataire.

Il est indispensable si vous consultez plusieurs prestataires, mais aussi pour présenter le projet en interne. Pour aller plus loin, téléchargez notre livre blanc pour lancer son application métier.

Les éléments indispensables du cahier des charges

Un bon cahier des charges tient en 10 à 30 pages. Ce qui compte, c’est sa précision, pas sa longueur.

Il contient au minimum :

1. le contexte : votre entreprise, l’existant, ce qui déclenche le projet ;
2. les objectifs chiffrés ;
3. les utilisateurs et leurs rôles ;
4. les fonctionnalités, classées par priorité ;
5. les contraintes techniques, métier et réglementaires ;
6. le budget et le planning souhaités ;
7. les critères de validation : comment saurez-vous que l’outil fonctionne ?

Définir le périmètre fonctionnel et technique

Le périmètre dit ce qui est dans le projet, et surtout ce qui n’y est pas.

Écrire « hors périmètre » est aussi important que décrire les fonctionnalités.

Côté technique, pas besoin d’être développeur. Répondez simplement à quelques questions : l’outil sera-t-il utilisé sur ordinateur, sur mobile, ou les deux ? Avec quels logiciels doit-il échanger des données ? Combien d’utilisateurs en même temps ? Faut-il reprendre des données existantes ?

Chez TCM, ce cahier des charges devient ensuite le point de départ de nos spécifications fonctionnelles. Chaque règle métier reçoit un numéro. Ce numéro suit la règle jusqu’au code et jusqu’aux tests. Rien ne se perd en route.

Intégrer les contraintes métier et réglementaires

Les contraintes métier et réglementaires sont celles qu’on ne découvre jamais trop tôt.

• Contraintes métier : délais légaux, circuits de validation, règles de calcul spécifiques à votre secteur.
• Contraintes réglementaires : RGPD (quelles données personnelles, combien de temps les garder, qui y accède), archivage, traçabilité, règles propres à certains secteurs (santé, finance, bâtiment).

Ce type de contrainte change l’architecture de l’application. Mieux vaut la connaître dès le cadrage.

Choisir les bons outils et technologies pour votre projet

Le choix technique dépend de trois choses : la complexité de vos règles métier, le nombre d’outils à connecter, et la durée de vie attendue de l’application.

Développement sur mesure vs solutions low code

Le low code convient aux besoins simples et standards. Le sur mesure convient aux processus spécifiques, aux intégrations complexes et aux outils qui doivent durer.

Les plateformes low code permettent de créer une application avec des fonctionnalités en glisser-déposer, sans écrire de code ou presque. C’est rapide et peu coûteux pour un formulaire, un petit workflow de validation ou un prototype.

Leurs limites apparaissent vite quand le projet grandit : règles métier complexes, volumes de données importants, connexions avec un ERP, dépendance à un éditeur et à sa grille tarifaire.

Un outil métier sur mesure demande un investissement de départ plus important. En échange, il s’adapte exactement à vos processus, vous appartient, et peut évoluer sans limite imposée.

Il existe aussi une voie hybride : prototyper un parcours en low code pour tester une idée, puis développer la version durable sur mesure.

Sélectionner la stack technique adaptée à vos besoins

La stack technique, c’est l’ensemble des langages et outils utilisés pour construire l’application. Votre prestataire doit vous la proposer, et vous expliquer pourquoi.

Quelques repères pour vous aider à poser les bonnes questions :

• Pour une application web métier, des frameworks éprouvés comme Symfony ou Laravel côté serveur, et React ou Vue côté interface, sont des choix robustes et faciles à maintenir.
• Si l’outil doit aussi fonctionner sur mobile, des technologies comme Flutter ou React Native permettent de développer iOS et Android sur une seule base de code.
• Si vous avez surtout des contenus à gérer (pages, actualités, documents), un système de gestion de contenu comme WordPress peut suffire, éventuellement enrichi de développements spécifiques.

Méfiez-vous des technologies trop récentes ou trop rares : elles compliquent le recrutement et la maintenance. Pour approfondir, lisez notre article pour choisir la bonne technologie pour votre application.

Anticiper l’évolution et la maintenance de l’application

Une application métier vit souvent de nombreuses années. Son coût ne s’arrête pas à la mise en production.

Prévoyez dès le départ :

• les mises à jour de sécurité et de versions (langages, frameworks, serveurs) ;
• les corrections et les petites évolutions demandées par les utilisateurs ;
• un budget annuel pour les nouvelles fonctionnalités.

Posez la question au prestataire dès la consultation : qui assurera la maintenance applicative, avec quels délais d’intervention, et à quel coût ? Une application bien documentée et testée coûte beaucoup moins cher à faire évoluer.

Constituer et organiser l’équipe projet

Un projet d’application métier réussi repose sur une équipe claire des deux côtés : chez vous et chez votre prestataire.

Définir les rôles et responsabilités de chaque intervenant

Chaque rôle doit avoir un nom. « L’équipe » ne valide jamais rien. Une personne, si.

Côté client, trois rôles sont indispensables :

• le sponsor : il porte le projet en interne, arbitre les priorités et le budget ;
• le référent métier (ou product owner) : il connaît le terrain, répond aux questions et valide les livraisons. Prévoyez-lui du temps, souvent une demi-journée à une journée par semaine ;
• le référent technique (souvent la DSI) : il garantit l’intégration avec votre système d’information.

Côté prestataire, vous aurez en général un chef de projet, des développeurs, un designer UX/UI et une personne dédiée à l’assurance qualité.

Un tableau simple qui indique, pour chaque décision, qui la prend, qui est consulté et qui est informé évite beaucoup de flottements.

Impliquer les utilisateurs finaux dès la conception

Les utilisateurs finaux sont vos meilleurs testeurs. Impliquez-les tôt, et régulièrement.

Montrez-leur les maquettes avant le développement. Faites-leur tester chaque livraison. Leurs retours sur l’expérience utilisateur et l’interface utilisateur valent de l’or : un bouton mal placé, un champ inutile, une étape en trop.

C’est aussi la meilleure façon de préparer l’adoption. Des utilisateurs qui ont participé à la conception deviennent les ambassadeurs de l’outil auprès de leurs collègues.

Choisir entre équipe interne, prestataire externe ou mode hybride

Le bon choix dépend de vos compétences internes, de la durée du projet et de votre envie de garder la main.

• Équipe interne : vous gardez toute la maîtrise, mais il faut recruter et retenir des développeurs expérimentés.
• Prestataire externe : vous bénéficiez d’une équipe complète et expérimentée immédiatement, sans recrutement.
• Mode hybride : le prestataire développe, puis transfère progressivement les compétences à votre équipe, ou vos développeurs rejoignent l’équipe du prestataire.

Dans tous les cas, exigez que le code vous appartienne et qu’il soit documenté.

Planifier les étapes de développement et les livrables

Un bon planning découpe le projet en petites étapes, chacune avec un livrable que l’on peut voir, tester et valider.

Découper le projet en phases et sprints

La plupart des projets d’application métier suivent quatre grandes phases : cadrage, conception, développement, puis recette et mise en production. La règle d’or : ne jamais développer pendant des mois sans rien montrer.

C’est ce qu’on appelle l’effet tunnel : le client ne voit l’application qu’à la fin, et découvre trop tard qu’elle ne correspond pas à ce qu’il imaginait. Pour l’éviter, on découpe le développement en livraisons intermédiaires, chacune avec des fonctionnalités utilisables, que vous pouvez tester. Deux façons de faire, selon votre contrat :

• En agile, le développement avance par sprints de 2 à 3 semaines. À la fin de chaque sprint, une démonstration montre ce qui a été fait, et vous ajustez les priorités pour le sprint suivant. Le périmètre reste souple.
• Au forfait, le périmètre et le prix sont fixés à l’avance. Ce n’est pas une raison pour tout livrer d’un bloc : le planning prévoit plusieurs lots, livrés et recettés les uns après les autres (par exemple : commandes, puis réceptions, puis portail fournisseurs). Vous gardez la visibilité d’un projet agile, avec l’engagement de budget d’un forfait.

Dans les deux cas, chaque livraison est un rendez-vous : on montre, vous testez, on corrige avant d’aller plus loin.

Cette gestion de projet en utilisant des outils partagés (tableau de suivi, outil de tickets) vous donne une vision claire de l’avancement, à tout moment.

Définir les jalons et critères de validation

Un jalon, c’est un point de passage où l’on vérifie que tout va bien avant de continuer.
Les jalons classiques sont : validation du cahier des charges, validation des maquettes, chaque livraison intermédiaire, fin de recette, mise en production.

Pour chacun, écrivez à l’avance ce qui permet de dire « c’est validé ».

Prévoir les phases de tests et de recette utilisateur

La recette, c’est le moment où vous vérifiez que l’application fait bien ce qui était prévu. Elle se prépare dès le cadrage.

Les critères de validation deviennent des scénarios de test. Pour une application métier de taille moyenne, le cahier de recette compte facilement une centaine de cas de test, classés par module. Cela paraît beaucoup. C’est surtout la garantie que rien n’est oublié.

Prévoyez du temps chez vous pour cette recette : ce sont vos équipes qui testent avec leurs vrais cas. Pour en savoir plus, voir notre article sur les tests fonctionnels et la recette.

Anticiper la qualité, la sécurité et les performances

La qualité, la sécurité et les performances ne s’ajoutent pas à la fin. Elles se décident au début.

Intégrer les bonnes pratiques de développement dès le départ

Demandez à votre prestataire comment il garantit la qualité du code, pas seulement s’il le fait.

Les bonnes pratiques à attendre :

• des tests automatisés, qui vérifient à chaque modification que rien n’est cassé ;
• une relecture du code par un autre développeur avant chaque mise en ligne ;
• un déploiement automatisé, qui réduit les erreurs humaines ;
• une documentation à jour, pour que n’importe quel développeur puisse reprendre le projet.

Ces pratiques coûtent un peu de temps au départ. Elles en font gagner beaucoup à chaque nouvelle fonctionnalité.

Définir les exigences de sécurité et de conformité

Une application métier manipule souvent des données sensibles : clients, prix, contrats, salariés.

Définissez dès le cadrage :

• qui a accès à quoi (gestion des rôles et des droits) ;
• comment les utilisateurs se connectent (authentification forte, connexion avec les comptes de l’entreprise) ;
• où sont hébergées les données (en France, en Europe) ;
• comment l’application respecte le RGPD.

Prévoyez aussi un audit de sécurité avant la mise en production pour les outils les plus sensibles.

Prévoir les tests de performance et de charge

Une application rapide avec 5 utilisateurs peut ralentir avec 200. Les tests de charge permettent de le savoir avant vos utilisateurs.

Indiquez dans le cahier des charges le nombre d’utilisateurs simultanés attendus, les volumes de données (nombre de commandes par an, par exemple) et les pics d’activité (clôture mensuelle, soldes, inventaire). Le prestataire pourra dimensionner l’application en conséquence, et la tester dans des conditions réalistes.

Préparer la mise en production et l’adoption utilisateur

Une application métier réussie est une application utilisée. La mise en production n’est pas la fin du projet, c’est le début de sa vie.

Planifier la formation des utilisateurs

Prévoyez une formation adaptée à chaque profil, au plus près de la date de lancement.

Quelques formats qui fonctionnent bien :

• une session de formation courte (1 à 2 heures) par groupe d’utilisateurs ;
• des ambassadeurs formés en premier, qui aident ensuite leurs collègues ;
• des tutoriels vidéo de 2 minutes, accessibles depuis l’application ;
• une aide contextuelle directement dans l’interface.

Une interface bien conçue réduit le besoin de formation. Les utilisateurs sont habitués aux applications grand public et aux réseaux sociaux : ils attendent la même simplicité de leurs outils professionnels.

Organiser le déploiement et la migration des données

La reprise des données existantes est souvent sous-estimée. Commencez-la tôt.

Pour le déploiement, deux options :

• tout le monde en même temps, plus simple mais plus risqué ;
• par étapes (un site, puis un autre ; un groupe d’utilisateurs, puis un autre), plus sûr pour les outils critiques.

Prévoyez une période pendant laquelle l’ancien et le nouvel outil coexistent, et une équipe disponible pour répondre aux questions les premiers jours.

Mettre en place le suivi et l’évolution continue

Après le lancement, mesurez, écoutez, améliorez.

Reprenez les objectifs fixés au départ et mesurez-les après 1 mois, 3 mois, 6 mois. Mettez en place un moyen simple de recueillir les retours utilisateurs : un formulaire dans l’application, un point mensuel avec les référents métier.

Ces retours alimentent la liste des évolutions. Intégrer les retours utilisateurs régulièrement, c’est ce qui fait qu’un outil reste utile dans le temps, au lieu de devenir le prochain fichier Excel qu’on contourne.

 Questions fréquentes sur la préparation d’une application métier

Votre application métier

Un projet, même encore flou ?

Parlons-en. On vous aide à transformer votre idée en projet clair, chiffré et réaliste, avant d’écrire la moindre ligne de code.

✓Des ateliers pour cadrer le besoin

✓Un cahier des charges et des maquettes

✓Un chiffrage détaillé

✓Un code qui vous appartient

Parler de mon projet

Publié le 2 juin 2022

---