Formation aux contrats informatiques SaaS et Open Source

Contrats informatiques Saas et Open SourceMarie Soulez anime une formation pour Lamy Formation (Wolters Kluwer) sur les contrats informatiques SaaS et Open Source le 21 mai 2019.

Avocat au barreau de Paris et directrice du département Propriété intellectuelle Contentieux de Lexing Alain Bensoussan Avocats, Marie Soulez, abordera de nombreuses questions autour des contrats SaaS et Open source :

  • quels sont les outils juridiques permettant d’améliorer la rédaction des contrats SaaS ?
  • comment optimiser sa pratique rédactionnelle des contrats SaaS ?
  • quels sont les principes liés à la protection des logiciels par le droit d’auteur et les prérogatives associées de l’auteur ?
  •  comment maîtriser les principes fondamentaux du logiciel libre ? les différents niveaux de copyleft, les enjeux liés à la contamination et à la compatibilité des licences , etc.

La protection du logiciel par la propriété intellectuelle

  • La définition du logiciel (les éléments protégeables, la condition d’originalité, la traçabilité)
  • Le titulaire de droits (les principes, les œuvres de commande, le logiciel développé par un salarié)
  • Les droits patrimoniaux
  • Les différents types de contrat (les contrats de cession, les contrats de développement, les contrats de licence, les contrats de maintenance)

Le Contrat Saas

  • Les acteurs et l’objectif du contrat SaaS
  • Les clauses essentielles (Préambule et définitions, périmètre des services et bénéficiaires, conformité et recette, responsabilité, propriété intellectuelle, convention de services, service level agreement)
  • Le contrat Saas et les données

L’Open Source

  • Les 4 libertés fondamentales (exécuter, étudier et modifier, distribuer, redistribuer)
  • Les typologies de licences et leurs philosophies (Copyleft et sans copyleft, l’absence de garantie, les impacts)
  • La gestion contractuelle (exploiter des logiciels sous licence libre, distribuer des logiciels sous licence libre)
  • Etude de cas
  • L’identification des clauses favorables au client et celles favorables au fournisseur dans un contrat Saas par l’analyse d’un contrat piégé
  • L’analyse d’un contrat de tierce-maintenance applicative de logiciel libre

Télécharger la fiche thématique : Contrats informatiques Saas et Open Source

Pour la formation « Contrats informatiques Saas et Open Source », s’inscrire auprès des éditions Wolter Kluwer




Les données, l’élément central et malmené du TensorFlow

Les données, l’élément central et malmené du TensorFlow

Plus d’un an après le reversement du système TensorFlow en open source, la stratégie de Google interroge.

Le reversement en open source du TensorFlow

Google vient de publier la version finale de l’élément phare de son programme d’intelligence artificielle, le TensorFlow, que l’entreprise avait déjà mis gratuitement à disposition en novembre 2015 (1) . Cette technologie cruciale pour le géant de Palo Alto, est utilisée pour analyser et classer les images, pour assurer la reconnaissance vocale sur Android, ou encore pour trier les spams et envoyer des réponses automatiques via « Smart reply » sur Gmail.

En agissant de la sorte, Google a souhaité donner la possibilité à tout développeur d’enrichir librement son système et a ainsi ajouté TensorFlow à la liste des technologies machine et deep learning en open source et comprenant déjà Torch, Caffe ou Theano (2). Cette stratégie de partage à des fins d’amélioration collective n’est pas si singulière et a été partiellement suivie par Microsoft et son programme CNTK (3), ainsi que par Facebook qui a diffusé certains modules de deep learning pour Torch (4).

Aussi salutaire et bienvenue que puisse être qualifiée cette politique, elle ne doit toutefois pas être perçue comme l’avènement tant attendu du logiciel libre et du partage universel des connaissances. L’intérêt de ces entreprises est le perfectionnement gratuit et inconditionné de son système deep learning. Jouissant d’une très grande renommée auprès de l’ensemble des développeurs, le TensorFlow attire indéniablement la curiosité des plus aguerris. En prêtant attention à toutes les pistes et travaux de la communauté open source, Google peut ainsi faire profiter ses propres services et produits des différentes avancées constatées.

Google, bénéficiaire principal des progrès du TensorFlow

La raison pour laquelle Google sera le premier bénéficiaire des progrès du TensorFlow est que la valeur d’un système machine learning est avant tout fonction de la quantité de données collectées (5). En effet, puisqu’un programme de machine learning fonctionne en dotant un exemple du résultat attendu, à partir de la connaissance préalable des résultats associés aux exemples similaires, ce programme nécessite impérativement de disposer, en amont, d’une large base de données. Plus cette base de données sera importante, plus justes et étendues seront les prédictions du système learning.

Ainsi et concernant cette branche de l’intelligence artificielle, tout l’enjeu réside dans la collecte d’informations. Une entreprise aura beau avoir apporté à un algorithme machine learning toute une série d’améliorations remarquables, sans détention de données, le machine learning ne lui sera strictement d’aucune utilité. A l’opposé, Google, via notamment Google Maps, Gmail, Android et Youtube, collecte une quantité gigantesque de données, capables d’alimenter en des proportions infinies ses programmes machine et deep learning, et peut aisément se positionner comme leader sur le marché.

Le risque d’entorses à la réglementation Informatique et libertés par les machine learning

Le traitement de données constitue le cœur de la problématique machine learning et son développement tous azimuts soulève ainsi de nombreuses questions Informatique et libertés intéressant tant les principes du consentement (6) (7), celui du respect de la finalité du traitement, de la collecte loyale et licite des données (8) que celui relatif à l’interconnexion (9).

En machine learning, le programme traite les données de façon autonome et ce dernier ne se préoccupe naturellement pas de savoir si les données disponibles et utilisées sont issues d’une personne qui a préalablement donné son accord à un traitement par un programme d’intelligence artificielle. Les notions d’autonomie et d’apprentissage, inhérentes au fonctionnement du machine learning, apparaissent de facto contradictoires avec l’exigence pourtant essentielle du consentement de la personne concernée au traitement de ses données.

Par ailleurs, une difficulté supplémentaire découle du principe selon lequel le machine learning a pour essence d’établir des prédictions, et plus spécifiquement d’obtenir une information inconnue à partir de données connues (10). Selon les déductions opérées par le machine learning, un organisme privé comme public peut se procurer des informations sur un individu dans un domaine complètement étranger au domaine des données initialement collectées et acquerra une donnée dont la collecte n’a a fortiori pas été consentie ou en contradiction avec la finalité ayant justifié le traitement originaire.

De surcroît, les informations que le machine learning finira par détenir au travers de ses algorithmes prédictifs, pourront être des données dites sensibles dont le traitement est interdit (11). Un machine learning serait en effet aisément capable de recueillir des données relatives à la santé ou encore aux opinions politiques à partir de données plus anodines et déjà à disposition de l’entreprise. Par conséquent et outre les problèmes ci-dessus évoqués, les machine learning mettent très fréquemment en œuvre des interconnexions de fichiers aux finalités différentes et les traitements qu’ils opèrent sont donc à ce titre soumis à l’autorisation préalable de la Cnil (10).

Il convient donc, pour toute entreprise souhaitant développer un système machine learning, de veiller à respecter la protection des données personnelles.

Lexing Alain Bensoussan Selas
Lexing Informatique et libertés

(1) www.nextinpact.com, Article de Vincent Hermann du 19-2-2017
(2) www.lemonde.fr, Article de Morgane Tual du 10-11-2015
(3) www.numerama.com, Article de Julien Lausson du 27-1-2016
(4) www.clubic.com, Article de Guillaume Belfiore du 19-1-2015
(5) www.wired.com, Article de Cade Metz du 16-11-15
(6) Loi 78-17 du 6-1-1978, art. 7
(7) Règl. UE 2016/679 du 27-4- 2016, art. 6 § 1
(8) Loi 78-17 du 6-1-1978, art. 6
(9) Loi 78-17 du 6-1-1978, art. 25
(10) Post du 6-2-2017
(11) Loi 78-17 du 6-1-1978, art. 8




Logiciel libre/open source : rappel d’un outil collaboratif

Logiciel libre/open source : rappel d’un outil collaboratifLe mouvement « open » et ses déclinaisons prônent plus de collaboratif et une plus grande liberté d’exploitation.

Open data, open knowledge, open innovation et crowdsourcing, sont autant de mouvements qui s’intègrent dans le sillage de l’économie collaborative et tendent à se déployer. Dans ce contexte, les logiciels dits libres ou open source jouent un rôle majeur.

Rappels terminologiques

Le logiciel libre est défini comme « un logiciel distribué avec l’intégralité de ses programmes sources, afin que l’ensemble des utilisateurs qui l’emploient puissent l’enrichir et le redistribuer à leur tour. Un logiciel libre n’est pas nécessairement gratuit et les droits de la chaîne des auteurs sont préservés ». En anglais, il est traduit par « free software » ou « open source software » (1).

Le logiciel libre, comme le logiciel propriétaire, est protégé par le droit d’auteur. Toutefois, dans le cadre de ses prérogatives, l’auteur décide de mettre au profit de la communauté son logiciel sous une licence dite libre. Ainsi, le programme logiciel, notamment son code source, peut être exécuté, copié, distribué, étudié, modifié, amélioré par tous et au profit de tous.

Bien que souvent associées de manière interchangeable, les notions de « logiciel libre » et de « logiciel open source » doivent être distinguées.

La Fondation pour le logiciel libre (Free Software Foundation, FSF), organisation américaine à but non lucratif fondée en 1985, associée au mouvement du logiciel libre, est à l’origine des quatre règles définissant le logiciel libre.

Pour être qualifié de logiciel libre, l’utilisateur doit avoir quatre libertés essentielles (2) :

