Circulaire Ayrault (septembre 2012) : Usage du logiciel libre dans l’administration

Avertissement : Ce document est une retranscription de la circulaire officielle réalisée à partir de la dernière version de travail. Il peut contenir des erreurs.

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, et 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 à 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 d’expert interministériel. Il a été revu en CTSIC du 21 juin 2012 pour validation, diffusion et mise en œuvre effective.

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’au 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 à un fournisseur.

Désormais, pour répondre aux besoins métiers, le logiciel libre doit être considéré à pied d’égalité avec les autres solutions. C’est dans cette évolution que s’inscrit l’usage du logiciel libre par 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 à ses besoins ;
  • garantir la liberté de redistribuer des 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 sûr 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é à 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 diffusé l’est selon le mode dit « copyleft » de la licence GNU GPL. Dans son principe il empêche celui qui utilise le code de faire sien l’effort de la communauté sans rien lui reverser des améliorations ou des corrections. La contribution à l’effort collectif devient un principe et permet de maintenir la dynamique de développement.

  • L’évolution d’un logiciel libre est orienté par le besoin utilisateur

Une communauté n’a pas intérêt à développer une fonction qui n’est utile qu’à 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 de 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 à orienter les développements en s’éloignant de l’intérêt de la communauté. Le modèle libre permet alors à 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.

  • 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ûr 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 en 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 (effet ou non contaminant, multilicensing, droit applicable, garanties) juridiques 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é du logiciel libre : il convient de connaître les obligations associées à 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 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 à 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.

Quoiqu’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…) et se prête donc bien à une mutualisation et favorise une concentration des usages en interministériel.

A cet avantage essentiel, s’ajoute les avantages d’indépendance vis à 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 maintenir de rester dans les prix du marché.

Il est important à ce sujet de marquer que le Conseil d’État a bien 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.

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’usages, 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 avec un coût 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 assure une réelle mise en concurrence, par achat de service 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 est une opportunité de favoriser le principe de mise en concurrence et d’ouverture à la commande publique dans l’achat de logiciels et de services. La jurisprudence a bien rappelé qu’un pouvoir adjudicateur pouvait sans remettre en cause les principes de l’achat public organiser une mise en concurrence basé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 fait l’objet de quelques points d’attention que l’on pourrait ainsi résumer :

  • 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 ne sont 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 ;
  • 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 libre 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 amènent 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 simples utilisateurs finaux, il conviendra toutefois d’assurer une conduite du changement pour préparer l’introduction d’un nouveau logiciel, surtout s’il vient une solution largement utilisée. Ceci doit être intégré à l’équation économique.

3.3.1.2. Un déploiement de logiciel sur une grande infrastructure

Dans certains grands systèmes ou pour certaines applications utilisateurs, il est nécessaire d’acheter un grands nombre de licences. Des milliers de licences de base de données ou de systèmes d’exploitation peuvent rapidement donner des coûts substantiels.

Il peut facilement devenir rentable de supporter directement voire d’améliorer une souche libre existante pour correspondre exactement au besoin et de participer à la maintenance de cette souche. Cet investissement peut être ensuite rendu utile à 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 impressionnante des coûts est pourtant 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 des baisses de coût de support utilisateurs et une augmentation de la qualité.

3.3.1.3. Un logiciel utilisé dans un contexte virtualisé ou à fort changement 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 peut ê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, donc lié à la criticité de l’usage. Dans la plupart des cas, comme le démontre le marché de support interministériel, 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 ayant éliminé la concurrence. Le logiciel libre apporte alors des possibilités alternatives.

Certaines 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és 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és 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 les mêmes chez de nombreux acteurs publics. Dans ce contexte, il est particulièrement contre-productif que chaque acteur fasse ses développements spécifiques de son côté, et paye donc la totalité plutôt que 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.

Les collectivités territoriales ont pour certaines 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 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.

3.3.1.7. Un déploiement dans des contextes multiples d’acteurs publics ou privés

Certaines fonctions de l’Etat amènent à établir 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 doit faire 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 utilisées parfois même par des éditeurs.

Avoir des licences d’utilisation ouvertes sur des populations aussi large, 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 à sa logique. Qui plus est dans ce contexte il n’est pas facile à l’Etat 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ôle de la diffusion. La simplicité de gestion, la réduction des coûts et la commodité de réutilisation sont évidentes.

