Monsieur le Conseiller fédéral,
Mesdames, Messieurs,

Vous nous avez invités à prendre position dans le cadre de la consultation relative à la loi fédérale sur l’utilisation des moyens électroniques pour l’exécution des tâches des autorités (LMETA). C’est volontiers que nous saisissons cette occasion.

Depuis 2011, Opendata.ch s’engage pour que davantage de personnes aient accès à davantage de données et puissent en tirer davantage de connaissances, de progrès et de valeur ajoutée. Organisé en association d’utilité publique, Opendata.ch met en réseau et organise depuis des années autour de questions de politique et de technique des données et mène notamment, avec les hackathons, des formats d’innovation interdisciplinaires.
La promotion d’une culture Open Data à tous les échelons de l’administration tient particulièrement à cœur à l’association, y compris dans le cadre de sa collaboration de longue date avec la Confédération.

Opendata.ch salue l’orientation générale de la loi. Nous estimons toutefois que, précisément dans le domaine en rapide évolution de la numérisation, il faut tenir compte encore plus fortement et plus rapidement d’une série de développements déjà en cours. Cela afin de préserver de manière adéquate la capacité d’action des autorités à l’avenir et de tenir compte des besoins évolutifs des citoyennes et citoyens, de l’économie et de la société civile.

Dans leur version actuelle, les articles sur l’Open Data et l’Open Source manquent de la portée nécessaire, du caractère contraignant requis et des instruments indispensables pour engager efficacement des étapes décisives vers une numérisation réussie et pour les mesurer en continu. Nous regrettons vivement l’absence d’un article consacré aux interfaces, dont l’importance ne cesse de croître. Nous regrettons tout aussi vivement que l’avant-projet ne prévoie pas la possibilité pour les autorités de collaborer non seulement avec des entreprises, mais aussi avec des organisations de la société civile numérique, notamment les associations actives dans le domaine de l’Open Source et de l’Open Data.

Vous trouverez ci-joint nos propositions détaillées visant à améliorer concrètement l’avant-projet. Nous sommes confiants que vous pourrez en tenir compte dans la suite du processus. Nous ne pouvons soutenir l’avant-projet actuel qu’à cette condition, c’est-à-dire avec des formulations plus ciblées et plus contraignantes sur les thèmes mentionnés et une meilleure prise en compte de la société civile. Nous vous remercions de l’attention que vous porterez à nos remarques et vous prions de tenir compte de nos préoccupations.

Veuillez agréer, Monsieur le Conseiller fédéral, Mesdames, Messieurs, nos salutations distinguées.

Andreas Kellerhals, président d’Opendata.ch
Hannes Gassert, vice-président d’Opendata.ch

Remarques sur l’art. 2 Champ d’application

Dans l’optique d’un effet plus large, en particulier des dispositions relatives à l’Open Data, une extension du champ d’application nous paraît clairement indiquée, par analogie par exemple avec les lois thématiquement proches que sont la LTrans et la LAr. Les personnes de droit public ou privé devraient à tout le moins être elles aussi soumises à la LMETA, dans la mesure où elles accomplissent des tâches d’exécution de la Confédération qui leur ont été confiées.

Remarques sur l’art. 4 Principes

La formulation de cet article accorde plus de poids aux risques qu’aux opportunités, puisqu’elle explicite les premiers, mais pas les secondes. Dans un souci d’équilibre, nous jugeons donc opportun de mentionner également les principales opportunités, telles que l’accélération et la simplification de l’activité administrative ou l’accroissement de la participation.

En outre, il manque selon nous, en plus des obligations de coordination et d’accessibilité, une obligation d’adapter en permanence les processus à la numérisation. Nous proposons donc un alinéa supplémentaire:

4 Lors de l’élaboration de lois, d’ordonnances et de directives, elles veillent à ce que les moyens électroniques soient utilisés de manière efficace et prioritaire.

