5 mars 2010

Contentieux informatique Les logiciels libres Le recours aux logiciels libres dans le secteur public L’introduction du logiciel libre dans les services publics qu’ils soient gérés par les administrations centrales ou les collectivités territoriales est vivement encouragée. L’acquisition de logiciels libres peut être gratuite (cad ne pas relever du Code des marchés publics) ou payante et nécessiter dans le cas de montants financiers significatifs, le recours aux procédures d’achat décrites par le Code des marchés publics. Les derniers freins que pouvaient constituer le foisonnement des licences existantes et leur rédaction quasi systématique en langue anglaise ont été levé par la publication par le CEA (Commissariat à l’Energie Atomique), le CNRS (Centre National de la Recherche Scientifique) et l’INRIA (Institut National de Recherche en Informatique et en Automatique) d’une licence suivant le modèle du logiciel libre rédigée en français et conforme au droit français de la propriété intellectuelle : la licence CeCILL (1). Par ailleurs, pour renforcer l’usage et la production de composants logiciels diffusés sous licence libre, l’Agence pour le développement de l’administration électronique (Adae) vient de lancer un appel à commentaires pour actualiser le guide de référence qu’elle a élaboré en décembre 2002. La licence « CeCILL » est la première licence qui définit les principes d’utilisation des logiciels libres en conformité avec le droit français. Son usage par les administrations de l’État, les établissements publics de l’État et les collectivités locales permettra de diffuser les résultats sous licence de logiciel libre, en toute sécurité juridique, tout en conservant au mieux l’esprit des licences de source américaine comme la GNU GPL (licence publique générale). Elle peut servir de référence aux collectivités qui souhaitent utiliser et diffuser des logiciels libres, sous réserve bien entendu que les producteurs de logiciels acceptent de les mettre sous le régime de cette licence. Elle intègre les mentions obligatoires imposées par l’article L.131-3 du Code de propriété intellectuelle ainsi que des clauses limitatives de garantie et de responsabilité valides. (1) Acronyme pour Ce(A)C(nrs)I(NRIA)L(ogiciel)L(ibre). Paru dans la JTIT n°39/2005 p.2 (Mise en ligne Avril 2005)

Contentieux informatique Les logiciels libres La licence d’utilisation de logiciels libres Assurer une maîtrise des coûts et son indépendance à l’égard des éditeurs, telles sont les principales motivations du recours au logiciel libre. Pour autant, il faut prendre certaines précautions, tant sur le plan du droit d’auteur, que sur celui de l’organisation du projet. Tout d’abord, le logiciel libre demeure soumis au Code de la propriété intellectuelle ; ainsi « tout ce qui n’est pas autorisé est interdit ». L’examen attentif de la licence s’impose afin d’identifier le dispositif contractuel de type « copyleft » (sans restriction) ou « non copyleft » (avec restriction) et de déterminer les contraintes d’exploitation et la conformité du contrat aux libertés fondamentales des licences de type GPL ou compatibles : liberté d’exécuter le programme, liberté d’étudier et d’adapter, liberté de redistribuer et liberté d’améliorer. Libre et gratuit ne sont pas forcément synonymes, dès lors qu’il est parfois nécessaire d’avoir recours à des éditions de type « distribution », pour certaines applications, qui peuvent alors être payantes. Les sociétés de services en logiciels libres (SS2L) se multiplient et présentent la particularité d’avoir à gérer le double objectif du client : obtenir d’une part, des garanties nécessaires, notamment en terme de pérennité, pour assurer la bonne fin du projet et inscrire les investissements concernés dans la durée et disposer d’autre part d’une indépendance technique, au terme d’une période d’appropriation. Ce sont ces particularités que les contrats de réalisation et d’intégration de logiciel doivent respecter, en mettant en place des processus de réception des prestations, incluant le transfert des connaissances associées, gage d’autonomie ultérieure au plan technique et un dispositif d’assistance technique sur une certaine durée, pouvant aller jusqu’à la tierce maintenance applicative, la SS2L étant alors chargée de l’interface avec la communauté des développeurs. C’est la capacité à conjuguer ces engagements particuliers qui forme la spécificité des contrats de réalisation de solution basée sur du libre. Paru dans la JTIT n°40/2005 p.1 (Mise en ligne Mai 2005)

