View source for Éléments pour un cadre d'interopérabilité technique pour Patrimoine Canadien

'''Montréal, le 8 février 2016'''

Rapport établi par '''Jonathan Le Lous, Hussein Abdallah (Savoir-faire Linux), Benjamin Jean et Camille Moulin (Société Inno3)'''


'''<big>SOMMAIRE EXÉCUTIF</big>'''

Savoir-faire Linux a été mandaté de mener une étude sur les cadres d'interopérabilité existants et de rédiger un rapport sur les enjeux et les possibilités opérationnelles liées à l'implantation d'un cadre d’interopérabilité basé sur des standards ouverts au sein du Ministère du Patrimoine Canadien.

L'étude sur le concept d'interopérabilité s'est basée sur la comparaison des cadres d'interopérabilité existants. À cet effet, les référentiels d'interopérabilité  québécois, européen, français et britannique ont été retenus comme exemples. Cette étude a permis de faire le lien entre l'interopérabilité des TI et les standards ouverts en les définissant par ces caractéristiques essentielles :  ouverture du processus de développement du standard à toutes les parties prenantes et sa transparence, droits de propriété intellectuelle permettant l'implémentation du standard dans tout type de logiciel (logiciels libres comme propriétaires), disponibilité de la spécification à coût nul ou marginal.

L'utilisation des TI interopérables a plusieurs avantages comme une plus grande indépendance vis-à-vis des fournisseurs et une plus grande flexibilité dans la conception et l'évolution de l'architecture d'entreprise.

Pour comprendre le contexte technologique et organisationnel de PCH, plusieurs employés de PCH et du Secrétariat du Conseil du Trésor ont été rencontrés au début du projet. Ces informations ont notamment permis de faire un inventaire des standards ouverts applicables à PCH : il s'agit de protocoles réseau et de formats de fichiers (ex : bureautique et multimédia). 

Les impacts immédiats de l'adoption d'un cadre d'interopérabilité à PCH incluent ces actions :
* Utilisation les standards ouverts lorsque possible dans les logiciels existants.
* Mise à jour des procédures et des directives pour la sélection et l'utilisation des formats de fichiers. Les standards ouverts doivent être favorisés;
* Changement des procédures de sélection des logiciels pour tenir compte du cadre d'interopérabilité. 
* Sensibilisation des employés à la problématique d'interopérabilité et des standards ouverts.

Enfin, il faut noter que pour profiter pleinement des avantages de l'interopérabilité, celle-ci doit  s'étendre à l'échelle du gouvernement du Canada et ne pas se faire individuellement dans chaque ministère.


'''<big>Introduction</big>'''

L'informatique, comme toutes les disciplines technologiques, connaît une évolution constante dont le rythme tend naturellement à s'accélérer, mais a désormais investi tant de domaines que sa nature globale s'en est trouvée changée. Un glissement terminologique s'est progressivement opéré : on parle désormais plus volontiers de numérique, pour rendre compte d'un périmètre qui, au-delà des technologies, s'étend désormais aux usages - la grande majorité des moyens de communication empruntant aujourd'hui ce support.

Les acteurs impliqués dans des interactions numériques ont à la fois crû exponentiellement en nombre et se sont diversifiés : individus, utilisateurs, entreprises, citoyens, institutions, objets, tous communiquent via des échanges informatiques. Ces échanges informatiques sont devenus un vecteur intermédiaire incontournable et l'hétérogénéité qu'ils présentent dans leur ensemble vient solliciter encore davantage la notion d'interopérabilité, c'est-à-dire la capacité à faire communiquer une diversité de systèmes d'information. Puisque ce rapport discute d'interactions numériques, les expressions « interopérabilité des systèmes d'information (SI) » et « interopérabilité des technologies de l'information et de communication (TI ou TIC) » sont ici synonymes.

Une politique positive en matière d'interopérabilité est donc d'autant plus fondamentale pour une organisation comme Patrimoine Canadien (PCH) au regard de ses missions de soutien et de promotion de la culture, des arts et des sports canadiens. En effet, les activités de PCH impliquent beaucoup d'échange de données avec toute sorte d'intervenants à travers le Canada pour organiser les événements culturels et sportifs d'une part, et pour subventionner les artistes et les sportifs canadiens d'autre part.

L'absence d'interopérabilité résulte ainsi au mieux en une communication ou un fonctionnement dégradés et, au pire, en la perte pure et simple de l'accès à ses informations.


== Périmètres, enjeux et définitions ==
Ce document a pour objectif d'impulser les réflexions nécessaires en termes d'interopérabilité au sein de Patrimoine Canadien ainsi que de l'administration canadienne dans son ensemble, tout en gardant à l'esprit les préoccupations relatives à la culture ainsi que la gestion des systèmes d'informations. Il s'appuie autant que nécessaire sur des initiatives internationales similaires et/ou remarquables.

Pour toute organisation, et a fortiori pour les organismes publics, ce besoin d'interopérabilité se présente à deux niveaux distincts susceptibles de se recouper partiellement : l'interopérabilité interne avec ses propres technologies de l'information et de la communication (TIC) et celle avec les TIC des acteurs externes (autres administrations, citoyens, entreprises, associations), que ce soit directement ou indirectement, par la mise à disposition de données ouvertes ou de réseaux de données ouvertes et liées.

[[File:Interoperabilite interne externe.PNG]]

Les démarches de Gouvernement Ouvert du Canada, qui comprennent les données ouvertes, l'information ouverte et le dialogue ouvert, renforcent encore ces enjeux puisque l'accès et le traitement des informations mises à disposition reposent sur l'usage de formats ouverts (communs) et interopérables<ref>http://ouvert.canada.ca/fr/principes-de-donnees-ouvertes</ref>. Ces principes sont souvent rappelés, que ce soit dans le cadre de politiques nationales telle que l'Open Standards principles (UK)<ref>https://www.gov.uk/government/publications/open-standards-principles/open-standards-principles </ref> ou encore au sein d'initiatives dédiées telle l'Open Government Standards<ref>http://www.opengovstandards.org</ref>.

=== Niveaux d'interopérabilité ===
En considérant l'interopérabilité externe, il apparaît que la nature du problème n'est pas uniquement technique, mais repose sur un ensemble de préoccupations à échelle différente. Le Cadre d'interopérabilité européen<ref>http://ec.europa.eu/isa/documents/isa_annex_ii_eif_en.pdf</ref> évoque ainsi :
* le '''cadre politique''' dans lequel cette interopérabilité prend place. Il s'agit de la volonté des dirigeants de définir les priorités ainsi que de fournir les ressources et les moyens pour réaliser les niveaux d'interopérabilité ci-dessous;
* l''''interopérabilité juridique''', qui s'assure de la légalité des échanges de données (notamment en matière de propriété intellectuelle et de communication des spécifications). Ces échanges peuvent être compliqués lorsque plusieurs États ayant des législations différentes sont impliqués. Le travail nécessaire ici est surtout un effort d'harmonisation juridique. ;
* l''''interopérabilité organisationnelle''', permettant aux entités impliquées de coordonner leurs processus pour le traitement des données. Ces entités (différents gouvernements, par exemple) n'ayant pas toujours de pendant direct d'un État à l'autre, ni les mêmes structurations internes, il est nécessaire de mettre en place les équivalences pertinentes selon les différents contextes;
* l''''interopérabilité sémantique''', qui s'assure de la compréhension et de la préservation des concepts manipulés. Les concepts, à la fois au niveau des institutions et de la langue, n'étant pas toujours identiques, il convient d'expliciter des correspondances permettant de cadrer les échanges d'un État à l'autre. 
* l''''interopérabilité technique''', qui concerne les interfaces logicielles et peut être elle-même subdivisée en deux sous-catégories, afin de distinguer l'interopérabilité syntaxique, qui concerne les formats d'échanges (manière dont des données sont codées et sauvegardées dans un fichier), par opposition aux protocoles d'échanges et APIs (ensembles de règles, instructions et routines qui permettent l'échange de messages entre systèmes voire le fonctionnement conjoint de deux applications).

La définition générique de l'interopérabilité englobe l'ensemble de ces dimensions :

<blockquote>« L'interopérabilité, dans le contexte des services publics européens, est l'habilité des différentes organisations à interagir pour atteindre des objectifs mutuellement avantageux, impliquant le partage de l'information (…) à travers les processus d'affaires qu'elles supportent, au moyen de l'échange des données entre leurs systèmes de technologies de l'information et de la communication respectifs.. »</blockquote>

[[File:Niveaux interoperabilite.PNG]]


L'interopérabilité interne est beaucoup plus centrée sur la dimension technique. La définition de celle-ci mérite une attention particulière, afin qu'elle reflète fidèlement les attentes associées au terme, notamment en termes d'indépendance - on parle parfois de souveraineté - et de neutralité. Une définition couramment retenue est celle proposée par le groupe de travail Interopérabilité de l'association francophone des utilisateurs des logiciels libres (AFUL)<ref>http://definition-interoperabilite.info/ </ref>:
<blockquote>« L'interopérabilité est la capacité que possède un produit ou un système, dont les interfaces sont intégralement connues, à fonctionner avec d'autres produits ou systèmes existants ou futurs, et ce sans restriction d'accès ou de mise en œuvre. »</blockquote>

Cette définition est également associée à un rappel du lien essentiel entre interopérabilité et standards ouverts. Les interfaces spécifiées font en effet l'objet de processus de standardisation et/ou de normalisation destiné à assurer l'émergence et le maintien de références communes et documentées.  Cette activité de normalisation est réalisée par des organismes spécialisés, qui sont le plus souvent soit des organismes d'État, soit des organisations créées par les professionnels d'un secteur d'activité donné. Parmi ces organismes, on peut citer l'exemple de l'IETF (Internet Engineering Task Force), l'ISO (International Organisation for Standardization) et l'OASIS (Organization for the Advancement of Structured Information Standards). De manière générale, les référentiels d'interopérabilité existants recommandent aux administrations et à leurs fournisseurs d'évaluer et d'utiliser les standards industriels existants au même titre que les normes issues des organismes de normalisation nationaux.

=== Caractéristiques des standards ouverts ===
Un standard ouvert est un standard implémentable par tous (dans des solutions libres comme propriétaires) et dont l'évolution n'est pas dépendante d'un acteur particulier. À l'inverse, on parle de standard fermé lorsque le référentiel n'est pas diffusé ou qu'il est soumis à des restrictions d'accès (par exemple : accord de confidentialité, licences non libres, brevets). L'utilisation des standards ouverts est nécessaire pour assurer l'interopérabilité entres des produits ou systèmes.

La formalisation exacte de ces aspects peut varier selon les instances, mais on constate cependant une forte convergence, illustrée ci-dessous par la comparaison du RGI<ref>http://references.modernisation.gouv.fr/interoperabilite</ref> (Référentiel Général d'Interopérabilité), du CCIGQ<ref>http://www.tresor.gouv.qc.ca/fileadmin/PDF/ressources_informationnelles/architecture_entreprise_gouvernementale/AEG_3.1-CCIGQinteroperabilite.pdf</ref> (Cadre Commun d'Interopérabilité du Gouvernement du Québec) et de l'EIF<ref>http://ec.europa.eu/isa/documents/isa_annex_ii_eif_en.pdf</ref> (European Interoperability Framework). Les critères contenus dans les OSP (Open Standard Principles)<ref>https://www.gov.uk/government/publications/open-standards-principles/open-standards-principles#open-standard-definition</ref> du Bureau du Cabinet britannique sont identiques à ceux du CCIGQ.

