Prix d'une application métier : décrypter un devis sans se faire piéger

Est-ce que valider la commande réserve du stock ? Si oui, que fait le système quand deux commerciaux valident la même pièce à trois secondes d’intervalle ? Est-ce que ça génère un PDF ? Est-ce que ce PDF part par mail, et si le mail échoue, qui est prévenu ? Est-ce que ça crée une écriture dans votre outil comptable ? Est-ce que le client peut annuler après validation, et dans ce cas est-ce qu’on rembourse, on crée un avoir, on remet le stock en circulation ?

Le même bouton peut valoir 300 euros ou 15 000 euros. Le prestataire qui vous a chiffré 8 000 a lu « un bouton ». Celui qui vous a chiffré 90 000 a supposé toute la chaîne, y compris les cas d’erreur, parce qu’il sait qu’il devra les traiter un jour.

Ce que vous pouvez faire tout de suite : reprenez les trois ou quatre actions principales de votre future application et, pour chacune, écrivez ce qui doit se passer juste après, y compris quand ça se passe mal. Une page suffit. Ce document vaut plus qu’un cahier des charges de 80 pages, et il rend les devis comparables.

Les cinq variables qui font vraiment bouger le prix

Le périmètre réel, pas le périmètre annoncé

« Une application de gestion de chantier » ne veut rien dire. Six écrans ou quarante-cinq écrans, c’est le même intitulé et un facteur dix sur la facture. Demandez systématiquement la liste des écrans prévus. Un prestataire qui ne peut pas vous la donner n’a pas chiffré votre projet, il a chiffré une impression.

Le nombre de rôles utilisateurs

C’est le multiplicateur le plus sous-estimé. Une application avec un seul type d’utilisateur est un objet simple. Ajoutez un rôle administrateur, un rôle client externe, un rôle sous-traitant en lecture seule, et vous ne multipliez pas le travail par quatre : vous ajoutez la gestion des droits, les écrans propres à chaque rôle, et la question « qui a le droit de voir quoi » sur chaque donnée de l’application.

Un cas typique : une PME de 12 personnes demande un outil de suivi d’interventions. Version un rôle (les salariés internes), c’est un projet court. Version avec accès client pour suivre son intervention en temps réel, c’est un autre projet, avec authentification externe, données cloisonnées, et un support à assurer auprès de gens qui ne sont pas vos salariés.

Commencez avec un rôle. Ajoutez les autres quand le premier tourne.

Les intégrations avec vos outils existants

Brancher une application sur un logiciel tiers coûte entre zéro et très cher, selon un critère que vous pouvez vérifier vous-même : est-ce que l’outil en question a une API documentée et publique ?

Si votre logiciel de facturation a une API moderne, la connexion est une affaire de jours. Si c’est un progiciel installé sur un serveur dans votre local technique, avec une base de données qu’un intégrateur a modifiée en 2014 et dont plus personne n’a le schéma, le chiffrage explose et personne ne peut le garantir à l’avance.

Faites la liste de vos outils et cherchez « [nom du logiciel] API documentation ». Le résultat de cette recherche de dix minutes change la nature de la conversation avec vos prestataires.

La reprise de données

C’est le poste qui apparaît rarement dans les devis bas et qui fait dérailler les projets en fin de parcours. Vous avez huit ans d’historique dans un fichier Excel avec des colonnes ajoutées au fil du temps, des noms de clients écrits de quatre façons différentes, des cellules fusionnées, des dates au format texte. Nettoyer et importer ça n’est pas du développement, c’est de l’archéologie, et ça se compte en jours.

Deux options honnêtes : payer pour la reprise, ou décider de démarrer avec les données de l’année en cours et garder l’ancien fichier en lecture. La deuxième est souvent la bonne, et elle est gratuite.

Le modèle de facturation

Un devis en régie (facturation au temps passé, souvent affiché comme un TJM) et un devis au forfait ne sont pas comparables, même si le montant final est proche.

En régie, le montant affiché est une estimation. Il n’engage pas grand-chose. Et il y a un problème structurel que peu de gens formulent : plus le prestataire travaille vite, moins il facture. Ce n’est pas une accusation de malhonnêteté, c’est juste une mécanique. Le modèle ne récompense pas la vitesse.

Au forfait, le prestataire porte le risque de dérapage. Il a donc intérêt à cadrer sérieusement avant de signer, et à livrer vite. En contrepartie, il refusera de chiffrer un périmètre flou, ce qui est plutôt un bon signe.

Pour aller dans le détail des postes de coût et de leur poids respectif, 5000.dev publie une décomposition assez précise de ce qui se cache derrière un devis d’application web, avec des fourchettes par type de projet. Utile à lire avant de recevoir vos propres propositions.

Pourquoi les gros devis sont souvent le mauvais choix, même quand ils sont justes ?

Un devis à 200 000 euros n’est pas forcément gonflé. Il correspond souvent à ce que vous avez décrit. Le problème est ailleurs : il engage votre trésorerie sur un projet dont vous ne verrez rien avant plusieurs mois, et dont vous ne savez pas encore s’il correspond à vos usages réels.

Les projets informatiques échouent rarement sur la technique. Ils échouent parce qu’au bout de six mois, l’entreprise a changé, le processus a évolué, et l’application livrée correspond à l’organisation d’il y a six mois.

La sortie n’est pas de négocier le devis à la baisse. C’est de changer la question posée.

Découpez avant de demander un devis

Au lieu de demander « combien pour mon application », demandez « combien pour la première partie utilisable en production ».

La règle de découpe est simple : un premier livrable doit tenir sur un utilisateur, un flux principal, et un résultat mesurable. Tout le reste attend.

Reprenons l’outil de suivi d’interventions. Le projet complet contient la planification, l’application mobile terrain, la signature client, la facturation automatique, un tableau de bord de rentabilité et un portail client. Le premier bloc utile, c’est : les techniciens saisissent leur intervention sur leur téléphone, et le bureau voit la liste du jour. Rien d’autre. Ça remplace déjà les photos de bons de commande envoyées par messagerie, et ça se livre en quelques semaines.

Ce que vous gagnez : vous voyez le prestataire travailler avant d’engager le gros du budget, vos équipes utilisent quelque chose de réel et vous disent ce qui manque vraiment (ce n’est jamais ce que vous aviez prévu), et vous pouvez arrêter après le premier bloc si ça ne prend pas.

Un point à vérifier dans le contrat, quel que soit le modèle choisi : la propriété du code source. Si elle n’est pas écrite noir sur blanc, elle n’est pas acquise, et vous serez dépendant du prestataire pour la moindre évolution.

Votre prochaine étape

Prenez une heure cette semaine et produisez une page, pas plus, contenant : la liste des écrans que vous imaginez, le nombre de types d’utilisateurs distincts, les outils auxquels l’application devra se connecter, et ce que vous faites de vos données existantes.

Envoyez cette page à vos prestataires en leur demandant de chiffrer uniquement le premier bloc livrable, au forfait, avec la propriété du code incluse.

Les devis que vous recevrez seront enfin comparables. Et l’écart entre eux, s’il reste, portera cette fois sur quelque chose que vous pourrez juger.