8 mars 2010

Informatique Les obligations du fournisseur 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 Décembre 1991)

Informatique Les obligations du fournisseur Le devoir d’information Ayant fait l’acquisition d’une imprimante d’étiquettes et de diverses fournitures auprès d’une société d’informatique, une pharmacie fit part à cette dernière de son insatisfaction. Malgré l’envoi par la suite de modèles de maquettes déterminés à partir de précisions relatives aux besoins de la pharmacie, le résultat ne fut pas davantage satisfaisant et le vendeur vit son cocontractant demander l’annulation du contrat. Cette affaire oppose le traditionnel « triptyque » d’obligations du fournisseur (obligation de mise en garde, d’information et de conseil) au devoir de précision et d’expression de ses besoins incombant à l’utilisateur. En l’espèce, la pharmacie n’avait pas défini ses besoins de manière claire et précise, tandis que le fournisseur n’avait, pour sa part, proposé aucune solution adaptée ni mené d’étude satisfaisante. Par le biais de cette décision, la cour d’appel de Poitiers précise l’articulation entre les obligations respectives du fournisseur et de l’utilisateur. En effet, si l’utilisateur est tenu à un devoir de collaboration en précisant ses besoins, le fournisseur a le devoir de rechercher cette information et de fournir les conseils adaptés. CA Poitiers ch. civ. 1re sect., 11 avril 1995 (Mise en ligne Avril 1995)

Informatique Les obligations du fournisseur Les prestations assujetties à une obligation de résultat Un fournisseur informatique était chargé de l’informatisation du réseau commercial d’une entreprise. En raison d’un certain nombre de retards, ainsi que des dysfonctionnements du système, le client ne s’acquitta pas d’une partie de la facture. L’affaire fut portée en justice, afin de déterminer la véritable qualification de l’obligation de fourniture d’un système informatique dans un contrat dit « clés en main ». Ce type de contrat signifie que le client aura à sa disposition un système dont toutes les composantes fonctionnent ensemble, une fois la prestation du fournisseur finie. Traditionnellement, le contrat « clés en main » engendre une obligation de résultat à la charge du fournisseur informatique, ce dernier ne pouvant s’en dégager qu’en invoquant un cas fortuit ou de force majeure ou bien le fait d’un tiers ou de la victime. La décision des juges du fond de retenir la responsabilité du fournisseur a été confirmée par la cour de cassation. Allant même plus loin, la cour a considéré que le fournisseur, qui avait été induit en erreur par le distributeur, a négligé son obligation de conseil en ne procédant pas à une vérification des performances des matériels et logiciels. Cette affaire démontre, une fois de plus, que le cahier des charges est un outil indispensable pour apprécier l’obligation du fournisseur. CA Reims ch. civ. Sect. 1, 17 janvier 1996 (Mise en ligne Janvier 1996)

Informatique Les obligations du fournisseur Le devoir de conseil et de mise en garde Après avoir commandé un système informatique de gestion d’une cantine adapté au matériel préexistant et avoir convenu que ce système ferait l’objet d’une adaptation de portage confiée à une société tierce, un établissement scolaire a obtenu judiciairement le droit de ne pas payer les factures en raison de la non compatibilité du système depuis la livraison. Selon la cour de cassation, l’obligation de conseil du vendeur s’étend à l’information de l’acheteur quant à la faisabilité des interventions nécessaires à leur mise en service et quant aux délais requis par elles. Se fondant sur ce principe, les juges ont considéré que le fournisseur devait identifier les difficultés que pourrait susciter l’adaptation d’un nouveau système informatique à celui préexistant. De plus, l’obligation de délivrance n’étant exécutée qu’une fois la mise au point effective de la chose vendue réalisée, le fournisseur a donc aussi manqué à cette dernière obligation. L’intervention du tiers au contrat ne saurait en outre modifier la responsabilité du fournisseur. Cet arrêt démontre que l’obligation de conseil du fournisseur d’un matériel complexe se prolonge au-delà de la conclusion du contrat, par une mission d’assistance technique. Cass. 1re ch. civ., 3 juillet 2001 (Mise en ligne Juillet 2001)

Informatique Les obligations du fournisseur Manque à gagner et indemnisation pour dysfonctionnement des systèmes informatiques d’encaissement Deux hypermarchés exploitant la même enseigne avaient fait l’acquisition d’une solution informatique d’encaissement et de télépaiement. Après le constat d’un certain nombre de dysfonctionnements qui bloquent leurs caisses et leurs télépaiements, ils saisirent les autorités judiciaires. La cour d’appel prononce la résolution des contrats, la version du logiciel installée par le fournisseur n’étant pas agréée par le Groupement des cartes bancaires, contrairement aux exigences réglementaires en vigueur. La restitution des matériels et logiciels au fournisseur a été suivie du remboursement par ce dernier des coûts d’acquisition par crédit-bail. Pour évaluer le montant des manques à gagner subis par les deux clients, dont les ventes ont été perturbées pendant trois ans par des dysfonctionnements informatiques, la cour calcule leurs pertes de marge sur coûts variables en appliquant leur taux de résultat d’exploitation au montant de la perte de chiffre d’affaires retenue. CA Paris, 25e ch. Sect A., 22 février 2002 (Mise en ligne Février 2002)

