Devra-t-on rendre l'open source obligatoire ?

L’open source a bien des avantages, mais il est des domaines où il est pratiquement obligatoire, ou devrait l’être. Car il rend les appareils plus fiables et renforce le contrôle de la sécurité des équipements et logiciels. De plus, l'open source est le seul gage d'une pérennité de long terme, puisqu'il est la voie naturelle de mise en œuvre des standards.

L’open source a bien des avantages, mais il est quelques domaines où l’open source est pratiquement obligatoire, ou du moins devrait l’être. 

Citons-en quelques-uns.

Vers un pacemaker open source ?

Pour bien expliquer la nécessité de “contrôler le logiciel qui, de plus en plus, contrôle nos vies”, il m’arrive de prendre en exemple le pacemaker, un dispositif implanté qui stimule électriquement des cœurs malades. Les pacemakers sont des objets sophistiqués, ils reçoivent des signaux de multiples capteurs et les analysent pour en déduire si une stimulation électrique est nécessaire. Tout cela sous le contrôle d’un programme complexe, comme on peut l’imaginer. Comme il n’y a rien de plus critique que de faire battre un cœur, on imagine que l’illustration peut marquer les esprits. Je n’ai pas inventé cet exemple, il a été cité par plusieurs auteurs depuis que Karen Sandler, directrice de la Gnome Foundation, a effectivement eu besoin d’un pacemaker en 2012, et a engagé un combat pour en disposer du code source.

C’est un exemple qui amène deux réflexions. La première est éthique : si ma vie doit dépendre de quelques lignes de code, n’est-il pas légitime que je puisse les connaître et les analyser ? La seconde est plus terre à terre : ce programme censé m'aider à vivre pourrait-il être de meilleure qualité si son code était rendu disponible ?

Un nombre croissant de dispositifs médicaux intègrent du logiciel, et souvent dans des fonctions critiques. Dans beaucoup de cas, un dysfonctionnement du logiciel, un bug, aura des conséquences très graves en termes de santé, parfois mortelles. On se souvient de défauts logiciels sur des appareils de ratiothérapie, qui ont causé de nombreuses morts.

L’open source peut sauver quelques vies
Les pompes à médicaments sont aussi des dispositifs intégrant une part croissante de logiciel. Aux Etats-Unis, la FDA, l’agence américaine du médicament, estime que, entre 2005 et 2009, il y a eu plus de 20 000 dommages graves et plus de 700 morts, du fait de dysfonctionnements de pompes à médicaments, une majorité de ces défaillances étant d’origine logicielle. Et l’agence américaine estime que des logiciels open source pourraient être le moyen de relever la qualité, souvent médiocre, de ces logiciels. Les autres industries utilisant le logiciel dans des missions critiques, en particulier l’aéronautique ou le nucléaire, ont travaillé depuis longtemps à améliorer la qualité de leurs logiciels. Parfois, mais pas exclusivement, en s’appuyant sur du logiciel open source, et les pratiques associées. Or les industriels du médical sont loin d’avoir le même historique. L’intégration de logiciel est relativement nouvelle pour eux, et souvent prise en charge par de petites équipes.

Doit-on exiger que les dispositifs médicaux n’intègrent que du logiciel open source ? Au delà de l’exigence de principe de pouvoir contrôler le logiciel dont dépend ma vie, la finalité serait très pragmatique: le plus sûr moyen de relever rapidement une qualité de logiciel souvent très insuffisante, qui cause des morts chaque année.

A la rigueur, l’open source véritable – le droit non seulement d’étudier le code, mais aussi de le modifier et de le redistribuer – est peut-être une exigence superflue dans ce cas particulier. Le seul droit d’étudier serait déjà un grand pas en avant. Il s’accompagnerait inévitablement du droit de critiquer, de signaler les bugs, et au moins d’en proposer une amélioration. Ainsi, on amènerait mécaniquement un progrès rapide dans la sûreté de ces dispositifs. Et l’on peut être certains que les logiciels véritablement open source ne tarderaient pas alors à supplanter les autres.

De nombreux universitaires travaillant dans le médical ont regretté aussi cette barrière infranchissable entre d’un côté leur recherche, qui fonctionne en mode ouvert, collaboratif et incrémental, comme la science a toujours fonctionné, et de l’autre ces dispositifs et leurs logiciels embarqués dont ils ne peuvent rien connaître, rien étudier, rien améliorer.

La sécurité est elle possible sans open source ?

Il y a plusieurs autres domaines où l’accès au code source semblerait être une nécessité absolue. On peut citer la sécurité des équipements réseau, par exemple.

