Coût de développement d’une application : comparer les devis

Prenons un cas type : une entreprise souhaite une application sur mesure, envoie son cahier des charges à trois prestataires, et le plus cher des trois devis vaut plusieurs fois le moins cher. Le premier soupçon est tout trouvé : quelqu’un gonfle ses prix.

L’écart peut pourtant tenir à ce que le prestataire a inclus dans son devis, à ce qu’il a omis et au risque qu’il a laissé à votre charge.

Nous examinons dans l’article Un bon système interne peut se rentabiliser plus vite qu’un nouveau salarié si un système sur mesure vaut l’investissement. Nous nous plaçons ici à l’étape suivante : les devis sont sur la table, et la question devient celle du coût de développement d’une application que chaque prestataire imagine à sa façon.

Un devis plusieurs fois plus cher n’est pas forcément gonflé

Dans une étude de 2009, Bente Anda, Dag Sjøberg et Audris Mockus décrivent l’appel d’offres par lequel le Simula Research Laboratory cherchait un prestataire pour un système web. Sur les 81 entreprises consultées en Norvège, 35 ont remis une offre au forfait, toutes sur la base du même cahier des charges de 11 pages. Les montants hors TVA allaient de 2 630 à 69 940 euros, soit un écart d’un facteur 26,6 environ. C’est ce rapport qui est instructif, et non les montants, aujourd’hui datés.

Les entreprises estimaient d’ailleurs que le cahier des charges était bien spécifié. Leurs offres variaient pourtant aussi quant au degré d’analyse et de conception : certaines n’en prévoyaient aucune, d’autres allaient jusqu’aux écrans, à l’architecture et aux modèles de données. Les auteurs n’ont trouvé aucun lien entre le prix et la démarche prévue et, selon eux, les offres ne renseignaient que partiellement sur la façon dont chaque entreprise travaille et sur la qualité qu’elle entend livrer. Le montant, à lui seul, ne vous dit donc pas ce que vous obtiendrez en contrepartie.

Lors de la phase préliminaire de ce même appel d’offres, 17 de ces entreprises ont fourni une estimation indicative, sans engagement, sur la seule base d’une description des besoins tenant sur une page. D’après Magne Jørgensen et Gunnar J. Carelius, l’estimation la plus élevée était environ dix fois supérieure à la plus basse, notamment en raison de différences dans les solutions proposées et dans la productivité. Les auteurs soulignent qu’avec une spécification vague, le prix d’une offre ne se contente pas de refléter le projet : il le définit aussi.

De quoi se compose le prix

Si le cahier des charges est muet, c’est le prestataire qui prendra ces décisions à votre place :

Le périmètre fonctionnel. Ce que l’application fera et ne fera pas. La phrase « l’utilisateur génère un rapport » peut désigner aussi bien un export vers un tableur qu’un module d’analyse.
Les intégrations. Les connexions, par exemple avec votre logiciel comptable. Leur complexité dépend d’interfaces que le prestataire ne connaît pas forcément.
Le design et l’UX. L’UX, c’est-à-dire l’expérience utilisateur, influe sur l’adoption de l’application, comme nous l’expliquons dans l’article Le système le plus cher est celui que vos équipes n’utilisent pas. Un template prêt à l’emploi coûte moins cher qu’une conception validée auprès des utilisateurs.
Le modèle de données. La structure des données et de leurs relations. Tout le reste repose dessus, c’est pourquoi ses erreurs sont difficiles à corriger.
La sécurité et les droits d’accès. Un rôle unique pour tout le monde coûte peu, alors que des accès différenciés selon le poste doivent être conçus, puis testés.
Les tests. Après chaque modification, les tests automatisés vérifient que les fonctionnalités existantes sont toujours opérationnelles. Sans eux, ce sont vos équipes qui testent.
La gestion de projet. La coordination et la gestion des changements. Vérifiez si elle est comprise dans le prix ou si quelqu’un de chez vous devra s’en charger.

