Développement d'applications métier

Choisir un développeur d'applications métier

Une application métier remplace souvent un ensemble de tableurs, de fichiers partagés et de logiciels généralistes qui ne se parlent pas. Le développeur qui la conçoit doit donc comprendre votre façon de travailler avant de penser technologie. Cette page vous aide à repérer les prestataires capables de mener ce type de projet, à poser les bonnes questions et à vérifier ce qui compte vraiment avant de signer.

Ce que recouvre le métier

Le développement d'applications métier couvre des outils conçus pour une organisation précise : gestion de stocks, suivi de chantiers, planification d'interventions, facturation sur mesure, portails clients, outils internes de production. Certains prestataires partent d'une plateforme existante et la paramètrent, d'autres écrivent le logiciel entièrement à partir de zéro. Aucune approche n'est meilleure par principe. Tout dépend de la complexité des règles métier et de la durée de vie que vous attendez de l'outil.

Sur une même liste de prestataires, vous trouverez donc des profils très différents : développeurs indépendants, petites équipes spécialisées, sociétés d'ingénierie logicielle plus structurées, ou agences qui combinent conception, design et intégration. La taille ne dit rien de la qualité. Ce qui compte, c'est la capacité à comprendre votre métier et à tenir un calendrier.

Les questions à poser avant de comparer les devis

Un devis n'a de sens que si les deux parties parlent du même périmètre. Avant de comparer les montants, demandez à chaque prestataire comment il décrit le besoin qu'il a compris. Un bon interlocuteur reformule vos processus, pose des questions sur les exceptions, les volumes et les personnes qui utiliseront l'outil. Un interlocuteur qui répond tout de suite par une solution toute faite sans avoir posé de question mérite votre prudence.

Interrogez-le aussi sur la façon dont il travaille : découpage en étapes, présentations intermédiaires, tests par les futurs utilisateurs, gestion des changements en cours de projet. Un projet qui avance par étapes courtes et validées limite les mauvaises surprises beaucoup mieux qu'un forfait signé d'un seul bloc.

Les documents et engagements à vérifier

Certains points relèvent du contrat et non de la technique, et ils pèsent lourd sur la durée. Demandez systématiquement :

• un extrait Kbis et les coordonnées de la structure juridique qui signera ;
• une description écrite des livrables, avec les fonctionnalités incluses et celles qui ne le sont pas ;
• les conditions de propriété du code source et des données une fois le projet livré ;
• les modalités de maintenance, de correction des anomalies et d'hébergement après la mise en service ;
• la façon dont les données personnelles sont traitées, avec un engagement de conformité au RGPD ;
• les moyens de sauvegarde et de restauration prévus.

Ne vous contentez pas d'une liste de technologies. Un prestataire qui utilise un langage ou un framework populaire peut livrer un outil fragile, tandis qu'un autre, moins connu, peut produire un logiciel solide et bien documenté. Ce qui fait la différence, c'est la rigueur des tests, la documentation et la capacité à reprendre le code plus tard.

Préparer votre besoin pour obtenir des offres comparables

Un cahier des charges, même court, change la qualité des réponses. Décrivez les personnes qui utiliseront l'outil, les tâches qu'elles réalisent aujourd'hui, les outils qu'elles remplacent et les données qu'elles manipulent. Indiquez ce qui est indispensable et ce qui relève du souhaitable. Précisez enfin votre calendrier et votre budget de départ, même approximatif : un prestataire honnête vous dira alors ce qui est réaliste et ce qui ne l'est pas.

Demandez à plusieurs prestataires de répondre au même document. Vous verrez vite qui a réellement lu votre besoin et qui envoie un devis type.

Après la signature : garder la main sur l'outil

Une application métier vit plusieurs années, et ses règles évoluent avec votre activité. Prévoyez dès le départ une recette réalisée par de vraies personnes sur des cas réels, une formation des équipes et une documentation utilisable par quelqu'un d'autre que son auteur. C'est aussi le moment de définir qui répondra aux demandes d'évolution et dans quel délai. Un outil dont personne ne sait plus modifier le code devient vite un actif bloqué, même s'il fonctionne parfaitement le jour de sa livraison.