Cahiers 2012 › Interopérabilité › Moyens de l'interopérabilité et insécurité juridique
Le mercredi 7 mars 2012, 16:42 - Lien permanent
La délivrance des informations essentielles à l'interopérabilité par l'éditeur est la condition sine qua non, dans des cycles d'innovation particulièrement courts, au développement et à la mise sur le marché d'un logiciel indépendant interopérant avec un autre. Mais les grands éditeurs de logiciels, lorsqu'ils y consentent, soumettent trop souvent la délivrance de ces informations à des licences abusives. Les autorités de régulation de la concurrence ne parviennent pas à changer les choses.
Lorsque l'interopérabilité n'est pas assurée par la mise à disposition des informations essentielles par les concepteurs du logiciel, elle peut être légalement mise en place par les techniques d'ingénierie inverse ou de décompilation. Cela demeure cependant des solutions limitées et mises à mal par des dispositions législatives contradictoires. La multiplication des revendications de brevets ou de secret sur les protocoles, les formats, et les méthodes intellectuelles nécessaires à la mise en œuvre de l'interopérabilité trouble encore davantage les débats, tout comme la tentative de certains industriels d'imposer que seuls des logiciels certifiés par leur consortium puissent interopérer avec leurs produits.
Cette analyse fait partie du cahier Interopérabilité de candidats.fr, à l'occasion de la campagne présidentielle 2012.
L'obtention des informations essentielles à l'interopérabilité par ses propres moyens est source d'insécurité juridique
L'obtention des informations essentielles par des techniques complexes et coûteuses
En cas de rétention des informations essentielles, c'est-à-dire que, d'après la loi, l'éditeur n'a pas donné « facilement et rapidement accès »1 à ces informations, il est possible d'utiliser les techniques d'ingénierie inverse et de décompilation pour les obtenir ; mais l'effort peut être monumental, et le résultat n'est pas forcément au rendez-vous, ni pérenne.
La décision de la Commission européenne condamnant Microsoft pour abus de position dominante2 donne plusieurs exemples concrets :
« 685. Premièrement, le reverse-engineering des interfaces d'un programme aussi volumineux que Windows nécessite des efforts considérables qui ne sont pas certains d'être couronnés de succès. [...] Même le reverse-engineering d'un ensemble plus limité [...] impliquera la difficulté de localiser les points de connexion pertinents, qui sont enterrés quelque part dans les plus de 30 millions de lignes de code de Windows. Du fait de ces difficultés techniques, ce processus entraîne un retard important, ce qui est un handicap majeur sur des marchés de logiciels qui évoluent rapidement. Samba en constitue une illustration. [...] »
« 686. Deuxièmement, la rentabilité des produits développés en utilisant le reverse-engineering est tributaire de la volonté de Microsoft de ne pas remettre en cause la compatibilité. Elle pourrait facilement le faire par des moyens d'actions légitimes tels que la mise à niveau du système d'exploitation. Le reverse-engineering est par conséquent un choix commercial intrinsèquement vulnérable. »
La sécurité juridique est, d'autre part, loin d'être assurée, dans la mesure où le recours à de telles pratiques – considérées comme des exceptions aux droits exclusifs d'adaptation et de reproduction – est encadré par des textes parfois contradictoires et à l'articulation complexe.
C'est tout particulièrement vrai en France où les exceptions d'ingénierie inverse et de décompilation sont assorties de limitations reprises du test en trois étapes3, règle de droit international destinée à l'origine à guider le législateur dans l'écriture des exceptions, et non le juge dans son interprétation.
Des dispositions contradictoires et à l'articulation complexe
En l'absence de publication effective des spécifications techniques, les exceptions de décompilation et d’ingénierie inverse permettent donc de rechercher les informations essentielles à l'interopérabilité sans demander l'autorisation à l'éditeur : « La reproduction du code du logiciel ou la traduction de la forme de ce code n'est pas soumise à l'autorisation de l'auteur lorsque la reproduction ou la traduction [...] est indispensable pour obtenir les informations nécessaires à l'interopérabilité d'un logiciel créé de façon indépendante avec d'autres logiciels »4.
Cette disposition légalise donc ces techniques aux fins d'interopérabilité sous diverses conditions5, suffisamment complexes pour entraîner une grande insécurité juridique. Ainsi, la mise en œuvre de l'interopérabilité par décompilation ou ingénierie inverse peut se retrouver en contradiction de dispositions législatives telles que celles relatives à l'interdiction du contournement des menottes numériques ou DRM (Digital Right Management)6. De même, la directive 2001/29CE instaure une protection juridique des informations électroniques attachées à une œuvre numérique qu'il devient illégal de modifier ou de supprimer, ce qui peut arriver quand on interopère « en aveugle ». Enfin, lors d'une conversion de fichiers, la signature numérique de l’œuvre – qui peut être considéré comme une information protégée au regard de cette loi – peut changer.
Le cas du logiciel libre
Les auteurs et éditeurs de logiciels libres ont souvent des difficultés à obtenir les informations nécessaires à l'interopérabilité à cause des clauses de non-divulgation et des exigences de redevance à la copie imposés par les éditeurs propriétaires. Les auteurs de logiciels libres utilisent donc l'ingénierie inverse et la décompilation pour développer des logiciels interopérants avec d'autres systèmes, y compris avec des mesures techniques de protection. Pourtant ces exceptions ont failli tomber dans l'illégalité par un décret d'application de la loi DADVSI7. En effet, la diffusion d'une part d'un logiciel permettant de lire un fichier normalement uniquement accessible par un DRM est passible de 6 mois de prison et 30 000 euros d'amende8 et, d'autre part, la détention et l'utilisation d'un tel logiciel est passible d'une contravention de quatrième classe9. Par une interprétation littérale de ces dispositions, on pouvait en déduire que la diffusion ou la détention d'un logiciel libre permettant de lire un contenu protégé par des DRM, comme le logiciel de lecture multimédia VLC, étaient constitutives d'infractions. La situation a cependant été clarifiée par le Conseil d’État10 , sur requête en annulation de l'April11, pour s'assurer de la légalité de ces logiciels :
« Considérant que ces dispositions [de l'article L122-6-1] instituent, sous certaines conditions, une exception de décompilation destinée à permettre le développement de logiciels libres ; qu'en prévoyant qu'est sanctionnée la détention de dispositifs "conçus ou spécialement adaptés" pour porter atteinte à une mesure technique de protection mentionnée à l'article L. 335-1 du code de la propriété intellectuelle, lequel s'applique sans préjudice des dispositions de l'article L. 122-6-1 précité, le pouvoir réglementaire n'a pas entendu viser l'exception régie par ces dispositions, laquelle ne saurait dès lors relever du champ d'application de l'article R. 335-3 du code de la propriété intellectuelle. »
Des logiciels libres ont pu se développer malgré l'absence de standards ouverts, grâce à l'ingénierie inverse. LibreOffice.org en est d'ailleurs un bon exemple, car il a été rendu compatible avec les formats bureautiques de Microsoft uniquement grâce à la décompilation. Pour autant, si la garantie de pouvoir le faire est essentielle, l'ingénierie inverse n'est pas pour autant optimale : étant donnés les coûts d'une décompilation, peu d'auteurs ou éditeurs peuvent se lancer dans cette entreprise, d'autant plus que l'éditeur du format fermé peut modifier les spécifications techniques dans une version ultérieure, et tout le travail de décompilation serait alors à refaire ; et un tel travail d'ingénierie inverse n'assure pas que l'interopérabilité soit totale. À l'inverse, l'ouverture des conditions d'élaboration et de maintenance du standard garantit la stabilité d'un format ou d'une norme, nécessaires à l'interopérabilité.
L'obtention des informations essentielles à l'interopérabilité par une décision judiciaire ou administrative est un parcours coûteux et incertain
L'obtention des informations essentielles via une autorité : du principe à l'incapacité
En théorie, si l'éditeur pratique la rétention des informations essentielles, il est possible de demander à une autorité judiciaire ou administrative que l'éditeur fournisse ces informations en s'appuyant sur la théorie dite des facilités essentielles. Mais les jurisprudences appliquant cette théorie sont rares et les autorités de régulation répugnent à intervenir avant que le mal ne soit fait. De plus, comme l'illustre le cas opposant Microsoft à la Commission européenne, quand l'abus de position dominante est établi et l'obligation de fourniture actée, le débat est déporté sur ce que sont réellement ces fameuses « informations essentielles à l'interopérabilité », et sur ce qui est « équitable et non discriminatoire » en matière de fourniture de telles informations.
Ainsi, quand la Commission européenne ordonne à Microsoft de donner à ses concurrents un accès aux spécifications techniques des protocoles qu'elle utilise, pour que des logiciels serveurs indépendants soient capables de communiquer correctement avec son système Windows, Microsoft saisit la Cour de justice des Communautés européennes (CJCE) dénonçant une expropriation. Puis, en l'attente de la décision, elle fournit à la Commission des milliers de pages de documentation non pertinente, et réclame une indemnité au titre de brevets logiciels, et la non utilisation des spécifications décrites dans des logiciels libres, au nom du secret industriel.
S'agissant des menottes numériques ou DRM (Digital Right Management), l'éditeur doit communiquer les informations essentielles à l'interopérabilité12, conformément à la loi13. La demande d'information doit nécessairement être faite à l'éditeur, car ce n'est qu'en cas de refus de l'éditeur que la Haute Autorité pour la diffusion des œuvres et la protection des droits sur internet (Hadopi) peut être saisie14. Cependant, aucune décision de l'Hadopi n'est encore intervenue sur ce sujet et il est fort peu probable que l'Autorité ordonne un jour la transmission d'informations essentielles. En effet, le titulaire de droits sur le DRM peut bloquer la fourniture des informations essentielles par la preuve qu'une telle transmission serait une « atteinte à la sécurité et à l'efficacité de ladite mesure technique »15. Cette capacité de blocage du titulaire de droits vide donc de sa substance cette procédure devant l'Hadopi et rend compte de l'incapacité des éditeurs de logiciels libres d'obtenir les informations essentielles à l'interopérabilité par la voie contentieuse.
La condition de certification pour interopérer
En plus des revendications faites au titre de droits de propriété, inexistants en droit européen, des revendications exagérées faites au nom de la sécurité informatique ou de la lutte contre la contrefaçon se multiplient également pour justifier la mise en place de nouveaux obstacles à la mise en œuvre de l'interopérabilité. Un arrangement passé par Microsoft lors d'un procès anti-trust aux États-Unis16 l'illustre parfaitement. Dans cet accord, Microsoft s'arroge le droit de conditionner l'accès aux informations essentielles à l'interopérabilité à des critères subjectifs sur la validité des demandeurs (notamment la viabilité de l'entreprise et la qualité de ses technologies), et la compétence de juger si ces critères sont satisfaits.
Un autre exemple d'une volonté de restreindre l'interopérabilité aux seuls logiciels certifiés “conformes” aux critères du dominant est la proposition de définition de l'interopérabilité, proposée par le rapporteur Christian Vanneste (UMP) pendant les débats sur le projet de loi DADVSI. « Au sens du présent article, on entend par interopérabilité la capacité à lire une œuvre sur un système conformément à l'état de l'art, dans la limite des droits accordés par les détenteurs des droits et qui maintient la protection de l’œuvre dans des conditions d'efficacité, de robustesse et de conformité d'exécution équivalentes à celles assurées par le système originel ».
Dans les deux cas, les exceptions posées à l'obligation de fourniture des informations essentielles impose de passer des tests payants de conformité aux standards Microsoft pour pouvoir obtenir l'accès aux informations. L'aboutissement d'une telle démarche est l'informatique dite “de confiance” qui empêche dans les faits, par des moyens techniques, la mise en œuvre de l'interopérabilité aux logiciels non certifiés. Comme l'explique le rapport sur la sécurité des systèmes d'informations rédigé par le député Pierre Lasbordes17, « l'émergence de cette informatique de confiance conduirait un nombre très limité de sociétés à imposer leur modèle de sécurité à la planète, en autorisant ou non, par la délivrance de certificats numériques, des applications à s'exécuter sur des PC donnés » ; ce qui pose, en plus des risques pour la vie privée et la sécurité nationale, d'évidents problèmes de libre concurrence. Cette informatique déloyale plutôt que « de confiance »18 est malheureusement déjà une réalité. Ainsi, de plus en plus d'ordinateurs ne peuvent exécuter que le système d'exploitation avec lequel ils sont vendus.
La définition proposée par le rapporteur Christian Vanneste, faite sur mesure pour l'informatique déloyale, n'a heureusement pas été retenue. Mais le contenu de la loi finalement promulguée, la décision du Conseil constitutionnel associée19, le décret relatif à l'autorité de régulation des DRM puis celui sur Hadopi20, montrent que l'idée d'une interopérabilité uniquement accessible par voie contractuelle, conditionnée in fine au bon vouloir du dominant, reste, en France, d'une actualité brûlante.
1Art. L122-6-1 IV Code de propriété intellectuelle (CPI).
3Conditions cumulatives prévues par la Convention de Berne pour les exceptions aux droits des auteurs prévues par les législations nationales : application à des cas particuliers, non-atteinte à l'exploitation normale de l’œuvre, absence de préjudice injustifié pour les titulaires de droits.
4Art. L122-6-1 Code de propriété intellectuelle (CPI) http://www.legifrance.gouv.fr/affichCodeArticle.do;jsessionid=7412F0DF83DFA24FE34930E1B2360B14.tpdjo02v_2?idArticle=LEGIARTI000006278920&cidTexte=LEGITEXT000006069414&dateTexte=20111221.
5Ces conditions sont : avoir le droit d'utiliser le logiciel, ne pas avoir eu facilement accès aux informations essentielles à l'interopérabilité, se limiter à la partie du logiciel nécessaire à cette interopérabilité.La Cour de cassation est intervenue sur le sujet de l'interopérabilité. Ainsi, la détention de programmes exécutables pour la récupération de fichiers, sans accès aux codes sources, à la demande de l'utilisateur et dans le but de lui permettre de passer d'un système de gestion informatique à un autre, est conforme à l'article L122-6-1 du Code de propriété intellectuelle. Dès lors, la détention et l'utilisation de programmes exécutables, à la différence des codes sources, ne sont pas soumises au droit d'auteur et ne sont pas constitutives d'un acte de contrefaçon si celles-ci sont effectuées à des fins d'interopérabilité. Cass. civ. 1re, 20 oct. 2011, n°10-14069, à paraître au Bulletin: http://www.legifrance.gouv.fr/affichJuriJudi.do?oldAction=rechJuriJudi&idTexte=JURITEXT000024701253&fastReqId=316997419&fastPos=1.
6Pour plus d'information, voir le cahier DRM.
7Décret n° 2006-1763 du 23 décembre 2006, relatif à la répression pénale de certaines atteintes portées au droit d'auteur et aux droits voisins http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000817096&dateTexte=.
8L335-3-1 CPI « est puni de six mois d'emprisonnement et de 30 000 euros d'amende le fait de procurer ou proposer sciemment à autrui, directement ou indirectement, des moyens conçus ou spécialement adaptés pour porter atteinte à une mesure technique efficace [...] » http://www.legifrance.gouv.fr/affichCode.do;jsessionid=87DF7B0E7D5795A3F9A18A95332B67E3.tpdjo07v_1?idSectionTA=LEGISCTA000006161658&cidTexte=LEGITEXT000006069414&dateTexte=20111003.
9R335-3 CPI http://www.legifrance.gouv.fr/affichCode.do;jsessionid=87DF7B0E7D5795A3F9A18A95332B67E3.tpdjo07v_1?idSectionTA=LEGISCTA000006161722&cidTexte=LEGITEXT000006069414&dateTexte=20111003.
10CE 10e et 9e sous-sect., 16 juillet 2008, n° 301843, APRIL, http://juriscom.net/jpt/visu.php?ID=1087 J-C Zarka, « Le Conseil d’État et l'usage des logiciels libres », la Semaine juridique Entreprise et Affaires n°45, 6 novembre 2008, 2377.
11http://www.april.org/en/dadvsidrm-le-conseil-detat-retablit-le-contournement-a-des-fins-dinteroperabilite.
12Article L331-5 alinéa 4 CPI http://www.legifrance.gouv.fr/affichCode.do;jsessionid=87DF7B0E7D5795A3F9A18A95332B67E3.tpdjo07v_1?idSectionTA=LEGISCTA000006179045&cidTexte=LEGITEXT000006069414&dateTexte=20111003.
13Article L331-32 alinéa 2 CPI : « la documentation technique et les interfaces de programmation nécessaires pour permettre à un dispositif technique d'accéder, y compris dans un standard ouvert au sens de l'article 4 de la loi n°2004-575 du 21 juin 2004 pour la confiance dans l'économie numérique, à une œuvre ou un objet protégé par une mesure technique et aux informations sous forme électronique jointes, dans le respect des conditions d'utilisation de l’œuvre ou de l'objet protégé qui ont été définies à l'origine » http://www.legifrance.gouv.fr/affichCode.do;jsessionid=87DF7B0E7D5795A3F9A18A95332B67E3.tpdjo07v_1?idSectionTA=LEGISCTA000020740341&cidTexte=LEGITEXT000006069414&dateTexte=20111003.
14Article L331-32 alinéa 1 CPI.
15Article L331-32 alinéa 3 CPI.
17Voir la section « Informatique dite de confiance » du cahier n°4 : MTP/DRM.
18Pour davantage d'informations sur l'informatique de confiance : http://www.april.org/trusted-computing-le-film.
19http://www.conseil-constitutionnel.fr/conseil-constitutionnel/francais/les-decisions/acces-par-date/decisions-depuis-1959/2006/2006-540-dc/decision-n-2006-540-dc-du-27-juillet-2006.1011.html.
20Décret n°2010-1366 du 10 novembre 2010, art R331-55 et suivants CPI http://www.legifrance.gouv.fr/affichCode.do;jsessionid=2C76345C987E75B4ABA417760BA59433.tpdjo03v_1?idSectionTA=LEGISCTA000023092422&cidTexte=LEGITEXT000006069414&dateTexte=20110926.