Dans le meilleur des cas, elle crée des incertitudes et de la confusion inutiles. Dans le pire des cas, elle pourrait faire augmenter les coûts pour l’utilisateur final et avoir un effet dévastateur sur l’innovation technologique dans la région.

Pourquoi une réglementation est-elle nécessaire ?

Nous vivons dans un monde centré sur les technologies de logiciels et technologies connectées. Celles-ci interviennent à tout niveau : de l’uniformisation des chaînes logistiques mondiales au maintien des avions dans les airs. Mais les logiciels étant conçus par des humains, ils sont inévitablement sujets aux erreurs et aux failles. Cela représente un risque croissant, dans un monde où, selon les estimations de l’UE, le coût annuel de la cyber-criminalité au niveau mondial pouvait atteindre 5 500 milliards d’euros en 2021. Certains états-nations enhardis ou cyber-criminels motivés par l’appât du gain exploitent de plus en plus fréquemment ces failles afin d’atteindre leurs objectifs. Ils utilisent même des algorithmes de l’IA pour optimiser leurs campagnes malveillantes.
Dans ce contexte, les composants de logiciels open source représentent à la fois une bénédiction et une malédiction. Ils permettent d’aider les développeurs à accélérer le Time to Value en sélectionnant des composants pré-intégrés. Mais ils ajoutent également de la complexité et des risques. Il est de plus en plus fréquent pour des composants de contenir des bugs ou malware, mais ceux-ci peuvent être compliqués à isoler et à repérer au sein d’un environnement informatique global.
Pour résumer, nous sommes maintenant dans une situation où les infrastructures critiques sont construites sur la base de logiciels qui ne sont pas pleinement maîtrisés sauf par ceux qui les ont développés. Et le secteur des logiciels en lui-même n’est pas réglementé, ce qui fait qu’il n’existe aucune norme agréée établissant un niveau de sécurité pour le code. L’absence de réglementation, la complexité croissante et le manque de directives de sécurité compréhensibles représentent une menace au niveau sociétal et économique.
Dans ce contexte, nous étions initialement favorables à l’émergence de la Loi sur la Cyber-Résilience. Ses objectifs paraissaient concrets : faire en sorte que les fabricants améliorent la sécurité sur l’ensemble du cycle de conception et de développement des produits, et créer un cadre cohérent pour assurer le respect des bonnes pratiques par les développeurs. La loi devait également comporter de nombreux avantages pour l’utilisateur final, avec une plus grande transparence des capacités en termes de sécurité et la possibilité pour les entreprises et les particuliers d’utiliser équipements et logiciels de manière plus sécurisée.

Intention louable, exécution ratée

Hélas, si l’intention était bonne, nos premières impressions de la loi ne le sont pas. Pourquoi cela ? Le premier problème concerne la certification. On va demander aux développeurs qu’ils créent et conçoivent leurs logiciels en accord avec les exigences législatives. Mais les personnes accordant la certification aux logiciels sont susceptibles d’être issus d’un environnement non technique. Il existe un risque d’incohérences et d’erreurs. En second lieu, il faudra considérer la charge administrative et financière reposant sur la communauté du logiciel start-up. Si les grandes entreprises auront moins de mal à surmonter la lourdeur bureaucratique, un grand nombre de petites structures risquent d’être dépassées par les exigences en termes de pré-étude et de préparation des documents de conformité. Le risque de les voir fuir totalement la région est bien réel.
Le troisième problème concerne les incertitudes. La loi telle qu’elle a été conçue est extrêmement confuse. Personne ne comprend réellement de façon claire les implications, tant le langage utilisé dans le document est sujet à interprétation. Si les coûts finissent par être répercutés sur l’utilisateur final, ces organisations vont-elles tout simplement se tourner vers l’extérieur de l’UE et vers des logiciels qui n’auront pas eu besoin de franchir les nombreuses contraintes réglementaires de l’UE ? D’ailleurs en auront-elles le droit ?
Ces incertitudes sont particulièrement critiques au sein de la communauté open source, qui repose sur les contributions de développeurs aux quatre coins du monde, mais n’a souvent ni les ressources, ni le savoir-faire pour analyser les implications d’exigences de conformité complexes. Peut-être que le plus simple pour les développeurs hors UE serait de limiter l’accès à leur code aux seuls résidents de leur région. Dans le même temps, les développeurs au sein de l’UE pourraient hésiter à partager leur code en raison des coûts de conformité élevés. Cela pourrait avoir un effet dévastateur sur l’innovation. Il existe une autre interrogation, pour l’instant sans réponse, concernant l’ensemble du code open source actuellement utilisé. Sa conformité devra-t-elle être évaluée de façon rétroactive ?

L’heure de la clarification et de la prudence
Il n’existe pas de réponses toutes faites, même si les développeurs pourraient envier les États-Unis et leur approche beaucoup plus souple de la réglementation en termes de cyber-sécurité. Là-bas, le gouvernement consulte les experts du secteur et avance pas à pas, au lieu de vouloir en accomplir trop avec une approche choc qui pourrait tout faire sauter. L’accent a également été mis sur la responsabilité des fabricants de logiciels commerciaux plutôt que celle des contributeurs open source.
Heureusement, l’UE commence à entendre le message de la communauté open source, et à en tenir compte. À elle maintenant de rassurer les développeurs sur le fait que les référentiels et les projets vont rester en ligne, et sur la recherche d’un équilibre entre une amélioration de la sécurité de base et le maintien opérationnel des organisations des secteurs public et privé.
Nous pouvons encore espérer une issue positive, si les législateurs de Bruxelles entendent nos appels à la clarification et au bon sens. Une opportunité s’ouvre également pour les législateurs du Royaume-Uni, remarquablement silencieux sur la question. S’ils parviennent à sélectionner le meilleur des deux approches de part et d’autre de l’Atlantique, nous pourrions même obtenir la réglementation de sécurité la plus performante au monde.