Les critères présents dans les quatre référentiels sont :
* L'ouverture du processus de développement du standard à toutes les parties prenantes et sa transparence;
* Des droits de propriétés intellectuelle permettant l'implémentation du standard dans tout type de logiciel (logiciels libres comme propriétaires).
* La disponibilité de la spécification à coût nul ou marginal;
Un quatrième critère fréquent concerne la gouvernance du standard par un organisme indépendant.

Le CCIGQ et l'OSP ajoutent un critère sur la validation du standard et de son indépendance par le marché. Le tableau ci-après indique les correspondances entre les différentes clauses des référentiels :

{| class="wikitable" border="1"
|-
! CCIGQ/OSP
! RGI
! EIF
|-
| '''Collaboration''' - le standard est élaboré par un processus décisionnel collaboratif sur la base d'un consensus indépendant de tout fournisseur. L'engagement dans le développement et l'évolution du standard est ouvert à toutes les parties intéressées.

'''Transparence''' - le processus décisionnel est transparent (accessible au public) et fait l'objet d'un examen par des experts en la matière.
| Ses évolutions se font sur la base d'un processus de décision transparent, ouvert, et accessible à toutes les parties intéressées.
| Toutes les parties prenantes ont la même possibilité de contribuer au développement de la spécification et la revue publique fait partie du processus décisionnel.
|-
| '''Accès équitable''' - le standard est publié, soigneusement documenté et accessible au public, soit gratuitement, soit pour un coût modique.
| La spécification fonctionnelle et technique du standard doit être complète, publique, sans restriction ni d'accès ni de mise en œuvre.

La spécification est disponible à coût zéro, (voire à coût faible ou marginal sans toutefois limiter la réutilisation notamment dans des logiciels libres).
| La spécification est disponible pour être étudiée par tout le monde.
|-
| '''Procédure régulière''' - le standard est adopté par un organisme de normalisation, un forum ou un consortium, et un processus de rétroaction ainsi que d'approbation permet d'en assurer la qualité.
| Il est maintenu par une organisation sans but lucratif (organisme de standardisation, forum, consortium...).

Un calendrier d'évolutions est publié et les parties intéressées sont informées de la teneur des prochaines versions.
| Le standard est adopté et maintenu par une organisation sans but lucratif et son évolution ultérieure se base sur une procédure de prise de décision transparente.
|-
| '''Droits''' - pour assurer notamment l'interface avec d'autres implémentations [...] les droits essentiels à la mise en œuvre du standard sont autorisés sur une base libre de redevances qui est compatible avec les solutions en logiciels libres et les solutions sous licences propriétaires. Ces droits doivent être irrévocables, sauf en cas de violation des conditions de la licence.
| Les droits du standard sont sous sur une base libre de droits et compatible avec les logiciels libres et les logiciels propriétaires.
| Les droits de propriété intellectuelle reliés à la spécification ne doivent pas empêcher son implémentation aussi bien par les logiciels libres que les logiciels propriétaires.
|-
| '''Soutien du marché''' - à l'exception d'un contexte de solutions innovantes, le standard est mature, il a le soutien du marché et il a démontré son indépendance par rapport aux plates-formes, aux applications et aux fournisseurs.
| 
| 
|}

==== Les recommandations conséquentes ====
À terme, il pourra être envisagé :
* de s'inspirer des pratiques du gouvernement du Royaume-Uni qui a sélectionné à travers un processus ouvert<ref>https://standards.data.gov.uk/</ref> un ensemble de standards ouverts<ref>https://www.gov.uk/government/publications/open-standards-for-government</ref> et qui s'est doté une politique sur les principes des standards ouverts<ref>https://www.gov.uk/government/publications/open-standards-principles/open-standards-principles</ref>. Il propose de manière complémentaire une liste détaillée de questions qu'il peut être pertinent de se poser, relativement à chaque critère, afin d'évaluer les différents standards<ref>http://standards.data.gov.uk/core-assessment-questions</ref>.
* de définir une Méthode de classification et de présentation homogène des standards. Le RGI français propose par exemple d'utiliser Wikipédia pour décrire ces standards. L'objectif est, en rajoutant également un lien vers la page Wikipédia du standard, d'avoir une vision la plus proche de l'état de l'art relatif au standard (Wikipédia est régulièrement mis à jour en ce qui concerne ses articles sur ces standards).
* de constituer des "profils d'interopérabilité" à l'instar de la version 1.9.10 du RGI<ref>http://references.modernisation.gouv.fr/sites/default/files/Referentiel_General_Interoperabilite_V1.9.10.pdf</ref> (soumise aux commentaires du public) qui les a instaurés pour opérer une classification claire et homogène des standards, et lutter contre leur prolifération en ne sélectionnant que les plus pertinents selon les contextes. Un profil d'interopérabilité est donc "un ensemble limité de standards à utiliser dans un contexte, un usage déterminé."

=== Interopérabilité et logiciels libres ===
D'un point de vue conceptuel, l'interopérabilité et les logiciels libres sont clairement distincts, tout comme le sont les standards ouverts et les logiciels libres. D'un point de vue culturel et historique, on constate en revanche des liens forts entre ces notions. Cela s'explique par la « communauté de valeurs » : par leur nature ouverte, les modèles économiques liés aux logiciels libres sont moins fondés sur des logiques d'enfermement de l'utilisateur et favorisent aux contraires l'interopérabilité bénéfique  aux utilisateurs.

Par ailleurs, les logiciels libres constituent un bon révélateur du réel degré d'interopérabilité d'un contexte : si l'implémentation d'un standard n'est pas possible dans le cadre d'une solution libre, alors le standard ne peut être considéré comme ouvert<ref>https://opensource.org/osr</ref>. Inversement, certains « standards » s'imposent sans processus de standardisation formels, jugés trop longs, mais par la diffusion alternative de bibliothèques sous licences Open Source de référence.

L'Europe a très tôt rappelé le lien étroit entre les deux notions, par exemple au sein du Cadre d'interopérabilité européen pour les services de gouvernement électronique :
<blockquote>« Les logiciels libres tendent à utiliser les standards ouverts tout en aidant à définir les spécifications publiquement disponibles. Les logiciels libres représentent par leur nature des spécifications publiquement accessibles et la disponibilité de leur code source permet de promouvoir un débat ouvert et démocratique sur les spécifications, les rendant ainsi plus robustes et interopérables. Pour cette raison, les logiciels libres correspondent aux objectifs de ce cadre et devraient être considérés favorablement au côté des alternatives propriétaires. » (p. 10) [traduction non officielle de l'anglais]</blockquote>

=== Interopérabilité et sécurité ===
Un standard ouvert n'est pas nécessairement plus ou moins sécuritaire que le format propriétaire. À ce sujet, on peut citer en exemple la présentation du ministère de la défense français qui compare les formats Office Open XML et OpenDocument<ref>http://www.decalage.info/files/PacSec06_Lagadec_OpenDocument_OpenXML.pdf</ref>. Ils arrivent à la conclusion que le format ouvert ODF n'est pas intrinsèquement plus sécuritaire mais qu'il permet de détecter et de filtrer plus facilement le contenu à risque. De façon générale, la sécurité d'un système d'information est une préoccupation essentielle qui vient s'ajouter à la problématique de l'interopérabilité mais n'en fait pas directement partie. Pour cette raison, ce rapport ne traite pas de la sécurité informatique en tant que telle.

=== Interopérabilité interne et architecture d'entreprise ===
==== Indépendance et substituabilité ====
D'un point de vue interne, l'interopérabilité est étroitement liée à la question de l'architecture d'entreprise (urbanisation), en permettant le découplage de ses différentes composantes tout en conservant leur intégration. Ainsi, le cadre commun d'interopérabilité du gouvernement du Québec (CCIGQ)<ref>http://www.tresor.gouv.qc.ca/ressources-informationnelles/architecture-dentreprise-gouvernementale/standards-et-normes/cadre-commun-dinteroperabilite/</ref> s'inscrit dans le Cadre de référence de l'architecture d'entreprise gouvernementale et la version 2 du RGI français renvoie au Cadre Commun d'Urbanisation du Système d'Information de l'État<ref>http://references.modernisation.gouv.fr/sites/default/files/Cadre%20Commun%20d'Urbanisation%20du%20SI%20de%20l'Etat%20v1.0_0.pdf</ref>.

Dans le contexte des TIC que l'on maîtrise entièrement, une possibilité pour assurer l'intégration des composants est celle de l'uniformisation, soit des produits directement, soit à l'intérieur d'une famille de produits, généralement proposés par un même fournisseur. Une telle démarche peut présenter des avantages fonctionnels (généralement au niveau de la finesse de l'intégration entre les produits), mais elle présente l'inconvénient de lier les TI internes à un système externe ou à un fournisseur en particulier. Ce lien peut devenir un handicap à la fois technique (excluant l'adoption de nouvelles solutions plus pertinentes) et économique (en réduisant les possibilités de négociation et en augmentant les coûts de sortie).

Dans une situation d'interopérabilité idéale, on dispose au contraire d'une substituabilité des briques, chacune pouvant évoluer plus facilement et de façon indépendante. Une telle démarche renforce la liberté de choix et renforce l'agilité au sein du SI puisque chaque brique peut être remplacée par une autre à fonctionnalité équivalente sans impacter le reste du SI.

==== Interopérabilité et adhérences applicatives ====
Dans le cadre d'un SI interne, l'interopérabilité peut se considérer selon deux dimensions : l'une « horizontale », entre deux applications distinctes, qui se rapproche dans sa nature de celle en jeu lors de l'interaction entre deux SI différents, et l'autre « verticale », qui concerne les composantes d'une même application. C'est typiquement le cas entre la partie applicative proprement dite et les briques d'infrastructure sous-jacentes (par exemple un applicatif peut exiger une base de données spécifique, qui elle-même ne fonctionne que sur un système d'exploitation particulier, sans qu'aucune spécificité fonctionnelle n'entre en jeu). On entre ici dans le cadre d'adhérences applicatives, qui déborde celui de l'interopérabilité, mais en partage de nombreux principes fondamentaux.

[[File:Interoperabilite_verticale.PNG]]

On peut citer en exemple la gendarmerie nationale française.  Elle a mis en place une politique très stricte pour la transférabilité des solutions logicielles, la réversibilité des externalisations et l'indépendance stricte entre applications.  Donc, aucun projet ne doit contraindre le choix des logiciels des autres.  Toute interface entre applications doit respecter un standard ouvert et les logiciels doivent être multi-plateformes. Ceci a permis d'éliminer les adhérences applicatives au niveau du système d'exploitation. Depuis 2008, la très grande majorité des renouvellements de postes s'effectue sur Linux et le passage de Windows à Linux est un non-événement, les utilisateurs passent indifféremment de l'un à l'autre.  Depuis, ils ont observé une uniformisation des postes et des versions logicielles générant des gains conséquents dont une réduction de 40% du coût pour le cycle de vie des postes de travail.<ref>https://www.s2lq.com/sites/s2lq.local/files/Retex%20-%20Quebec%202014.pdf</ref>

==== Interopérabilité et infonuagique ====
L'infonuagique consiste à offrir des services d'infrastructure et des services applicatifs à la demande. Cela est rendu possible grâce à une virtualisation poussée des composants matériels par des logiciels d'infrastructure-service (tels qu'OpenStack). L'infonuagique s'appuie sur une architecture logicielle complexe qui gère à la fois l'élasticité des ressources (processeurs, mémoire vive, stockage et réseaux) et la capacité des applicatifs à utiliser  celles-ci de façon optimale.

