Comparer des devis de développement d'application

Pour comparer des devis de développement d'application, ramenez-les d'abord au même périmètre : mêmes fonctions, mêmes intégrations, même reprise de données, même exploitation après la livraison. Comparez ensuite la nature du prix (ferme ou estimé), la façon dont chaque prestataire traite les modifications et le coût total sur la durée d'usage. Deux devis qui varient du simple au triple décrivent presque toujours deux projets différents.

Le réflexe naturel est de poser les montants côte à côte. C'est la dernière étape, pas la première. Voici une méthode en cinq temps pour arriver à une comparaison qui a un sens.

Étape 1 : réécrire chaque devis dans la même grille

Un devis est écrit dans la logique de celui qui l'a rédigé : par lots techniques chez l'un, par écrans chez l'autre, par jours chez le troisième. Avant de comparer, reportez chaque proposition dans une grille unique, organisée par besoin et non par technique.

Trois cas pour chaque case : inclus et chiffré, exclu explicitement, ou non mentionné. C'est la troisième catégorie qui compte. Un poste non mentionné n'est pas gratuit : il sera facturé plus tard, ou laissé à votre charge.

Étape 2 : lire les hypothèses, pas seulement les lignes

Un devis repose sur des hypothèses, parfois écrites en petits caractères, parfois absentes. Ce sont elles qui expliquent la plupart des écarts.

• Les données : « reprise des données fournies dans un format exploitable » veut souvent dire que le nettoyage de vos tableurs est à votre charge.
• Les intégrations : « connexion à l'ERP via son API » suppose que l'API existe, qu'elle est documentée et qu'elle couvre le besoin. Si ce n'est pas le cas, le poste peut doubler. Notre article sur l'intégration d'une application à un ERP existant détaille ces pièges.
• La disponibilité de vos équipes : un planning serré suppose des validations rapides de votre côté.
• Le nombre d'allers-retours : certains devis limitent les cycles de correction de la maquette ou de la recette.

Demandez à chaque prestataire la liste écrite de ses hypothèses. Celui qui n'en a pas les a quand même : il ne les a simplement pas écrites.

Étape 3 : identifier la nature du prix

Deux montants identiques n'engagent pas de la même façon.

Un « forfait » présenté comme 40 jours multipliés par un tarif journalier n'est un forfait que si le contrat dit que vous ne paierez pas le 41^e jour. Faites préciser la règle par écrit. Notre article forfait ou régie développe la différence, et celui sur l'abonnement comparé au forfait explique comment comparer une mensualité à un prix d'achat.

Étape 4 : comparer le coût total, pas le prix d'entrée

Le prix de développement n'est qu'une partie de ce que vous paierez. Une application métier doit être hébergée, sauvegardée, surveillée, corrigée et adaptée tant qu'elle sert. Pour chaque devis, calculez :

coût total = développement + (exploitation mensuelle x durée d'usage) + évolutions prévisibles

Prenez une durée d'usage réaliste, trois ans au minimum pour un outil métier. Si un devis ne dit rien de l'exploitation, demandez le chiffre : un devis muet sur ce point n'est pas moins cher, il est incomplet. Nous détaillons ce qui compose ce poste dans notre article sur la maintenance.

Étape 5 : évaluer ce que le prix ne dit pas

À coût total comparable, d'autres critères départagent les offres :

• La preuve de compréhension. Le prestataire vous a-t-il montré quelque chose (prototype, maquette, schéma des parcours) ou seulement envoyé un montant ? Un devis construit sur un prototype validé décrit ce qui sera livré ; les autres décrivent ce que chacun a imaginé.
• Le traitement des modifications. Chiffrées une à une et soumises à votre accord, ou absorbées « au mieux » puis facturées en bloc ?
• La livraison par étapes. Des paliers utilisables, ou un tunnel jusqu'à la livraison finale ?
• Les droits sur le code et la sortie. Qu'est-ce que vous pourrez faire du code, et que récupérerez-vous si vous changez de prestataire ? Les réponses varient d'un contrat à l'autre ; nous les détaillons dans notre article sur la propriété du code source.
• La technologie. Un socle standard et documenté reste reprenable par une autre équipe ; un outil propriétaire vous lie au prestataire.

Les écarts qui doivent alerter

Certains écarts ne s'expliquent pas par le périmètre, et ils doivent vous faire poser des questions :

• un devis nettement plus bas que les autres sans exclusion visible ;
• un montant global sans aucune décomposition ;
• des intégrations mentionnées en une ligne, sans hypothèse ;
• aucune ligne de recette, comme si le logiciel allait fonctionner du premier coup ;
• aucun mot sur ce qui se passe après la mise en production.

À l'inverse, un devis plus cher mais qui liste tout, hypothèses comprises, est souvent le plus sûr. Pour comprendre d'où vient un prix, notre article sur ce qui fait le prix d'une application métier reprend les cinq facteurs principaux, et celui sur les applications mobiles ajoute les postes propres au mobile.

Et si les devis restent incomparables ?

C'est fréquent quand le besoin a été décrit en quelques lignes : chaque prestataire a comblé les vides à sa façon. Le remède n'est pas de demander un quatrième devis, mais de fermer le périmètre. Un prototype que vous validez devient une base commune : ce qui est à l'écran est dans le prix, le reste fait l'objet d'une décision explicite. Vous pouvez même transmettre ce périmètre validé aux autres prestataires pour obtenir des chiffres enfin comparables. Pour choisir ensuite entre eux, nos douze questions à poser à une agence complètent la grille.

Par où commencer

Reprenez vos devis dans la grille de l'étape 1, puis listez les cases « non mentionné » : ce sont vos questions pour la prochaine réunion. Si votre périmètre n'est pas encore assez précis pour être chiffré, LPR Studio vous présente un prototype visuel gratuit en visio sous 5 jours ouvrés, et le prix au forfait est fixé à partir de ce prototype, avant la première ligne de code. Nos trois formules sont détaillées sur l'accueil.