Qui numérise un processus sous-optimal n’obtient qu’un processus numérique sous-optimal. On peut activement l’éviter, ce que nous estimons nécessaire.

Remarques sur l’art. 7 Prise en charge des coûts

Du point de vue de l’Open Source et de l’Open Data, mais aussi dans une perspective de start-up, se pose ici la question du préfinancement. Pour que des conventions au sens de l’al. 1 ne soient pas possibles seulement avec des acteurs établis et bien financés, mais aussi avec des acteurs émergents dans le domaine de la «civic tech» et de la «gov tech», il faut au moins aborder ici la question du financement de l’innovation et du préfinancement.

À notre avis, il est donc urgent de ne pas considérer ici uniquement la prise en charge des coûts d’exploitation, mais d’inclure également le financement des innovations nécessaires à un stade précoce. En Allemagne, cela est notamment garanti par le «Prototype Fund», financé par le ministère fédéral de l’Éducation et de la Recherche. Étonnamment, son équivalent suisse est en revanche actuellement financé de manière purement privée.

La LMETA offre ici une chance d’ouvrir de nouvelles possibilités innovantes pour la Suisse également, y compris avec des acteurs non traditionnels. Nous proposons donc de compléter l’art. 7 dans ce sens, par exemple par le nouvel alinéa suivant:

2 La Confédération peut fournir un préfinancement et un financement de démarrage si une réglementation au sens de l’al. 1 peut être trouvée.

Remarques sur l’art. 10 Logiciels libres (OSS)

Nous saluons tout particulièrement la réglementation claire de cette question. L’ancrage du principe de l’Open Source au niveau de la loi est juste et important.

Les formulations actuelles ne vont toutefois clairement pas assez loin. Les logiciels libres représentent une chance exceptionnelle de renforcer de manière décisive l’autonomie numérique de la Suisse, d’apporter une contribution importante au développement de notre société numérique du savoir — et de réduire les coûts, en particulier d’un point de vue économique. La stratégie Open Source de la Commission européenne le constate elle aussi clairement.

Sur la base de cette appréciation, nous sommes convaincus que la formulation potestative proposée («peut») ne saurait suffire. À notre avis, l’al. 1 doit être modifié comme suit:

1 Les autorités fédérales soumises à la présente loi mettent à disposition les logiciels (..):

Des exceptions à ce principe peuvent être autorisées par le département compétent si le secret de fonction, la sécurité nationale ou d’autres facteurs prépondérants légitimes l’exigent. Cela équivaut à un «open by default» au sens de l’art. 11, également pour les logiciels. À titre d’alternative, une obligation d’examiner des alternatives Open Source peut être envisagée, pour autant qu’elle soit suffisamment contraignante.

Afin de ne pas concurrencer inutilement l’économie privée, nous proposons de concevoir l’al. 4 de manière plus différenciée et d’exiger, au lieu d’«émoluments couvrant les coûts», plutôt une «rémunération conforme au marché» lorsqu’il existe un marché pour des prestations comparables.

Indépendamment des points mentionnés ci-dessus, nous estimons nécessaire d’aborder ici, à l’art. 10, la question des acquisitions. D’une part, l’«open by default» doit être reflété de manière contraignante dans les critères d’adjudication. D’autre part, la pratique montre qu’il faut dans tous les cas accorder suffisamment tôt une attention suffisante à l’aspect de l’ouverture du code source pour que les divers avantages des OSS, notamment le «total cost of ownership», puissent se déployer. Nous proposons donc le nouvel alinéa suivant:

6 La mise à disposition est planifiée suffisamment tôt lors de la conception, de l’acquisition et du développement du logiciel.

Pour conclure, nous sommes convaincus qu’avec ce caractère plus contraignant, l’art. 10 ouvre clairement davantage de possibilités d’effets positifs pour les autorités comme pour l’économie. La part de la valeur ajoutée réalisée en Suisse lors des acquisitions de logiciels devrait par exemple augmenter sensiblement.

