Gouvernance informatique: Il est temps d’y intégrer l’Open Source

Dans le cadre de mes activités pour le Conseil des technologistes d’HP France, j’ai écrit un article pour le Webzine IT experts sur la l’intégration de Open Source et la gouvernance informatique disponible sur http://www.it-expertise.com/gouvernance-informatique-il-faut-integrer-lopen-source/. Un grand merci à Aurélie Magniez pour m’avoir aidé à faire cette publication.

Ci-dessous, une version légèrement modifiée qui tient compte de retours et rétablit certaines formules auxquelles je tiens, quoique moins journalistiquement correctes et certains liens (jugés trop nombreux par le Webzine, mais je tiens à citer mes sources, et Tim Berners-Lee ne les a pas inventés pour que l’on ne s’en serve pas non ? :-))

Bonne lecture !

Aujourd’hui en 2013, toutes les entités, publiques comme privées, en France, comme partout dans le monde, utilisent massivement des Logiciels Free, Libres et Open Source (abrégé en FLOSS (1)). Quelques exemples de cet état de fait sont fournis par la Linux Foundation, comme les 600 000 télévisions intelligentes vendues quotidiennement fonctionnant sous Linux ou les 1,3 millions de téléphones Andoïd activés chaque jour. Le dernier rapport de top500.org, présentant les super-calculateurs mondiaux, indique une utilisation de Linux à 96,4%. Des sociétés ayant aujourd’hui un impact quotidien sur notre environnement numérique telles que FaceBook ou Twitter ont non seulement bâti leur infrastructure sur une grande variété de FLOSS, mais ont aussi publié de grandes quantités de code et des projets complets sous licence libre. Ceci concerne aussi des acteurs plus classiques du monde de l’informatique comme HP ou IBM.

Ceci peut sembler normal, car on évolue là dans le monde du numérique, mais le phénomène touche tous les secteurs comme le montre une récente étude de l’INSEE, qui reporte que 43% des entreprises françaises d’au moins 10 personnes utilisent des suites bureautique FLOSS ou encore que 15% des sociétés de construction utilisent un système d’exploitation FLOSS par exemple. Cette large adoption se trouve corroborée par le développement de la filière FLOSS en France, comme rapporté par le CNLL, représentant en 2013 2,5 milliard d’Euros et 30 000 emplois.

Enfin, le secteur public n’est pas en reste avec la publication en septembre 2012 de la circulaire du premier ministre qui reconnait la longue pratique de l’administration des FLOSS, et incite celle-ci, à tous les niveaux, à un “bon usage du logiciel libre”, ce qui se vérifie dans certains ministères comme celui de l’intérieur ou de l’économie. Le ministère de l’éducation nationale a ainsi déployé 23 000 serveurs EOLE sous Linux et utilise de nombreux projets FLOSS pour la gestion multi-fonctions (réseau, sécurité, partage) des établissements scolaires.

Services impliqués dans la gouvernance FLOSS

Dans ce contexte d’utilisation généralisée, se posent certaines questions quant à la gouvernance particulière à mettre en place ou l’adaptation de celle existante pour accroître l’usage, la distribution, la contribution au FLOSS, tant pour les fournisseurs que pour les utilisateurs de ces technologies. En effet, les FLOSS ont des spécificités tant techniques qu’organisationnelles (rapport à la communauté, méthodologie de développement, licence utilisée) qui ont un impact sur la façon de les gérer dans une entité. La Gouvernance Open Source, aujourd’hui, doit donc être partie intégrante d’une Gouvernance Informatique.

Contrairement à ce qu’une rapide analyse pourrait laisser penser, ce n’est pas uniquement le service informatique qui est concerné par l’utilisation des FLOSS. Celle-ci touche la totalité de l’entité et le modèle de gouvernance doit donc être adapté en conséquence. En effet, le service des achats se voit souvent court-circuité par l’utilisation de composants logiciels téléchargés et non achetés en suivant les procédures qu’il met en place, le service du personnel ne dispose pas de contrats de travail statuant sur les contributions des employés à des projets FLOSS (ne parlons pas des stagiaires ou co-traitants), le service juridique doit apprendre à distinguer la licence Apache de la GPLv2, ou v3, le service de propriété intellectuelle considérer si telle modification faite à un projet FLOSS peut ou doit être reversée au projet, et dans quel contexte, voire le PDG évaluer, lors d’une scission de sa société en différentes entitées juridiques, l’impact représenté sur la redistribution de logiciels faite à cette occasion et le respect des licences utilisées. Ce ne sont que quelques exemples des questions auxquelles les entités doivent répondre dans le cadre d’une Gouvernance Informatique intégrant les FLOSS.

