Combien coûte une application web métier ?

Le prix d’un site vitrine peut souvent être rapproché de formats connus. Celui d’un outil métier dépend davantage de vos règles de gestion, de vos données, des connexions à l'existant et du niveau de criticité attendu. Ces outils sont conçus autour de votre organisation et de vos contraintes particulières. Des fourchettes circulent, mais elles sont difficiles à comparer tant que l’on ne sait pas précisément ce qu’elles comprennent. C'est ce qui rend la question délicate, et c’est pourquoi deux devis apparemment semblables peuvent en réalité couvrir des prestations très différentes.

Voici nos fourchettes, ce qui place un projet en bas ou en haut de chacune, et le calcul qui permet de savoir si l'outil sera rentable dans votre cas.

Elles décrivent ce que nous facturons, pas une moyenne de marché. Le cadrage, la conception des écrans, la reprise des données existantes, la formation et le mois de stabilisation sont compris dans les trois cas.

• Premier périmètre en production : de 8 000 à 18 000 € HT. Un processus, un type d'utilisateur, les écrans strictement nécessaires. C'est la forme que nous recommandons pour commencer, parce qu'elle se met en service vite et qu'elle apprend beaucoup sur la suite.
• Outil métier complet : de 18 000 à 45 000 € HT. Plusieurs processus, des rôles aux droits distincts, des règles de gestion nombreuses et au moins une connexion à vos outils existants.
• Produit multi-clients : à partir de 45 000 € HT. Quand vous commercialisez l'outil à votre tour, il faut isoler les données de chaque client, gérer la facturation à l'usage et administrer l'ensemble.

Ces montants sont hors taxes et hors coût de possession. Ils varient dans les deux sens selon vos attentes, et c'est le rôle du cadrage de vous le dire avant le devis plutôt qu'après.

Pour un site, on compte les pages. Pour un outil métier, ce compte ne veut rien dire : le travail se cache dans les situations qui sortent de la règle générale. Prenez la validation d'une commande. Décrite en réunion, elle tient en une phrase : le responsable valide et la commande part. Dans les faits, il y a le client qui a négocié un tarif à part, la commande urgente qui doit partir sans attendre, le remplaçant qui valide pendant les congés, et la fin de mois où la comptabilité veut tout figer. Quatre situations, quatre comportements à concevoir, à développer et à tester.

Ces situations ne sont pas des détails : ce sont elles qui font le budget, et elles expliquent pourquoi un logiciel du marché finit souvent par coincer. Il couvre le fonctionnement standard, puis atteint ses limites sur une validation, une permission ou une connexion à vos autres outils. C'est à ce moment qu'un tableur réapparaît à côté du logiciel, pour traiter ce qu'il ne sait pas faire.

• Les droits d'accès. Qui peut consulter quoi, qui peut supprimer, modifier ou créer quoi. Tant que tout le monde dispose d'un accès en lecture et en écriture à toutes les données, l'outil se conçoit vite. Par exemple, dès que le commercial ne voit que ses clients, que le comptable lit les montants sans pouvoir les corriger et que seul le responsable peut valider, chaque combinaison doit être conçue, développée et vérifiée.
• La densité des règles de gestion. Un calcul tarifaire à quelques conditions ne demande pas le même travail qu'une grille où les conditions se combinent entre elles. Un client a 10 % de remise au titre de son contrat annuel, et le produit qu'il commande est déjà soldé à 15 %. Les deux remises s'additionnent-elles ? La plus forte l'emporte-t-elle ? Aucune réponse ne va de soi, et chacune se traduit par une règle de plus à écrire et à vérifier.
• Les connexions à l'existant. Faire dialoguer deux logiciels suppose que celui d'en face sache parler. Certains prévoient une porte d'entrée documentée pour les autres outils (une API), et la connexion se fait vite. D'autres ne savent qu'échanger des fichiers à heures fixes (export CSV, flux XML) : cela fonctionne, mais il faut s'accorder sur le format et renoncer au temps réel. D'autres enfin n'ouvrent rien sans l'accord de leur éditeur, qui peut refuser. C'est le poste le plus difficile à estimer tant qu'on n'a pas vérifié dans quel cas on se trouve.
• La reprise des données. L'historique est rarement exploitable tel quel. Le même client y figure sous trois orthographes, des informations que le nouvel outil réclame n'ont jamais été saisies, et une partie des lignes anciennes n'est plus fiable. Il faut donc décider ce qu'on reprend et ce qu'on laisse, corriger le reste, puis vérifier que les totaux d'arrivée correspondent à ceux du départ. Ce travail est souvent sous-estimé parce qu'il ne se voit pas à l'écran.
• Le niveau de criticité. Un outil dont la panne arrête l'activité ne se construit pas comme un outil de confort. La surveillance et les sauvegardes peuvent s'ajouter plus tard. Ce qui se décide à la conception, c'est le comportement en cas d'interruption : si le serveur tombe pendant l'enregistrement d'une commande, elle doit être retrouvée entière ou pas du tout, jamais en double.

• L'hébergement, plus exigeant que pour un site : une application qui porte votre activité demande des sauvegardes testées et une supervision.
• La maintenance, que nous chiffrons entre 12 et 20 % du coût de développement par an selon la criticité de l'outil.
• Les évolutions. Un outil métier suit votre organisation ; si celle-ci change et pas lui, il redevient le problème qu'il avait résolu.

Avant de comparer des devis, comparez le coût de l'outil à celui de la situation actuelle. Le temps passé chaque semaine en saisie, en vérification et en correction d'erreurs a un coût que personne ne facture mais que tout le monde paie. C'est cette comparaison qui dit si le projet est justifié, pas le montant du devis pris isolément.

Nous mettons un calculateur à votre disposition pour faire cette comparaison à partir de vos propres chiffres. Il raisonne sur trois hypothèses de gain que vous fixez vous-même, et il peut parfaitement conclure que le projet ne vaut pas la peine. C'est aussi une réponse utile.