« Usage du logiciel libre dans l'administration » : différence entre les versions
(mise à jour) |
|||
(62 versions intermédiaires par 9 utilisateurs non affichées) | |||
Ligne 1 : | Ligne 1 : | ||
{{Introduction|Circulaire sur les usages du logiciel libre}} | {{Introduction|Circulaire sur les usages du logiciel libre}} | ||
{{Tache|960}} | |||
{{Travail publié|adresse_publication=http://www.april.org/circulaire-ayrault-sur-le-bon-usage-des-logiciels-libres-dans-ladministration-francaise}} | |||
Résultat du passage dans un logiciel de reconnaissance optique de caractères (OCRFeeder) du fichier http://circulaire.legifrance.gouv.fr/pdf/2012/09/cir_35837.pdf | Résultat du passage dans un logiciel de reconnaissance optique de caractères (OCRFeeder) du fichier http://circulaire.legifrance.gouv.fr/pdf/2012/09/cir_35837.pdf | ||
Texte à corriger : | |||
J'ai supprimé l'en-tête («Usage du logiciel libre dans l'administration — version finale») et le pied de page («PM/SGG/DISIC #page/18 Septembre 2012»). | |||
Liberté · | Ces éléments sont présents sur tout le document joint à la lettre (ici de la page 3 à la page 19 du document, avec une numérotation de page allant de 2 à 18). | ||
--[[Utilisateur:LowMemory|LowMemory]] ([[Discussion utilisateur:LowMemory|discussion]]) 3 octobre 2012 à 19:34 (CEST) | |||
==Page 1== | |||
{{Introduction|Page 1 relue}} | |||
Liberté · Égalité · Fraternité | |||
RÉPUBLIQUE FRANÇAISE | |||
Le Premier Ministre | |||
5608/SG | 5608/SG | ||
Ligne 13 : | Ligne 25 : | ||
Paris, le 19 septembre 2012 | Paris, le 19 septembre 2012 | ||
à | |||
Mesdames et Messieurs les ministres | Mesdames et Messieurs les ministres | ||
Objet : Orientations pour l' | '''Objet''' : Orientations pour l'usage des logiciels libres dans l’administration | ||
'''P.J.''' : 1 | |||
Les logiciels libres sont des logiciels dont le modèle de propriété intellectuelle est conçu | Les logiciels libres sont des logiciels dont le modèle de propriété intellectuelle est conçu | ||
pour donner | pour donner à l’utilisateur une grande liberté d’utilisation, de modification et de diffusion. Ils | ||
couvrent un domaine d’emploi très large, | couvrent un domaine d’emploi très large, à la fois dans les entreprises privées et dans les | ||
administrations. On peut citer notamment le développement d’applications, les bases de données, | administrations. On peut citer notamment le développement d’applications, les bases de données, | ||
les systèmes | les systèmes d’exploitation des serveurs, les suites bureautiques et la messagerie. | ||
Au sein de l'administration, on constate une longue pratique de leur usage qui a permis le | Au sein de l'administration, on constate une longue pratique de leur usage qui a permis le | ||
développement de compétences et la capitalisation de nombreuses expériences positives. Celles-ci | développement de compétences et la capitalisation de nombreuses expériences positives. Celles-ci | ||
ont notamment démontré les atouts du logiciel libre (moindre coût, souplesse d’utilisation, levier | ont notamment démontré les atouts du logiciel libre (moindre coût, souplesse d’utilisation, levier | ||
de discussion avec les éditeurs). | de discussion avec les éditeurs). | ||
Après plusieurs années au cours desquelles la question de l’usage du logiciel libre a pu | Après plusieurs années au cours desquelles la question de l’usage du logiciel libre a pu | ||
faire | faire l’objet de nombreuses discussions, il est désormais possible de retenir une série d’orientations | ||
et de recommandations sur le bon usage du logiciel libre. C’est l’objet du document joint en | et de recommandations sur le bon usage du logiciel libre. C’est l’objet du document joint en | ||
annexe, préparé avec les directeurs des systèmes d’information de vos ministères, dans le cadre | |||
d’un travail animé par la direction interministérielle des | d’un travail animé par la direction interministérielle des systèmes d’information et de | ||
communication. Je vous demande de mettre en | communication. Je vous demande de mettre en œuvre, au sein de vos services, les orientations | ||
définies dans le document joint. | définies dans le document joint. | ||
Jean—Marc AYRAULT | |||
Hôtel de Matignon - 57. | Hôtel de Matignon - 57. rue de Varenne - 75007 Paris - Tél. 01 42 75 80 00 | ||
==Page 2== | |||
{{Introduction|Page 2 relue}} | |||
Liberté • Égalité • Fraternité | |||
RÉPUBLIQUE FRANÇAISE | RÉPUBLIQUE FRANÇAISE | ||
PREMIER MINISTRE | PREMIER MINISTRE | ||
SECRÉTARIAT GÉNÉRAL DU GOUVERNEMENT | SECRÉTARIAT GÉNÉRAL DU GOUVERNEMENT | ||
DIRECTION INTERMINISTÉRIELLE DES SYSTÈMES | DIRECTION INTERMINISTÉRIELLE DES SYSTÈMES | ||
D'INFORMATION ET DE COMMUNICATION | |||
Usage du Logiciel libre | Usage du Logiciel libre | ||
dans l'administration | dans l'administration | ||
Septembre 2012 | Septembre 2012 | ||
==Page 3== | |||
Table des matières | |||
==Page 4== | |||
{{Introduction|Page 4 relue}} | |||
1. | 1. OBJECTIF DU DOCUMENT | ||
OBJECTIF DU DOCUMENT | |||
Une longue pratique de l'usage du logiciel libre a permis le développement de compétences et la | Une longue pratique de l'usage du logiciel libre a permis le développement de compétences et la | ||
Ligne 74 : | Ligne 91 : | ||
savoirs et la définition d'orientations communes permettrait de franchir une nouvelle étape, pour gagner en | savoirs et la définition d'orientations communes permettrait de franchir une nouvelle étape, pour gagner en | ||
efficacité opérationnelle et économique. | efficacité opérationnelle et économique. | ||
Dans le cadre des travaux interministériels lancés par la DISIC, un groupe de travail, piloté par la DSI du | Dans le cadre des travaux interministériels lancés par la DISIC, un groupe de travail, piloté par la DSI du | ||
ministère de la culture et de la communication, a été chargé de définir les orientations nécessaires a l’usage | ministère de la culture et de la communication, a été chargé de définir les orientations nécessaires a l’usage | ||
du logiciel libre dans les ministères. | du logiciel libre dans les ministères. | ||
Ce document présente, | |||
Ce document présente, après des rappels sur le contexte d’émergence du logiciel libre et sur le modèle de | |||
propriété intellectuelle associé, les orientations issues des premiers travaux, précisant notamment les | propriété intellectuelle associé, les orientations issues des premiers travaux, précisant notamment les | ||
environnements dans lesquels son usage est approprié, décrivant les actions communes lancées et les | environnements dans lesquels son usage est approprié, décrivant les actions communes lancées et les | ||
instances de travail créées. | instances de travail créées. | ||
'''Statut du document''' : <em>Ce document est basé sur les travaux du groupe interministériel d’experts. Il a été | |||
revu en CTSIC du 21juin 2012 pour validation, diffusion et mise en œuvre effective.</em> | |||
==Page 5== | |||
{{Introduction|Page 5 relue}} | |||
2.ORIGINES ET FONDEMENTS DU LOGICIEL LIBRE | |||
2. | 2.1. Contexte de développement de la position du logiciel libre | ||
Le logiciel libre a conquis une grande part des infrastructures techniques et prend une place de plus en plus | Le logiciel libre a conquis une grande part des infrastructures techniques et prend une place de plus en plus | ||
importante dans tous les | importante dans tous les systèmes d'information jusqu‘aux terminaux. Les standards Internet ont créé un | ||
contexte commun sur lequel de plus en plus de productions logicielles se sont appuyées, devenant | contexte commun sur lequel de plus en plus de productions logicielles se sont appuyées, devenant | ||
interchangeables. De nombreux logiciels sont maintenant des | interchangeables. De nombreux logiciels sont maintenant des « utilités » avec une valeur d'innovation | ||
limitée, et les clients acceptent de moins en moins de payer un prix élevé pour des produits jugés communs | |||
et rentabilisés, et d' | et rentabilisés, et d'être liés a un fournisseur. | ||
Désormais, pour répondre aux besoins métiers, le logiciel libre doit être considéré a égalité avec les | |||
solutions C'est dans cette | autres solutions C'est dans cette évolution que s'inscrit l‘usage du logiciel libre dans l'administration. | ||
2.2. Le | 2.2. Le modèle du logiciel libre | ||
Le logiciel libre est un | |||
Le logiciel libre est un modèle de propriété intellectuelle prenant différentes formes, dont les principes | |||
sont de : | sont de : | ||
* garantir la '''liberté d'exécuter le programme''', pour tous les usages ; | |||
* garantir la '''liberté d'étudier le fonctionnement du programme et de l'adapter''' a ses besoins ; | |||
* garantir la '''liberté de redistribuer de copies du programme'''; | |||
* permettre '''d‘améliorer le programme et de distribuer ces améliorations au public''', pour en faire profiter toute la communauté ; | |||
Tout ceci implique bien | |||
Cette vision | Tout ceci implique bien sur que le code source doit être librement accessible. | ||
encore | Cette vision très ouverte, a permis la mise en place de groupe d’intérêts sur certains logiciels libres, ou | ||
encore « souches», et a amené a développer un modèle de développement en communautés dont les plus | |||
( | connues de nos jours sont GNU/Linux, Apache, Mozilla (Firefox, Thunderbird), Document Fondation | ||
Ces principes | (LibreOffice). | ||
Ces principes donnent certaines caractéristiques au logiciel libre : | |||
* comme tout modèle de propriété intellectuelle, il tend à s'auto-entretenir | |||
Le logiciel libre le plus diffuse l‘est selon le mode dit << copyleft » de la licence GNU GPL. Dans son | Le logiciel libre le plus diffuse l‘est selon le mode dit << copyleft » de la licence GNU GPL. Dans son | ||
principe il | principe il empêche celui qui utilise le code de s’approprier l'effort de la communauté sans rien lui reverser | ||
des améliorations ou des corrections. La contribution a l'effort collectif devient un principe et permet de | des améliorations ou des corrections. La contribution a l'effort collectif devient un principe et permet de | ||
maintenir la dynamique de développement. | maintenir la dynamique de développement. | ||
* l'évolution d’un logiciel libre est orientée par le besoin utilisateur | |||
Une communauté n'a pas | Une communauté n'a pas intérêt a développer une fonction qui n'est utile qu'a très peu d‘utilisateurs au sein | ||
d’un logiciel libre. Alors que le changement de version régulier chez l’éditeur est | d’un logiciel libre. Alors que le changement de version régulier chez l’éditeur est difficilement maîtrisable | ||
pour | pour l'utilisateur, la stabilité est une qualité pour un logiciel libre. La règle est donc la mise en commun des | ||
besoins et la priorisation des évolutions. | besoins et la priorisation des évolutions. | ||
* le modèle garantit que la communauté puisse conserver le contrôle | |||
Dans certaines communautés libres, des acteurs du logiciel propriétaire sont | Dans certaines communautés libres, des acteurs du logiciel propriétaire sont très actifs. L’intérêt propre de | ||
leur société peut les amener a orienter les développements en s'éloignant de l' | leur société peut les amener a orienter les développements en s'éloignant de l'intérêt de la communauté. Le | ||
modèle libre permet alors a une partie de celle-ci de faire ce que l'on nomme un « fork », c'est-à-dire | |||
repartir du code source du moment dans une autre direction de développement. | repartir du code source du moment dans une autre direction de développement. | ||
==Page 6== | |||
{{Introduction|Page 6 relue}} | |||
* le modèle permet de créer l'émulation nécessaire à la créativité | |||
Que cela soit au travers de "fork" ou en s'appuyant sur l'ensemble des logiciels libres existants, ceux qui | |||
sont sûrs d'avoir une bonne idée peuvent toujours se lancer avec un faible investissement et réunir une | |||
communauté autour de cette idée. C'est ainsi que de nombreuses souches se créent eu permanence, seules | |||
survivant celles qui sont suffisamment pertinentes pour être portées par un grand nombre de développeurs | |||
et d'utilisateurs. | |||
Contrairement aux idées | Contrairement aux idées reçues, '''le recours à des logiciels libres ne signifie en rien qu’il n’y a aucune obligation à respecter pour les utilisateurs. Un logiciel libre n’est pas libre de droit''' puisqu’il a un | ||
obligation | |||
créateur. Les initiateurs du logiciel libre, réalistes, se sont insérés dans le monde du droit en formulant dans | créateur. Les initiateurs du logiciel libre, réalistes, se sont insérés dans le monde du droit en formulant dans | ||
des licences les droits et obligations | des licences les droits et obligations s'appliquant. Plusieurs grands types de licences ont été définis dont les | ||
principales sont la Gnu General Public Licence (GPL), la Berkeley Software Distribution (BSD) et la | principales sont la Gnu General Public Licence (GPL), la Berkeley Software Distribution (BSD) et la | ||
licence Apache. | licence Apache. Il en existe aussi une en droit français, la licence CEA CNRS INRIA Logiciel Libre | ||
(CECILL). Les caractéristiques juridiques (effet ou non héréditaire, multilicensing, droit applicable, | (CECILL). Les caractéristiques juridiques (effet ou non héréditaire, multilicensing, droit applicable, | ||
garanties) varient en fonction de leur auteur, mais ces licences sont toutes des objets de droit positif et fort, | garanties) varient en fonction de leur auteur, mais ces licences sont toutes des objets de droit positif et fort, | ||
reconnu en justice. | reconnu en justice. | ||
Lorsqu'on télécharge une licence de logiciel libre, on se retrouve dans le cadre d’un contrat | |||
c'est- | Lorsqu'on télécharge une licence de logiciel libre, on se retrouve dans le cadre d’un contrat d'adhésion, | ||
sont imposées par l' | c'est-à-dire dans la même situation qu’en cas d’achat d’un logiciel propriétaire. Les clauses de la licence | ||
faire ce qui y est mentionné, soit il ne peut pas bénéficier de toutes | sont imposées par l'auteur et ne sont pas négociables. Au final, soit le licencié accepte la licence et peut | ||
faire ce qui y est mentionné, soit il ne peut pas bénéficier de toutes les libertés inhérentes au logiciel libre | |||
(modification et distribution). | (modification et distribution). | ||
2.3. Le libre, un | C'est un des points importants et pourtant souvent négligés du logiciel libre: '''il convient de connaître les obligations associées a un logiciel libre en particulier dans le cadre d'une utilisation dans un système d'information professionnel.''' | ||
Si les droits sur le logiciel libre ne sont associés | |||
qu'il n'en | |||
2.3. Le libre, un modèle de service | |||
En effet, | |||
s'assurer de son maintien en conditions | Si les droits sur le logiciel libre ne sont associés à aucune compensation financière, cela ne veut pas dire | ||
qu'il n'en coûte rien de mettre en œuvre et d’utiliser du logiciel libre, en particulier dans le domaine | |||
faisant appel a des sociétés de service, dont certaines spécialisées | professionnel. | ||
de Logiciel Libre | |||
On remplace | En effet, comme pour tout logiciel, il est nécessaire de l'intégrer dans son système d'information et de | ||
service | '''s'assurer de son maintien en conditions opérationnelles (support, maintenance) ainsi que de le faire évoluer en fonction des besoins.''' Ces tâches doivent être couvertes soit par de la charge interne soit en | ||
critiques il conviendra d'avoir un support fort et réactif, en général | faisant appel a des sociétés de service, dont certaines spécialisées s’affichent comme "Sociétés de Services | ||
le support au travers de la communauté | de Logiciel Libre" (SSLL). | ||
Quoi qu'il en | |||
d'usage (nombre de serveurs installés, | On remplace donc un modèle "coût de licence/coût de maintenance" sur licences, par un modèle "coût de | ||
service" à façon qui peut être adapté aux besoins réels de l'entité utilisatrice. '''Sur des infrastructures critiques il conviendra d'avoir un support fort et réactif''', en général externalisé, dans d'autres contextes | |||
A cet avantage essentiel, s'ajoutent les avantages | le support au travers de la communauté pourra suffire. | ||
remise en concurrence | |||
Quoi qu'il en soit, les coûts dans le modèle de service du logiciel libre sont peu sensibles à la volumétrie | |||
d'usage (nombre de serveurs installés, nombres d'utilisateurs simultanés...). Il se prête donc bien à une | |||
mutualisation et favorise une concentration des usages en interministériel. | |||
A cet avantage essentiel, s'ajoutent les avantages d'indépendance vis a vis des acteurs externes. En effet une | |||
remise en concurrence régulière des sociétés de services, pouvant toutes intervenir sur les souches libres, | |||
permet de rester dans les prix du marché. | permet de rester dans les prix du marché. | ||
Il est important à ce sujet de relever que le Conseil d’État a validé ce principe de libre concurrence, dans un | |||
modèle de service autour des souches libres, dans l'arrêt n°350431 du 30 septembre 2011. | |||
possible par tous | '''L’administration peut choisir unilatéralement une solution libre,''' étant entendu que son utilisation est | ||
possible par tous les acteurs et que ceux-ci peuvent donc fournir sans entrave extérieure une offre de service | |||
adaptée. | adaptée. | ||
==Page 7== | |||
{{Introduction|Page 7 relue}} | |||
3. LE LIBRE, UN CHOIX RAISONNÉ | |||
Le logiciel libre a été porté à l'origine par une philosophie d'ouverture et par des «pionniers militants» qui ont rendu les utilisateurs plus institutionnels, qu'ils soient publics ou privés, méfiants par rapport à cette approche. | |||
Aujourd'hui le choix du logiciel libre dans l'administration n'est pas un engagement idéologique, mais le fruit d'un choix raisonné. Les motivations sont multiples, mais on retiendra principalement : | |||
* la contrainte de plus en plus forte sur les moyens d'investissement et de fonctionnement des SI, concomitante avec une forte augmentation de la demande ; | |||
* la valorisation des compétences et de l'expertise professionnelle des équipes informatiques, qui ne sont pas de simples acheteurs de solutions. | |||
3. | 3.1. Avantages | ||
En fonction des cas d'usage, les avantages suivants peuvent être apportés par le logiciel libre, dans le contexte public : | |||
* le logiciel libre n'est pas gratuit mais souvent '''moins cher''', et surtout son coût est modulable en fonction de la criticité des systèmes ; | |||
* le logiciel libre est piloté par les besoins, '''minimisant les évolutions superflues''' ; | |||
* le logiciel libre permet de gérer les versions selon son contexte, et même de se fixer sur une version en assurant son '''support à long terme''' ; | |||
* le logiciel libre facilite '''les expérimentations et l'adaptation''' au volume d'usage, l'absence de droit d'usage permettant de varier fortement sans contrainte ; | |||
* le logiciel libre facilite la '''mutualisation entre acteurs publics''' que cela soit dès l'expression de besoins ou en capitalisant sur des souches existantes ; | |||
* le logiciel libre apporte une '''transparence accrue''' dans la définition et l'animation de politique de sécurité des systèmes d'information, avec une exigence et un coût adaptable par le choix du niveau de | |||
support ; | |||
* le logiciel libre permet une '''réelle mise en concurrence''', par l'achat de services auprès de sociétés mises sur un pied d'égalité par la publication des sources. | |||
Appliqué au contexte de la commande publique, le recours au logiciel libre offre l'opportunité de favoriser le principe de mise en concurrence et d'ouverture à la commande publique dans l'achat de logiciels et de services. Le juge a bien précisé qu'un pouvoir adjudicateur pouvait, sans remettre en cause les principes de l'achat public, organiser une mise en concurrence fondée sur une solution libre choisie unilatéralement par l'administration (Arrêt du Conseil d'Etat n°350431 du 30 septembre 2011). | |||
3.2. Limites/points d'attention | |||
Le logiciel libre a aussi ses limites et doit faire l'objet de quelques points d'attention : | Le logiciel libre a aussi ses limites et doit faire l'objet de quelques points d'attention : | ||
* le logiciel libre est '''lié à une communauté :''' il convient donc de connaître et de suivre cette communauté pour s'assurer de la pérennité et du sérieux de la solution ; | |||
communauté | * les licences libres n'emportent pas une absence de droit de la propriété intellectuelle, mais '''une autre forme de droit''', qu'il faut gérer, en particulier dans le développement ; | ||
* pour le simple utilisateur final, l'effet de marque et de marketing vaut aussi dans le logiciel, et le logiciel libre n'ayant pas de prix est parfois jugé sans valeur ; | |||
forme | |||
logiciel libre n'ayant pas de prix est parfois | |||
==Page 8== | |||
{{Introduction|Page 8 relue par Cpm}} | |||
* la possibilité de contribuer au développement du logiciel par l'accès au code source ne doit pas donner la '''tentation de multiplier les ajouts de code spécifique''', au risque de perdre le lien avec la souche communautaire et d‘avoir à supporter une solution isolée sur le long terme. Une démarche d‘analyse de la valeur de l'écart au « standard » s’impose avec rigueur ; | |||
* la participation à la dynamique du libre est liée à la contribution, l'utilisateur, surtout professionnel, ne peut se limiter à profiter du système ; il doit '''entretenir le modèle par réinjection d'une part de ses gains''' sous une forme ou une autre ; | |||
* certains éditeurs jouent à la marge du modèle du logiciel libre, en gérant une version dite « entreprise » ou « premium » sous licence classique propriétaire et une version dite « communautaire » sous licence libre, mais qui est en général en retard sur l'autre version. C‘est le modèle dit du « Freemium ». '''Ces souches, portées par un éditeur plus que par une communauté, doivent être utilisées avec prudence''' car elles risquent toujours de rebasculer dans un mode propriétaire. | |||
3.3. Les différents contextes d'usage | 3.3. Les différents contextes d'usage | ||
Quand on décide de développer un système d'information, le choix d'utiliser du logiciel libre, voire de développer selon le modèle libre, doit être analysé selon des critères prenant en compte le cadre d'utilisation, le nombre d'acteurs concernés, la complexité du système et l'implication nécessaire. | |||
3.3.1 Les cadres favorables au modèle libre | |||
3.3.1.1. Un logiciel libre existant et internationalement reconnu | |||
Certains logiciels libres sont tenus par une communauté déjà très forte avec de nombreux utilisateurs (JBoss, Firefox...). Dans certains cas le logiciel libre devient incontournable comme par exemple pour le serveur web Apache qui est utilisé par près de 60% du parc installé (fin 2011). | |||
Dans ce cas, '''la réduction des coûts est directe, et le produit est immédiatement utilisable''' et souvent suffisamment supporté au travers de la communauté. Il reste cependant possible de se mettre en lien avec la communauté de développement pour remonter le cas échéant les rapports de dysfonctionnement et contribuer à l'amélioration du logiciel. | |||
Des exemples de ce contexte sont omniprésents et conduisent au déploiement de plus en plus important dans le secteur public comme privé de grandes souches libres : Linux, Apache, Firefox, Thunderbird, JBoss, OpenSSL, Eclipse... | |||
Dans le cas des logiciels pour les utilisateurs finals, il conviendra toutefois d'assurer une '''conduite du changement''' pour préparer l'introduction d'un nouveau logiciel, surtout s'il vient remplacer une solution largement utilisée. Ceci doit être intégré au calcul économique. | |||
3.3.1.2. Un déploiement de logiciel sur une grande infrastructure | |||
Dans certains grands systèmes ou pour certaines applications destinées aux utilisateurs, il est nécessaire d'acheter un grand nombre de licences. Des milliers de licences de base de données ou de systèmes d'exploitation peuvent entraîner des coûts substantiels. | |||
Il peut dès lors être rentable de supporter directement voire d‘améliorer une souche libre existante et de participer à la maintenance de cette souche. Cet investissement peut être ensuite utile pour tout autre acteur public. | |||
Un exemple d'usage des logiciels libres dans un système d’information critique d’une direction ministérielle a permis de diviser par 10 les coûts de fonctionnement des applicatifs. Cette réduction nette des coûts a été obtenue en mettant en place un marché de maintenance dans des conditions très strictes (délais de 48h de résolution...) sur plus de 100 souches logicielles. | |||
Quand il s'agit de postes utilisateurs, le déploiement de nouvelles briques ou de mises à jours peut se faire | |||
de manière homogène sur l'ensemble du parc, sans coût particulier (pas de rachats de licences, pas d’achat de licence évolutive), ce qui facilite le maintien de l'homogénéité du parc et induit une baisse des coûts de support utilisateurs et une augmentation de la qualité. | |||
==Page 9== | |||
{{Introduction|Page 9 relue}} | |||
3.3.1.3. Un logiciel utilisé dans un contexte virtualisé ou à forte variation de charge | |||
Dans une logique comparable, '''le déploiement dans un contexte virtualisé simplifie la création de serveurs logiques et l'adaptation de leur nombre ou de la puissance processeur accordée'''. La gestion et le paiement des licences propriétaires peuvent être soit un frein à cette adaptabilité, soit un générateur de complexité et de coût qui n'est pas optimisé. En effet les licences propriétaires ont des coûts liés à la puissance physique maximale utilisée. | |||
A contrario, le coût de support, interne ou externe, du logiciel libre n'est pas modifié par l'intensité de l'usage et dépend de l'exigence en qualité de service. Il est donc lié a la criticité de l'usage. Dans la plupart des cas, comme le démontre le marche de support interministériel récemment notifié, il sera très inférieur au coût de licences couvrant le déploiement en pointe de charge. | |||
3.3.1.4. Un logiciel utilisé dans le contexte du développement agile | |||
Le '''développement agile''' est par définition «opportuniste» et ajoute des fonctions au fur et à mesure de la définition des besoins en rapport avec les utilisateurs. Ce mode de développement permet aussi de procéder, d'une manière limitée, par «essais/erreurs». Il est donc difficile d'avoir une vision précise d'entrée sur les bases logicielles qui sont utiles et qui devront être intégrées. | |||
L'usage du logiciel libre permet de «piocher» au fur et à mesure du développement dans les souches disponibles, dans un cadre technologique propre à chaque entité, en fonction de leur adéquation, sans question de droit d'usage dans la phase de développement ni dans la phase d'exploitation. | |||
3.3.1.5. Face à des situations de faible concurrence | |||
Certains produits d'éditeur ont de moins en moins d'alternatives commerciales crédibles, le leader du marché ayant éliminé la concurrence. Le logiciel libre apporte alors des possibilités alternatives. | |||
Certaines souches ont un niveau fonctionnel élevé et peuvent '''remplacer des logiciels propriétaires avec un coût limité''' au support assuré de manière forfaitaire et aussi mutualisé que possible. Les systèmes Linux ont ainsi clairement montré leur intérêt. | |||
D'autres ont un contour fonctionnel un peu moins riche que le logiciel d'éditeur et ont vocation à '''être sélectionnées lorsque les fonctions complexes spécifiques aux solutions propriétaires ne sont pas absolument nécessaires'''. C'est par exemple le cas dans le domaine des bases de données où PostgreSQL constitue une alternative souvent pertinente et à développer. | |||
Il est à remarquer que les éditeurs de solutions progicielles (grands PGI, ...) favorisent généralement l'utilisation de composants d'architectures propriétaires (OS, SGBD) en ne garantissant la compatibilité qu'avec ceux-ci. Même si certaines solutions libres, et en particulier Linux, rentrent dans les matrices de compatibilité supportées, '''une attention particulière doit être portée à ce point au moment du choix d'une solution progicielle''' qui peut par cette voie limiter les choix technologiques et induire des surcoûts cachés. | |||
Les ministères financiers ont démontré l'intérêt de l'utilisation du logiciel libre dans ce contexte, dans le cadre de la reprise d'une application en Cobol. L'usage d'OpenCobol leur a permis de réduire le coût d'un facteur supérieur à 10. | |||
3.3.1.6. Un même besoin à traiter par de nombreux acteurs publics | |||
Des besoins liés au métier ou à la réglementation sont communs à de nombreux acteurs publics. Dans ce contexte, il est particulièrement contre-productif que chaque acteur conduise ses développements spécifiques de son côté, et en paye la totalité au lieu de partager la charge du développement. Que cela soit pour développer un système de gestion d'aide au niveau local ou une plate-forme de dématérialisation des marchés publics, il est aisé de voir qu'une association des acteurs facilitée par le modèle libre sera profitable à chacun. | |||
Certaines collectivités territoriales ont compris ce point et ont mis en place des associations ayant pour objet de '''fédérer leurs développements''' selon le modèle libre comme l'ADULLACT. | |||
On constate d'ailleurs une augmentation remarquable de la qualité technique des développements réalisés en vue de publication sous licences libres comparativement aux développements spécifiques réalisés précédemment. C'est aussi un effet positif de l'ouverture du contenu du développement à l'externe. | |||
==Page 10== | |||
{{Introduction|Page 10 relue}} | |||
3.3.1.7. Un déploiement dans des contextes multiples d'acteurs publics ou privés | |||
Certaines fonctions de l'État appellent des applications ou des systèmes d'interfaçage utilisables par des acteurs très nombreux, ne serait-ce que les différents types de collectivités territoriales. Par exemple la comptabilité publique induit des échanges de relevés comptables formatés avec les ordonnateurs locaux. Ces fonctions doivent pouvoir être intégrées aux systèmes de ces partenaires et donc être utilisées parfois par les éditeurs. | |||
Avoir des licences d'utilisation ouvertes sur des populations aussi larges, et qui permettent une intégration large, revient presque à avoir une licence libératoire, ce qui dans le modèle propriétaire est en général très cher, car contraire a sa logique. Qui plus est dans ce contexte il n'est pas facile à l'État de payer tout ou partie pour tous les acteurs publics. Dans le modèle libre il ne s'agit que de la licence normale qui de toute façon ne nécessite aucun contrô1e de la diffusion. La '''simplicité de gestion, la réduction des coûts et la commodité de réutilisation''' sont évidentes. | |||
Des exemples de contextes éligibles sont donnés par les systèmes développés par l'État en lien avec de nombreux partenaires, comme par exemple Xemelios de la DGFiP, pour le traitement des fichiers de dématérialisation de la chaîne comptable et financière. | |||
3.3.2 Les contextes défavorables au modèle libre | |||
3.3.2.1. Petit nombre d'acteurs concernés par la mise en œuvre | |||
3.3.2.1. Petit nombre d'acteurs concernés par | |||
Le développement selon le modèle libre nécessite pour être utile de mettre en place une communauté de contributeurs qui échangent et mutualisent leurs efforts. Si les entités concernées ou devant maîtriser le développement d'un logiciel sont peu nombreuses et mal identifiées, il est moins utile d'en libérer le développement. Il convient cependant d'être prudent et il peut être utile de garder la possibilité de le faire si un besoin émerge par la suite. | |||
3.3.2.2. Système complet et complexe (non modulaire) | |||
Le principe de mutualisation qui sous-tend le modèle libre va de pair avec une approche modulaire dans le développement et la conception des systèmes d'information. Les briques et modules, plus facilement abordables par de nouveaux entrants, plus facilement réutilisables dans de nombreux systèmes, plus légers à maintenir, sont plus éligibles au modèle libre. | |||
A contrario, les systèmes complets et complexes sont parfois si difficiles a gérer qu'ils requièrent un professionnel dédié, c'est à dire un éditeur... C'est notamment le cas des systèmes de gestion tels les PGI généralistes. | |||
4. | Il convient toutefois de souligner que les principes d'urbanisation et de bonne gestion de l'évolution des systèmes d'information incitent à limiter l'usage de systèmes monolithiques pour favoriser la modularité qui correspond au modèle libre. | ||
Pour faciliter le recours | |||
positionner au | ==Page 11== | ||
de qualité, | |||
4.1. Instaurer une convergence effective sur des | {{Introduction|Page 11 relue}} | ||
Le principe fondateur du logiciel libre est la mise en commun des efforts. La concentration des acteurs sur | 4. L'ACTION INTERMINISTÉRIELLE SUR LE LOGICIEL LIBRE | ||
certaines souches est un gage d'efficacité. Ainsi les efforts de développement d'expertise, les | |||
corrections de | Pour faciliter le recours à des solutions «logiciel libre» dans les choix des administrations, et ainsi le positionner au même niveau que les autres offres, tout en dégageant le maximum d'efficacité économique et de qualité, l'État doit agir de façon concertée et coordonnée, selon les modalités détaillées ci-après. | ||
Un cadre de convergence des souches | |||
l' | 4.1. Instaurer une convergence effective sur des souches de logiciels libres | ||
Ce cadre ne fait pas obstacle | Le principe fondateur du logiciel libre est la mise en commun des efforts. La concentration des acteurs sur certaines souches est un gage d'efficacité. Ainsi les efforts de développement d'expertise, les coûts de corrections de «bugs», parfois à la charge de l'utilisateur, voire d'évolution, sont mutualisés. | ||
évolution. Il ne rend pas non plus obligatoire l'évolution adaptative des applications existantes non | |||
conformes. En revanche, il | Un '''cadre de convergence des souches''' à privilégier dans le développement des systèmes d'information de l'État, '''défini en 2012''', est désormais maintenu en concertation interministérielle. Il touche en priorité les systèmes les plus déployés, sur les serveurs comme sur les postes bureautiques. | ||
Ce cadre est aussi une composante indispensable | Ce cadre ne fait pas obstacle à l'innovation par essai de nouvelles souches, qui pourront aider à son évolution. Il ne rend pas non plus obligatoire l'évolution adaptative des applications existantes non conformes. En revanche, il définit des versions de référence à privilégier et indique les solutions à abandonner, avec des réserves éventuelles pour des contextes d'usage particuliers. | ||
et | |||
des | Ce cadre est aussi une composante indispensable à la convergence progressive des contextes d'exploitation et à la mutualisation de certains moyens. À ce titre il doit être intégré dans tous les cadres technologiques des ministères et pris en compte à l'occasion de nouveaux développements et de refontes majeures. | ||
'''Chaque ministère doit participer au maintien à jour de ce cadre et à son renforcement progressif. En particulier il déclarera régulièrement l'usage fait des souches du cadre et les usages hors du cadre, pour permettre le suivi de sa prise en compte et la gestion de son évolution.''' | |||
Le cadre de convergence est publié et remis a jour à un rythme trimestriel, en lien avec les marchés de support interministériels, sur l'outil collaboratif de l'équipe «noyau» (cf. organisation). | |||
4.2. Activer un réseau d'expertise sur les souches de convergence | 4.2. Activer un réseau d'expertise sur les souches de convergence | ||
L'efficacité de la mise en commun autour du logiciel libre vient aussi du partage d'expertise et de la montée en compétence sur les souches. Chaque ministère peut difficilement être compétent sur l'ensemble des souches, mais chacun a des compétences. '''La constitution d'un réseau d'experts permet de faire profiter l'ensemble des administrations des expertises ponctuelles nécessaires.''' | |||
Les porteurs de ce type d'expertise sont naturellement volontaires pour le partage et sont valorisés par l'usage de leur compétence. Le plus difficile est d'organiser la mise en relation et d'assurer l'acceptation par la hiérarchie de la charge induite, même limitée, de participation à l'effort interministériel. | |||
Il convient de constituer des réseaux portés par une mise en relation physique événementielle, indispensable à la création d'un échange riche et suivi, et par une mise en relation électronique en travail collaboratif. Plusieurs outils sont mis en place a cette fin : | |||
* les '''groupes de travail thématiques,''' avec rencontre régulière sur les sujets bureautiques (MimO), socle serveur (MimOS), exploitation bureautique (MimOG) et base de données (MimDB) ; | |||
* la '''«journée logiciel libre»''' favorisant l'ouverture à de nouveaux acteurs, et permettant d'ouvrir de nouveaux sujets ou de diffuser largement des retours d'expérience ; | |||
==Page 12== | |||
{{Introduction|Page 12 relue}} | |||
Usage du logiciel libre dans l'administration — version finale | |||
* les '''listes de diffusion''', par groupes thématiques ou sur des thèmes définis, permettant de faire appel dans l'instant au réseau sur des questions précises ; | |||
* les '''sites collaboratifs''' des groupes thématiques pour le partage de ressource (CD de distribution ou valise pédagogique LibreOffice...). | |||
Chaque ministère s'implique dans la démarche commune. | |||
Les réseaux d'expertise, et en priorité les groupes thématiques quand ils existent, sont le creuset de définition et d'évolution du socle de convergence sur leur périmètre de compétence. La liste proposée au cadre de convergence est publiée sur l'outil collaboratif du groupe. | |||
4.3. Améliorer le support des logiciels libres dans un contexte économique contrôlé | |||
Le logiciel libre permet d'adapter sa politique de maintenance en fonction de l'étendue et de la criticité des systèmes. Une grande partie de l'usage du logiciel libre s'est fait sans support particulier, en profitant du support apporté par les communautés. Même si ce moyen reste toujours valable, il est nécessaire, pour un certain nombre d'usages, d'avoir un support réactif avec des engagements de résultat. | |||
Le logiciel libre permet d'avoir des engagements de support supérieurs aux logiciels propriétaires, car le code est à disposition pour correction en interne ou par un prestataire choisi, alors que les éditeurs ont des processus de support normalisés qui ne s'adaptent que partiellement aux besoins du client. Le problème des grands logiciels propriétaires est renforcé par la distance des centres de développement et la complexité des processus de publication de version à l'échelle mondiale. En outre, la politique contractuelle des éditeurs prive généralement le client de la possibilité de négocier le niveau de service standard de l'éditeur, niveau de service par ailleurs très protecteur pour ce dernier. | |||
Les ministères financiers ont démontré la faisabilité et l'efficacité économique de mise en place d'un marché de support par un prestataire de type société de service. '''Au niveau interministériel, un marché a été passé sous l'égide du SAE et sous la direction du ministère de l'intérieur pour couvrir les besoins des autres ministères'''. Il prévoit des mécanismes de réduction des coûts quand plusieurs acteurs demandent du support pour une même souche (plus précisément pour les mêmes versions d'une souche). Ce marché est donc une incitation supplémentaire à la mise en œuvre du cadre de convergence. | |||
4.4. Contribuer de manière concertée sur des souches choisies | |||
Au travers du marché de support interministériel et du cadre de convergence, l'État concentre désormais son action sur un ensemble de souches et contribuera à leur amélioration en reversant des correctifs aux communautés. Toutefois, pour respecter la logique de la dynamique du libre, il est nécessaire que l'administration contribue aussi directement sur l'enrichissement fonctionnel de certaines souches, en particulier sur celles avec lesquelles il fait le plus d'économies. En réinjectant une faible part de la dépense évitée, les ministères pourraient avoir une action significative d'amélioration de l'offre au profit de tous. | |||
'''Une règle simple à appliquer serait de réinjecter systématiquement de 5 à 10% des coûts de licences évités. Cela permet de contribuer de manière utile dans tous les cas, de ne pas mettre en risque le gain économique d'usage du libre, sans pour autant faire systématiquement une étude poussée de gain complet.''' | |||
Cette contribution peut prendre de nombreuses formes : | |||
* dans les marchés utilisant des logiciels libres, veiller à rendre possible la reprise des éventuelles évolutions de souches par la communauté, facilitant ainsi leur suivi par la communauté et évitant une maintenance spécifique ; | |||
==Page 13== | |||
{{Introduction| Page 13 relue par vinux, LowMemory}} | |||
* envisager le financement de conventions de recherche pour ajout de fonctions évoluées pouvant faire | |||
l'objet de travaux universitaires (par exemple un correcteur grammatical polyglotte pour une suite | |||
bureautique) ; | bureautique) ; | ||
* étudier le financement par des fonds sur l'accessibilité pour l'amélioration de logiciel sur les postes de | |||
travail ; | travail ; | ||
* mettre en place un marché d'expertise et d'évolution de souches, qui au travers d'un prestataire verse | |||
aux | aux communautés ; | ||
* et bien sûr favoriser l'implication à titre professionnel d'agents, souvent passionnés à titre personnel, | |||
dans certaines communautés. Cette implication peut porter sur le code, mais aussi sur des domaines | dans certaines communautés. Cette implication peut porter sur le code, mais aussi sur des domaines | ||
moins techniques comme la traduction, la | moins techniques comme la traduction, la documentation… | ||
Dans la | |||
d' | '''Dans la foulée du marché de support interministériel, le MI et le SAE mettent en place un marché | ||
d'expertise et d'évolution de souches qui pourra être la base de contributions concertées et partagées | |||
s' | interministérielles.''' Cette action aura d'autant plus de poids qu'un grand nombre de ministères | ||
concentration des achats qui ne favorise pas la montée | s'associeront. L‘existence d'un deuxième marché permettra en outre de limiter l'effet négatif de la | ||
concentration des achats qui ne favorise pas la montée en puissance de multiples grands acteurs du logiciel | |||
libre. | libre. | ||
4.5. Suivre les grandes communautés | 4.5. Suivre les grandes communautés | ||
De | |||
De même que les éditeurs logiciels maintiennent des contacts réguliers avec tous les ministères pour | |||
actualiser la connaissance de leurs produits, permettre d'en anticiper les changements voire recueillir les | actualiser la connaissance de leurs produits, permettre d'en anticiper les changements voire recueillir les | ||
besoins, il est indispensable d'avoir des liens avec les grandes communautés comme la Mozilla Fondation, | besoins, il est indispensable d'avoir des liens avec les grandes communautés comme la Mozilla Fondation, | ||
la Document Fondation. Celles-ci n'ayant toutefois pas une approche commerciale, la logique est inversée. | la Document Fondation. Celles-ci n'ayant toutefois pas une approche commerciale, la logique est inversée. | ||
C'est | C'est l'administration qui doit se mettre en rapport régulier avec eux. | ||
A | |||
A l'égard de ces communautés, il est important pour être entendus de parler d'une seule voix. Cette voix | |||
Ces contacts réguliers permettent d' | unifiée a plus de poids dans la masse d'utilisateurs existants de par le monde. | ||
Ces contacts réguliers permettent d'assurer la prise en compte de besoins qui ne sont pas encore couverts, | |||
que cela soit fonctionnellement ou dans les processus de gestion des souches. En particulier, il est essentiel | que cela soit fonctionnellement ou dans les processus de gestion des souches. En particulier, il est essentiel | ||
que toutes les souches | que toutes les souches intègrent la logique de version à maintenance longue qui corresponde au mode de | ||
gestion de nos infrastructures. Ces contacts permettent aussi d'avoir une information précise sur les | gestion de nos infrastructures. Ces contacts permettent aussi d'avoir une information précise sur les | ||
évolutions | évolutions à attendre, les besoins des communautés, qui pourraient éventuellement être couverts par des | ||
actions interministérielles. | actions interministérielles. | ||
Certains | |||
échanges, en | Certains ministères ont des contacts privilégiés avec certaines communautés, ils sont alors porteurs des | ||
échanges, en cohérence avec l'équipe « noyau », et peuvent organiser des rencontres, en tant que de besoin, | |||
avec les groupes interministériels. | avec les groupes interministériels. | ||
4.6. Déployer des alternatives crédibles et opérationnelles aux | 4.6. Déployer des alternatives crédibles et opérationnelles aux grandes solutions éditeurs | ||
grandes solutions éditeurs | |||
Il | Il s'agit de veiller, dans le cadre du développement des systèmes d'information de l'État, à assurer le | ||
contrôle des coûts de fonctionnement et le maintien de la performance dans le temps. A cette fin, l'État doit | |||
favoriser la mise en concurrence | favoriser la mise en concurrence même dans les domaines dominés par des acteurs internationalement | ||
reconnus. Une des solutions consiste | reconnus. Une des solutions consiste à profiter des alternatives crédibles apportées par le logiciel libre. | ||
Dans cet esprit les travaux sur | Dans cet esprit les travaux sur LibreOffice ou PostgreSQL sont essentiels. Ils sont respectivement portés | ||
par les groupes thématiques MimO et MimDB. | par les groupes thématiques MimO et MimDB. Ils visent spécifiquement à renforcer la mutualisation sur | ||
tous les aspects de mise en | tous les aspects de mise en œuvre de ces logiciels (technologique, accompagnement, retour d'expérience, | ||
formations...). Des référents experts sont aussi désignés. | formations...). Des référents experts sont aussi désignés. | ||
Le groupe | Le groupe « noyau » (cf. organisation) veille, en coordination particulière avec le SAE, à définir les actions | ||
ciblées sur certaines souches pour en favoriser | ciblées sur certaines souches pour en favoriser spécifiquement l'adoption dans un contexte de mutation de | ||
l'offre commerciale vers l'offre libre. La prochaine opération pourrait porter sur les couches de | |||
virtualisation. | virtualisation. | ||
==Page 14== | |||
{{Introduction|Page 14 relue par LowMemory}} | |||
4.7. Tracer l'usage et ses effets | |||
Pour renforcer l'approche logiciel libre, il faut aussi en suivre l'évolution et le déploiement effectif tant dans | |||
les centres serveurs qu'au niveau bureautique. Une analyse annuelle des volumes et de la valeur de cet | |||
usage, ainsi que de son évolution, sera désormais réalisée et publiée. | |||
4.8. Développer la culture d'usage des licences libres dans les développements | |||
de SI publics | |||
L'État doit veiller à ce que ses développements soient utilisables par l'ensemb1e des acteurs impliqués dans | |||
ses systèmes d'information. Les nombreux statuts des entités publiques et l'implication éventuelle | |||
4.8. Développer la culture d'usage des licences libres dans les | d'utilisateurs finals comme les professionnels ou les éditeurs de solutions professionnelles rendent | ||
complexe la gestion de propriété des codes. | |||
L' | |||
ses | Sur les développements spécifiques, l'État doit préserver sa capacité à libérer les codes selon son intérêt | ||
d'utilisateurs finals comme les professionnels ou les éditeurs de solutions | |||
complexe la gestion de | |||
Sur les développements spécifiques, | |||
propre indépendamment du prestataire de développement. L'Etat doit donc faire usage, ou préparer l‘usage, | propre indépendamment du prestataire de développement. L'Etat doit donc faire usage, ou préparer l‘usage, | ||
des licences libres, permissives ou non selon les contextes, et veiller | des licences libres, permissives ou non selon les contextes, et veiller à faire prévaloir cette liberté vis-à-vis | ||
de ses prestataires dans tout contexte pouvant amener a réutilisation, sauf si un | de ses prestataires dans tout contexte pouvant amener a réutilisation, sauf si un surcoût explicite est induit. | ||
Un réseau d' | Un réseau d'expertise est mis en place entre juristes/acheteurs impliqués dans la rédaction des cahiers des | ||
clauses administratives. D'une | clauses administratives. D'une manière générale, il est mis en place des formations particulières, rapides | ||
pour les chefs de projets et les développeurs, et plus étoffées pour les juristes et acheteurs pour apporter une | pour les chefs de projets et les développeurs, et plus étoffées pour les juristes et acheteurs pour apporter une | ||
réelle | réelle maîtrise du sujet dans les ministères et les DSI. | ||
Par ailleurs, le CCAG TIC sera réexaminé pour définir une option portant la possibilité de | |||
Par ailleurs, le CCAG TIC sera réexaminé pour définir une option portant la possibilité de libération par | |||
l'administration, qui n'existe pas à ce jour. I1 doit aussi être enrichi de clauses de responsabilité et | |||
obligations des prestataires qui utilisent ou enrichissent du code libre. | obligations des prestataires qui utilisent ou enrichissent du code libre. | ||
La gestion des licences doit par ailleurs être une des composantes de la gouvernance des SI explicite de | |||
chaque ministère. | |||
==Page 15== | |||
{{Introduction|Page 15 relue par LowMemory}} | |||
5. Points d'appui à l'action interministérielle sur le logiciel libre | |||
5.1. Les instances « logiciel libre » interministérielles | |||
Pour travailler en interministériel, tout en s'appuyant sur la dynamique plus large de la sphère publique, | |||
deux niveaux d'instances ont été créés de manière pérenne : | |||
• une équipe dite « noyau », strictement interministérielle, qui concentre les propositions de décisions, | |||
de validation des choix à soumettre en CTSIC/CSIC et pilote les actions découlant de décisions de | |||
gouvernance interministérielles (marchés, évolution du catalogue des souches, mise en œuvre de | |||
• une équipe dite | directives…), | ||
de validation des choix | |||
gouvernance interministérielles (marchés, évolution du catalogue des souches, mise en | |||
• des groupes thématiques de mutualisation, ouverts aux structures publiques, qui réunissent les | • des groupes thématiques de mutualisation, ouverts aux structures publiques, qui réunissent les | ||
experts d'un domaine, favorisent | experts d'un domaine, favorisent l'échange et la montée en compétence, et proposent des orientations. | ||
Quatre groupes sont identifiés : | Quatre groupes sont identifiés : | ||
- mimO : mutualisation interministérielle pour une bureautique ouverte ; | - mimO : mutualisation interministérielle pour une bureautique ouverte ; | ||
- mimOG : mutualisation interministérielle pour OCS et GLPI ; | - mimOG : mutualisation interministérielle pour OCS et GLPI ; | ||
- | - mimBD : mutualisation interministérielle pour les bases de données ; | ||
- mimOS : mutualisation interministérielle pour le | - mimOS : mutualisation interministérielle pour le système d'exploitation et couches basses | ||
d'exploitation. | d'exploitation. | ||
Les missions, | |||
Les missions, l'organisation et les moyens de ces équipes sont développés en annexe. | |||
5.2. Leviers complémentaires | 5.2. Leviers complémentaires | ||
Afin d'appuyer la démarche, des actions complémentaires doivent être engagées, en interministériel ou à | |||
l'initiative de chaque ministère : | |||
• intégration du cadre de convergence sur les souches communes dans tous les cadres technologiques | • intégration du cadre de convergence sur les souches communes dans tous les cadres technologiques | ||
des | des ministères ; | ||
• | • examen de l'alternative libre systématique lors des nouveaux développements et des refontes | ||
majeures | majeures d'application, et a ce titre un point sera fait sur les choix dans chaque projet examiné dans le | ||
cadre des articles 7 et 8 (le choix des bases de données sera un point d'attention particulier) ; | cadre des articles 7 et 8 (le choix des bases de données sera un point d'attention particulier) ; | ||
• participation fortement conseillée au groupe | • participation fortement conseillée au groupe « noyau » pour l'ensemble des ministères, afin de | ||
renforcer la dynamique ; | renforcer la dynamique ; | ||
• | • définition explicite par chaque ministère des consignes d'implication des experts à l'effort de | ||
mutualisation dans les réseaux d'expertise ; | mutualisation dans les réseaux d'expertise ; | ||
• sous pilotage du SAE, étude | • sous pilotage du SAE, étude d'opportunité d'une révision du CCAG TIC pour la mise en place d'une | ||
option de développement avec | option de développement avec possibilité de libération du code, ainsi que la définition des obligations | ||
des prestataires dans | des prestataires dans l'usage des logiciels libres ; | ||
• association systématique | • association systématique à tout format préconisé (notamment dans le référentiel général | ||
d'interopérabilité), d'une implémentation de référence en logiciel libre. Les formats seront alors de | |||
fait suffisamment | fait suffisamment ouverts ; | ||
• diffusion des bonnes pratiques, notamment dans le contexte | • diffusion des bonnes pratiques, notamment dans le contexte bureautique, afin que l'usage des | ||
logiciels libres ne soit pas obéré. | logiciels libres ne soit pas obéré. | ||
==Page 16== | |||
{{Introduction|Page 16 relue par LowMemory}} | |||
6. ANNEXE : Organisation des instances « logiciel libre » interministrérielles | |||
6.1. L'équipe « noyau » | |||
L'équipe « noyau » est l'instance de pilotage, de définition des orientations et des choix au niveau interministériel. À ce titre elle n'accueille que des représentants des ministères, avec au moins un représentant désigné, ainsi qu'un membre de l'ANSSI et du SAE. Le représentant de chaque structure est chargé de porter la position de son ministère, ou a défaut d'assurer le lien avec les instances décisionnelles de son ministère, et en retour de s'assurer de la mise en application des principes d’action retenus. | |||
6.1.1 Missions de l'équipe | |||
6. | • définir et améliorer le cadre de convergence des souches de logiciel libre ; | ||
• suivre les groupes thématiques de mutualisation, pour s'assurer de la prise en compte et de la diffusion des travaux, et pour valider les orientations proposées ; | |||
• mettre en œuvre des pilotes sur des thèmes fixés par la DISIC ; | |||
• piloter les marchés interministériels sur le logiciel libre (support, expertise, évolution…) en coordination avec les ministères porteurs et le SAE ; | |||
• piloter les opérations de contribution hors marchés ; | |||
• suivre les relations et organisations de contacts avec les grandes communautés ; | |||
• choisir et suivre les opérations de déploiement d'alternatives libres ; | |||
• assurer la veille économique sur l'usage du logiciel libre et le suivi des indicateurs associés en coordination avec le SAE ; | |||
• définir des opérations de communication et de formation sur le logiciel libre en interministériel ; | |||
• améliorer les pratiques d'usage et de contractualisation autour du logiciel libre ; | |||
• échanger sur l'activité dans les ministères et sur les besoins naissant, pour favoriser la mutualisation. A ce titre recenser les souches créées dans certains ministères et pouvant être réutilisées par d‘autres (ex : Xemelios, OCS…) ; | |||
• assurer la cohérence de la conduite du projet « Usage du logiciel libre » avec les autres projets DISIC ; | |||
• faire le rapport d'activité à la DISIC. | |||
6.1.2 Moyens de l'équipe | |||
Pour l'ensemble de ses missions, ses moyens sont limités au strict nécessaire dans une logique mutualisée : | |||
• réunions physiques trimestrielles dans une salle d'un ministère ; | |||
• listes de diffusions pour chaque groupe constitué y compris l'équipe « noyau », opérées par le MCC ; | |||
• site collaboratif au sein du site DISIC, opéré par le MEDDE. | • site collaboratif au sein du site DISIC, opéré par le MEDDE. | ||
Par ailleurs pour enrichir le débat, permettre | Par ailleurs pour enrichir le débat, permettre à de nouveaux entrants de découvrir les instances, organiser un échange d'expérience et tester de nouveaux sujets de travail, des « journées du logiciel libre » sont organisées deux fois par an. Elles sont l'occasion de séquences de courtes présentations de retour d'expérience et de débat sur l'usage des logiciels libres dans l'administration. Elles sont réservées a des agents du service public, et ne font pas l’objet de communication pour y garder une parole libre sur les difficultés rencontrées. | ||
échange d'expérience et tester de nouveaux sujets de travail, des | |||
d' | |||
agents du service public, et ne font pas l’objet de communication pour y | |||
==Page 17== | |||
{{Introduction|Page 17 relue par LowMemory}} | |||
Les membres de l'équipe "noyau" ne peuvent de fait que consacrer un temps limité et discontinu a cette activité. Pour maintenir une motivation durable, une qualité de la production et une continuité des travaux il est nécessaire de compter, au sein de la DISIC ou dans un ministère, sur une personne dédiée, a très grande proportion de son temps de travail, à l'animation et à la formalisation des travaux de l'équipe "noyau". Elle pourra aussi assurer le lien formel avec les groupes thématiques de mutualisation. Il serait utile à terme que les ministères définissent et fassent connaître à l’équipe noyau une enveloppe pour contribution sur certaines souches. | |||
6.2. Les groupes thématiques de mutualisation | |||
Les groupes thématiques de mutualisation réunissent les experts d'un domaine pour favoriser le partage d'expérience, la montée en compétence, la constitution de réseaux d'échange et d'assistance, et la proposition d'orientations et de choix techniques. À ce titre ils gèrent par subsidiarité l'activité autour des souches de leur domaine. | |||
Quatre groupes sont identifiés : | |||
• mimO : mutualisation interministérielle pour une bureautique ouverte ; | |||
• mimOG : mutualisation interministérielle pour OCS et GLPI ; | |||
• mimBD : mutualisation interministérielle pour les bases de données ; | |||
• mimOS : mutualisation interministérielle pour le système d’exploitation et couches basses d'exploitation. | |||
Ils accueillent les représentants de l'administration d’État, d'organismes publics, de collectivités territoriales .... Tous les participants sont des agents publics. | |||
6.2.1 Missions générales des groupes | |||
• élaborer les préconisations pour le socle de convergence ; | |||
• identifier les sources de mutualisation possibles ; | |||
• collecter les retours d’expériences ; | |||
• collecter et diffuser l’information (espaces de discussion et de dépôt de documents) ; | |||
• jouer le rôle d’interface entre les communautés et les administrations, et organiser des rencontres ; | |||
• assurer une veille technologique ; | |||
• suivre les travaux des autres chantiers de la DISIC (poste/environnement de travail, TCI pour la partie exploitation…) ; | |||
• animer les espaces collaboratifs ; | |||
• faire le rapport d'activité régulier a l'équipe « noyau ». | |||
Le représentant de la DISIC garantit la connexion entre les chantiers. Les membres participants à d'autres chantiers font des points sur l'état d’avancement de la réflexion sur ces chantiers. | |||
6.2.2 Spécificités des groupes | |||
6.2.2.1. MimO | 6.2.2.1. MimO | ||
Domaine : | |||
• ensemble des logiciels applicatifs sur le poste bureautique. | |||
Missions spécifiques : | |||
• gérer la distribution de la suite bureautique et des extensions jugées utiles, et outils associés (correcteurs…) ; | |||
• produire des paquets d’installation, des documentations, des valises pédagogiques… | |||
==Page 18== | |||
{{Introduction|Page 18 relue par LowMemory}} | |||
Usage du logiciel libre dans l'administration - version finale | |||
À terme cela s'entendra aussi sur le socle bureautique libre. Les tâches opérationnelles seront portées par certains ministères. | |||
Une liste de sujets à étudier sur 2012 est retenue : | |||
* évolutions Mozilla Firefox (avec Android aussi) et Thunderbird ; | |||
* usages bureautiques sur les agents mobiles (lire les messages et les documents bureautiques sur les téléphones cellulaires, les tablettes...) ; | |||
Une liste de sujets | * compétition LO/OOo ; | ||
* usage de Trustedbird ; | |||
* choix Firefox face à Chrome ; | |||
téléphones cellulaires, les tablettes | * Grammalecte ou autre correcteur grammatical, relation avec son concepteur et étude de participation à son développement ; | ||
* évolution de Lightning ; | |||
* maintenance du correcteur terminologique ; | |||
* mise en place d'une plate-forme d'échanges pour conversion des documents en formats libres (cf initiative Europe). | |||
initiative Europe). | |||
6.2.2.2. MimOG | 6.2.2.2. MimOG | ||
Domaine : | Domaine : | ||
* ensemble des logiciels utiles à la gestion et au support du parc bureautique. | |||
Missions | |||
Missions spécifiques : | |||
GLPI... | * produire des paquets d'installation, des documentations, des valises pédagogiques pour OCS et GLPI... | ||
Une liste de sujets | |||
Une liste de sujets à étudier sur 2012 est retenue : | |||
cadre de convergence ; | * gestion fine des versions (et distributions) OCS et GLPI et de leurs extensions pour définition d'un cadre de convergence ; | ||
* FusionInvetory vs OCS (choix à faire et lutte à modérer...) ; | |||
* souche VNC à retenir ; | |||
* outils de génération des paquets de télédistribution. | |||
6.2.2.3. MimBD | 6.2.2.3. MimBD | ||
Domaine : | Domaine : | ||
* ensemble des logiciels de base de données. | |||
Missions | |||
Missions spécifiques : | |||
* favoriser la migration des bases propriétaires vers des bases libres, et en particulier PostgreSQL. | |||
Une liste de sujets à étudier sur 2012 est retenue : | |||
* collecte de retours d'expérience en termes de migration ; | |||
* croisement des politiques concernant les bases de données libres et propriétaires ; | |||
* préconisations d'usage ; | |||
* préconisations de migration ; | |||
* l'avenir de MySQL: MariaDB, SkySQL... ; | |||
* les souches NoSQL. | |||
==Page 19== | |||
{{Introduction|Page 19 relue par LowMemory}} | |||
6.2.2.4. MimOS | 6.2.2.4. MimOS | ||
Domaine : | |||
* ensemble des logiciels des couches basses des serveurs, en particulier les systèmes d'exploitation et les outils de virtualisation, ainsi que l'ensemble des outils utiles à l'exploitation des serveurs. | |||
6.2.3 | Une liste de sujets a étudier sur 2012 a été mise en avant : | ||
* cartographie de l'existant système et visualisation ; | |||
* distribution Linux à privilégier. | |||
6.2.3 Moyens des groupes | |||
Pour l'ensemble de leurs missions, les moyens sont limités au strict nécessaire dans une logique mutualisée : | |||
* réunions physiques trimestrielles dans une salle d'un ministère ; | |||
* listes de diffusions thématiques, opérées par le MCC ; | |||
* site collaboratif au sein du site DISIC ou du MEDDE, opéré par le MEDDE ; | |||
* site de distribution de paquets, opérés par un des membres du groupe. | |||
[[Catégorie:Institutions]] | [[Catégorie:Institutions]] |
Dernière version du 4 octobre 2012 à 16:57
Cette page présente un contenu fini et publié en ligne.
Résultat du passage dans un logiciel de reconnaissance optique de caractères (OCRFeeder) du fichier http://circulaire.legifrance.gouv.fr/pdf/2012/09/cir_35837.pdf
Texte à corriger :
J'ai supprimé l'en-tête («Usage du logiciel libre dans l'administration — version finale») et le pied de page («PM/SGG/DISIC #page/18 Septembre 2012»). Ces éléments sont présents sur tout le document joint à la lettre (ici de la page 3 à la page 19 du document, avec une numérotation de page allant de 2 à 18). --LowMemory (discussion) 3 octobre 2012 à 19:34 (CEST)
Page 1[modifier]
Liberté · Égalité · Fraternité
RÉPUBLIQUE FRANÇAISE
Le Premier Ministre
5608/SG
Paris, le 19 septembre 2012
à
Mesdames et Messieurs les ministres
Objet : Orientations pour l'usage des logiciels libres dans l’administration
P.J. : 1
Les logiciels libres sont des logiciels dont le modèle de propriété intellectuelle est conçu pour donner à l’utilisateur une grande liberté d’utilisation, de modification et de diffusion. Ils couvrent un domaine d’emploi très large, à la fois dans les entreprises privées et dans les administrations. On peut citer notamment le développement d’applications, les bases de données, les systèmes d’exploitation des serveurs, les suites bureautiques et la messagerie.
Au sein de l'administration, on constate une longue pratique de leur usage qui a permis le développement de compétences et la capitalisation de nombreuses expériences positives. Celles-ci ont notamment démontré les atouts du logiciel libre (moindre coût, souplesse d’utilisation, levier de discussion avec les éditeurs).
Après plusieurs années au cours desquelles la question de l’usage du logiciel libre a pu faire l’objet de nombreuses discussions, il est désormais possible de retenir une série d’orientations et de recommandations sur le bon usage du logiciel libre. C’est l’objet du document joint en annexe, préparé avec les directeurs des systèmes d’information de vos ministères, dans le cadre d’un travail animé par la direction interministérielle des systèmes d’information et de communication. Je vous demande de mettre en œuvre, au sein de vos services, les orientations définies dans le document joint.
Jean—Marc AYRAULT
Hôtel de Matignon - 57. rue de Varenne - 75007 Paris - Tél. 01 42 75 80 00
Page 2[modifier]
Liberté • Égalité • Fraternité
RÉPUBLIQUE FRANÇAISE
PREMIER MINISTRE
SECRÉTARIAT GÉNÉRAL DU GOUVERNEMENT
DIRECTION INTERMINISTÉRIELLE DES SYSTÈMES
D'INFORMATION ET DE COMMUNICATION
Usage du Logiciel libre
dans l'administration
Septembre 2012
Page 3[modifier]
Table des matières
Page 4[modifier]
1. OBJECTIF DU DOCUMENT
Une longue pratique de l'usage du logiciel libre a permis le développement de compétences et la capitalisation de nombreuses expériences positives dans l’administration. Un meilleur partage de ces savoirs et la définition d'orientations communes permettrait de franchir une nouvelle étape, pour gagner en efficacité opérationnelle et économique.
Dans le cadre des travaux interministériels lancés par la DISIC, un groupe de travail, piloté par la DSI du ministère de la culture et de la communication, a été chargé de définir les orientations nécessaires a l’usage du logiciel libre dans les ministères.
Ce document présente, après des rappels sur le contexte d’émergence du logiciel libre et sur le modèle de propriété intellectuelle associé, les orientations issues des premiers travaux, précisant notamment les environnements dans lesquels son usage est approprié, décrivant les actions communes lancées et les instances de travail créées.
Statut du document : Ce document est basé sur les travaux du groupe interministériel d’experts. Il a été revu en CTSIC du 21juin 2012 pour validation, diffusion et mise en œuvre effective.
Page 5[modifier]
2.ORIGINES ET FONDEMENTS DU LOGICIEL LIBRE
2.1. Contexte de développement de la position du logiciel libre
Le logiciel libre a conquis une grande part des infrastructures techniques et prend une place de plus en plus importante dans tous les systèmes d'information jusqu‘aux terminaux. Les standards Internet ont créé un contexte commun sur lequel de plus en plus de productions logicielles se sont appuyées, devenant interchangeables. De nombreux logiciels sont maintenant des « utilités » avec une valeur d'innovation limitée, et les clients acceptent de moins en moins de payer un prix élevé pour des produits jugés communs et rentabilisés, et d'être liés a un fournisseur. Désormais, pour répondre aux besoins métiers, le logiciel libre doit être considéré a égalité avec les autres solutions C'est dans cette évolution que s'inscrit l‘usage du logiciel libre dans l'administration.
2.2. Le modèle du logiciel libre
Le logiciel libre est un modèle de propriété intellectuelle prenant différentes formes, dont les principes sont de :
- garantir la liberté d'exécuter le programme, pour tous les usages ;
- garantir la liberté d'étudier le fonctionnement du programme et de l'adapter a ses besoins ;
- garantir la liberté de redistribuer de copies du programme;
- permettre d‘améliorer le programme et de distribuer ces améliorations au public, pour en faire profiter toute la communauté ;
Tout ceci implique bien sur que le code source doit être librement accessible. Cette vision très ouverte, a permis la mise en place de groupe d’intérêts sur certains logiciels libres, ou encore « souches», et a amené a développer un modèle de développement en communautés dont les plus connues de nos jours sont GNU/Linux, Apache, Mozilla (Firefox, Thunderbird), Document Fondation (LibreOffice). Ces principes donnent certaines caractéristiques au logiciel libre :
- comme tout modèle de propriété intellectuelle, il tend à s'auto-entretenir
Le logiciel libre le plus diffuse l‘est selon le mode dit << copyleft » de la licence GNU GPL. Dans son principe il empêche celui qui utilise le code de s’approprier l'effort de la communauté sans rien lui reverser des améliorations ou des corrections. La contribution a l'effort collectif devient un principe et permet de maintenir la dynamique de développement.
- l'évolution d’un logiciel libre est orientée par le besoin utilisateur
Une communauté n'a pas intérêt a développer une fonction qui n'est utile qu'a très peu d‘utilisateurs au sein d’un logiciel libre. Alors que le changement de version régulier chez l’éditeur est difficilement maîtrisable pour l'utilisateur, la stabilité est une qualité pour un logiciel libre. La règle est donc la mise en commun des besoins et la priorisation des évolutions.
- le modèle garantit que la communauté puisse conserver le contrôle
Dans certaines communautés libres, des acteurs du logiciel propriétaire sont très actifs. L’intérêt propre de leur société peut les amener a orienter les développements en s'éloignant de l'intérêt de la communauté. Le modèle libre permet alors a une partie de celle-ci de faire ce que l'on nomme un « fork », c'est-à-dire repartir du code source du moment dans une autre direction de développement.
Page 6[modifier]
- le modèle permet de créer l'émulation nécessaire à la créativité
Que cela soit au travers de "fork" ou en s'appuyant sur l'ensemble des logiciels libres existants, ceux qui sont sûrs d'avoir une bonne idée peuvent toujours se lancer avec un faible investissement et réunir une communauté autour de cette idée. C'est ainsi que de nombreuses souches se créent eu permanence, seules survivant celles qui sont suffisamment pertinentes pour être portées par un grand nombre de développeurs et d'utilisateurs.
Contrairement aux idées reçues, le recours à des logiciels libres ne signifie en rien qu’il n’y a aucune obligation à respecter pour les utilisateurs. Un logiciel libre n’est pas libre de droit puisqu’il a un
créateur. Les initiateurs du logiciel libre, réalistes, se sont insérés dans le monde du droit en formulant dans
des licences les droits et obligations s'appliquant. Plusieurs grands types de licences ont été définis dont les
principales sont la Gnu General Public Licence (GPL), la Berkeley Software Distribution (BSD) et la
licence Apache. Il en existe aussi une en droit français, la licence CEA CNRS INRIA Logiciel Libre
(CECILL). Les caractéristiques juridiques (effet ou non héréditaire, multilicensing, droit applicable,
garanties) varient en fonction de leur auteur, mais ces licences sont toutes des objets de droit positif et fort,
reconnu en justice.
Lorsqu'on télécharge une licence de logiciel libre, on se retrouve dans le cadre d’un contrat d'adhésion, c'est-à-dire dans la même situation qu’en cas d’achat d’un logiciel propriétaire. Les clauses de la licence sont imposées par l'auteur et ne sont pas négociables. Au final, soit le licencié accepte la licence et peut faire ce qui y est mentionné, soit il ne peut pas bénéficier de toutes les libertés inhérentes au logiciel libre (modification et distribution).
C'est un des points importants et pourtant souvent négligés du logiciel libre: il convient de connaître les obligations associées a un logiciel libre en particulier dans le cadre d'une utilisation dans un système d'information professionnel.
2.3. Le libre, un modèle de service
Si les droits sur le logiciel libre ne sont associés à aucune compensation financière, cela ne veut pas dire qu'il n'en coûte rien de mettre en œuvre et d’utiliser du logiciel libre, en particulier dans le domaine professionnel.
En effet, comme pour tout logiciel, il est nécessaire de l'intégrer dans son système d'information et de s'assurer de son maintien en conditions opérationnelles (support, maintenance) ainsi que de le faire évoluer en fonction des besoins. Ces tâches doivent être couvertes soit par de la charge interne soit en faisant appel a des sociétés de service, dont certaines spécialisées s’affichent comme "Sociétés de Services de Logiciel Libre" (SSLL).
On remplace donc un modèle "coût de licence/coût de maintenance" sur licences, par un modèle "coût de service" à façon qui peut être adapté aux besoins réels de l'entité utilisatrice. Sur des infrastructures critiques il conviendra d'avoir un support fort et réactif, en général externalisé, dans d'autres contextes le support au travers de la communauté pourra suffire.
Quoi qu'il en soit, les coûts dans le modèle de service du logiciel libre sont peu sensibles à la volumétrie d'usage (nombre de serveurs installés, nombres d'utilisateurs simultanés...). Il se prête donc bien à une mutualisation et favorise une concentration des usages en interministériel. A cet avantage essentiel, s'ajoutent les avantages d'indépendance vis a vis des acteurs externes. En effet une remise en concurrence régulière des sociétés de services, pouvant toutes intervenir sur les souches libres, permet de rester dans les prix du marché.
Il est important à ce sujet de relever que le Conseil d’État a validé ce principe de libre concurrence, dans un
modèle de service autour des souches libres, dans l'arrêt n°350431 du 30 septembre 2011.
L’administration peut choisir unilatéralement une solution libre, étant entendu que son utilisation est
possible par tous les acteurs et que ceux-ci peuvent donc fournir sans entrave extérieure une offre de service
adaptée.
Page 7[modifier]
3. LE LIBRE, UN CHOIX RAISONNÉ
Le logiciel libre a été porté à l'origine par une philosophie d'ouverture et par des «pionniers militants» qui ont rendu les utilisateurs plus institutionnels, qu'ils soient publics ou privés, méfiants par rapport à cette approche.
Aujourd'hui le choix du logiciel libre dans l'administration n'est pas un engagement idéologique, mais le fruit d'un choix raisonné. Les motivations sont multiples, mais on retiendra principalement :
- la contrainte de plus en plus forte sur les moyens d'investissement et de fonctionnement des SI, concomitante avec une forte augmentation de la demande ;
- la valorisation des compétences et de l'expertise professionnelle des équipes informatiques, qui ne sont pas de simples acheteurs de solutions.
3.1. Avantages
En fonction des cas d'usage, les avantages suivants peuvent être apportés par le logiciel libre, dans le contexte public :
- le logiciel libre n'est pas gratuit mais souvent moins cher, et surtout son coût est modulable en fonction de la criticité des systèmes ;
- le logiciel libre est piloté par les besoins, minimisant les évolutions superflues ;
- le logiciel libre permet de gérer les versions selon son contexte, et même de se fixer sur une version en assurant son support à long terme ;
- le logiciel libre facilite les expérimentations et l'adaptation au volume d'usage, l'absence de droit d'usage permettant de varier fortement sans contrainte ;
- le logiciel libre facilite la mutualisation entre acteurs publics que cela soit dès l'expression de besoins ou en capitalisant sur des souches existantes ;
- le logiciel libre apporte une transparence accrue dans la définition et l'animation de politique de sécurité des systèmes d'information, avec une exigence et un coût adaptable par le choix du niveau de
support ;
- le logiciel libre permet une réelle mise en concurrence, par l'achat de services auprès de sociétés mises sur un pied d'égalité par la publication des sources.
Appliqué au contexte de la commande publique, le recours au logiciel libre offre l'opportunité de favoriser le principe de mise en concurrence et d'ouverture à la commande publique dans l'achat de logiciels et de services. Le juge a bien précisé qu'un pouvoir adjudicateur pouvait, sans remettre en cause les principes de l'achat public, organiser une mise en concurrence fondée sur une solution libre choisie unilatéralement par l'administration (Arrêt du Conseil d'Etat n°350431 du 30 septembre 2011).
3.2. Limites/points d'attention
Le logiciel libre a aussi ses limites et doit faire l'objet de quelques points d'attention :
- le logiciel libre est lié à une communauté : il convient donc de connaître et de suivre cette communauté pour s'assurer de la pérennité et du sérieux de la solution ;
- les licences libres n'emportent pas une absence de droit de la propriété intellectuelle, mais une autre forme de droit, qu'il faut gérer, en particulier dans le développement ;
- pour le simple utilisateur final, l'effet de marque et de marketing vaut aussi dans le logiciel, et le logiciel libre n'ayant pas de prix est parfois jugé sans valeur ;
Page 8[modifier]
- la possibilité de contribuer au développement du logiciel par l'accès au code source ne doit pas donner la tentation de multiplier les ajouts de code spécifique, au risque de perdre le lien avec la souche communautaire et d‘avoir à supporter une solution isolée sur le long terme. Une démarche d‘analyse de la valeur de l'écart au « standard » s’impose avec rigueur ;
- la participation à la dynamique du libre est liée à la contribution, l'utilisateur, surtout professionnel, ne peut se limiter à profiter du système ; il doit entretenir le modèle par réinjection d'une part de ses gains sous une forme ou une autre ;
- certains éditeurs jouent à la marge du modèle du logiciel libre, en gérant une version dite « entreprise » ou « premium » sous licence classique propriétaire et une version dite « communautaire » sous licence libre, mais qui est en général en retard sur l'autre version. C‘est le modèle dit du « Freemium ». Ces souches, portées par un éditeur plus que par une communauté, doivent être utilisées avec prudence car elles risquent toujours de rebasculer dans un mode propriétaire.
3.3. Les différents contextes d'usage
Quand on décide de développer un système d'information, le choix d'utiliser du logiciel libre, voire de développer selon le modèle libre, doit être analysé selon des critères prenant en compte le cadre d'utilisation, le nombre d'acteurs concernés, la complexité du système et l'implication nécessaire.
3.3.1 Les cadres favorables au modèle libre
3.3.1.1. Un logiciel libre existant et internationalement reconnu
Certains logiciels libres sont tenus par une communauté déjà très forte avec de nombreux utilisateurs (JBoss, Firefox...). Dans certains cas le logiciel libre devient incontournable comme par exemple pour le serveur web Apache qui est utilisé par près de 60% du parc installé (fin 2011).
Dans ce cas, la réduction des coûts est directe, et le produit est immédiatement utilisable et souvent suffisamment supporté au travers de la communauté. Il reste cependant possible de se mettre en lien avec la communauté de développement pour remonter le cas échéant les rapports de dysfonctionnement et contribuer à l'amélioration du logiciel.
Des exemples de ce contexte sont omniprésents et conduisent au déploiement de plus en plus important dans le secteur public comme privé de grandes souches libres : Linux, Apache, Firefox, Thunderbird, JBoss, OpenSSL, Eclipse...
Dans le cas des logiciels pour les utilisateurs finals, il conviendra toutefois d'assurer une conduite du changement pour préparer l'introduction d'un nouveau logiciel, surtout s'il vient remplacer une solution largement utilisée. Ceci doit être intégré au calcul économique.
3.3.1.2. Un déploiement de logiciel sur une grande infrastructure
Dans certains grands systèmes ou pour certaines applications destinées aux utilisateurs, il est nécessaire d'acheter un grand nombre de licences. Des milliers de licences de base de données ou de systèmes d'exploitation peuvent entraîner des coûts substantiels.
Il peut dès lors être rentable de supporter directement voire d‘améliorer une souche libre existante et de participer à la maintenance de cette souche. Cet investissement peut être ensuite utile pour tout autre acteur public.
Un exemple d'usage des logiciels libres dans un système d’information critique d’une direction ministérielle a permis de diviser par 10 les coûts de fonctionnement des applicatifs. Cette réduction nette des coûts a été obtenue en mettant en place un marché de maintenance dans des conditions très strictes (délais de 48h de résolution...) sur plus de 100 souches logicielles.
Quand il s'agit de postes utilisateurs, le déploiement de nouvelles briques ou de mises à jours peut se faire de manière homogène sur l'ensemble du parc, sans coût particulier (pas de rachats de licences, pas d’achat de licence évolutive), ce qui facilite le maintien de l'homogénéité du parc et induit une baisse des coûts de support utilisateurs et une augmentation de la qualité.
Page 9[modifier]
3.3.1.3. Un logiciel utilisé dans un contexte virtualisé ou à forte variation de charge
Dans une logique comparable, le déploiement dans un contexte virtualisé simplifie la création de serveurs logiques et l'adaptation de leur nombre ou de la puissance processeur accordée. La gestion et le paiement des licences propriétaires peuvent être soit un frein à cette adaptabilité, soit un générateur de complexité et de coût qui n'est pas optimisé. En effet les licences propriétaires ont des coûts liés à la puissance physique maximale utilisée.
A contrario, le coût de support, interne ou externe, du logiciel libre n'est pas modifié par l'intensité de l'usage et dépend de l'exigence en qualité de service. Il est donc lié a la criticité de l'usage. Dans la plupart des cas, comme le démontre le marche de support interministériel récemment notifié, il sera très inférieur au coût de licences couvrant le déploiement en pointe de charge.
3.3.1.4. Un logiciel utilisé dans le contexte du développement agile
Le développement agile est par définition «opportuniste» et ajoute des fonctions au fur et à mesure de la définition des besoins en rapport avec les utilisateurs. Ce mode de développement permet aussi de procéder, d'une manière limitée, par «essais/erreurs». Il est donc difficile d'avoir une vision précise d'entrée sur les bases logicielles qui sont utiles et qui devront être intégrées.
L'usage du logiciel libre permet de «piocher» au fur et à mesure du développement dans les souches disponibles, dans un cadre technologique propre à chaque entité, en fonction de leur adéquation, sans question de droit d'usage dans la phase de développement ni dans la phase d'exploitation.
3.3.1.5. Face à des situations de faible concurrence
Certains produits d'éditeur ont de moins en moins d'alternatives commerciales crédibles, le leader du marché ayant éliminé la concurrence. Le logiciel libre apporte alors des possibilités alternatives.
Certaines souches ont un niveau fonctionnel élevé et peuvent remplacer des logiciels propriétaires avec un coût limité au support assuré de manière forfaitaire et aussi mutualisé que possible. Les systèmes Linux ont ainsi clairement montré leur intérêt.
D'autres ont un contour fonctionnel un peu moins riche que le logiciel d'éditeur et ont vocation à être sélectionnées lorsque les fonctions complexes spécifiques aux solutions propriétaires ne sont pas absolument nécessaires. C'est par exemple le cas dans le domaine des bases de données où PostgreSQL constitue une alternative souvent pertinente et à développer.
Il est à remarquer que les éditeurs de solutions progicielles (grands PGI, ...) favorisent généralement l'utilisation de composants d'architectures propriétaires (OS, SGBD) en ne garantissant la compatibilité qu'avec ceux-ci. Même si certaines solutions libres, et en particulier Linux, rentrent dans les matrices de compatibilité supportées, une attention particulière doit être portée à ce point au moment du choix d'une solution progicielle qui peut par cette voie limiter les choix technologiques et induire des surcoûts cachés.
Les ministères financiers ont démontré l'intérêt de l'utilisation du logiciel libre dans ce contexte, dans le cadre de la reprise d'une application en Cobol. L'usage d'OpenCobol leur a permis de réduire le coût d'un facteur supérieur à 10.
3.3.1.6. Un même besoin à traiter par de nombreux acteurs publics
Des besoins liés au métier ou à la réglementation sont communs à de nombreux acteurs publics. Dans ce contexte, il est particulièrement contre-productif que chaque acteur conduise ses développements spécifiques de son côté, et en paye la totalité au lieu de partager la charge du développement. Que cela soit pour développer un système de gestion d'aide au niveau local ou une plate-forme de dématérialisation des marchés publics, il est aisé de voir qu'une association des acteurs facilitée par le modèle libre sera profitable à chacun.
Certaines collectivités territoriales ont compris ce point et ont mis en place des associations ayant pour objet de fédérer leurs développements selon le modèle libre comme l'ADULLACT.
On constate d'ailleurs une augmentation remarquable de la qualité technique des développements réalisés en vue de publication sous licences libres comparativement aux développements spécifiques réalisés précédemment. C'est aussi un effet positif de l'ouverture du contenu du développement à l'externe.
Page 10[modifier]
3.3.1.7. Un déploiement dans des contextes multiples d'acteurs publics ou privés
Certaines fonctions de l'État appellent des applications ou des systèmes d'interfaçage utilisables par des acteurs très nombreux, ne serait-ce que les différents types de collectivités territoriales. Par exemple la comptabilité publique induit des échanges de relevés comptables formatés avec les ordonnateurs locaux. Ces fonctions doivent pouvoir être intégrées aux systèmes de ces partenaires et donc être utilisées parfois par les éditeurs.
Avoir des licences d'utilisation ouvertes sur des populations aussi larges, et qui permettent une intégration large, revient presque à avoir une licence libératoire, ce qui dans le modèle propriétaire est en général très cher, car contraire a sa logique. Qui plus est dans ce contexte il n'est pas facile à l'État de payer tout ou partie pour tous les acteurs publics. Dans le modèle libre il ne s'agit que de la licence normale qui de toute façon ne nécessite aucun contrô1e de la diffusion. La simplicité de gestion, la réduction des coûts et la commodité de réutilisation sont évidentes.
Des exemples de contextes éligibles sont donnés par les systèmes développés par l'État en lien avec de nombreux partenaires, comme par exemple Xemelios de la DGFiP, pour le traitement des fichiers de dématérialisation de la chaîne comptable et financière.
3.3.2 Les contextes défavorables au modèle libre
3.3.2.1. Petit nombre d'acteurs concernés par la mise en œuvre
Le développement selon le modèle libre nécessite pour être utile de mettre en place une communauté de contributeurs qui échangent et mutualisent leurs efforts. Si les entités concernées ou devant maîtriser le développement d'un logiciel sont peu nombreuses et mal identifiées, il est moins utile d'en libérer le développement. Il convient cependant d'être prudent et il peut être utile de garder la possibilité de le faire si un besoin émerge par la suite.
3.3.2.2. Système complet et complexe (non modulaire)
Le principe de mutualisation qui sous-tend le modèle libre va de pair avec une approche modulaire dans le développement et la conception des systèmes d'information. Les briques et modules, plus facilement abordables par de nouveaux entrants, plus facilement réutilisables dans de nombreux systèmes, plus légers à maintenir, sont plus éligibles au modèle libre.
A contrario, les systèmes complets et complexes sont parfois si difficiles a gérer qu'ils requièrent un professionnel dédié, c'est à dire un éditeur... C'est notamment le cas des systèmes de gestion tels les PGI généralistes.
Il convient toutefois de souligner que les principes d'urbanisation et de bonne gestion de l'évolution des systèmes d'information incitent à limiter l'usage de systèmes monolithiques pour favoriser la modularité qui correspond au modèle libre.
Page 11[modifier]
4. L'ACTION INTERMINISTÉRIELLE SUR LE LOGICIEL LIBRE
Pour faciliter le recours à des solutions «logiciel libre» dans les choix des administrations, et ainsi le positionner au même niveau que les autres offres, tout en dégageant le maximum d'efficacité économique et de qualité, l'État doit agir de façon concertée et coordonnée, selon les modalités détaillées ci-après.
4.1. Instaurer une convergence effective sur des souches de logiciels libres
Le principe fondateur du logiciel libre est la mise en commun des efforts. La concentration des acteurs sur certaines souches est un gage d'efficacité. Ainsi les efforts de développement d'expertise, les coûts de corrections de «bugs», parfois à la charge de l'utilisateur, voire d'évolution, sont mutualisés.
Un cadre de convergence des souches à privilégier dans le développement des systèmes d'information de l'État, défini en 2012, est désormais maintenu en concertation interministérielle. Il touche en priorité les systèmes les plus déployés, sur les serveurs comme sur les postes bureautiques.
Ce cadre ne fait pas obstacle à l'innovation par essai de nouvelles souches, qui pourront aider à son évolution. Il ne rend pas non plus obligatoire l'évolution adaptative des applications existantes non conformes. En revanche, il définit des versions de référence à privilégier et indique les solutions à abandonner, avec des réserves éventuelles pour des contextes d'usage particuliers.
Ce cadre est aussi une composante indispensable à la convergence progressive des contextes d'exploitation et à la mutualisation de certains moyens. À ce titre il doit être intégré dans tous les cadres technologiques des ministères et pris en compte à l'occasion de nouveaux développements et de refontes majeures.
Chaque ministère doit participer au maintien à jour de ce cadre et à son renforcement progressif. En particulier il déclarera régulièrement l'usage fait des souches du cadre et les usages hors du cadre, pour permettre le suivi de sa prise en compte et la gestion de son évolution.
Le cadre de convergence est publié et remis a jour à un rythme trimestriel, en lien avec les marchés de support interministériels, sur l'outil collaboratif de l'équipe «noyau» (cf. organisation).
4.2. Activer un réseau d'expertise sur les souches de convergence
L'efficacité de la mise en commun autour du logiciel libre vient aussi du partage d'expertise et de la montée en compétence sur les souches. Chaque ministère peut difficilement être compétent sur l'ensemble des souches, mais chacun a des compétences. La constitution d'un réseau d'experts permet de faire profiter l'ensemble des administrations des expertises ponctuelles nécessaires.
Les porteurs de ce type d'expertise sont naturellement volontaires pour le partage et sont valorisés par l'usage de leur compétence. Le plus difficile est d'organiser la mise en relation et d'assurer l'acceptation par la hiérarchie de la charge induite, même limitée, de participation à l'effort interministériel.
Il convient de constituer des réseaux portés par une mise en relation physique événementielle, indispensable à la création d'un échange riche et suivi, et par une mise en relation électronique en travail collaboratif. Plusieurs outils sont mis en place a cette fin :
- les groupes de travail thématiques, avec rencontre régulière sur les sujets bureautiques (MimO), socle serveur (MimOS), exploitation bureautique (MimOG) et base de données (MimDB) ;
- la «journée logiciel libre» favorisant l'ouverture à de nouveaux acteurs, et permettant d'ouvrir de nouveaux sujets ou de diffuser largement des retours d'expérience ;
Page 12[modifier]
Usage du logiciel libre dans l'administration — version finale
- les listes de diffusion, par groupes thématiques ou sur des thèmes définis, permettant de faire appel dans l'instant au réseau sur des questions précises ;
- les sites collaboratifs des groupes thématiques pour le partage de ressource (CD de distribution ou valise pédagogique LibreOffice...).
Chaque ministère s'implique dans la démarche commune.
Les réseaux d'expertise, et en priorité les groupes thématiques quand ils existent, sont le creuset de définition et d'évolution du socle de convergence sur leur périmètre de compétence. La liste proposée au cadre de convergence est publiée sur l'outil collaboratif du groupe.
4.3. Améliorer le support des logiciels libres dans un contexte économique contrôlé
Le logiciel libre permet d'adapter sa politique de maintenance en fonction de l'étendue et de la criticité des systèmes. Une grande partie de l'usage du logiciel libre s'est fait sans support particulier, en profitant du support apporté par les communautés. Même si ce moyen reste toujours valable, il est nécessaire, pour un certain nombre d'usages, d'avoir un support réactif avec des engagements de résultat.
Le logiciel libre permet d'avoir des engagements de support supérieurs aux logiciels propriétaires, car le code est à disposition pour correction en interne ou par un prestataire choisi, alors que les éditeurs ont des processus de support normalisés qui ne s'adaptent que partiellement aux besoins du client. Le problème des grands logiciels propriétaires est renforcé par la distance des centres de développement et la complexité des processus de publication de version à l'échelle mondiale. En outre, la politique contractuelle des éditeurs prive généralement le client de la possibilité de négocier le niveau de service standard de l'éditeur, niveau de service par ailleurs très protecteur pour ce dernier.
Les ministères financiers ont démontré la faisabilité et l'efficacité économique de mise en place d'un marché de support par un prestataire de type société de service. Au niveau interministériel, un marché a été passé sous l'égide du SAE et sous la direction du ministère de l'intérieur pour couvrir les besoins des autres ministères. Il prévoit des mécanismes de réduction des coûts quand plusieurs acteurs demandent du support pour une même souche (plus précisément pour les mêmes versions d'une souche). Ce marché est donc une incitation supplémentaire à la mise en œuvre du cadre de convergence.
4.4. Contribuer de manière concertée sur des souches choisies
Au travers du marché de support interministériel et du cadre de convergence, l'État concentre désormais son action sur un ensemble de souches et contribuera à leur amélioration en reversant des correctifs aux communautés. Toutefois, pour respecter la logique de la dynamique du libre, il est nécessaire que l'administration contribue aussi directement sur l'enrichissement fonctionnel de certaines souches, en particulier sur celles avec lesquelles il fait le plus d'économies. En réinjectant une faible part de la dépense évitée, les ministères pourraient avoir une action significative d'amélioration de l'offre au profit de tous.
Une règle simple à appliquer serait de réinjecter systématiquement de 5 à 10% des coûts de licences évités. Cela permet de contribuer de manière utile dans tous les cas, de ne pas mettre en risque le gain économique d'usage du libre, sans pour autant faire systématiquement une étude poussée de gain complet.
Cette contribution peut prendre de nombreuses formes :
- dans les marchés utilisant des logiciels libres, veiller à rendre possible la reprise des éventuelles évolutions de souches par la communauté, facilitant ainsi leur suivi par la communauté et évitant une maintenance spécifique ;
Page 13[modifier]
- envisager le financement de conventions de recherche pour ajout de fonctions évoluées pouvant faire
l'objet de travaux universitaires (par exemple un correcteur grammatical polyglotte pour une suite bureautique) ;
- étudier le financement par des fonds sur l'accessibilité pour l'amélioration de logiciel sur les postes de
travail ;
- mettre en place un marché d'expertise et d'évolution de souches, qui au travers d'un prestataire verse
aux communautés ;
- et bien sûr favoriser l'implication à titre professionnel d'agents, souvent passionnés à titre personnel,
dans certaines communautés. Cette implication peut porter sur le code, mais aussi sur des domaines moins techniques comme la traduction, la documentation…
Dans la foulée du marché de support interministériel, le MI et le SAE mettent en place un marché
d'expertise et d'évolution de souches qui pourra être la base de contributions concertées et partagées
interministérielles. Cette action aura d'autant plus de poids qu'un grand nombre de ministères
s'associeront. L‘existence d'un deuxième marché permettra en outre de limiter l'effet négatif de la
concentration des achats qui ne favorise pas la montée en puissance de multiples grands acteurs du logiciel
libre.
4.5. Suivre les grandes communautés
De même que les éditeurs logiciels maintiennent des contacts réguliers avec tous les ministères pour actualiser la connaissance de leurs produits, permettre d'en anticiper les changements voire recueillir les besoins, il est indispensable d'avoir des liens avec les grandes communautés comme la Mozilla Fondation, la Document Fondation. Celles-ci n'ayant toutefois pas une approche commerciale, la logique est inversée. C'est l'administration qui doit se mettre en rapport régulier avec eux.
A l'égard de ces communautés, il est important pour être entendus de parler d'une seule voix. Cette voix unifiée a plus de poids dans la masse d'utilisateurs existants de par le monde.
Ces contacts réguliers permettent d'assurer la prise en compte de besoins qui ne sont pas encore couverts, que cela soit fonctionnellement ou dans les processus de gestion des souches. En particulier, il est essentiel que toutes les souches intègrent la logique de version à maintenance longue qui corresponde au mode de gestion de nos infrastructures. Ces contacts permettent aussi d'avoir une information précise sur les évolutions à attendre, les besoins des communautés, qui pourraient éventuellement être couverts par des actions interministérielles.
Certains ministères ont des contacts privilégiés avec certaines communautés, ils sont alors porteurs des échanges, en cohérence avec l'équipe « noyau », et peuvent organiser des rencontres, en tant que de besoin, avec les groupes interministériels.
4.6. Déployer des alternatives crédibles et opérationnelles aux grandes solutions éditeurs
Il s'agit de veiller, dans le cadre du développement des systèmes d'information de l'État, à assurer le contrôle des coûts de fonctionnement et le maintien de la performance dans le temps. A cette fin, l'État doit favoriser la mise en concurrence même dans les domaines dominés par des acteurs internationalement reconnus. Une des solutions consiste à profiter des alternatives crédibles apportées par le logiciel libre. Dans cet esprit les travaux sur LibreOffice ou PostgreSQL sont essentiels. Ils sont respectivement portés par les groupes thématiques MimO et MimDB. Ils visent spécifiquement à renforcer la mutualisation sur tous les aspects de mise en œuvre de ces logiciels (technologique, accompagnement, retour d'expérience, formations...). Des référents experts sont aussi désignés. Le groupe « noyau » (cf. organisation) veille, en coordination particulière avec le SAE, à définir les actions ciblées sur certaines souches pour en favoriser spécifiquement l'adoption dans un contexte de mutation de l'offre commerciale vers l'offre libre. La prochaine opération pourrait porter sur les couches de virtualisation.
Page 14[modifier]
4.7. Tracer l'usage et ses effets
Pour renforcer l'approche logiciel libre, il faut aussi en suivre l'évolution et le déploiement effectif tant dans les centres serveurs qu'au niveau bureautique. Une analyse annuelle des volumes et de la valeur de cet usage, ainsi que de son évolution, sera désormais réalisée et publiée.
4.8. Développer la culture d'usage des licences libres dans les développements de SI publics
L'État doit veiller à ce que ses développements soient utilisables par l'ensemb1e des acteurs impliqués dans ses systèmes d'information. Les nombreux statuts des entités publiques et l'implication éventuelle d'utilisateurs finals comme les professionnels ou les éditeurs de solutions professionnelles rendent complexe la gestion de propriété des codes.
Sur les développements spécifiques, l'État doit préserver sa capacité à libérer les codes selon son intérêt propre indépendamment du prestataire de développement. L'Etat doit donc faire usage, ou préparer l‘usage, des licences libres, permissives ou non selon les contextes, et veiller à faire prévaloir cette liberté vis-à-vis de ses prestataires dans tout contexte pouvant amener a réutilisation, sauf si un surcoût explicite est induit. Un réseau d'expertise est mis en place entre juristes/acheteurs impliqués dans la rédaction des cahiers des clauses administratives. D'une manière générale, il est mis en place des formations particulières, rapides pour les chefs de projets et les développeurs, et plus étoffées pour les juristes et acheteurs pour apporter une réelle maîtrise du sujet dans les ministères et les DSI.
Par ailleurs, le CCAG TIC sera réexaminé pour définir une option portant la possibilité de libération par l'administration, qui n'existe pas à ce jour. I1 doit aussi être enrichi de clauses de responsabilité et obligations des prestataires qui utilisent ou enrichissent du code libre.
La gestion des licences doit par ailleurs être une des composantes de la gouvernance des SI explicite de chaque ministère.
Page 15[modifier]
5. Points d'appui à l'action interministérielle sur le logiciel libre
5.1. Les instances « logiciel libre » interministérielles
Pour travailler en interministériel, tout en s'appuyant sur la dynamique plus large de la sphère publique, deux niveaux d'instances ont été créés de manière pérenne :
• une équipe dite « noyau », strictement interministérielle, qui concentre les propositions de décisions, de validation des choix à soumettre en CTSIC/CSIC et pilote les actions découlant de décisions de gouvernance interministérielles (marchés, évolution du catalogue des souches, mise en œuvre de directives…), • des groupes thématiques de mutualisation, ouverts aux structures publiques, qui réunissent les experts d'un domaine, favorisent l'échange et la montée en compétence, et proposent des orientations. Quatre groupes sont identifiés : - mimO : mutualisation interministérielle pour une bureautique ouverte ; - mimOG : mutualisation interministérielle pour OCS et GLPI ; - mimBD : mutualisation interministérielle pour les bases de données ; - mimOS : mutualisation interministérielle pour le système d'exploitation et couches basses d'exploitation.
Les missions, l'organisation et les moyens de ces équipes sont développés en annexe.
5.2. Leviers complémentaires
Afin d'appuyer la démarche, des actions complémentaires doivent être engagées, en interministériel ou à l'initiative de chaque ministère :
• intégration du cadre de convergence sur les souches communes dans tous les cadres technologiques des ministères ; • examen de l'alternative libre systématique lors des nouveaux développements et des refontes majeures d'application, et a ce titre un point sera fait sur les choix dans chaque projet examiné dans le cadre des articles 7 et 8 (le choix des bases de données sera un point d'attention particulier) ; • participation fortement conseillée au groupe « noyau » pour l'ensemble des ministères, afin de renforcer la dynamique ; • définition explicite par chaque ministère des consignes d'implication des experts à l'effort de mutualisation dans les réseaux d'expertise ; • sous pilotage du SAE, étude d'opportunité d'une révision du CCAG TIC pour la mise en place d'une option de développement avec possibilité de libération du code, ainsi que la définition des obligations des prestataires dans l'usage des logiciels libres ; • association systématique à tout format préconisé (notamment dans le référentiel général d'interopérabilité), d'une implémentation de référence en logiciel libre. Les formats seront alors de fait suffisamment ouverts ; • diffusion des bonnes pratiques, notamment dans le contexte bureautique, afin que l'usage des logiciels libres ne soit pas obéré.
Page 16[modifier]
6. ANNEXE : Organisation des instances « logiciel libre » interministrérielles
6.1. L'équipe « noyau »
L'équipe « noyau » est l'instance de pilotage, de définition des orientations et des choix au niveau interministériel. À ce titre elle n'accueille que des représentants des ministères, avec au moins un représentant désigné, ainsi qu'un membre de l'ANSSI et du SAE. Le représentant de chaque structure est chargé de porter la position de son ministère, ou a défaut d'assurer le lien avec les instances décisionnelles de son ministère, et en retour de s'assurer de la mise en application des principes d’action retenus.
6.1.1 Missions de l'équipe
• définir et améliorer le cadre de convergence des souches de logiciel libre ;
• suivre les groupes thématiques de mutualisation, pour s'assurer de la prise en compte et de la diffusion des travaux, et pour valider les orientations proposées ;
• mettre en œuvre des pilotes sur des thèmes fixés par la DISIC ;
• piloter les marchés interministériels sur le logiciel libre (support, expertise, évolution…) en coordination avec les ministères porteurs et le SAE ;
• piloter les opérations de contribution hors marchés ;
• suivre les relations et organisations de contacts avec les grandes communautés ;
• choisir et suivre les opérations de déploiement d'alternatives libres ;
• assurer la veille économique sur l'usage du logiciel libre et le suivi des indicateurs associés en coordination avec le SAE ;
• définir des opérations de communication et de formation sur le logiciel libre en interministériel ;
• améliorer les pratiques d'usage et de contractualisation autour du logiciel libre ;
• échanger sur l'activité dans les ministères et sur les besoins naissant, pour favoriser la mutualisation. A ce titre recenser les souches créées dans certains ministères et pouvant être réutilisées par d‘autres (ex : Xemelios, OCS…) ;
• assurer la cohérence de la conduite du projet « Usage du logiciel libre » avec les autres projets DISIC ;
• faire le rapport d'activité à la DISIC.
6.1.2 Moyens de l'équipe
Pour l'ensemble de ses missions, ses moyens sont limités au strict nécessaire dans une logique mutualisée :
• réunions physiques trimestrielles dans une salle d'un ministère ;
• listes de diffusions pour chaque groupe constitué y compris l'équipe « noyau », opérées par le MCC ;
• site collaboratif au sein du site DISIC, opéré par le MEDDE.
Par ailleurs pour enrichir le débat, permettre à de nouveaux entrants de découvrir les instances, organiser un échange d'expérience et tester de nouveaux sujets de travail, des « journées du logiciel libre » sont organisées deux fois par an. Elles sont l'occasion de séquences de courtes présentations de retour d'expérience et de débat sur l'usage des logiciels libres dans l'administration. Elles sont réservées a des agents du service public, et ne font pas l’objet de communication pour y garder une parole libre sur les difficultés rencontrées.
Page 17[modifier]
Les membres de l'équipe "noyau" ne peuvent de fait que consacrer un temps limité et discontinu a cette activité. Pour maintenir une motivation durable, une qualité de la production et une continuité des travaux il est nécessaire de compter, au sein de la DISIC ou dans un ministère, sur une personne dédiée, a très grande proportion de son temps de travail, à l'animation et à la formalisation des travaux de l'équipe "noyau". Elle pourra aussi assurer le lien formel avec les groupes thématiques de mutualisation. Il serait utile à terme que les ministères définissent et fassent connaître à l’équipe noyau une enveloppe pour contribution sur certaines souches.
6.2. Les groupes thématiques de mutualisation
Les groupes thématiques de mutualisation réunissent les experts d'un domaine pour favoriser le partage d'expérience, la montée en compétence, la constitution de réseaux d'échange et d'assistance, et la proposition d'orientations et de choix techniques. À ce titre ils gèrent par subsidiarité l'activité autour des souches de leur domaine.
Quatre groupes sont identifiés :
• mimO : mutualisation interministérielle pour une bureautique ouverte ;
• mimOG : mutualisation interministérielle pour OCS et GLPI ;
• mimBD : mutualisation interministérielle pour les bases de données ;
• mimOS : mutualisation interministérielle pour le système d’exploitation et couches basses d'exploitation.
Ils accueillent les représentants de l'administration d’État, d'organismes publics, de collectivités territoriales .... Tous les participants sont des agents publics.
6.2.1 Missions générales des groupes
• élaborer les préconisations pour le socle de convergence ;
• identifier les sources de mutualisation possibles ;
• collecter les retours d’expériences ;
• collecter et diffuser l’information (espaces de discussion et de dépôt de documents) ;
• jouer le rôle d’interface entre les communautés et les administrations, et organiser des rencontres ;
• assurer une veille technologique ;
• suivre les travaux des autres chantiers de la DISIC (poste/environnement de travail, TCI pour la partie exploitation…) ;
• animer les espaces collaboratifs ;
• faire le rapport d'activité régulier a l'équipe « noyau ».
Le représentant de la DISIC garantit la connexion entre les chantiers. Les membres participants à d'autres chantiers font des points sur l'état d’avancement de la réflexion sur ces chantiers.
6.2.2 Spécificités des groupes
6.2.2.1. MimO
Domaine :
• ensemble des logiciels applicatifs sur le poste bureautique.
Missions spécifiques :
• gérer la distribution de la suite bureautique et des extensions jugées utiles, et outils associés (correcteurs…) ;
• produire des paquets d’installation, des documentations, des valises pédagogiques…
Page 18[modifier]
Usage du logiciel libre dans l'administration - version finale
À terme cela s'entendra aussi sur le socle bureautique libre. Les tâches opérationnelles seront portées par certains ministères.
Une liste de sujets à étudier sur 2012 est retenue :
- évolutions Mozilla Firefox (avec Android aussi) et Thunderbird ;
- usages bureautiques sur les agents mobiles (lire les messages et les documents bureautiques sur les téléphones cellulaires, les tablettes...) ;
- compétition LO/OOo ;
- usage de Trustedbird ;
- choix Firefox face à Chrome ;
- Grammalecte ou autre correcteur grammatical, relation avec son concepteur et étude de participation à son développement ;
- évolution de Lightning ;
- maintenance du correcteur terminologique ;
- mise en place d'une plate-forme d'échanges pour conversion des documents en formats libres (cf initiative Europe).
6.2.2.2. MimOG
Domaine :
- ensemble des logiciels utiles à la gestion et au support du parc bureautique.
Missions spécifiques :
- produire des paquets d'installation, des documentations, des valises pédagogiques pour OCS et GLPI...
Une liste de sujets à étudier sur 2012 est retenue :
- gestion fine des versions (et distributions) OCS et GLPI et de leurs extensions pour définition d'un cadre de convergence ;
- FusionInvetory vs OCS (choix à faire et lutte à modérer...) ;
- souche VNC à retenir ;
- outils de génération des paquets de télédistribution.
6.2.2.3. MimBD Domaine :
- ensemble des logiciels de base de données.
Missions spécifiques :
- favoriser la migration des bases propriétaires vers des bases libres, et en particulier PostgreSQL.
Une liste de sujets à étudier sur 2012 est retenue :
- collecte de retours d'expérience en termes de migration ;
- croisement des politiques concernant les bases de données libres et propriétaires ;
- préconisations d'usage ;
- préconisations de migration ;
- l'avenir de MySQL: MariaDB, SkySQL... ;
- les souches NoSQL.
Page 19[modifier]
6.2.2.4. MimOS
Domaine :
- ensemble des logiciels des couches basses des serveurs, en particulier les systèmes d'exploitation et les outils de virtualisation, ainsi que l'ensemble des outils utiles à l'exploitation des serveurs.
Une liste de sujets a étudier sur 2012 a été mise en avant :
- cartographie de l'existant système et visualisation ;
- distribution Linux à privilégier.
6.2.3 Moyens des groupes
Pour l'ensemble de leurs missions, les moyens sont limités au strict nécessaire dans une logique mutualisée :
- réunions physiques trimestrielles dans une salle d'un ministère ;
- listes de diffusions thématiques, opérées par le MCC ;
- site collaboratif au sein du site DISIC ou du MEDDE, opéré par le MEDDE ;
- site de distribution de paquets, opérés par un des membres du groupe.