Contentieux informatique Les logiciels libres Construire son projet sur du « libre » Assurer une maîtrise des coûts et son indépendance à l’égard des éditeurs, telles sont les principales motivations du recours au logiciel libre. Pour autant, il faut prendre certaines précautions, tant sur le plan du droit d’auteur, que sur celui de l’organisation du projet. Tout d’abord, le logiciel libre demeure soumis au Code de la propriété intellectuelle ; ainsi « tout ce qui n’est pas autorisé est interdit ». L’examen attentif de la licence s’impose afin d’identifier le dispositif contractuel de type « copyleft » (sans restriction) ou « non copyleft » (avec restriction) et de déterminer les contraintes d’exploitation et la conformité du contrat aux libertés fondamentales des licences de type GPL ou compatibles : liberté d’exécuter le programme, liberté d’étudier et d’adapter, liberté de redistribuer et liberté d’améliorer. Libre et gratuit ne sont pas forcément synonymes, dès lors qu’il est parfois nécessaire d’avoir recours à des éditions de type « distribution », pour certaines applications, qui peuvent alors être payantes. Les sociétés de services en logiciels libres (SS2L) se multiplient et présentent la particularité d’avoir à gérer le double objectif du client : obtenir d’une part, des garanties nécessaires, notamment en terme de pérennité, pour assurer la bonne fin du projet et inscrire les investissements concernés dans la durée et disposer d’autre part d’une indépendance technique, au terme d’une période d’appropriation. Ce sont ces particularités que les contrats de réalisation et d’intégration de logiciel doivent respecter, en mettant en place des processus de réception des prestations, incluant le transfert des connaissances associées, gage d’autonomie ultérieure au plan technique et un dispositif d’assistance technique sur une certaine durée, pouvant aller jusqu’à la tierce maintenance applicative, la SS2L étant alors chargée de l’interface avec la communauté des développeurs. C’est la capacité à conjuguer ces engagements particuliers qui forme la spécificité des contrats de réalisation de solution basée sur du libre. l’interview d’Alexandre Zapolsky, LINAGORA Paru dans la JTIT n°40/2005 p.1 (Mise en ligne Mai 2005)

Contentieux informatique Les logiciels libres Logiciels libres : quelques bonnes pratiques à respecter Les composants « libres » sont de plus en plus attractifs et les éditeurs de logiciels peuvent être tentés d’en utiliser pour concevoir des produits qui eux seront « propriétaires ». Mais attention à respecter certaines règles… (Lire l’article paru dans CXP – l’Oeil expert) (Mise en ligne Juillet 2005)

Contentieux informatique Les logiciels libres Intégrer des logiciels libres : vérifier l’adéquation des licences de composants ! Les logiciels libres ne sont pas juridiquement homogènes mais présentent des caractéristiques communes. Toutefois, ces dernières ne suffisent pas à garantir aux utilisateurs une liberté d’exploitation absolue. Rappelons que sont qualifiés de libres des logiciels dont les droits patrimoniaux sont volontairement libérés par les titulaires des droits tant au titre de la reproduction (liberté d’utilisation), de leur représentation (liberté de distribution) que de leur transformation (liberté de maintenance). Les « libertés fondamentales » devant être associées aux logiciels libres ont été théorisées et listées par la Free software foundation qui énonce que ne peuvent être qualifiés de libres que des logiciels dont l’exploitation est soumise aux quatre libertés suivantes : liberté d’exécuter les programmes pour tous les usages, liberté d’étudier le fonctionnement des programmes et de l’adapter aux besoins, liberté de redistribuer des copies donc d’aider son voisin, liberté d’améliorer le programme et de diffuser les améliorations pour le bien de tous. En plus de ce socle commun, il existe une cinquième liberté fondamentale, celle d’associer aux productions des conditions d’exploitation diverses et variées. Ce sont ainsi plusieurs dizaines de licences de logiciels plus ou moins libres qui coexistent (GPL, LGPL, BSD…) (1). Devant la diversité des licences, il s’agit de déterminer quelles sont leurs compatibilités par rapport à la destination des composants libres auxquels elles sont associées. L’étude d’adéquation des licences doit être réalisée en amont de l’intégration des premiers composants libres mais également pendant tout le cycle de vie du produit ou du système dans lequel ces composants sont intégrés. Une politique de qualification des licences libres acceptables doit ensuite être mise en œuvre en établissant la liste de licences de logiciels libres compatibles avec les besoins et finalités de l’entreprise (distributeurs, SSII, intégrateurs …). Il est également nécessaire de prévoir une procédure de sauvegarde de ces licences en mettant en place à l’intention des acteurs, une procédure de déclaration d’intention d’utiliser un composant libre. Une base de données correspondante à un inventaire des composants libres utilisés dans l’entreprise et les licences qui leur sont associées pourra alors être créée et mise à jour. Elle permettra d’assurer la traçabilité de leur utilisation en terme d’interfaçage et de compatibilité entre eux et/ou avec des logiciels propriétaires. (1) Cf. JTIT n° 58/2006 p. 2. Paru dans la JTIT n°64/2007 p.2 (Mise en ligne Mai 2007)

