3 missions perdues sur une clause de propriété intellectuelle — les 7 étapes de contrat que j’aurais dû exiger dès la première

En douze ans d’indépendance, j’ai signé une centaine de contrats de mission. Trois m’ont coûté cher, et jamais pour la raison que j’anticipais. Aucun litige sur le tarif. Aucun sur la qualité du code. Les trois se sont joués sur des lignes que j’avais lues en diagonale parce qu’elles ressemblaient à du remplissage juridique.

La plus douloureuse : un moteur de règles que j’avais développé sur mon temps propre, réutilisé sur une mission, et qu’un client a considéré comme sa propriété exclusive au titre d’une cession globale. Il avait juridiquement raison, parce que rien dans le contrat ne disait le contraire. J’ai réécrit le moteur de zéro pour la mission suivante.

Voici la méthode que j’applique désormais, en sept étapes, dans l’ordre de rédaction. Elle ne demande pas d’avocat pour des missions courantes, et elle tient en trois pages.

Étape 1 — Décrire le périmètre en livrables, pas en jours

Un contrat qui dit « quarante jours d’intervention sur le projet X » ne décrit rien de réceptionnable. Il vend du temps, ce qui vous expose à la seule question qui n’a pas de réponse objective : est-ce que quarante jours, c’était trop ?

Un contrat qui dit « livraison du module d’authentification, du module de facturation et de la migration de données, réceptionnés selon les critères de l’annexe 1 » vend des résultats identifiables. Le débat sur le temps passé disparaît, remplacé par une question binaire et vérifiable : le livrable correspond-il aux critères ?

Cela ne signifie pas passer au forfait. On peut parfaitement facturer au taux journalier avec des jalons de réception — c’est même la configuration la plus saine, elle combine la souplesse de la régie et la protection du forfait. Ce qu’il faut éviter est la mission au jour sans aucun livrable identifié, où votre seule preuve de travail est un relevé d’heures contestable en bloc.

Étape 2 — Limiter la cession de droits d’auteur au strict nécessaire

Ouvrez le contrat qu’on vous propose et cherchez la formule. Elle ressemble presque toujours à ceci : « le prestataire cède au client l’ensemble des droits patrimoniaux sur les développements réalisés ».

La cession en elle-même est légitime : le client paie pour du code écrit spécifiquement pour lui, il est normal qu’il en dispose. Le problème est le périmètre non borné. « L’ensemble des développements réalisés » englobe, dans sa lecture littérale, les briques que vous aviez avant la mission et que vous avez intégrées au projet.

Deux ajouts corrigent la situation, et ils tiennent en deux phrases :

• La cession porte sur les développements réalisés spécifiquement dans le cadre de la mission, à l’exclusion des composants préexistants du prestataire.
• Les composants préexistants, listés en annexe 2, font l’objet d’une licence d’usage non exclusive, perpétuelle et cessible au bénéfice du client dans le cadre du projet.

Le client obtient exactement ce dont il a besoin : le droit d’utiliser, modifier et transmettre le tout sans dépendre de vous. Vous conservez le droit de réutiliser vos propres briques ailleurs. Personne ne perd, et je n’ai jamais vu cette rédaction refusée.

Étape 3 — Nommer vos briques réutilisables avant le début de la mission

L’annexe évoquée ci-dessus est le document le plus rentable de tout le contrat, et c’est celui que personne ne rédige. Elle doit être établie avant le démarrage, jamais pendant, parce qu’une brique ajoutée en cours de route à une liste de composants préexistants soulève immédiatement une question de bonne foi.

Le contenu est simple : nom du composant, description en une ligne, date de création approximative, régime de licence. Cinq lignes suffisent pour la plupart des indépendants. Si vous n’avez jamais fait cet inventaire, comptez une heure la première fois, puis dix minutes par contrat.

Étape 4 — Encadrer l’usage des composants open source

Sujet systématiquement absent des contrats de mission, et systématiquement présent dans les projets. Trois lignes le règlent.

D’abord, la liste des familles de licences autorisées par le client. La plupart des directions techniques ont une politique écrite ; demandez-la, elle existe. Si elle n’existe pas, proposez une liste par défaut, ce qui vous protège d’une contestation ultérieure.

Ensuite, l’obligation de tenir un inventaire des dépendances et de leurs licences. C’est un livrable comme un autre, produit automatiquement par vos outils, et il vous protège autant qu’il protège le client.

