L'agence est-elle automatiquement propriétaire du code livré ?

Non, et c'est le contresens le plus fréquent. En droit français, l'auteur d'un code en reste titulaire des droits tant qu'une cession écrite et précise n'a pas eu lieu. Payer une prestation ne vaut pas cession des droits d'auteur. Sans clause explicite de cession, vous avez un droit d'usage mais pas la pleine propriété, ce qui peut poser problème le jour où vous voulez revendre ou faire évoluer le site ailleurs. Faites valider la formulation par un avocat.

La clause de non-sollicitation du client final est-elle valable ?

Elle l'est si elle est proportionnée : durée limitée, périmètre défini, et une contrepartie qui n'étrangle pas le sous-traitant. Une non-sollicitation illimitée dans le temps ou dans son champ risque d'être jugée abusive et donc inapplicable. Le bon réflexe est de viser précisément le client final présenté dans le cadre de la mission, pour une durée raisonnable, pas d'interdire au développeur tout un secteur d'activité. Un avocat calibrera la durée selon votre situation.

Qui doit héberger le site, l'agence ou le développeur ?

Peu importe le choix tant que le contrat dit ce qui se passe à la rupture. Le vrai risque n'est pas de savoir qui héberge, mais de se retrouver avec un site en otage sur un compte qu'on ne contrôle pas. Exigez une clause qui garantit la remise des accès, des sauvegardes et des noms de domaine sous un délai précis, même en cas de litige sur le paiement. C'est la clause de réversibilité qui vous évite la prise d'otage technique.

Faut-il un contrat RGPD séparé avec le développeur ?

Dès que le développeur traite des données personnelles pour votre compte, l'article 28 du RGPD impose un acte de sous-traitance écrit, souvent appelé accord de traitement. Il peut être intégré au contrat principal ou annexé. Il précise les finalités, la durée, les mesures de sécurité et le sort des données en fin de mission. C'est une obligation légale, pas une option, et son absence engage votre responsabilité de responsable de traitement en cas de contrôle.

Contrat de sous-traitance développeur : les clauses qui comptent

Un confrère m'a raconté avoir perdu l'accès complet à un site qu'il avait pourtant payé, parce que son ancien sous-traitant hébergeait tout sur son propre compte et refusait de rendre les clés tant qu'une facture contestée n'était pas soldée. Le site tournait toujours, le client final ne voyait rien, mais l'agence ne pouvait plus rien modifier, plus rien sauvegarder, plus rien migrer. Techniquement, elle était propriétaire de rien. Ce genre de situation ne se règle pas dans l'urgence : elle se prévient dans le contrat, avant que la relation ne se tende. Je vais parcourir les clauses qui comptent vraiment, celles dont l'absence coûte cher, en précisant d'emblée un point : je suis développeur, pas juriste, et le contrat final doit passer entre les mains d'un avocat. Ce qui suit vous dit où regarder, pas ce qu'il faut signer les yeux fermés.

La propriété du code ne se transmet pas avec la facture

Commençons par le malentendu le plus répandu, celui qui fait le plus de dégâts parce qu'il passe inaperçu jusqu'au jour où il compte. Payer un développeur ne vous rend pas automatiquement propriétaire du code qu'il produit. En droit français, l'auteur d'une œuvre logicielle conserve ses droits patrimoniaux tant qu'une cession écrite, précise et délimitée n'est pas intervenue. Autrement dit, sans clause de cession, vous avez acheté une prestation et un droit d'usage, mais pas la faculté de faire ce que vous voulez du code, y compris le confier à un autre prestataire ou le revendre avec le fonds.

La clause de cession doit nommer les droits cédés, l'étendue, la durée et le territoire. Une formule vague du type le client est propriétaire du site ne suffit pas juridiquement, même si elle rassure. Je conseille de distinguer deux couches : le code spécifique développé pour le projet, qui a vocation à être cédé, et les composants réutilisables ou briques open source que le développeur intègre et qu'il ne peut pas céder parce qu'ils ne lui appartiennent pas. Un développeur honnête vous dira franchement ce qu'il cède et ce qu'il vous licencie, et c'est cette franchise que vous voulez voir apparaître noir sur blanc. Le choix de la stack technique influence directement cette question, un sujet que j'aborde dans Symfony ou WordPress pour un site client.

La non-sollicitation protège votre relation client, dans la limite du raisonnable

Vous présentez votre client final à un sous-traitant, et vous voulez éviter qu'il vous court-circuite six mois plus tard en proposant directement ses services. La clause de non-sollicitation répond à ce risque, mais elle marche sur une ligne de crête. Trop molle, elle ne protège rien. Trop dure, elle devient inapplicable, parce qu'un juge peut requalifier en abusive une clause qui interdit au développeur de travailler pour tout un secteur ou sans limite de temps.

Ce qui tient, c'est une clause proportionnée : elle vise nommément le client final présenté dans le cadre de la mission, pour une durée raisonnable après la fin de la collaboration, et elle n'empêche pas le développeur d'exercer son métier ailleurs. Je précise un point de bon sens que mon avocat m'a rappelé : une non-sollicitation crédible se double souvent d'une contrepartie ou au minimum d'un équilibre, parce qu'une interdiction totalement gratuite et déséquilibrée fragilise sa validité. Le bon calibrage dépend de votre situation exacte, et c'est précisément le genre de curseur qu'un avocat ajuste, ni vous ni moi.

