Les spécifications accessibles au public et le secteur public

Le 24 avril 1995

Les spécifications accessibles au public et le secteur public
Document de travail rédigé à l'intention de l'International Public Sector Information Technology Group (IPSIT)

M. Harrop
Secrétariat du Conseil du Trésor du Canada
Ottawa
Canada

Avant-propos

Le présent document a été rédigé à l'intention de l'International Public Sector Information Technology Group (IPSIT). Les membres du groupe font face à quantité de défis communs dans l'application de la technologie de l'information (TI) à l'administration publique. Ils se sont dotés sans exception de politiques régissant les acquisitions de TI fondées sur des normes et ils ont tous buté, plus ou moins, sur des problèmes comparables posés par l'application des politiques précitées face à l'évolution technologique rapide et aux forces inattendues du marché. La plupart des politiques du secteur public en matière de TI offrent une marge de manœuvre donnée en ce qui a trait à l'acquisition de produits et de services fondés sur des spécifications accessibles au public (SAP), mais le recours à ces dernières soulève de nombreuses questions et occasionne bien des conséquences. Or les questions et les conséquences ne sont pas limitées à l'utilisation des SAP dans le secteur public.

L'objet du présent document est de décrire, dans la perspective du secteur public, les grandes questions que soulève le recours aux SAP. Nous nous sommes inspirés, au cours de la rédaction, de certaines des nombreuses communications de qualité présentées à l'occasion de l'atelier sur les politiques de normalisation des technologies de l'information et des communications (TIC), tenu à Bruxelles, du 28 au 30 novembre 1994, de même que de l'expérience collective des membres de l'IPSIT.

Introduction

Le milieu en mutation

Il est notoire que la technologie évolue à grands pas, notamment sous l'influence de l'amélioration fulgurante du ratio prix-rendement des microprocesseurs et de l'accroissement sans borne de la largeur de bande des communications. Cet état de chose a pour effet la prolifération sur le marché d'appareils à puces à grande fonctionnalité et à prix relativement modeste – ordinateurs personnels, magnétoscopes, lecteurs de cédérom, téléphones cellulaires, modules de contrôle et de surveillance pour voitures, et ainsi de suite, autant de dispositifs qui, comme le sait le consommateur, deviennent rapidement vétustes lorsque la génération suivante de microprocesseurs est mise en marché. En clair, le contexte technologique en mutation rapide a modifié notre façon d'utiliser la technologie de l'information, mais elle a également débouché sur d'autres changements, moins évidents – changements aux stratégies marketing, à la domination des marchés, à la prestation de services, voire au degré de collaboration entre les fournisseurs. Dans certains cas, la cadence de l'évolution technologique a devancé de loin la capacité des organisations à s'y adapter afin d'en tirer parti pleinement.

L'organisation qui fait usage de TI doit se poser la question essentielle de savoir si ses politiques actuelles sont appropriées. Comme il est mentionné dans le premier document de référence, le contexte du début des années 1980, moment où nombre des politiques des normes OSI ont été élaborées, était marqué par la primauté d'IBM sur le marché et les spécifications brevetées. Dans une large mesure, le traitement des données reposait sur des gros ordinateurs centralisés dotés de structures de réseaux hiérarchisés. Les principaux protocoles de réseaux étaient les protocoles brevetés qui accompagnaient normalement le gros ordinateur, et ils provenaient d'IBM dans la plupart des cas. D'autres fabricants proposaient leurs architectures brevetées, mais l'acheteur courait chaque fois le risque de devoir se limiter à un fournisseur unique, comme les produits et les architectures des principaux fournisseurs étaient pour la plupart incompatibles. L'interconnexion uniforme et à grande échelle était à écarter, même, dans certains cas, celle de produits provenant du même fournisseur.

