Pistes de réflexion concernant l’utilisation des logiciels libres Document de travail Québec, janvier 2011

Ordre du jour Positionnement du Regroupement Éléments de réflexion mise en évidence Méthodes d’acquisition Enjeux identifiés Décisions d’acquisition de logiciels Conclusion et plan d’action

Position sommaire du RPGTI Le RPGTI n’est pas contre l’utilisation de logiciels libres dans le secteur public québécois Les processus de décision doivent assurer clarté, équité et transparence dans un contexte concurrentiel servir les intérêts des clients, tout en respectant la réglementation en place ne pas imposer de contraintes d’évolution Le RPGTI s’offre pour participer à des groupes de travail pour analyser et adapter, si requis, le cadre de gestion pour traiter les décisions d'acquistion de logiciels, commerciaux ou libres, ainsi que tous les autres aspects du cadre de gestion actuel Plusieurs sociétés-membres disposent d’expertise dans le domaine et ont des réalisations à leur actif

Plusieurs modes d’acquisition Il existe plusieurs façon d’introduire des logiciels dans une organisation Appels d’offres de logiciels À l’occasion d’une acquisition de matériel Licences forcées par l’appel d’offres en accompagnement au matériel faisant l’objet de l’appel d’offres Licences incluses par le manufacturier, faisant partie du produit proposé À l’occasion d’un contrat d’intégration Licences faisant partie de la solution globale retenue À l’insu de tout processus, parce que « gratuit » ou parce que le client est éligible à une nouvelle version, sans frais additionnels Le cadre de gestion retenu devrait encadrer l’ensemble des possibilités

Principaux enjeux identifiés Coût d’acquisition vs TCO (Total cost of ownership) Évaluation de la valeur du TCO (transition, soutien, etc…) pour les logiciels Calibration des composantes du TCO lors d’une décision d’acquisition Détermination de la proportion acceptable par rapport au prix global Évaluation et poids des éléments de risque particuliers Soutien, pérennité, évolutivité, etc. Réglementation concernant les acquisitions Comment encadrer les situations lorsque le coût apparent d'acquisition apparaît "nul" - versus le seuil de 25K$ Notion de produit unique Seuil acceptable concernant des critères de recherche sérieuse et approfondie Encadrement de la notion d’intérêt public

Principaux enjeux identifiés Processus d’acquisition Il faut maintenir un processus d’acquisition simple et léger, compte tenu des volumes de transactions Minimiser le nombre d’études préalables requises (recherches sérieuses, intérêt public, avis d’intention, estimation de TCO et autres critères) Traitement de la propriété intellectuelle Cession vs licence: les clauses actuelles sont problématiques et devront être adaptées aux modalités de licences généralement retrouvées dans le monde des logiciels libres Traitement des améliorations apportées à l’actif À qui appartiennent les améliorations? Protection contre les recours de tiers relatif à la PI Qui assure la protection du client contre les recours de tiers?

Principaux enjeux identifiés Soutien du logiciel Soutien provenant d’une communauté vs une société commerciale Qui est responsable, et selon quelles modalités? Responsabilité partagée du fournisseur, du revendeur ou de l’intégrateur; comment départager? Garanties de niveaux de service Comment s’articule le processus d’escalade en cas de problème urgent? Application consistante des pénalités prévues en cas de manquement aux niveaux de service exigés Règles relatives à l’évolution Niveau d’assurance face à la pérennité Traitement des nouvelles versions Soutien des versions précédentese

Principaux enjeux identifiés Logiciel acheté à l’occasion d’acquisition de matériel Lorsque le client achète des postes de travail avec un portefeuille d’applications pré-chargées Responsabilité face au soutien du logiciel acquis Que faire lorsqu’il n’existe pas d’organisation formelle supportant le logiciel exigé? Obligation d’avoir une machine « bootable » aux frontières Traitement différent des manufacturiers vs assembleurs qui eux ne sont pas soumis à cette règle Responsabilité d’interopérabilité avec l’environnement client Lors d’acquisitions logicielles, plusieurs étapes préalables (analyse d’opportunité, architecture, etc…) ont précédé l’appel d’offres Essais intégrés effectués par les manufacturiers de concert avec les grands éditeurs de logiciels Comment traiter / supporter une nouvelle combinaison d’exigences unique à un client et n’ayant pas fait l’objet de tests préalables?

Principaux enjeux identifiés Logiciel acheté à l’occasion...matériel (suite) Traitement des règles applicables au logiciel Coûts de transition peuvent être supérieurs à la valeur de la transaction Règle relative à l’amortissement ( prix du « produit » > 1 000$) Selon l’évaluation des coûts des licences, il pourrait y avoir augmentation du nombre de produits logiciels demandés lors d’acquisition de postes de travail Règle limitant l’accessoire à un maximum de 30% du principal pour permettre l'amortissement du coût d'acquisition du produit plutôt qu’en passer le coût dans les dépenses d'opération comment gérer les licences à 0$?

Principaux enjeux identifiés Logiciels acquis via un contrat d’intégration Écarts fonctionnels comblés lors du développement de la solution Quel est l’impact sur l’alignement du logiciel final vs la communauté Soutien, évolutivité, propriété intellectuelle, etc. Comment et à quelles conditions sera fait le soutien du logiciel au terme du contrat d’intégration? En cas de conflit entre les termes contractuels et la licence de logiciel, avec qui négocie-t-on?

Décisions relatives aux logiciels Décisions à la pièce vs orientation ministérielle, sectorielle ou gouvernementale Est-ce que chaque décision de logiciel devrait être le simple résultat d’un appel d’offres concurrentiel? Systèmes d’exploitation, BD vs solution de niche Comment assurer une portabilité maximale des applications à l’intérieur du secteur public? Comment favoriser la portabilité et la réutilisation de l’expertise à l’intérieur du secteur public? Difficulté de préciser des exigences fonctionnelles Meilleures conditions obtenues en négociation de volume vs en concurrence restreinte?

Conclusion et plan d’action Le RPGTI est qualifié de façon unique pour contribuer à la réflexion gouvernementale sur les logiciels libres Assurer la satisfaction des besoins gouvernementaux aux meilleurs coûts totaux possibles Processus d’encadrement assurant une saine et réelle concurrence Connaissance intime des environnements TI et administratifs gouvernementaux Plan d’action ...