Remarques sur l’art. 11 Données publiques ouvertes (OGD)

L’ancrage légal de l’«open by default» est une étape importante pour la Suisse numérique. L’économie, la science et la société civile, mais aussi les autorités elles-mêmes, devraient en retirer une grande utilité.

Ici aussi, nous souhaitons toutefois insister sur un renforcement du caractère contraignant. Les stratégies nationales en matière d’Open Data ainsi que l’audit transversal correspondant du Contrôle fédéral des finances (CDF) ont montré qu’un caractère plus contraignant est nécessaire. Nous proposons donc de préciser l’al. 1 comme suit:

1 Les unités administratives de l’administration fédérale centrale sont tenues de mettre activement les données (..) à disposition en vue de leur libre réutilisation. Toute personne a le droit de consulter ces données, de les utiliser et d’obtenir des autorités des renseignements sur leur contenu.

Actuellement, de nombreuses données relevant de l’Open Government Data ne sont mises à disposition que si une demande motivée est déposée. Cela contredit clairement l’esprit de l’OGD. Une précision telle que proposée ci-dessus («activement») permet de l’éviter et d’ancrer clairement aussi dans le droit l’exigence de la stratégie correspondante

En outre, un droit d’accès clair doit être défini, par analogie avec la LTrans. C’est le but de la deuxième phrase de notre proposition pour l’art. 11, al. 1.

L’al. 3a restreint inutilement la libre utilisation des données des autorités. La protection des données et des informations est déjà mentionnée dans les stratégies de 2014 et de 2019. Il n’est pas nécessaire d’ajouter des restrictions, car ce sont précisément les registres (à l’exception du registre de l’état civil) ou des plateformes comme simap.ch qui contiennent des données devant bel et bien être considérées comme des données administratives ouvertes par principe et qui doivent enfin être rendues accessibles à la réutilisation. Elles permettent des analyses structurelles indispensables à une société moderne et à ses débats politiques.

Toujours au vu des expériences faites avec les stratégies nationales en matière d’Open Data, l’al. 3b doit être complété par une obligation de prouver une éventuelle disproportion. Une simple déclaration selon laquelle une ouverture serait trop coûteuse ne doit pas suffire. En outre, il faut impérativement examiner au cas par cas si les charges peuvent être réduites par l’utilisation de moyens techniques nouveaux ou différents conformes à l’«état de la technique». Celui-ci se mesure à la pratique la plus efficace déjà établie dans les cantons ou les communes.

L’al. 5 nous paraît discutable; nous proposons de le biffer. L’exactitude et l’exhaustivité ne peuvent jamais être démontrées qu’à l’usage. Un contrôle préalable complet et une garantie d’exactitude constituent de grands obstacles à la publication. Il est en revanche essentiel d’exploiter de manière fiable des canaux clairement définis pour les retours sur les données, afin que celles-ci puissent être améliorées en permanence. C’est à notre avis l’«état de la technique», tel qu’il est pratiqué par exemple dans les transports ou pour les géodonnées.

Dans le même but, une obligation pourrait en outre être introduite de fournir, dans les métadonnées, des informations claires sur l’exactitude, l’exhaustivité et la plausibilité.

Outre le caractère contraignant, il faut selon nous accélérer le rythme de mise en œuvre. Les restrictions à l’«open by default» doivent en même temps être maintenues au strict minimum! Il convient en particulier de renoncer à des processus de validation complexes impliquant un grand nombre de parties prenantes. La Confédération doit pouvoir décider seule de l’ouverture des données, y compris des données de tiers avec lesquels elle travaille ou qu’elle gère de manière centralisée pour eux

Remarques sur l’art. 13 Normes

