Contrat de product builder freelance : les clauses à ne pas oublier

Un contrat de product builder doit répondre à six questions avant le démarrage : quoi livrer, comment le valider, combien et quand payer, à qui appartient le résultat, à qui sont les comptes des outils, et comment sont protégées les données. Les missions no-code et IA ont leurs pièges propres : abonnements aux outils, code généré par l'IA, données clients qui transitent par des services tiers.

Cet article partage de l'information, pas un conseil juridique : pour un contrat à fort enjeu, faites relire votre modèle par un juriste.

Quelles clauses prévoir dans un contrat de prestation no-code ?

Voici les clauses essentielles, et la question à laquelle chacune répond.

Comment cadrer le périmètre et la recette ?

Le périmètre est la clause qui évite le plus de conflits. Listez les fonctionnalités prévues, puis ce qui est explicitement exclu. Toute demande hors périmètre devient un avenant ou un devis complémentaire.

La recette fixe la règle du jeu à la livraison : un délai pour tester (par exemple 10 jours ouvrés), une liste d'anomalies à corriger, et ce qui vaut validation si le client ne répond pas. Sans cette clause, un projet peut rester « presque fini » indéfiniment. La méthode pour cadrer un projet de bout en bout est détaillée dans gérer un projet client de A à Z.

À qui appartient l'application livrée ?

Par défaut, en France, le freelance reste titulaire des droits sur ce qu'il crée : payer la prestation ne transfère pas la propriété. Pour que le client obtienne des droits, le contrat doit prévoir une cession. Selon l'article L131-3 du Code de la propriété intellectuelle, elle n'est valable que si elle précise chaque droit cédé (reproduction, adaptation, diffusion…), son domaine d'exploitation, le territoire et la durée. Un droit non listé reste au freelance.

Trois points sont propres aux missions no-code et IA :

• Les briques réutilisables : vos modèles, scénarios ou composants préexistants peuvent être exclus de la cession et concédés en simple licence.
• Les outils eux-mêmes restent la propriété de leurs éditeurs : le client acquiert un usage dans le cadre de leurs conditions, pas la plateforme.
• Le contenu généré par l'IA : seule une personne humaine peut être auteur. Ce qui est entièrement produit par une IA, sans apport créatif humain, n'est en principe pas protégé par le droit d'auteur. Mieux vaut le dire clairement au client.

Une bonne pratique : prévoir que la cession ne prend effet qu'au paiement complet.

À qui sont les comptes et les abonnements des outils ?

Idéalement, les comptes sont ouverts au nom du client, qui paie directement ses abonnements. Le client garde ainsi la main sur ses données et ses outils si la collaboration s'arrête, et le freelance n'avance pas de frais. Le freelance y est invité comme collaborateur. Si vous utilisez vos propres comptes pendant le développement, le contrat doit prévoir le transfert à la livraison.

Quelles obligations sur les données personnelles ?

Dès qu'une automatisation ou une application traite des données personnelles pour le compte du client, le freelance est en général sous-traitant au sens du RGPD. L'article 28 du RGPD impose alors un contrat qui précise l'objet, la durée et les mesures de sécurité du traitement. Listez aussi les services tiers par lesquels transitent les données (outil d'automatisation, modèle d'IA), et l'endroit où elles sont hébergées. Pour les projets qui intègrent un chatbot ou une décision automatisée, voir aussi l'AI Act en 2026.

Se former à la contractualisation

Bien contractualiser fait partie du métier, au même titre que construire. L'École Cube a consacré une masterclass gratuite à la contractualisation pour les product builders IA, disponible avec ses autres masterclass en replay^partenaire. Pour le statut et les tarifs, lisez du CDI à product builder freelance, et pour comparer les parcours de l'école, voici toutes les formations Cube^partenaire.