1. la liberté d’exécuter le programme comme il le souhaite, pour n’importe quel usage ;
2. la liberté d’étudier le fonctionnement du programme et de le modifier pour qu’il effectue ses tâches informatiques ;
3. la liberté de redistribuer des copies, donc d’aider à son tour un autre utilisateur ;
4. la liberté de distribuer aux autres des copies de ses versions modifiées ; en faisant cela, l’utilisateur donne à toute la communauté une possibilité de profiter de ses changements.

La première et la troisième libertés nécessiteront alors un accès au code source.

Il existe trois principales catégories de licences libres qui se distinguent selon les modalités d’utilisation et de redistribution du code source :

  • la licence de domaine public, type BSD, CeCILL-B ;
  • la licence semi-libre, exemple GNU LGPL, CeCILL-C, MPL ;
  • la licence libre stricte, exemple GNU GPL, CeCILL-A.

Pour les licences libres, les libertés sont garanties par le « copyleft », terme anglais construit par opposition au terme « copyright », traduit parfois par « gauche d’auteur » ou « copie laissée », qui est la règle selon laquelle les utilisateurs qui redistribuent le programme logiciel libre ne doivent pas nier les libertés des utilisateurs de leur programme.

Le terme open source, se rattache plus précisément aux critères énoncés par une autre organisation américaine, appelée Open Source Initiative.

Une licence de logiciel est dite open source lorsqu’elle satisfait aux dix critères suivants (3) :

1. une libre redistribution : la licence ne doit pas empêcher une partie de vendre ou de donner le logiciel en tant que composant d’une distribution logicielle globale contenant des programmes provenant de diverses origines. La licence ne doit pas exiger que cette vente soit soumise au paiement de droits d’auteur ou de royalties ;
2. le code source : le programme doit inclure le code source, et doit permettre la distribution sous forme de code source et sous forme compilée. Lorsqu’une certaine forme de produit n’est pas distribuée avec le code source correspondant, il doit exister des moyens clairement indiqués afin d’obtenir le code source pour un coût de reproduction raisonnable, de préférence via un téléchargement sur Internet, sans frais supplémentaire. Le code source doit être la forme préférée dans laquelle un programmeur modifie le programme. Il n’est pas autorisé de proposer un code source rendu difficile à comprendre. Il n’est pas autorisé également de proposer des formes intermédiaires, comme ce qu’engendre un préprocesseur ou un traducteur ;
3. les œuvres dérivées : la licence doit autoriser les modifications et les œuvres dérivées, et doit permettre leur distribution dans les mêmes conditions que la licence du logiciel original ;
4. l’intégrité du code source de l’auteur : la licence ne peut restreindre la redistribution du code source sous forme modifiée que si elle autorise la distribution de fichiers « patch » à côté du code source dans le but de modifier le programme au moment de la construction. La licence doit explicitement permettre la distribution de logiciels construits à partir de code source modifié. La licence peut exiger que les œuvres dérivées portent un nom ou un numéro de version différent du logiciel d’origine ;
5. l’absence de discrimination entre les personnes et les groupes : la licence ne doit créer aucune discrimination à l’égard d’une personne ou d’un groupe de personnes ;
6. l’absence de discrimination entre les domaines d’application : la licence ne doit restreindre l’usage du programme selon le domaine d’application. Par exemple, la licence ne peut pas restreindre l’utilisation du programme dans une entreprise, ou pour la recherche génétique ;
7. distribution de la licence : Les droits attachés au programme doivent s’appliquer à tous ceux à qui le programme est redistribué sans qu’il soit nécessaire d’exécuter une licence supplémentaire par ces parties ;
8. la licence ne doit pas être spécifique à un produit : les droits attachés au programme ne doivent pas dépendre du fait que le programme fasse partie d’une distribution logicielle spécifique. Si le programme est extrait de cette distribution et est utilisé ou distribué dans les termes de la licence du programme, toutes les parties auxquelles le programme est redistribué devront bénéficier des mêmes droits que ceux accordés lorsque le programme est au sein de la distribution originale de logiciels ;
9. la licence ne doit pas restreindre les autres logiciels : la licence ne doit pas imposer de restrictions à d’autres logiciels distribués avec le logiciel sous licence. Par exemple, la licence ne doit pas exiger que tous les autres programmes distribués sur le même support soient des logiciels open source ;
10. la licence doit être technologiquement neutre : aucune disposition de la licence ne peut être fondée sur une technologie individuelle ou un style d’interface.

Des avantages collaboratifs certains

En matière de logiciel libre, l’effet collaboratif permet au titulaire de droit de voir son programme logiciel écrit et débogué plus rapidement et à moindre coût. En contrepartie, les utilisateurs jouissent librement, parfois gratuitement, de droits d’exploitation, sous réserve de conditions qui garantissent de garder le code accessible et protègent les autres utilisateurs en aval.

Des inconvénients restant dissuasifs

En pratique, le logiciel libre soulève des difficultés pouvant limiter son essor.

Economiquement, le logiciel libre n’est pas attractif pour celui qui le crée ou y contribue. Les éditeurs sont souvent obligés de proposer des services complémentaires, afin de financer le développement de leur programme.

Légalement et techniquement, l’interopérabilité avec les logiciels propriétaires est souvent rendue difficile par les éditeurs des logiciels propriétaires qui souhaitent protéger leurs créations et restent pour cela très actifs dans le lobby de leurs produits.

D’autres inconvénients pourraient être cités. On relèvera notamment celui de l’effet dit « viral » ou « contaminant » des logiciels libres, qui impose que les modifications du programme ou de certaines de ses œuvres dérivées soient elles-mêmes soumises aux conditions de la licence libre initiale. Face au faible contentieux en matière de logiciel libre, les acteurs sont souvent réticents à développer leurs produits par cet intermédiaire.

On se rappelle qu’en 2011, Free a été contraint, après une transaction faisant suite à son assignation devant le Tribunal de grande instance de Paris en 2008 (4), de donner accès aux codes sources des logiciels libres utilisés dans ses Freebox, en raison de son utilisation de logiciels libres soumis à la licence GNU GPL ; emboîtant le pas dans le secteur de la téléphonie à Orange et SFR-Neuf (5).

Un intérêt renouvelé pouvant permettre son essor

Malgré ces difficultés, le recours à ces logiciels tend à se développer. Le secteur public pourrait bien devancer le monde de l’entreprise.

La Commission européenne a déjà lancé son plan Open Source 2014-2017 (6).

L’article 16 de la loi n° 2016-1321 du 7 octobre 2016 pour une République numérique (7) encourage son développement dans les administrations françaises :

« Les administrations mentionnées au premier alinéa de l’article L. 300-2 du code des relations entre le public et l’administration veillent à préserver la maîtrise, la pérennité et l’indépendance de leurs systèmes d’information.
Elles encouragent l’utilisation des logiciels libres et des formats ouverts lors du développement, de l’achat ou de l’utilisation, de tout ou partie, de ces systèmes d’information. Elles encouragent la migration de l’ensemble des composants de ces systèmes d’information vers le protocole IPV6, sous réserve de leur compatibilité, à compter du 1er janvier 2018 ».

Enfin et surtout, les réflexions continuent et les adeptes des logiciels libres s’organisent. Après Le Free and Open Source Developers’ European Meeting (FOSDEM) qui s’est tenu en Belgique les 4 et 5 février 2017 (8) ; Lyon accueillera, les 1er et 2 avril 2017, la 18e édition des Journées du Logiciel Libre (JDLL) sur le thème « Société (dé)connectée, les dessous de la transparence… ». (9). A Paris, le Paris Open Source Summit se tiendra les 6 et 7 décembre 2017 (10).

Un nouveau souffle du logiciel libre, open source, en tant qu’outil collaboratif au sein des entreprises reste donc à suivre.

Marie Soulez
Lylia Lanasri
Lexing Contentieux Propriété intellectuelle

(1) Vocabulaire de l’informatique (liste des termes, expressions et définitions adoptés), JORF n°93 du 20-4-2007, p. 7078, texte n°84
(2) Définition du logiciel libre proposée par la Communauté GNU
(3) Définition du logiciel open source proposée par l’Open Source Initiative
(4) Assignation de Free devant le Tribunal de Grande Instance de Paris en 2008
(5) Numerama, Article « Orange publie le code source de ses Livebox », 30-11-2009
(6) Plan Open Source 2014-2017 sur le site de la Commission européenne
(7) Loi 2016-1321 du 7-10-2016, art. 16
(8) Site officiel du FOSDEM 2017
(9) Site officiel du JDLL
(10) Site officiel du Paris Open Source Summit




Galion Project – les levées de fonds des start-up numériques

Galion ProjectLe think tank Galion Project vient d’annoncer la mise en ligne d’un « term sheet » en open source.

Cette lettre d’intention type a été élaborée collectivement par une soixantaine d’entrepreneurs et des fonds d’investissement pour aider les fondateurs dirigeants lors de leurs premières levées de fonds avec des investisseurs.

Galion Project, qui regroupe des entrepreneurs du numérique français, a pour objectif de stimuler les entrepreneurs de la Frenchtech et de soutenir la diffusion d’une culture collaborative en France.

A destination des start-up réalisant leur première levée de fonds auprès de professionnels, cette lettre d’intention, proposée en anglais, reprend les différentes clauses usuelles utilisées par les investisseurs lors des levées de fonds et explique pédagogiquement les différents termes aux fondateurs de start-ups.

Pour les investisseurs, comme pour les fondateurs, il peut être intéressant de conclure très rapidement un accord afin de capter la cible pour l’investisseur et de sécuriser le financement pour le fondateur. Toutefois, la précipitation dans la signature de tels documents peut être dangereuse.

Généralement ces « term sheets », très souvent non engageants, figent néanmoins intellectuellement les négociations. Ils peuvent donner lieu à des incompréhensions susceptibles de provoquer des ruptures de pourparlers ou une mise sous pression du fondateur qui ne peut plus revenir sur ses engagements.

