Administrations et logiciels libres - Clausier des marchés publics
Titre : Administrations et logiciels libres, Le clausier des marchés publics
Intervenants : Anne-Claire Viala - Thierry Aimé
Lieu : RMLL2015 - Beauvais
Date : Juillet 2015
Durée : 35 min 07
Lien vers la vidéo
Description
La circulaire du Premier ministre de 2012 décrit le bon usage des logiciels libres dans l’Administration. Les spécificités de l’environnement du logiciel libre nécessitent la mise en œuvre de clauses de propriétés intellectuelle (PI) pour les marchés de développement et de maintenance de logiciels libres et conseils opérationnels qui complètent ou dérogent au CCAG TIC.
Au Ministère des Finances et des Comptes publics, la Direction générale des Finances publiques (DGFiP) et l’Agence du patrimoine immatériel de l’État (APIE) ont rédigé des modèles de clauses permettant de contractualiser des marchés publics comportant du logiciel libre.
Transcription MO
Thierry Aimé : Anne-Claire Viala, l'APIE, l'agence du patrimoine ?
Anne-Claire Viala : Anne-Claire Viala. Je suis juriste en propriété intellectuelle à l'Agence du Patrimoine immatériel de l’État. En fait, c'est une agence conseil interne au sein de l'administration, qui est rattachée aux ministères financiers.
Thierry Aimé : Et moi je suis Thierry Aimé, je travaille à la DGFiP, la Direction générale des Finances publiques, et je suis en charge des logiciels libres, particulièrement, et du marché de support logiciels libres des ministères financiers. C'est à ce titre que, donc, nous avons travaillé à ce sujet, à produire un guide pour les marchés les publics. Ce travail s’inscrit, en fait, dans le cadre d'une circulaire du Premier ministre, qui a été signée en septembre 2012, et qui incitait les administrations à utiliser, à chaque fois que c'était possible, du logiciel libre. Il ne s'agissait pas de privilégier le logiciel libre, mais en tout cas, à chaque fois qu'un logiciel libre pouvait rendre le service attendu par l'administration, il fallait le prendre, sans hésiter. Évidemment, cette directive était motivée pour des raisons financières, mais aussi pour des questions de maîtrise du patrimoine informatique de l'administration. Essentiellement donc, pour la mettre en œuvre cette directive, comme on a quand même souvent recours à des marchés publics pour développer notre système d'information, il fallait s'appuyer sur des dispositions au niveau de nos marchés publics qui mettent en œuvre, disons, l'utilisation de ces logiciels libres, dans le respect de ce que ces logiciels libres ont de spécifique, à savoir, donc, leur licence. Donc voilà l'objectif de ce clausier, qui est donc initié à cette époque et puis il a fallu, environ, un an et demi pour y travailler et conclure ce document qu'on va vous présenter. Il s'agit, bon, je te laisse parler.
Anne-Claire Viala : Effectivement il s'agit d'un document qui est éminemment juridique. On s'était rendu compte que c'était très bien d'avoir cette circulaire du Premier ministre, qui incitait à avoir recours aux logiciels libres, pour autant, dans le cadre des marchés, ça avait du mal à se mettre en place parce que certaines dispositions spécifiques devaient être prévues. L'idée c'était de prévoir du modèle de contrat qui permettait aux administrations qui souhaitaient avoir recours à une solution sous forme de logiciel libre, de pouvoir, plus facilement, passer le marché.
Pourquoi il y avait des difficultés ? D'une part, parce que dès lors qu’on parle de logiciel, on parle de droits d'auteur, avec cette spécificité qu'il va falloir prendre en compte, dans le cadre des marchés publics, puisque le seul fait de passer une commande publique, de passer un marché public, n'emporte pas transfert de droits. Il va falloir avoir des dispositions spécifiques pour que la personne publique puisse utiliser ce logiciel.
Ce qu'il faut savoir c'est que, dans la sphère publique, les administrations, finalement, pour passer un marché, disposent de modèles de contrats. Ces modèles de contrats sont consacrés dans des arrêtés et, notamment, on en a un particulier, c'est le cahier des clauses administratives générales en matière de technologie de l'information et de la communication, qui propose un canevas contractuel pour que les administrations puissent passer leurs marchés. Ce canevas, tel qu'il était rédigé, devait quand même être adapté pour pouvoir s'adapter au monde du libre. Et dans le cadre du guide qui nous a occupés pendant une année entière, on s'est intéressés au cas où une administration commanderait un développement spécifique, et qu'elle aurait pour objectif de vouloir diffuser ce développement sous une licence libre de logiciel. Donc, c’était fournir à ces administrations, la possibilité, savoir quelles étaient les clauses qu'il fallait prévoir dans le marché pour diffuser en libre un logiciel spécifiquement développé pour elles.
Le deuxième type de marché qui nous a intéressés c’était les marchés de maintenance de logiciels libres. C’est-à-dire une administration utilise, dans le cadre de son activité, un logiciel libre, que faut-il prévoir dans le marché de maintenance compte tenu des spécificités du monde du libre ?
Donc, ce qu'on va faire, c'est vous présenter, finalement assez rapidement compte tenu du temps qui nous est imparti de manière à vous permettre de nous poser des questions, ces deux types de marché, tout du moins les points de vigilance qui nous ont semblé importants, dans le cas du marché de développement spécifique de logiciels qui sont destinés, dans un premier temps, à être mis en ligne.
La première chose, à partir du moment où l'administration passe un marché public auprès d'un prestataire pour faire un développement spécifique qu'elle veut diffuser en libre, la première recommandation, effectivement, qu'il faut faire, c'est que l’administration doit informer le prestataire du fait que le logiciel qu'elle a commandé, elle ne va pas l'utiliser uniquement pour ses besoins internes, mais elle va vouloir le diffuser sous forme de logiciel libre. D'un point de vue juridique, de manière à ce que, finalement, le logiciel, dans la manière dont il va être développé par le prestataire puisse être compatible avec la licence sous laquelle sera diffusé ce logiciel, c'est indiquer quelle est cette licence. Est-ce que c'est une licence CeCILL, ou une autre licence ? Mais ce qui va permettre au prestataire d'utiliser des composants, et notamment un logiciel est rarement développé from stretch, donc débouter des composants pré-existants, qui auront un régime juridique, qui vont être compatibles avec la licence sous laquelle ce logiciel sera diffusé. Et donc finalement, tout l'objectif de ce guide, c'était de prévoir, de régler cette question des droits de propriété intellectuelle. On ne va pas vous exposer tout ça maintenant. Le guide est diffusé, il est en libre accès sur le site de l'APIE ; il indique aux administrations, finalement, qu’est-ce qui doit être prévu d'un point de vue strictement contractuel dans le cadre du marché, pour aboutir à cet objectif.
Effectivement, à partir du moment où l’administration veut diffuser sous licence libre de logiciels, des obligations spécifiques à la charge du prestataire vont devoir être prévues. Notamment, prévoir des composants, tous les éléments, les briques préexistantes qui vont être utilisées pour développer le logiciel, qu'elles soient compatibles avec le régime de la licence.
On s'est rendu compte, aujourd'hui, en fait tout ça vient d’une certaine expérience, qu'au sein de l'administration on avait des logiciels où souvent le développement spécifique, tel qu'il avait été conçu par leur prestataire, on aurait pu le diffuser sous licence libre, mais ce qui paralysait, finalement, cette diffusion sous licence libre, c’était la manière dont il avait été développé avec des composants qui ne permettaient pas de le diffuser sous licence libre. Donc c'est un peu le fruit de cette expérience qui nous a permis d'aboutir à ce guide, et notamment les cas dans lesquels on n'a pas réussi à diffuser sous licence libre, c’étaient les cas dans lesquels le logiciel, il avait été développé sur la base de composants préexistants, qui étaient incorporés dans ces développements spécifiques, et qui étaient indissociables. Dans l'hypothèse, et là on a fait obligation au prestataire, soit de ne pas utiliser de composants qui soient indissociables, ou si, pour développer son logiciel, il a besoin de composants qui sont indissociables, prévoir un régime juridique harmonisé, c’est-à-dire qu'il utilise des composants qu'on va pouvoir, eux aussi, diffuser sous licence libre.
L'autre écueil qu'on a souvent rencontré, c'est que, finalement, on se retrouve avec des logiciels, mais on ne sait pas comment ils ont été composés. Et donc, le jour où on veut les mutualiser au sein de l'administration, on est un peu en peine puisqu'on ne sait absolument pas de quoi ils sont composés. Donc, avec une obligation spécifique de fournir un rapport qui va décrire la liste complète des composants et le régime juridique qui leur est associé, et évidemment, la fourniture des codes sources, parce qu'à défaut, on ne pourrait pas diffuser cet ensemble logiciel sous une licence libre.
Dans le guide que nous avons rédigé, finalement, on retrouve, traduit d'un point de vue purement contractuel, ces différents éléments.
09' 00
Deuxième type de marché sur lequel nous avons travaillé, c’était les marchés de maintenance de logiciels libres et je laisse la parole à Thierry puisque ce sont des aspects un peu plus techniques.
Thierry Aimé : Bon, alors dans cette hypothèse de maintenance, il y a un point qui n'a plus à être traité c'est la licence a priori du logiciel puisqu'elle nous est donnée avec le logiciel libre, et ça, on n'a pas le choix, en général, de la modifier, ni l’Intérêt d'ailleurs.
Donc maintenant, la question est de savoir, cette licence du logiciel qu'on va réutiliser, qu'on va utiliser pour nos besoins, est-ce que dans le contrat qu'on va conclure avec le prestataire, cette licence fait partie du contrat du marché ? Le principe de notre approche, qui est développé, c'est de considérer que la licence libre est extérieure au contrat de marché public. Ça amène beaucoup d’avantages, parce que déjà, souvent les licences de logiciels libres sont en anglais, donc c'est toujours un problème d'avoir, dans un contrat en français, des éléments en anglais. Donc, le marché est une chose, il est rédigé en français, les licences sont extérieures au marché. Le titulaire du marché a le droit d’utiliser ce logiciel indépendamment de l'administration, puisque le logiciel est libre, chacun est libre de l'utiliser. Le prestataire n'a pas besoin de l'autorisation de l'administration pour s'approprier le code et développer des patchs, des correctifs sur ce code. Donc l'utilisation du titulaire est externe au marché ; et de même que l'utilisation de l'administration est externe à l'utilisation du prestataire. Chacun utilise donc indépendamment le logiciel. Néanmoins, le prestataire qui va venir à notre aide sur ce marché de support, ne pourra pas prétexter que c'est à cause de l'administration qu'il a enfreint, éventuellement, une règle de la licence. C'est à lui, prestataire, de s'assurer que les opérations qu'il va mener sont bien autorisées par la licence. Donc, c'est ce que notre proposition contient, donc dans ces dispositions pour les marchés de maintenance.
Maintenant, il y a un deuxième sujet compliqué, c'est que, quand on parle de logiciel libre, on n'a pas souvent de spécifications très claires de ce qu'il est supposé faire, même s'il existe, quand même souvent, pour les meilleurs logiciels libres, des documents techniques assez nombreux, des guides d'utilisation, des guides d'installation, etc. On peut même trouver des spécifications parfois. Enfin, bon, comme ce ne sont pas des éléments qu'on peut contractuellement opposer avec le titulaire, il faut avoir une vision assez extensive des éléments qui permettent de dire « le problème que je rencontre aujourd'hui avec ce logiciel relève bien d'un bug, et il faudrait que vous le corrigiez ». Donc on a mis en place un certain nombre de dispositions, qui permettent d'avoir une vision assez large, même peut-être trop large parfois, en particulier on écrit qu'un bug ça peut être, aussi, un comportement différent des logiciels équivalents observés. En tout cas, ce genre de disposition, c'est vrai que c'est assez large, néanmoins le marché actuel de support logiciels libres du ministère des Finances contient cette clause. Donc le prestataire est engagé à ce que, si le logiciel ne marche pas comme certains logiciels équivalents, on puisse, éventuellement, le considérer comme des bugs. Après on n'est pas idiots, on sait qu'il est important que, quand on demande la correction d'un bug, qu'il ne soit pas contre nature avec l'esprit du logiciel libre en question, et, à chaque fois, l'importance de pouvoir reverser est bien présente à nos esprits. Et c'est une obligation, d'ailleurs, qui est faire au prestataire, on va le voir juste après. Il faut tenir compte aussi de ça, c'est-à-dire que si on veut modifier le comportement du logiciel de manière opposée au choix de la communauté, ça serait une très mauvaise idée de notre part que de l'imposer.
On a aussi la notion de maintenance adaptative. Ça c'est une spécificité aussi du logiciel libre, parce que le logiciel libre, il vous est donné en tant que code source, indépendamment de la plateforme d'exécution, en général. C'est-à-dire qu'un logiciel, vous pouvez tout à fait le compiler sur une autre architecture. Une application qui tourne spécifiquement sous Linux, pour peu que vous ayez un peu de travail à faire, ce n'est pas toujours aussi simple d'ailleurs, mais enfin, on peut très bien la recompiler pour une autre plateforme. Donc, cette disposition permet aussi de disposer auprès du support de versions compilées dans des plateformes non prévues par la communauté. Donc, là aussi, ce sont des dispositions qui figurent aujourd'hui à notre marché de support logiciels libres.
L'élément essentiel lorsque l'on fait des corrections sur du logiciel libre, est bien entendu que ces correctifs regagnent la souche communautaire, le logiciel communautaire, puisque, si l'on ne fait pas cette opération, la correction qu'on opère sur notre version sera à refaire lorsqu'on mettra à jour la version ; comme, par exemple sur LibreOffice, si vous corrigez un problème sur la version 4.1, et que vous ne faites pas attention à ce que correctif ne soit pas reporté sur les versions suivantes, vous risquez de devoir le refaire, ce correctif, sur les versions 4.4, etc. Donc l’important est de prévoir dans le cadre de ce marché de maintenance le reversement. Évidemment le reversement ne peut être qu'une obligation de moyens, puisque la communauté restera maître d'intégrer, ou pas, le correctif. Elle pourrait ne pas l'intégrer parce qu'il est mal écrit. Si, effectivement, c'est le retour que fait la communauté, le prestataire aura obligation de reprendre son patch et d'améliorer sa forme. Si, en revanche, le correctif porte, parce qu'on a aussi ce cas très souvent, sur des versions tellement anciennes que le patch ne peut absolument pas fonctionner sur une version récente, et peut-être même, d'ailleurs, n'aurait pas de sens étant donné des refontes d’architecture, etc, il nous arrive souvent que, malheureusement, pour les versions très anciennes le patch ne soit pas repris par la communauté. Ça c'est un risque, l'idée est, quand même, qu'à chaque fois que c'est possible ce soit fait. Et, dans le concret de notre exemple, marché support logiciels libres, c'est ce qui se passe dans plus de 80 % des cas. Les patchs sont effectivement repris dans les versions ultérieures des communautés.
En revanche, pour les maintenances évolutives, qu’est-ce qu'on cache derrière la notion évolutive ? C'est vraiment rajouter de nouvelles fonctionnalités. Là il ne s'agit pas juste de corriger à la marge un dysfonctionnement, il s'agit vraiment d'ajouter de nouvelles fonctionnalités, de construire quelque chose de nouveau avec un logiciel libre. Là aussi, l'impératif de reversement est très fort, puisque, si ça ne se fait pas, ça veut dire qu'on va avoir un logiciel spécifique, interne à l'administration, mais plus aucune dynamique communautaire possible. On sera sur un fork, comme on dit techniquement.
Quand on fait de la maintenance évolutive, le principe est de travailler en amont de tout développement de nouvelles fonctionnalités avec la communauté, pour connaître son avis sur la fonctionnalité qu'on souhaite. Est-ce que c'est quelque chose qui est attendu par la communauté, qui va dans le sens de ce qu'attend la communauté ? Et si oui, seulement, on va entamer les travaux. Sinon, soit on assume de faire un fork et on garde notre version pour nous, tant pis. Mais si on compte vraiment maintenir notre logiciel dans une dynamique communautaire, il est impératif de travailler, en amont avec la communauté, les conditions de reversement. Ça c'est un travail que le titulaire du marché devra entreprendre avec la communauté, en préalable à tout développement sur le code. S'assurer que la fonctionnalité est attendue, qu'elle pourra s’inscrire dans une road map raisonnable avec la communauté, que le titulaire a bien pris en compte toutes les règles d'architecture, de développement, de fonctionnement de la communauté. Sans ce travail préalable, ce n'est pas la peine d'aller plus loin. Justement on a fait une construction de marché qui permet d'organiser par étapes le développement avec un préalable qui consiste à se garantir, auprès de la communauté, que ce travail qu'on va développer est attendu. Et là, donc, l'obligation va être de résultat. C’est-à-dire que le titulaire de ce marché va s'engager à faire tout le travail amont pour que les travaux menés d'évolution soient bien repris par la communauté à l'issue du marché. C'est assez compliqué. Il faut vous rapporter au clausier qui explique, en détail, comment on met en place ce type de choses.
Malheureusement on ne va pas voir tout à fait la fin. Il faudrait remonter la fenêtre
19' 01
Globalement quand vous faites du développement, ça va être, donc, un titulaire qui va développer pour vous le code. Par défaut, si vous ne faites rien, le code développé par une société lui appartient, n'appartient pas à l'administration. L'administration a, tout au plus, le droit d'utiliser le logiciel avec les correctifs apportés, rien de plus. Donc dans le CCHG, le Cahier des clauses administratives générales, vous avez des dispositions avec une clause A ou B, et là il faut choisir la clause B, qui va organiser le transfert des droits de propriété depuis le titulaire jusqu’à l'administration. C'est une disposition qu'il faut quand même compléter, en elle-même elle ne se suffit pas, et justement le clausier amène les éléments nécessaires pour compléter cette disposition. Si tu veux ajouter.
Anne-Claire Viala : Effectivement, une fois que notre prestataire va avoir fait les évolutions nécessaires, la question qu'on s'est posée, on s'est dit « d'accord, il va faire les évolutions. Ces évolutions, il va falloir les transférer à la communauté, mais il va falloir, également, que nous on puisse les exploiter ». Donc prévoir un régime juridique associé. Après vu le temps qui nous était imparti, effectivement, on n'a absolument pas le temps de rentrer dans les dispositions des CCHG. Maintenant, si dans le cadre des questions vous êtes intéressés, parce que vous avez à manier ces différentes options A et B du CCHG TIC, qui, en fait, définissent un régime juridique qu'on retrouve en matière de logiciel libre et qu'on est venus adapter aux spécificités du logiciel libre, n'hésitez pas à nous poser de questions.
Thierry Aimé : On attend vos questions. Je crois qu'on est à peu près dans le timing prévu.
Public : Moi, mon utilisation de ça, c'est essentiellement saisir mon service des marchés publics. Donc, ces options A et B, je voudrais juste savoir à quel article ça correspond pour les transmettre aux personnes compétentes.
Anne-Claire Viala : Je suis ravie que vous disiez ça, parce que options A et B, finalement, ça veut dire quoi ? Je vais faire ça de manière très schématique. La A c'est de la licence. La B c'est du transfert de propriété. En revanche, là où j'attire votre attention, c'est qu'on se rend compte que souvent, effectivement, le prescripteur, la DSI va saisir son service marché, et, ce qui fait cruellement défaut, et la raison pour laquelle souvent ces clauses de propriété intellectuelle sont mal rédigées, c'est que ces clauses-là, la propriété intellectuelle normalement c'est de la négociation, si vous voulez. Il faut prévoir une durée, un territoire, des modes d'exploitation. Pour ça il faut définir son besoin. Un juriste, si on lui dit juste « je veux utiliser le logiciel », vous allez avoir le droit de l'utiliser, le logiciel. Maintenant, si vous ne lui avez pas dit « le logiciel que je veux utiliser, je veux aussi pouvoir le diffuser sous licence libre », si vous ne lui avez donné cette précision, il ne pas pouvoir vous rédiger les clauses de propriété intellectuelle. Si vous ne lui avez pas dit « moi, mon objectif, dans le cadre de ce logiciel, c'est certes que la personne morale, mon administration, mon service, puisse utiliser ce logiciel, mais si vous n'avez pas prévu, par exemple, que ça pourrait intéresser d'autres administrations, la possibilité de le mutualiser, finalement il ne va pas y avoir la bonne option qui va être choisie.
Donc A, B. A c'est licence. Alors A, B ça s'applique uniquement pour des développements spécifiques. Si l'objet du marché c'est une licence de progiciel, il y a un régime juridique aussi de la licence, parce qu'on sait que les éditeurs ont des licences types qu'ils trouvent à s'appliquer. Ensuite A et B c'est licence cession pour le B. Le B doit obligatoirement être complété par durée, territoire et qu'est-ce que je vais en faire, et le B offre la possibilité de rétrocéder des droits à des tiers. Globalement quand vous faites du développement,
Public : Bonjour. Je travaille dans l'enseignement supérieur, j'ai suivi un peu l’évolution des choses. En 2013, il y a eu une loi dans l'enseignement supérieur pour l'utilisation du logiciel libre. Je crois qu'il n'y a pas eu de décret d'application et je vois que le travail que vous avez fait va dans le bon sens pour l'utilisation, ou des marchés logiciels libres. Donc sur le fond je trouve ça très bien. Votre travail, bon, je n’étais pas là au début, mais je vais en prendre connaissance plus en détail, j'imagine qu'on peut y accéder sur le site web du ministère.
Anne-Claire Viala : Et sur le site de l'APIE, qui est au début de ce powerpoint. Vous avez le site c'est www.apie.gouv.fr, vous avez ce guide en fait.
Public : D’accord. Donc je vais juste vous titiller un petit peu, parce que j'ai juste une remarque à faire sur la forme. Je vois en entête de votre document qu'il s'agit d'un document powerpoint. Il ne s'agit même pas d'un format standardisé ISO, puisque c'est du ppt, donc c'est un format...
Public : Inaudible.
Public : La source est un PPT powerpoint, donc c'est un format propriétaire, privateur, ce n'est même pas du pptx qui serait certifié ISO et donc je suis un peu étonné. Alors quel est l'état du marché bureautique au ministère des Finances ?
Anne-Claire Viala : Voilà. Avant de laisser Thierry répondre à l'état du marché bureautique au ministère des Finances, je suis désolée, moi je suis juriste et, effectivement, mes powerpoints, j'arrive à les faire sous ce format-là, et je vous prie de bien vouloir m'en excuser. J'ai eu conscience, en plus, je n'ai pas su le transformer dans un format libre.
Thierry Aimé : J'ai essayé de rattraper le coup, mais c'est parti avant que j'ai pu. Bon, voilà. En tout cas au ministère des Finances, à la DGFiP, on est maintenant, exclusivement, sous LibreOffice. Donc moi je ne sais même pas produire des ppt. J'arrive à les lire parce que LibreOffice lit les choses.
Public : I have a question, if mister ??? here. You have a question ?
Public : J'ai une question pour les deux. C'est possible de donner un exemple de composant qui n'est pas compatible ?
Thierry Aimé : Oui. Alors, voyons. Même si ça s'est arrangé avec la GPLv3, il me semble, par exemple, que la GPLv2 n'est pas compatible avec la licence Apache.
Public : Inaudible.
Thierry Aimé : Oui, mais c'est bien de ça que je parle.
Anne-Claire Viala : En tant que juriste, ce que j'ai compris, parce qu'effectivement ce travail, ce guide, pour réussir à l’élaborer, il y a eu un travail entre juristes et informaticiens, qui a été de longue haleine, quand même, parce qu'il a fallu se comprendre. Ça a été question de savoir qu'est-ce que c'était « indissociable ». Moi, ce qu'on m'a expliqué et ce que je comprends en tant que juriste, c'est que les lignes de code, finalement, quand on a le code du logiciel, le code source, on n’arrive pas à savoir ce qui a été développé par le prestataire, et ce qui est de la composante préexistante, parce que les lignes de code sont mélangées. Si c'est « dissociable », de ce que j'ai compris aussi, c'est que, finalement, pour faire fonctionner le développement spécifique avec le composant préexistant, vous pouvez faire de l'interfaçage, et du coup, ça voulait dire qu'une administration qui voulait diffuser sous libre ce développement spécifique pouvait le faire. Pour autant, d'autres administrations pour pouvoir s'y connecter, il leur fallait un interfaçage. C'est ça ?
26' 45
Thierry Aimé : Eh bien, effectivement, enfin dans les applications réelles,