Des écarts se cachent aussi dans les exigences non fonctionnelles, qui ne décrivent pas ce que fait le système, mais avec quel niveau de qualité il le fait : rapidité, fiabilité ou maintenabilité, c’est-à-dire la facilité à le modifier. Dans l’étude norvégienne, elles étaient décrites moins en détail que les exigences fonctionnelles, et les auteurs recommandent de les spécifier dès le cahier des charges, en particulier la maintenabilité. Le modèle de qualité de la norme ISO/IEC 25010:2023, que les clients peuvent eux aussi utiliser pour rédiger leurs spécifications, peut y aider.

Ce qui peut manquer dans un devis

Vérifiez ces postes auprès de chaque prestataire. Si le cahier des charges ne les mentionnait pas, l’un a pu les chiffrer et l’autre non.

Le back-office. La gestion des utilisateurs, des listes de valeurs et des contenus. Sans lui, la moindre modification passe par un développeur et vous est facturée.
La migration des données. Le transfert et le nettoyage des données issues de l’ancien système ou de tableurs.
Le multilinguisme. Si le code ne le prévoit pas dès le départ, l’ajouter ensuite peut toucher une grande partie de l’application.
L’accessibilité. L’utilisabilité, y compris pour les personnes en situation de handicap. La traiter après coup oblige à reprendre des écrans déjà terminés.
Le support après la mise en production. Les corrections, les mises à jour de sécurité et l’assistance aux utilisateurs. S’il n’est pas prévu, le premier problème en exploitation devient une nouvelle commande.

Nous analysons les coûts sur plusieurs années d’utilisation dans l’article Sept outils SaaS ou un seul système ? Pour lire un devis, il suffit d’en retenir une idée : un code sans tests ni documentation coûte moins cher à livrer, mais plus cher à faire évoluer, car à chaque intervention, le développeur doit d’abord déterminer ce que la modification va casser.

Qui porte le risque : forfait, régie ou formule hybride

Le forfait signifie que le risque de dépassement des coûts est porté par le prestataire, qui l’intègre donc dans son prix : plus le cahier des charges est vague, plus la marge pour aléas est importante ou plus l’interprétation du périmètre est restrictive. La réglementation américaine des achats fédéraux, la Federal Acquisition Regulation, indique qu’un contrat à prix ferme fait peser un risque maximal sur le prestataire et que le type de contrat doit se négocier en même temps que le prix. Ce texte ne relève pas de notre droit, mais sa logique nous paraît transposable.

La régie (time and materials) signifie que vous payez le temps passé aux taux convenus et que c’est vous qui portez le risque lié à l’incertitude. La même réglementation ne l’admet que lorsque l’ampleur ou la durée des travaux ne peuvent pas être estimées précisément à l’avance. Comme ce modèle n’incite pas le prestataire à maîtriser ses coûts, la réglementation exige une surveillance de la part du client. Elle impose également un prix plafond, que le prestataire dépasse à ses risques et périls.

La formule hybride avec un premier jalon au forfait fixe un prix ferme pour une première étape dont le livrable est clairement défini, par exemple une analyse ou un prototype, et la suite n’est décidée que sur la base du périmètre ainsi décrit. Le prestataire porte le risque d’une étape de faible ampleur, et vous décidez de l’essentiel du budget avec de meilleures informations. Cette première étape coûte toutefois de l’argent et du temps, et son livrable doit pouvoir être exploité par un autre prestataire, faute de quoi vous achetez la dépendance une étape plus tôt.

Un cahier des charges imprécis se paie pendant le développement

Une change request, ou demande de modification, est une requête formelle portant sur un changement du périmètre convenu, assortie de son propre prix et de son impact sur les délais. Lorsque le cahier des charges est imprécis, l’exception devient la règle, car les éléments manquants n’apparaissent qu’en cours de développement.

Jørgensen et Carelius indiquent que les dépassements de coûts des prestataires s’expliquent souvent par des changements d’exigences qui ne peuvent pas être facturés au client. Selon nous, celui qui a remporté le marché avec un prix bas a donc tout intérêt à facturer chaque écart comme une modification. Si le contrat ne fixe pas à l’avance le taux, la méthode d’estimation et le processus de validation des modifications, vous en négocierez le prix à un moment où vous ne pourrez plus facilement changer de prestataire.