En 1995, nous avons déjà fait le passage à un environnement technologique reposant sur les microprocesseurs, les ordinateurs personnels, les architectures de traitement parallèle, une grande largeur de bande et les communications numériques, ce dans un contexte d'exploitation où l'architecture client-serveur devient rapidement la norme. IBM n'est plus le fournisseur dominant et la prépondérance d'un fournisseur de matériel inquiète moins que la domination d'un fournisseur de logiciels. Les besoins des utilisateurs ont évolué au rythme de la technologie, et ils comprennent couramment la nécessité de transmettre d'importants volumes de données tant dans des réseaux locaux que des grands réseaux; une grande connectivité, particulièrement aux fins du courrier électronique; la portabilité des applications et des données; la sécurité des données stockées et en cours de transmission. Par-dessus tout, la nécessité d'interconnexions larges et homogènes s'impose. Le document de référence 2 déclare : « [...] l'interconnexion est foncièrement nécessaire pour que se matérialise le concept de l'inforoute par le recours à la technologie actuelle, qui permet la transmission non seulement de textes, mais aussi de la voix, de l'image et de la vidéo. »

Deux facteurs ont motivé le remaniement des structures d'application des TI dans les secteurs public et privé. Il s'agit d'abord de la réponse donnée à l'évolution de la technologie même. Deuxièmement, facteurs éventuellement plus déterminants pour la plupart des organisations, citons la réaction à la récession et le mouvement général envers la compression des coûts des administrations publiques, cependant que les niveaux de service étaient maintenus, voire augmentés. Cette situation a fait que, dans bien des cas, des fonctions ont été automatisées qui, déjà, étaient exercées par des humains. D'autres tendances ont suivi, dans la foulée surtout des initiatives de compression des coûts. Nombre d'organisations ont consolidé leurs TI (ou sont en voie de le faire). Plusieurs administrations publiques s'affairent à se donner une « approche pangouvernemenale » des TI ou une approche « à guichet unique ». Ces approches entraînent un plus grand degré de partage de l'information entre les services et un recours beaucoup plus poussé à des structures de données, à des interfaces et à des formats communs. Dans certains cas, par souci d'économie, l'organisation a confié à contrat à un fournisseur la totalité de sa fonction de TI et, plutôt que d'acheter du matériel et des logiciels, s'est simplement procuré des services par l'adjudication de marchés. Fait à noter, comme l'ont fait des membres de l'IPSIT, certains des objectifs de compression des coûts entrent fréquemment en conflit avec la notion de renouvellement du gouvernement. À titre d'exemple, il est beaucoup plus difficile de réaliser des objectifs comme ceux du « guichet unique » et de la coordination centrale des activités de TI là où les pouvoirs sont de plus en plus délégués aux services particuliers et où la fonction entière de TI d'un service est l'objet d'un marché.

Au chapitre de l'offre, nous avons observé une hausse appréciable de la collaboration entre les fournisseurs. Nombre de ces derniers ont contribué de façon importante à l'activité des comités officiels de normalisation et ont collaboré étroitement aux travaux effectués aux ateliers régionaux sur les normes OSI et les systèmes ouverts où il est décidé du mode d'application des normes officielles. De plus, divers consortiums, tels X/Open et le Forum ATM, ont à toutes fins pratiques mis en place un mécanisme de substitution en vue de l'élaboration de certaines normes propres à l'industrie.

Nous avons observé des changements, dans le cadre du processus des normes officielles, visant à faciliter l'application des normes, à accélérer le processus de production et, plus récemment, à concevoir un processus rapide d'agrément des spécifications élaborées par d'autres groupes tels les consortiums du secteur et l'Internet Society.

À n'en point douter, les faits qui ont marqué les 10 ou 15 dernières années ont profondément changé notre approche des TI. De plus, tout porte à croire que l'évolution se poursuivra à grande cadence dans un avenir prévisible. Il est donc indiqué de revoir périodiquement les politiques de TI afin de décider des changements, s'il en est, à opérer en vue de tenir compte de l'évolution de l'environnement d'exploitation.

Depuis 10 ans, il est largement supposé que les normes de systèmes ouverts constituent l'unique moyen de parvenir au degré de connectivité exigé. Cette hypothèse est désormais mise en doute dans de nombreux milieux.

Politiques des TI et contraintes du secteur public

