Le même produit peut coûter du simple au quintuple. Les sept facteurs qui déterminent l'écart, et ceux sur lesquels tu peux agir.
« Combien coûte une application comme la mienne ? » Aucune réponse honnête ne tient en un chiffre, et pas par prudence commerciale : deux produits qui se ressemblent de l'extérieur peuvent différer d'un facteur cinq. Voici les sept facteurs qui expliquent l'écart. Quatre dépendent de toi.
1 · Le nombre de rôles.
Le facteur le plus sous-estimé. Une application avec un seul type d'utilisateur est un produit. Avec trois — un client, un fournisseur, un administrateur — ce sont trois interfaces, trois jeux de permissions, trois parcours à tester, et des interactions entre eux qui multiplient les cas limites. Passer de un à trois rôles ne triple pas la charge : il la multiplie davantage, parce que la complexité vient des croisements. Tu peux agir dessus : choisis un rôle pour la v1.
2 · Qui détient la vérité.
Une application qui affiche des données est simple. Une application qui devient la source de vérité — celle où l'on saisit, corrige, valide — impose des pistes d'audit, une gestion de la concurrence d'accès, des règles de réconciliation, une stratégie de reprise après erreur. Peu négociable : c'est une propriété du problème, pas du produit.
3 · Les intégrations tierces.
Chaque intégration ajoute une dépendance qui échouera un jour. Paiements, comptabilité, expédition, calendriers : il faut gérer les erreurs, les délais d'attente, les nouvelles tentatives, la réconciliation en cas de désynchronisation.
Le coût d'une intégration n'est pas dans le cas normal, il est dans les cas d'échec.●
Un prestataire qui chiffre une intégration en deux jours n'a chiffré que le cas normal. Tu peux agir dessus : reporte celles qui ne bloquent pas la première vente.
4 · La contrainte réglementaire.
Un produit qui traite des renseignements personnels de résidents québécois ou européens impose consentement granulaire, purge automatique, export, journalisation des accès, résidence des données. Prévue au cadrage, cette contrainte est marginale. Découverte au sprint 10, elle impose une migration. C'est le facteur dont l'écart de coût dépend le plus du moment où on le pose.
5 · Le bilinguisme.
Conçu dès l'origine : un surcoût modeste, essentiellement du temps de conception. Ajouté après le lancement : migration du schéma, reprise des requêtes, réindexation de la recherche, révision des maquettes, refonte des documents. Tu peux agir dessus — une seule fois, au début.
6 · La disponibilité du décideur.
Le facteur le moins technique et l'un des plus déterminants. Une question bloquante sans réponse pendant quatre jours, c'est une équipe qui construit sur une hypothèse — qui sera parfois fausse, et il faudra alors défaire. Sans interlocuteur décisionnaire disponible chaque semaine, compte environ 30 % de charge supplémentaire. Ce n'est pas une pénalité contractuelle : c'est la reprise du travail construit sur des suppositions. Tu peux agir dessus, et c'est gratuit.
7 · La qualité exigée.
Un prototype pour tester une hypothèse et un produit qui encaissera des paiements le mois prochain n'ont pas les mêmes exigences en matière de tests, de journalisation, de sauvegardes ou de tolérance aux pannes. Les deux sont légitimes. Ce qui ne l'est pas, c'est de payer le prix du premier en attendant le second.
La question à poser à tout devis.
« Qu'est-ce qui n'est pas compris dans ce chiffre ? » Un devis sérieux répond en trois minutes avec une liste précise. Un devis flou répond « tout est compris », ce qui n'est jamais vrai — et tu découvriras lesquels au sprint 6, quand il sera trop tard pour comparer.
Ce qu'on ne fait pas.
On ne chiffre pas un développement avant d'avoir vu le périmètre. Un chiffre annoncé sans périmètre est un chiffre faux — soit il t'engage sur une somme qui ne tiendra pas, soit il gonfle par prudence et tu paies la marge d'incertitude du prestataire.