~bzg/politique-logiciels-libres-secteur-public

ref: HEAD politique-logiciels-libres-secteur-public/idees.md -rw-r--r-- 20.7 KiB
a61b91f4Bastien idees.md: Correction mineure de mise en forme 10 months ago
  1. Construire un positionnement et un discours clairs sur le rapport entre l'ouverture des codes sources publics et la souveraineté numérique.

  2. En s'inspirant du réseau des Administrateurs Ministériels de Données (AMD), construire un réseau interministériel de référents logiciels libres dans les ministères.

  3. Mettre en place un baromètre de l'open source pour l'administration.

  4. Aider les Société d'Accélération de Transfert de Technologies (SATT) à mieux comprendre les modèles économiques qui peuvent être proposés autour de logiciels libres.

  5. Mettre en place une politique industrielle venant en soutien aux entreprises du logiciel libre en France.

  6. Mettre en place la priorité à l'utilisation de logiciels libres dans le secteur public français, comme c'est le cas en Italie.

  7. Soutenir la montée en compétence des services juridiques et achat des administrations publiques pour qu'elles appréhendent mieux les enjeux du logiciel libre.

  8. Encourager le secteur de la l'enseignement supérieur et recherche à détecter et soutenir les futures « pépites » libres développées sur fonds publics (e.g. scikit-learn).

  9. Mettre en place un portail unique pour toutes les publications liées à l'open source dans la sphère publique.

  10. Tenir une liste à jour des organismes publics ayant une politique d'utilisation et de publication de logiciels libres.

  11. "Financer le déploiement, la maintenance et les évolutions d'instances de frama* et autres services libres au service de l'administration et des citoyens, notamment outils « transverses » (ex: matomo, sentry, captchas, nextcloud…) Et sensibiliser à l'utilisation de ces services." (via Twitter)

  12. "Monter une équipe degafamisation à la DINUM pour éradiquer les trackers dans les outils de l'état, former et sensibiliser les équipes internes aux alernatives libres" (via Twitter)

  13. Organiser des formations professionnelles autour des logiciels libres (ce tweet) et notamment "former les DSI des établissements publics sur les logiciels libres (qu'ils n'en aient pas peur)" (cf. ce tweet).

  14. "Valoriser les exemples réussis, mettre en réseau, partager les bonnes pratiques et faire des guides simples pour rassurer sur les aspects juridiques et les modes de gouvernance." (via Twitter)

  15. "Faire en sorte que chacune des applications developpées avec des fonds publics soit pensée comme un outil libre (documenté, réutilisable, reinstallable, partiellement générique) au lieu d’une simple ouverture du code." (via Twitter)

  16. "Une infra numérique libre et décentralisée ?" (via Twitter)

  17. "Montrer et démontrer les avantages et bénéfices du code source libre et de la gouvernance ouverte" (via Twitter)

  18. Acculturer les ESN à l'open source pour les inciter à répondre aux exigences de l'administration lorsqu'elle souhaite éviter la dépendance aux GAFAM (inspiré de ce tweet).

  19. Collecter et publier des témoignages d'utilisations et transitions réussies (inspiré de ce tweet).

  20. Publier de la documentation (notamment vidéo) autour des logiciels libres (inspiré de ce tweet).

  21. "Organiser des install parties [dans l'administration]" (via Twitter)

  22. "choisir des early-adopters avec qui on maintiendra une relation privilégiée pour continuer d'évangéliser en interne" (via Twitter)

  23. "Imposer que toutes les applications professionnelles soient au moins compatibles [avec] tout système d'exploitation (à défaut d'être libres, elles pourraient tourner avec GNU/Linux)" (via Twitter).

  24. "Créer une école d'état pour développeurs comme cela se fait dans d'autres métiers (agriculture, architecture) avec des études financées si contrat dans le public pendant une période." (via Twitter).

  25. Publier le détail des budgets des projets informatiques du secteur public - par exemple https://mon-entreprise.fr/budget (via Twitter).

  26. Encourager la prise de participation de l'État dans des entreprises clefs du logiciel libre pour assurer l'indépendance des SI du secteur public.

  27. Encourager la participation de l'État à des organisations internationales comme la Linux Foundation afin d'avoir des droits de vote sur des décisions potentiellement impactantes pour les SI du secteur public. Voir aussi la Core Infrastructure Initiative pour la consolidation des briques open source essentielles.

  28. Développer en open sources des applications clefs pour la souveraineté des SI du secteur public :

    • authentification à 2 facteurs
    • captcha (aller au-delà de tchatcha)
  29. Favoriser l'indépendance vis-à-vis des GAFAM en utilisant des solutions libres pour des secteurs clefs comme l'analytics (via une utilisation généralisée de Matomo, par ex., pour tout le secteur public.)

  30. Déployer un "store" à la F-Droid pour toutes les applications du secteur public, de façon à ne pas dépendre de Google Play ou de l'AppStore pour leur distribution. [Voir sur ce sujet la question de la distribution de StopCovid.]

  31. Avoir un outil unique (sous licence libre) pour faire des retours de bug sur tous les sites du secteur public. Retours publics ou privés selon les besoins.

  32. Permettre au citoyen de faire tourner n'importe quel code source partagé par une administration. Par exemple, si le ministère des finances partage le code source des impôts, il faudrait un bouton pour pouvoir déployer ce code source facilement et permettre au citoyen de le tester sur une instance à part.

  33. Généraliser l'utilisation et la publication de versions sur tous les applicatifs développés dans le secteur public, et que cette information soit disponible pour le citoyen. Le tout avec une description claire des différences entre les versions.

  34. Initier les composants cœur de l’Etat plateforme avec des licences avec obligation de réciprocité pour éviter toute enclosure future :

    • Prise de rendez-vous
    • Application de notification de l’usager
    • Outil de preuve de géolocalisation pour différents usages
  35. Publication du code source des API de l’Etat sur des systèmes critiques (voir api.gouv.fr où le code n’est pas disponible). Permettre une concurrence des API sur le speech2text par exemple et les services qui peuvent y être associés notamment dans les situations d’urgence.

  36. Publication des algorithmes cœur utilisés par l’Etat pour permettre de les améliorer : quel est l’algorithme de matching d’empreintes digitales ? de reconnaissance faciale ? de reconnaissance des véhicules ? de lecture automatique de plaques ? etc.

  37. Tous les systèmes devant interragir avec la société civile (associations) ou les collectivités territoriales, doivent être open source pour permettre une collaboration.

  38. Engager l'État dans la mise en place d'un système de partage des données sécurisé, distribué, avec des niveaux de partage selon les données.

  39. Flécher des fonds publics (par exemple du plan de relance) vers le développement de logiciels libres "d'intérêt public ou industriel". Via ces suggestions.

  40. [Quid du côté des collectivités territoriales?] Via ces suggestions.

  41. Créer un espace dédié au « code moche », dans l'ESR et/ou dans l'administration publique en général : un endroit où publieraient ceux qui souhaiteraient trouver des relecteurs sans être jugés sur la qualité du code qu'ils écrivent, avec une revue bienveillante par les pairs.

  42. Créer des services en ligne renforçant l'utilisation des formats recommandés par le RGI, notamment en aidant à la conversion de fichiers d'un format vers un autre. Un exemple d'un tel service serait une API permettant d'envoyer des fichiers en .docx pour recevoir en retour une version en .odt (voir cette suggestion.)

  43. « [Créer] trois nouveaux corps de fonctionnaires. Un corps de catégorie B (pour les techniciens informatique), un corps de catégorie A (pour les programmeurs) et un corps de catégorie A+ (pour le management). Ces corps appartiendraient à la fonction publique d'État et seraient rattachés à un niveau interministériel, à la DINUM par exemple. » (Voir la proposition.)

  44. Contribuer à la maintenance de projets libres utilisés dans le secteur public, de trois façons : (1) détacher des agents du secteur public à la maintenance d'un projet open source ; (2) employer le programmeur du logiciel libre ; (3) un modèle de subvention faisant secteur public et acteurs du logiciel libre pour financer des développeurs travaillant sur des projets libres utilisés dans le secteur public. (Voir la proposition.)

  45. Créer des passerelles entre la recherche publique appliquée (en informatique) et l'administration, par exemple en permettant à universités et instituts de recherche de détacher des chercheurs appliqués dans l'administration pour expérimenter une innovation. (Voir ce commentaire).

  46. Trouver les bonnes façons d'éviter que les bons personnels techniques soient promus en mauvais manager : soit en donnant plus de perspectives de promotion aux personnels techniques en tant que tels, soit renforçant les formations au management. Le modèle des entreprises techn des États-Unis peut inspirer. (Voir ce commentaire.)

  47. Financer des licornes du logiciel libre.

  48. Fournir des services numériques transverses à base de solutions open source et visant soit les agents publics (comme Tchap et Webconf), soit les métiers et leurs besoins techniques (comme un service de forge centralisée, un sentry, un CDN, un service d'envoi de mails et de textos, etc. (Proposition de J. Bouquillon.)

  49. Recommander d'ajouter dans les clauses de CCTP l'impératif de suivre les standards de bonnes pratiques de développement issus de l'open source, notamment en matière de versionnement, de sécurité. (Proposition de J. Bouquillon.)

  50. Démystifier l'ouverture de code source avec des ressources simples et non techniques, pour les décideurs. Car il y a encore beaucoup de crainte de perdre le contrôle de leur projet informatique.

  51. Partager des ressources juridiques simples sur les enjeux liées à l'ouverture des données et des codes sources.

  52. Fournir des ressources techniques et juridiques simples car la plupart des structures ne savent pas ce qu'elles doivent ou peuvent inclure dans leurs marchés publiques pour garantir l'ouverture des données et codes sources des solutions développées.

  53. Accompagner et favoriser la maintenance technique et communautaire des projets libres des administrations.

  54. Valoriser les projets réussis.

  55. Encourager la collaboration entre les structures et les territoires, plutôt que leur concurrence.

  56. Encourager et valoriser le fait de collaborer entre administrations, plus que d'être "la première administration à…", "la seule administration à…".

  57. Maintenir et renforcer des compétences techniques internes pour pouvoir mener des projets de moyen et long terme dans les administrations, ou au moins avec des personnes techniques capables de suivre et encadrer des prestataires.

  58. Réfléchir à de réels moyens pour que l'ouverture des données et des codes sources, ne soit pas un aspect optionnel, en bonus, la plupart du temps bénévole, des projets.

  59. Mettre en avant les contributions faites dans l'administration aux logiciels libres.

  60. Favoriser la mise en relation de clients publics d'une solution libre sans que cela nuise au modèle commercial d'un éditeur qui produit le code.

  61. Encourager les « clubs utilisateurs » auxquels adhèreraient des administrations pour peser sur la feuille de route d'un projet, ou bien une redevance avec des remontées des utilisateurs (publics) qui s'intègrent aux discussions sur les feuilles de route.

  62. Soutenir les événements et la communication dans l'écosystème.

  63. Arriver à mettre en contact les décideurs de terrain et ceux qui portent le sujet du libre politiquement à un niveau plus stratégique.

  64. Développer un discours sur le logiciel libre qui ne prête pas le flanc à l'accusation de « discours idéologique ». Décliner les enjeux du « libre » en de multiples valeurs.

  65. Faire savoir aux entreprises qu'elles peuvent dire à leur client du secteur public qu'ils peuvent s'appuyer sur la DINUM pour être accompagnés pour faire remonter des contributions libres.

  66. Mettre en place un outil de remontée d'idées (cf. celui-ci) pour que les collectivités expriment leurs besoins sur des logiciels libres, en attendant que d'autres puissent mutualiser - une façon aussi de garder trace des idées non retenus lors de cet appel de l'incubateur de l'ANCT.

  67. Permettre de filtrer les marchés publics selon qu'ils font référence ou non à des technologies libres.

  68. Permettre de filtrer les offres d'emploi du secteur public selon qu'ils font référence ou non à des technologies libres.

  69. Monter une mission logiciels libres s'inspirant des différents Open Source Program Office (voir définition provisoire). Cette mission pourrait s'appuyer sur un réseau interministériel de missions ou équivalents.

  70. S'inspirer de standards existants (https://digitalpublicgoods.net, https://publiccode.net) pour promouvoir certains logiciels libres de l'administrations, soit pour valoriser les réutilisations au sein de l'administration, soit pour les faire avancer comme communs.

  71. Monter un site permettant de récolter les besoins d'évolution de logiciels libres utilisés dans l'administration.

  72. Monter une fondation permettant aux acteurs publics de financer en commun des évolutions de logiciels libres.

  73. S'attaquer pour de vrai aux guides logiciels libres.

  74. Définir et mettre en place un baromètre évaluant la mise en oeuvre des objectifs d'une mission logiciels libres dans les ministères.

  75. Mettre en place une variante de woof pour publier, depuis une liste de discussion privée, un flux RSS d'événements liés au logiciel libre.

  76. Faire une agrégation de flux pour les « bonnes nouvelles » du libre dans l'administration.

  77. Avancer sur un arbre décisionnel pour accompagner les porteurs de projets dans la maturation vers les bonnes pratiques open source (aka "floss-status").

  78. Permettre d'afficher les dépôts d'une ou plusieurs organisations à partir d'un iframe de code.etalab.gouv.fr.

  79. sill.etalab.gouv.fr : se connecter et pouvoir faire une liste de logiciels utilisés et la publier dans une iframe.

  80. Proposer des icones Github/Lab pour les niveaux d'ouverture décrits dans https://guides.etalab.gouv.fr/logiciels/

  81. Comment intégrer les comptes personnels GitHub/Lab qui développent du libre sur fonds publics dans code.etalab.gouv.fr ?

  82. De la même façon qu'il existe des audits de sécurité (faits par des acteurs extérieurs), il pourrait y avoir, pour les projets libres de l'administration, des audits sur l'aspect « libre » et (si pertinent), contributif - en lien aussi avec l'idée de donner des repères avec floss-status.

  83. Organiser un « tchapathon » : Tchap est aujourd'hui très utilisé mais la DINUM elle-même continue d'utiliser Slack pour différents besoins. Nous pourrions organiser un hackathon interministériel pour échanger des idées ou développer des fonctionnalités autour de Tchap.

  84. Lister les packages (npm, R, maven, etc.) sur code.etalab.gouv.fr et indiquer dans les dépendances lesquelles sont des dépendances produites (et encore maintenues) par l'administration.

  85. Produire un guide orienté décideur pour les aider dans leurs décisions d'achat de logiciels libres. Peut-être un équivalent de "alternative to", possiblement intégré au SILL.

  86. Financer des briques open source utilisées dans l'administration, peut-être en priorisant les dépendances identifiées par le projet backyourstack comme nécessitant un financement.

  87. Mettre une instance Yunhost à disposition pour tester le déploiement de logiciels libres.

  88. Faire une frise chronologique collaborative mettant en évidence les avancées et les reculs du logiciel libre dans l'administration.

  89. Construire un outil de montée en compétence des décideurs sur le logiciel libre basé sur le moteur de pix.fr.

  90. Construire un dépôt de code source "exemple", pour souligner tout ce à quoi une administration doit faire attention en publiant des codes sources.

  91. Faire connaître la OW2 Good Governance Initiative auprès des administrations pour qu'elles s'approprient la méthodologie et s'appuient dessus pour structurer des missions logiciels libres.

  92. Voir s'il est possible pour les administrations de prévoir des budgets pour soutenir des projets libres via opencollective.com.

  93. Mettre en place un équivalent du Prototype Fund où administration et acteur militant travaillent ensemble pour financer de nouveaux logiciels libres d'intérêt général.

  94. Rapprocher des projets libres de l'administration de contribulle.org

  95. Permettre de classer les prestataires listés dans le Comptoir du libre en fonction de leurs contributions à des logiciels libres.

  96. Permettre aux enseignants-chercheurs de valoriser leurs contributions aux logiciels libres dans leurs carrières.

  97. Sensibiliser les acheteurs au besoin de contribuer aux briques logiciels libres dont leurs achats dépendent indirectement.

  98. Valoriser les contributions des agents publics à des logiciels libres extérieurs à l'administration.

  99. S'inspirer de la mission de TOSIT pour détecter des briques libres qui ne sont portées que par un seul éditeur et pour lesquels l'administration doit se tenir prête à maintenir une version libre, si l'éditeur venait à changer la licence du logiciel.

  100. Imaginer un canal de subvention pour organiser la maintenance de logiciels libres critiques pour les administrations. (Voir cette proposition)