Le sort de l'hébergement décide qui tient les clés à la rupture

Je reviens au cas d'ouverture parce qu'il illustre la clause la plus sous-estimée. La question n'est pas de savoir qui héberge, agence ou développeur, mais ce qui se passe le jour où la relation s'arrête, y compris dans le désaccord. Un site vit sur un empilement d'accès : le serveur, le nom de domaine, les DNS, les sauvegardes, parfois les comptes tiers comme un service d'envoi d'e-mails ou une passerelle de paiement. Celui qui contrôle ces accès contrôle le site, indépendamment de qui a payé quoi.

La clause à exiger garantit la remise de l'ensemble de ces accès et des sauvegardes sous un délai précis à la fin de la mission, y compris en cas de litige sur le paiement, le litige financier se réglant par ailleurs sans prendre le site en otage. Séparer les deux plans, le technique et le financier, est ce qui vous évite la prise d'otage. J'ai vu trop d'agences découvrir cette clause par son absence, le jour où elles ont dû reprendre un site dont le prestataire était parti. Anticiper coûte une phrase dans un contrat ; réparer coûte des semaines et parfois une reconstruction.

La réversibilité, c'est la clause de sortie que personne ne lit à la signature

Dans le prolongement de l'hébergement, la réversibilité mérite sa propre clause. Elle décrit concrètement ce que le développeur remet pour qu'un autre puisse prendre le relais : le code source dans un format standard et versionné, la documentation d'installation, la liste des dépendances et des services externes, les procédures de déploiement. Une réversibilité bien écrite, c'est la garantie que vous n'êtes prisonnier de personne, ni du sous-traitant ni de sa manière de faire.

Je mesure cette clause à un test simple : si demain je disparais, un autre développeur de niveau équivalent peut-il reprendre le projet en une journée de prise en main, sans avoir à me téléphoner. Si la réponse est non, la réversibilité est théorique. C'est aussi ce qui distingue une prestation propre d'un travail qui vous enchaîne, et c'est un critère que je recommande d'évaluer avant même de signer, au même titre qu'un audit technique sur un existant. La réversibilité conditionne d'ailleurs directement la qualité de la maintenance que vous pourrez assurer ensuite, en interne ou avec un autre prestataire.

Le RGPD n'est pas optionnel dès qu'il y a des données personnelles

Voici le point où je vois le plus d'agences naviguer à l'aveugle, alors que le risque est réel et documenté. Dès que le développeur traite des données personnelles pour votre compte, formulaire de contact, comptes clients, historique de commandes, il devient votre sous-traitant au sens du RGPD, et l'article 28 du règlement impose un acte écrit encadrant ce traitement. On l'appelle souvent accord de traitement des données, et il peut être intégré au contrat principal ou annexé, peu importe la forme tant que le fond y est.

Cet acte doit préciser l'objet et la durée du traitement, sa finalité, les catégories de données concernées, les mesures de sécurité mises en œuvre, le recours éventuel à d'autres sous-traitants, et le sort des données à la fin de la mission, restitution ou suppression. Ce n'est pas une formalité de confort : en tant que responsable de traitement, c'est votre responsabilité qui est engagée en cas de contrôle ou d'incident, et l'absence de cet acte est en soi un manquement. Un développeur sérieux vous le proposera de lui-même ou acceptera sans broncher de le formaliser. Celui qui traîne des pieds sur ce point vous en apprend beaucoup sur sa manière de travailler. La formulation exacte, là encore, relève de l'avocat, surtout si le traitement touche des données sensibles.

Le contrat parfait peut tuer la relation avant qu'elle commence

Je vais nuancer tout ce qui précède, parce qu'un contrat n'est pas qu'un bouclier et qu'à trop le blinder, on se tire une balle dans le pied. J'ai reçu des projets de contrat de sous-traitance de trente pages, empilant pénalités de retard automatiques, clauses de responsabilité illimitée, non-concurrence étouffante et audits unilatéraux. Le message qu'un tel document envoie est limpide : cette agence me considère d'abord comme un risque à contenir, pas comme un partenaire. Ma réponse est tout aussi limpide, je passe mon tour, ou je gonfle mon prix pour couvrir l'hostilité contractuelle que je pressens.

Un contrat déséquilibré sélectionne les mauvais sous-traitants. Les bons développeurs, ceux qui ont du travail et le choix de leurs clients, déclinent une relation qui commence par de la défiance. Il vous reste alors ceux qui n'ont pas le choix, c'est-à-dire souvent pas les meilleurs. Le contrat juste protège les deux parties sur les points qui comptent vraiment, propriété, réversibilité, RGPD, sortie propre, et fait confiance sur le reste. Il tient en quelques pages lisibles, pas en un pavé anxiogène. Cette recherche d'équilibre est au cœur de la manière dont je conçois la relation avec les agences partenaires, où la répétition des projets vaut mille clauses coercitives.

Le meilleur garde-fou n'est d'ailleurs pas contractuel, il est relationnel, et il tient dans un revenu partagé qui dure. Une collaboration qui rapporte régulièrement aux deux parties se protège d'elle-même, parce que personne n'a intérêt à la briser, un mécanisme que je détaille dans mon article sur le revenu récurrent en agence web. Le contrat pose le cadre du pire ; la relation, elle, construit le meilleur. Faites rédiger le premier par un avocat, et cultivez la seconde vous-même. Aucun des deux ne remplace l'autre.