Administrations et logiciels libres - Le clausier des marchés publics

[8]

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
Pour visionner la vidéo [8]
Pour visionner le support format PDF [9]

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.
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

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’État1. 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 guide2 pour les marchés publics. Ce travail s’inscrit, en fait, dans le cadre d'une circulaire du Premier ministre3, 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 était 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. Je te laisse parler d'ailleurs.

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, finalement 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 droit 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 des 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 communication4, 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és 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és, à tout le moins les points de vigilance qui nous ont semblé importants, dans le cadre du marché de développement spécifique de logiciels qui sont destinés, dans un premier temps, à être mis en Libre.

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 CeCILL5 ou une autre licence ? Mais ce qui va permettre au prestataire d'utiliser des composants, et notamment un logiciel est rarement développé from scratch, 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 logiciel, 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, que, 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 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.

Deuxième type de marchés 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é : 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.

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. 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 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 plate-forme 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 plate-forme. Donc, cette disposition permet aussi de disposer auprès du support de versions compilées dans des plates-formes 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 donc 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é de 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

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 CCAG, 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 à 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 CCAG. 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 CCAG TIC, qui, en fait, définissent un régime juridique qu'on retrouve en matière de logiciels libres et qu'on est venus adapter aux spécificités du logiciel libre, n'hésitez pas à nous poser des 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és, 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 va 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 les droits à des tiers.

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 [10], 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 : 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,et 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 de PPT. J'arrive à les lire parce que LibreOffice lit les choses.

Public : I have a question here. OK. You have a question ?

Public : J'ai une question pour les deux. C'est possible de donner un exemple d'un 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. Cette 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 ?

Thierry Aimé : Eh bien, effectivement, enfin dans les applications réelles, on voit vraiment des choses assez étonnantes. Enfin moi j'ai vu, par exemple, des morceaux de la librairie Spring, enfin Spring Integration, récupérés, enfin copiés, des morceaux copiés dans une application maison, en développement interne. A priori, il n'y a pas de problème, puisqu'on utilise ça en interne, c'est du logiciel libre et comme on ne le rediffuse pas, on peut mélanger à peu près tout ce qu'on veut en termes de licence. Mais en revanche, si tout d'un coup il nous prenait l'envie de le diffuser, il faudrait vraiment regarder les choses, à nouveau, finement, et je ne sais pas si ça marcherait tout à fait. En tout cas, voilà ! Donc la réalité des développements qui sont réalisés. Quand on a des bibliothèques bien définies, bien délimitées, avec leurs licences, en général c'est assez facile de regarder ce qu'il en est, mais après, on peut avoir des choses autrement plus compliquées dans la réalité des projets qui sont développés ici ou ailleurs, enfin chez nous comme ailleurs. Sans compter d'ailleurs, une habitude aussi qui se fait beaucoup chez les développeurs, je ne sais pas, peut-être pas vous parce que vous êtes des très bons développeurs, mais qui consiste à aller copier des exemples de code qu'on trouve sur Internet, dont on n'a aucune idée de la licence qui les couvre. Ça, ce sont des choses qu'on voit. Si vous faites une recherche avec Google, vous prenez deux ou trois lignes de code, et vous pouvez les retrouver, dans un exemple, sur le site de Microsoft, par exemple.

Public : Une autre question. Quelle est votre expérience dans le cas où on demande d’être propriétaire, donc option B, il est possible que les producteurs demandent plus cher. Alors parle-t-on de 5 ou de 50 % ?

Anne-Claire Viala : Je ne peux pas vous dire si on parle de 5 ou de 50 %. Ce qui est sûr c'est que si vous appliquez l'option B, avec une cession à titre exclusif des droits, à titre exclusif ça veut dire que vous privez le prestataire de la possibilité de ré-exploiter, forcément le coût de la cession, le prix du marché, sera plus important. Maintenant, en tous les cas, c'est peut-être l'expérience depuis le début de l'application des CCHG, autant quand on est dans d'autres domaines du droit, et je pense notamment aux marchés de prestation intellectuelle, l'exclusivité elle a un sens. Quand on fait faire un logo, on veut avoir une exclusivité sur ce logo. En matière informatique, je crois que la question, même quand on applique l'option B, de l'exclusivité, elle mérite d’être posée. Elle mérite d’être posée ne serait-ce que parce qu'elle a un coût. Après, l'option B, elle peut avoir un intérêt parce qu’elle permet de rétrocéder les droits et donc d'aboutir à cet objectif de mutualisation, ou de diffuser en Libre, mais si on diffuse en Libre, évidemment, on n'a pas besoin de l'exclusivité puisqu'on va le diffuser en Libre. Ça serait un non-sens que de priver le prestataire de la possibilité d'exploiter. Mais je crois que dans les marchés informatiques c'est vraiment une question qu'il faut se poser, celle de la pertinence, même si on retient cette fameuse option B, de garder cette exclusivité. Et en plus, effectivement, le fait que le prestataire puisse continuer à l’exploiter sur d'autres marchés, à partir du moment où vous, vous pouvez rétrocéder les droits, ça doit avoir une incidence assez limitée. Alors après, en termes de prix, malheureusement, vous avez la possibilité de demander des variantes dans les marchés.