Ceci n’est pas un débat oiseux: il y a eu maintenant trop d’exemples allant jusqu’au procès et sur des problématiques de non-respect des licences FLOSS pour que les entreprises et services publics ignorent le problème. Les conséquences tant financières que sur leur image de marque peuvent être très importantes et causer des dommages beaucoup plus graves que ne le représente la mise en conformité (qui consiste le plus souvent en la seule publications des codes sources modifiés).

Il ne s’agit pas ici d’énoncer des éléments qui tendraient à restreindre l’utilisation des FLOSS dans une entité. Au contraire, les bénéfices de leur utilisation sont aujourd’hui trop évidents, la baisse des coûts induite par la mutualisation, les gains technologiques d’avoir des souches logicielles si versatiles et éprouvées doivent juste s’accompagner des mesures de gestion nécessaires pour en retirer tous les bénéfices annoncés. L’analyse des risques fait partie des choix quotidiens exercés au sein d’une entité et de même que pour une démarche qualité, l’impulsion doit venir du sommet de la hiérarchie de l’entité. Celle-ci doit soutenir la création des instances nécessaires à l’établissement d’une gouvernance FLOSS en leur donnant le pouvoir requis et l’interaction avec les différents services de l’entité.

Composants d’une gouvernance FLOSS

Tout d’abord, il s’agira de développer la compréhension de l’écosystème libre au sein de l’entité pour en appréhender les spécificités.

La première d’entre elles est la licence gouvernant les FLOSS. Comme pour toute utilisation d’un logiciel, ou d’un service, un utilisateur se voit décrit ses droits et ses devoirs au sein de ce document. Ceux-ci diffèrent selon que la licence est permissive (type Apache v2 par exemple), qui permet une utilisation (y compris pour des développement non-FLOSS) et une redistribution avec peu de contraintes (mentions légales et paternité par exemple). Elle permet ainsi à des sociétés de vendre des versions propriétaires d’Andoïd distribué sous Licence Apache v2 embarquées dans leurs téléphones portables. C’est ce qui permet de considérer cette licence comme “libre”. En regard on donnera également l’exemple des licences de gauche d’auteur (copyleft en anglais, type GPL v2 par exemple), qui permettent une utilisation tant que le logiciel distribué s’accompagne des sources (éventuellement modifiées) servant à le fabriquer. Elle permet à des projets comme le noyau Linux d’être développé par des milliers de développeurs tout en restant toujours accessible dans toutes ses variantes par la mise à disposition de son code source, dû à cette contrainte. C’est ce qui permet de considérer cette licence comme “libre”. Simplement les libertés sont vues ici sous l’angle du projet (qui le reste ad vitam aeternam) plutôt que sous celui de l’utilisateur comme dans l’autre cas. C’est la raison pour laquelle toutes ces licences sont considérées comme Open Source par l’OSI.

Une entité doit donc choisir les briques FLOSS qu’elle souhaite utiliser en fonction de l’usage prévu pour respecter les droits et devoirs d’usage codifiés dans les licences (ni plus ni moins qu’avec une offre non-FLOSS), sachant que, dans la plupart des cas, l’élément déclenchant l’application de la licence est la distribution du logiciel. Ainsi une société peut parfaitement utiliser un logiciel sous licence GPL v2, y faire des modifications et ne pas les publier, tant que l’usage reste interne à sa structure juridique (cas fréquent en mode utilisation de logiciel dans un département informatique). En revanche, si elle l’incorpore à un produit qu’elle commercialise, elle devra juste se mettre en conformité avec la licence et fournir en parallèle du produit un acccès aux dites sources.

Ceci n’est finalement pas si compliqué, eu égard aux gains énormes qu’elle peut en retirer en bénéficiant d’une brique logicielle éprouvée qu’elle n’a ni à développer, ni à maintenir. Dans tous les cas, il est important que son service juridique ait une compréhension des droits et devoirs des licences utilisées pour apporter le conseil requis, comme lors de la signature de contrats avec tout fournisseur.

On le voit, la formation du service juridique est à la base de la mise en place de toute gouvernance. D’autre part, il faut organiser au sein de l’entité la mise en relation entre ce service juridique et les équipes de développement. Non seulement pour qu’elles apprennent à se connaître, mais aussi pour qu’elles échangent sur leurs besoins réciproques et qu’elles comprennent comment chacune cherche à protéger l’entité pour laquelle elle oeuvre. Les uns le faisant eu égard au respect des règles de droit, ce qui comprend l’explication envers les développeurs des licences libres, les autres eu égard au mode d’utilisation des composants techniques spécifiques des équipes de développement.