Mais un cahier des charges imprécis ne se paie pas seulement en factures. Le modèle Cost of Friction, que nous utilisons sur ce blog, calcule le coût des frictions selon la formule temps × fréquence × nombre de personnes × coût. Calcul type avec des données hypothétiques : 30 points flous dans le cahier des charges, dont chacun nécessite une réunion de deux heures avec trois de vos collaborateurs, représentent 2 × 30 × 3 = 180 heures de travail interne. Personne ne vous les facturera, et pourtant vous les paierez. Refaites le calcul avec vos propres chiffres et votre coût horaire.

Droits sur le code et possibilité de changer de prestataire

On parle de vendor lock-in lorsque vous ne pouvez pas facilement remplacer votre prestataire, parce qu’il est le seul à comprendre le système. En 2016, la Commission européenne indiquait que 42 % des organisations étudiées déclaraient avoir déjà été confrontées à un lock-in dans le domaine des TIC.

Selon l’article 91, paragraphe 4, de la loi slovaque n° 185/2015 Z. z. sur le droit d’auteur, dans sa version en vigueur à compter du 1er septembre 2026, les dispositions relatives à l’œuvre de salarié s’appliquent à un programme d’ordinateur créé en tout ou en partie sur commande, et le commanditaire est considéré comme l’employeur. Sauf convention contraire, le commanditaire exerce donc les droits patrimoniaux, notamment le droit d’utiliser l’œuvre, peut en céder l’exercice à un tiers, et l’auteur est réputé avoir également consenti à la modification de l’œuvre (article 90, paragraphes 4 à 6). C’est le droit slovaque ; d’autres pays peuvent régler la question autrement. Quel que soit le pays, le contrat doit donc préciser explicitement à qui appartient le code.

Par œuvre de commande, la loi entend une œuvre créée sur la base d’un contrat d’entreprise, et ce dont les parties sont convenues est également déterminant. En outre, la loi règle la question des droits, pas celle de la remise : sans le code source dans votre dépôt, sans les accès ni la documentation, le droit de modifier l’œuvre ne vous avancera guère.

Le contrat doit aussi encadrer les éléments préexistants apportés par le prestataire, par exemple sa plateforme ou des composants payants, car ils n’ont pas été créés sur votre commande. Ceci ne constitue pas un conseil juridique : faites examiner le contrat par un avocat.

Comment comparer les devis

Posez les mêmes questions à tous les prestataires et consignez leurs réponses côte à côte :

Qu’est-ce qui est inclus dans le périmètre, et qu’en excluez-vous explicitement ?
Quelles hypothèses avez-vous retenues concernant les intégrations, les données et les rôles ?
Comment traitez-vous les performances, la sécurité et la maintenabilité, et que testez-vous ?
Comment chiffrez-vous et validez-vous les modifications de périmètre ?
Que comprend le support après la mise en production, et combien coûte la première année d’exploitation ?
Quels droits obtiendrons-nous sur le code, où sera-t-il stocké et comment se déroulera la réversibilité vers un autre prestataire ?

Les auteurs de l’étude norvégienne recommandent que les offres présentent explicitement les méthodes de travail et le niveau de qualité visé, et pas seulement de manière implicite, à travers le prix forfaitaire. Nous considérons comme des signaux d’alerte :

Un forfait sans questions. Un cahier des charges vague chiffré à un montant ferme, sans questions de clarification, peut reposer sur une interprétation restrictive du périmètre ou sur une marge pour aléas dont vous ignorez l’existence.
L’absence de tests. Ce sont alors vos utilisateurs qui découvriront les bugs.
Des droits et des accès flous. On ne sait pas où le code sera stocké, ou les accès sont liés à la durée de la collaboration.

Quand le devis le moins cher est le bon choix