L'infonuagique peut-être privée c'est-à-dire interne à l'entreprise, publique si elle est hébergée par une organisation tierce ou hybride quand elle allie les deux modes.

Il n'y a pas de différence fondamentale en termes d'interopérabilité entre une infrastructure classique et  infonuagique si ce n'est la complexité que celle-ci engendre et la nécessité de standardiser les composantes verticales et horizontales de façon plus poussée. En particulier l'externalisation du SI au sein d'une infonuagique publique doit prendre en compte la capacité de l'organisation tierce, privée ou les services partagés, à appliquer des standards qui offrent la possibilité de changer de fournisseurs ou de réintégrer un certains nombres de services le cas échéants. Dans ce contexte l'absence de cadre interopérabilité et de standards acceptés par le fournisseur fait porter un risque important sur la pérennité du SI.

En ce qui concerne le déploiement d'une infonuagique privée, l'interopérabilité favorise la mise en compétition avérée des fournisseurs, que ce soit au niveau matériel comme logiciel, ainsi que la capacité à faire évoluer son infrastructure dans le temps. En effet, l'usage de standards, via des API par exemple, permettra d'augmenter l'indépendance vis-à-vis des différents pilotes propres aux éléments matériels mais aussi de rendre indépendant ces services d'infrastructure des logiciels qu'elle déploie.

L'implantation infonuagique est ainsi une occasion unique de standardiser ces processus et de s'accorder sur un cadre commun. L'usage d'un cadre d'interopérabilité et l'usage de standards, notamment en terme de virtualisation, au sein de l'infrastructure infonuagique privée rendra plus simple et moins coûteuse l'externalisation d'une partie de celle-ci vers une organisation tierce, que ce soit une entreprise ou les services partagés, dans une logique d'hybridation.

=== La notion de cadre d'interopérabilité ===
Un cadre d'interopérabilité se définit par l'ensemble des politiques, des lignes directrices, des standards, des règles et des recommandations prises par un réseau d'acteurs en vue d'atteindre le plus haut niveau d'interopérabilité possible.

Il décrit également les règles de fonctionnement qui régissent l'analyse, le choix, l'adoption et la mise à jour de chacun de ces éléments.

Il apparaît en effet nécessaire, pour permettre la mise en place, puis la pérennité, de systèmes interopérables d'effectuer des choix communs en termes de standards à adopter, mais également concernant les conditions de leur implémentation.

C'est ainsi que plusieurs pays européens (dont la France et le Royaume-Uni), et des provinces canadiennes comme le Québec ont choisi de mettre en place des cadres d'interopérabilité. Les résultats en sont probants, les standards ouverts y étant à présent d'usage courant et, sont toujours considérés en premier lieu lorsque de nouveaux besoins émergent.

Comme cela est rappelé dans les différents cadres d'interopérabilité déjà publiés, ces derniers n'ont que vocation à identifier des standards clés, et non pas présenter des solutions (par exemple en termes de choix de logiciel associé) prédéfinies et uniques. Le RGI va jusqu'à proposer des profils d"interopérabilité (assemblages clés), mais ne va pas plus loin. L'objectif d'un cadre d'interopérabilité est donc de faciliter et d'orienter les choix des organisations en matière d'interopérabilité, tout en limitant le nombre de standards potentiels afin de garantir un maximum de clarté.

== Définition du cadre d'interopérabilité ==
=== Contexte de Patrimoine Canada ===
==== L'interopérabilité au cœur du Plan du Canada pour un gouvernement ouvert ====
Le gouvernement du Canada s'inscrit dans une démarche volontaire d'ouverture, se déployant nécessairement à plusieurs niveaux, comme l'illustrent les différentes composantes le Plan du Canada pour un gouvernement ouvert (2014).

En effet, une telle démarche de gouvernement ouvert ne peut se penser indépendamment d'une solide politique de données ouvertes et de principes standardisés en matière d'interopérabilité (et donc de standards ouverts). C'est dans cette logique que le gouvernement du Royaume-Uni a publié en 2012 l'Open Data White Paper<ref>https://data.gov.uk/sites/default/files/Open_data_White_Paper.pdf</ref>, présentant leurs fameux "Open Data Principles" qui se sont progressivement imposés au cœur de la politique de publication de données du gouvernement. Ils sont  au centre de la récente actualisation du National Information Infrastructure (mars 2015), présentés comme ayant vocation à être une base permettant de sélectionner et de mettre en œuvre différents standards en vue d'encourager les données ouvertes, et plus largement les stratégies du gouvernement en matière de technologies de l'information et de numérique.

C'est ainsi que dans le cadre du plan d'action du Canada pour un gouvernement ouvert, le gouvernement du Canada s'est doté de plusieurs principes en matière des données ouvertes, dont l'utilisation des formats communs.

La justification donnée est la suivante : « Par exemple, si une seule entreprise fabrique le programme pouvant lire un fichier où des données sont conservées, l'accès à l'information dépend de l'utilisation du programme de cette entreprise. Ce programme peut être inaccessible au public ou l'être moyennant certains frais. L'élimination de ces frais permet de rendre les données accessibles à un plus grand nombre d'utilisateurs potentiels. Dans la mesure du possible, les jeux de données publiés par le gouvernement du Canada devraient donc être conservés dans des formats de fichiers accessibles gratuitement. »<ref>http://ouvert.canada.ca/fr/principes-de-donnees-ouvertes</ref> La Charte du G8 sur les données ouvertes va dans le même sens en énonçant le principe d'utilisation universelle qui consiste à « diffuser le plus de données possible dans autant de formats ouverts que possible. » Par rapport à ce principe, le Canada s'engage  « à ce que toutes les données ouvertes publiées le soient dans des formats ouverts gratuits. »<ref>http://ouvert.canada.ca/fr/charte-du-g8-sur-les-donnees-ouvertes-plan-daction-du-canada</ref>

==== L'interopérabilité, un enjeu de long terme pour PCH ====
===== L'interopérabilité au service de la mission de PCH =====
Patrimoine Canadien a pour mission de favoriser un « environnement dans lequel tous les Canadiens profitent pleinement d'expériences culturelles dynamiques, célèbrent leur histoire et leur patrimoine, et contribuent à bâtir des communautés créatives ».<ref>http://pch.gc.ca/fra/1310495889171</ref> Pour mener à bien ces différentes missions, PCH se doit d'emprunter le virage du numérique en tirant le maximum des avantages offerts par ce dernier. 
Pour apporter une réponse à ces objectifs, l'adoption d'une politique en matière d'interopérabilité par Patrimoine Canadien apparaît tout à fait pertinente, facilitant d'une part les missions de ses agents, et d'autre part la participation des usagers. Le présent document vise ainsi à présenter les différents standards ouverts que PCH peut utiliser pour améliorer l'interopérabilité avec les systèmes d'information des utilisateurs et des fournisseurs de données, et aussi pour assurer la pérennité de ces données informatiques dont certaines font partie du patrimoine canadien.

===== Accès aux données, et utilisation par les usagers =====
Dans le contexte de PCH, la mise en place d'un cadre d'interopérabilité et l'application de standards ouverts permettraient de garantir que tous les individus aient accès aux contenus diffusés par l'organisation, cela sans limite technologique ni obligation d'accéder à des technologies payantes.

Ce choix n'est cependant pas neutre et nécessite la prise en compte des contraintes organisationnelles et techniques tout en restant axé sur l'opportunité d'innover et d'offrir un service à haute valeur ajoutée aux Canadiens. L'interopérabilité ne doit pas se faire au détriment de la qualité et de l'exactitude des données.

===== Indépendance envers les fournisseurs =====
À la demande du Secrétariat du Conseil du trésor, Patrimoine Canadien doit rationaliser son portfolio d'applications.  Le but étant de passer de 300 applications à environ 30 en regroupant des systèmes similaires dans une même application, comme par exemple le systèmes de suivi. PCH doit évaluer des solutions possibles, mais il n'y a pas de direction claire sur l'interopérabilité et les standards ouverts, ce qui fait que ces critères sont rarement considérés lors du processus de sélection de technologies.

Le respect de ces critères en matière de standards permet à PCH de réduire le risque que l'accès au patrimoine numérique dépende d'un seul fournisseur. Cette situation de verrouillage et d'enfermement s'avère en effet particulièrement dommageable, réduisant le choix et les potentialités de chaque partie prenante, augmentant les contraintes en termes de coûts, et présentant des risques en termes de pérennité et d'accessibilité des données. L'élaboration du plan de rationalisation d'applications est donc une bonne occasion pour introduire un cadre d'interopérabilité.

===== Pérennité des données et interopérabilité avec les systèmes futurs =====
Bibliothèques et Archives nationales Canada indique que la « capacité à utiliser l'information est en danger si le matériel et les logiciels nécessaires pour consulter l'information ne sont plus disponibles ou si les spécifications du format ne sont pas accessibles.»<ref>http://www.bac-lac.gc.ca/fra/services/gestion-ressources-documentaires-gouvernement/lignes-directrices/Pages/lignes-directrices-formats-fichier-transferers-ressources-documentaires.aspx</ref> Alors, pour s'assurer que les données importantes pour PCH soient et restent disponibles à long terme aussi bien pour le personnel de PCH que pour les citoyens, il est nécessaire d'utiliser des formats ouverts lors de la production et de l'archivage du contenu numérique. Cela permet d'assurer, ou tout au moins de favoriser l'interopérabilité avec les systèmes futurs sans égard à l'existence ou au coût des logiciels qui ont été utilisés pour les produire.

Toutefois, pour conserver les données durablement avec une qualité identique il n'est pas suffisant d'utiliser les formats ouverts. L'emplacement et le support physique de ces données sont également importants afin de sécuriser leur accessibilité et leur réutilisation sur le long terme. Vu l'importance de cette question pour Patrimoine Canadien, cette problématique est mentionnée dans ce document même si elle n'est pas directement reliée aux standards ouverts. Il s'agit en quelque sorte de l'interopérabilité des média de stockage de données.