Contentieux informatique Les logiciels libres Première décision en matière de licence de logiciels libres Le Tribunal de grande instance de Paris a rendu la première décision en matière de licence de logiciels libres, le 28 mars 2007. Il s’agit d’une décision importante pour ceux qui souhaitent développer des logiciels s’appuyant sur des applications sous licence libre. Il a décidé que la conclusion d’une licence spéciale avec le détenteur des droits sur le logiciel sous licence GNU était nécessaire quand un programme développé ne pouvait être identifié comme raisonnablement indépendant et devait être considéré comme dérivé du programme libre. Le lien de dépendance, dans le cas examiné par le Tribunal, n’est pas constitué par une inbrication des deux programmes ou par une modification du programme libre mais par le développement de couches autonomes. Dans le cas d’espèce, la couche de bas niveau relevait de la licence GNU. Une couche intermédiaire permettait la communication entre la couche de bas niveau et l’application développée. En conséquence de quoi l’application nouvelle ne pouvait pas fonctionner sans l’application sous licence GNU ou sans des développements complémentaires qui s’y substitueraient. Le Tribunal a également indiqué dans cette même décision que l’information quant au rôle d’une partie du programme sous licence GNU est de nature substantielle. Il convient d’en déduire que l’absence de cette information au moment de la négociation et de la signature d’un contrat de cession de l’application pourrait être qualifiée de dolosive. Cette décision doit alerter les professionnels quant à l’importance de l’audit des codes sources qui constitue une phase nécessaire avant la signature d’un contrat de cession de droit sur des programmes. Elle doit rappeler aux éditeurs de logiciels que pour limiter les accusations de contrefaçon, il convient de développer les programmes en conservant l’ensemble des traces assurant le suivi et la preuve des modalités de leur réalisation ainsi que le détail des interactions nécessaires avec d’autres applications, et ce quand bien même ces applications seraient sous licence libre. TGI Paris, 3e ch, 1re sect., 28 mars 2007, Educaffix c. Cnrs, Université Joseph Fourier et autres (Mise en ligne Avril 2007)

Contentieux informatique Les logiciels libres Guide pratique d’usage des logiciels libres dans les administrations En décembre dernier, est paru un guide intitulé « Guide pratique d’usage des logiciels libres dans les administrations » publié par la direction générale de la modernisation de l’Etat (DGME) et rédigé par Thierry Aimé. La qualité technique de certains composants libres, les avantages procurés par la disponibilité du code source et les avantages économiques poussent de plus en plus d’administrations à utiliser des logiciels libres. Toutefois, des difficultés de compréhension, notamment dans le cadre du développement ou de l’utilisation de ces derniers peuvent constituer un frein à leur développement. L’objet du guide est d’éclairer les utilisateurs et les aider dans leur démarche. Ce guide présente sous forme de questions-réponses, les concepts de bases (définition et régime juridique du logiciel; différence entre logiciel libre et logiciel propriétaire), des questions pratiques (où trouver des logiciels libres ?; comment vérifier si la licence d’un logiciel est libre ?; comment utiliser et redistribuer un logiciel libre ?), des questions juridiques propres aux administrations ( logiciels libres et appel d’offres, l’exigence de composants libres dans son CCTP, la compatibilité entre les différentes licences de logiciels libre). Sur les questions juridiques, les auteurs du guide attirent l’attention notamment sur : les clauses intitulées « Propriété intellectuelle » figurant dans les Cahiers des clauses administratives générales (notamment le CCAG Prestations intellectuelles : CCAGPI) des marchés publics. En effet, ces clauses traitent de l’utilisation des « résultats » du marché, et offrent trois options, dont l’une par défaut. qui ne sont pas conformes aux prescriptions du Code de la propriété intellectuelle, ce qui les rend notamment inaptes à transférer efficacement des droits d’auteur, et pourrait empêcher l’administration de mutualiser son investissement avec d’autres administrations, au moyen d’une licence libre. C’est pourquoi il est recommandé de ne pas se contenter des clauses du CCAGPI auxquelles il peut tout de même être fait référence comme document contractuel de rang inférieur. Mieux vaut ajouter, même dans les conventions soumises aux marchés publics, une annexe relative à la propriété intellectuelle respectant les exigences formalistes prévues par l’article L 131-3 du Code de la propriété intellectuelle ; la possibilité d’exiger des composants libres dans son CCTP tout en respectant des principes de la commande publique et du code des marchés publics et de la concurrence, à cet égard, le guide donne un exemple de besoins pouvant figurer dans le CCTP ; le choix de la licence de logiciel libre pour diffuser une application : l’une des difficultés résulte du foisonnement des licences existantes et du fait qu’elles soient quasi systématiquement rédigées en langue anglaise. Aussi, le guide recommande la licence CeCILL V2 pour son adéquation avec le droit français. Il convient de rappeler que cette licence, publiée par le CEA et l’INRA suivant le modèle du logiciel libre, est conforme au droit français de la propriété intellectuelle et comble les lacunes des licences de source américaine, en ce qu’elle intègre les mentions obligatoires imposées par l’article L.131-3 du Code de la propriété intellectuelle, ainsi que des clauses de garantie et de responsabilité valides ; question, le guide propose une grille de lecture sur la compatibilité des licences libres, sachant que le principe dans ce domaine et que la licence du logiciel ne peut conférer plus de droits et moins d’obligations que les licences de chacun des composants. Guide pratique d’usage des logiciels libres dans les administrations (Mise en ligne Juin 2008)

