Qu'est-ce que l'Open Source d'entreprise ?

Nous savons déjà ce qu'est l'Open Source et beaucoup de choses ont été écrites à ce sujet, selon différents points de vue. Il en existe même une définition complète et pratique, mais quid de l'Open Source d'entreprise ? Sans donner de définition exhaustive, voici ce que nous entendons par « Open Source d'entreprise ».

Premièrement, c'est de l'Open Source. Un produit n'est pas qualifié d'Open Source d'entreprise simplement parce qu'il intègre une bibliothèque Open Source avec une licence permissive, ou qu'il « fonctionne avec » ou « s'exécute sur » de l'Open Source.

Des solutions testées et « renforcées » pour l'entreprise

Tout le monde peut télécharger et installer un projet Open Source, ou le compiler et le déployer tel quel depuis le référentiel en amont. Néanmoins, cela n'apporte aucune valeur au projet et peut comporter des risques.

Pour qu'un produit soit qualifié d'Open Source d'entreprise, il doit être soumis à des tests et ses performances doivent être optimisées. Il faut aussi rechercher de manière proactive ses éventuelles failles de sécurité. Enfin, il doit être pris en charge par une équipe de sécurité qui met en place des processus pour résoudre les vulnérabilités émergentes et informer les utilisateurs des problèmes de sécurité et des mesures correctives.

Si vous êtes seul face aux problèmes de qualité et de sécurité d'un produit, alors la solution que vous utilisez n'est pas de l'Open Source d'entreprise.

Des fonctionnalités adaptées aux entreprises

Les besoins des grandes entreprises et des organisations d'envergure, que l'on regroupera dans cet article sous le terme d'« entreprises » pour plus de facilité, ne sont pas les mêmes que ceux des petites structures et des particuliers.

Par exemple, une petite société ou un simple utilisateur n'a probablement pas besoin de mettre en place un système d'authentification unique, ni d'intégrer des plateformes SSO ou de gérer des répertoires, des calendriers, etc. Il existe certes des utilisateurs technophiles qui ont doté leur environnement personnel de configurations très complexes, mais dans la plupart des cas, ces exigences ne s'appliquent que dans les entreprises d'une certaine taille.

Il en va de même pour les petites boutiques. Elles ne sont généralement pas soumises aux mêmes exigences d'audit et n'ont pas besoin de fédérer des services entre plusieurs datacenters ou clouds publics. Les entreprises clientes doivent disposer de capacités de stockage des données bien supérieures et gérer des systèmes plus complexes. Elles doivent aussi mettre en place des mécanismes de reprise d'activité plus poussés que ceux des PME.

Prenons l'exemple du langage Java : il y a le Java de base et Enterprise Java, qui comprend des API et des serveurs d'applications pour simplifier le développement de logiciels « à l'échelle de l'entreprise » et faciliter leur maintenance à long terme. Si vous devez tenir compte de milliers d'utilisateurs simultanément, vous entrez dans la catégorie des logiciels d'entreprise, et de l'Open Source d'entreprise. Maintenant que nous avons vu les fonctionnalités, nous allons nous pencher sur l'idée de long terme que je viens d'évoquer.

Un cycle de vie long et prévisible

Les environnements informatiques d'entreprise impliquent beaucoup d'investissements et d'efforts de planification. Cela peut être très intéressant si vous aimez apprendre de nouvelles choses et travailler avec les technologies. Néanmoins, l'intérêt de ces technologies est de faciliter le travail des utilisateurs. En général, la majorité d'entre eux n'apprécient pas de devoir réapprendre à utiliser un système ou devoir se passer d'une application, car elle ou ses composants sous-jacents sont devenus inutilisables suite à une mise à jour.

La plupart des applications sur lesquelles nous travaillons sont constituées d'une pile complexe basée sur du matériel robuste, un système d'exploitation stable, un ou plusieurs langages de programmation, quelques bibliothèques ou frameworks et une base de données, ainsi que des données utilisateurs, des configurations et du code développés au sein de l'entreprise.

Si un élément de cette pile est mis à jour et devient incompatible avec la couche supérieure ou inférieure, c'est toute l'application qui est compromise. Si vous tentez d'installer un système d'exploitation sur une couche nouvelle de matériel non testé, vous constaterez peut-être que le réseau ne fonctionne plus, car les pilotes nécessaires ne sont pas installés, ou que le système rencontre des problèmes au niveau du stockage ou de la carte graphique.

