Ces cas dépassent largement le cadre de l’hypothèse classique du » prestataire qui réalise un logiciel conforme à un cahier des charges établi ensemble ». En réalité, on retrouve aussi ce cas dans certaines relations de partenariat entre prestataires de services. Le partenariat est d’ailleurs peut-être plus révélateur de la véritable relation qui unit les parties.Plus concrètement, il s’agit souvent pour l’une des parties de transmettre à l’autre qui est un développeur, un savoir, des connaissances ou des données. A charge alors pour le plus technicien des deux de mettre en formes ces éléments afin de constituer une application, que l’on appellera logiciel métier, serious game, logiciel expert, logiciel d’audit, logiciel de simulation ou autre … Autant de noms qui désignent en fait des applications qui ne font que matérialiser et modéliser le savoir faire d’un sachant ou d’une entreprise.
Cette transmutation qui peut sembler sans doute anodine, recèle quelques surprises juridiques sur deux points principaux. Le premier point concerne la détermination de la propriété du logiciel. Plus exactement, la question est de déterminer si la partie qui fournit le savoir faire a accès au droit d’auteur à l’instar du développeur. En effet, rien n’est moins certain puisque notre pauvre spécialiste ne donne a priori que du contenu qui est mis en forme par le prestataire sur la seule tête duquel va naître le droit d’auteur. Attention néanmoins à ne pas tomber dans la caricature car certaines formes de collaboration vont certainement ouvrir droit au statut d’auteur à notre spécialiste. De là à dire que l’œuvre ainsi constituée est co-développée, il n’y a qu’un pas que nous ne franchiront pas. A tout le moins la structure de l’œuvre (et non celle de son code source) aura été co-réfléchie. Enfin il conviendra certainement de différencier les cas où le logiciel est au final la seule matérialisation du savoir faire, des autres cas où le contenu aura été mis en forme par d’autres moyens (ouvrages, formations, etc.)
Deuxième point critique, celui de la responsabilité vis-à-vis de la fiabilité, ce dernier ne concernant que les logiciels dont l’usage ou la fiabilité des fonctions peuvent s’avérer critique. Ce sera particulièrement le logiciel d’aide au diagnostic ou l’ensemble des logiciels d’aide à la décision mais aussi les serious games. En cas de fonctionnement erroné aboutissant à un préjudice pour l’utilisateur ou un tiers, la question pourra se poser de qui du développeur ou de l’expert est à blâmer. Seule une analyse poussée du dysfonctionnement de l’application semble alors pouvoir en révéler la nature :
- Soit un problème relevant des données intégrées => responsabilité du spécialiste.
- Soit un problème relevant d’une pure erreur de programmation (bug) => responsabilité du développeur.
- Soit un problème relevant de la conception globale de l’application => responsabilité du développeur ou partagée avec le spécialiste.
Face à ce type de partenariat, seul le contrat peut déterminer à l’avance la répartition des droits et des responsabilités de chacun. A bon entendeur…
Gérald SADDE