Le cadre proposé par Galion Project met en exergue la complexité des clauses que peut contenir une lettre d’intention. Par exemple, la rédaction et la mise en œuvre des clauses dites de liquidation préférentielle, de « BSA ratchet », de droit de préemption, de « lock up » ou encore de « bad leaver » ou « good leaver » nécessitent une attention particulière pour ne pas freiner par la suite la croissance et le développement de la start-up.

Même s’il peut être tentant de se dispenser d’avocat conseil dès les premières discussions, on ne rappellera jamais assez l’importance de ce deuxième acte fondateur dans la croissance et le développement d’une entreprise.

Les dirigeants, seuls depuis la création et luttant pour la survie de leur entreprise, doivent impérativement lors de cette étape critique prendre les bons engagements et s’inscrire dans une vision à long terme.

L’accompagnement des avocats, lors des levées de fonds, n’est pas limité à la rédaction de clauses juridiques, il est aussi humain, et le conseil aide généralement l’entrepreneur à prendre du recul dans un contexte d’ouverture du capital qui est très souvent déstabilisant.

En conclusion, cette initiative, enrichissante dans le partage d’expérience et l’esprit collaboratif, a également le mérite de mettre en évidence la complexité d’une lettre d’intention lors des levées de fonds et la nécessité pour les fondateurs d’associer, dès les premières discussions, leur avocat conseil.

Nathalie Plouviet
Lexing Financement de projets




Le projet Wikibuilding de génie urbain numérique

Le projet Wikibuilding de génie urbain numériqueLe projet « Wikibuilding » a pris vie dans le cadre de « Réinventer Paris », l’appel à projets urbains innovants lancé par la Ville de Paris, le 3 novembre 2014.

La compétition « Réinventer Paris », qui a pour objectif de développer les projets urbains et de constructions innovantes sur 23 sites parisiens, suscite un grand enthousiasme chez les professionnels du secteur du bâtiment. A ce jour, sur les 815 équipes en lice 6OO équipes provenant du monde entier ont d’ores et déjà déposé leur projet, dont le projet « Wikibuilding ».

Le projet « Wikibuilding », porté par l’agence d’architecture HOST, le promoteur REI France et la start-up UFO, apparaît comme un candidat idéal pour devenir l’un des lauréats de l’appel à projets urbains innovants « Réinventer Paris » et ce dans la mesure où le projet « Wikibuilding » repose sur l’idée d’un urbanisme innovant participatif.

Le cœur de cette initiative urbaine est l’open architecture : le projet « Wikibuilding » consiste à mettre à disposition du public, sur une plateforme, les plans de construction du bâtiment et permettre ainsi au public de soumettre des propositions de modifications voire de modifier directement les plans de construction, à l’aide de logiciels informatiques spécialement crées et mis à sa disposition, afin de construire, en collaboration avec les architectes, les promoteurs, les acteurs du numérique, un immeuble en bois intégralement modulaire et modulable.

L’ensemble des plans de construction sera ainsi en open source, ce qui permettra à chacun d’expérimenter ou d’améliorer le concept du « Wikibuilding ».

L’innovation sera au cœur du « Wikibuilding ». A cet égard et ce sur l’initiative de groupe d’assurances, il est prévu qu’un système de e-santé soit notamment intégré aux logements.

Les futurs habitants, les financeurs, les architectes, etc., seront invités à participer au design des lieux afin que l’immeuble puisse toujours évoluer en fonction des besoins ou des usages de ces derniers et reste un lieu dynamique et en perpétuel mouvement.

Le « Wikibuilding » sera un lieu d’habitations mais pourra également, à hauteur de 40% du bâtiment, devenir hôtel, espaces de travail, magasins, lieux de fêtes, showrooms, restaurants, librairie, conciergerie, etc.

Pour Monsieur Paul Jarquin, Président et fondateur de REI, le projet « Wikibuilding » constitue « la symbiose entre l’architecture et le pouvoir collaboratif de l’économie numérique ».

Les lauréats de l’appel à projets urbains innovants « Réinventer Paris » seront connus à la fin de l’année 2015.

Anne-Sophie Cantreau
Julie Feuvrier-Laforêt
Lexing Droit des dessins et modèles




Audit de licence : savoir s’y préparer et bien réagir

Audit de licence : savoir s'y préparer et bien réagirAlors que la clause d’audit de conformité devient systématique dans les contrats de licence de logiciel, la probabilité de sa mise en œuvre est de plus en plus forte. En l’absence d’une telle clause, certains éditeurs n’hésitent pas à mettre en œuvre des procédures de saisie-contrefaçon (1).

Un risque fort dans toute entreprise. Le risque d’un résultat défavorable est loin d’être négligeable. Les métriques prévus au contrat de licence ont parfois mal vieilli et ne sont plus en concordance avec un système d’information qui évolue vite et en profondeur, notamment sous l’effet du clustering ou de virtualisation de serveurs.

Les conséquences de la mise en œuvre d’un tel audit sont souvent très lourdes : les licences surnuméraires détectées sont généralement facturées au tarif public en vigueur, lequel peut être majoré dans certains contrats de 30 à 50%. Certains contrats vont même jusqu’à prévoir des indemnités au titre d’une clause pénale.

A défaut d’accord avec l’éditeur, le licencié récalcitrant encourt une action en contrefaçon ou, a minima, en responsabilité contractuelle (2).

La préparation proactive à un audit de licence. Pour se préparer à un audit, le mécanisme de contrôle s’inscrit dans une démarche S.A.M. (« Software Asset Management ») et comprend :

  • le recensement des progiciels installés sur les serveurs puis sur les postes de travail ;
  • la vérification des contrats de licence (incluant les logiciels sous licence libre ou « open source ») et de maintenance ;
  • la relation avec la facturation, en particulier pour la maintenance ;
  • les opérations de régularisation et d’optimisation du parc, y compris la résiliation des contrats de maintenance des progiciels qui ne sont plus utilisés ;
  • la régulation interne au moyen d’un dispositif de sensibilisation et de contrôle à l’aide la charte des SI.

Ce mécanisme permet au travers de l’analyse des écarts de procéder aux régularisations nécessaires qui peuvent parfois se traduire par des économies substantielles lorsqu’il en résulte que la maintenance de certains outils obsolètes est toujours en vigueur.

La réponse à l’annonce d’un audit de licence par l’éditeur. Il faut toujours prendre le temps de la réflexion et de l’analyse, surtout s’il s’agit d’exécuter directement des « scripts » fournis.

Les clauses d’audit sont souvent peu détaillées. Il faut donc exiger un délai suffisant avant la mise en œuvre d’un audit et des garanties de sécurité dans le cadre d’un protocole d’audit.

Si l’éditeur refuse d’accorder ces garanties, il appartiendra à l’éditeur de demander une expertise en justice, comme dans cette récente affaire opposant Carrefour à Oracle (3).

De par sa forte expérience dans l’accompagnement de ses clients dans les procédures d’audit, le cabinet est l’interlocuteur privilégié du DSI pour conduire toute étude d’analyse de risques et fournir les préconisations pertinentes à tout audit de licence.

Jean-François Forgeron
Eric Le Quellenec
Lexing Droit Informatique

(1) CPI, art. L. 122-6 et L. 332-1.
(2) TGI Paris, 3ème ch. 1ère sect. 6-11-2014.
(3) TGI Nanterre, 12-6-2014.




Maintenance des applications : les bonnes pratiques

Maintenance des applications : les bonnes pratiquesLa maintenance des applications est souvent un poste de dépense important qui n’est pas toujours optimisé faute d’être bien maîtrisé. Comment organiser au mieux les activités de maintenance applicative ?

Sur le plan juridique, la question de la maintenance applicative doit distinguer les hypothèses de tierce maintenance applicative (TMA) et l’internalisation de cette activité.

Externaliser la maintenance de tout ou partie des applications d’une entreprise auprès d’un prestataire présente certains avantages : bénéficier de technologies de pointe et d’une expertise à portée de main en permanence, dégager ses propres équipes informatiques internes de la maintenance de certaines applications et augmenter ainsi les performances du SI de l’entreprise.

Mais cette solution peut présenter certains inconvénients comme la dépendance à l’égard des fournisseurs et surtout, le coût financier.

En fonction des caractéristiques de l’organisation, il peut être intéressant pour l’entreprise de garder la maintenance de certaines applications notamment les applications importantes à longue durée de vie ou celles utilisant des technologies aisément accessibles en interne comme les applications développées en open source.

Tierce maintenance applicative (TMA) ou internalisation ?  TMA ou internalisation, dans les deux cas, des instruments juridiques majeurs peuvent être mis en œuvre pour favoriser l’efficience et l’efficacité de la maintenance.

Dans le cas de la TMA, il s’agit naturellement du contrat et de ses deux attributs majeurs : la convention de niveaux de services et le plan qualité de maintenance.

La convention de niveaux de services est destinée à mesurer pour l’essentiel, la performance des tâches de maintenance avec son lot de pénalités.

Ces dernières ne doivent pas être construites dans un esprit de sanction financière ou de compensation d’un quelconque préjudice, mais comme une incitation à bien faire. Dans cette optique, la politique de malus n’est pas non plus à proscrire.

Le plan qualité maintenance (PQM) est l’outil indispensable qui permet d’organiser la relation opérationnelle. Il doit notamment prévoir :

  • une matrice des responsabilités ;
  • les organes de la gouvernance ;
  • la documentation de reporting ;
  • les processus d’escalade.

Dans le cas d’une maintenance internalisée, un tel plan qualité n’est pas non plus dénué d’intérêt. Il peut être encadré par une charte de gouvernance interne entre « métiers » et DSI. Le contenu de cette charte peut reprendre certains éléments du PQM.