Informatique Les obligations du fournisseur Un système informatique ne répondant pas aux besoins d’une entreprise IBM avait proposé à une société de commander à un éditeur un progiciel en développement, dont le délai d’achèvement était estimé à dix-huit mois. Dans ce projet, IBM était chargé de la fourniture des matériels et de l’assistance à la maîtrise d’ouvrage du projet, incluant le suivi de la définition des spécifications, le suivi du développement du progiciel, l’intégration et le déploiement. Deux ans plus tard, l’éditeur se trouvait en liquidation judiciaire, alors que le progiciel n’était toujours pas terminé. Ayant demandé au repreneur de terminer l’ouvrage, la société s’est rendue compte trois ans plus tard que le système informatique ne répondait pas à ses besoins et a saisi le tribunal en vue d’obtenir réparation de la part d’IBM. Se fondant sur des rapports d’experts, la cour a estimé que IBM avait failli à ses obligations d’assistance au développement. Le logiciel ayant été longuement utilisé et l’inadéquation des matériels fournis n’étant pas prouvée, la cour n’a accordé qu’une indemnisation partielle, sans préciser explicitement la répartition entre les différents préjudices. CA Paris, 25e ch., 15 novembre 2002 (Mise en ligne Novembre 2002)

Informatique Les obligations du fournisseur Annuaire et responsabilité des éditeurs Les annuaires ont une double vocation. Pour les utilisateurs, cet outil permet la recherche efficace d’un correspondant par des moyens classiques ou électroniques. Pour les entreprises, il permet d’être connu et identifié. L’effet de notoriété en découlant appelle à une réglementation soucieuse de la protection des données personnelles et sensibles aux enjeux économiques sous-jacents. Ainsi, la cour de cassation avait jugé, dans une affaire relative à un annuaire édité par une société, que cette dernière avait commis une faute en n’étant pas exhaustive, eu égard au périmètre ciblé qui comprenait, notamment, des professionnels. Cette tendance qu’a introduit la cour met en relief toute l’importance de la complétude des informations pour les exploitants d’annuaires. En outre, la voie est ouverte à la vérification systématique de l’exhaustivité de ces bases par les personnes concernées. Cass. Civ. 2, 9 octobre 2003, n°02-12641 Loi n°96-659 du 26 juillet 1996 (Mise en ligne Octobre 2003)

Informatique Les obligations du fournisseur Gérer la qualité de service Qu’ils s’agissent d’un projet d’implémentation d’un nouveau système d’information, d’intégration du système, de mise en œuvre d’un ERP, ou encore de mise en œuvre de services récurrents, telles que infogérance, administration de réseau télécoms, la gestion de la qualité n’est pas seulement l’affaire du prestataire mais également celle du client-utilisateur. Il n’est pas rare qu’un différend naisse sur une divergence d’appréciation du critère qualitatif, qui peut conduire à la résiliation du contrat. Or, la qualité d’un service, d’un résultat ou d’un document (dossier de spécification, manuels de procédures d’exploitation …), ne se décrète pas : elle se constate. Toute la difficulté est de mettre en place des outils de constat les plus objectifs possibles. Pour éviter une appréciation subjective, il est impératif de convenir préalablement d’un certain nombre de critères. Il en est de même pour l’évaluation des niveaux de services et des résultats attendus. La gestion de la qualité peut être mise en œuvre avec différents outils : contractuels, internes ou externes. Parmi les outils contractuels permettant de suivre la qualité, de tracer les anomalies et les difficultés on trouve le plan d’assurance qualité, le comité de pilotage, les états de suivi ou indicateurs, les procédures de recette et d’escalade. Mais ces outils permettent rarement de suivre l’origine et les responsabilités qui en découlent. Il est possible de mettre en œuvre une dataware house dédiée au projet comprenant l’ensemble des documents électroniques du projet échangé y compris les mails. Ils sont le reflet des actions entreprises par les parties car ils sont écrits en mode plus naturel que les comptes rendus de comité. Ces éléments pourront être examinés par un expert judiciaire en cas de litige car ils permettent le plus souvent d’analyser l’origine des problèmes et les responsabilités. Il est donc indispensable de gérer et de « normer » ce dataware house. S’agissant des outils externes, les parties peuvent se référer à des normes à condition de vérifier qu’elles sont applicables ou adaptables. S’agissant des outils internes, l’entreprise utilisatrice peut mettre en place un système d’enquête de satisfaction en conformité avec la loi Informatique, fichiers et libertés. Paru dans la JTIT n°40/2005 p.4 (Mise en ligne Mai 2005)