Il est important de s'assurer que les serveurs qui contiennent les fichiers de PCH appartiennent à PCH et soient hébergés soit dans les locaux de PCH, soit dans un espace réservé à PCH dans un centre de données externe. Il existe un certain nombres de solutions de gestion de fichier à la demandes externes tels que Dropbox, Microsoft OneDrive et Google Drive. Ces solutions peuvent être très pratiques, mais les serveurs et donc les données qu'ils sauvegardent ne sont pas sous le contrôle de PCH et le gouvernement ne doit pas faire confiance à des entreprises privées pour conserver ses données. En effet, il n'est pas possible pour le gouvernement de contrôler les pratiques de ces entreprises en ce qui concerne la conservation et l'accès aux données enregistrées sur leurs plates-formes. Enfin, ces dernières se trouvent généralement à l'extérieur du Canada, ce qui peut parfois occasionner des problèmes légaux. Ces solutions pourraient toutefois servir à sauvegarder hors site des fichiers qui ne contiennent pas d'information sensible et qui ne sont pas très importants.

L'enregistrement de données sur une infrastructure appartenant au gouvernement est donc souhaitable. Il faut également s'assurer que les données soient enregistrées sur des serveurs fiables contenant plusieurs disques en réplication, régulièrement sauvegardés et qu'une copie de sauvegarde hors site existe pour les données les plus importantes, afin de se prémunir contre un sinistre sur le site principal. En effet, lors des rencontres à PCH, il a été révélé que certaines données sont enregistrées uniquement sur un seul ordinateur dans un seul bureau.

Pour les données archivées sur des supports numériques tels que les disques durs, les CD-ROM et DVD-ROM et les supports flash (disques SSD, clés USB, cartes SD) il est important d'avoir un plan de conservation à long terme : ces supports numériques ont une durée de vie limitée qui dépend de la qualité physique du média et des conditions de leur entreposage. Ils deviendront probablement illisibles après quelques années ou dizaines d'années. Il est donc important de vérifier que ces supports restent lisibles à intervalles réguliers et de copier les données importantes vers des supports neufs. Cette stratégie étant fiable, mais coûteuse, il est nécessaire de bien identifier les données les plus importantes pour PCH pour lesquelles elle devra être appliquée.

==== Critères d'inclusion des standards dans un cadre d'interopérabilité ====
Il convient de prendre en compte un certain nombre de critères afin de sélectionner les standards qu'il est pertinent de recommander aux organisations. Idéalement une organisation n'utiliserait que des standards ouverts, c'est à dire des standards qui répondent aux critères présentés dans la section 1.2 : élaborés de manière collaborative et transparente, sans restriction quant à l'accès et à l'implémentation (donc pas de brevets logiciels restrictifs), maintenus par un organisme indépendant et soutenus par l'industrie.

Il n'est pas suffisant qu'un standard soit ouvert pour être inclus dans un cadre d'interopérabilité. Il doit également être pertinent, mature, et facile à déployer. La pertinence dans ce contexte correspond à l'adéquation entre les fonctionnalités offertes par le standard et les fonctionnalités requises par l'organisation. Il s'agit d'un critère fonctionnel. Quant à la maturité, il s'agit de s'assurer que le format a déjà fait ses preuves. Enfin, le coût de l'implémentation d'un standard reste un critère incontournable.

Enfin, certains standards qui ne répondent pas à tous les critères d'un standard ouvert sont tellement répandus qu'ils peuvent quand même être inclus par souci d'interopérabilité.

===== Critère fonctionnel : transmission et conservation de l'information =====
Le premier critère de sélection d'un protocole ou d'un format numérique est fonctionnel : est-ce qu'il permet de transmettre ou de conserver l'information de façon pertinente.

Par exemple :
* Est-ce que le format de document permet d'intégrer un tableau et des images?
* Est-ce que le format de photographie ou de dessin numérique permet l'impression sur un format de papier donné ou la visualisation sur un écran de taille donnée, et ce, avec une qualité jugée acceptable par les utilisateurs?
* Est-ce que la taille des fichiers audio qui contiennent de la musique permet un téléchargement rapide sur une connexion résidentielle ou mobile typique?
* En cas de compression, est-ce que les données du fichier original sont perdues?
* Est-ce que le fichier peut-être facilement édité / modifié par la suite?

Les critères fonctionnels concernent aussi bien les formats ouverts que les formats fermés et propriétaires. Il se peut que dans certains cas, il n'existe pas de formats ouverts qui répondent à tous les critères fonctionnels. Dans cette situation, l'utilisation du format propriétaire peut-être acceptable à condition qu'une copie existe également dans un format ouvert.

===== Le critère du coût de remplacement (coût de sortie) =====
Bien évidemment, le coût reste un critère essentiel lors de la comparaison des logiciels et solutions nécessaires pour utiliser les différents standards.