La formulation «Elle s’inspire des normes reconnues ou répandues au niveau international.» est trop faible; une orientation seulement approximative va à l’encontre du sens et du but des normes. En outre, la simple diffusion ne suffit pas comme critère d’adéquation d’une norme pour la Suisse et ses autorités. Nous suggérons donc d’ajouter une phrase telle que la suivante:

Dans la mesure du possible et lorsque cela est judicieux, on choisit des normes librement et ouvertement disponibles et disposant d’une implémentation de référence ouverte.

Remarques sur l’art. 16 Dispositions transitoires

Concernant l’al. 1: le délai maximal doit être fixé à 2 ans au lieu de 5, en particulier au regard de l’art. 11. Une stratégie nationale contraignante en matière d’Open Government Data existe depuis 2014; pour que la Suisse ne perde pas le fil, il faut maintenant accélérer le rythme.

Concernant l’al. 2: il existe bien entendu déjà une obligation de libérer les données avant l’entrée en vigueur, à savoir par la stratégie nationale contraignante en matière d’Open Data mentionnée. Cette obligation existe depuis 2014, la présente loi ne doit pas en délier. Si une formulation est nécessaire ici, «avant l’entrée en vigueur de la présente loi» doit être remplacé par «avant l’ année 2014». Une possibilité acceptable pour nous est de donner la priorité à la publication des données actuelles, la publication rétroactive venant dans un second temps.

Remarques sur l’art. 17

À notre avis, l’al. 2 doit être biffé, en particulier au regard de l’art. 11; compte tenu de l’urgence de progrès clairs évoquée, la loi doit entrer en vigueur dès son adoption.

Remarques sur le thème des interfaces (API)

À l’avenir, les interfaces, dites interfaces de programmation d’applications (API), compteront parmi les principaux moyens électroniques d’exécution des tâches des autorités. Elles permettent la communication de logiciel à logiciel et sont déjà utilisées à divers endroits aujourd’hui. L’objectif est chaque fois soit de donner accès à certains jeux de données sans libérer l’ensemble de la base de données en tant qu’OGD, soit, et c’est de plus en plus important, de permettre l’accès à des fonctions. Cela facilite massivement l’interaction entre applications, ce qui non seulement rend possibles de nouvelles applications, mais accroît aussi nettement la réutilisation de ces fonctions et donc leur utilité.

Le thème des interfaces revêt déjà aujourd’hui une grande importance — et celle-ci va encore croître. Nous estimons donc urgent d’édicter les règles nécessaires dans un article distinct de la LMETA.

En font partie:

Un principe «API by default», par analogie avec l’«open by default» de l’art. 11 sur l’OGD. Les logiciels nouvellement développés doivent disposer d’interfaces documentées et, dans la mesure du possible, potentiellement utilisables par tous. Un délai transitoire doit être défini pour les «logiciels existants» (legacy software).
Les interfaces disponibles et leurs métadonnées doivent être publiées sur une plateforme centrale analogue à celle de l’OGD — ou, idéalement, sur la même plateforme. Cette plateforme doit mettre à disposition une «gestion des API» permettant d’attribuer des droits d’accès et des limites de requêtes par fonction et par classe de fonctions.
La classification des fonctions («API endpoints»), p. ex. en «publique», «publique avec authentification», «partagée» (p. ex. entre les échelons fédéraux) et «privée» (uniquement au sein de l’administration fédérale), est effectuée par le département compétent, de même que l’attribution correspondante des autorisations.
Le département compétent exploite un «point d’orientation unique» central auquel peuvent être adressées des propositions de nouvelles interfaces, des suggestions d’amélioration, etc.
Les interfaces doivent être conçues selon des normes internationales ouvertes, conformément à l’art. 13.

Le thème des interfaces fait le pont entre les thèmes de l’OGD, des OSS et des normes; une réglementation claire et contraignante est nécessaire de notre point de vue. Le potentiel pour l’économie et la société est énorme. Nous renvoyons volontiers à ce sujet aux motions 20.4260, 18.4276 et 18.4238