Freelance info

Après le statut et le tarif, ce qu’on signe

Le parcours d’entrée est balisé : choisir une forme juridique, calculer un taux journalier, décrocher une première mission. Ces questions se règlent en quelques semaines et se posent une fois.

Le contrat, lui, se pose à chaque mission. Et c’est là que se joue l’exposition réelle d’un indépendant en informatique : ce qu’il cède, ce dont il répond, ce qu’il doit rendre, et ce qui peut se retourner contre lui des mois plus tard. Un développeur peut avoir un statut irréprochable et signer, sans le voir, un contrat qui le prive des droits sur son travail ou l’expose à un litige de responsabilité.

Quatre terrains méritent d’être compris avant de signer : la nature de l’engagement, la propriété du code, les données que l’on manipule, et la façon dont une mission qui dure peut changer de nature.

Forfait ou régie

deux contrats, deux responsabilités

La distinction se présente souvent comme une modalité de facturation — au projet ou à la journée. C’est une lecture incomplète : ce qui change, c’est ce sur quoi on s’engage.

Au forfait, une estimation optimiste ne se paie pas seulement en nuits blanches : elle se prélève directement sur la marge, et parfois la dépasse. C’est aussi le mode où le périmètre doit être écrit avec le plus de soin, parce que la moindre ambiguïté sera tranchée en défaveur de celui qui a proposé le contrat, et parce que chaque ajout non prévu devient une négociation.

En régie, le risque financier est moindre, mais la contrepartie est une dépendance qui s’installe. Le client pilote, décide des priorités, et supporte les conséquences d’un cahier des charges qui bouge.

Entre les deux, beaucoup de contrats hybrides : régie avec un engagement de livrable, forfait avec des jours additionnels. Ces montages ne sont pas illégitimes, à condition que le document dise clairement lequel des deux régimes s’applique à quoi.

À qui appartient le code que vous écrivez

C’est l’erreur la plus répandue, et elle circule dans les deux sens. Beaucoup de clients pensent qu’ayant payé, ils sont propriétaires de tout. Beaucoup de prestataires le pensent aussi.

Le droit français dit autre chose. Le code est une œuvre de l’esprit, protégée à ce titre, et l’existence d’un contrat de prestation n’emporte pas dérogation au droit d’auteur. Autrement dit : à défaut de cession expresse et écrite, l’auteur reste titulaire des droits patrimoniaux sur ce qu’il a produit. La facture acquittée ne vaut pas transfert.

Une confusion fréquente vient du régime des salariés. Pour les logiciels créés par un salarié dans l’exercice de ses fonctions, les droits patrimoniaux sont dévolus à l’employeur, qui est seul habilité à les exercer. Cette règle est propre au contrat de travail. Elle ne s’étend pas aux prestataires indépendants, qui sont précisément en dehors de ce lien.

Quand la cession a lieu, elle obéit à un formalisme strict et souvent ignoré : chaque droit cédé doit faire l’objet d’une mention distincte, avec délimitation de son étendue, de sa destination, du lieu et de la durée. Une clause qui se contente d’écrire que le client devient propriétaire de tous les droits, sans autre précision, est fragile. Elle protège mal le client, qui croit avoir tout acquis, et laisse le prestataire dans l’incertitude.

Dès qu’il y a des données personnelles, vous êtes sous-traitant

Intervenir sur une base de production, un back-office, un fichier d’export ou un environnement de test alimenté par des données réelles suffit à faire entrer la mission dans le champ du règlement européen sur la protection des données.

Le vocabulaire compte ici. Le client, qui décide pourquoi et comment les données sont traitées, est responsable de traitement. Le prestataire qui intervient pour son compte est sous-traitant. Ce n’est pas une question de taille ni de durée : un développeur seul, sur une mission de trois semaines, occupe ce rôle dès qu’il manipule des données identifiantes.