De façon générale, les politiques de TI de l'État entrent dans deux catégories distinctes : celles qui portent sur l'acquisition et l'utilisation des produits et des services de TI; celles qui traitent du développement et du commerce des produits et des services de TI. Bien qu'il soit difficile de séparer complètement les deux catégories, notons qu'une politique dont l'objet est de réaliser les objectifs de l'une d'entre elles ne répondra pas nécessairement aux exigences de l'autre. Le présent document ne porte que sur les questions liées à l'utilisation des TI dans la poursuite d'objectifs opérationnels précis, non sur le commerce ou l'expansion industrielle régionale.

Si, dans bien des cas, les normes du secteur public et les programmes de normalisation de l'État en matière de TI sont antérieurs aux applications OSI et aux systèmes ouverts, c'est au moment de traiter des politiques portant sur les applications OSI que le secteur privé s'est donné un rôle proactif vis-à-vis de la normalisation des TI. L'élaboration de normes OSI a été amorcée en 1978, et nombre d'intéressés apparentaient d'abord les applications OSI à un moyen de faire contrepoids à l'architecture brevetée Systems Network Architecture (SNA) d'IBM en établissant des « règles du jeu équitables » et de permettre aux autres fournisseurs de fabriquer des produits réseau répondant à des normes communes.

Au contraire de la plupart des entreprises privées, les organismes publics ont longtemps été tenus au respect d'un système ouvert de soumissions. Cette obligation augmente grandement le risque de mettre en place un environnement hétérogène. De plus, la technologie en évolution et les besoins changeants, notamment la demande accrue d'activités axées sur les réseaux, qui ont marqué les années 1970, ont débouché sur la tendance incontournable à constituer des environnements hétérogènes dans les secteurs public et privé. Face aux architectures brevetées qui ont caractérisé le début des années 1980, les organismes ont constaté de plus en plus que leurs options en matière d'acquisition étaient limitées et que, très souvent, ils devaient choisir entre une relation de durée indéterminée avec un fournisseur unique et l'engagement de sommes énormes en vue de transférer les systèmes de production en place au matériel d'un fournisseur autre.

Dans la perspective de l'utilisateur et de l'acheteur de TI du secteur public, l'obligation de pratiquer une politique d'acquisition non discriminatoire (assortie du risque de mettre en place un environnement hétérogène) a été le principal facteur qui a motivé le secteur public à avaliser la norme OSI et la norme des systèmes ouverts à titre d'orientation stratégique, bien que, en Europe du moins, le fait que les politiques de TI étaient « une arme à utiliser dans la guerre économique » (c'est-à-dire un moyen de contrer la domination du marché des TI par les États-Unis) ait également beaucoup joué.

La plupart des politiques gouvernementales de TI accréditent les normes OSI et encouragent l'acquisition de produits et de services qui y sont conformes. Leur application est tantôt obligatoire, tantôt facultative. Les obligations découlant de traités (comme ceux du GATT et de son organisme successeur, l'OMC, le Traité de Maastricht et l'ALÉNA) et les règlements supranationaux (comme la décision 87/95/CEE) imposent des obligations supplémentaires à certaines administrations publiques. Cela dit, peu importe les exigences des politiques en vigueur, les administrations ont très souvent été tenues d'adopter une approche pragmatique fondée sur la grande disponibilité d'un produit, son prix raisonnable et l'existence de bons services de soutien fournis par le personnel compétent du fournisseur. Si des produits conformes aux normes internationales satisfont à ces exigences, le choix portera sur eux. Dans le cas contraire, des produits conformes à des normes de fait et non brevetés sont à préférer à des solutions brevetées.

Les normes, les utilisateurs et le marché

Au moment de concevoir des politiques en matière de normes OSI et de normes des TI, les concepteurs ont peu songé à la possibilité que la technologie devance les normes ou que les solutions de rechange sur le marché supplantent les produits. À ce moment, il a été supposé que des normes seraient élaborées et intégrées rapidement aux produits, que les produits offriraient une fonctionnalité complète et un bon rapport coûts-avantages, et que les gens les achèteraient. En rétrospective, il semble que ces hypothèses aient été par trop optimistes. Même les utilisateurs qui souscrivaient le plus fortement aux politiques et qui désiraient acheter des produits normalisés ont découvert que, dans bien des cas, ils n'avaient pas accès en temps opportun à des produits fonctionnels et économiquement efficaces.

