Diffuser un logiciel de laboratoire : recommandations juridiques et administratives

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 11/04/10
  • Correction mineure : 27/05/13

Diffuser un logiciel de laboratoire : recommandations juridiques et administratives

Cet article n'est pas un document officiel d'un organisme ou d'une autre entité. Il continue l'étude commencée avec les documents qui sont décrits dans : Documents de référence PLUME pour mieux gérer les développements logiciels, les diffuser et les valoriser dans un laboratoire Fiche Plume, en répondant aux questions :

  • Quelles sont les bonnes pratiques à suivre lorsqu'on prépare la diffusion d'un logiciel ?
  • Quelles sont les démarches à faire ?
  • Quels sont les documents importants à conserver (la traçabilité est une question essentielle !) ?
  • Quelles notions importantes du droit d'auteur s'appliquent ?

À la différence des documents cités, ce texte prend la perspective de l'auteur ou responsable d'un logiciel dans un laboratoire ou une institution de recherche.

L'auteur principal de cet article est Teresa Gomez-Diaz, chargée du référencement des développements de son laboratoire LIGM et responsable thématique PLUME, mais les procédures présentées ont été étudiées avec Pascal Janots, responsable du SAIC de l'UPEMLV (service de valorisation de la recherche de l'université Paris-Est Marne la Vallée). D'autres ont ensuite relu et complété : Jean-Luc Archimbaud (UREC), Geneviève Romier (UREC), Vincent Guhur (DAJ CNRS). Des versions de ce document ont été aussi relues par : M.-P. Béal, directrice du LIGM, Véronique Baudin, Pascal Dayre, Samuel Godey, Konrad Hinsen.

Ce texte a été motivé par l'étude d'un cas qui nous a été soumis, et qui est illustratif : regulièrement, des développements logiciels dans les laboratoires de recherche font surgir des problèmes analogues.

Cas d'étude

Un projet logiciel a abouti. Le projet a été dirigé par un professeur (laboratoire L1) et un maître de conférences (laboratoire L2) de l'Université G1. Un premier logiciel a été développé par un stagiaire, lors d'un stage gratifié (S1) de deux mois en 2008. Ce premier logiciel n'a pas été diffusé, mais il a été complètement repris par un nouvel étudiant lors d'un deuxième stage en 2009 gratifié par le CNRS (S2) : ce deuxième stage a donné lieu à un logiciel abouti. Le professeur prépare la diffusion du logiciel sous licence libre, une publication associée et sa présentation pour un prochain congrès. De nouvelles évolutions du logiciel sont prévues, avec l'intervention de nouveaux stagiaires.

Ma réponse

Ceci ne constitue pas une réponse officielle ; c'est mon opinion, sans aucun engagement de ma responsabilité ou celle des différents relecteurs de cette fiche.

Le logiciel du stage S1 ne peut pas être modifié sans l'accord explicite du premier stagiaire, pour le second stage, le stagiaire doit donc repartir à zéro (au niveau du code). Si l'on prévoit de diffuser le logiciel du stage S2, le mieux est de le faire sous une licence libre, avec l'accord (signé) de tous les intervenants au projet, ceci avant de lancer la soumission à publication ou la présentation au congrès. Cela simplifie les évolutions futures du logiciel, et en particulier tous les collaborateurs pourront le faire évoluer sans obstacle légal. L'Université G1 intervient dans la décision de licencier ce logiciel, même si on détecte souvent l'oubli de ce point. Je pense que les tutelles des laboratoires doivent définir leurs politiques sur les logiciels et fournir des procédures simples et adaptées pour permettre la diffusion rapide des logiciels sous licence libre.

Même si les responsables du projet n'ont pas écrit de code, ils ont proposé le projet et le code n'aurait pas pu s'écrire sans leur expérience et leur savoir-faire. C'est parfois difficile de décider quels sont les auteurs d'un logiciel. Etablir une liste d'auteurs, en leur assignant un pourcentage de participation, est la solution adoptée par d'autres projets (voir la présentation Développer en logiciel libre : Empaquetage et diffusion par exemple) : c'est une très bonne solution. Je n'ajouterais pas le premier stagiaire comme auteur du logiciel : ce sont des briques logicielles indépendantes, je recommanderais de simplement citer ce premier travail.

Deuxième cas d'étude

Lors de la rédaction de cette fiche, un autre cas nous a été posé, sur un projet logiciel proposé à des étudiants, ce type de projets étant nécessaire pour valider leur diplôme. Les étudiants n'ont pas le statut de stagiaires. La rédaction de la proposition explicite que le logiciel obtenu sera soumis à une licence libre.

Ma réponse

Dans ce cas il n'y a pas de convention de stage ni de contrat. Il me semble qu'un document signé qui établit l'accord des étudiants sur leur participation au développement d'un logiciel libre est indispensable. Ce document doit indiquer le nom du logiciel, décrire le projet, indiquer qui en est le responsable et quelle est la licence prévue ainsi que la liste des participants et la durée du projet. Ce document doit être daté et signé par tous les participants.

Procédure pour la diffusion d'un logiciel (résumé des paragraphes suivants, pour les lecteurs pressés)

Voici les principaux points de la procédure proposée qui sont explicités dans les paragraphes suivants (que nous vous conseillons de lire, même si vous êtes un lecteur pressé) :

(*) À revoir à chaque nouvelle version du logiciel.

Il est primordial d'établir une licence avant de diffuser un logiciel.

Il est important aussi d' informer la direction du laboratoire de cette diffusion. L'utilisation de sa fiche PLUME pour donner à la direction les informations sur le logiciel, nous semble un bon moyen :). Si une fiche est créée pour chaque nouveau logiciel du laboratoire, celui-ci pourra plus tard facilement accéder à toutes les fiches de logiciels développées et mettre un pointeur depuis son site Web vers cette liste (voir par exemple la liste de logiciels du LIGM).