Thierry Aimé : À mon avis c'est un peu une légende urbaine. S'il y a de la concurrence il n'y a pas de raison que les prix soient vraiment plus élevés avec l'option B que l'option A.

Aparté entre les deux intervenants

Anne-Claire Viala : Ça dépend si on est sur du développement spécifique.

Thierry Aimé : Oui, mais, tu vas faire appel à une société de services. Il n'y en a pas qu'une en France. Il y a de la concurrence, tu sais, elles se battent.

Anne-Claire Viala : Il y a une question là-haut ?

Thierry Aimé : Oui. Frédéric Couchet.

Fin de l'aparté

Public : Il faut poser les questions avec le micro. Moi, j'ai une question à poser. Il faut spécifier la licence quand on dit qu'on veut faire du transfert de propriété. De toutes façons, est-ce qu'il est raisonnable de laisser le choix au prestataire en disant « je veux une licence approuvée par l'Open Source Initiative », et puis de s’arrêter là quoi ?

Thierry Aimé : Non, ça, ça ne me paraît pas un bon choix. Il faut vraiment, si on veut cadrer un minimum, puisque justement, le principe des marchés publics c'est quand même qu’ils soient cadrés en particulier en matière de contrat, je pense qu'il faut que ce soit l'administration, si on part d'un développement qui n'existe pas, enfin un développement from scratch, enfin comme on dit, il faut fixer, a priori, la licence et ne pas laisser le titulaire la choisir.

Public : Inaudible.

Thierry Aimé : Ouais, non, c'est trop, ouais, mais il y en a une centaine. Certaines sont un peu exotiques ou ésotériques, ou en tout cas, non, disons pas très utilisées, donc c'est un peu dommage parce qu'après ça va impacter, peut-être, la manière dont on pourra utiliser le logiciel. Je ne sais pas, par exemple si le prestataire choisit de faire une Affero, ce n'est pas tout à fait sans incidence sur la manière dont on va l'utiliser, nous, par rapport à une GPL par exemple, une GPL simple. L'avantage des licences qu'on cible, c'est-à-dire l'EUPL européenne6 et puis la licence CeCILL française, c'est qu'elles ont un régime de compatibilité extrêmement large, et elles permettent, quand même, de quasiment faire à peu près ce qu'on veut en intégrant les briques qui existent sans que ça ne pose de points de blocage. Elles ont vraiment cet avantage d’être très ouvertes et très faciles à intégrer.

Thierry Aimé : Alors, le RGI.

Frédéric Couchet : Voilà. Donc tu as dit que, à Bercy, vous utilisiez exclusivement LibreOffice. Moi j'ai une question plutôt sur le format. Dans la dernière version du RGI, le format ODF est mis en recommandé, et OOXML vient d’être ajouté en toléré, mais pour un cas particulier qui est le « besoin d'échanges d'informations sous forme de tableaux ». Et je me demandais si tu savais à quel cas particulier d'usage ça pouvait correspondre. Mon intuition étant que ça pouvait être un des services de Bercy qui pourrait être contraint d'utiliser ce format pour des raisons, peut-être, d'échange d'informations avec des pays comme les États-Unis ou autres, je ne sais pas. Enfin, est-ce que tu as une idée de ce cas d'usage précis qui est cité dans le RGI 1.9.97 ?

Thierry Aimé : Je crois que c'est pour les comptes de l’État. Quel est l'organisme qui certifie ? Ce n'est pas la Cour des comptes ? Je crois que la Cour des Comptes, en particulier, utilise encore beaucoup de tableaux et donc on est amenés à produire un certain nombre de résultats, d'éléments financiers, dans ce format. Je sais que ça, en tout cas, c'est un élément. Je ne crois pas, non, de contraintes extérieures. Il faudrait voir avec l'INSEE, parce que, au niveau européen, peut-être, qu'à l'INSEE on leur demande des formats. Enfin bon, comme d'habitude, ce sujet des formats est très compliqué. C'est un sujet, en plus, à rebondissements. Il n'est pas terminé. En tout cas donc, aujourd’hui, dans la réalité il reste encore un nombre substantiel d’utilisations, enfin un nombre encore non négligeable d'utilisations du format, des formats Microsoft, mais enfin ça tend quand même à diminuer. Parce que, de fait, aujourd’hui sur les postes de ma direction, l’essentiel des postes n'ont plus que LibreOffice. Donc, de toutes façons, la source va se tarir, je pense, un peu, au fil du temps, et, au final, il va rester un usage relativement cantonné, quelques utilisateurs, très gros utilisateurs. C'est vrai que c'est Calc qui pose le plus de problèmes.

Public : Inaudible.

Thierry Aimé : Collectivités, oui, avec lesquelles on peut avoir à échanger. Je ne sais pas où elles en sont, effectivement, si elles migrent beaucoup.

Public : Inaudible.

Public : Pas du tout ? Dommage.

Applaudissements