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

f6917ddd6c9db178d9ec6d82fd9f23e9e4ac6806 — Bastien 1 year, 3 months ago 6244b00
Export des fichiers .org en .md pour les rendre directement lisibles
3 files changed, 462 insertions(+), 27 deletions(-)

A README.md
A idees.md
M idees.org
A README.md => README.md +17 -0
@@ 0,0 1,17 @@


# Espace collectif d'idées

Ce dépôt réunit des idées que je glâne au fil de mes discussions avec
différents acteurs sur les différentes façons de renforcer le logiciel
libre dans et via le secteur public.

Vous pouvez [lire les idées ici](idees.md).


# Contributions

Vos contributions sont les bienvenues !

Le contenu de ce dépôt est publié sous licence [Creative Commons CC0 1.0](https://creativecommons.org/publicdomain/zero/1.0/).


A idees.md => idees.md +412 -0
@@ 0,0 1,412 @@
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](https://www.satt.fr/societe-acceleration-transfert-technologies/)) à 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](https://scikit-learn.org)).

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](https://twitter.com/revolunet/status/1284129025074626560))

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](https://twitter.com/revolunet/status/1284129545357086722))

13. Organiser des formations professionnelles autour des logiciels
    libres ([ce tweet](https://twitter.com/sebtouze/status/1284383159036059649)) et notamment "former les DSI des établissements
    publics sur les logiciels libres (qu'ils n'en aient pas peur)"
    (cf. [ce tweet](https://twitter.com/thom_karum/status/1284189815483899911)).

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](https://twitter.com/cmonchicourt/status/1284833611502571522))

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](https://twitter.com/jparis_py/status/1284606997573390339))

16. "Une infra numérique libre et décentralisée ?" ([via Twitter](https://twitter.com/jparis_py/status/1284606997573390339))

17. "Montrer et démontrer les avantages et bénéfices du code source
    libre et de la gouvernance ouverte" ([via Twitter](https://twitter.com/nyconyco/status/1284115111263850501))

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](https://twitter.com/pgayat/status/1284437480234770432)).

19. Collecter et publier des témoignages d'utilisations et transitions
    réussies (inspiré de [ce tweet](https://twitter.com/drobaux/status/1284451842768896004)).

20. Publier de la documentation (notamment vidéo) autour des logiciels
    libres (inspiré de [ce tweet](https://twitter.com/drobaux/status/1284451842768896004)).

21. "Organiser des install parties [dans l'administration]" (via
    [Twitter](https://twitter.com/looking4poetry/status/1284118404950110208))

22. "choisir des early-adopters avec qui on maintiendra une relation
    privilégiée pour continuer d'évangéliser en interne" (via [Twitter](https://twitter.com/looking4poetry/status/1284118404950110208))

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](https://twitter.com/thom_karum/status/1284190110783864833)).

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](https://twitter.com/paulsouche/status/1286208386443485190)).

25. Publier le détail des budgets des projets informatiques du secteur
    public - par exemple <https://mon-entreprise.fr/budget> (via
    [Twitter](https://twitter.com/maeool/status/1301092442607943680)).

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](https://www.linuxfoundation.org/) 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](https://www.coreinfrastructure.org/)
    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](https://github.com/etalab/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](https://gitlab.inria.fr/stopcovid19/stopcovid-android/-/issues/20).]

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](https://github.com/bzg/politique-logiciels-libres-secteur-public/issues/2).

40. [Quid du côté des collectivités territoriales?]  Via [ces
    suggestions](https://github.com/bzg/politique-logiciels-libres-secteur-public/issues/2).

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](https://github.com/bzg/politique-logiciels-libres-secteur-public/issues/3).)

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](https://github.com/bzg/politique-logiciels-libres-secteur-public/issues/1).)

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](https://github.com/bzg/politique-logiciels-libres-secteur-public/issues/1).)

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](https://github.com/bzg/politique-logiciels-libres-secteur-public/issues/1#issuecomment-694267053)).

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](https://github.com/bzg/politique-logiciels-libres-secteur-public/issues/1#issuecomment-694390022).)

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](https://github.com/revolunet).)

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](https://github.com/revolunet).)

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
    à&#x2026;", "la seule administration à&#x2026;".

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](https://ideas.digitalocean.com)) 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](https://mon.incubateur.anct.gouv.fr/processes/transformation-numerique).

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](https://github.com/todogroup/ospodefinition.org) 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](https://github.com/bzg/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](https://code.etalab.gouv.fr)
    et indiquer dans les [dépendances](https://code.etalab.gouv.fr/fr/deps) 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](https://backyourstack.com/) 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](https://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](https://contribulle.org/)

95. Permettre de classer les prestataires listés dans le [Comptoir du
    libre](https://comptoir-du-libre.org/fr/) 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](https://tosit.fr/) 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](https://github.com/bzg/politique-logiciels-libres-secteur-public/issues/1))


M idees.org => idees.org +33 -27
@@ 2,21 2,22 @@
   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.
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.
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 ([[https://www.satt.fr/societe-acceleration-transfert-technologies/][SATT]])
   à mieux comprendre les modèles économiques qui peuvent être proposés
   autour de logiciels libres.
4. Aider les Société d'Accélération de Transfert de Technologies
   ([[https://www.satt.fr/societe-acceleration-transfert-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 logiciels libres en France.
   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.
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


@@ 26,8 27,8 @@
   détecter et soutenir les futures « pépites » libres développées sur
   fonds publics (e.g. [[https://scikit-learn.org][scikit-learn]]).

9. Mettre en place un portail unique pour toutes les publications liées
   à l'open source dans la sphère publique.
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.


@@ 53,8 54,8 @@

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." ([[https://twitter.com/jparis_py/status/1284606997573390339][via Twitter]])
    réutilisable, reinstallable, partiellement générique) au lieu
    d’une simple ouverture du code." ([[https://twitter.com/jparis_py/status/1284606997573390339][via Twitter]])

16. "Une infra numérique libre et décentralisée ?" ([[https://twitter.com/jparis_py/status/1284606997573390339][via Twitter]])



@@ 78,8 79,9 @@
    privilégiée pour continuer d'évangéliser en interne" (via [[https://twitter.com/looking4poetry/status/1284118404950110208][Twitter]])

23. "Imposer que toutes les applications professionnelles soient au
    moins compatibles tout système d'exploitation (à défaut d'être
    libre, elles pourraient tourner avec GNU/Linux)" (via [[https://twitter.com/thom_karum/status/1284190110783864833][Twitter]]).
    moins compatibles [avec] tout système d'exploitation (à défaut
    d'être libres, elles pourraient tourner avec GNU/Linux)" (via
    [[https://twitter.com/thom_karum/status/1284190110783864833][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


@@ 87,7 89,8 @@
    [[https://twitter.com/paulsouche/status/1286208386443485190][Twitter]]).

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

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


@@ 131,13 134,14 @@
    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 :
    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 ou le code n’est pas disponible).
    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.


@@ 150,7 154,7 @@

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.
    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


@@ 160,7 164,8 @@
    développement de logiciels libres "d'intérêt public ou
    industriel".  Via [[https://github.com/bzg/politique-logiciels-libres-secteur-public/issues/2][ces suggestions]].

40. [Quid du côté des collectivités territoriales?]  Via [[https://github.com/bzg/politique-logiciels-libres-secteur-public/issues/2][ces suggestions]].
40. [Quid du côté des collectivités territoriales?]  Via [[https://github.com/bzg/politique-logiciels-libres-secteur-public/issues/2][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


@@ 198,8 203,8 @@
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 [[https://github.com/bzg/politique-logiciels-libres-secteur-public/issues/1#issuecomment-694390022][ce
    tels, soit renforçant les formations au management.  Le modèle des
    entreprises techn des États-Unis peut inspirer. (Voir [[https://github.com/bzg/politique-logiciels-libres-secteur-public/issues/1#issuecomment-694390022][ce
    commentaire]].)

47. Financer des licornes du logiciel libre.


@@ 311,8 316,8 @@
    des objectifs d'une mission logiciels libres dans les ministères.

75. Mettre en place une variante de [[https://github.com/bzg/woof][woof]] pour publier, depuis une
    liste de discussion privée, un flux  RSS à partir d'événements qui
    sont annoncés sur la liste.
    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.


@@ 325,7 330,7 @@
    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 un iframe.
    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/


@@ 361,7 366,8 @@
    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.
    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.