Pour comparer deux devis de développement, ne commencez pas par le total. Vérifiez d’abord que chaque proposition couvre le même résultat, avec des livrables, des hypothèses, des critères d’acceptation, des responsabilités et des exclusions explicites. Une offre moins chère peut être la meilleure si ses limites sont acceptables. Une ligne absente n’est pas une économie tant que vous ne savez pas qui prendra le travail en charge.
Méthode préparée le 8 septembre 2026. Elle aide à questionner une proposition, mais ne remplace pas l’examen juridique, comptable ou réglementaire adapté au projet.
Deux prix ne sont comparables qu’après le périmètre
Deux devis peuvent chiffrer le même produit avec des marges différentes ou acheter des prestations distinctes : maquettes contre interface développée, connexion prévue contre intégration testée, livraison du code contre lancement accompagné. Demandez d’abord quel résultat chaque prestataire s’engage à rendre vérifiable.
France Num recommande de rendre visibles objectifs, fonctionnalités, outils tiers, livrables, calendrier et grille d’évaluation (France Num). Sans cette base commune, un tableau de notes additionne des promesses qui ne parlent pas du même projet.
Transformez les formulations en cinq statuts
Relisez chaque proposition sans interpréter les silences. Pour chaque résultat attendu, attribuez un statut à ce que le document dit réellement.
| Statut | Ce que le devis permet d’affirmer | Action avant la décision |
|---|---|---|
| Engagé | Le livrable, la validation et la responsabilité sont explicites | Comparer la portée et les conditions de cet engagement |
| À confirmer | Une hypothèse ou une formulation laisse plusieurs lectures | Poser une question et faire inscrire la réponse dans le devis |
| Option | Le travail est chiffré séparément et peut être activé | Vérifier son déclencheur, son délai et ses dépendances |
| Exclu | Le prestataire indique qu’il ne réalise pas ce travail | Nommer le responsable, le coût et l’effet sur le calendrier |
| Absent | Le document ne traite pas le sujet | Ne pas le considérer inclus ; demander une position écrite |
« API incluse » reste à confirmer sans outil, opérations ni conditions d’accès. « Tests avant livraison » reste imprécis sans scénarios et règle d’acceptation. Une phrase courte peut suffire : « le client envoie une demande, le gestionnaire la qualifie et les deux voient le même statut ; le scénario sera validé en recette ». La précision porte sur le résultat, pas sur le jargon.
Les huit engagements à mettre côte à côte
Utilisez une ligne par sujet qui peut changer votre décision. Pour chaque devis, relevez la preuve écrite et l’impact d’un écart.
| Sujet | Ce qu’il faut retrouver dans la proposition | Risque si le sujet reste implicite |
|---|---|---|
| Périmètre fonctionnel | utilisateurs, parcours, règles, opérations internes et cas d’échec | deux prestataires chiffrent des produits différents |
| Conception et livrables | ateliers, parcours, maquettes, contenus, documentation et formats remis | le client doit produire un élément supposé prêt |
| Données et intégrations | sources, opérations, reprise, qualité attendue, accès et traitement des erreurs | l’intégration devient une option ou une régie non anticipée |
| Tests et acceptation | scénarios, appareils, environnement, responsable de recette et règle de correction | la livraison existe sans critère partagé pour l’accepter |
| Lancement et accès | hébergement, comptes, stores, déploiement, sauvegardes et accès administrateur | le produit est développé mais ne peut pas être exploité |
| Code, créations et licences | dépôt, code source, éléments antérieurs, composants tiers et droits prévus | la reprise par l’équipe ou un autre prestataire reste incertaine |
| Support et maintenance | défaut couvert, durée, délai de réponse, supervision et évolution | « garantie » et maintenance désignent des services incompatibles |
| Gouvernance et changements | interlocuteurs, démonstrations, validations, procédure d’arbitrage et tarification | chaque précision du besoin devient un conflit de périmètre ou de facture |
Cette grille n’exige pas que tout soit inclus. Une migration manuelle réalisée par votre équipe peut être un bon arbitrage si le volume est faible et si la procédure est fiable. L’erreur consiste à découvrir cette exclusion après le début du projet.
Pour les données personnelles, ne vous contentez pas d’une ligne « conforme au RGPD ». La CNIL indique que le contrat avec un sous-traitant doit être précis, contraignant et décrire concrètement la mise en œuvre des obligations et du niveau de sécurité (CNIL). Demandez au minimum les rôles, les données concernées, les sous-traitants, les mesures prévues et la gestion de la fin de prestation.
Forfait ou facturation au temps : que compare-t-on ?
Le forfait est utile si le périmètre, les hypothèses et le traitement des changements sont lisibles. Une API inconnue ou une reprise non inspectée peut sinon déplacer le risque vers les exclusions. La facturation au temps reste maîtrisable si la proposition fixe l’équipe, les priorités, une enveloppe, une règle d’alerte et un résultat attendu par lot.
Comparez donc le mode d’engagement :
- au forfait, demandez ce qui constitue un changement et ce qui se passe si une hypothèse est fausse ;
- au temps passé, demandez qui décide des priorités et comment la consommation est suivie ;
- dans les deux cas, isolez une exploration si l’inconnue peut modifier l’architecture ou le budget.
Exemple rempli : deux propositions pour un portail de service
Cet exemple est fictif. Les montants sont inventés et ne représentent pas les tarifs de Klaapp.
Une PME de maintenance veut ouvrir un portail à ses clients. Un client crée une demande avec photos, un coordinateur la qualifie et un technicien met à jour le statut. L’entreprise veut reprendre 4 000 demandes, utiliser les comptes de son logiciel métier et lancer le portail avant le renouvellement de son ancien outil. La documentation de l’API n’a pas encore été testée.
- Proposition A : 29 000 € HT. Maquettes, portail et espace coordinateur au forfait. La connexion au logiciel métier est annoncée comme incluse. Les tests, la reprise de données, les accès au dépôt et le support sont évoqués sans détail.
- Proposition B : 36 000 € HT. Phase d’exploration de l’API, prototype validé avec les trois rôles, import d’un échantillon, environnement de recette, scénarios d’acceptation et deux mois de correction des défauts définis. La reprise complète reste une option.
Le dirigeant remplit le registre sur les écarts qui comptent.
| Décision critique | Proposition A | Proposition B | Clarification ou arbitrage |
|---|---|---|---|
| Connexion au logiciel métier | À confirmer : « API incluse » | Engagé après une exploration limitée | faire tester accès, opérations et erreurs avant le lot principal |
| Reprise des 4 000 demandes | Absent | Option après import d’un échantillon | décider si tout l’historique est utile ou archivable ailleurs |
| Validation avec trois rôles | À confirmer : maquettes citées, aucun scénario | Engagé : prototype puis recette | écrire les actions et droits attendus pour chaque rôle |
| Correction après acceptation | À confirmer : « garantie » | Engagé sur les défauts liés aux scénarios acceptés | distinguer défaut, évolution et demande hors périmètre |
| Dépôt, comptes et documentation | Absent | Engagé au nom du client avec documentation de reprise | exiger le calendrier des accès dans les deux offres |
| Échéance de remplacement | Date de livraison annoncée | lots, dépendances et date cible | relier la date à l’API, aux validations et à la migration |
L’offre B n’est pas automatiquement meilleure parce qu’elle est plus détaillée. Elle achète, dans cet exemple, la réduction de trois inconnues : faisabilité de l’API, reprise des données et acceptation par rôle. Le dirigeant demande à A une version révisée qui chiffre ou exclut ces points. Il demande à B si seules les demandes ouvertes doivent être migrées, ce qui peut réduire l’option.
La décision devient alors explicite. Si A confirme les mêmes engagements pour un coût total plus faible, A peut gagner. Si A maintient un prix bas en laissant l’API et la reprise à la charge du client, l’écart n’est plus une remise : c’est un transfert de travail et de risque.
La clarification doit modifier le document
Envoyez les mêmes questions aux deux prestataires pour fermer les écarts de lecture, puis demandez une proposition révisée ou une annexe.
- Quel parcours complet sera utilisable à la fin du premier lot, par quels rôles ?
- Quels livrables seront remis, dans quel format et sur quels comptes ?
- Quelles hypothèses peuvent modifier le prix ou le délai ? Comment seront-elles vérifiées ?
- Quels scénarios permettront d’accepter la livraison et qui exécutera la recette ?
- Quels travaux sont à la charge de notre équipe ou d’un tiers ?
- Quels coûts continuent après le lancement : hébergement, licences, support, maintenance ou services externes ?
- Comment une demande nouvelle sera-t-elle estimée, arbitrée et validée ?
- Comment le produit pourra-t-il être repris : code, données, accès, documentation et licences ?
Une réponse orale ne corrige pas une exclusion écrite. Faites rattacher la clarification au devis ou au contrat et, pour un enjeu juridique, demandez l’avis d’un professionnel compétent.
Quels signaux doivent faire reporter la décision ?
Reportez la signature si l’un de ces points touche le parcours principal et reste sans réponse :
- une intégration est chiffrée sans accès ni hypothèse vérifiable ;
- personne ne sait qui fournit les contenus, les données ou les comptes ;
- « livraison » ne précise pas ce qui sera utilisable ni comment l’accepter ;
- le prix est ferme, mais toute précision est qualifiée de supplément ;
- la date ne dépend d’aucune validation du client ni d’aucun service tiers ;
- la propriété du code est promise sans traiter les composants existants, les licences et les créations graphiques ;
- la maintenance est présentée comme incluse sans durée, périmètre ni délai de traitement.
L’INPI montre que les droits sur une application et ses différentes composantes ne se déduisent pas simplement du financement de la création ; leur organisation dépend des auteurs, des éléments et des cessions prévues (INPI, pages 128 à 130). La bonne question n’est donc pas seulement « le code m’appartient-il ? », mais « quels éléments, quels droits, quels accès et quelles limites sont prévus ? ».
Si plusieurs sujets centraux sont encore absent ou à confirmer, revenez au cahier des charges d’application ou financez un cadrage court. Si les propositions sont comparables mais dépassent l’enveloppe, utilisez la décomposition du budget d’une application mobile pour reporter un lot, simplifier un parcours ou isoler une exploration.
Préparer la décision avec Klaapp
Klaapp peut aider à relier les deux propositions au besoin, aux utilisateurs et aux contraintes de lancement. Un premier échange peut mettre à plat les hypothèses, les critères d’acceptation, les intégrations et les responsabilités, puis conclure qu’une offre est comparable, qu’elle doit être précisée ou qu’un autre chemin est préférable. Le cadrage et la création de produit ne vous obligent pas à engager immédiatement un développement.
Questions fréquentes
Faut-il choisir le devis de développement le moins cher ?
Choisissez le moins cher seulement s’il couvre les engagements dont vous avez besoin et si ses exclusions sont assumées. Comparez le coût total d’un même résultat : travail interne, options, services récurrents, reprise de données, lancement et maintenance. Un écart de prix sans écart de périmètre mérite une explication, pas une conclusion automatique.
La remise du code source garantit-elle l’indépendance ?
Non. La reprise demande aussi les accès au dépôt et aux services, les instructions de lancement, les configurations, les tests, les données, la documentation et les droits nécessaires sur les composants. Faites vérifier les clauses de propriété intellectuelle selon votre situation.
Une garantie et une maintenance couvrent-elles la même chose ?
Non par défaut. Une garantie peut viser la correction des défauts par rapport à un périmètre accepté. La maintenance peut inclure supervision, mises à jour, support ou évolutions, selon le contrat. Demandez une définition, une durée, un délai de réponse et les exclusions pour chaque service.
Une précision échangée par e-mail suffit-elle ?
Une clarification importante doit être rattachée aux documents qui organisent l’engagement. La DGCCRF rappelle, dans le cadre des relations avec les consommateurs, qu’un devis accepté peut engager sur l’étendue, le coût et les délais (DGCCRF). Les règles applicables à votre relation, notamment en B2B, doivent être vérifiées avec un conseil compétent.
Sources
- France Num — Modèles de cahiers des charges pour un site internet d’entreprise
- CNIL — Responsable du traitement, sous-traitants : comment bien identifier son rôle ?
- INPI — La propriété intellectuelle et la transformation numérique de l’économie
- DGCCRF — Devis
Valentin Merault est cofondateur de Klaapp. Il intervient sur le cadrage, le produit, l’IHM et l’expérience utilisateur. Découvrir le studio Klaapp.