Contentieux informatique La gouvernance des systèmes d’information (SI) Les implications de la SOX sur les SI C’est pour répondre aux scandales Enron et Worldcom que le Congrès américain a voté en juillet 2002, la loi Sarbanes-Oxley (SOX) qui modifie les règles de gouvernance des sociétés cotées aux Etats-Unis. La SOX oblige ces sociétés à mettre en place un contrôle interne efficace concernant la gestion de leurs données financières et à déposer un rapport auprès de la SEC (Commission américaine des opérations de bourse). Les exigences de la SOX et ses implications s’étendent à toute société française qui serait cotée aux Etats-Unis et à toute filiale française d’une société américaine cotée aux Etats-Unis. Ces dispositions obligent les sociétés à appliquer des règles strictes de gouvernance sur leurs systèmes d’information (SI). L’entreprise et notamment le directeur des systèmes d’information (DSI), dispose d’un modèle de référence en matière d’audit et de maîtrise des systèmes d’information, la norme CobiT (Control Objectives for Business and related Technology) qui s’inscrit dans la lignée des nouvelles pratiques de la gouvernance informatique. Ces « bonnes pratiques », sont proposées par l’IT Governance Institute, pour mieux gérer les risques liés à l’informatique en tenant compte notamment des contraintes liées à la mise en œuvre des dispositions de la SOX. Le DSI joue un rôle fondamental dans ce processus de mise en conformité du SI. C’est lui qui doit en garantir la sécurité et les contrôles lesquels peuvent porter notamment sur la gestion électronique et l’archivage des documents ou des courriers électroniques, l’amélioration des systèmes financiers et la conduite du changement ou encore la sécurité des bases de données et des réseaux. Ces règles peuvent conduire à exiger des prestataires qu’ils respectent les processus de production de SI définis par les « bonnes pratiques » communes, de manière à optimiser la sécurité et la conformité. (Mise en ligne Février 2006)

Contentieux informatique La gouvernance des systèmes d’information (SI) Renforcer sa politique de sécurité : une préocupation constante de l’entreprise Les moyens informatiques et les réseaux de télécoms sont devenus des outils de travail indispensables à l’activité quotidienne des entreprises.Or, l’utilisation de systèmes d’information et de communication de plus en plus ouverts avec l’extérieur rend indispensable la mise en œuvre d’une politique de sécurité visant à protéger de risques variés. Face aux nombreuses menaces et compte tenu des obligations imposées notamment par l’article 35 de la loi Informatique et Libertés (1) applicables à la protection des systèmes et des données nominatives, les entreprises doivent définir des politiques globales de sécurité. Les moyens techniques même s’ils sont indispensables ne sont pas suffisants et doivent s’accompagner d’une politique d’information et de sensibilisation des utilisateurs pour éviter que ceux-ci, par un comportement inapproprié, ne compromettent la sécurité de l’entreprise.Ceci explique le succès grandissant des chartes depuis quelques années dont la généralisation répond à ces préoccupations. En complément de la charte il apparaît nécessaire de définir des procédures pour la recherche et la conservation de la preuve en cas d’utilisation déviante des systèmes d’information et de télécoms ou encore d’agissement frauduleux avérés. Ces procédures doivent permettre de concilier efficacité et fiabilité des constats pour que ceux-ci soient juridiquement recevables et probants dans le respect des dispositions édictées par le Code du travail et par la loi Informatique et Libertés qui consacrent des exigences de proportionnalité, de transparence et de loyauté. Leur mise en œuvre nécessite par conséquent une bonne connaissance des textes applicables et des jurisprudences rendues en ces matières. Par ailleurs, il ne faudra pas oublier la gestion assurantielle des risques liés à la sécurité résultant notamment de la perte de chiffre d’affaires induite par des actes frauduleux ou encore les coûts engendrés par la reconstitution des données qui seraient altérées ou perdues. (1)Loi du 06/01/1978 modifiée par la loi du 06/08/2004. Paru dans la JTIT n°50/2006 p.2 (Mise en ligne Mars 2006)