Personnellement, en tant qu’ingénieur de formation, il m’a été très bénéfique de discuter avec divers avocats spécialistes des licences libres, pour mieux comprendre leur volonté de protéger l’entreprise pour laquelle ils travaillent et comment ils devaient le faire dans ce contexte. Et réciproquement, je sais que les informations techniques et exemples parfois complexes d’agrégats de composants logiciels les aident en retour à mieux tenir compte des cas particuliers qui peuvent se faire jour. La communication sur ce sujet doit dépasser dans l’entité les structures classiques et fonctionner comme une communauté.

Du reste, la seconde spécificité du logiciel libre est le fait qu’il est développé par une communauté de personnes partageant un intérêt pour ce logiciel. Il en existe de toute taille (d’un développeur assurant tout, jusqu’à plusieurs centaines de personnes comme les larges fondations comme Apache ou OpenStack). Etudier une communauté avant d’utiliser le composant libre qu’elle produit est une bonne pratique pour avoir des informations sur sa vitalité, son organisation, sa feuille de route, en plus des caractéristiques purement techniques du composant. Certains sites comme Ohloh peuvent aider à se forger une opinion dans ce domaine, pour les projets suivis. De même qu’il peut être alors pertinent de se poser la question des modes de contributions en retour. Cela peut consister en des correctifs, du code apportant de nouvelles fonctions, de la documentation, des traductions, une animation de communauté, de l’achat de prestation intellectuelle auprès de professionnels oeuvrant sur le composant ou un soutien financier à l’organisation d’un événement permettant le rassemblement physique de la communauté. Certaines entreprises, comme la Compagnie Nationale des Commissaires aux Comptes témoignent de leurs contributions en retour envers un projet tel que LibreOffice.

Comme précédemment, chacun de ces aspects pourra faire l’objet d’une étude dans le volet Open Source de la Gouvernance Informatique. On notera que la gestion de la proprété intellectuelle sera à considérer tout particulièrement pour les contributions sous forme de code, et en liaison avec la licence utilisée. Mais cet aspect peut aussi avoir un impact sur les contrats de travail des employés, des co-traitants, des stagiaires, afin de déterminer sous quelles conditions leurs contributions sont autorisées.

Encore une fois, il s’agit d’inciter les entités utilisatrices de logiciels libres à ne pas se contenter d’être de simples utilisatrices de FLOSS, mais à être actrices de l’écosystème et à contribuer à leur tour à l’améliorer en s’intégrant dans les communautés. Le dynamisme actuel autour des FLOSS est le fait du soutien très actif de nombreux utilisateurs. Pour ne citer qu’un exemple, on regardera la synergie créée autour du projet GENIVI par ses 120+ membres, dont de nombreuses sociétés hors secteur informatique.

Enfin la dernière spécifcité du logiciel libre est la méthodologie de développement utilisée par la communauté. Quoiqu’elles soient toutes attachées à l’accès au code, elles varient énormément d’un projet à l’autre, en fonction de sa taille, de son style de gouvernance, des outils utilisés et de son historique. Mais il est important pour une entité qui souhaite interagir avec une communauté d’en comprendre la culture. Si le noyau Linux a une méthodologie organisée autour d’un “dictateur bénévole” (Linus Torvalds) qui prend les ultimes décisions et de ses lieutenants, nommés, en qui il a toute confiance pour prendre les décisions concernant une branche de développement, d’autres projets comme OpenStack cherchent à adopter le mode le plus “méridémocratique” en procédant à l’élection des représentants techniques des branches du projet par les développeurs, et à celle des représentants au conseil d’administration par la totalité des membres de la fondation, quels que soient leurs rôles. Le processus d’intégration continue d’OpenStack implique des étapes précises pour y ajouter un patch par exemple. Cela nécessite d’abord une application sur l’arbre courant sans erreur, avant de devoir recevoir deux votes positifs puis de satisfaire le passage de l’ensemble des tests automatiques prévus. Et ceci s’applique aussi bien aux représentants techniques des branches du projet qui proposent des centaines de patches par an, ou au contributeur occasionnel faisant une modification mineure de documentation. En revanche, celui qui souhaite soumettre une modification sur le noyau Linux devra passer par des listes de diffusion où les échanges peuvent parfois se révéler vifs, et s’adapter aux desiderata potentiellement différents des mainteneurs de branches.

Bonnes pratiques de gouvernance FLOSS

Face à tous ces aspects de ce monde foisonnant, certaines bonnes pratiques simples peuvent permettre aux entreprises de faire les bons choix et de s’assurer une utilisation optimale des FLOSS en en tirant le meilleur profit sans mettre à risque leur bonne réputation par des actions mal vues des communautés.

