Section 2 : Enjeux et concepts clés pour la création d'un écosystème du logiciel libre #

Une organisation habilitante #

Les logiciels libres exigent que les intervenants de différents ministères, organismes gouvernementaux et unités opérationnelles acquièrent de nouvelles compétences et adaptent leur rôle quotidien de façon à appuyer efficacement les logiciels libres. Il s’agit notamment des personnes affectées aux services numériques, à l’informatique, à un certain nombre de fonctions de prestation de services directs (p. ex., la circulation et le stationnement), aux achats, à la budgétisation ou à la comptabilité, aux services juridiques et à d’autres fonctions au sein des organisations et entre elles.

Toutes ces personnes doivent être capables de poser les bonnes questions, de déterminer les bons résultats et d’avoir une connaissance de base des principes fondamentaux de la conception moderne de logiciels.¹

Compétences et expertise internes #

La dotation en personnel technique est l’un des principaux obstacles perçus en ce qui concerne l’adoption des logiciels libres. Étant donné que les logiciels libres nécessitent une participation active de l’utilisateur (par opposition aux logiciels propriétaires, dont le service et la mise à niveau sont assurés par le vendeur), nombreux sont ceux qui supposent qu’ils sont inaccessibles sans capacités de développement de logiciels.

À l’inverse, nombreux sont ceux qui pensent que l’obtention d’un logiciel propriétaire auprès d’un fournisseur signifie qu’ils n’ont pas besoin d’experts techniques au sein de leur effectif.Or, en l’absence d’expertise interne, les processus de passation de marchés, d’acquisition et de mise en œuvre de logiciels propriétaires peuvent avoir des conséquences néfastes. Sans une connaissance adéquate de la propriété et de la monétisation des données, un contrat portant sur un logiciel propriétaire peut finir par priver le secteur public de tout pouvoir à long terme (voir le module 3).

Les clients – le secteur public en particulier – comptent sur les fournisseurs de logiciels pour obtenir un soutien continu. Dans le cas des logiciels propriétaires, les clients n’ont pas de choix. Le code source étant caché, le fournisseur est la seule partie à y avoir accès. Dans le cas des logiciels libres, tout le monde peut contribuer, mais il n’y a pas de fournisseur unique. Les gouvernements doivent disposer de capacités internes, collaborer avec leurs pairs ou faire appel à un prestataire capable d’offrir du soutien.

Rôles du personnel afin d’appuyer les logiciels libres #

Il est possible d’entreprendre des projets de logiciels libres sans rôles officiels. Toutefois, cette approche peut ne pas être viable à long terme si les « champions » de tels logiciels au sein de votre organisation ne sont pas en mesure d’encourager les efforts en matière de logiciels libres en plus de leurs obligations professionnelles officielles.

Idéalement, vous pourrez faire appel aux compétences et à l’expertise de plusieurs intervenants différents lorsque vous vous lancerez dans une initiative de logiciel libre (voir le tableau 2.1). Ces rôles passent au premier plan ou à l’arrière-plan, selon la phase et, une fois de plus, il n’est pas nécessaire que tous ces rôles soient internes ou à temps plein.

Tableau 2.1 : Rôles associés à chaque phase d’une initiative de logiciel libre, participation par phase

* Indique un rôle qui peut exister en dehors de votre organisation (p. ex., au sein d’une administration semblable ou sous contrat avec un fournisseur).

Élimination du cloisonnement ministériel #

Un manque systémique de collaboration entre les ministères et les unités opérationnelles peut avoir une incidence sur l’adoption des logiciels libres et ce, pour plusieurs raisons :

• Les ministères peuvent avoir des objectifs divergents ou conflictuels, ce qui peut entraîner une désharmonisation des priorités et des frictions avant et pendant le processus d’acquisition et de développement des logiciels.

• Le cloisonnement fréquent entre les unités opérationnelles existantes (p. ex., le service juridique, l’informatique, la prestation de services, la budgétisation et l’approvisionnement) peut faire en sorte qu’il est difficile de déterminer qui est réellement responsable d’un processus. Cela est particulièrement vrai pour les processus nouveaux ou non conventionnels.

L’adoption de normes et de protocoles interministériels nécessite une gestion du changement de processus indépendante des services concernés.

De nombreuses grandes entreprises du secteur privé ont mis en place des bureaux de programme responsables des logiciels libres (OSPO), qui servent de centre d’échange pour tout ce qui concerne les logiciels libres au sein de l’organisation. Cela peut inclure notamment le travail en collaboration avec des fondations/organisations et des collectivités OSS, assurer la conformité légale, élaborer et mettre en œuvre des stratégies OSS, lancer de nouveaux projets, fournir des formations, fournir des conseils aux employés sur la façon dont ils pourraient s’engager dans des activités OSS et autres.²

Certains gouvernements et institutions du secteur public adoptent désormais la même approche. Ainsi, la Commission européenne a créé son bureau Open Source en octobre 2020. Une structure organisationnelle telle qu’un OSPO vise à amener les gouvernements non seulement à adopter des politiques générales, mais également à garantir leur application et leur maintien d’une manière plus horizontale et stratégique, tout en assurant leur mise en œuvre dans une pratique quotidienne.³

• Précédent
• Suivant