Pour construire cette charte, on peut également s’inspirer des 5 modèles de collaboration établis par le Forrester Research (1) permettant à chaque métier (DSI, MOE, pilote, MOA et client), d’identifier les besoins, de les prioriser, de choisir et d’implémenter la solution, et enfin, de la gérer et la renouveler.

Jean-François Forgeron
Lexing Droit Informatique

(1) Forrester Research, 6 avril 2010, Livre blanc de Forrester Consulting sur l’innovation commandé par Hewlett Packard.




Open innovation et propriété intellectuelle

Open innovation et propriété intellectuelleNée du développement des pratiques collaboratives et des technologies de l’information, l’ open innovation est à la mode.

Pourquoi limiter le champ des initiatives et la source de l’innovation aux services internes de R&D et risquer de passer à côté de mines d’or de bonnes idées ?

L’idée n’est pas nouvelle au sein des entreprises, où on la trouve par exemple implémentée sous la forme primitive des « boîtes à idées ». Elle au cœur des processus de recherche et de développement en commun mis en place dans les pôles de compétitivité. Ce qui est plus nouveau est l’association des clients et partenaires externes de l’entreprise, voire du grand public invité à participer à un projet de « crowdsourcing ».

L’open innovation permet aux entreprises d’être plus proches de leurs clients ou partenaires et d’atteindre des communautés éloignées, et donne aux innovateurs une chance inespérée de voir leur projet retenu et développé par un acteur majeur du domaine. Certains projets d’open innovation ont été largement médiatisés. A titre d’exemple :

  • Boeing a consulté 14 associations de passagers pour dessiner le Dreamliner ;
  • Oxylane (Décathlon) a conçu un vélo électrique en sollicitant une communauté de concepteurs professionnels ou amateurs travaillant selon les principes de l’open source ;
  • Dell a créé une plate-forme technique pour le grand public ;
  • Fiat a consulté 17 000 personnes dans 160 pays pour les spécifications de la Fiat Moi ;
  • Lego a invité ses clients à dessiner leur propre boîte de jeux en ligne ;
  • Raidlight a conçu avec ses clients son célèbre sac à dos ventral ;
  • etc.

Open. L’open innovation s’inscrit dans le mouvement « open » – open source, open contenus, open data, open knowledge, etc. – qui repose sur une idée de liberté d’exploitation, qu’il est d’usage d’opposer à la propriété intellectuelle, par nature privative. Open innovation et propriété intellectuelle sont-ils deux mondes inconciliables ?Sur le principe, il convient de souligner que ces deux mondes, non seulement ne sont pas étanches, mais qu’ils sont interdépendants : s’il n’existait pas de propriété intellectuelle, la question de l’« open » ne se poserait pas puisque l’exploitation des logiciels, des contenus, des données, serait libre. Or tel n’est généralement pas le cas ; par exemple, il n’existe aujourd’hui aucun logiciel qui soit dans le domaine public (c’est-à-dire dont l’auteur est décédé depuis plus de 70 ans).Open ne signifie pas libre, mais libéré, ce qui est différent. Il s’agit d’une liberté conditionnelle et limitée : c’est uniquement celle octroyée par le titulaire des droits de la propriété intellectuelle. La jurisprudence illustre régulièrement les déconvenues de ceux qui ignorent cette règle de base.

Risques. Les projets d’open innovation présentent des risques juridiques spécifiques, en ce sens qu’à la différence des auteurs des logiciels « libres» ou de contenus « libres de droits », l’initiateur d’un projet d’open innovation entend généralement conserver la maîtrise et l’exploitation exclusive des résultats obtenus. Comment réunir et s’approprier des droits de propriété intellectuelle éparpillés entre des concepteurs multiples, parfois situés aux quatre coins du monde ?

Mais la problématique essentielle posée par les projets d’open innovation tient au caractère technique des innovations, lesquelles sont susceptibles de constituer des inventions brevetables ou des savoir-faire, les deux systèmes de protection étant conditionnés au secret sur le plus absolu. Comment concilier une telle exigence de secret avec un système collaboratif, a fortiori s’il est largement ouvert ? Comment s’assurer qu’un contributeur n’a pas divulgué son innovation préalablement à un tiers ?

Par ailleurs, quand les sources sont étrangères, multiples et difficilement contrôlables, comment être certain que les contributions apportées ne sont pas contrefaisantes, ou ne portent pas atteinte aux droits de tiers ?

Approche. Une politique de l’open innovation performante est celle qui assure la préservation et la défense de ses droits de propriété intellectuelle, et fait un bon usage de la propriété intellectuelle pour optimiser ses droits.

Mais c’est aussi une approche équilibrée, offrant aux participants un espoir raisonnable de succès et une contrepartie équitable, ces principes devant guider tant le choix des participants que la contrepartie versée, laquelle peut être financière, mais aussi revêtir d’autres formes.

Il faut cependant tenir compte, à cet égard, des règles contraignantes du droit d’auteur, susceptibles de s’appliquer à toutes les innovations de forme, notamment les créations de mode et de design industriel.

Démarche. Pour être sécurisé sur la plan juridique, un projet d’open innovation requiert une démarche rigoureuse, reposant sur :

  • La définition de processus : tout d’abord, un processus de qualification des innovations concernées, car une invention brevetable n’engendre pas les mêmes problématiques juridiques qu’une forme esthétique ou qu’un nom commercial, étant souligné qu’une même innovation est susceptible de présenter, du point de vue de la propriété intellectuelle, de multiples facettes, ce qui rend sa qualification complexe. Mais il convient également de mettre en place des processus de gestion de la confidentialité, laquelle représente un enjeu majeur de l’open innovation, de traçabilité, d’anticipation des risques de contrefaçon, de vérification.
  • La gestion contractuelle : des contrats en bonne et due forme, et opposables aux contributeurs, doivent gérer les aspects de confidentialité, d’exclusivité, de propriété intellectuelle, de rémunération des contributeurs, de garantie.
  • La mise en place d’une organisation : la mise en place et le suivi d’un projet d’open innovation requiert des ressources appropriées en nombre et en qualité, permettant de réunir les compétences techniques, financières, commerciales, en marketing, et juridiques, dans une organisation cohérente, où les rôles de chacun sont bien définis, et dotée d’une instance de pilotage (tel un comité de l’innovation).
  • L’utilisation de bons outils : la politique de l’open innovation doit pouvoir reposer de bons outils juridiques ; outre les outils contractuels, il peut être mis en place et diffusé des guides pratiques, des tableaux d’équivalence et d’aide à la qualification, des grilles d’analyse, des grilles d’audit, des FAQ, etc., dont l’usage et la compréhension seront facilités par des formations internes.

Bénéficier de l’intelligence collective tout en protégeant et valorisant son patrimoine intellectuel, et ce dans un cadre équitable, le défi juridique lancé par l’open innovation n’est pas simple, mais il ne relève pas de l’impossible.

Laurence Tellier-Loniewski




La FING et l’ouverture des données publiques

La Fondation Internet nouvelle génération ( FING) a publié en janvier 2011 un guide pratique (1) autour de la réutilisation des données publiques qui a pour objectif d’éclairer les acteurs publics et de leurs présenter les initiatives déjà existantes en France comme à l’étranger. Au cours de  ces dernières années, le droit des données publiques a connu une véritable révolution et se voit aujourd’hui reconnaître, sous l’appellation d’ « informations publiques », un statut légal.  La directive du 17 novembre 2003 (2) a été transposée dans notre droit interne par l’ordonnance du 6 juin 2005 (3) qui instaure un véritable droit de réutilisation des informations publiques, à quelque titre que ce soit. Ce droit se traduit notamment par l’obligation, pesant sur les administrations, de cataloguer les données en leur possession et de désigner un responsable de leur diffusion.

Le guide, après avoir rappelé, la notion de donnée publique et la diversité de celles-ci (rapports, études, statistiques, indices, cartes, photographies dans des domaines juridique, culturels, économique, géographique ou encore social etc), met en avant  les opportunités offertes par l’accès aux données publiques qui constituent un vecteur de communication engendrant notamment une floraison d’applications et de services nouveaux. Dans une seconde partie, il se décrit la démarche à entreprendre notamment d’un point de vue juridique.

Le guide énumère les cadres juridiques déjà existants concernant la réutilisation des informations publiques, et axe notamment sa présentation sur  les  licences libres ( licence OdbL, licence ODC-by, licence PDDL 1.0), licences Creative Commons, Licence IP du ministère de la Justice. A titre d’exemple, l’on peut citer la ville de Paris, le 14 décembre 2010, a décidé de diffuser certaines de ses données sous la licence Open Source OdbL (Open Data Base License ), et de construire une infrastructure de mise à disposition de ces données. Ce choix de diffusion de ses données sous licence libre place la ville de Paris dans le prolongement d’initiatives prises par plusieurs grandes villes françaises telles que Brest ou Rennes ou internationales comme San Francisco. 

Il doit cependant être souligné que la compatibilité de ces licences avec la loi, qui ne permet pas d’imposer de restrictions des usages des données publiques, est discutable. Notamment les restrictions et obligations imposées par certaines licences libres ( obligation de rediffuser sous la même licence, obligation de communiquer les améliorations, interdictions de revente commerciales etc) ne semblent pas conformes à la loi, aux termes de laquelle les licences qui fixent les conditions de la réutilisation des informations publiques ne peuvent apporter de restrictions à la réutilisation que pour des motifs d’intérêt général et de façon proportionnée. Les seules conditions s’imposant au licencié étant que les informations publiques ne soient pas altérées, que leur sens ne soit pas dénaturé et que leurs sources et date de leur dernière mise à jour soient mentionnées.

