Un devis de projet digital décrit généralement bien le travail à faire. Il décrit beaucoup moins souvent ce qui se passe si la date glisse, ce que vous recevez exactement le jour de la livraison, et qui corrige quoi six mois plus tard.
Ces trois sujets ne coûtent rien à négocier avant la signature. Ils deviennent très chers après.
Le devis décrit le travail, pas les engagements
Un devis de projet digital est presque toujours construit autour du périmètre fonctionnel et du prix. Trois pages de fonctionnalités, un total en bas, un délai indicatif. Côté dirigeant, c’est rassurant : on voit ce qu’on achète.
Ce qu’on ne voit pas, c’est la zone grise qui commence le jour de la livraison. Qui possède le résultat. Ce qu’il faut faire si une anomalie apparaît en février alors que la livraison était en novembre. Comment on récupère son outil si la relation s’arrête.
Cette zone grise n’est pas le signe d’une mauvaise foi généralisée. Elle existe parce que personne n’a intérêt à l’ouvrir pendant la phase commerciale : le prestataire ne veut pas alourdir une proposition qu’il espère voir signée, et le dirigeant ne sait pas toujours quelles questions poser. Elle se referme en quelques paragraphes, à condition de les demander avant de signer.
Une PME industrielle fait développer un outil de suivi de commandes. Livraison dans les temps, outil fonctionnel, tout le monde est satisfait. Dix-huit mois plus tard, le prestataire change d’activité et cesse de répondre.
L’entreprise découvre alors trois choses : elle n’a jamais reçu le code source, l’hébergement est facturé sur un compte ouvert au nom du prestataire, et aucun document ne décrit le fonctionnement interne de l’outil. Le nouveau prestataire consulté annonce qu’il est moins coûteux de reconstruire que de reprendre à l’aveugle.
Rien dans cette histoire n’est contraire au devis signé. Le devis ne parlait simplement d’aucun de ces trois points.
Délais : une échéance sans conséquence n’en est pas une
Une date unique en bas d’un devis a peu de valeur opérationnelle. Elle ne dit pas où en sera le projet à mi-parcours, elle ne permet pas de réagir avant qu’il soit trop tard, et surtout elle n’est associée à rien : si elle glisse de six semaines, il ne se passe rien d’autre qu’une conversation gênée.
Ce qui tient, c’est une suite de jalons. Trois à cinq points de passage, chacun avec un livrable que vous pouvez constater vous-même — une maquette validée, un premier parcours utilisable, une version de test ouverte à deux personnes de votre équipe. Un jalon dont vous ne pouvez pas vérifier l’atteinte n’est pas un jalon.
Deux éléments complètent utilement ce calendrier, et ils sont presque toujours absents :
Vos propres obligations. Les retards de projet viennent au moins autant du client que du prestataire : contenus non fournis, validations qui traînent trois semaines, interlocuteur indisponible en juillet. Un calendrier qui n’écrit pas ce que vous devez fournir et en combien de jours vous validez n’est opposable dans aucun sens. Écrire « le client dispose de 5 jours ouvrés pour valider chaque jalon » protège le prestataire, mais vous protège aussi : au-delà, c’est vous qui portez le glissement, et vous le savez d’avance.
La conséquence d’un dépassement. Elle n’a pas besoin d’être brutale. Une obligation d’alerte écrite dès qu’un jalon est menacé, avec un calendrier révisé sous huit jours, suffit dans la plupart des cas. L’important n’est pas la sanction, c’est que le dépassement déclenche quelque chose plutôt que rien.
Pour calibrer ces jalons sur des durées réalistes selon le type de projet, j’ai détaillé les fourchettes observées dans combien coûte vraiment un logiciel métier sur mesure.
Livrables : la question de la propriété
C’est le point le plus coûteux à découvrir après coup, et le moins souvent abordé.
Quand un salarié développe un logiciel dans le cadre de ses fonctions, la loi attribue les droits d’exploitation à l’employeur, sans qu’aucun contrat particulier soit nécessaire : c’est l’article L. 113-9 du Code de la propriété intellectuelle. Beaucoup de dirigeants supposent, assez logiquement, que la règle est la même quand on paie un prestataire.
Elle ne l’est pas. Un prestataire indépendant, freelance ou société, n’est pas un salarié : ce mécanisme ne s’applique pas à lui. Sans clause de cession expresse dans le contrat, vous avez acheté une prestation, pas les droits sur son résultat. Et le formalisme est exigeant : l’article L. 131-3 du même code impose que chaque droit cédé fasse l’objet d’une mention distincte, et que le domaine d’exploitation soit délimité en étendue, destination, lieu et durée.
Traduit en conséquences concrètes : sans cette clause, faire modifier votre outil par quelqu’un d’autre, le revendre avec votre entreprise, ou en déployer une variante dans une filiale sont autant d’opérations sur lesquelles le prestataire d’origine garde un mot à dire.
La propriété n’est qu’une partie du sujet. Un livrable complet comprend aussi les accès et les éléments qui rendent l’outil reprenable par un tiers.
| Votre exigence | Formulation sans valeur | Formulation qui engage |
|---|---|---|
| Propriété du résultat | « Le client est propriétaire du livrable » | Cession des droits de reproduction, de modification et de diffusion, pour tous supports, sans limite de durée ni de territoire |
| Code source | « Sources disponibles sur demande » | Remise à chaque jalon sur un espace dont vous êtes titulaire, et non en fin de projet |
| Hébergement et nom de domaine | « Hébergement inclus » | Comptes ouverts à votre nom, facturés à votre nom, avec accès administrateur de votre côté |
| Vos données | « Export possible » | Export complet dans un format lisible par un autre outil, obtenable par vous sans intervention du prestataire |
| Documentation | « Documentation fournie » | Un document de reprise permettant à un prestataire tiers de redémarrer le projet, livré et relu avant le solde |
Cette phrase figure dans énormément de devis, et elle ne règle rien. Détenir un exemplaire d’un outil et détenir les droits de l’exploiter sont deux choses différentes — c’est exactement la distinction que fait l’article L. 131-3 en exigeant l’énumération de chaque droit cédé.
Un prestataire sérieux n’a aucune difficulté à remplacer cette formule par trois lignes précises. Un prestataire qui répond que « c’est l’usage » ou que « ça n’arrive jamais » vous indique surtout que la question le dérange.
Garanties : la frontière entre correction et évolution
Dans la plupart des devis, « garantie » signifie : correction gratuite des anomalies pendant trois à douze mois après la mise en ligne. C’est utile, et c’est insuffisant tel quel, parce que le mot « anomalie » n’est jamais défini.
Or c’est là que se jouent toutes les discussions tendues. Un bouton qui ne fonctionne pas comme décrit dans le cahier des charges est une anomalie : elle relève de la garantie. Un besoin qui apparaît à l’usage, parce que votre équipe a découvert en travaillant qu’il faudrait aussi filtrer par fournisseur, est une évolution : elle se facture. Entre les deux, il existe une zone d’interprétation large, et elle se tranche beaucoup mieux par écrit avant la livraison qu’au téléphone trois mois après.
Quatre éléments suffisent à cadrer une garantie : sa durée, sa définition de l’anomalie — un écart par rapport au comportement spécifié —, le délai de prise en charge selon la gravité, et la liste de ce qui en est explicitement exclu. Un prestataire qui garantit tout, gratuitement et sans limite de durée, a soit intégré ce risque dans son prix, soit prévu de ne pas honorer la promesse.
Reste l’essentiel, qui n’est pas la garantie : la vie du projet après elle. Un développement se construit en quelques mois et s’exploite pendant des années. Mes missions les plus longues le montrent sans ambiguïté : dix ans sur l’extranet d’un groupement national, cinq ans de maintenance mensuelle pour une fondation hospitalière. La question à poser avant de signer n’est donc pas seulement « qui corrige les bugs en janvier », mais « à quelles conditions et à quel tarif ce travail continue-t-il dans trois ans » — un sujet que je détaille sur ma page maintenance et accompagnement.
Mettre ces engagements dans le devis
Rien de ce qui précède ne demande un avocat ni une négociation de plusieurs semaines. Quatre questions, posées par courriel avant la signature, suffisent à faire apparaître l’essentiel :
- Quels sont les jalons intermédiaires, et quel livrable vérifiable est attendu à chacun ?
- Quels droits exactement me sont cédés sur le résultat, et sous quelle forme est-ce écrit ?
- Au nom de qui sont ouverts l’hébergement et le nom de domaine, et qui détient les accès administrateur ?
- Que couvre la garantie, pendant combien de temps, et qu’est-ce qui en est exclu ?
Un prestataire qui travaille proprement répond à ces quatre questions en quelques lignes, parce qu’il a déjà les réponses. Un prestataire qui esquive, renvoie à « plus tard » ou s’agace vous donne une information au moins aussi utile que celle que vous demandiez. Cette lecture du comportement pendant la phase de devis est d’ailleurs un bon révélateur en soi, comme je l’évoque dans développeur freelance ou agence web.
Pour aller plus loin
7 questions à poser avant de lancer un projet digital pour votre PME
Le guide reprend ces questions contractuelles et les replace dans l'ordre complet des sept points à verrouiller avant de signer, avec la réponse type d'un prestataire sérieux et les signaux d'alerte à chaque étape.
Télécharger le guide gratuitementMa recommandation
Ne transformez pas votre devis en contrat de cinquante pages : dans les projets que je mène, trois paragraphes ajoutés au devis couvrent 90 % du risque réel. Un paragraphe de jalons avec les obligations des deux parties, un paragraphe de cession de droits qui énumère les droits cédés, un paragraphe de garantie qui définit l’anomalie et ses exclusions.
Et si vous hésitez à les demander par peur de paraître méfiant : c’est l’inverse qui se produit. Un prestataire expérimenté lit ces demandes comme le signe d’un client qui sait où il va — et ces clauses le protègent autant que vous, parce qu’elles disent aussi noir sur blanc ce qu’il ne s’est pas engagé à faire. Les projets qui finissent mal ne sont presque jamais ceux où ces sujets ont été posés au début. Ce sont ceux où personne n’a voulu les ouvrir.
Si vous préparez un projet d’outil interne et que vous voulez cadrer ces engagements avant de lancer les devis, je le fais régulièrement en amont de mes missions d’applications métier sur mesure.
Questions fréquentes
Le travail réalisé par un développeur freelance m'appartient-il automatiquement ?
Non. La loi attribue les droits d'exploitation d'un logiciel à l'employeur lorsqu'il est créé par un salarié (article L. 113-9 du Code de la propriété intellectuelle), mais un prestataire indépendant n'est pas un salarié : ce mécanisme ne s'applique pas à lui. Sans clause de cession écrite dans le contrat, vous avez payé une prestation sans acquérir les droits qui vont avec. L'article L. 131-3 du même code exige en outre que chaque droit cédé fasse l'objet d'une mention distincte, et que le domaine d'exploitation soit délimité en étendue, destination, lieu et durée.
Qui doit héberger le code et les données d'un projet confié à un prestataire ?
Vous, dans des comptes ouverts à votre nom et sur lesquels vous détenez l'accès administrateur. Un prestataire peut tout à fait gérer l'hébergement pour vous — c'est souvent plus simple — mais la facture doit être à votre nom et les accès partagés, pas détenus par lui seul. C'est la différence entre déléguer l'exploitation et perdre la main sur son propre outil.
Quels délais exiger dans un devis de développement ?
Des jalons intermédiaires plutôt qu'une seule date finale, chacun associé à un livrable identifiable et à un délai de validation de votre côté. Une date isolée en bas d'un devis, sans conséquence prévue si elle glisse, n'est qu'une intention. Précisez aussi ce que vous devez fournir et à quelle échéance : les retards de projet viennent au moins autant du client que du prestataire.
Que couvre réellement la garantie d'un développement sur mesure ?
Dans la plupart des devis, la correction gratuite des anomalies pendant quelques mois après la mise en ligne. Tout l'enjeu est la définition d'une anomalie : un comportement contraire à ce qui était spécifié relève de la garantie, un besoin apparu après la livraison relève d'une évolution facturable. Faites écrire cette frontière, la durée, et le délai de prise en charge — pas seulement le mot « garantie ».