Contentieux informatique La gouvernance des systèmes d’information (SI) Gérer la convergence des systèmes d’information Il est extrêmement fréquent, voir courant, en cas de fusion ou de rachat de sociétés, ou même tout simplement en cas d’acquisition de nouveaux sites, que les différentes entités qui se regroupent disposent de systèmes informatiques différents. La forte augmentation des ERP ou des systèmes intégrés au sein des entreprises, rend indispensable pour les entreprises qui se rassemblent la disposition d’un seul et même système d’information pour l’ensemble du groupe. Elles doivent en effet, pouvoir obtenir des remontées d’informations homogènes de l’ensemble des sociétés du groupe et disposer de données uniques et conjointes. Faire converger les SI de plusieurs entreprises constitue un véritable projet informatique. Sa mise en oeuvre peut en effet, se révéler extrêmement délicate : ce n’est pas parce qu’un système a été éprouvé au sein d’une entreprise que la migration s’effectuera facilement au sein d’une entreprise nouvellement acquise. Il s’agit pour cette dernière d’un véritable projet de changement de SI. La réalisation d’un tel projet n’est pas limitée au choix du SI qui sera privilégié, même si cela constitue un préalable à la convergence des systèmes. Encore faut-il en examiner les modalités. Toutes les étapes nécessaires à l’implémentation d’une nouvelle solution devront également être respectées, depuis la vérification des besoins jusqu’à la conduite du changement. Cette convergence peut également avoir pour effet de remettre en cause les processus et implémentations d’ores et déjà réalisées dans l’entreprise dont le système d’information a été privilégié. Lorsqu’il y a plusieurs sites, différentes démarches peuvent être adoptées : déploiement du système déjà éprouvé sur l’ensemble des autres sites et identification des écarts ; réalisation d’un site pilote sur l’un des sites, avant déploiement du système… toutes ces solutions nécessitent de : vérifier les contrats existants sur chacun des autres sites et effectuer les due diligences (licences, maintenance, propriété, CNIL, assurance, sécurité…) ; souscrire un nouveau contrat avec l’intégrateur prestataire et/ou l’éditeur qui sera chargé d’effectuer cette convergence, l’enjeu étant considérable ; gérer l’impact sur le plan social : modification des conditions de travail nécessitant une interventions des IRP, redéploiement des ressources humaines… effectuer un audit de mise en conformité avec la loi informatique et libertés. Paru dans la JTIT n°53/2006 p.4 (Mise en ligne Juin 2006)

Contentieux informatique DRM La protection du logiciel au coeur de l’architecture DRM La protection accordée au dispositif technique de verrou et de traçage d’une oeuvre, notamment par le biais du projet de loi DADVSI, est-elle efficace et nécessaire au regard des autres modes de protection des logiciels ? (Lire la suite…) (Mise en ligne Juillet 2006)

Contentieux informatique DRM Installation de l’Autorité de régulation des mesures techniques (ARMT) L’Autorité de Régulation des Mesures Techniques (ARMT) instaurée par la loi n°2006-961 du 1er août 2006 relative aux droits d’auteurs et aux droits voisins dans la société de l’information (loi DADVSI) voit enfin le jour. C’est ce qu’annonce le ministre de la culture dans un communiqué du 6 avril 2007 (lire la suite) parallèlement à la parution du décret du 4 avril 2007 qui fixe l’organisation, le fonctionnement et la procédure de saisine et d’instruction des dossiers devant l’Autorité. Cette autorité aura la lourde tâche de concilier les mesures techniques de protection des œuvres (DRM) légalisées par la loi DADVSI avec : d’une part, l’exercice des exceptions au droit d’auteur dont bénéficie les usagers ou certaines catégories d’entre eux (et notamment l’exception de copies privées) ; et d’autre part, les exigences d’interopérabilité : l’autorité doit veiller « à ce que les mesures de protection des œuvres n’aient pas pour conséquence, du fait de leur incompatibilité mutuelle ou de leur incapacité d’interopérer, d’entraîner dans l’utilisation d’une œuvre, des limitations supplémentaires indépendantes de celles expressément décidées par le titulaire d’un droit d’auteur ». L’Autorité pourra, dans ce cadre, ordonner à tout éditeur de logiciel, à tout fabricant de système technique ou encore à tout exploitant de service de fournir les informations nécessaires à l’interopérabilité des mesures techniques. Pour assurer cette mission, l’ARMT qui pourra être saisie par les bénéficiaires des exceptions ou encore les associations agréées les représentant, disposera de larges pouvoirs tant préventif que répressif. En effet, alors que la loi oblige notamment les fournisseurs de mesures techniques de protection à donner « l’accès aux informations essentielles à l’interopérabilité », l’ARMT disposera d’importantes prérogatives destinées à assurer le respect de ces obligations. Notamment, elle pourra, pour obtenir ces informations, émettre des injonctions si besoin sous astreinte et infliger, en cas d’inexécution, une sanction pécuniaire proportionnelle à l’importance du dommage causé et à la situation des entreprises sanctionnées. Les fonctions et missions conférées à l’ARMT ne sont pas figées. Elles seront amenées à évoluer notamment en fonction des évolutions techniques. Décret n° 2007-510 du 4 avril 2007 Communiqué de presse du 6 avril (Mise en ligne Avril 2007)