Informatique Les obligations du fournisseur Le défaut de conformité et la recette en informatique Sur la base d’un bon de commande, un utilisateur a acquis un système informatique. Ce système était présenté de manière détaillée composant par composant. Lors de la livraison, l’utilisateur n’a pas contesté la livraison et a payé les composants du système malgré des différences entre le système commandé et celui livré portant notamment sur les marques de produits et les références de certains éléments de l’ensemble informatique. L’utilisateur final du système informatique a introduit une action en résolution pour inadéquation de la chose livrée avec la chose commandée, s’analysant en un manquement du vendeur à ses obligations de délivrance. Débouté par la Cour d’appel d’Angers, il a porté l’affaire devant la Cour de cassation, laquelle a confirmé l’arrêt d’appel en ces termes : « La réception sans réserve de la chose vendue couvre ses défauts apparents de conformité » (1). Sur le plan légal, l’acheteur doit contrôler la délivrance lors de la « prise en main ». L’obligation de réception qui incombe à l’acquéreur est la contrepartie de l’obligation de délivrance du fournisseur. L’absence de réserves lors de la livraison le prive du droit d’invoquer la non-conformité, la preuve n’étant pas rapportée que ce matériel est incomplet ou inadéquat avec celui commandé. Ce n’est en effet que si l’acquéreur peut établir la non-conformité, qu’il peut demander la résolution de la vente ou la réfaction du prix si le matériel conserve néanmoins son utilité. Cass.civ. 17/07/2005 pourvoi n°03-13851,Soc.Amix Informatique (Mise en ligne Juillet 2005)

Informatique Normalisation Le standard OOXML de Microsoft devient une norme internationale Le format OOXML supporté par OpenOffice devient une norme internationale, l’ISO/IEC DIS 29500, Technologies de l’information, Formats de fichier «Office Open XML». Elle vient d’être confirmée par les bureaux techniques de l’ISO (organisation regroupant les instituts nationaux de normalisation de 157 pays) et de la CEI (organisation mondiale pour l’élaboration et la publication de Normes internationales pour tout ce qui a trait à l’électricité, à l’électronique et aux technologies apparentées). Paru dans la JTIT n°80/2008 p.14 (Mise en ligne Septembre 2008)

Informatique Les marchés publics La transmission électronique des marchés publics dans le cadre du contrôle de légalité En application du Code général des collectivités territoriales (CGCT), les acheteurs publics sont tenus au titre du contrôle de légalité, de transmettre un certain nombre d’actes au représentant de l’Etat pour acquérir un caractère exécutoire, c’est-à-dire pouvoir être mis en œuvre. De nombreux contrats, à commencer par les marchés publics, passés par une collectivité sont concernés par cette obligation. La transmission au préfet est cependant conditionnée par le montant du marché. Elle n’est obligatoire que pour un marché dépassant le seuil de 230 000 € HT. Toutefois, les délibérations de l’assemblée délibérante afférentes à des marchés inférieurs au seuil de 230 000 € HT demeurent soumises à l’obligation de transmission au titre du contrôle de légalité. Ainsi, dans le cas où une collectivité territoriale se dote, pour les marchés inférieurs à 230 000 € HT d’un guide interne de procédure, la délibération adoptant ce guide sera soumise à l’obligation de transmission au titre du contrôle de légalité (1). En application de l’article L. 2131-1 alinéa 3 du CGCT, « la preuve de la réception des actes par le représentant de l’Etat dans le département ou son délégué dans l’arrondissement peut être apportée par tout moyen ». A côté du circuit classique de transmission des actes par voie postale ou par télécopie, un décret du 7 avril 2005(2) pose les règles générales à suivre pour la transmission électronique des actes des collectivités territoriales soumis au contrôle de légalité. Ce décret prévoit notamment que la commune doit recourir à un dispositif de télétransmission ayant fait l’objet d’une homologation ou encore, que le maire doit signer avec le préfet une convention comprenant la référence du dispositif homologué, prévoyant par exemple, la nature et les caractéristiques des actes transmis ainsi que les engagements respectifs de chacun pour l’organisation du fonctionnement de la télétransmission. Cette procédure doit être strictement encadrée puisque le défaut de transmission d’un acte qui aurait dû l’être empêche ce dernier d’acquérir le caractère exécutoire prévu par la loi, ce qui en pratique, peut avoir de lourdes conséquences. (1) Circulaire du ministère de l’intérieur, Direction générale des collectivités locales, 10 août 2004, NOR/LBL/B/04/10069/C. (2) Décret n°2005-324 du 7 avril 2005, JO n° 82 du 08.04.2005. Paru dans la JTIT n°48/2006 p.4 (Mise en ligne Janvier 2006)

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)

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)

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)

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)

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)

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 Mars 2007)

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 Janvier 2008)

Informatique La gouvernance des 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 juillet-août 2002)