Cette situation s'explique de plusieurs façons :

Les normes de droit sont d'autant plus compliquées que certaines politiques gouvernementales en matière d'acquisition exigent que les produits soient soumis à des essais formels. Comme l'a mentionné Isabel Valet [6], cette exigence complique grandement le processus de mise en œuvre et augmente de façon appréciable le coût des produits normalisés, à telle enseigne qu'il est parfois trois ou quatre fois celui d'un produit breveté ou conforme à des spécifications accessibles au public (SAP).

Cette situation n'annonce pas l'échec de l'ensemble soit des normes soit des politiques en matière de TI. Nombre de normes ont donné de bons résultats, notamment aux paliers inférieurs du modèle OSI, bien que, comme le fait savoir Ray O'Connor [1], il soit normal que certaines réussissent tandis que d'autres échouent. Il en est ainsi également des politiques et des produits. Par contre, on ne s'étonnera pas du scénario que décrit Ruth Kerry [2], dans lequel les acheteurs suivent les tendances et achètent des produits et des services (peu en importe la source) qui répondent à leurs besoins opérationnels, compte tenu de la pénurie de produits disponibles qui soient fonctionnels et qui offrent un bon rapport coût-efficacité.

Les besoins actuels des utilisateurs appellent des produits qui offrent une connectivité ouverte, homogène et à grande échelle. Voici 10 ou 15 ans, les normes étaient considérées comme l'unique moyen de parvenir aux objectifs précités, et les politiques reflètent pareille hypothèse. Les normes demeurent un moyen éventuellement utile à prendre pour parvenir à ces objectifs, et elles sont parfois essentielles, mais comme le dit Ray O'Connor [1] :

« Il est désormais faux que l'interconnexion de machines provenant de fournisseurs différents nécessite des normes officielles, et, de fait, elles ne sont nécessaires que de façon restreinte à l'appui de l'interconnexion de réseaux. Les normes ne constituent qu'une solution parmi d'autres, et chacune offre des avantages et des inconvénients, tant techniques qu'économiques. »

L'acheteur envisage très souvent l'achat de produits conformes à des spécifications accessibles au public (parfois qualifiées de « normes de fait ») là où il n'existe pas de produits normalisés ou, s'il en est, ils sont jugés inacceptables en raison de leur fonctionnalité non appropriée, de leur coût élevé, ou même simplement à cause des pressions du marché. Dans bien des cas, on estime que les SAP constituent une solution de rechange aux normes de droit, et elles respectent les objectifs prisés de l'ouverture et de la pluralité sur le marché.

Les normes de fait et les SAP