Il convient de rappeler que les administrations peuvent soumettre la réutilisation des informations publiques au versement de redevance. Dans cette hypothèse, une licence doit obligatoirement être conclue. En effet, l’absence de licence type définissant les conditions ne saurait faire obstacle au droit réutilisation : cette réutilisation étant dans ce cas  gratuite (4). Il appartient donc à l’administration de mettre à la disposition des usagers des licences types fixant les conditions de réutilisation des informations publiques. A cet égard, l’APIE, propose notamment deux modèles de licences pour les informations soumises au versement de redevances. Ces licences doivent porter au moins sur les informations faisant l’objet de la réutilisation, leur source et leur date de mise à disposition, le caractère commercial ou non de leur réutilisation, ainsi que sur les droits et obligations du licencié, dont le montant de la redevance et les modalités de son paiement. Toutefois  comme il a été indiqué ci-dessus, elles ne peuvent apporter de restrictions à la réutilisation que pour des motifs d’intérêts généraux et de façon proportionnée.

(1) Guide pratique de janvier 2011
(2) Directive n° 2003/98 CE du 17 novembre 2003 concernant la réutilisation des informations du secteur public
(3) Ordonnance n° 2005-650 du 6 juin 2005 relative à la liberté d’accès aux documents administratifs et à la réutilisation des informations publiques
(4) Circulaire du Premier Ministre n°5156/SG du 29 juin 2006




Diffusion par la Ville de Paris de données publiques sous licence libre

La Ville de Paris a décidé, par délibération du Conseil municipal du 14 décembre 2010, la diffusion de certaines données sous la licence Open Source « Open Data Base License » (ODBL), ainsi que la construction d’une infrastructure de mise à disposition de ces données. Cette décision est motivée par la volonté de la Ville de Paris de porter à la connaissance du public un plus grand nombre de données via les moyens modernes de communication.

Laurence Tellier-Loniewski, Alain Bensoussan Avocats pour Localtis, le 12 janvier 2011




Mise à disposition par la Ville de Paris d’informations publiques sous licence libre

La Ville de Paris, par une délibération de son Conseil du 14 décembre 2010, a décidé de diffuser certaines de ses données sous la licence Open Source  » Open Data Base License  » (ODBL) et de construire une infrastructure de mise à disposition de ces données. Sont donc exclues les données ne constituant pas des  » informations publiques « .

Laurence Tellier-Loniewski, Alain Bensoussan Avocats pour Localtis.info, le 12 janvier 2011




la preuve de la contrefaçon de logiciel

Expertises judiciaires ICE et Audit

Administration de la preuve

La contrefaçon de logiciel : une question de preuve avant tout !

En matière de propriété intellectuelle, toute contrefaçon de logiciel suppose que soient démontrées des ressemblances touchant à l’écriture, aux instructions et algorithmes, aux schémas de base de données, à la conception d’ensemble etc. Ces ressemblances ne pourront être déterminées qu’après analyse du programme contrefaisant, laquelle ne sera valablement effectuée qu’après mise en oeuvre d’une procédure judiciaire de saisie contrefaçon permettant de conserver auprès du tribunal les éléments indispensables à la détermination de l’infraction. L’expert judiciaire dispose, pour pouvoir établir la contrefaçon d’un certain nombre de moyens. Outre la comparaison entre les instructions des deux programmes, il pourra identifier une éventuelle contrefaçon par le biais d’empreinte (1). La contrefaçon ne peut être établie qu’au vu des similitudes entre les deux programmes. Elle ne résulte pas exclusivement d’une copie servile ou quasi-servile, mais aussi de modifications ou d’évolutions du code original.

Le Code de la propriété intellectuelle n’impose aucun dépôt à l’auteur pour lui permettre de faire valoir ses droits. Toutefois, un dépôt chez un tiers (Agence pour la Protection des Programmes, Logitas, etc.) permet de rapporter la preuve d’une antériorité. Le procès-verbal de dépôt fait généralement état de la date et l’heure de dépôt et un descriptif succinct du programme peut être effectué sur la demande de dépôt conservée par l’organisme. Il est également possible de pré constituer des preuves en définissant des procédures internes permettant d’assurer la traçabilité des cycles de développements d’un logiciel. Ce dispositif permet de se protéger contre d’éventuelles allégations de contrefaçon de tiers et a contrario, d’assurer une protection opérationnelle de ses propres développements. Enfin, il peut être intéressant de faire réaliser un diagnostic de propriété intellectuelle que ce soit dans le cadre de l’activité courante de l’entreprise ou dans les cas plus spécifiques d’acquisition ou de fusion afin d’établir la consistance du patrimoine intellectuel de l’entreprise, notamment lorsque des codes « Open source » ont été utilisés à l’excès.

Paru dans la JTIT n°54-55/2006 p.2

(Mise en ligne Juillet/Août 2006)




Mise à disposition par la Ville de Rennes d’informations publiques en open source

La ville de Rennes a décidé la mise à disposition gratuite des données publiques du réseau de transport Rennes Métropole, ainsi que des données d’informations pratiques géolocalisées de 1.500 organismes publics et associatifs, accessibles depuis un portail en ligne. Cette initiative vise à donner accès notamment aux développeurs de services innovants à des données au format libre « creative commons » en vue de permettre le développement de nouveaux usages destinés à répondre aux besoins et attentes des usagers.

Laurence Tellier-Loniewski pour Localtis, le 16 mars 2010




Propositions de l’Afdel en faveur du logiciel

Marchés publics

Informatique

Propositions de l’Afdel en faveur de l’industrie du logiciel