Contentieux informatique DRM Pas de droit opposable à la copie privée La Cour d’appel de Paris, après une décision de la Cour de cassation du 28 février 2006, vient de statuer en tant que cours de renvoi, sur les mesures techniques de protection appliquées aux DVD. A l’origine de ce contentieux, un consommateur avait acquis le DVD du film « Mulholland Drive » et n’avait pu en réaliser une copie de sauvegarde en raison d’un dispositif anti-copie. Il avait donc contacté l’association de consommateurs UFC Que choisir ? afin de faire reconnaître un droit à la copie privée. Le tribunal de première instance avait refusé d’accéder à la demande en avril 2004, jugeant que la copie privée n’était un droit mais une exception. Dans sa décision du 22 avril 2005, la 4e chambre de la Cour d’appel de Paris avait contredit le premier juge et reconnu l’existence d’un droit opposable à la copie privée. Les studios de production se sont alors pourvus en cassation et ont obtenus le renvoi de l’affaire devant la cour d’appel de Paris, les juges du fond n’ayant pas, comme l’exigent les engagements internationaux (directive européenne du 22 mai 2001), vérifié si la copie des DVD portait atteinte à « l’exploitation normale de l’oeuvre » ou causait « un préjudice injustifié aux intérêts de l’auteur« . Dans son arrêt du 4 avril 2007, la Cour d’appel de Paris reprend les arguments de première instance qu’elle avait pourtant contredit en 2004. Elle considère en effet que la copie privée « ne constitue pas un droit mais une exception légale au principe de la prohibition de toute reproduction intégrale ou partielle d’une oeuvre protégée« . Elle en déduit que l’exception pour copie privée, « ne saurait être invoquée comme étant constitutive d’un droit au soutien d’une action formée à titre principal« , rappelant ainsi un principe fondamental de la procédure judiciaire où le droit est la condition de l’action (repris par le célèbre adage : « pas de droit, pas d’action« ). Si la loi prévoit qu’on n’a pas le droit d’interdire une copie privée, on ne peut bénéficier de ce droit qui n’en est pas un, sans être d’abord poursuivi par l’ayant droit. CA Paris 4e ch. 4 avril 2007 (Mise en ligne Avril 2007)

Contentieux informatique DRM L’Autorité de Régulation des Mesures Techniques voit enfin le jour Instaurée par la loi du 1er 2006 relative aux droits d’auteur et aux droits voisins dans la société de l’information (DADVSI)(1), l’Autorité de Régulation des Mesures Techniques (ARMT) voit enfin le jour grâce au décret du 4 avril 2007(2). Alors que la loi DADVSI légalise les mesures techniques de protection des œuvres (DRM), cette autorité est la gardienne de l’interopérabilité. Elle a la lourde tâche de concilier les DRM avec : l’exercice des exceptions au droit d’auteur dont bénéficie les usagers ou certaines catégories d’entre eux (et notamment l’exception de copies privées) ; les exigences d’interopérabilité : l’autorité doit veiller « à ce que les mesures de protection des œuvres n’aient pas pour conséquence, du fait de leur incompatibilité mutuelle ou de leur incapacité d’interopérer, d’entraîner dans l’utilisation d’une œuvre, des limitations supplémentaires indépendantes de celles expressément décidées par le titulaire d’un droit d’auteur ». L’ARMT peut être saisie par tout éditeur de logiciel, tout fabricant de système informatique et tout exploitant de service, en cas de refus d’accès aux informations essentielles à l’interopérabilité, c’est-à-dire :la documentation techniques et les interfaces de programmation nécessaires pour permettre à un dispositif technique d’accéder à une œuvre ou à un objet protégé par une mesure technique aux informations sous forme électronique jointes. Pour assurer sa mission, l’ARMT dispose de larges pouvoirs. Elle peut notamment émettre des injonctions, si besoin sous astreinte. Elle peut également prononcer des sanctions pécuniaires soit en cas de non-respect de ses injonctions, soit en cas de non-respect des engagements des parties qu’elle aurait acceptés. Les sanctions pécuniaires pouvant être infligées par l’ARMT peuvent être très lourdes puisque chaque sanction pécuniaire est non seulement proportionnée à l’importance du dommage causé aux intéressés, mais aussi à la situation de l’organisme ou de l’entreprise sanctionné, ainsi qu’à l’éventuelle réitération des pratiques contraires à l’interopérabilité. Ces sanctions pécuniaires peuvent ainsi atteindre jusqu’à 5 % du montant du chiffre d’affaires mondial hors taxes le plus élevé réalisé au cours d’un des exercices clos depuis l’exercice précédant celui au cours duquel les pratiques contraires à l’interopérabilité ont été mises en œuvre dans le cas d’une entreprise et à 1, 5 million d’euros dans les autres cas. (1) Loi n° 2006-961 du 01/ 08/2006 , JO du 03/08/2007. (2) Décret n° 2007-510 du 04/04/2007, JO du 05/04/2007 Paru dans la JTIT n°64/2007 p.1 (Mise en ligne Mai 2007)