Il faut garder à l'esprit lors de cette comparaison qu'il faut inclure les coûts de sortie et de migration (remplacement d'une solution TI par une autre). À ce sujet, une étude de l'université de Delft au Pays-Bas explique que les coûts de remplacement d'une solution TI par une solution provenant d'un autre fournisseur sont élevés lorsque la solution remplacée utilise les formats fermés et ce, indépendamment de l'utilisation des standards ouverts par la solution de remplacement. Cependant, une fois que l'organisation implémente des standards ouverts, les coûts de remplacement de fournisseur sont plus bas justement parce que la solution basée sur les standards ouverts proposée par le nouveau fournisseur est interopérable avec la solution précédente. Les avantages de l'utilisation des standards ouverts sont donc effectifs à long terme une fois que ces standards ouverts sont devenus la norme pour les TI d'une organisation<ref>http://repository.tudelft.nl/assets/uuid:391a61e9-cdf4-476d-9e97-070b733450ff/295829.pdf</ref>.

Selon la même étude, voici les coûts de remplacement qui sont plus bas dans le cas où la solution à remplacer utilise des standards ouverts :
* coûts reliés à l'incompatibilité (appelés aussi coûts reliés aux effet de réseau - network effects) : lorsque la solution remplacée et la solution de remplacement utilisent les mêmes standards ouverts, les risques d'incompatibilité sont minimisés. La réduction de ces coûts d'incompatibilité est l'une des raisons d'être principales d'un cadre d'interopérabilité;
* coûts de recherche : dans le cadre d'une solution TI utilisant des standards ouverts, l'effort nécessaire pour trouver des solutions de remplacement compatibles est probablement moindre que si la solution à remplacer utilisait des formats fermés propres à une entreprise spécifique;
* coûts d'apprentissage : deux applications utilisant le même format ouvert (exemple le format ODF pour la bureautique ou le format JPG pour les images) peuvent avoir des interfaces d'utilisateur différentes, donc les coûts d'apprentissage des utilisateurs finaux ne sont pas réduits. Toutefois, si on parle des applications développées à l'interne et qui utilisent ces formats, le fait d'utiliser un format ouvert réduit le temps d'apprentissage des développeurs qui doivent créer des nouvelles applications ou des nouveaux liens entre applications existantes.

En résumé, même si l'adoption des standards ouverts ne permet pas toujours de faire des économies immédiates, elle permet d'éviter les coûts reliés à l'enfermement propriétaire dans le futur.

=== Exemples de cadres d'interopérabilité ===
==== L'exemple européen ====
La Commission européenne a eu de 2004 à 2009 le programme IDABC (Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens) chargé de faciliter les démarches administratives transfrontalières à l'intérieur de l'Europe. Il a été prolongé par le programme ISA (Solutions d'interopérabilité pour les administrations publiques européennes) de 2010 à 2015, lui-même suivi d'ISA2, qui s'étendra de 2016 à 2020.

En décembre 2010, une synthèse a été publiée (« Vers l'interopérabilité des services publics européens »)<ref>http://ec.europa.eu/isa/documents/isa_iop_communication_en.pdf</ref> présentant la Stratégie européenne d'interopérabilité (EIS, European Interoperability Strategy)<ref>http://ec.europa.eu/isa/documents/isa_annex_i_eis_en.pdf</ref> et le Cadre européen d'interopérabilité (EIF, European Interoperability Framework) dans sa deuxième version, dont l'élaboration a soulevé plusieurs controverses<ref>http://fsfe.org/activities/os/eifv2.en.html</ref>.

Ce cadre constitue un point de convergence pour les cadres d'interopérabilité nationaux des pays membres (NIF, National Interoperability Framework). Les NIF ne sont pas des transpositions directes de l'EIF, mais correspondent aux documents, souvent préexistants, couvrant ces sujets et qui devront à terme converger pour implémenter l'EIF. Ils sont pour la plupart plus techniques que l'EIF et peuvent couvrir des cas d'interopérabilité interne aussi bien qu'externe. Dans le cadre du programme ISA, un observatoire<ref>https://joinup.ec.europa.eu/community/nifo/home</ref> a été créé sur le sujet (NIFO, National Interoperability Framework Observatory), offrant une vue synthétique de l'évolution des différents NIF.

Il est possible de faire un parallèle entre la relation qui existe entre les cadres d'interopérabilité nationaux et européen en Europe et le relation qui pourrait exister entre les cadres d'interopérabilité provinciaux et fédéraux au Canada. Cela dépasse toutefois le cadre de ce rapport et pourrait être complexe à mettre en œuvre à cause des spécificités politiques des relations provinciales-fédérales au Canada.

==== L'exemple français ====
Le Référentiel Général d'Interopérabilité (RGI)<ref>http://references.modernisation.gouv.fr/interoperabilite</ref> français est un document élaboré par la DISIC (Direction interministérielle du numérique et du système d'information et de communication de l'État) adressant les questions d'interopérabilité entre les autorités administratives françaises. La dernière version disponible est la 1.9.10, en attente de validation finale pour devenir la version 2.0. Il concerne en premier lieu l'interopérabilité externe, en précisant cependant : « Pour leurs besoins internes, les autorités administratives restent libres du choix des normes, standards et pratiques à mettre en œuvre. Toutefois, il est souhaitable qu'elles suivent par défaut les recommandations du RGI. »

Il se situe uniquement au niveau technique comprend une liste de standards ainsi qu'une série de profils techniques : les profils correspondent à des ensembles cohérents de standards, adaptés à des contextes spécifiques.

==== L'exemple britannique ====
En mars 2011, Le Cabinet Office du Royaume-Uni a publié sa stratégie en matière de Technologies de l'Information et de la Communication<ref>https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/85968/uk-government-government-ict-strategy_0.pdf</ref>. Cette stratégie comporte deux axes. Le premier consiste en l'intention de créer un cadre de compétition équitable pour les logiciels libres; et le second d'imposer des standards ouverts.

Plus spécifiquement, le gouvernement du Royaume-Uni a décidé de choisir le format OpenDocument pour tous les documents bureautiques éditables<ref>https://www.gov.uk/guidance/open-document-format-odf-guidance-for-uk-government</ref>. Considérant l'omniprésence des fichiers bureautiques dans les organisations et la quantité de données enregistrée dans ces fichiers, le choix d'un standard ouvert comme l'ODF est un pas important vers une meilleure interopérabilité.

2.2.4    L'exemple québécois
Le cadre commun d'interopérabilité du gouvernement du Québec a été élaboré par le Secrétariat du Conseil du trésor du Québec dans « l'objectif de servir de cadre normatif de référence pour tout acteur d'un organisme public jouant un rôle dans la conception, le développement et la gestion d'un système d'information. Il peut servir comme intrant et matériel de référence à l'architecture d'entreprise gouvernementale et à l'architecture d'entreprise corporative. »<ref>http://www.tresor.gouv.qc.ca/fileadmin/PDF/ressources_informationnelles/cadre_commun_interoperabilite.pdf</ref>

Ce cadre s'inscrit dans la Politique-cadre sur la gouvernance qui a pour objectifs :
* Minimiser les investissements complémentaires : en général, les logiciels basés sur les standards ouverts peuvent fonctionner sur plusieurs plate-formes, alors que l'utilisation des formats non ouverts comme ceux de Microsoft ou de Adobe nécessite l'utilisation des logiciels qui ne fonctionnent que sous (certaines versions) de Microsoft Windows et de Mac OS X, ce qui fait que l'organisation est obligée d'acheter des licences pour les systèmes d'exploitation en plus des licences des applications. Plus en général, les standards ouverts permettent souvent d'utiliser aussi bien des logiciels libres que les logiciels propriétaires, alors que par définition, il est difficile, voir impossible, d'avoir des logiciels libres qui implémentent de façon 100% compatible et légale les formats propriétaires.
* Tirer profit des ressources informationnelles en tant que levier de transformation;
* Investir de façon optimale et rigoureuse;
* Optimiser la gestion de l'expertise et du savoir-faire;
* Assurer la sécurité de l'information;
* Tirer profit des logiciels libres.

== Revue des protocoles et formats ==
Cette partie traite des protocoles et formats informatiques qui sont pertinents pour PCH. Même si la plupart d'entre eux sont déjà utilisés, il convient ici de les présenter de façon systématique ainsi que d'émettre des recommandations allant dans le sens de l'interopérabilité. Les protocoles et formats listés se basent sur les domaines fonctionnels identifiés lors des échanges avec les employés de PCH.

Les protocoles et standards retenus doivent donc être pertinents du point de vue fonctionnel (répondant au besoins informatiques de PCH) mais aussi matures, faciles à déployer et soutenus par l'industrie. Ils doivent aussi être ouverts tel que présenté dans la section 1.2. Cependant, certains formats qui ne répondent pas à tous les critères de formats ouverts sont présentés ici soit à titre comparatif, soit à cause de leur grande diffusion. Dans ce cas, l'utilisation de ces formats peut être acceptable si une copie est également enregistrée dans un format ouvert.

=== Références utilisées dans ce document ===
Lorsqu'un format ou protocole est spécifié dans une RFC (Request for Comment - demande de commentaires) du IETF (Internet Engineering Task Force), l'URL complète n'est pas indiquée dans les tableaux pour alléger le texte. Toutes les RFC ont une URL du type https://tools.ietf.org/html/rfcNNNN où NNNN est le numéro de la RFC. L'IETF est un groupe informel, international, ouvert à tout individu, qui participe à l'élaboration des standards Internet. Lorsque le protocole ou le format n'est pas spécifié dans une  RFC, l'URL complète de la source est indiquée. Plusieurs résumés des formats et protocoles utilisent les descriptions de Wikipédia (dans sa version française ou anglaise).

Voici les documents produits par les gouvernements de la France et du Québec qui ont été également utilisés dans la rédaction du présent document :
* Cadre commun d'interopérabilité du gouvernement du Québec : http://www.tresor.gouv.qc.ca/fileadmin/PDF/ressources_informationnelles/architecture_entreprise_gouvernementale/AEG_3.1-CCIGQinteroperabilite.pdf 
* Référentiel général d'interopérabilité du gouvernement de la France : http://references.modernisation.gouv.fr/interoperabilite
* Principes des standards ouverts du gouvernement du Royaume-Uni : https://www.gov.uk/government/publications/open-standards-principles/open-standards-principles

=== Protocoles au niveau de l'infrastructure réseau ===
{| class="wikitable" border="1"
|-
| '''Couche réseau'''
| IPv4 et IPv6
|-
| '''Téléchargement et téléversement de fichiers'''
| FTP, HTTP, SFTP/SSH
|-
| '''Courriel'''
| POP3, IMAP4, SMTP
|-
| '''Communication en temps réel'''
| SIP
|}

==== Couche réseau ====
{| class="wikitable" border="1"
|-
! Protocole
! 
|-
| '''IPv4'''
| Protocole Internet originel. Les adresses IPv4 sont en voie d'épuisement
IETF RFC 791, mise à jour par les RFC 1349, RFC 2474, RFC 6864
|-
| '''IPv6 (à retenir pour les déploiements futurs)'''
| Nouvelle version du protocole Internet
|}

IPv4 est la version originale du protocole Internet qui forme encore en 2016 la base des communications sur Internet et les réseaux locaux. Toutefois, l'adressage sur 32 bits inclus dans le protocole IPv4 ne permet plus de fournir une adresse unique à tous les utilisateurs d'Internet. Pour cette raison, mais aussi pour mieux intégrer la sécurité et faciliter l'auto-configuration réseau, la nouvelle version du protocole Internet IPv6 a été conçue pour remplacer IPv4.

IPv6 dispose d'un espace d'adressage sur 128 bits, ce qui permet de résoudre le problème d'épuisement d'adresses IP à long terme et d'éviter d'utiliser le NAT ou ''Network Address Translation''.  Même si le NAT permet de faire face à l'épuisement des adresses IPv4 à court et moyen terme, il introduit de nombreuses difficultés dans les applications qui ont besoin d'une connectivité pont à point (ex : Voix et vidéo sur IP, messagerie instantanée, échange de fichiers). De plus, IPv6 fournit les améliorations suivantes en comparaison avec IPv4 :
* L'intégration d'IPsec pour des communications sécurisées. IPsec est utilisable avec IPv4, mais devient intégré dans IPv6.
* Une auto-configuration réseau plus facile

Même si une migration complète vers IPv6 n'est pas envisageable à PCH et ne répond pas directement à la problématique des formats ouverts, il est recommandé de retenir IPv6 pour les futurs déploiements réseau afin de garantir l'interopérabilité de PCH avec les réseaux et applications conçues avec IPv6. En effet, l'ARIN (organisme qui  gère l'attribution des adresses IP en Amérique du Nord), n'a plus d'adresses IPv4 à distribuer depuis septembre 2015<ref>https://www.arin.net/resources/request/ipv4_countdown.html</ref>. Pour cela, PCH doit au moins s'assurer que les tous les nouveaux équipements réseau supportent IPv6. Tous les systèmes d'exploitation modernes comme Windows (depuis Vista), MacOS, GNU/Linux, Android et Blackberry supportent IPv6.

==== Échange de fichiers ====
{| class="wikitable" border="1"
|-
! Protocole
! 
|-
| '''HTTP/1.1'''
'''HTTPS'''
| Protocole de transfert standard pour les pages web. Protocole devenu universel avec la généralisation du web et des applications mobiles.
IETF RFC 7230 à RFC 7237
|-
| '''FTP'''
| Protocole de transfert de fichiers
IETF RFC 959, RFC 3659 et RFC 2640
|-
| '''SFTP (SSH)'''
| Protocole de services réseaux sécurisés tels que le shell (terminal en ligne de commande) et le transfert de fichiers.
IETF RFC 4253
|}

===== HTTP/HTTPS =====
Le protocole HTTP est à privilégier pour le transfert de fichiers, car il ne nécessite pas l'utilisation de logiciels particuliers : un navigateur web suffit. Sa version sécurisée (HTTPS) est recommandée aussitôt qu'un site web nécessite l'envoi d'un mot de passe à des fins d'authentification ou si les fichiers contiennent des données sensibles. L'adoption de HTTP/2 qui est la nouvelle version de ce protocole n'est pas encore recommandée à ce stade : son utilisation sur Internet reste faible (7% des sites web l'utilisent en avril 2016<ref>http://w3techs.com/technologies/details/ce-http2/all/all</ref>) et sa maturité est pour l'instant jugée insuffisante.

Dans un contexte organisationnel comme celui de PCH, le protocole HTTP possède l'avantage d'utiliser une seule connexion TCP vers des ports standards (80 et 443 en général) qui sont généralement déjà permis en sortie par les pare-feu afin d'autoriser la navigation sur le web. Aussi, HTTP traverse bien le NAT, ce qui peut être plus problématique pour les autres protocoles comme FTP.

===== FTP =====
FTP est un protocole conçu pour échanger des fichiers entre clients et serveurs. C'est l'un des plus vieux protocoles Internet encore utilisés, car il prédate TCP/IP. FTP est adapté pour des applications qui nécessitent beaucoup de téléversements de fichiers. Contrairement à HTTP où il faut développer un formulaire/application web de téléversement, un client FTP suffit pour envoyer des fichiers au serveur. Le protocole FTP n'offre pas de sécurité et tous les transferts, y compris l'envoi des mots de passe, se font en clair. On peut dire que le protocole FTP peut être utilisé pour transférer une grande quantité de données qui n'ont pas besoin d'être chiffrées à l'interne, mais il est préférable d'utiliser HTTP/HTTPS pour l'échange de fichiers avec le grand public.

===== SFTP (SSH) =====
Pour les transferts sécurisés à l'interne, notamment ceux impliquant des ordinateurs de type Unix (Ex.: GNU/Linux, FreeBSD, MacOS X, autres systèmes Unix propriétaires comme Solaris, IBM AIX, HP-UX), le protocole SSH est recommandé. Le transfert des fichiers par SSH porte parfois le sigle de SFTP (S pour Sécurisé), mais c'est un protocole complètement différent du protocole FTP régulier. En plus de permettre une administration à distance, ce protocole permet le transfert de fichiers sécurisé et l'établissement de tunnels pour tout type de connexions TCP. Un serveur SSH est installé par défaut sur la plupart des systèmes de type Unix et il existe des clients gratuits pour Windows.

==== Courrier électronique ====
===== Envoi de courriel =====
{| class="wikitable" border="1"
|-
! Protocole
! 
|-
| '''SMTP'''
'''SMTPS'''
| Protocole de transfert de courrier utilisé pour tous les envois de courriels sur Internet. STMPS réfère à l'utilisation du protocole SMTP standard sur une connexion sécurisée par TLS.
IETF RFC 821, RFC 5321
|}

===== Réception de courriel  =====
{| class="wikitable" border="1"
|-
! Protocole
! 
|-
| '''POP3'''
'''POP3S'''
| Protocole de récupération des courriels sur un serveur. Il est possible de le sécuriser par TLS
IETF RFC 1939
|-
| '''IMAP4'''
'''IMAP4S'''
| Protocole de récupération des courriels sur un serveur offrant plus de fonctionnalités que POP3. Il est possible de le sécuriser avec TLS
IETF RFC 4253
|}

===== Format d'archivage  =====
{| class="wikitable" border="1"
|-
! Protocole
! 
|-
| '''Maildir'''
| Format qui utilise le système de fichiers du système d'exploitation pour enregistrer les courriels dans des fichiers séparés
IETF RFC 1939
|}

SMTP est le standard Internet pour l'envoi des courriels et POP3 et IMAP4 sont les standards pour la récupération de courriel et à ce titre, ils sont supportés par tous les clients de messagerie électronique.

PCH a fini de migrer ses courriels d'une solution de IBM (Domino + LotusNotes) vers une solution de Microsoft (Exchange + Outlook). Microsoft Outlook communique avec le serveur Exchange en utilisant le protocole propriétaire MAPI aux lieu des protocoles standards énumérés ci-dessus. Même s'il est possible d'utiliser IMAP4 dans ce scénario, les utilisateurs perdront alors les autres fonctionnalités collaboratives telles que le partage des agendas et des carnets d'adresses. Il n'apparaît donc pas souhaitable d'utiliser IMAP4 pour la configuration des clients Microsoft Exchange.

Il est tout de même envisageable d'utiliser IMAP4 pour l'archivage des courriels. Le serveur Microsoft Exchange enregistre le contenu (y compris les courriels) dans un format propriétaire (EDB) et le client Microsoft Outlook les enregistre dans un format PST. Il existe des logiciels pour extraire les courriels des fichiers EDB vers les fichiers PST et des fichiers PST vers des fichiers EML, mais ce sont des logiciels propriétaires. Il est souhaitable d'extraire tous les courriels importants, dans un format ouvert  afin de s'assurer qu'ils resteront toujours lisibles peu importe les décisions des éditeurs des logiciels propriétaires.

Un serveur d'archivage qui supporte le format Maildir peut être une solution d'archivage. Les courriels seront récupérés du serveur Exchange en utilisant le protocole IMAP4. Ainsi, même si le serveur Exchange n'est plus présent (à cause d'un problème technique ou parce que PCH passerait à une autre solution dans le futur), il sera possible de récupérer les courriels directement. En effet, le format Maildir enregistre chaque courriel dans un fichier à l'intérieur d'une arborescence normale d'un système de fichiers. Dans ce fichier, le contenu du courriel reste au format texte et les pièces jointes sont en base64. Le format Maildir n'est qu'une option d'archivage. Toute solution qui archive les courriels dans un format ouvert est acceptable.

'''Avertissement ''': Microsoft Exchange 2013 ne supporte pas les protocoles standards POP3 et IMAP4 avec la configuration par défaut, mais il est possible de les activer<ref>https://technet.microsoft.com/en-us/library/jj657728(v=exchg.150).aspx</ref>. Si jamais Microsoft abandonne le support de ces protocoles dans Microsoft Exchange, alors ce produit ne répondra plus aux exigences d'interopérabilité définies dans le présent document.

==== Communications en temps réel ====
{| class="wikitable" border="1"
|-
! Protocole
! 
|-
| '''Maildir'''
| Protocole d'initiation de session de la couche applicative initialement destiné à la voix sur IP, mais utilisé également pour la visioconférence, la messagerie instantanée. Il se charge de l'authentification et de la localisation des multiples participants. Il se charge également de la négociation sur les types de médias utilisables par les différents participants.
IETF RFC 3261, RFC 6665 
|}

Il n'y a pas de système de téléphonie uniformisé à PCH. Des téléphones de bureau ont été remplacés par des cellulaires, mais parfois ils ne fonctionnent pas bien à l'intérieur des édifices. Ce n'est pas un problème de format de données, car un système téléphonique ne sert pas à entreposer et à conserver des données, mais cela peut être un problème d'interopérabilité. Un système de téléphonie IP basé sur des standards ouverts comme SIP et des codecs sans brevets permet d'assurer une interopérabilité entre différents types de serveurs et de terminaux (matériels, logiciels, mobiles). Il permet aussi de faciliter l'interopérabilité avec des systèmes téléphoniques externes, mais aussi avec des systèmes de courrier électronique et de collaboration (agendas, messagerie instantanée).

=== Formats de fichiers ===
Le tableau ci-dessous présente les formats de fichiers considérés dans cette étude. '''<span style="color:#FF0000">Les formats marqués en rouge</span>''' ne répondent pas à tous les critères de formats ouverts mais leur description a été incluse ici à cause de leur grande popularité. Si la diffusion dans ces formats peut s'avérer nécessaire par souci d'interopérabilité avec les appareils / logiciels des utilisateurs, il est recommandé de toujours avoir une copie dans un format ouvert. ''Les formats en italique'' sont en fait des formats « conteneurs » : ils ont besoin d'un ou plusieurs codecs pour représenter le contenu sous forme numérique. Dans l'usage courant, on parle cependant de « fichiers MP4, fichiers OGG,... », raison pour laquelle ils ont été inclus parmi les formats.

{| class="wikitable" border="1"
|-
| '''Encodage des caractères'''
| UTF-8
|-
| '''Compression'''
| Bzip2, Gzip, ZIP, 7z/xz, TAR
|-
| '''Bureautique'''
| ODF, <span style="color:#FF0000">OOXML</span>, PDF
|-
| '''Collaboration'''
| vCard, iCalendar
|-
| '''Web'''
| HTML5, CSS3, Javascript, JSON, XML
|-
| '''Images'''
| PNG, JPEG, SVG, ''<span style="color:#FF0000">TIFF</span>''
|-
| '''Audio'''
| ''Opus'', ''OGG/Vorbis'', MP3, FLAC, <span style="color:#FF0000">AAC</span>
|-
| '''Vidéo'''
| ''<span style="color:#FF0000">MP4</span>'', ''MKV'', ''WebM'', ''OGG/Theora'', VP8, VP9, <span style="color:#FF0000">H264</span>
|}

==== Encodage des caractères ====
{| class="wikitable" border="1"
|-
! Format
! 
|-
| '''UTF-8'''
| Codage de caractères informatiques conçu pour coder l'ensemble de tous les systèmes d'écritures et tous les alphabets du monde
IETF RFC 3629
|}

L'encodage UTF-8 permet d'encoder la plupart des systèmes d'écriture existants, notamment les alphabets latins utilisés pour écrire dans les deux langues officielles du Canada, mais aussi les alphabets utilisés pour écrire dans les langues des peuples autochtones comme l'inuktikut. Selon W3Techs, 85% des sites web présents sur Internet utilisent l'encodage UTF-8<ref>http://w3techs.com/technologies/overview/character_encoding/all</ref>. Cet encodage est déjà adopté par PCH comme standard pour les sites web. Le nouveau portail gouvernemental canada.ca utilise également UTF-8. Tous les fichiers textes produits manuellement ou par d'autres applications doivent être également enregistrés en UTF-8 plutôt qu'en ASCII (ou l'une de ses extensions telles qu'ISO 8859-1).

==== Compression ====
{| class="wikitable" border="1"
|-
! Format
! 
|-
| '''BZIP2'''
| bzip2 permet en général de compresser les fichiers de façon plus efficace que zip ou gzip au détriment de la vitesse de compression.
Voir http://www.bzip.org/
|-
| '''GZIP'''
| GZIP est un format de compression basé sur l'algorithme deflate très utilisé dans les systèmes d'exploitation libres comme GNU/Linux. 
IETF RFC 1952
|-
| '''ZIP'''
| Permet de compresser un ensemble de fichiers dans un seul fichier (archive compressée). C'est le format utilisé dans les formats bureautiques Open Document.
Spécification du format sur le site de PKWARE :
https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT
|-
| '''7z / xz'''
| Format de fichiers compressés qui peuvent utiliser l'algorithme LZMA. Offre un meilleur taux de compression que gzip ou bzip2.
Informations sur le format : http://www.7-zip.org/sdk.html
|-
| '''TAR'''
| TAR est un standard Unix pour créer des fichiers archive qui peuvent être compressés par gzip, bzip2 ou LZMA
IEEE POSIX.1-2001
|}

La plupart des formats de compression utilisés couramment sont ouverts, donc il n'y a pas de risque de problème d'interopérabilité à ce niveau. Il faut tout de même éviter les formats propriétaires qui existent encore comme RAR. Le choix entre les formats présentés ci-dessus peut être guidé par le choix entre un taux de compression maximal, le temps de compression et de décompression, ainsi que l'utilisation de la mémoire. Par exemple l'algorithme LZMA utilisé par les formats 7z et xz offre un taux de compression supérieur à bzip2 (qui lui même en général compresse plus que gzip), mais au détriment du temps de compression. Par contre, le temps de décompression d'un fichier compressé par LZMA se trouve entre les temps affichés par gzip et bzip2. Gzip offre l'avantage d'utiliser moins de mémoire, ce qui est important dans certaines applications<ref>http://tukaani.org/lzma/benchmarks.html</ref>.

==== Web ====
{| class="wikitable" border="1"
|-
! Format
! 
|-
| '''HTML5'''
| Langage spécifiquement conçu pour la création des pages web.
Spécification du W3C : http://www.w3.org/TR/html5/ 
|-
| '''JavaScript'''
| JavaScript est un langage de programmation de scripts principalement employé dans les pages web interactives mais aussi pour les serveurs 
ECMA-262 ISO/CEI 16262
|-
| '''CSS'''
| CSS est un langage informatique qui décrit la présentation des documents HTML et XML. La version 3 ou supérieure est à privilégier.
Spécifications du W3C http://www.w3.org/Style/CSS/current-work 
|-
| '''JSON'''
| JSON est un format de données textuelles dérivé de la notation des objets du langage JavaScript.
IETF RFC 7159
|-
| '''XML'''
| Langage de marquage extensible conçu pour faciliter l'échange automatisé de contenus complexes
Spécification du W3C : http://www.w3.org/TR/2008/REC-xml-20081126/ 
|}

PCH a déjà adopté des standards web, notamment en utilisant le Boîte à Outils de l'Expérience Web (BOEW) ou le ''Web Experience Toolkit'' (WET) en anglais. C'est<ref>http://wet-boew.github.io/v4.0-ci/index-fr.html</ref> :
* Une bibliothèque de code primée pour construire des sites Web accessibles, faciles d'emploi, interopérables, optimisés pour les appareils mobiles et multilingues.
* Des modèles, ainsi que des composants réutilisables, qui sont flexibles et personnalisables
* Un projet logiciel libre collaboratif dirigé par le Secrétariat du Conseil du Trésor du Canada

WET-BOEW est conçu autour de HTML5, JavaScript et CSS3 afin d'assurer l'interopérabilité avec les différentes plate formes et navigateurs, y compris les périphériques mobiles tels que les téléphones intelligents et les tablettes. C'est aussi l'une des raisons pour lesquelles les formats PDF et Flash ont été écartés : l'affichage peut ne pas être très lisible sur les appareils mobiles ou parfois ne fonctionne pas du tout.

==== Bureautique ====
{| class="wikitable" border="1"
|-
! Format
! 
|-
| '''ODF (version≥1.2)'''
| Open Document Format est un format ouvert de données pour les applications bureautiques : traitements de texte, tableurs, présentations, diagrammes, dessins et base de données bureautique. Open Document Format est la désignation d'usage d'une norme dont l'appellation officielle est OASIS Open Document Format for Office Applications, également abrégée par le sigle ODF
Spécification OASIS : http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2.html 
ISO/IEC 26300-1:2015, ISO/IEC 26300-2:2015, ISO/IEC 26300-3:2015
|-
| '''<span style="color:#FF0000">OOXML</span> (déconseillé)'''
| Office Open XML est une norme ISO/CEI 29500 créée par Microsoft entre autres pour concurrencer le format ODF. Il utilise les suffixes .docx, .xlsx, .pptx… Seule la suite Microsoft Office à partir de la version 2013 est totalement compatible avec la norme (en lecture et en écriture).
ISO/IEC 29500:2008-2012 http://www.iso.org/iso/catalogue_detail.htm?csnumber=61750 (le téléchargement de la norme nécessite un paiement)
|-
| '''PDF (version≥1.7)'''
| La spécificité du PDF est de préserver la mise en forme d'un fichier telle qu'elle a été définie par son auteur, et ce quels que soient le logiciel, le système d'exploitation et l'ordinateur utilisés pour l'imprimer ou le visualiser. 
Tous les logiciels ne produisent pas des fichiers PDF strictement conformes à la norme ISO  32000-1:2008.
|}

===== ODF =====
La liste de vérification de publication sur Intranet de PCH préconise l'utilisation des formats Word, Excel et PDF, mais n'indique pas le format exact à utiliser. La collecte des informations à PCH a permis de comprendre que c'est le format par défaut OOXML qui est utilisé. Bibliothèque et Archive Canada liste les formats ODF parmi les formats favorisés tandis que le format OOXML est listé comme acceptable<ref>http://www.bac-lac.gc.ca/fra/services/gestion-ressources-documentaires-gouvernement/lignes-directrices/Pages/lignes-directrices-formats-fichier-transferers-ressources-documentaires.aspx</ref>. ODF est également le format préféré dans le cadre commun d'interopérabilité du gouvernement du Québec. Enfin, ce format a été choisi par le gouvernement du Royaume-Uni pour tous les documents bureautiques éditables<ref>https://www.gov.uk/guidance/open-document-format-odf-guidance-for-uk-government</ref>. Quels sont les avantages du format ODF par rapport au format OOXML ?<ref>http://www.opendocumentformat.org/features</ref> :
* Pris en charge par les suites bureautiques les plus populaires comme Microsoft Office 2013 et LibreOffice (cette dernière est libre et gratuite, un utilisateur n'est donc pas obligé d'acheter une licence pour visualiser et éditer des documents ODF);
* Développé et maintenu par un organisme indépendant à but non lucratif (OASIS) plutôt que par une seule entreprise privée;
* Le contenu (images, vidéos, etc.) est directement accessible, il est alors facile d'y accéder avec des outils externes à l'application bureautique;
* Basé sur le format XML : facilite le traitement et l'extraction automatique si nécessaires, c'est également un format lisible par l'homme ;
* Un document ODF est un fichier ZIP qui contient plusieurs fichiers XML : possible d'accéder le contenu directement en cas d'application défaillante. Cela réduit le risque de corruption et de perte totale de contenu suite à d'éventuels bogues applicatifs;
* Meilleure accessibilité (pour personnes handicapées);
* Le format étant indépendant d'une suite bureautique, il est possible d'utiliser n'importe laquelle le prenant en charge.

Par ailleurs, le format Office Open XML a été critiqué pour sa complexité (la spécification est 7 fois plus longue que celle pour ODF) et le manque d'ouverture dans son élaboration (étant une initiative de Microsoft).

Puisque PCH utilise déjà Microsoft Office, il est souhaitable d'utiliser le format ODF comme format par défaut afin d'assurer l'interopérabilité avec d'autres logiciels bureautiques (que ce soit à l'extérieur de PCH ou dans le cas où PCH utilisera une autre suite bureautique dans le futur). Cela ne nécessite pas d'installer des logiciels différents ou de former les utilisateurs à une nouvelle façon d'utiliser un logiciel existant. Il faut toutefois s'assurer que c'est la version 2013 de Microsoft Office qui est installée. Les versions antérieures de Microsoft Office ne supportent pas ODF 1.2.

Toutefois, comme indiqué par le cadre commun d'interopérabilité du gouvernement du Québec, « les nouvelles polices de Microsoft dont le nom commence par un C (Calibri, Cambria, Candara, Consolas, Constantia et Corbel), doivent être évitées au niveau du traitement du texte puisqu'elles sont soumises à une licence qui en permet l'affichage seulement avec la suite Microsoft Office. Dans ce cas, des polices libres ne peuvent pas en émuler l'aspect et tous les documents utilisant ces polices seraient mal affichés ce qui causera un problème d'interopérabilité. »<ref>http://www.tresor.gouv.qc.ca/fileadmin/PDF/ressources_informationnelles/architecture_entreprise_gouvernementale/AEG_3.1-CCIGQinteroperabilite.pdf</ref>

Le format OpenDocument regroupe les formats suivants (avec les extensions de documents associées) :
{| class="wikitable" border="1"
|-
! Type de fichier
! Extension
|-
| '''Texte formaté'''
| .odt
|-
| '''Tableur'''
| .ods
|-
| '''Présentation'''
| .odp
|-
| '''Dessin'''
| .odg
|-
| '''Diagramme'''
| .odc
|-
| '''Formule'''
| .odf
|-
| '''Base de données'''
| .odb
|-
| '''Image'''
| .odi
|-
| '''Document principal'''
| .odm
|}

===== PDF =====
Le format PDF permet de visualiser un document dans n'importe quel environnement en respectant son formatage d'origine. C'est la raison pour laquelle les documents au format PDF doivent être conformes à la norme, sinon ils ne pourraient être affichés et édités que dans les logiciels Adobe. Ce problème existe déjà à PCH, notamment avec l'affichage des fichiers PDF par les lecteurs intégrés dans certains navigateurs. Le même problème est rencontré avec d'autres formulaires PDF produits par le gouvernement du Canada qui nécessitent l'installation d'un logiciel propriétaire (Adobre Reader, dont les dernières versions ne sont plus disponibles pour GNU/Linux).

Si le format PDF était dans les précédentes versions non éditable, il existe maintenant plusieurs logiciels qui permettent de retravailler les documents soit sous forme hybride (LibreOffice) soit en éditant le PDF (Inskape, Xournal).

==== Collaboration ====
{| class="wikitable" border="1"
|-
! Format
! 
|-
| '''vCard'''
| Format ouvert  d'échange des données personnelles (notamment pour les cartes d'affaires électroniques)
IETF RFC6350 , RFC6868
|-
| '''iCalendar (iCal)'''
| Standard pour la représentation et les échanges de données de calendrier qui définit la structuration des données dans un fichier ics.
IETF RFC 5545, RFC6868
|}

L'utilisation des formats vCard et iCal permet d'assurer l'interopérabilité avec de nombreux logiciels de courrier électronique et de collaboration, aussi bien du côté client que du côté serveur.

==== Multimédia ====
Cette section présente les formats de fichier image, audio et vidéo.

===== Images =====
{| class="wikitable" border="1"
|-
! Format
! 
|-
| '''JPEG'''
| Ce format conçu pour la photographie numérique permet de compresser les images pour réduire l'espace disque et la bande passante utilisée, mais entraîne des pertes d'information. Il est possible de choisir entre un taux de compression plus grand et une meilleure qualité de l'image. Ce format est supporté par la plupart des appareils photo numériques.
Spécification du W3C : http://www.jpeg.org/jpeg/workplan.html 
ISO/CEI 10918-1 
ITU-T Recommendation T.81 http://www.w3.org/Graphics/JPEG/itu-t81.pdf 
|-
| '''PNG'''
| Ce format utilise une compression sans perte et il est adapté pour les graphismes destinés au Web comme les logos, les icônes, les images représentant du texte et les images contenant des dégradés. 
IETF RFC 2083
|-
| '''TIFF'''
| Tagged Image File Format : c'est un conteneur qui peut contenir des images compressées ou non.
Spécification de Adobe : http://partners.adobe.com/public/developer/tiff/index.html 
|-
| '''SVG'''
| (Scalable Vector Graphics) est un format graphique vectoriel basé sur le XML. Le format permet l'intégration d'animations.
Spécification du W3C : http://www.w3.org/Graphics/SVG/ 
|}

La liste de vérification pour la publication sur l'Intranet de PCH précise que les photographies doivent être au format JPEG qui est un format ouvert. L'équipe de communication a également des directives concernant la résolution et la taille des images, mais pas de directives sur les formats des fichiers. Le format SVG ne semble pas être utilisé.

Le format SVG est recommandé pour les graphismes web qui sont susceptibles d'être redimensionnés : il n'est plus nécessaire de préparer plusieurs images de résolution différentes pour les différentes tailles d'écran. Les navigateurs modernes supportent SVG<ref>http://caniuse.com/#feat=svg</ref>, mais il est possible de prévoir une copie en PNG si on veut supporter les anciennes versions des navigateurs.

Le format GIF ne supporte qu'une palette de 256 couleurs. Il est donc préférable d'utiliser le format PNG à la place de GIF. Contrairement au format JPEG, le format PNG utilise une compression sans perte, donc il est plus adapté que le format JPEG pour enregistrer des schémas, des diagrammes et d'autres graphismes où la compression à perte de JPEG entraîne une perte de lisibilité.

Le format TIFF de base (« baseline TIFF ») n'utilise pas de compression et produit par conséquent des fichiers volumineux. La spécification appartient à Adobe, donc ce n'est pas un format ouvert strictement parlant, mais il n'est pas nécessaire de payer des royautés pour s'en servir. Ce format est souvent utilisé pour archiver des images numérisées de haute qualité ce qui explique son inclusion dans ce rapport sur l'interopérabilité. Son utilisation n'est toutefois pas répandue sur Internet. Il est possible d'utiliser la compression LZW avec le format TIFF, les brevets concernés ayant expiré depuis quelques années. Toutefois, il est préférable d'utiliser le format ouvert PNG lorsque la compression sans perte est nécessaire et s'il faut utiliser une compression à perte pour réduire davantage la taille des fichiers, il est préférable d'utiliser le format ouvert JPEG.

===== Audio =====
{| class="wikitable" border="1"
|-
! Format
! 
|-
| '''''OGG'''''
| C'est un conteneur multimédia qui peut contenir des pistes audio, vidéo et texte. C'est un format libre et dégagé de tout brevet.
Spécification de la fondation xiph.org http://www.xiph.org/ 
|-
| '''VORBIS'''
| Codec audio ouvert et libre et sans brevet. Utilisé avec le conteneur OGG.
IETF RFC 2083
|-
| '''FLAC'''
| Free Lossless Audio Codec : format de compression audio sans perte. 
Spécification de la fondation xiph.org : https://xiph.org/flac
|-
| '''<span style="color:#FF0000">MP3</span>'''
| Format de compression audio (avec perte) le plus populaire. Il est toutefois à éviter pour la conservation du patrimoine musical et autre enregistrement sonores, car il est soumis à des brevets.
ISO/CEI IS 11172-3 et ISO/CEI IS 13818-3 
|-
| '''<span style="color:#FF0000">AAC</span>'''
| Format de compression audio avec perte qui permet en général une meilleure qualité que le format MP3. Il n'y a pas de frais pour la distribution et la diffusion du contenu en AAC, mais des frais liés aux brevets pour la production et le développement de codecs AAC.
ISO/IEC 13818-7 et ISO/IEC 14496-3
|-
| '''Opus'''
| Codec ouvert conçu pour les applications interactives en temps réel sur Internet
IETF RFC 6716
|}

Le format ouvert FLAC est recommandé pour conserver les séquences audio, la musique, etc. dans leur qualité originale. Ogg Vorbis est le format ouvert recommandé lorsque la compression est nécessaire, notamment pour offrir des téléchargements de fichiers audio sur Internet. MP3 n'est pas un format ouvert, mais sa popularité fait en sorte qu'il peut être nécessaire de produire des fichiers MP3 si on veut qu'ils soient lisibles sur tous les appareils. Dans ce cas, il est souhaitable d'avoir une autre copie du fichier dans un format ouvert.

===== Vidéo =====
{| class="wikitable" border="1"
|-
! Format
! 
|-
| '''''<span style="color:#FF0000">MP4</span>'''''
| Format de conteneur pour du contenu audio et vidéo basé sur le format QuickTime. Il est habituellement utilisé avec le codec H.264 pour la vidéo et AAC pour l'audio.
ISO/CEI 14496-14
|-
| '''''OGG'''''
| C'est un conteneur multimédia qui peut contenir des pistes audio, vidéo et texte. C'est un format libre et dégagé de tout brevet.
Spécification de la fondation xiph.org http://www.xiph.org
|-
| '''<span style="color:#FF0000">H.264</span>'''
| Codec vidéo couramment utilisé avec le format MP4. Contient des technologies brevetées.
ISO/CEI 14496-10, UIT-T H.264
|-
| '''''Matroska (MKV)'''''
| Format de conteneur libre et ouvert qui peut contenir de l'audio, des vidéos et du texte. 
Spécifications : http://matroska.org/technical/specs/index.html
|-
| '''WebM'''
| Format ouvert basé sur Matroska et destiné au web (fait partie des formats proposés pour le support vidéo dans HTML5). WebM permet la combinaison des codecs suivante :
Les combinaisons de codecs suivantes :
* VP8 et Vorbis
* VP9 et Opus, ou, VP9 et Vorbis
Ces formats, ainsi que H.264, sont supportés par le lecteur vidéo HTML5 de YouTube<ref>http://www.youtube.com/html5</ref>
|-
| '''Theora'''
| Codec vidéo libre non encombré par des brevets. Utilisé avec le conteneur OGG.
Spécification du W3C : http://www.w3.org/Graphics/SVG/ 
|-
| '''VP8'''
| Codec vidéo rendu ouvert par Google
IETF RFC 6386
|-
| '''VP9'''
| Codec vidéo ouvert et libre de droits développé par Google
https://www.webmproject.org/vp9
|}

En ce moment, il y a une préférence pour le format propriétaire de création vidéo de Adobe à PCH (plus facile de l'éditer ensuite) même si les autres formats comme MP4/H.264, QuickTime, MKV sont acceptés pour la réception des vidéos. 
Il est recommandé d'utiliser des codecs ouverts et non encombrés par des brevets comme VP8 et VP9 pour la vidéo et Vorbis/FLAC/Opus pour l'audio afin de garantir la pérennité du patrimoine vidéo enregistré au format numérique. Si le format d'Adobe est nécessaire pour l'édition, il faut s'assurer de garder une copie des vidéos importantes dans un format ouvert. Ainsi, elles pourront être consultées même si le logiciel de Adobe n'est pas disponible.

=== Résumé des recommandations ===
Voici un tableau récapitulatif des protocoles et formats discutés dans ce document. Les formats qui apparaissent en rouge ne sont pas ouverts, mais leur popularité nécessite que PCH puisse les utiliser par souci d'interopérabilité. Il est toutefois recommandé de toujours privilégier les formats ouverts lorsque c'est possible.

==== Protocoles réseau ====
{| class="wikitable" border="1"
|-
| '''Réseau'''
| IPv4, IPv6
|-
| '''Téléchargement et téléversement de fichiers'''
| FTP, HTTP, SFTP (SSH)
|-
| '''Courriel'''
| POP3, IMAP4, SMTP
|-
| '''Communication en temps réel'''
| SIP
|}



==== Formats de fichiers ====
{| class="wikitable" border="1"
|-
| '''Encodage des caractères'''
| UTF-8
|-
| '''Compression'''
| Bzip2, Gzip, ZIP, 7z/xz, TAR
|-
| '''Bureautique'''
| ODF, <span style="color:#FF0000">OOXML</span>, PDF
|-
| '''Collaboration'''
| vCard, iCalendar
|-
| '''Web'''
| HTML5, CSS3, Javascript, JSON, XML
|-
| '''Images'''
| PNG, JPEG, SVG, ''<span style="color:#FF0000">TIFF</span>''
|-
| '''Audio'''
| ''Opus'', ''OGG/Vorbis'', MP3, FLAC, <span style="color:#FF0000">AAC</span>
|-
| '''Vidéo'''
| ''<span style="color:#FF0000">MP4</span>'', ''MKV'', ''WebM'', ''OGG/Theora'', VP8, VP9, <span style="color:#FF0000">H264</span>
|}

PCH utilise déjà plusieurs standards énumérés ci-dessus, mais doit porter une attention particulière sur ces cas d'utilisation des protocoles et formats commerciaux :
* Utilisation de Microsoft Exchange et de Microsoft Outlook avec le protocole MAPI pour la messagerie électronique. Il faut s'assurer que les courriels soient archivés dans un format ouvert. L'activation du protocole IMAP4 permet d'installer un serveur d'archivage (par exemple au format Maildir).
* Utilisation du format OOXML pour la bureautique avec Microsoft Office. Il est préférable d'utiliser le format ODF comme format par défaut surtout que les dernières versions de Microsoft Office supportent ce format.
* Utilisation de formats propriétaires pour l'édition vidéo : si l'utilisation de ces logiciels est indispensable, il faut s'assurer de garder des copies dans un format ouvert.
* Utilisation du format PDF non standard : il faut enregistrer les documents aux formats PDF standard (ISO) sans les extensions propriétaires de Adobe ou utiliser un autre format.
* Pas de standardisation de la téléphonie. Si une nouvelle solution de téléphonie est envisagée dans les bureaux de PCH, il est préférable de standardiser autour d'un protocole ouvert comme SIP.

== Analyse des impacts d'un cadre d'interopérabilité à PCH ==
Dans le contexte de PCH, la mise en place d'un cadre d'interopérabilité basé sur des standards ouverts permettrait de garantir que tous les individus aient accès aux données, informations et services offert par l'organisation, cela sans limite technologique ni obligation d'accéder à des technologies payantes.  D'un point de vue interne, l'interopérabilité est étroitement liée à la question de l'architecture d'entreprise, en permettant le découplage de ses différentes composantes logicielles tout en conservant leur intégration. L'interopérabilité technique n'est possible qu'avec l'utilisation des standards ouverts.  Les avantages des standards ouverts ont été déjà évoqués dans la deuxième section du présent rapport.

Plus spécifiquement, voici les impacts immédiats de l'adoption d'un cadre d'interopérabilité à PCH :
* Revue de la configuration des logiciels existants pour utiliser les standards ouverts lorsque possible.
** Office 2013 peut être configuré pour sauvegarder en utilisant les formats ODF et pour générer des PDF standards;
* Mise à jour des procédures et des directives pour la sélection et l'utilisation des formats de fichiers;
* Changement des procédures de sélection des logiciels pour tenir compte du cadre d'interopérabilité. Ceci inclus les solutions sélectionnées par les équipes d'architecture et d'ingénierie des postes de travailles;
** Les logiciels qui supportent pleinement les standards ouverts sont favorisés;
** Il faut s'assurer d’inclure les coûts de sortie et de migration dans l'évaluation du coût total d'un logiciel;
* Sensibilisation des employés à la problématique d'interopérabilité et des standards ouverts. Il est important que les employés ne perçoivent pas les politiques et directives d'interopérabilité comme juste une autre exigence administrative qui les dérangera dans leur travail.

Plus à long terme, l'adoption d'un cadre d'interopérabilité basé sur des standards ouverts à PCH permet d'éviter les coûts de l'enfermement commercial (appelé ''vendor lock-in'' dans la littérature en anglais) et de rendre l'architecture d'entreprise plus flexible.  En effet, l'utilisation de formats standards, l'indépendance et la substituabilité des solutions permet le remplacement d'une composante ou système par un autre à coût moindre qu'avec des formats propriétaires.  On évite les problèmes liée à l'adhérence applicative puisque chaque système doit pouvoir communiquer à travers des interfaces utilisant des standards ouverts. Ceci inclut les systèmes infonuagiques, qui malgré qu'ils ne soient pas hébergés sur l'infrastructure de PCH, peuvent facilement être réinternalisés ou changés d'hébergeur que ce soit avec Services Partagées ou un autre fournisseur.

L'utilisation des standards ouverts par PCH facilitera la publication des données ouvertes lorsque ce sera nécessaire. PCH n'aura plus besoin alors de convertir ces données d'un format restrictif vers un format ouvert avant de les publier sur le portail des données ouvertes.

Puisque Services Partagées Canada et le Secrétariat de Conseil du trésor s'intéresse peu aux questions autour de l'interopérabilité et des standards ouverts, à l'exception des données ouvertes; PCH pourrait être aux premières loges pour le développement d'un cadre d'interopérabilité technique interne pour le Gouvernement du Canada.

== Conclusion ==
Ce rapport avait pour objectif d'introduire le concept d'interopérabilité technique à PCH. La définition suivante de l'interopérabilité a été retenue : « L'interopérabilité est la capacité que possède un produit ou un système, dont les interfaces sont intégralement connues, à fonctionner avec d'autres produits ou systèmes existants ou futurs, et ce sans restriction d'accès ou de mise en œuvre. » L'exigence des interfaces connues a permis de présenter les standards ouverts avec une définition basée sur les référentiels d'interopérabilité québécois, européen, français et britannique. Les standards ouverts se caractérisent donc par :
* L'ouverture du processus de développement du standard à toutes les parties prenantes et sa transparence;
* Des droits de propriétés intellectuelle permettant l'implémentation du standard dans tout type de logiciel (logiciels libres comme propriétaires);
* La disponibilité de la spécification à coût nul ou marginal.

Les avantages des TI interopérables ont été ensuite présentées, comme une plus grande indépendance vis-à-vis des fournisseurs et une plus grande flexibilité dans la conception et l'évolution de l'architecture d'entreprise. Plusieurs sujets connexes ont été également abordés dans ce rapport, à savoir la sécurité, la pérennité des données et l'interopérabilité dans le cadre d'infrastructures TI infonuagiques.

Enfin, les standards ouverts applicables à PCH ont été présentés : il s'agit de protocoles réseau et de format de fichiers (comme par exemple pour la bureautique et le multimédia). PCH utilise déjà beaucoup de formats ouverts mais il y a des ajustements à faire notamment en ce qui concerne les formats bureautiques et multimédia.

Ce rapport constitue donc un premier pas vers l'interopérabilité à PCH. Une implication de tout le personnel sera nécessaire pour rendre effective la mise en place du cadre d'interopérabilité, et ce, aussi bien au niveau technique que procédural. Pour profiter pleinement des avantages de l'interopérabilité, celle-ci doit toutefois à s'étendre à l'échelle du gouvernement du Canada et ne pas se faire individuellement dans chaque ministère.

==References==
<references/>

[[Category:PCH]]
[[en:Elements_of_a_Technical_Interoperability_Framework_for_Canadian_Heritage]]