Des exemples de contexte éligibles sont donnés par tous les systèmes développés par l’Etat en rapport avec ses 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 vont pouvoir échanger et mutualiser 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 tient lieu cependant d’être prudent et parfois 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 (par rapport à brique/module)

Le principe de mutualisation qui sous-tend le modèle libre rend plus utile d’avoir 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éutilisable dans des nombreux systèmes, plus légères à maintenir sont plus éligibles au modèle libre.

A contrario, les systèmes complets et complexes sont parfois si difficile à gérer qu’ils requièrent un professionnel dédié, c’est à dire un éditeur… C’est encore le cas des systèmes de gestion tels les PGI généralistes.

Il convient toutefois de constater 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.

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é aussi bien économique qu’en terme de qualité, l’Etat doit agir de façon concertée et coordonnée, détaillée 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 seront mutualisés.

Un cadre de convergence des souches à privilégier dans le développement des systèmes d’information de l’Etat, défini en 2012, est 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 à l’évolution du cadre. Ce cadre ne rend pas non plus obligatoire l’évolution adaptative des applications existantes non conformes. Par contre 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. A 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 à jour sur 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 de 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 à 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 ;
  • 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 évidemment 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, pour un certain nombre d’usages il est nécessaire 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 avec des adaptations aux besoins du client forcément réduits. 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 élimine généralement toute possibilité pour le client 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é monté 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’Etat va concentrer son action sur un ensemble de souches et va le cas échéant contribuer à 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’économie. 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, toujours veiller à mettre les efforts nécessaires pour la reprise des éventuelles évolutions de souches par la communauté. Cela apporte de plus la sécurité de la prise en charge de son suivi par la communauté et évite de faire une maintenance spécifique ;
  • 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 être 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 MIOMCTI 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érielle. Cette action aura d’autant plus de poids qu’un grand nombre de ministères s’associeront. L’existence d’un deuxième marché, permet 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 la même manière 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.

Face à 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 part de 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 utilisées aux grandes solutions éditeurs

Il s’agit de veiller, dans le cadre du développement de ses systèmes d’information de l’Etat, à assurer le contrôle des coûts de fonctionnement et le maintien de la performance dans le temps. Pour ce faire il favorise la mise en concurrence même dans des domaines avec des acteurs internationalement reconnus. Un des moyens est de 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éterminé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 être sur les couches de virtualisation.

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, est 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’Etat doit veiller à ce que ses développements soient utilisables par l’ensemble des acteurs impliqués dans ses systèmes d’information. Les nombreux statuts des entités publiques et l’implication éventuelles d’utilisateurs finaux comme les professionnels ou les éditeurs de solutions professionnelles rendent complexes la gestion de propriété des codes.

Sur les développements spécifiques, l’Etat doit se préserver la capacité de 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 à imposer cette liberté à ses prestataires dans tout contexte pouvant amener à 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 juriste 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. Il 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.

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, mais s’appuyer à la fois sur la dynamique qui va au-delà des ministères dans 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ées en annexe.

5.2. Leviers complémentaires

Afin d’appuyer la démarche, des décisions complémentaires doivent être actionnées :

  • 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 à ce titre un point sera fait sur les choix dans chaque projet examiné dans le cadre des articles 7 et 9 (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 participer à 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é.

6. ANNEXE : Organisation des instances « logiciel libre » interministé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. A 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 à 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 points 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 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és 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 à 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.

Les membres de l’équipe « noyau » ne peuvent de fait que consacrer un temps limité et discontinu à cette activité. Pour maintenir une pression constante, une qualité de la production et une continuité des travaux il est nécessaire d’avoir une personne dédiée, si ce n’est à 100% à très grande proportion de son temps de travail, sur 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.

Cette personne sera à définir dans un ministère ou à la DISIC.

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ématique de mutualisation sont les instances de réunions des 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’orientation et de choix techniques. A ce titre il 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 tous des 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 de travail, TCI pour la partie exploitation…) ;
  • animer les espaces collaboratifs ;
  • faire le rapport d’activité régulier à 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…

A 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 Androïd aussi) et Thundebird ;
  • 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.

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 à étudier sur 2012 a été mise en avant :

  • cartographie de l’existant système et virtualisation ;
  • 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 ;
  • liste de diffusions thématique, opérée par le MCC ;
  • site collaboratif au sein du site DISIC ou du MEDDTL, opéré par le MEDDTL ;
  • site de distribution de paquets, opérés par un des membres du groupe.
3 Likes