À noter que toute cette liste de points s'applique aussi pour un développement diffusé avec une licence commerciale : il faut de même établir la liste des auteurs...

Droits d'auteur

Un logiciel est considéré comme une œuvre au sens du Code de la Propriété Intellectelle (CPI). D'après l'article L112-2 : "Sont considérés notamment comme œuvres de l'esprit au sens du présent code :

1° Les livres, brochures et autres écrits littéraires, artistiques et scientifiques ;
...
13° Les logiciels, y compris le matériel de conception préparatoire ;
..."

Toutefois, il est important de noter que seules les œuvres présentant un caractère original sont protégées par le droit d'auteur.

Puisque les logiciels ne connaissent pas les frontières, il est important de connaître que le cadre légal international est donné par la Convention de Berne pour la protection des œuvres littéraires et artistiques. Cette convention est gérée actuellement par l'Organisation mondiale de la propriété intellectuelle (OMPI).

Avant de pouvoir appliquer les règles établies par le CPI, il est essentiel de pouvoir répondre à tout moment à deux questions qui semblent innocentes :

  • qui est l'auteur ?
  • de quelle œuvre ?

L'œuvre

  • Il est nécessaire de nommer le logiciel. Le titre du logiciel bénéficie aussi de la protection par le droit d'auteur (s'il présente un caractère original). Il est important de choisir un nom qui ne porte pas atteinte aux droits des tiers (par exemple, il faut éviter de donner au logiciel un nom similaire à celui d'une marque désignant un autre logiciel). Afin de savoir si un nom est déposé en tant que marque vous pouvez consulter la Base de données des marques de l'Institut National de la Propriété Industrielle (INPI).
    Il est utile de choisir des noms faciles à prononcer (lbqavr-tsy n'est pas un bon nom de logiciel).
  • Il faut savoir qui en est le(s) propriétaire(s). Ce sont les détenteurs des droits patrimoniaux associés au logiciel. Selon la loi française, aucun propriétaire ne peut prendre l'initiative d'exploiter une œuvre sans l'autorisation explicite des autres propriétaires.
  • Le logiciel doit avoir un caractère original. Il faut rédiger un descriptif du logiciel avec : son contenu, ses foncionnalités, ses applications envisagées, en quoi est-il une nouvelle œuvre par rapport à l'existant (i.e. l'originalité apportée).
  • Il faut dater le logiciel. La protection par le droit d'auteur s'appliquant de plein droit du fait de la création de l'œuvre, il est nécessaire de pouvoir déterminer sa date de création. Plusieurs dates sont importantes : date du matériel préparatoire, date de diffusion, date de chaque version, dates des contrats et conventions liés au logiciel.
  • Il faut savoir localiser le logiciel (par une adresse ou un point de contact si l'œuvre n'est pas distribuée).
  • Il faut pouvoir citer le logiciel. Comme pour toute œuvre produite dans un laboratoire ou une institution de recherche, l'utilisation d'une référence est fondamental pour l'évaluation et la gestion du patrimoine scientifique (voir Préciser la genèse des documents diffusés).

Note : ni le lieu de développement (bureau, maison, avion...) ni l'heure (2 heures du matin) sont retenus comme des informations importantes dans la production d'une œuvre, en revanche il est tenu compte de ce que l'œuvre est en relation avec votre activité professionnelle.

La traçabilité du code

Face à un problème légal, il est essentiel de pouvoir tracer le code et de pouvoir apporter des preuves (sur les dates, le contenu, les auteurs, ...) Des organismes comme l'INRIA proposent d'effectuer des dépôts dans l'Agence de protection des programmes (APP) Fiche Plume pour renforcer cette traçabilité (entre autres objectifs), et cela à chaque version majeure ou à chaque départ d'un contributeur important.

Constituer un dossier de dépôt APP est un moment privilégié de communication entre les responsables d'un projet logiciel et les services de valorisation, et cette communication est nécessaire et doit se développer.

Il peut arriver néanmoins que les services de valorisation d'autres entités de recherche ne soient pas aussi bien établis que ceux de l'INRIA et que faire des dépôts APP peut s'avérer une tâche compliquée sans le soutien adéquat. Malgré cela, il peut être utile d'assurer la traçabilité du code en archivant le code d'un logiciel à chaque étape importante : nouvelle fonctionalité, arrivée ou départ d'un contributeur, modification du financement du code (contrats, ...) ; bref, à chaque évolution importante des données essentiels de l'oeuvre. Pour cela on peut par exemple garder des fichiers .tar.gz ou utiliser des forges.

Les auteurs

Il est parfois complexe de déterminer le ou les auteurs d'un logiciel notamment lorsqu'il s'agit d'un logiciel qui a été enrichi tout au long des années et des collaborations, cela peut demander l'intervention d'avocats dans des cas extrêmes (voir la page 28 du document Report on the proposed IPR tracking methodology, Deliverable A1.D2.1.4 du projet Quality Platform for Open Source Software (Qualipso) Fiche Plume). Voilà pourquoi il faut établir des documents qui clarifient la question. Il ne s'agit pas de prévoir toutes sortes de controverses possibles, mais de bien établir des documents qui peuvent s'avérer indispensables dans des utilisations imprévues et futures du logiciel.

Il faut donc établir une liste d'auteurs, avec le nom de leur laboratoire et leur statut (en particulier pour les stages, thèses, postdocs, ...). Il peut être utile d'associer à chaque auteur un pourcentage de collaboration (donc à ne pas oublier). Cette liste doit être revue à chaque version du logiciel, surtout s'il y a de nouveaux intervenants, ou un changement de responsable du projet logiciel.

L'auteur d'une œuvre est celui qui l'écrit, rien de plus clair... Cependant, un logiciel peut avoir plusieurs auteurs dans des cadres de collaboration très différents (stage, doctorat, collaboration avec des entreprises, ou entre plusieurs établissements de recherche). Le Code de la Propriété Intellectelle (CPI) définit dans son article L113-2 différentes catégories d'œuvres : œuvre de collaboration, œuvre collective, œuvre composite. Toutes ces catégories peuvent, suivant le cas, s'appliquer à un même logiciel.

Le concept d'œuvre de collaboration indique une collaboration "horizontale" : les collaborateurs participent au même niveau et sont tous considérés comme auteurs de l'œuvre (pourcentage égal de participation). L'œuvre collective correspond à une collaboration "verticale" : une seule personne sera auteure de l'œuvre. Dans le cas particulier des stages, le développement ne peut pas se faire sans l'expérience du responsable de stage : il y a à la fois une collaboration verticale et horizontale. Il est donc difficile d'utiliser une seule de ces catégories pour caractériser les logiciels quand des stages sont inclus.

La liste d'auteurs avec leur pourcentage de participation est ainsi un outil indispensable pour clarifier ce point.

Les droits patrimoniaux

L'article L113-9 du CPI stipule : "Sauf dispositions statutaires ou stipulations contraires, les droits patrimoniaux sur les logiciels et leur documentation créés par un ou plusieurs employés dans l'exercice de leurs fonctions ou d'après les instructions de leur employeur sont dévolus à l'employeur qui est seul habilité à les exercer."

Donc en cas de travail salarié, l'auteur d'un logiciel est différent du détenteur des droits patrimoniaux (qui est l'employeur). Cela ne s'applique pas dans le cas des stages car un stagiaire ne peut pas être assimilé à un salarié ou à un agent de l'Etat. Donc il est essentiel de connaître le statut des personnes ayant collaboré à la création du logiciel. La question "qui est propriétaire des droits patrimoniaux ?" est aussi complèxe que celle des auteurs et peut requérir la décision d'un juge.

Si le logiciel est lié a un contrat de collaboration, les droits patrimoniaux du logiciel produit peuvent y être attribués. Ces contrats peuvent aussi établir les licences qui lui seront associées. Les négociateurs du contrat doivent être attentifs sur ces deux points.

Concernant les autres contributeurs non salariés du laboratoire (bourses, stages non gratifiés, thèses sans rémunération... ) il est indispensable de leur faire signer un engagement comportant des clauses sur la propriété intellectuelle et des règles de confidentialité à respecter.

Finalement, la liste des détenteurs des droits patrimoniaux découle directement de la liste d'auteurs et de leur statut, d'où l'importance de bien établir cette première liste.

Note : la liste de détenteurs des droits patrimoniaux s'indique dans le code source du logiciel (ligne de copyright, voir la FAQ PLUME Licence & copyright pour les développements de logiciels libres de laboratoires de recherche Fiche Plume).

La documentation d'un logiciel et les droits patrimoniaux

On peut parfois considérer que la documentation d'un logiciel est soumise aux normes classiques de la propriété intellectuelle, or le CPI stipule que les règles des droits patrimoniaux s'appliquent aux logiciels et leurs documentations. En conséquence, toute décision qui fait intervenir ces droits patrimoniaux (licence, diffusion...) correspond aux détenteurs de ces droits.

La cession des droits

Le Code de la Propriété Intellectuelle traite dans son chapitre III de la cession des droits d'auteur, aussi appellée parfois cession des droits patrimoniaux. Il est impossible de céder les droits moraux, qui restent toujours associés aux auteurs d'une œuvre.

Récemment nous avons vu le cas d'une demande de cession des droits (disclaimer of rights) faite par la FSF (Free Software Fondation) à une Université, dans le cadre d'un stage d'un étudiant de l'Université dans un autre établissement pour faire évoluer le logiciel GCC.

Le logiciel GCC possède une longue liste d'auteurs, et donc il peut être très compliqué de contacter tous les propriétaires du logiciel face à un problème légal. La FSF pourra faire face au problème et représenter les intérêts de la communauté des développeurs si les cessions de droits sont faites. Voir How to contribute à GCC, GDB, Binutils et autres.

Le personnel d'un laboratoire de recherche

Dans cette section nous parcourons la liste des différents types de personnel d'un laboratoire et leur régime (salarié ou pas), ce qui déterminera les droits patrimoniaux associés à leur participation au développement d'un logiciel.

Note : pour les unités mixtes de recherche (UMR), le concept d'établissement hébergeur peut s'appliquer avec des conséquences importantes. Ce point s'étudie lors de la signature des contrats quadriennaux.

Régime salarié. L'auteur a la qualité d'employé ou d'agent de l'Etat, des collectivités publiques ou des établissements publics à caractère administratif. L'université ou l'établissement employeur est le détenteur des droits patrimoniaux associés à l'œuvre. Cette règle s'applique si l'auteur est :

  • chercheur (chargé de recherche, directeur de recherche),
  • enseignant-chercheur (maître de conférences et professeur des universités),
  • enseignant-chercheur associé (maître de conférences et professeur des universités associé ou invité),
  • ingénieur, assistant ingénieur, technicien,
  • un chercheur en accueil en délégation (CNRS, INRIA...),
  • un doctorant allocataire de recherche.

Même s'il s'agit des postes non-permanents, le régime salarié peut s'appliquer aussi pour les postes suivants :

  • post-doctorants,
  • attachés temporaires d'enseignement et de recherche (ATER),
  • doctorants : contrat doctoral, bourses CIFRE,
  • CDD.

Pour les doctorants et post-doctorants la source du financement est promordiale et il faut veiller à la signature de documents qui comportent des clauses sur la propriété intellectuelle et la confidentialité.

Lors des congés pour recherches ou conversions thématiques (CRCT), l'employeur ne change pas. Lors de la mise à disposition, du détachement, de disponibilité d'un agent, il faut étudier le cas d'un changement de régime (salarié/non-salarié) et le changement d'employeur (pour tenir en compte le détenteur des droits patrimoniaux associé à cette période).

L'auteur n'a pas la qualité d'employé. Dans ce cas, l'auteur est aussi le détenteur des droits patrimoniaux (en fonction du pourcentage de participation au projet logiciel). Cette règle s'applique si l'auteur a la qualité de :

  • professeur émérite, retraité,
  • boursier,
  • stagiaire (voir la Circulaire du 23 juillet 2009 relative à l'accueil des étudiants de l'enseignement supérieur en stage),
  • étudiant participant sur des projets sans le statut de stagiaire.

Ce dernier statut ne correspond pas, bien entendu, à des personnels du laboratoire, mais il apparaît souvent lié aux activités d'enseignement du personnel du laboratoire. L'étudiant pourrait, par exemple, être sous contrat d'apprentissage, ce qui est une forme de contrat de travail. L'étudiant peut suivre d'autre type de formation en alternance, selon des cadres juridiques différents tels que contrat de travail (entre entreprise et salarié), convention de stage (entreprise-stagiaire-université ou centre de formation), convention CIFRE (montage pluri-contractuel entreprise-salarié-université-ANRT), ou convention de formation continue (entreprise-université).

Le statut de retraité ne correspond pas non plus à des personnels d'un laboratoire, mais il arrive parfois que des personnes à la retraite continuent à s'impliquer dans des projets (logiciels) commencés lors d'un travail salarié.

En l'absence de dispositions prévues par convention signés par ces personnes (stage, d'accueil, cession de droit, ...), elles conservent les droits de propriété des logiciels auxquels elles ont participé (selon leur pourcentage de participation). Pour obtenir plus d'information sur les clauses des conventions nécessaires, on peut s'adresser aux services de ressources humaines ou aux services des affaires juridiques de vos établissements.

Vous l'aurez compris, ce sont des cas un peu hétéroclites qui posent des questions délicates. Il faut les traiter avec prudence, les conséquences légales pouvant s'avérer importantes.

La mobilité des personnels

La mobilité des personnels qui ont collaboré à un projet logiciel peut devenir un casse-tête lorsqu'il est nécessaire de contacter tous les acteurs intervenant aux décisions importantes dans son évolution. Bien que cela puisse sembler rare, cela arrive assez souvent et il vaut mieux en prévoir les conséquences.

Une possible solution est d'ajouter, dans le document d'accord de licence une adresse de contact pour chaque auteur et une clause qui indique l'engagement des parties à donner une nouvelle adresse de contact lorsque celle qui figure sur le texte ne fonctionne plus.

Lorsque les responsables d'un projet logiciel changent de laboratoire, il nous semble qu'une copie du dossier du logiciel doit rester au laboratoire. Pour la gestion de ces dossiers, la figure de correspondant logiciels du laboratoire est une solution à étudier.

Choisir une licence

Pour plus d'informations concernant les licences libres nous vous invitons à consulter la FAQ PLUME Licence & copyright pour les développements de logiciels libres de laboratoires de recherche Fiche Plume et la fiche PLUME Pourquoi diffuser un logiciel développé dans un laboratoire ou une université avec une licence libre ? Fiche Plume qui étudie les avantages des logiciels libres dans le monde scientifique. Ces deux documents vous seront peut-être utiles pour étudier la question du choix de licence.

Si le logiciel est lié à un contrat de collaboration, la licence sous laquelle le logiciel obtenu sera distribué peut y être indiquée et fait partie des négociations habituelles à la rédaction du contrat. Il peut y avoir des contrats différents qui financent un projet, il faut y indiquer quelles sont les parties du logiciel ou les fonctionnalités qui sont attachées au contrat et veiller à la "compatibilité" des contrats (ou des licences associées).

Si le logiciel est une œuvre dérivée d'un logiciel sous licence GPL, sa diffusion doit se faire en respectant cette licence : le logiciel dérivé sera diffusé en code source et sous licence GPL. Rien n'empêche l'utilisation simultanée de plusieurs licences qui seront peut-être utiles selon le cadre de collaboration mais cela n'est pas possible pour tous les types de licences des briques initiales.

Dans les autres cas, la licence doit être décidée avec les détenteurs des droits patrimoniaux. Pour les licences libres, les tutelles peuvent établir des procédures qui donnent un accord au préalable et simplifient la diffusion rapide des logiciels produits dans les laboratoires de recherche sous ce type de licence.

Il est utile d'établir un accord de licence daté et signé par tous les auteurs : << Les auteurs du logiciel X et signataires de ce document manifestent leur accord pour diffuser le logiciel (nom, description) sous la licence...>>

Respecter une licence

Si vous avez utilisé des briques logicielles dans votre logiciel, cela veut dire que vous connaissez quels sont les droits associés à ces briques (ie. que vous connaissez leurs licences) et quelles sont les obligations qui vous sont imposées (et que vous avez acceptées).

Il y a des licences qui indiquent qu'un logiciel est de libre utilisation pour la recherche mais pas pour des utilisations commerciales, d'autres indiquent qu'il faut citer un ouvrage lié au logiciel... Ces obligations doivent être respectées.

Les documentations des logiciels sont aussi soumises à des licences, qui à leur tour imposent des obligations à respecter.

Documents pour établir un dossier du logiciel

Voici donc la liste des documents à rassembler lors du développement d'un logiciel :

  • Matériel préparatoire : notes, articles... Il sert à dater le logiciel.
  • Document de description, avec nom, dates importantes, liste d'auteurs (avec pourcentage de participation) et leur affiliation.
  • Liste des briques logicielles avec leur licence (ou documents qui accordent des droits d'utilisation, de rediffusion, ...).
  • Document d'accord de licence avec liste d'auteurs, leur adresse de contact, leur signature...
  • Contrats
  • Conventions de stage, conventions d'accueil...

Ces documents sont à revoir à chaque nouvelle version du logiciel.

Les divers types de collaboration au développement d'un logiciel

La fiche PLUME Guide laboratoire pour recenser ses développements logiciels Fiche Plume étudie la question du recensement des logiciels produits dans les laboratoires de recherche.

La procédure proposée dans ce document étudie les logiciels qui sont développés complétement dans le cadre d'un ou plusieurs laboratoires de recherche, mais il arrive souvent que des chercheurs et des développeurs d'un laboratoire s'impliquent dans des projets logiciels libres et parfois externes aux établissements de recherche français. Dans ce cas, et en fonction de l'importance de la contribution, il est conseillé d'informer le laboratoire de cette contribution et de mentionner dans votre collaboration le détenteur des droits patrimoniaux de votre travail.

Comment gérer les collaborations de chercheurs de plusieurs laboratoires, y compris à l'étranger ? À notre avis, cette question doit se traiter de façon similaire à celle des publications du laboratoire, en faisant attention "à la signature" du logiciel : auteur (avec pourcentage de participation) et détenteur des droits patrimoniaux.

Références

Commentaires

Texte avec une auteur

Ce texte a une auteur : Térésa Gomez-Diaz ingénieure en informatique dans un laboratoire de recherche, chargée du référencement de logiciels. Elle a étudié ces questions depuis plusieurs années et a maintenant de l'expérience dans le traitement de cas concrets de questionnement lors de la diffusion de développements dans les laboratoires. Elle est l'expert 'patrimoine logiciel d'un laboratoire' dans PLUME.

Ce document donne donc son avis, ses réponses. Demander l'avis d'une personne experte 'du terrain' est aujourd'hui la seule manière pour émettre des recommandations. Les cas de diffusion de logiciels sont très divers, dans une organisation complexe de la recherche (multi-tutelles...), sans jurisprudence ; les services officiels (juridiques, de valorisation) de nos tutelles ne peuvent pas diffuser rapidement l'équivalent. Or la demande des développeurs est forte et en leurs donnant quelques recommandations (liste des auteurs, information de la direction...) qu'il est assez simple de suivre on peut éviter beaucoup de travail ou de problèmes a posteriori. Retrouver des stagiaires qui ont travaillé sur un logiciel 5 ans après leur passage dans un laboratoire par exemple n'est pas toujours simple.

Mais ce document a été relu par des acteurs divers : direction de laboratoire, services juridiques, de valorisation, ce qui en valide le contenu.

Jean-Luc Archimbaud
Directeur du projet PLUME