Développées lors des Assises du logiciel dans le cadre des Assises du numériques, les propositions de l’Afdel (1) en faveur de l’industrie du logiciel invitent le gouvernement à faire de l’industrie du logiciel une priorité publique. Elles s’inscrivent sur les 4 axes ci-après autour de 16 mesures :

  • 1er axe : Faire de l’industrie du logiciel une priorité d’action publique
  • Parmi les 5 mesures qui s’articulent autour de ce premier axe de proposition de l’Afdel, les mesures 4 et 5 vise à mieux adapter les aides à l’innovation d’une part et à adapter la normalisation à l’innovation logicielle d’autre part. L’Afdel recommande en effet par parvenir à la réalisation des objectifs correspondants aux mesures 4 et 5 de reporter la réduction des avances remboursables à la fin des projets de recherche seulement en cas d’échec. Elle préconise également une nouvelle définition de « l’assiette » des investissements de R&D, consistant à prendre en compte à 100%, l’activité des personnes affectées à la R&D chez un éditeur de logiciel et d’inclure dans la liste des personnes affectées à la R&D, les profils de poste affecté à la R&D qui ne sont pas nécessairement des ingénieurs. L’association considère également que les processus de normalisation sont trop long par rapport à l’évolution des technologies et propose donc l’attribution d’aide des PME en contrepartie de leur participation aux travaux de normalisation.

  • 2ème axe : Soutenir le développement à l’international des sociétés éditrices de logiciels
  • Cet axe comprend 3 mesures. Après avoir dressé le constat de la difficulté des PME-PMI françaises en matière de développement à l’international, la France ne représentant que 5% du marché potentiel mondial du logiciel. L’Afdel recommande la création d’un statut spécifique pour les sociétés éditrices de logiciel afin de mieux identifier et valoriser l’industrie du logiciel. Elle propose également, nonobstant les nombreuses aides et mesures d’incitation existantes, la mise en place de financement spécifique pour l’accompagnement de l’implantation de filiale d’une société éditrice de logiciel à l’étranger.

  • 3ème axe : Renforcer les moyens de protection de la propriété intellectuelle du logiciel
  • Quatre mesures sont proposées par l’Afdel pour cet axe :

    • une clarification du régime de protection par le brevet des inventions mises en œuvre par ordinateur. Tout en refutant militer pour un élargissement du domaine des inventions brevetables, l’Afdel souhaite la mise en œuvre par les institutions communautaires d’une stratégie audacieuse pour la brevetabilité des inventions mises en œuvre par ordinateur afin que seules les inventions ayant « subies un examen rigoureux » permettant de vérifier les critères de brevetabilité, puissent être protégés par la voie du brevet ;
    • dans le prolongement de la clarification ci-dessus, la création d’un brevet communautaire, permettant là aussi une réduction des coûts de traduction de tout brevet européen délivré par l’Office Européen des Brevets (OEB) dans les autres langues nationales européennes ;
    • la réduction de 50% des taxes perçues par l’OEB auprès des PME, au motif que le coût des taxes et en particulier les frais d’obtention d’un brevet européen sont difficilement supportables pour une PME qui souhaite déposer plusieurs brevets ;
    • la création et mise en place d’une juridiction paneuropéenne commune compétente pour les litiges en matière de brevets, afin de renforcer l’harmonisation jurisprudentielle européenne, notamment en ce qui concerne l’interprétation des revendications.
  • 4ème axe : Faciliter l’accès des éditeurs de logiciels aux marchés publics
  • Ce dernier axe de proposition compte pas moins de 4 mesures importantes proposées par l’Afdel :

    • la simplification de l’accès aux marchés publics aux PME (mesure n° 13) ;
    • la réservation de 15% des marchés publics logiciels aux PME (mesure n° 14) ;
    • la refonte du référentiel général d’interopérabilité (RGI) dans le cadre d’une nouvelle gouvernance (mesure n° 16).

    La mesure n° 13 suggère la rédaction d’un projet de modification du chapitre VII (cahier des clauses administratives générales applicables aux marchés publics de Fournitures Courantes et de Services) consistant dans la révision ou modification des éléments obsolètes et/ou inadaptés au marché de l’informatique publique ainsi que l’intégration de nouvelles dispositions relatives aux progiciels, leurs évolutions, les responsabilités de la personne publique. Signalons que les technologies de l’information et de la communication auront bientôt leur propre référentiel contractuel, le CCAG-TIC. Ce projet de texte vient d’être ouvert à la concertation publique jusqu’au 29 septembre 2008 pour une adoption prévue avant fin 2008.

    Rappelons que depuis l’adoption de l’article 7 de la loi relative à la modernisation de l’économie qui prévoit à titre expérimental et pour une période de 5 ans à partir de la date de publication de la loi, les acheteurs soumis au code des marchés publics pourront «réserver une partie de leurs marchés de haute technologie (…) d’un montant inférieur aux seuils des procédures formalisées, aux sociétés innovantes », l’Afdel souligne que le montant total de ces marchés ne pourra être supérieur à 15% du montant annuel moyen des marchés de haute technologie. L’Afdel souhaite que cette réservation de 15% des marchés publics logiciels aux PME qui s’inspire du Small Business Act américain puisse être pérennisée dans la législation européenne.

    Le Référentiel Général d’Interopérabilité qui s’impose à tout système d’information aux termes de l’ordonnance du 8 décembre 2005, définit des critères permettant de s’assurer de la conformité des offres des prestataires. L’Afdel met en avant les protestations des éditeurs de logiciels et les conséquences résultants de la mise en œuvre du RGI sur le marché des logiciels, et plaide en faveur d’un cadre de prescriptions se « référant exclusivement aux normalisations ISO à l’exclusion de toute référence – explicite ou implicite – à l’open source ».

    Nous ne partageons pas les objections de l’Afdel concernant l’application du RGI et nous aurons l’occasion de revenir dans le cadre d’un prochain article de fond sur les propositions de l’association relatives au Référentiel Général d’Interopérabilité.

    Propositions Afdel

    (1) Créée en 2005, l’ Association Française des Editeurs de Logiciels compte aujourd’hui plus de 150 membres avec la vocation d’être le porte-parole de l’industrie du logiciel en France.

    (Mise en ligne Septembre 2008)

    Autres brèves




    Propositions de l’Afdel pour l’industrie du logiciel

    Développées lors des Assises du logiciel dans le cadre des Assises du numériques, les propositions de l’Afdel (1) en faveur de l’industrie du logiciel invitent le gouvernement à faire de l’industrie du logiciel, à terme, l’une des priorités publiques. Elles s’articulent plus particulièrement autour des quatre axes ci-après définis.

    • 1er axe : Faire de l’industrie du logiciel une priorité d’action publiqueParmi les 5 mesures qui s’articulent autour de ce premier axe de proposition de l’Afdel, les mesures 4 et 5 vise à mieux adapter les aides à l’innovation d’une part et à adapter la normalisation à l’innovation logicielle d’autre part. L’Afdel recommande en effet par parvenir à la réalisation des objectifs correspondants aux mesures 4 et 5 de reporter la réduction des avances remboursables à la fin des projets de recherche seulement en cas d’échec. Elle préconise également une nouvelle définition de « l’assiette » des investissements de R&D, consistant à prendre en compte à 100%, l’activité des personnes affectées à la R&D chez un éditeur de logiciel et d’inclure dans la liste des personnes affectées à la R&D, les profils de poste affecté à la R&D qui ne sont pas nécessairement des ingénieurs. L’association considère également que les processus de normalisation sont trop long par rapport à l’évolution des technologies et propose donc l’attribution d’aide des PME en contrepartie de leur participation aux travaux de normalisation.
    • 2ème axe : Soutenir le développement à l’international des sociétés éditrices de logicielsCet axe comprend 3 mesures. Après avoir dressé le constat de la difficulté des PME-PMI françaises en matière de développement à l’international, la France ne représentant que 5% du marché potentiel mondial du logiciel. L’Afdel recommande la création d’un statut spécifique pour les sociétés éditrices de logiciel afin de mieux identifier et valoriser l’industrie du logiciel. Elle propose également, nonobstant les nombreuses aides et mesures d’incitation existantes, la mise en place de financement spécifique pour l’accompagnement de l’implantation de filiale d’une société éditrice de logiciel à l’étranger.
    • 3ème axe : Renforcer les moyens de protection de la propriété intellectuelle du logicielQuatre mesures sont proposées par l’Afdel pour cet axe :
    • une clarification du régime de protection par le brevet des inventions mises en œuvre par ordinateur. Tout en refutant militer pour un élargissement du domaine des inventions brevetables, l’Afdel souhaite la mise en œuvre par les institutions communautaires d’une stratégie audacieuse pour la brevetabilité des inventions mises en œuvre par ordinateur afin que seules les inventions ayant « subies un examen rigoureux » permettant de vérifier les critères de brevetabilité, puissent être protégés par la voie du brevet ;
    • dans le prolongement de la clarification ci-dessus, la création d’un brevet communautaire, permettant là aussi une réduction des coûts de traduction de tout brevet européen délivré par l’Office Européen des Brevets (OEB) dans les autres langues nationales européennes ;
    • la réduction de 50% des taxes perçues par l’OEB auprès des PME, au motif que le coût des taxes et en particulier les frais d’obtention d’un brevet européen sont difficilement supportables pour une PME qui souhaite déposer plusieurs brevets ;
    • la création et mise en place d’une juridiction paneuropéenne commune compétente pour les litiges en matière de brevets, afin de renforcer l’harmonisation jurisprudentielle européenne, notamment en ce qui concerne l’interprétation des revendications.
    • 4ème axe : Faciliter l’accès des éditeurs de logiciels aux marchés publicsCe dernier axe de proposition compte pas moins de 4 mesures importantes proposées par l’Afdel :
    • la simplification de l’accès aux marchés publics aux PME (mesure n° 13) ;
    • la réservation de 15% des marchés publics logiciels aux PME (mesure n° 14) ;
    • la refonte du référentiel général d’interopérabilité (RGI) dans le cadre d’une nouvelle gouvernance (mesure n° 16).

    La mesure n° 13 suggère la rédaction d’un projet de modification du chapitre VII (cahier des clauses administratives générales applicables aux marchés publics de Fournitures Courantes et de Services) consistant dans la révision ou modification des éléments obsolètes et/ou inadaptés au marché de l’informatique publique ainsi que l’intégration de nouvelles dispositions relatives aux progiciels, leurs évolutions, les responsabilités de la personne publique. Signalons que les technologies de l’information et de la communication auront bientôt leur propre référentiel contractuel, le CCAG-TIC. Ce projet de texte vient d’être ouvert à la concertation publique jusqu’au 29 septembre 2008 pour une adoption prévue avant fin 2008.

    Rappelons que depuis l’adoption de l’article 7 de la loi relative à la modernisation de l’économie qui prévoit à titre expérimental et pour une période de 5 ans à partir de la date de publication de la loi, les acheteurs soumis au code des marchés publics pourront «réserver une partie de leurs marchés de haute technologie (…) d’un montant inférieur aux seuils des procédures formalisées, aux sociétés innovantes », l’Afdel souligne que le montant total de ces marchés ne pourra être supérieur à 15% du montant annuel moyen des marchés de haute technologie. L’Afdel souhaite que cette réservation de 15% des marchés publics logiciels aux PME qui s’inspire du Small Business Act américain puisse être pérennisée dans la législation européenne.

    Le Référentiel Général d’Interopérabilité qui s’impose à tout système d’information aux termes de l’ordonnance du 8 décembre 2005, définit des critères permettant de s’assurer de la conformité des offres des prestataires. L’Afdel met en avant les protestations des éditeurs de logiciels et les conséquences résultants de la mise en œuvre du RGI sur le marché des logiciels, et plaide en faveur d’un cadre de prescriptions se « référant exclusivement aux normalisations ISO à l’exclusion de toute référence – explicite ou implicite – à l’open source ».

    Nous ne partageons pas les objections de l’Afdel concernant l’application du RGI et nous aurons l’occasion de revenir dans le cadre d’un prochain article de fond sur les propositions de l’association relatives au Référentiel Général d’Interopérabilité.

    Propositions Afdel

    (1) Créée en 2005, l’ Association Française des Editeurs de Logiciels compte aujourd’hui plus de 150 membres avec la vocation d’être le porte-parole de l’industrie du logiciel en France.




    Contrefaçon de logiciel : une question de preuve avant tout !

    Informatique
    Atteintes au droit d’auteur

    La contrefaçon de logiciel : une question de preuve avant tout !

    En matière de propriété intellectuelle, toute contrefaçon de logiciel suppose que soient démontrées des ressemblances touchant à l’écriture, aux instructions et algorithmes, aux schémas de base de données, à la conception d’ensemble etc. Ces ressemblances ne pourront être déterminées qu’après analyse du programme contrefaisant, laquelle ne sera valablement effectuée qu’après mise en oeuvre d’une procédure judiciaire de saisie contrefaçon permettant de conserver auprès du tribunal les éléments indispensables à la détermination de l’infraction. L’expert judiciaire dispose, pour pouvoir établir la contrefaçon d’un certain nombre de moyens. Outre la comparaison entre les instructions des deux programmes, il pourra identifier une éventuelle contrefaçon par le biais d’empreinte (1). La contrefaçon ne peut être établie qu’au vu des similitudes entre les deux programmes. Elle ne résulte pas exclusivement d’une copie servile ou quasi-servile, mais aussi de modifications ou d’évolutions du code original.

    Le Code de la propriété intellectuelle n’impose aucun dépôt à l’auteur pour lui permettre de faire valoir ses droits. Toutefois, un dépôt chez un tiers (Agence pour la Protection des Programmes, Logitas, etc.) permet de rapporter la preuve d’une antériorité. Le procès-verbal de dépôt fait généralement état de la date et l’heure de dépôt et un descriptif succinct du programme peut être effectué sur la demande de dépôt conservée par l’organisme. Il est également possible de pré constituer des preuves en définissant des procédures internes permettant d’assurer la traçabilité des cycles de développements d’un logiciel. Ce dispositif permet de se protéger contre d’éventuelles allégations de contrefaçon de tiers et a contrario, d’assurer une protection opérationnelle de ses propres développements. Enfin, il peut être intéressant de faire réaliser un diagnostic de propriété intellectuelle que ce soit dans le cadre de l’activité courante de l’entreprise ou dans les cas plus spécifiques d’acquisition ou de fusion afin d’établir la consistance du patrimoine intellectuel de l’entreprise, notamment lorsque des codes « Open source » ont été utilisés à l’excès.

    Paru dans la JTIT n°54-55/2006 p.2

    (Mise en ligne Juillet-Août 2006)




    comment établir une contrefaçon de logiciel

    Contentieux informatique

    Atteintes au droit d’auteur

    Comment établir une contrefaçon de logiciel ?

    En matière de propriété intellectuelle, toute contrefaçon de logiciel suppose que soient démontrées des ressemblances touchant à l’écriture, aux instructions et algorithmes, aux schémas de base de données, à la conception d’ensemble etc. Ces ressemblances ne pourront être déterminées qu’après analyse du programme contrefaisant, laquelle ne sera valablement effectuée qu’après mise en oeuvre d’une procédure judiciaire de saisie contrefaçon permettant de conserver auprès du tribunal les éléments indispensables à la détermination de l’infraction. L’expert judiciaire dispose, pour pouvoir établir la contrefaçon d’un certain nombre de moyens. Outre la comparaison entre les instructions des deux programmes, il pourra identifier une éventuelle contrefaçon par le biais d’empreinte (1). La contrefaçon ne peut être établie qu’au vu des similitudes entre les deux programmes. Elle ne résulte pas exclusivement d’une copie servile ou quasi-servile, mais aussi de modifications ou d’évolutions du code original.

    Le Code de la propriété intellectuelle n’impose aucun dépôt à l’auteur pour lui permettre de faire valoir ses droits. Toutefois, un dépôt chez un tiers (Agence pour la Protection des Programmes, Logitas, etc.) permet de rapporter la preuve d’une antériorité. Le procès-verbal de dépôt fait généralement état de la date et l’heure de dépôt et un descriptif succinct du programme peut être effectué sur la demande de dépôt conservée par l’organisme. Il est également possible de pré constituer des preuves en définissant des procédures internes permettant d’assurer la traçabilité des cycles de développements d’un logiciel. Ce dispositif permet de se protéger contre d’éventuelles allégations de contrefaçon de tiers et a contrario, d’assurer une protection opérationnelle de ses propres développements. Enfin, il peut être intéressant de faire réaliser un diagnostic de propriété intellectuelle que ce soit dans le cadre de l’activité courante de l’entreprise ou dans les cas plus spécifiques d’acquisition ou de fusion afin d’établir la consistance du patrimoine intellectuel de l’entreprise, notamment lorsque des codes « Open source » ont été utilisés à l’excès.

    Paru dans la JTIT n°54-55/2006 p.2

    (Mise en ligne Juillet-Août 2006)




    la contrefacon logiciel une question de preuve avant tout

    Contentieux informatique

    Administration de la preuve

    La contrefaçon de logiciel : une question de preuve avant tout !

    En matière de propriété intellectuelle, toute contrefaçon de logiciel suppose que soient démontrées des ressemblances touchant à l’écriture, aux instructions et algorithmes, aux schémas de base de données, à la conception d’ensemble etc. Ces ressemblances ne pourront être déterminées qu’après analyse du programme contrefaisant, laquelle ne sera valablement effectuée qu’après mise en oeuvre d’une procédure judiciaire de saisie contrefaçon permettant de conserver auprès du tribunal les éléments indispensables à la détermination de l’infraction. L’expert judiciaire dispose, pour pouvoir établir la contrefaçon d’un certain nombre de moyens. Outre la comparaison entre les instructions des deux programmes, il pourra identifier une éventuelle contrefaçon par le biais d’empreinte (1). La contrefaçon ne peut être établie qu’au vu des similitudes entre les deux programmes. Elle ne résulte pas exclusivement d’une copie servile ou quasi-servile, mais aussi de modifications ou d’évolutions du code original.

    Le Code de la propriété intellectuelle n’impose aucun dépôt à l’auteur pour lui permettre de faire valoir ses droits. Toutefois, un dépôt chez un tiers (Agence pour la Protection des Programmes, Logitas, etc.) permet de rapporter la preuve d’une antériorité. Le procès-verbal de dépôt fait généralement état de la date et l’heure de dépôt et un descriptif succinct du programme peut être effectué sur la demande de dépôt conservée par l’organisme. Il est également possible de pré constituer des preuves en définissant des procédures internes permettant d’assurer la traçabilité des cycles de développements d’un logiciel. Ce dispositif permet de se protéger contre d’éventuelles allégations de contrefaçon de tiers et a contrario, d’assurer une protection opérationnelle de ses propres développements. Enfin, il peut être intéressant de faire réaliser un diagnostic de propriété intellectuelle que ce soit dans le cadre de l’activité courante de l’entreprise ou dans les cas plus spécifiques d’acquisition ou de fusion afin d’établir la consistance du patrimoine intellectuel de l’entreprise, notamment lorsque des codes « Open source » ont été utilisés à l’excès.

    Paru dans la JTIT n°54-55/2006 p.2

    (Mise en ligne Juillet-Août 2006)




    Propositions de l’Afdel en faveur de l’industrie du logiciel

    Propriété littéraire et artistique

    Logiciels et multimédia

    Propositions de l’Afdel en faveur de l’industrie du logiciel

    Développées lors des Assises du logiciel dans le cadre des Assises du numériques, les propositions de l’Afdel (1) en faveur de l’industrie du logiciel invitent le gouvernement à faire de l’industrie du logiciel une priorité publique. Elles s’inscrivent sur les 4 axes ci-après autour de 16 mesures :

  • 1er axe : Faire de l’industrie du logiciel une priorité d’action publique
  • Parmi les 5 mesures qui s’articulent autour de ce premier axe de proposition de l’Afdel, les mesures 4 et 5 vise à mieux adapter les aides à l’innovation d’une part et à adapter la normalisation à l’innovation logicielle d’autre part. L’Afdel recommande en effet par parvenir à la réalisation des objectifs correspondants aux mesures 4 et 5 de reporter la réduction des avances remboursables à la fin des projets de recherche seulement en cas d’échec. Elle préconise également une nouvelle définition de « l’assiette » des investissements de R&D, consistant à prendre en compte à 100%, l’activité des personnes affectées à la R&D chez un éditeur de logiciel et d’inclure dans la liste des personnes affectées à la R&D, les profils de poste affecté à la R&D qui ne sont pas nécessairement des ingénieurs. L’association considère également que les processus de normalisation sont trop long par rapport à l’évolution des technologies et propose donc l’attribution d’aide des PME en contrepartie de leur participation aux travaux de normalisation.

  • 2ème axe : Soutenir le développement à l’international des sociétés éditrices de logiciels
  • Cet axe comprend 3 mesures. Après avoir dressé le constat de la difficulté des PME-PMI françaises en matière de développement à l’international, la France ne représentant que 5% du marché potentiel mondial du logiciel. L’Afdel recommande la création d’un statut spécifique pour les sociétés éditrices de logiciel afin de mieux identifier et valoriser l’industrie du logiciel. Elle propose également, nonobstant les nombreuses aides et mesures d’incitation existantes, la mise en place de financement spécifique pour l’accompagnement de l’implantation de filiale d’une société éditrice de logiciel à l’étranger.

  • 3ème axe : Renforcer les moyens de protection de la propriété intellectuelle du logiciel
  • Quatre mesures sont proposées par l’Afdel pour cet axe :

    • une clarification du régime de protection par le brevet des inventions mises en œuvre par ordinateur. Tout en refutant militer pour un élargissement du domaine des inventions brevetables, l’Afdel souhaite la mise en œuvre par les institutions communautaires d’une stratégie audacieuse pour la brevetabilité des inventions mises en œuvre par ordinateur afin que seules les inventions ayant « subies un examen rigoureux » permettant de vérifier les critères de brevetabilité, puissent être protégés par la voie du brevet ;
    • dans le prolongement de la clarification ci-dessus, la création d’un brevet communautaire, permettant là aussi une réduction des coûts de traduction de tout brevet européen délivré par l’Office Européen des Brevets (OEB) dans les autres langues nationales européennes ;
    • la réduction de 50% des taxes perçues par l’OEB auprès des PME, au motif que le coût des taxes et en particulier les frais d’obtention d’un brevet européen sont difficilement supportables pour une PME qui souhaite déposer plusieurs brevets ;
    • la création et mise en place d’une juridiction paneuropéenne commune compétente pour les litiges en matière de brevets, afin de renforcer l’harmonisation jurisprudentielle européenne, notamment en ce qui concerne l’interprétation des revendications.
  • 4ème axe : Faciliter l’accès des éditeurs de logiciels aux marchés publics
  • Ce dernier axe de proposition compte pas moins de 4 mesures importantes proposées par l’Afdel :

    • la simplification de l’accès aux marchés publics aux PME (mesure n° 13) ;
    • la réservation de 15% des marchés publics logiciels aux PME (mesure n° 14) ;
    • la refonte du référentiel général d’interopérabilité (RGI) dans le cadre d’une nouvelle gouvernance (mesure n° 16).

    La mesure n° 13 suggère la rédaction d’un projet de modification du chapitre VII (cahier des clauses administratives générales applicables aux marchés publics de Fournitures Courantes et de Services) consistant dans la révision ou modification des éléments obsolètes et/ou inadaptés au marché de l’informatique publique ainsi que l’intégration de nouvelles dispositions relatives aux progiciels, leurs évolutions, les responsabilités de la personne publique. Signalons que les technologies de l’information et de la communication auront bientôt leur propre référentiel contractuel, le CCAG-TIC. Ce projet de texte vient d’être ouvert à la concertation publique jusqu’au 29 septembre 2008 pour une adoption prévue avant fin 2008.

    Rappelons que depuis l’adoption de l’article 7 de la loi relative à la modernisation de l’économie qui prévoit à titre expérimental et pour une période de 5 ans à partir de la date de publication de la loi, les acheteurs soumis au code des marchés publics pourront «réserver une partie de leurs marchés de haute technologie (…) d’un montant inférieur aux seuils des procédures formalisées, aux sociétés innovantes », l’Afdel souligne que le montant total de ces marchés ne pourra être supérieur à 15% du montant annuel moyen des marchés de haute technologie. L’Afdel souhaite que cette réservation de 15% des marchés publics logiciels aux PME qui s’inspire du Small Business Act américain puisse être pérennisée dans la législation européenne.

    Le Référentiel Général d’Interopérabilité qui s’impose à tout système d’information aux termes de l’ordonnance du 8 décembre 2005, définit des critères permettant de s’assurer de la conformité des offres des prestataires. L’Afdel met en avant les protestations des éditeurs de logiciels et les conséquences résultants de la mise en œuvre du RGI sur le marché des logiciels, et plaide en faveur d’un cadre de prescriptions se « référant exclusivement aux normalisations ISO à l’exclusion de toute référence – explicite ou implicite – à l’open source ».

    Nous ne partageons pas les objections de l’Afdel concernant l’application du RGI et nous aurons l’occasion de revenir dans le cadre d’un prochain article de fond sur les propositions de l’association relatives au Référentiel Général d’Interopérabilité.

    Propositions Afdel

    (1) Créée en 2005, l’ Association Française des Editeurs de Logiciels compte aujourd’hui plus de 150 membres avec la vocation d’être le porte-parole de l’industrie du logiciel en France.

    (Mise en ligne Septembre 2008)




    Petit-déjeuner sur les implications juridiques de l’utilisation de code Open Source

    Evénement – Petit-déjeuner débat

    Le petit-déjeuner débat a eu lieu le 4 février 2009 dans nos locaux.

    Laurence Tellier-Loniewski a animé, aux côtés de Jean-Pierre Bigot, Président de ESALAB et Expert judiciaire et Hervé Guyomard, Black Duck Software, un petit-déjeuner débat consacré aux implications juridiques de l’utilisation de code Open Source.

    Aujourd’hui, nombreux sont les ingénieurs qui, à chaque étape du développement, réutilisent des composants logiciels Open Source, de tierce partie ou propriétaires. Réutiliser du code est plus économique que de le réécrire et s’avère plus rapide et plus fiable.

    Cependant, l’utilisation de code Open Source ou de tierce partie n’est pas sans risque pour votre entreprise et engendre ses propres difficultés de gestion. L’utilisation non maîtrisée de codes développés en externe peut aisément compromettre les droits de propriété intellectuelle, induire des obligations de redevances inconnues ou introduire des risques de sécurité cachés. La gestion et la maintenance d’un logiciel peuvent également être rendues plus difficiles par la diversité de l’origine de ses composants.

    Quels sont les risques et les bénéfices liés à la réutilisation de code Open Source ? Comment prévenir les risques ? Comment rediffuser un logiciel intégrant des composants libres en toute sécurité ? Quelles sont aujourd’hui les principales licences ? Quels sont les droits qu’elles accordent et leurs limites ? Quels audits mener pour identifier la présence de composants libres ? Quels sont les outils, méthodes et état de l’art ? etc.

    Nous vous avons proposé, au cours d’un petit-déjeuner débat, d’apporter des réponses à toutes ces questions.

    (Lire le compte rendu)




    un logiciel d'extraction automatique de données sur internet

    Propriété intellectuelle

    Logiciels et multimédia

    Propositions de l’Afdel en faveur de l’industrie du logiciel

    Développées lors des Assises du logiciel dans le cadre des Assises du numériques, les propositions de l’Afdel (1) en faveur de l’industrie du logiciel invitent le gouvernement à faire de l’industrie du logiciel une priorité publique. Elles s’inscrivent sur les 4 axes ci-après autour de 16 mesures :

  • 1er axe : Faire de l’industrie du logiciel une priorité d’action publique
  • Parmi les 5 mesures qui s’articulent autour de ce premier axe de proposition de l’Afdel, les mesures 4 et 5 vise à mieux adapter les aides à l’innovation d’une part et à adapter la normalisation à l’innovation logicielle d’autre part. L’Afdel recommande en effet par parvenir à la réalisation des objectifs correspondants aux mesures 4 et 5 de reporter la réduction des avances remboursables à la fin des projets de recherche seulement en cas d’échec. Elle préconise également une nouvelle définition de « l’assiette » des investissements de R&D, consistant à prendre en compte à 100%, l’activité des personnes affectées à la R&D chez un éditeur de logiciel et d’inclure dans la liste des personnes affectées à la R&D, les profils de poste affecté à la R&D qui ne sont pas nécessairement des ingénieurs. L’association considère également que les processus de normalisation sont trop long par rapport à l’évolution des technologies et propose donc l’attribution d’aide des PME en contrepartie de leur participation aux travaux de normalisation.

  • 2ème axe : Soutenir le développement à l’international des sociétés éditrices de logiciels
  • Cet axe comprend 3 mesures. Après avoir dressé le constat de la difficulté des PME-PMI françaises en matière de développement à l’international, la France ne représentant que 5% du marché potentiel mondial du logiciel. L’Afdel recommande la création d’un statut spécifique pour les sociétés éditrices de logiciel afin de mieux identifier et valoriser l’industrie du logiciel. Elle propose également, nonobstant les nombreuses aides et mesures d’incitation existantes, la mise en place de financement spécifique pour l’accompagnement de l’implantation de filiale d’une société éditrice de logiciel à l’étranger.

  • 3ème axe : Renforcer les moyens de protection de la propriété intellectuelle du logiciel
  • Quatre mesures sont proposées par l’Afdel pour cet axe :

    • une clarification du régime de protection par le brevet des inventions mises en œuvre par ordinateur. Tout en refutant militer pour un élargissement du domaine des inventions brevetables, l’Afdel souhaite la mise en œuvre par les institutions communautaires d’une stratégie audacieuse pour la brevetabilité des inventions mises en œuvre par ordinateur afin que seules les inventions ayant « subies un examen rigoureux » permettant de vérifier les critères de brevetabilité, puissent être protégés par la voie du brevet ;
    • dans le prolongement de la clarification ci-dessus, la création d’un brevet communautaire, permettant là aussi une réduction des coûts de traduction de tout brevet européen délivré par l’Office Européen des Brevets (OEB) dans les autres langues nationales européennes ;
    • la réduction de 50% des taxes perçues par l’OEB auprès des PME, au motif que le coût des taxes et en particulier les frais d’obtention d’un brevet européen sont difficilement supportables pour une PME qui souhaite déposer plusieurs brevets ;
    • la création et mise en place d’une juridiction paneuropéenne commune compétente pour les litiges en matière de brevets, afin de renforcer l’harmonisation jurisprudentielle européenne, notamment en ce qui concerne l’interprétation des revendications.
  • 4ème axe : Faciliter l’accès des éditeurs de logiciels aux marchés publics
  • Ce dernier axe de proposition compte pas moins de 4 mesures importantes proposées par l’Afdel :

    • la simplification de l’accès aux marchés publics aux PME (mesure n° 13) ;
    • la réservation de 15% des marchés publics logiciels aux PME (mesure n° 14) ;
    • la refonte du référentiel général d’interopérabilité (RGI) dans le cadre d’une nouvelle gouvernance (mesure n° 16).

    La mesure n° 13 suggère la rédaction d’un projet de modification du chapitre VII (cahier des clauses administratives générales applicables aux marchés publics de Fournitures Courantes et de Services) consistant dans la révision ou modification des éléments obsolètes et/ou inadaptés au marché de l’informatique publique ainsi que l’intégration de nouvelles dispositions relatives aux progiciels, leurs évolutions, les responsabilités de la personne publique. Signalons que les technologies de l’information et de la communication auront bientôt leur propre référentiel contractuel, le CCAG-TIC. Ce projet de texte vient d’être ouvert à la concertation publique jusqu’au 29 septembre 2008 pour une adoption prévue avant fin 2008.

    Rappelons que depuis l’adoption de l’article 7 de la loi relative à la modernisation de l’économie qui prévoit à titre expérimental et pour une période de 5 ans à partir de la date de publication de la loi, les acheteurs soumis au code des marchés publics pourront «réserver une partie de leurs marchés de haute technologie (…) d’un montant inférieur aux seuils des procédures formalisées, aux sociétés innovantes », l’Afdel souligne que le montant total de ces marchés ne pourra être supérieur à 15% du montant annuel moyen des marchés de haute technologie. L’Afdel souhaite que cette réservation de 15% des marchés publics logiciels aux PME qui s’inspire du Small Business Act américain puisse être pérennisée dans la législation européenne.

    Le Référentiel Général d’Interopérabilité qui s’impose à tout système d’information aux termes de l’ordonnance du 8 décembre 2005, définit des critères permettant de s’assurer de la conformité des offres des prestataires. L’Afdel met en avant les protestations des éditeurs de logiciels et les conséquences résultants de la mise en œuvre du RGI sur le marché des logiciels, et plaide en faveur d’un cadre de prescriptions se « référant exclusivement aux normalisations ISO à l’exclusion de toute référence – explicite ou implicite – à l’open source ».

    Nous ne partageons pas les objections de l’Afdel concernant l’application du RGI et nous aurons l’occasion de revenir dans le cadre d’un prochain article de fond sur les propositions de l’association relatives au Référentiel Général d’Interopérabilité.

    Propositions Afdel

    (1) Créée en 2005, l’ Association Française des Editeurs de Logiciels compte aujourd’hui plus de 150 membres avec la vocation d’être le porte-parole de l’industrie du logiciel en France.

    (Mise en ligne Septembre 2008)

    Autres brèves