Il se peut aussi qu'une mise à jour du système d'exploitation entraîne la mise à jour de la bibliothèque OpenSSL ou l'installation d'une version de Python qui n'est pas prise en charge par votre application.

Un produit Open Source d'entreprise a un cycle de vie prévisible, défini à l'avance et qui inclut des informations sur les composants susceptibles d'évoluer à des rythmes différents. Il a aussi une durée de vie appropriée pour que les entreprises puissent déployer des applications importantes. À titre d'exemple, une version majeure du système d'exploitation Red Hat Enterprise Linux (RHEL) a un cycle de vie de 10 ans.

Un éditeur de logiciels d'entreprise, tel que Red Hat, peut également assumer la lourde tâche de prendre en charge les composants bien après que le projet en amont a évolué vers de nouvelles versions. Un tel suivi est en effet nécessaire pour permettre aux entreprises clientes d'utiliser les logiciels pendant une durée convenable.

La communauté en amont peut avoir cessé le rétroportage de correctifs de sécurité sur une version depuis des années, alors que nous continuons de le faire pour éviter à nos utilisateurs de retravailler leurs applications ou de réaliser des mises à niveau majeures sur des logiciels critiques.

Des certifications

Outre un cycle de vie aligné sur les exigences des entreprises, l'Open Source d'entreprise est aussi caractérisé par des certifications.

Lorsque vous faites l'acquisition de matériel, vous souhaitez qu'il fonctionne avec le système d'exploitation et les applications que vous déployez. C'est pourquoi nous travaillons avec plusieurs partenaires de matériel pour certifier RHEL sur ces plateformes et permettre l'exécution de fonctions comme la passerelle de processeurs graphiques pour Red Hat OpenShift et Red Hat OpenStack Platform.

Il en va de même pour des produits comme Red Hat Enterprise Linux et Red Hat OpenStack Platform. Vous pouvez choisir ces plateformes pour exécuter des charges de travail stratégiques, y compris celles proposées par des éditeurs de logiciels indépendants (ISV). Si vous êtes vous-même un ISV, vous voulez pouvoir dire à vos clients que vos produits s'exécutent correctement sur RHEL et Red Hat OpenStack Platform.

L'intérêt de l'Open Source réside notamment dans la liberté de choix. Vous pouvez accéder au code source et combiner tous les projets comme vous l'entendez du moment qu'ils fonctionnent ensemble. Le choix et la variété sont cependant une source de frustration pour les équipes d'exploitation qui doivent assurer l'assistance en production. C'est aussi un véritable cauchemar pour les équipes infosec qui doivent savoir ce qui s'exécute dans leur environnement et si celui-ci risque d'être affecté par des vulnérabilités.

C'est pourquoi il existe des programmes de certification qui permettent aux ISV de certifier leurs produits pour que les clients puissent les déployer en toute confiance sur nos plateformes. Par définition, l'Open Source d'entreprise réduit l'amplitude du choix pour se concentrer sur des configurations supportables et qui offrent des fonctionnalités nécessaires pour les applications stratégiques.

Des accords de niveau de service et une assistance

Une certification est certes intéressante, mais elle ne vous aidera pas à résoudre un problème en cas de défaillance. Vous avez besoin pour cela d'un service d'assistance.

L'Open Source d'entreprise implique donc aussi de pouvoir faire appel à des fournisseurs qui proposent une assistance et des accords de niveau de service avec un champ d'application détaillé et des délais de résolution définis.

L'assistance ne se limite pas à cela. Elle comprend un grand nombre de tâches et de ressources pour aider les clients à déployer et à gérer leurs applications avec succès. Elle couvre aussi la gestion de la documentation, la rédaction d'articles d'informations et les forums. Certains environnements peuvent également demander l'assistance d'un Technical Account Manager (TAM) qui se consacre à ce compte pour être en mesure d'identifier les problèmes potentiels avant qu'ils n'apparaissent.

Les TAMs sont des experts produits qui disposent de connaissances techniques avancées et aident les clients à planifier leurs déploiements, à ajuster leurs plans et plus encore.

Des formations