Ces derniers six mois, les équipementiers chinois Huawei et ZTE ont été l’objet de critiques violentes aux Etats-Unis, certains les soupçonnant d’intégrer dans leurs routeurs des “portes dérobées” pouvant servir à l’espionnage des communications par la Chine. Difficile de dire si ces accusations relèvent du simple protectionnisme, où si elles ont quelque fondement. Mais il est incontestable que c’est une possibilité technique, et l’on pourrait de la même manière soupçonner Cisco vis à vis de son propre gouvernement.
Pour se défendre de ces accusations, Huawei a annoncé il y a peu, qu’elle donnait à certains gouvernements un accès illimité au code source de ses routeurs. On ne sait pas si l’offre sera suffisante pour lever l’interdiction des produits Huawei sur ces marchés publics. En général, envoyer un expert dans une salle isolée, pour auditer du code source, même pendant plusieurs semaines, n’est pas suffisant. Il faut au minimum être en mesure de regénérer à l’identique, au moyen de logiciels eux-mêmes vérifiés, l’ensemble des logiciels embarqués. Mais même ainsi, les volumes sont tellement énormes qu’un simple audit aura beaucoup de mal à en faire le tour. Sans parler des mises à jour... Bref, la tâche est immense, même pour un État.
Non, vraiment, la seule réponse solide à ces préoccupations est l’ouverture totale de l’ensemble du code, si ce n’est sous des licences open source, du moins en libre accès. On dispose alors de la capacité d’audit presque infinie des experts du monde entier.
Quand on aura traité le cas des routeurs, on pourra se poser les mêmes questions concernant les logiciels de messagerie qui, eux aussi, peuvent intégrer des portes dérobées. Mais de bien d’autres logiciels aussi, qu’il s’agisse d’infrastructure (VPN, Firewall, sauvegarde, …), et bien sûr on pourra aller jusqu’aux ERP: est-il tout à fait impossible que certains transfèrent des informations confidentielles sur les entreprises qui les utilisent ? On ne le saura vraiment qu’en disposant de leur code source.
Nous avons souvent souligné les multiples bénéfices que pouvaient apporter les logiciels open source: aux utilisateurs, aux entreprises, aux progrès de la connaissance, à l’humanité donc. Pour autant, nous ne pensons pas que le logiciel propriétaire ne puisse être que nocif. Dans de nombreux domaines, chaque décideur est libre d’apprécier les atouts spécifiques de logiciels open source, et de les retenir ou non. Mais dans certains domaines, tels que la santé ou la sécurité, ce ne sont pas juste des bénéfices à prendre ou à laisser, l’open source pourrait bien être une nécessité vitale.

Seul l’open source est gage d’une vraie pérennité

Nous pourrions citer encore quelques autres domaines où l’open source est une nécessité pratique. Il y a quelques semaines, j’étais invité à participer au colloque “Innovation Ouverte”, organisé par Aquinetic, le pôle de compétence logiciel libre d’Aquitaine (qui à cette occasion devenait la 11ème association constituant le CNLL). Parmi les thématiques abordées, celle du support de très longue durée.
Pierre Gaufillet, spécialiste méthodes génie logiciel au département avionique d’Airbus, expliquait l’impératif d’un support de 80 années pour le logiciel embarqué dans un avion de ligne.  Le logiciel et la totalité de son environnement d’exécution et de développement, bien sûr.  A cette échelle de temps, expliquait-il, aucune entreprise commerciale, aussi géante et solide soit-elle, ne peut s’engager de manière crédible. En d’autres termes, pour du support très longue durée, l’open source est, de facto, la seule alternative raisonnable.


Nous pourrions citer également le domaine des standards, qui sont souvent la base de toute interopérabilité. Dans l’informatique, de nombreux standards ne sont parfaitement décrits que lorsqu’ils sont accompagnés d’une implémentation de référence. Une telle première implémentation, pour contribuer à spécifier le standard, doit pouvoir être analysée librement, et ne peut donc qu’être open source. Or une implémentation open source d’un standard n’est possible que s’il est libre de droits, “royalty-free”. Des standards qui seraient contraints par des brevets non libres de droits, même soient-ils “FRAND” (“Fair, Reasonable and Non-Discriminatory”) c’est à dire d’un coût réputé équitable, raisonnable et non-discriminatoire, ne peuvent pas être implémentés par un logiciel open source qui, par essence, ne pourra exiger le paiement de droits. C’est un autre sujet, qui méritera un article à part entière.

Pas d’idéologie, du bon sens seulement

En conclusion, s’il est encore difficile d’exiger que tout le logiciel du monde soit open source, il est des domaines d’une importance critique, que ce soit en termes de santé, de sécurité, de droits individuels, de pérennité ou encore d’interopérabilité, des domaines où il n’y a pas d'alternative sérieuse au logiciel open source.  Il ne s’agit pas d’idéologie, mais de bon sens.

Autour du même sujet