Contentieux informatique Contrats spécifiques Le contrat de location de matériel informatique Une société avait conclu avec un négociant informatique un contrat de location d’ordinateur contenant des logiciels d’exploitation. Le logiciel d’application nécessaire au fonctionnement du matériel faisant défaut, la société assigna le prestataire informatique en résiliation du contrat. Se fondant sur l’argument selon lequel l’obligation de délivrance consiste non seulement à livrer ce qui a été convenu, mais aussi à mettre à la disposition du créancier une chose qui corresponde en tous points au but par lui recherché, le client cherche à ce que les juges apprécient la conformité de la livraison par rapport à l’usage auquel le matériel est destiné. Ce n’est pas la position qu’a adopté la cour de cassation, qui s’est cantonnée au strict contenu du contrat. A la lecture de ce dernier, aucune obligation de livraison d’un logiciel d’application n’apparaît. De plus, la société cliente ne peut se prévaloir d’une quelconque incompétence, la cour ayant relevé qu’elle est expérimentée dans l’utilisation de l’informatique. La résiliation du contrat s’est donc faite aux torts exclusifs de la société cliente. Cass, com., 17 décembre 1991 (Mise en ligne Janvier 2006)

Contentieux informatique Contrats spécifiques Le contrat « offshore » : les prérequis Dans le domaine des réalisations logicielles, l’offshore est amené à se développer. L’efficacité de ce type de prestation suppose un certain nombre de garde-fous contractuels… (Lire l’article paru dans CXP-l’Oeil expert) (Mise en ligne Mars 2006)

Contentieux informatique Contrats spécifiques Mieux encadrer les contrats offshore Selon une estimation Gartner, les opérations offshore sur le marché informatique représenteront, en 2007, 50 milliars de dollars, d’où l’intérêt de procéder à un encadrement minutieux des accords conclus entre clients français et prestataires étrangers… (Lire l’article paru dans Information & Systèmes) (Mise en ligne Avril 2006)

Contentieux informatique Contrats spécifiques Les ERP dans les systèmes d’information professionnels En tant que logiciels, les ERP bénéficient de la protection juridique particulière des œuvres de l’esprit. L’auteur en a donc le monopole d’exploitation au titre duquel il est seul habilité à organiser les modalités de reproduction, de représentation et d’adaptation de ses productions et ce pour une durée de soixante-dix ans à compter de la mise à disposition du public. En 1994, le législateur a voulu limiter cette situation de monopole en essayant de créer les droits de l’utilisateur, mais cette tentative n’a eu qu’une portée très limitée. De par ces dispositions, l’éditeur dispose plus particulièrement du monopole de l’adaptation de ses produits : il se réserve ainsi la maintenance corrective et évolutive de ses produits. Et bien que l’utilisateur ait acquis un droit d’exploitation, il n’a, en réalité, les droits d’exploitation que d’une version du progiciel. Ces mêmes textes prévoient également que l’utilisateur peut rectifier les erreurs affectant le produit, mais seulement si l’éditeur ne s’est pas lui-même réservé ce droit de correction. Et le fait de ne pas réaliser de modification ne vaut pas renonciation au droit de correction. Par nature, les ERP sont des produits destinés à couvrir les besoins fonctionnels génériques d’une catégorie d’utilisateurs, et la question de l’adéquation plus ou moins fine de ces produits aux besoins des utilisateurs se pose donc. Pour tenter de palier ce type de difficulté, les ERP sont très modulables et fortement paramétrables. La forte « paramétrabilité » peut néanmoins poser des problèmes d’intégration et de tierce maintenance applicative en termes de coûts et de maîtrise de la solution. Il est en effet plus économique que l’utilisateur s’adapte au progiciel plutôt que de l’adapter à ses besoins en réalisant de nombreux développements spécifiques. De même qu’en cas d’infogérance l’entreprise doit s’interroger sur la pertinence de confier à un tiers tout ou partie de son système d’information, dans l’intégration d’un ERP elle devra s’interroger sur la pertinence d’organiser les fonctions de l’entreprise concernées par le progiciel conformément aux règles envisagées par l’éditeur du progiciel ou au contraire de privilégier une organisation métier spécifique. Paru dans la JTIT n°68/2007 (Mise en ligne Septembre 2007)

