Un fondateur m'a montré trois devis pour la même application. Le premier : 8 000 €. Le deuxième : 28 000 €. Le troisième : 45 000 €. Même besoin, même cahier des charges envoyé à chacun. Il m'a demandé : "le moins cher est cinq fois moins cher, c'est forcément une arnaque ?"
Non. Ce n'était pas une arnaque. C'était trois prestataires qui ne chiffraient pas la même chose. Le devis à 8 000 € couvrait le développement brut — pas de tests, pas de maintenance, code livré "as is". Celui à 45 000 € incluait 12 mois de maintenance, une documentation technique et des tests automatisés. Le fondateur a choisi le devis à 8 000 €. Six mois plus tard, l'app plantait, le freelance avait un autre contrat et ne répondait plus. Coût total pour rattraper le projet : 65 000 €.
Le recrutement d'un développeur ou d'un prestataire, c'est la décision la plus opaque pour un fondateur non-technique. On regarde le prix en bas de page, on compare, et on espère. Sauf que ça ne marche pas comme ça.
Voici les 6 critères que j'utilise quand un client me demande de l'aider à trancher — et pourquoi le prix arrive en dernier.
Pourquoi le prix ne veut rien dire tout seul
Sur les projets que j'audite, le devis le moins cher finit presque systématiquement par être le plus cher. Pas parce que le prestataire est malhonnête. Parce qu'il chiffre différemment.
Un devis à 8 000 € qui ne mentionne pas la maintenance, c'est comme acheter une voiture sans assurance ni révisions. Ça roule. Jusqu'au premier problème.
Un client m'a montré trois devis il y a quelques mois. Le moins cher ne mentionnait pas la maintenance. Quand j'ai posé la question au prestataire : "la maintenance, c'est un autre devis." Le plus cher l'incluait sur 12 mois. En recalculant le coût réel sur 2 ans, c'était le moins cher des trois. Ce genre de signaux d'alerte sur un devis, on les repère vite quand on sait où regarder.
Avant de comparer les montants, vérifiez ce que chaque devis inclut réellement. Les différences se cachent dans les petites lignes — ou dans ce qui n'y est pas.
Critère 1 — Le scope : ce qui est écrit vs ce que vous imaginez
L'écart le plus dangereux dans un devis, ce n'est pas le prix. C'est le fossé entre ce que vous pensez acheter et ce que le prestataire pense livrer.
J'ai vu deux devis pour "une marketplace". Même fourchette de prix — autour de 35 000 €. Le premier détaillait 47 fonctionnalités avec des critères d'acceptation. Le deuxième tenait en 2 pages avec "développement de la marketplace" comme unique description. Le premier a livré exactement ce qui était convenu. Le deuxième a donné lieu à 6 mois d'allers-retours sur ce qui était "dans le scope" ou pas.
La question à poser à chaque prestataire : "Qu'est-ce qui n'est PAS inclus dans ce devis ?" La réponse vaut plus que tout le reste du document. Un prestataire sérieux sait exactement ce qu'il exclut. Un prestataire flou ne sait même pas ce qu'il inclut.
Critère 2 — La maintenance : le poste que personne ne veut voir
Une application, ça ne se "livre" pas comme un meuble. Ça vit. Ça casse. Ça doit évoluer. La maintenance représente en moyenne 20 à 30 % du coût initial, chaque année. Sur 3 ans, elle dépasse le budget de développement.
Sur les devis que j'analyse, la maintenance est soit absente, soit réduite à une ligne : "support technique : sur devis". Traduction : on verra bien.
Un engagement de maintenance sérieux contient :
- Un temps de réponse garanti (SLA) — pas "on fera au mieux"
- La distinction entre corrections de bugs (incluses) et nouvelles fonctionnalités (payantes)
- L'hébergement et les mises à jour de sécurité
- Une durée d'engagement claire
Un devis sans maintenance, c'est un prestataire qui pense à la livraison. Pas à ce qui vient après. Et la dette technique se construit précisément dans cet angle mort.
Critère 3 — La propriété du code
Sur 20 devis analysés récemment, 14 ne mentionnaient pas la propriété du code source. Quatorze sur vingt. C'est pourtant le critère qui décide si vous pouvez changer de prestataire un jour — ou si vous êtes prisonnier.
Un de mes clients a payé 45 000 € pour une application. Quand il a voulu changer d'agence, il a découvert que le code était hébergé sur le GitLab interne du prestataire. Pas de clause de transfert. L'agence a refusé de livrer les sources. Quarante-cinq mille euros. Perdus.
Pour éviter ce scénario, exigez trois choses : la cession complète des droits sur le code, l'hébergement sur votre propre dépôt, et une clause de réversibilité. Ces clauses ne sont pas un détail juridique. C'est votre seule garantie de ne pas repartir de zéro le jour où la relation se termine.
Critère 4 — Les technologies et votre dépendance
Un prestataire avait proposé de coder un projet client en Elixir avec Phoenix. Techniquement, c'est solide — performant, fiable. En pratique, trouver un développeur Elixir en France, c'est chercher un menuisier qui travaille l'ébène. Ils existent. Ils sont rares. Et ils sont chers.
Le fondateur se retrouvait 100 % dépendant de ce prestataire. S'il partait, personne pour reprendre le code.
Vous n'avez pas besoin de comprendre les technologies pour évaluer ce risque. Posez juste cette question : "Combien de développeurs maîtrisent cette techno en France ?" Si la réponse est floue ou si le prestataire botte en touche, c'est un signal. React, Node.js, Python, PHP — ce sont des choix standards avec un large vivier de développeurs. Un choix exotique peut se justifier techniquement, mais il augmente votre dépendance.
Votre app a ces failles ?
Architecture, recrutement, process — un CTO senior sans embaucher à plein temps.
Discuter de mon projetCritère 5 — Le processus de travail
Un prestataire qui vous envoie un devis en 48h sans poser une seule question a copié-collé un template. Un prestataire qui vous pose 30 questions avant de chiffrer a pris le temps de comprendre votre projet. Le devis reflète le processus.
J'ai moi-même fait cette erreur. J'ai recommandé un prestataire à un client sur la base de ses références et d'un prix compétitif. Il avait sous-évalué le projet. À mi-parcours, avenant de +40 %. Le fondateur était coincé : payer ou repartir de zéro avec un autre. Depuis, je pose systématiquement une question : "Que se passe-t-il si le projet dépasse le budget prévu ?" La réponse en dit long sur la maturité du prestataire.
Les signaux d'un processus solide :
- Des questions détaillées avant le devis, pas l'inverse
- Des spécifications écrites ou des maquettes avant de coder
- Des livraisons intermédiaires avec des démos régulières
- Un plan de recette clair — comment vous validez que c'est terminé
Critère 6 — Les références vérifiables
Tout le monde a un portfolio. Tout le monde affiche des logos. Ce qui compte, c'est ce que vous pouvez vérifier.
Demandez le nom de 2 ou 3 anciens clients — et appelez-les. Pas ceux mis en avant sur le site. Les vrais. Posez les questions qui comptent : le projet a-t-il été livré dans les temps ? Le budget a-t-il été respecté ? Le prestataire est-il joignable quand ça plante ? Retravailleriez-vous avec lui ?
Si vous voulez aller plus loin, faites auditer un échantillon de code d'un projet similaire. Le recrutement d'un développeur — salarié ou prestataire — repose sur la vérifiabilité, pas sur la confiance aveugle.
La grille de comparaison
Voici la grille que j'utilise avec mes clients. Pour chaque devis reçu, cochez :
| # | Critère | Ce que vous vérifiez | Devis A | Devis B | Devis C |
|---|---|---|---|---|---|
| 1 | Scope | Fonctionnalités détaillées ? Critères d'acceptation ? Exclusions listées ? | |||
| 2 | Maintenance | SLA précisé ? Durée ? Distinction bugs/évolutions ? | |||
| 3 | Propriété du code | Cession des droits ? Hébergement sur votre dépôt ? Réversibilité ? | |||
| 4 | Technologies | Techno standard ? Large vivier de devs ? Pas de lock-in ? | |||
| 5 | Processus | Cadrage avant devis ? Maquettes ? Démos ? Recette ? | |||
| 6 | Références | Anciens clients contactés ? Budget respecté ? Délais tenus ? |
Pour chaque case : ✓ (oui), ~ (partiel), ✗ (non ou absent).
Un devis plus cher avec 6 ✓ vaut systématiquement mieux qu'un devis moins cher avec 4 ✗. Le prix est un critère. Pas LE critère.
Ce qu'un mauvais choix coûte vraiment
Choisir le mauvais devis ne coûte pas la différence de prix entre deux prestataires. Ça coûte le premier prestataire, plus le deuxième qui reprend tout, plus les mois de retard sur votre mise en marché. Le fondateur du début a payé 65 000 € au lieu de 45 000 €. Et il a perdu 6 mois.
C'est un schéma que je retrouve à chaque choix entre freelance, agence ou salarié.
Si vous avez des devis sur la table et aucun repère technique pour trancher, faites-les analyser par quelqu'un qui n'a rien à vendre dans l'histoire. Un CTO externe peut relire vos devis en quelques heures et vous éviter une erreur à cinq chiffres.