Quatre entreprises de l’étude norvégienne ont finalement développé le système, chacune de son côté. La moins chère d’entre elles, à 8 750 euros, a accusé un retard de 93 % par rapport au délai convenu, avec une fiabilité et une maintenabilité médiocres. La plus chère, à 56 000 euros, a enregistré un retard de 5 %, avec une bonne utilisabilité et une bonne maintenabilité. À ne considérer que le prix, elle était 6,4 fois plus chère ; en intégrant le travail du client, elle ne l’était plus que 3,4 fois. Les résultats ne suivaient pas l’ordre des prix et, selon les auteurs, le système le moins cher pouvait être le meilleur choix pour un client qui tolère les retards, dispose d’une expertise suffisante et se montre moins exigeant sur certains aspects de la qualité.

Il peut s’agir par exemple d’un outil interne à courte durée de vie ou de la validation d’une idée.

Dans les données de Magne Jørgensen portant sur 785 325 missions, pour la plupart de très petite taille, issues d’une place de marché mondiale d’externalisation, c’est une collaboration antérieure entre le client et le prestataire qui réduisait le plus le risque d’échec, à 17 % du niveau observé pour les projets sans collaboration préalable. Toutes choses égales par ailleurs, les clients qui avaient choisi une offre dont le prix se situait au moins au niveau de la moyenne présentaient un risque équivalent à 85 % de celui des clients plus attachés à un prix bas. Selon l’auteur, ces résultats ne peuvent être généralisés aux projets plus importants qu’avec prudence. À ses yeux, la meilleure façon d’évaluer un prestataire reste une mise à l’épreuve réaliste, par exemple un vrai projet, et une petite première étape rémunérée peut jouer ce rôle.

La phase de cadrage transforme l’estimation en plan

Steve McConnell décrit le cône d’incertitude, un modèle qui montre comment la précision des estimations s’améliore au fil d’un projet. Au stade du concept initial, même des estimateurs chevronnés peuvent se tromper d’un facteur 4 dans un sens comme dans l’autre, soit une fourchette de 1 à 16, et selon lui, il n’est pas possible d’être plus précis. Ce n’est pas une semaine supplémentaire consacrée à l’estimation qui resserre le cône, mais uniquement les décisions sur ce que le produit fera et ne fera pas, sur les exigences et sur l’interface.

Ces décisions sont le fruit d’une analyse ou d’un prototype. Les prestataires chiffrent alors au moins le même périmètre, même si cela ne garantit pas des prix proches, comme l’a montré l’étude norvégienne.

Dans l’appel d’offres évoqué plus haut, les entreprises qui avaient d’abord fait une estimation à partir de la description tenant sur une page ont ensuite proposé, sur la base du cahier des charges détaillé, des prix en moyenne plus élevés que les autres. Jørgensen et Carelius recommandent donc de ne pas demander de prix indicatifs à partir d’informations incomplètes lorsque les offres définitives peuvent s’appuyer sur des informations plus complètes.

Une analyse payante n’est pas pour autant obligatoire. Pour une petite application au périmètre clairement délimité, il peut suffire de préciser le cahier des charges en interne. L’analyse peut aussi révéler que vous n’avez pas besoin de développement, parce qu’une simplification du processus ou un outil existant réglera le problème. C’est pourquoi la question du coût de développement d’une application n’a pas de réponse honnête tant que l’on ne sait pas clairement quel problème l’application doit résoudre.

Ce qu’il faut retenir

Qu’un devis soit plusieurs fois plus élevé qu’un autre ne signifie pas forcément que ses prix sont gonflés. L’écart peut refléter un autre périmètre, une autre solution ou une autre marge pour aléas.
Posez les mêmes questions à tous les prestataires et comparez le périmètre, les exclusions et les hypothèses, pas seulement les montants finaux.
Si le cahier des charges peut être précisé, ne demandez pas de prix indicatifs sur la base d’une description vague. Si le périmètre reste flou, commencez par une phase de cadrage au forfait, dont le livrable pourra aussi servir à un autre prestataire.
Avant de signer, encadrez dans le contrat les droits sur le code, les accès, la documentation et les composants préexistants, puis faites-le examiner par un avocat.
Le devis le moins cher peut être le bon choix si vous pouvez vous accommoder de retards, si vos exigences de qualité sont moins élevées et si vous avez les compétences pour superviser la réalisation.