|
|
| (21 versions intermédiaires par le même utilisateur non affichées) |
| Ligne 1 : |
Ligne 1 : |
| | [[Catégorie:Transcriptions]] | | [[Catégorie:Transcriptions]] |
| | | | |
| − | '''Titre :''' Administrations et logiciels libres, Le clausier des marchés publics
| + | Publié [http://www.april.org/administrations-et-logiciels-libres-le-clausier-des-marches-publics ici] |
| − | | |
| − | '''Intervenants :''' Anne-Claire Viala - Thierry Aimé
| |
| − | | |
| − | '''Lieu :''' RMLL2015 - Beauvais
| |
| − | | |
| − | '''Date :''' Juillet 2015
| |
| − | | |
| − | '''Durée :''' 35 min 07
| |
| − | | |
| − | '''[http://video.rmll.info/videos/amphi-bunuel-administrations-et-logiciels-libres-le-clausier-des-marches-publics/ Lien]''' vers la '''vidéo'''
| |
| − | | |
| − | '''[https://2015.rmll.info/IMG/pdf/ccag_tic_administration_et_ll_9_juillet_2015.pdf support format PDF] '''
| |
| − | | |
| − | ==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,
| |
