Quand on confie le développement d'un logiciel à une équipe externe, on veut être sûr de deux choses : le code et le savoir-faire restent là où ils doivent être, et le résultat revient bien au client à la fin. Le NDA est généralement le premier document signé. Mais la protection de la propriété intellectuelle au quotidien dépend d'autres questions : qui accède à quel dépôt, où sont stockés les identifiants, et que se passe-t-il quand quelqu'un quitte l'équipe ?
Cet article décrit comment nous organisons cela dans une Équipe nearshore répartie sur trois sites, et où la technique atteint ses limites.
Un NDA impose une obligation de confidentialité. Le contrat de développement précise qui obtient quels droits sur le code produit. Sur le plan technique, le code est protégé par des droits d'accès limités dans le temps, une procédure d'offboarding définie, une gestion centralisée des secrets, des dépôts séparés et la journalisation des accès. Les clients règlent l'aspect contractuel avec leur service juridique ou leur cabinet d'avocats.
Ce que couvre un NDA
Un NDA détermine qui peut transmettre des informations à des tiers. Il ne règle pas qui peut utiliser, modifier ou revendre le code. Cela relève du contrat de développement.
Une règle de la loi allemande sur le droit d'auteur montre pourquoi cette distinction compte pour les équipes externes. Selon le § 69b de la loi allemande sur le droit d'auteur (UrhG) les droits patrimoniaux sur un logiciel écrit par des salariés dans le cadre de leurs fonctions reviennent à l'employeur. Cette règle ne s'applique pas aux prestataires externes. Pour eux, la concession des droits d'utilisation est régie par le contrat (§ 31 UrhG). La forme que doit prendre une telle clause dans un cas précis relève de l'appréciation d'un service juridique ou d'un cabinet d'avocats. Nous nous en tenons ici à la partie dont nous sommes responsables en tant que développeurs.
Où la propriété intellectuelle se perd au quotidien
Le vol délibéré est rare. Les failles typiques sont d'ordre organisationnel :
- Un dépôt qui contient le code de plusieurs clients, ou des comptes privés par lesquels des développeurs accèdent au code client
- Des droits d'accès attribués largement en début de projet, puis jamais ajustés
- Des clés API et des mots de passe dans des fichiers de configuration, des tickets ou des historiques de chat
- Des accès d'anciens membres de l'équipe, encore actifs des semaines après leur départ
Un NDA n'empêche aucun de ces cas. Les quatre peuvent être éliminés par des mesures techniques et organisationnelles.
Les mesures, dans l'ordre où nous les mettons en place
- Des droits d'accès selon les besoins. Chaque personne obtient l'accès aux systèmes dont elle a besoin pour sa tâche en cours, limité à la durée de cette tâche. C'est le plus grand risque au quotidien, et en même temps la mesure qui demande le moins d'effort.
- Un offboarding selon une procédure fixe. Quand quelqu'un quitte le projet, tous ses accès sont retirés le jour même, selon une liste de contrôle et non de mémoire.
- Une gestion centralisée des secrets. Les identifiants sont stockés dans un système conçu à cet effet, pas dans des fichiers ou des chats.
- Des dépôts séparés pour chaque client. Selon nous, la meilleure solution est que le code se trouve dès le départ dans un dépôt appartenant au client. La question de la remise du code ne se pose alors pas en fin de projet.
- Une journalisation des accès. Les accès sont enregistrés, afin de pouvoir retracer plus tard qui a accédé à quoi et quand.
Comment c'est organisé chez torck
Dans chaque projet, le cocontractant est torck GmbH en Allemagne, même lorsque des développeuses et développeurs de Vienne ou de Rabat y participent. Rabat est une société torck à part entière, et non un partenaire intermédiaire. Pour les clients, cela signifie un seul contrat, un seul interlocuteur et aucune chaîne de sous-traitants par laquelle les accès transitent.
Les revues de code, le pipeline CI/CD et les règles d'accès sont identiques sur les trois sites. Le décalage horaire entre Maxhütte-Haidhof et Rabat est le plus souvent nul ou d'une heure. Les autorisations et les retraits d'accès se font donc dans la même journée de travail. Avec des équipes en Asie, ils restent souvent en suspens jusqu'au lendemain.
Les règles d'accès n'empêchent pas une fuite par une personne disposant d'un accès autorisé. Elles la rendent traçable et limitent l'étendue de ce qui peut être touché en une fois. Aucune de ces mesures ne règle la question de savoir qui détient contractuellement quels droits sur le code. Cela relève de l'appréciation du service juridique ou du cabinet d'avocats du client.
Accès et offboarding dans votre projet
Nous vous montrons volontiers, sur un projet concret, comment nous mettons en place les dépôts, les accès et l'offboarding pour une équipe nearshore.
Foire aux questions
Un accord de confidentialité suffit-il ?
C'est la base de la confidentialité. Il ne règle pas qui obtient quels droits sur le code, cela relève du contrat de développement. Au quotidien, il est de peu d'utilité contre un accès qui reste actif après le départ d'un développeur. Pour cela, il faut des règles d'accès et une procédure d'offboarding définie.
Où le code doit-il se trouver ?
Idéalement dans un dépôt appartenant au client, dans lequel l'équipe externe travaille avec ses propres comptes personnels. Le client voit alors à tout moment l'état actuel et peut retirer lui-même les accès. En fin de projet, rien n'a besoin d'être remis.
Quelles mesures techniques faut-il mettre en œuvre en premier lieu ?
D'abord les droits d'accès, ensuite la procédure d'offboarding. Les accès que personne ne retire sont la faille la plus fréquente dans un projet par ailleurs bien organisé. La gestion des secrets, les dépôts séparés et la journalisation suivent dès que ces deux points sont en place.
Pourquoi torck ?
torck travaille avec un seul cocontractant allemand, torck GmbH, et avec les mêmes règles d'accès sur les trois sites. Nous voyons ce que cela donne pour un projet concret lors d'un Premier entretien.
Cet article cite des lois et des règlements pour situer des décisions techniques. Il ne constitue pas un conseil juridique. Pour savoir si et comment une règle s'applique à votre entreprise, adressez-vous à votre service juridique ou à un cabinet d'avocats.
German 
English 
French