Enfin, et c’est le point délicat, l’attribution de la responsabilité de conformité. Un développeur indépendant ne peut pas raisonnablement garantir la conformité juridique de trois cents dépendances transitives. La formulation équilibrée est un engagement de moyens sur l’inventaire et le respect de la liste convenue, pas une garantie de résultat sur toute la chaîne. Le sujet rejoint directement l’hygiène de dépendances que nous détaillons dans sécuriser ses dépendances contre les attaques de chaîne d’approvisionnement.

Étape 5 — Poser des jalons de paiement adossés à la réception

Le risque d’impayé d’un indépendant ne se joue pas sur le taux journalier mais sur l’exposition maximale : le montant de travail livré et non encore payé à un instant donné.

Sur une mission de six mois facturée en fin de projet, cette exposition atteint la totalité du contrat. Sur la même mission découpée en jalons mensuels, elle plafonne à un mois plus le délai de règlement. Le tarif est identique ; le risque est divisé par six.

Deux mécanismes à ajouter systématiquement. Un acompte au démarrage, entre 20 et 30 % — c’est aussi un excellent test de la solvabilité et du sérieux du client. Et un délai de réception tacite : sans retour écrit sous dix jours ouvrés, le livrable est réputé réceptionné. Sans cette dernière clause, un client silencieux peut suspendre indéfiniment votre facturation sans jamais rien refuser.

Étape 6 — Exiger des pénalités symétriques

La quasi-totalité des contrats de mission qu’on vous proposera contient des pénalités de retard applicables au prestataire. C’est légitime. Ce qui l’est moins est qu’elles soient à sens unique, car dans un projet de développement, la majorité des retards ne viennent pas du prestataire.

Ils viennent d’une validation qui n’arrive pas, d’un accès à un environnement promis pour lundi et livré trois semaines plus tard, d’une spécification en attente d’arbitrage entre deux services du client. Vous subissez ces retards, vous ne les facturez pas, et vous êtes pénalisé sur la date de livraison finale qu’ils ont décalée.

La rédaction symétrique est courte : les délais de livraison sont suspendus de plein droit pendant toute période où le prestataire est en attente d’un élément incombant au client, dès lors que cette attente a été notifiée par écrit. Ajoutez, si le rapport de force le permet, une indemnité d’immobilisation au-delà de dix jours ouvrés d’attente.

La notification écrite est la partie qui compte. Une attente non notifiée n’existe pas au contrat. Un courriel de trois lignes le jour où le blocage commence vaut mieux qu’une réclamation argumentée trois mois plus tard.

Étape 7 — Écrire la rupture anticipée et le sort du code non payé

Dernière étape, et la seule qui se négocie mal après coup. Deux volets.

Le premier est le préavis de rupture. Un mois pour une mission de moins de six mois, deux mois au-delà, avec règlement de l’intégralité des travaux réalisés et réceptionnés à la date d’effet. Sans préavis écrit, une mission peut s’arrêter du jour au lendemain et votre plan de charge avec.

Le second est la clause la plus utile de tout le document : la cession des droits patrimoniaux n’est effective qu’au paiement intégral de la facture correspondante. Le client reçoit un droit d’usage provisoire pendant le délai de règlement, qui se transforme en cession définitive au paiement.

Cette rédaction est courante, elle n’a rien d’agressif, et elle change tout sur une relance d’impayé. Sans elle, le code est livré, la cession a produit ses effets, et il vous reste un recours en recouvrement dont le coût dépasse souvent l’enjeu. Avec elle, la conversation devient courte.

Ce que ces sept étapes ne couvrent pas

Elles ne remplacent pas un avocat sur une mission stratégique au-delà de 100 000 euros, ni sur un contrat de sous-traitance en cascade avec des clauses de responsabilité en chaîne. Elles ne traitent pas non plus la question fiscale et sociale, que nous abordons dans cotisations et statut du développeur indépendant.

Elles couvrent en revanche l’écrasante majorité des missions de développement entre 15 000 et 100 000 euros, qui est le cœur du marché français. Sur ce segment, les sept clauses ci-dessus règlent à peu près tous les litiges que j’ai vus passer, chez moi comme chez des confrères.

Pour la partie sécurité et conformité du code livré, sujet de plus en plus souvent contractualisé côté client, nos confrères de WebGuard Agency publient régulièrement. Et si la mission comporte un volet intelligence artificielle, les clauses de propriété des prompts et de réversibilité méritent un traitement à part, détaillé par Plug-Tech.

Enfin, si votre mission consiste justement à construire ce type de produit, notre guide créer une plateforme freelance traite le cadrage côté produit, et les tarifs du développeur freelance en France complètent l’amont commercial de la négociation.

Questions fréquentes