Sans code open source, le monde tel que nous le connaissons aujourd’hui cesserait brusquement d’exister. Même les logiciels d’entreprise en regorgent. Et à juste titre : il n’y a aucun intérêt à réinventer l’eau chaude. Pourtant, l’open source n’est pas sans risques.

1. Amateurs ou professionnels ?

La première grande inconnue est la qualité du code. En général, l’open source a bonne réputation. Les grands projets open source sont gérés par des développeurs professionnels, issus des quatre coins du monde. Les mises à jour au codage maladroit sont nettoyées et les meilleures pratiques sont respectées. Mais tous les projets ne sont pas suivis aussi scrupuleusement que le noyau Linux. Une certaine prudence est donc de mise, en particulier avec les petits fragments de code. Un fragment de code utile peut tout aussi bien avoir été rédigé par dix professionnels que par un étudiant solitaire de première année, aussi ambitieux que dépourvu de talent.

Voici quelques principes de précaution qui vous seront d’un grand secours. Prenez la peine d’évaluer la qualité de la documentation du code et la quantité de commits. Vous pouvez aussi vous aider d’outils en ligne ou procéder vous-même à un échantillonnage. Le premier pas consiste donc à réaliser qu’un projet pratique n’est pas forcément un projet de qualité.

2. Support

D’autre part, ne perdez jamais de vue l’importance du support. Les projets populaires d’envergure trouvent toujours les bénévoles qui les aideront à survivre, mais qu’en est-il des fragments de code plus petits ou plus ciblés ? Un gourou du Java perdu dans les montagnes du Nebraska peut rédiger un code qui fera son succès pendant vingt ans, jusqu’au moment où il prendra une retraite bien méritée et dira adieu au monde du 0/I. Le projet se mettra alors à stagner, alors même que son code demeure un élément essentiel de l’application d’entreprise que vous utilisez.

Il est donc judicieux d’évaluer l’enthousiasme que suscite un certain composant. Votre application fait l’objet d’un commit par le même expert tous les six mois ? Ou est-elle scrupuleusement tenue à jour par des collègues du monde entier sur une base hebdomadaire ou quotidienne ? Lorsqu’un projet vraiment utile devient moribond, vous pouvez naturellement envisager d’en devenir parrain ou marraine. La communauté open source est toujours prête à donner, pour autant qu’on donne en retour.

3. Que pouvez-vous vous autoriser ?

Même si vous vous trouvez loin du monde des grandes entreprises, les licences restent de rigueur. Un code open source aussi fait l’objet de licences. Pour des projets personnels, pas besoin de vous en inquiéter. Mais si vous souhaitez intégrer du code dans une application d’entreprise, mieux vaut réfléchir à deux fois.

Il existe des centaines de types de licence pour l’open source. Certaines permettent absolument tout. Dans ce cas, vous pouvez modifier sans crainte le code d’un composant et l’utiliser dans l’application que vous développez, qu’elle soit destinée à un usage interne ou externe.

Lorsqu’il s’agit de « licences copyleft », c’est différent. Le code qui fait l’objet d’une telle licence peut encore être utilisé dans votre propre logiciel, mais vous serez tenu de repartager vos modifications avec la communauté open source lorsque vous publierez le logiciel final. Une condition qui peut s’avérer problématique si vous réalisez une application d’entreprise commerciale contenant un composant open source.

Et quid des nombreux fragments de code qui ne font l’objet d’aucune licence désignée ? Eux aussi sont pourtant soumis à la législation sur les droits d’auteur. Les employer dans des produits commerciaux présente donc des risques. Dès lors, soyez prudent lorsque vous intégrez du code open source dans votre application d’entreprise.

4. Sûr, mais pas infaillible

Enfin, lorsque vous intégrez de l’open source, mieux vaut réfléchir aux répercussions en matière de sécurité. Étant donné que n’importe qui peut vérifier un code open source, il est généralement plus sûr que les alternatives développées entre les murs d’une entreprise privée. En effet, 500 paires d’yeux en voient bien plus que cinq et plus personne ne croit au principe de la « sécurité par l’obscurité ».

Et pourtant, il arrive que quelque chose échappe même à des centaines de personnes. Prenez l’exemple du fameux outil d’identification open source Log4j. Il est intégré dans des dizaines de milliers d’applications de par le monde, des applications d’entreprises internes d’une PME aux programmes de géants tels que VMware. Mais il est apparu récemment que Log4j contenant une faille critique, avec des conséquences graves à la clé. Tout utilisateur ayant intégré ce composant open source dans une application doit donc maintenant réaliser une mise à jour pour cette application.

Tout ira bien tant que vous saurez exactement quels composants open source vous avez utilisés dans vos projets et que vous vous assurerez qu’ils ne présentent aucune vulnérabilité. Procédez donc à un inventaire de vos composants et des applications dans lesquelles vous les avez intégrés, et suivez régulièrement leur statut.

5. Gestion

Nous pourrions résumer ces principes en une seule règle d’or : sachez ce que vous utilisez, et dans quoi. En répertoriant vos applications d’entreprise et les composants open source de chacune, vous éviterez bien des problèmes. Du moment que vous n’oubliez pas que « gratuit » ne signifie pas « sans licence ».