Une première bonne pratique peut consister à créer un comité Open Source. Par exemple, pour un grand groupe, il peut être utile pour la direction générale de nommer des représentants des différents services (achats, ressources humaines, informatique, technique, juridique, propriété intellectuelle) pour définir la politique à mettre en place. Ce comité devra se réunir régulièrement, tant dans la phase de définition de la partie Open Source de la Gouvernance Informatique, qu’ultérieurement pour la réviser sur la base des retours des utilisateurs et l’évolution de projets. Il devra également avoir les moyens associés à ses missions. Un groupe de travail du Syntec Numérique a développé, pour les aider dans cette activité, des contrats types pour leurs fournisseurs, leur demandant de préciser avec leur livraison logicielle, l’inventaire exhaustif des licences utilisées. Une présentation sur les contrats faite au sein de ce groupe pourra être aussi consultée avec profit. La FSF France propose aussi des avenants de contrats de travail type pour les employés contribuant à des projets libres, et l’AFUL des modèles économiques et financement de projets FLOSS ou de communautés. Il sera ensuite facile de donner des missions et des pouvoirs plus étendus à ce groupe de personnes quand l’utilisation des FLOSS augmente. Dans le cadre d’une PME, un correspondant FLOSS sera sans doute suffisant (comme il peut y avoir un correspondant sécurité ou CNIL), tâche qui pourra même être sous-traitée à des sociétés specialisées dans le domaine.

Une fois le comité/correspondant nommé et la politique FLOSS établie, il faudra prévoir des cycles de formations. D’une part pour le service juridique pour le cas où il manquerait de compétences sur le domaine spécifique des licences libres. La société Alterway propose par exemple une formation par un juriste pour des juristes. D’autre part, en interne, auprès de l’ensemble du personnel pour expliquer cette nouvelle politique FLOSS.

En parallèle, il est important d’avoir une vision précise de l’utilisation actuelle des FLOSS dans son entité. Notamment pour vérifier que leur utilisation est conforme aux licences sous lesquelles ils sont utilisés. Les non-conformités sont plus souvent dûes à la méconnaissance qu’à une réelle volonté d’enfreindre les licences. Cette tâche peut paraître fastidieuse de prime abord, mais elle est à mon sens fondamentale pour se prémunir, en particulier si votre activité vous amène à redistribuer du logiciel à vos clients. Heureusement des outils existent pour automatiser ce travail d’inventaire et faciliter l’analyse des licences utilisées. Le premier à recommander est libre: FOSSology a été développé par HP pour son utilisation interne, puis rendu libre en 2007 sous licence GPLv2. Il collecte dans une base de données toutes les meta-données associées aux logiciels analyés (il peut traiter des distributions Linux entières sans problème) et permet l’analyse des licences réellement trouvées dans le code depuis une interface Web. De nombreuses entités outre HP comme Alcatel-Lucent, l’INRIA ou OW2 l’utilisent, y compris pour certains, en couplage avec leurs forges de développement. Mais son accès libre et sa facilité de mise en oeuvre ne le réserve pas qu’aux grands groupes et il devrait être systématiquement utilisé comme complément naturel d’un gestionnaire de source, ou d’outillage d’intégration continue. En complément, des outils non-FLOSS peuvent également aider à ce travail d’inventaire en donnant accès à des bases préétablies de composants connus et déjà inventoriés et fournissent de nombreuses autres fonctions. La société française Antelink, émanation de l’INRIA, a développé une grande expertise dans ce domaine et a couplé son outillage avec FOSSology. D’autres acteurs tels que Blackduck et Palamida ont également un outillage complémentaire à considérer.

On pourra de plus prévoir ultérieurement un mode de déclaration des usages de FLOSS, voire, si les requêtes sont nombreuses et régulières, créer un comité de revue spécifique en charge de les évaluer et de les approuver.

Enfin certains documents de référence tel que le Guide Open Source du Syntec Numérique, les fondamentaux de la Gouvernance des logiciels libres, la vision des grandes entreprises sur la gouvernance et maturité de l’Open Source et le site de référence FOSSBazaar pourront permettre un approfondissement des sujets évoqués et donner des bonnes pratiques additionnelles quant à la mise en oeuvre d’une gouvernance Open Source.

Et pour ceux qui souhaiteraient être accompagnés dans la démarche, des sociétés telles que Smile, Alterway, Linagora, Atos, Inno3 ou HP disposent de prestations d’aide à la mise en oeuvre d’une gouvernance Open Source. Mais que vous le fassiez seuls ou accompagnés, il est temps et j’espère que cet article vous aura donné quelques clefs pour intégrer l’Open Source dans votre politique de Gouvernance Informatique.

(1): Dans tout ce document, on utilise le terme de FLOSS comme terme générique recouvrant aussi bien la notion de « logiciel libre », « Free Software » qu’« Open Source », tout en sachant que des nuances existent.

Tags: AFUL, APRIL, FOSSBazaar, FOSSology, français, Gouvernance, HP, HPLinux, LinuxFoundation, Open Source