Ton devis tient sur une demi-page et il y a juste un chiffre en bas ? Voici ce qu'il doit vraiment contenir.

Tu as reçu un devis pour ton logiciel. Il tient sur une page, il y a un chiffre en gras tout en bas, et... c'est à peu près tout. Pas de détail sur ce qui est réellement inclus, pas de date ferme, rien sur qui possédera le code une fois que ce sera fini. Tu signes quand même, parce que le projet presse et que le prix te paraît correct. Six semaines plus tard, tu reçois un mail qui commence par « suite à un avenant nécessaire » : la facture grimpe, et tu n'as aucun texte à opposer pour discuter.

Je vois passer ce scénario régulièrement dans ce que me racontent les dirigeants qui viennent me voir après une mauvaise expérience. Un devis n'est pas un ticket de caisse : c'est un document qui doit te protéger autant que protéger la personne qui va coder. Voici ce qui doit être écrit avant que tu signes quoi que ce soit.

Pourquoi le flou n'est presque jamais un hasard

Un devis vague n'arrange que celui qui l'a écrit. Tant que le périmètre reste flou, tout ce qui n'était « pas prévu explicitement » devient facturable en plus — et ça arrive presque toujours, parce qu'un projet réel a toujours des détails qui n'étaient pas anticipés au premier échange. Ce n'est pas forcément de la malhonnêteté : c'est souvent juste plus confortable à écrire, et plus facile à faire signer vite. Sauf que c'est toi qui portes le risque à la place du prestataire, et tu ne le découvres qu'au moment où la facture tombe, quand il est déjà trop tard pour négocier.

Un devis clair, à l'inverse, force les deux parties à se mettre d'accord sur ce qui est dedans et sur ce qui n'y est pas. C'est plus long à préparer. C'est aussi la seule version qui te protège vraiment.

Les 7 éléments qui doivent obligatoirement y figurer

• Le périmètre exact — la liste des fonctionnalités livrées, pas une phrase vague du type « plateforme complète de gestion ».
• Un prix unique et fixe — pas une fourchette, pas un « à partir de » qui te laisse deviner le vrai total.
• Les dates de livraison — une échéance pour la première version visible, une autre pour la mise en production.
• La règle en cas de changement — comment un ajout en cours de route est chiffré et validé, par écrit, avant d'être appliqué.
• La propriété du code à la fin — qui possède ce qui est construit, et sous quelles conditions.
• Ce qui est inclus après la livraison — support, corrections de bugs, durée précise.
• La durée de validité du devis — combien de temps ce prix et ce délai restent garantis.

Si l'un de ces sept points manque, ce n'est pas forcément un piège volontaire — mais c'est une question à poser avant de signer, pas après.

Le prix : un chiffre figé, ou une base de départ ?

Une fourchette large est acceptable au tout premier contact, avant que tu aies décrit précisément ce que tu veux. Ce qui n'est pas acceptable, c'est de signer sur cette fourchette sans jamais voir apparaître un chiffre unique. Le devis final, celui que tu signes, doit afficher un seul prix, qui engage les deux parties. J'ai détaillé les montants réels du marché et ce qui les fait varier dans cet article sur le coût d'un logiciel sur mesure — de quoi comparer ce qu'on te propose à ce qui se pratique vraiment.

Le planning : des dates, pas des promesses

« Livré rapidement » ne veut rien dire. Un devis sérieux indique une date, ou au minimum un nombre de semaines précis, pour deux jalons : la première version visible et cliquable, puis la mise en production après les allers-retours. Si personne ne peut te dire quand tu verras quelque chose tourner, c'est que le planning n'existe pas encore vraiment — j'explique le calendrier semaine par semaine que je tiens réellement dans cet article sur les délais d'un développement sur mesure.

Chez moi, cette date n'est jamais une vague estimation : c'est un engagement écrit, avec une garantie derrière — la maquette en 7 jours ou tu ne dois rien.

La propriété du code : le point que presque personne ne lit

Pose la question directement avant de signer : à qui appartiendra ce qui est construit ? Certains contrats gardent le flou sur ce point, ou pire, prévoient que le prestataire conserve les droits, ou t'oblige à une maintenance payante pour continuer à utiliser ton propre outil. C'est la différence la plus lourde entre un vrai logiciel sur mesure et un outil que tu loues sans jamais le posséder — j'y consacre un article entier sur pourquoi ça change tout le jour où tu veux évoluer ou changer de prestataire.

Chez moi, la propriété complète du code fait partie de la livraison, avec 30 jours de support inclus. Si tu veux ensuite que je continue à l'héberger et à le faire évoluer, c'est un forfait mensuel optionnel — jamais une obligation cachée dans une clause.

Le R0 → 1 : ce que le devis doit refléter, pas vendre

Méfie-toi d'un devis qui te promet un chiffre de retour sur investissement précis. Un ROI se calcule contre un avant, et ton avant, souvent, c'est un tableur ou une tâche faite à la main : il n'y a rien à comparer, donc rien à chiffrer honnêtement à l'avance. Je préfère parler de R0 → 1 : le devis doit décrire précisément ce qui va exister, pas te vendre un gain futur inventé pour faire joli sur un PDF.

Un bon devis se lit comme une carte, pas comme une pub : ce qui est construit, ce que ça coûte, quand ça arrive, et à qui ça appartient. Rien de plus, rien de moins.

Comment trancher avant de signer

Reprends le devis que tu as sous les yeux et coche mentalement les sept points plus haut. S'il en manque un ou deux, ce n'est pas forcément rédhibitoire — demande-les par écrit avant de signer, un prestataire sérieux répond sans détour et sans se vexer de la question. S'il en manque quatre ou cinq, c'est le signal qu'il vaut mieux comparer ailleurs, même si le prix affiché paraît intéressant sur le moment.

C'est exactement la logique que je tiens sur chaque devis que j'écris : périmètre listé, prix figé, dates fermes, propriété du code incluse. Va voir comment je construis ton logiciel sur mesure, avec le prix, la méthode et la garantie « ta maquette en 7 jours ou tu ne dois rien ».