actualités d’entreprise
Les applications open source ont clairement trouvé leur place dans les systèmes informatiques des grandes et moyennes entreprises. En plus de dominer certains segments comme les serveurs Web, les bases de données et les analyses, les solutions open source sont désormais largement utilisées pour la conteneurisation, l’apprentissage automatique, le DevOps et, évidemment, le développement de programmes. De nombreuses entreprises passent à l’open source pour des tâches non informatiques, comme le CRM, la production de contenu visuel ou la publication d’un blog. Selon Gartner, plus de 95 % des entreprises du milieu informatique utilisent des solutions open source, et ce chiffre dépasse les 40 % et ne cesse d’augmenter au sein des entreprises non informatiques. De plus, ces données n’incluent pas les nombreux cas d’applications propriétaires qui utilisent des bibliothèques open source.
Choisir entre open source et logiciel propriétaire est loin d’être facile : il ne s’agit pas seulement du gratuit versus le payant, ou de l’assistance versus l’absence d’assistance. Lorsqu’elles choisissent une solution informatique, les entreprises doivent prendre en compte plusieurs aspects importants.
Le coût et le délai du déploiement
Même s’il n’y a souvent aucun paiement de licence pour les solutions open source, le déploiement n’est pas gratuit. Selon la complexité de la solution, il vous faudra peut-être ajuster le budget-temps de l’équipe informatique, avoir recours à des consultants experts ou embaucher des développeurs qui vont constamment adapter l’application aux besoins de votre entreprise.
On trouve aussi le modèle de licence hybride qui permet d’utiliser gratuitement une version communautaire de l’application, alors que la version complète « d’entreprise » requiert le paiement d’une licence.
De plus, de nombreux produits open source ne contiennent pas des documents complets et/ou mis à jour, ni des formations pour les utilisateurs finaux. S’il s’agit d’un déploiement à grande échelle, cette lacune devra être couverte en interne et coûtera du temps et de l’argent.
L’avantage de l’open source au moment du déploiement est, évidemment, qu’il permet un test complet. Même si vous envisagez de déployer une solution open source auto-hébergée, ou avec l’aide d’un travailleur indépendant spécialisé, la réalisation de l’essai pilote (preuve de concept) est beaucoup plus efficace si vous la faites vous-même que si vous regardez les vidéos de démonstration des solutions propriétaires. Vous allez immédiatement constater si la solution est fonctionnelle et applicable à votre entreprise.
Lorsque vous comparez les solutions open source et propriétaires avant le déploiement, il est essentiel de comprendre de combien de temps vous disposez pour effectuer les tests, et si vous avez la possibilité de changer le produit à ses débuts. Si le délai n’est pas pressant, et que la réponse à la deuxième question est oui, alors le test approfondi du produit open source semble logique.
Le coût de l’assistance
L’assistance quotidienne et la configuration de nombreuses applications open source à échelle industrielle, ainsi que leur adaptation aux charges de travail importantes, exigent que l’équipe informatique ait des connaissances hautement spécifiques et approfondies. Si cela n’est pas possible, l’entreprise devra acquérir ce savoir-faire, que ce soit en embauchant des experts ou en l’externalisant. Les types les plus courants d’externalisation impliquent l’aide d’experts spécialisés dans l’application (comme Red Hat), ou un auto-hébergement optimisé pour une solution informatique spécifique (comme Kube Clusters, WP Engine ou autres).
Évidemment, l’assistance payante est aussi la norme pour les logiciels propriétaires. Les solutions open source ne sont pas les seules à en avoir besoin. Les coûts sont comparables. Comme le montre la pratique, l’assistance technique annuelle d’une application open source propre à une entreprise n’est que 10 à 15 % moins chère que celle des logiciels propriétaires.
La correction des bugs, l’ajout de nouvelles fonctionnalités et la scalabilité
Même si les solutions open source mâtures sont régulièrement mises à jour avec des fonctionnalités plus complètes et des corrections de bugs, il peut arriver que les développeurs ne donnent pas la priorité à un bug critique pour l’entreprise en question. C’est encore plus courant avec les requêtes de fonctionnalités. Dans ce cas, soit vous vous asseyez et attendez patiemment, soit vous utilisez le temps précieux de vos développeurs (en interne ou en externe) pour écrire le code nécessaire. Le point positif est que cela est possible, du moins en théorie. Le point négatif est que les dépenses sont imprévisibles et peuvent rapidement augmenter.
Il convient de souligner que vous n’avez pas à vous inquiéter des patchs et des mises à jour de l’application avec l’auto-hébergement, mais qu’il ne peut pas vous aider avec les réglages individuels. Une entreprise avec un tel besoin fait certainement son entrée sur le marché du développement et doit choisir le format de l’extension en cours de création : un embranchement du principal produit logiciel ou un ajout à la branche de développement principale en association avec les développeurs originaux de l’application. C’est là que les avantages stratégiques de l’open source entrent en jeu : à savoir la flexibilité d’utilisation et la vitesse d’innovation.
L’intégration et le support multi-plateformes
Pour les solutions à composants multiples à grande échelle qui échangent activement des données, l’intégration et la compatibilité avec d’autres plateformes peuvent jouer un rôle déterminant dans le choix du produit logiciel. La priorité reste le support des formats industriels pour le stockage et l’échange des données, ainsi que des interfaces de programmation d’application (API) bien documentée. La solution d’un seul fabricant avec un code logiciel propriétaire peut parfois mieux répondre à ces critères qu’un ensemble de solutions open source, même de haute qualité. Il est toujours intéressant d’estimer le coût d’ajustement d’une solution open source si elle a montré certains avantages pour d’autres critères et a passé la phase de la preuve de concept.
Les risques, la sécurité et la conformité
L’open source est souvent vendue comme une solution plus sécurisée. Après tout, si tout le monde peut voir le code source et corriger les bugs, ce doit être plus sûr que l’offre en boîte noire du propriétaire, n’est-ce pas ?
Comme toujours, la réalité est plus complexe. Tout d’abord, beaucoup d’applications open source ont des millions de lignes de code que personne ne peut entièrement vérifier. Le nombre important de mises à jour du code complique un peu plus la tâche. Cela étant dit, petit ne veut pas dire sûr. Par exemple, la vulnérabilité Shellshock basée sur Bash est passée inaperçue pendant 20 ans !
Ensuite, le problème de la dépendance est grave puisque les applications et le code ont leur propre chaîne d’approvisionnement. Une application open source peut utiliser une bibliothèque tierce open source, qui à son tour est liée à une autre bibliothèque open source, et les personnes responsables de vérifier l’application ne vont probablement pas analyser toutes les bibliothèques. Les risques d’une telle chaîne ont été démontrés plusieurs fois : une vulnérabilité dans la bibliothèque gratuite Log4j a affecté des milliers de solutions open source et a eu un impact sur certains géants, dont Amazon, Cloudflare et Elastic. Une attaque qui remplaçait les bibliothèques NPM par des homonymes malveillants fonctionnait sur Apple et Microsoft. Et la décision d’un développeur indépendant de ne pas accepter la minuscule bibliothèque left-pad dans le répertoire NPM a bloqué plus de milles applications et sites populaires (dont Facebook) pendant plusieurs heures.
La dépendance des programmes.
Caption: Source : xkcd.com/2347
La licence est un des autres problèmes causés par cette dépendance. Les licences open source sont assez spécifiques, et ce n’est parce que c’est gratuit qu’il n’y a pas de détenteur des droits d’auteur. L’application et ses bibliothèques peuvent avoir plusieurs licences, et le non-respect d’une des plus strictes (le copyleft) est rempli de procès. Similaire au processus bien établi de l’audit de sécurité informatique et de la mitigation des vulnérabilités, les principaux utilisateurs et développeurs de programme open source devraient avoir mis en place un processus similaire afin de vérifier régulièrement leur conformité à la licence. Dans l’idéal, ce processus devrait être semi-automatisé.
Tous les points mentionnés ci-dessus ne veulent pas dire que l’open source est le pire choix depuis le point de vue de la sécurité de l’information. Vous devez juste comprendre tous les risques qui en découlent : l’équipe de déploiement doit évaluer la culture de développement et la fréquence de sortie des mises à jour de sécurité des applications participantes, et doit aussi contrôler les dépendances et les licences (par exemple, en achetant un inventaire logiciel, ou SBOM). De plus, si votre entreprise travaille dans le domaine du développement de logiciels, il convient d’analyser tous les packs open source pour rechercher d’éventuelles vulnérabilités et fonctionnalités malveillantes.
Conseils