Si la norme de droit est relativement bien définie (il s'agit de spécifications élaborées par un organisme international ou national reconnu de normalisation ou un organisme responsable de l'application d'un traité), la norme de fait et les SAP ne répondent à aucune définition précise. Les normes de fait sont largement appliquées et n'ont pas été adoptées à titre de normes officielles. Toutefois, rien n'indique qu'une norme de fait répond à une formulation unique ou que les spécifications correspondantes sont disponibles publiquement ou du domaine public. Ainsi, des produits brevetés de même que des spécifications de nature relativement générale (comme celles qui servent à la fabrication de clones de l'OP IBM ou du système d'exploitation DOS de Microsoft) sont qualifiés de « normes de fait ». L'absence de spécifications publiées donne lieu à des mises en œuvre parfois sensiblement différentes.

En général, les SAP sont définies par des caractéristiques générales, et il ne fait aucun doute qu'elles sont disponibles publiquement, mais il est possible qu'elles ne soient pas réellement du domaine public : elles appartiennent parfois à un particulier, à une entreprise ou à un organisme, et cette situation soulève de graves questions en matière de droits de propriété intellectuelle. Comme leur nom le laisse entendre, les SAP sont largement utilisées, mais ce n'est pas invariablement le cas. Il est arrivé que des entreprises ou des organismes aient rendu publiques des spécifications et aient constaté qu'elles suscitaient peu de demande. Comme le constate dans son document de référence le groupe des coprésidents des CEN/CENELEC/ETSI [8], les SAP sont parfois des spécifications ébauchées par un groupe industriel ou professionnel (par exemple l'ECMA, l'IEEE, l'Internet Society, ou les ateliers des responsables de la mise en œuvre des normes OSI/OSE); des spécifications de consortiums (à l'instar de celles qu'ont élaborées l'ATM Forum, le Network Management Forum et X/Open); ou des spécifications qui ont été acceptées largement sur le marché (tels Postscript d'Adobe et Windows de Microsoft).

Ray O'Connor [1] offre les exemples suivants de normes de fait :

Dans certains cas, des restrictions peuvent s'appliquer à l'usage d'une norme de fait ou de SAP en raison de l'appartenance des droits de propriété intellectuelle ou pour d'autres motifs. Le milieu de la sécurité offre des exemples intéressants de situations que peuvent susciter les SAP et de restrictions possibles à leur utilisation. Ainsi, la Data Encryption Standard (DES), adoptée par l'US National Bureau of Standards (NBS) en 1977 à titre de norme fédérale de traitement de l'information et par l'ANSI en 1981 à titre de norme nationale américaine, a été conçue à l'origine par IBM et soumise au NBS. Ainsi, bien qu'elle ait vu le jour sous forme de spécifications de source privée, la DES est une norme américaine officielle et du domaine public. En revanche, les spécifications RSA de chiffrement à clé publique sont diffusées largement mais appartiennent au secteur privé. Dans bien des cas, l'utilisation de ces spécifications nécessite le versement de redevances au propriétaire de l'algorithme RSA. Bien que tant la DES que le RSA soient utilisés largement, les produits fondés sur l'un et l'autre sont soumis à des contrôles qu'appliquent nombre de pays à l'exportation de dispositifs de chiffrement. PGP (Pretty Good Privacy) est un algorithme de chiffrement récent qui est largement utilisé en vue du cryptage de messages de courrier électronique, notamment les communications Internet. Le logiciel et la documentation du PGP sont protégés par le droit d'auteur, mais le code source et la documentation même peuvent être obtenus facilement et gratuitement dans Internet. En outre, des versions sous licence peuvent être achetées en vue de leur utilisation commerciale au Canada et aux États-Unis. Bien que les restrictions à l'exportation de matériel de chiffrement semblent s'appliquer au PGP, le logiciel est utilisé librement partout au monde.

Il est à supposer que les organismes publics n'accréditeront à l'avenir soit des normes de fait ou des SAP que s'ils disposent de critères à appliquer pour définir des spécifications acceptables. Le fait d'autoriser simplement l'acquisition de produits et de services dont il est dit qu'ils sont conformes à une norme de fait ou à des SAP équivaudrait pratiquement à autoriser indifféremment tout achat et nous rapprocherait de la situation qui existait avant l'élaboration de politiques d'acquisition de TI fondées sur des normes.

Les SAP et le processus officiel de normalisation

Les organismes de normalisation ont pris plusieurs mesures en vue de reconnaître des spécifications ayant vu le jour par des moyens autres que le processus officiel de normalisation. Leur première intervention importante remonte à quelques années, au moment de l'établissement du Profil normalisé international (PNI), lequel représentait une nouvelle catégorie de documents de normalisation. Le PNI spécifie la façon dont les normes actuelles (et les options qu'elles offrent) seront appliquées en vue d'exécuter une tâche précise. Il n'est pas élaboré par l'ISO, mais plutôt par des groupes extérieurs (comme les ateliers régionaux et les consortiums industriels), et il est harmonisé à l'échelle internationale avant d'être soumis à l'approbation accélérée de l'ISO. La mise aux voix par l'ISO dans ce cas n'est pas de nature technique, mais concerne plutôt le « processus », notamment en confirmant que celui-ci a été rigoureusement respecté. Cela dit, le processus du PNI n'autorise pas la prise en compte ou la mention de spécifications hors norme, telles les normes de fait et les SAP.

Le comité technique conjoint 1 de l'ISO avalisait dernièrement un processus qui prévoit la marche à suivre pour faire reconnaître à titre de norme officielle de l'ISO des spécifications de source extérieure. Les particularités de la démarche sont énoncées dans le document intitulé The Transposition of Publicly Available Specifications into International Standards - A Management Guide [4]. Le processus que décrit le guide autorise tout organisme national ou organisation de liaison de type A à soumettre à l'ISO des spécifications de toute source. Grâce au processus, des SAP peuvent être déclarées « normes internationales » en six mois. L'annexe B du document de référence 4 énonce en détail les critères à respecter pour soumettre des SAP à l'ISO. Si les critères sont quelque peu nombreux, ils soulèvent néanmoins des questions que doit se poser l'organisation qui envisage d'applique des SAP. Les critères visent, entre autres, les caractéristiques de l'auteur des SAP ou de la partie qui en demande l'agrément; les renseignements sur les SAP mêmes, tels les dispositions d'entretien et les projets; les renseignements sur les droits de propriété intellectuelle, soit brevets, marques de commerce, droits d'auteur, et ainsi de suite; le processus de développement; la qualité et la stabilité de la documentation; de même que la concordance avec d'autres spécifications. L'annexe en question pourrait très bien servir d'aide-mémoire à quiconque envisage de demander l'accréditation de SAP.

L'ISO a donc fait le nécessaire pour que les SAP soient reconnues officiellement et, dans le cadre de la démarche fixée à cette fin, elle s'est assurée qu'elles sont soumises à un examen d'envergure internationale fondée sur des critères prédéfinis. Reste à déterminer dans quelle mesure les auteurs de SAP se prévaudront du processus pour faire reconnaître leurs spécifications de façon officielle, à l'échelle internationale. Il n'existe, pour l'heure, aucune solution au problème posé par la mention des SAP dans les normes, quoique l'ISO se penche sur la situation.

L'avenir des politiques de TI du secteur public

Tout examen qualitatif des effets de politiques prescrivant que les acquisitions soient conformes aux normes OSI semble révéler peu de différences entre les résultats de politiques d'application obligatoire et ceux des politiques dont le respect est facultatif. En dépit d'un petit nombre d'exceptions remarquables, notamment le cas du gouvernement de la Rhénanie du Nord-Westphalie [5], la plupart des administrations n'ont pas réussi entièrement à mettre en œuvre leurs politiques en matière de normes de TI. Nul ne peut se réclamer d'une politique entièrement réussie, mais aucune politique n'a entièrement échoué. Dans chaque cas, la politique des normes OSI a donné certains bons résultats et entraîné quelques difficultés. Le problème auquel les administrations font face actuellement vient de ce que, dans certains secteurs du moins, les forces du marché l'emportent sur les politiques et, plus particulièrement, sur l'obligation de recourir à des produits normalisés. Il en est ainsi notamment de la bureautique et des progiciels [2], mais le problème s'étend également à l'acquisition de protocoles de communications non normalisés. Si certains ont proposé la modification des politiques afin de permettre l'acquisition de produits conformes à des SAP pour remédier au problème de non-respect des politiques, il est peu probable qu'un léger assouplissement de ces dernières concoure aux objectifs globaux d'interopérabilité, et cette formule pourrait se révéler nuisible, notamment là où aucune attention n'est accordée aux facteurs connexes.

Dans la plupart des cas, les exigences de la politique sont demeurées les mêmes et la plupart des administrations conviendraient que les objectifs de leurs politiques respectives de TI demeurent valables. La nécessité d'une connectivité large et « ouverte » entre les systèmes de TI n'est pas près de changer. En outre, les politiques publiques d'acquisition resteront foncièrement non discriminatoires durant une période indéterminée, et la demande d'interconnexion de systèmes variés continuera d'augmenter, du moins pendant quelques années. Les questions centrales sont celles de savoir si les objectifs des politiques sont réalisés, et, le cas échéant, dans quelle mesure les politiques en vigueur concourent à leur réalisation, et si la modification des politiques en faciliterait l'atteinte. Notamment, faut-il assouplir les politiques afin d'autoriser l'acquisition de TI non conformes aux normes officielles?

La politique impose l'achat de TI normalisées bien que, force est de constater, dans certains secteurs une part importante du matériel et des logiciels qu'achètent les administrations publiques n'ont jamais été conformes à une norme formelle, quelle qu'elle soit. En témoignent l'OP compatible IBM, le système d'exploitation DOS, MS Windows, WordPerfect et MS Word. Dans d'autres secteurs (tels ceux des connecteurs de télécommunications et des protocoles de couche physique), l'achat d'un produit non normalisé est pratiquement inconcevable.

Même si différentes mises en œuvre ou différentes versions d'un matériel ou d'un logiciel ne sont pas entièrement compatibles, il est souvent possible de les interconnecter dans une large mesure. Il est également possible de transférer des documents d'un logiciel de traitement de textes à un autre, sous réserve de certains contraintes, par exemple entre un appareil Macintosh d'Apple et un OP d'IBM. Cette situation illustre la possibilité d'interconnexions avantageuses dans certains secteurs en l'absence de normes formelles et sans créer d'obligation exclusive envers un seul fournisseur (même s'il faut reconnaître que la situation occasionne très souvent des frais importants – qu'il reste à quantifier, attribuables au temps et à l'énergie consacrés aux efforts de résolution de problèmes de compatibilité et à l'efficience moindre due, par exemple, au maniement de fichiers convertis incommodes). Les membres d'IPSIT conviennent de la nécessité d'instaurer des normes dans certains secteurs et les jugent simplement souhaitables dans d'autres. À titre d'exemple, il n'est pas nécessaire d'imposer une norme unique à un système de traitement de textes; toutefois, il est nécessaire de normaliser les formats d'échange et les interfaces. Par contre, il n'est ni indiqué ni pratique de définir des normes applicables à des produits dont la durée de vie prévue est brève.

Au cours de l'atelier de la CCE, les participants ont mentionné plusieurs fois la nécessité de fixer des priorités de normalisation des TI, mais tout indice quant à la façon de s'y prendre se perd dans la généralité des recommandations issues des échanges [9]. Il pourrait même se révéler difficile, très long, voire futile, de tenter de définir une formule par laquelle d'éventuels utilisateurs de normes de TI pourraient établir les priorités du processus d'établissement des normes. Il est clair que l'alourdissement de la bureaucratie du processus n'améliorera aucunement la situation. Il existe deux façons d'influencer le processus qui n'appellent aucun changement à l'infrastructure des normes : les auteurs de politiques prescrivant l'application de normes pourraient préciser les produits dont ils souhaitent la normalisation; les organisations qui collaborent à l'élaboration de normes pourraient se montrer plus sélectives au moment d'approuver les propositions de projets. L'utilisateur doit indiquer plus clairement les secteurs dans lesquels les normes sont essentielles, souhaitables ou non désirables.

L'une des façons d'évaluer l'orientation à donner à la normalisation des TI pourrait consister à examiner les principaux besoins en interconnexion des divers paliers de gouvernement. Nous constatons à ce chapitre les activités prioritaires suivantes :

Pour ce qui est des coûts, on peut difficilement prendre à parti un service pour avoir choisi la solution fonctionnelle la moins coûteuse, d'autant que l'époque est aux compressions budgétaires et que les deniers publics se font rares. Une prime de 300 ou 400 pour 100 demandée pour une solution normalisée est carrément inacceptable. Néanmoins, comme l'a signalé Isabel Valet [6], la prime de coût des produits normalisés est largement attribuable aux exigences en matière d'essais imposées par les politiques gouvernementales. Il est intéressant de constater qu'aucune exigence comparable ne s'applique à l'acquisition de produits et de services non normalisés (même si la politique proscrit l'achat de nombre d'entre eux). Si la politique devait être modifiée pour autoriser l'achat de produits conformes à des SAP, il semble fort improbable que les produits en question soient l'objet d'essais obligatoires. Fait incontestable, des motifs valables semblent militer en faveur d'un nouvel examen de l'attitude face aux exigences en matière d'essais, ce afin que pareilles exigences s'appliquent de façon équitable à toutes les acquisitions.

Les politiques de TI ont accru la visibilité des solutions normalisées, mais l'achat de produits non normalisés, au mépris apparent des politiques, est motivé par plusieurs facteurs. S'ajoutent à ceux qui ont déjà été mentionnés (c'est-à-dire l'inexistence de solutions normalisées; une fonctionnalité insuffisante; des coûts élevés; de simples pressions favorisant l'achat des produits les plus courus) le fait que nombre d'utilisateurs n'ont pas voulu se donner la peine de se renseigner sur les produits normalisés et que certains vendeurs n'ont pas voulu en faire la promotion. Dans la plupart des cas, là où un utilisateur souhaitait acheter un produit non normalisé et où il existait un équivalent fonctionnel et économiquement efficace normalisé, les administrations ont manqué de rigueur dans l'application de leurs propres politiques d'acquisition. Si une administration omet d'appliquer sa propre politique qui impose le recours à des produits normalisés, on ne s'étonnera pas de constater que les fournisseurs et les utilisateurs doutent du sérieux de sa détermination. Dans la même optique, si un fournisseur engage d'importantes ressources au développement d'un produit normalisé et s'il n'en fait pas la promotion avec au moins autant d'énergie qu'il consacre à celle de solutions autres, l'acheteur ne peut à lui seul porter la faute de l'achat d'un produit autre.

Le succès d'une politique passe par la clarté et la cohérence. Un changement apporté aux politiques de TI pour autoriser les SAP peut être soit avantageux (en favorisant l'atteinte des objectifs à long terme en matière d'interopérabilité, en venant compléter la solution des produits normalisés, en étant généralement positif) ou destructeur (en donnant des messages ambigus et en poussant plus loin la discrimination contre les solutions normalisées). Qui plus est, comme le signale Ray O'Connor [1] dans ses recommandations, les artisans de la politique doivent éviter de récompenser les pratiques anti-concurrentielles lorsqu'ils formulent des changements qui ménagent une place aux SAP. Il existe sans conteste de bons motifs d'envisager l'assouplissement des politiques de TI, mais il faudra accorder un soin particulier à la formulation des modifications.

Questions touchant à l'utilisation ou à l'homologation des SAP par le secteur public

L'organisation, quelle qu'elle soit, qui envisage d'utiliser ou d'homologuer des SAP ne doit pas manquer de se pencher sur certaines questions importantes, dont les suivantes :

Le mot de la fin

Nous avons sciemment évité d'utiliser le mot « conclusion », car nous sommes conscients que les conclusions qui seront tirées du texte qui précède seront, du moins dans une certaine mesure, propres au contexte local et aux politiques particulières en vigueur.

Le présent document a été rédigé à l'intention de l'IPSIT plutôt que par l'IPSIT. Les membres du groupe l'ont examiné et leurs commentaires particuliers y ont été intégrés. Il est possible que l'IPSIT fonde sur le présent document une prise de position collective sur les SAP à l'avenir, mais il s'agit pour l'instant d'un simple document de travail.

Le document soulève un grand nombre de questions et évite, pour l'essentiel, d'avancer des réponses précises. (Nous souhaitons, néanmoins, que des réponses se dégagent des échanges qui y feront suite.) Toutefois, nous croyons pouvoir tirer sans risque une conclusion de nos propos : il est peu probable que l'objectif d'une interopérabilité améliorée soit servi par une politique qui traite des normes de fait ou des SAP sans définir clairement ces termes et sans peser soigneusement les questions soulevées dans la section précédente.

Documents de référence