Contentieux informatique Contrats spécifiques Le progiciel dans tous ses états Le forum organisé par le CXP sous le thème « Le progiciel dans tous ses états » a rencontré un vif succès traduisant l’intérêt croissant des utilisateurs pour des solutions innovantes qui demeurent en phase avec les attentes du marché et les normes en vigueur. La place croissante des progiciels dans les systèmes d’information peut aussi résulter d’une évolution fonctionnelle et organisationnelle. En effet, les progiciels du marché sont de plus en plus riches, paramétrables de telle sorte que la couverture des besoins des utilisateurs peut désormais être recherchée au moyen de paramétrages plus que de développements spécifiques. Parallèlement les utilisateurs inscrivent de plus en plus leur mode de production de gestion et administration dans des processus normés qui les rendent « visibles et lisibles » sur le marché pour leurs clients, leurs partenaires et surtout leurs actionnaires. Du fait de cette standardisation, les progiciels sont de nature à répondre aux exigences de conformité qui s’imposent de façon plus ou moins prégnante suivant le secteur d’activités concerné et/ou la taille de l’entreprise dès lors que la standardisation des processus métiers devient un impératif du marché, les progiciels contribuent à l’idée que l’utilisateur développe des pratiques standards, normées et mutualisées. Actuellement, l’offre de produit progiciel peut placer l’utilisateur dans un lien de dépendance technique vis-à-vis de son fournisseur, lequel contrôle le versioning et l’évolution de ses productions. Face à cette situation, se développent des centres de services dans le cadre desquels l’utilisateur ne « consomme » plus de produits progiciels mais les services rendus par le ou les progiciels nécessaires à l’exécution des tâches et traitements de son exploitation professionnelle. Leur multiplication permis par des moyens techniques de plus en plus fiables et performants (ASP) génère le glissement d’une consommation de produits à celle de services. Les impacts juridiques liés à une telle évolution son évidemment nombreux et structurants. Sur un plan comptable, les règles de valorisation d’un actif progiciel et d’un service ou un abonnement type ASP, BPO ou SAS sont distincts. En outre, les contrats permettant à l’utilisateur final d’utiliser les progiciels changent d’objet. Il ne s’agit plus d’un transfert à titre non-exclusif d’un droit d’exploitation, mais de l’accès au résultat des traitements opérés par le prestataire. Le contrat de licence principale sera donc conclu entre l’éditeur et le fournisseur de services. Les clauses essentielles de ces contrats de services ne seront plus celles des licences (réception, responsabilité, garantie d’éviction ou d’évolutivité et de compatibilité ascendante), mais les clauses d’accessibilité aux services, de disponibilité, de performances, de pénalité et surtout de réversibilité. De tels contrats ne pourront pas présenter le même degré d’automaticité et d’intangibilité que les contrats de licences de progiciels car ils doivent être adaptables aux besoins particuliers des utilisateurs et évoluer en fonction de leurs activités. Forum du 23/10/2007 Paru dans la JTIT n°71/2007 (Mise en ligne Décembre 2007)

Contentieux informatique Contrats spécifiques Quel contrat pour les architectures orientées services (SOA) ? Les architectures orientées services ou systèmes SOA sont conçues autour de la notion de services correspondant à une action exécutée par un fournisseur et consommée par un client, alors que l’interaction entre le producteur (fournisseur) et le consommateur (client) du service est assurée par un médiateur «bus». L’un des intérêts de ces architectures est de permettre une grande modularité des systèmes et surtout une réutilisation de services pouvant contribuer au traitement de nombreux processus distincts. Ils présentent toutefois une contrainte forte au regard de l’intégration de composants nouveaux. En matière d’intégration, le client maître d’ouvrage se voit investit d’une obligation de description de ses besoins, en termes de système cible et de description de son existant ou à tout le moins des composants avec lesquels les fournitures nouvelles « matériels et ou logiciels » devront interagir. Si l’existant est conçu avec une architecture de type SOA, cette organisation sera structurante pour le schéma d’intégration de composants nouveaux. Si le fournisseur ne dispose pas d’un accès ou d’une description de l’annuaire des services assez documentée, il y a un risque de dérive des coûts et des délais de réalisation et surtout d’inadéquation de la méthodologie d’intégration par rapport aux contraintes urbanistiques et architecturales du client. Les prestataires de TMA (tierce maintenance applicative) ou les centres de services doivent être informés des normes d’architecture utilisées tant pour les services existants que pour de la création de nouveaux services. Les relations contractuelles du maître d’ouvrage avec ses prestataires devront intégrer une garantie de compatibilité des fournitures et prestations avec l’existant et les principes et méthodes qui régissent cet existant. Dès lors que le client a mis en œuvre un schéma directeur intégrant une SOA, il paraît cohérent qu’il s’assure de l’évolutivité des fournitures diverses des prestataires de façon cohérente avec ce type d’architecture. Enfin, la dimension « SOA » devra nécessairement être intégrée dans les protocoles de tests des fournitures, ainsi que dans les plans de réversibilité pour toutes les prestations de services récurrentes. Paru dans la JTIT n°77/2008 p.1 (Mise en ligne Juin 2008)