Cette qualification impose un contrat écrit entre les deux parties, qui encadre l’objet et la durée du traitement, sa nature, les catégories de personnes concernées, les mesures de sécurité et le sort des données en fin de mission. Ce document accompagne le contrat de prestation, il ne s’y substitue pas.

Au-delà du formalisme, quelques réflexes évitent la plupart des problèmes : travailler sur des données anonymisées ou fictives chaque fois que c’est techniquement possible, ne pas rapatrier une copie de base de production sur son poste personnel parce que c’est plus commode, ne conserver aucune sauvegarde après la fin de la mission sauf demande écrite du client, et signaler sans attendre toute anomalie qui ressemble à une fuite. Le prestataire qui découvre l’incident et se tait aggrave sa propre situation.

La régie longue et le risque de requalification

Une mission en régie qui se prolonge chez le même client finit par ressembler à un poste. C’est un risque juridique identifié, qui porte un nom : la requalification de la relation en contrat de travail.

Aucune durée ne déclenche mécaniquement ce basculement. Ce qui compte, c’est un faisceau d’indices convergents, tous rattachés à une même notion : le lien de subordination. Des horaires imposés et contrôlés. Une intégration dans une équipe et une ligne hiérarchique, avec des comptes rendus à un responsable interne. Des moyens entièrement fournis par le client, poste de travail comme outils. L’absence d’autonomie sur la méthode et l’organisation du travail. Une présence exigée dans les locaux sans nécessité technique. Et, en toile de fond, un client unique qui occupe la totalité de l’activité depuis longtemps.

Aucun de ces éléments ne suffit isolément. Beaucoup de missions imposent légitimement un lieu ou des horaires, pour des raisons d’accès aux systèmes ou de sécurité. C’est leur accumulation qui pose problème.

Le risque n’est pas symétrique. Le client s’expose à un redressement et aux conséquences d’une relation de travail reconstituée. Le prestataire, lui, peut voir sa mission s’interrompre brutalement quand le client prend conscience du sujet, et perdre du jour au lendemain sa seule source de revenus. La parade est moins juridique qu’organisationnelle : conserver ses propres outils quand c’est possible, garder une trace de son autonomie sur la méthode, éviter la dépendance à un client unique, et redéfinir périmètre et durée à chaque renouvellement plutôt que de laisser le contrat se reconduire tacitement pendant des années.

Assurance, restitution, documentation

Trois sujets se règlent en fin de mission mais se décident au début.

La responsabilité civile professionnelle couvre les dommages causés au client dans l’exercice de la prestation. Elle n’est pas imposée par la loi à tous les prestataires informatiques, contrairement à ce qu’on lit parfois ; elle est en revanche très souvent exigée par le contrat, et réclamée sous forme d’attestation avant le démarrage. La souscrire après avoir signé, c’est découvrir tardivement qu’on s’est engagé sur une couverture qu’on n’a pas.

La restitution concerne les accès et les livrables. Un prestataire garde souvent, sans y penser, des identifiants, des clés, des accès à des environnements ou à des dépôts. La fin de mission est le moment de les rendre et de les faire révoquer — dans l’intérêt du client, mais aussi dans celui du prestataire, qui n’a rien à gagner à conserver des accès à un système dont il n’a plus la charge.

La documentation, enfin, distingue une mission qui se termine d’une mission qui laisse le client captif. Prévoir dès le devis ce qui sera livré — schéma d’architecture, procédure de déploiement, dépendances, comptes techniques — évite la dernière semaine passée à écrire en urgence ce qui aurait dû s’écrire au fil de l’eau. C’est aussi un argument commercial : le prestataire qui rend un système reprenable par un autre est celui qu’on rappelle.

Les clauses à lire avant de signer

Une relecture méthodique prend une heure et se concentre sur huit points.

Sur les contrats importants, faire relire le document par un professionnel du droit reste le réflexe le plus sûr, en particulier pour la clause de cession, dont les effets se découvrent parfois des années après la fin de la mission.