Outre les certifications, l'acquisition de connaissances techniques et la formation sont justement une autre caractéristique de l'Open Source d'entreprise. Aux débuts de Linux, les entreprises peinaient à recruter des administrateurs système qualifiés parmi les candidats qui prétendaient être des spécialistes Linux après une installation réussie de Slackware.

Élaborer et maintenir à jour des programmes de formation et de certification est loin d'être simple. Tout d'abord, il faut que les technologies concernées aient atteint une certaine maturité. Ensuite, il faut aussi qu'elles soient adaptées pour des charges de travail critiques et une prise en charge à long terme.

L'intégration

Une autre caractéristique de l'Open Source d'entreprise est l'intégration. Comme un collègue le dit souvent, les communautés qui interviennent en amont sont très douées pour créer des « bouts » de solutions. Si vous êtes à la recherche d'un serveur web novateur, les offres abondent dans la communauté Open Source. Idem si vous voulez un framework ou une base de données robuste, ou encore un bus de messagerie, une plateforme de diffusion des données, du stockage distribué, etc.

En revanche, si vous attendez que toutes ces solutions fonctionnent ensemble et soient opérationnelles dès demain et pendant les années à venir, les choses se compliquent. Dans ce cas, il vaut mieux vous tourner vers de l'Open Source d'entreprise.

Projets ou produits ?

Un autre moyen de définir l'Open Source d'entreprise est de s'intéresser à la différence entre les projets et les produits.

Les projets Open Source sont mis à la disposition des utilisateurs et de la communauté de contributeurs avec différents niveaux de finition. Certains projets, comme Fedora, sont proposés avec une meilleure finition à une large communauté d'utilisateurs et ils sont prêts à l'emploi. D'autres relèvent plus du bricolage et peuvent nécessiter une compilation ou l'assemblage de plusieurs composants avant de pouvoir fonctionner.

Les projets n'ont généralement pas d'employés attitrés. Ils ont des contributeurs qui peuvent travailler sur les technologies à temps plein et être payés par un éditeur (comme Red Hat) pour se consacrer à ce projet. Les contributions peuvent également provenir d'utilisateurs qui travaillent avec ces technologies dans le cadre de leur activité quotidienne et veulent assurer leur bon fonctionnement et les améliorer pour une utilisation future.

Rares sont les projets disposant d'équipes rémunérées pour veiller à la gestion des versions, produire la documentation ou réaliser toute autre activité en relation avec un produit. Si certains projets bénéficient d'un tel accompagnement, par exemple Fedora, c'est parce qu'un éditeur en a décidé ainsi, dans l'intérêt d'un produit. Les projets, en particulier ceux que l'on considère comme intègres, font l'objet d'une gouvernance qui n'est pas contrôlée par une entité unique.

Des utilisateurs à l'extérieur de l'entreprise sponsor peuvent être impliqués et influer sur le projet, dans les limites de leur responsabilité. (Quels que soient votre implication et votre engagement, vous ne parviendrez probablement pas à convaincre le projet Fedora d'abandonner x86-64 pour se concentrer sur les TRS-80 et le rétrocomputing.)

Les produits sont eux généralement caractérisés par tous les aspects que je viens de mentionner : un cycle de vie prévisible, une assistance, des formations, des certifications, éventuellement un écosystème d'ISV et un contrôle exercé par une entité unique qui répond aux besoins d'un marché soumis aux règles de l'offre et de la demande. Dans le cadre d'un produit, le développement de fonctions et l'élaboration de feuilles de route sont planifiés pour répondre aux besoins et aux attentes des clients. Ils ne sont pas laissés au bon vouloir de quelques utilisateurs disposés à travailler dessus, comme cela peut-être le cas avec les projets.

Une synergie

Les projets Open Source et les produits Open Source d'entreprise présentent des différences notables, mais ne s'opposent pas. Le travail investi dans les produits Open Source d'entreprise alimente les projets Open Source pour que tous les utilisateurs de projet puissent en profiter, pas uniquement les éditeurs ou ceux qui paient pour utiliser les produits.

Idéalement, l'Open Source d'entreprise combine le meilleur des deux mondes : les avantages de l'Open Source avec la stabilité, les performances, l'assistance et l'écosystème d'un logiciel d'entreprise.