Rémy Marchand : Standards ouverts, Open Source, Interopérabilité

Commençons pas les standards ouverts. Il n’existe pas d’accord universel quant à leur définition. Les adresses suivantes recensent de nombreuses acceptions du terme Open Standard ou Standard ouvert. http://en.wikipedia.org/wiki/Open_standard http://xml.coverpages.org/openStandards.html Nous n’allons pas examiner toutes ces définitions et nous retiendrons celles qui présentent un intérêt plus spécial du point de vue des systèmes d’échanges électroniques entre les organisations. Mentionnons à ce sujet qu’il existe des standards ouverts qui spécifient des formats, ce qui est bien le cas dans les échanges électroniques pour lesquels on définit le Vue Opérationnelle des Affaires comme y invite le modèle conceptuel pour l’EDI ouvert. En effet, pour que deux entités puissent échanger des informations susceptibles d’être traitées par des applications de part et d’autre, il faut bien définir un processus public, s’accorder sur les formats des documents échangés, sur l’ordre suivant lequel s’exécutent les conversations électroniques qui dépend de l’état respectif des systèmes d’information des partenaires : je reçois une commande, ma réponse dépendra de mes stocks et de mes productions en cours etc.. Ceci ayant été dit, il nous faut bien une définition de standards ouvert et nous avons donc fait un choix orienté par le sujet qui nous intéresse ici, à savoir les systèmes d’échanges électroniques d’informations structurées. Cette définition est celle de Bruce Perrens, par ailleurs bien connu pour son engagement envers les logiciels Open Source.

Cette définition considère qu’un standard est ouvert s’il a les caractéristiques suivantes : 1. Disponible pour quiconque veut le consulter et l’implémenter. Cette disponibilité doit être totale. Si – par exemple – on masque certains composants d’un standard, par exemple les codes des valeurs acceptables pour une donnée, cela ne permet pas de qualifier de standard ouvert une publication ainsi amputée d’informations indispensables en vue d’une implémentation. 2. Maximiser le choix de l’utilisateur : il s’agit de créer un marché concurrentiel, loyal et équitable pour ceux qui entendent implémenter le standard. Le client ne doit pas être à la merci d’un groupe ou d’un vendeur ou d’un service particulier. Il arrive hélas que le modèle économique soit invoqué pour justifier la création d’un service monopolistique, mais en ce cas des contrôles sont à prévoir pour ne pas faciliter la constitution de rentes. 3. Pas de Royalties : Les standards ouverts sont gratuits pour ceux qui veulent les implémenter et aucun paiement pour les obtenir ou les utiliser n’est à acquitter. En revanche la certification de conformité – assurée par des bancs de tests – est légitimement payante mais là encore il ne doit pas être crée d’obstacles dirimants tels que des coûts de certification de conformité prohibitifs. Ajoutons que dans le cas des systèmes d’échange la certification de conformité ne suffit pas. Il faut y ajouter une certification d’interopérabilité qui associe deux ou n implémentations devant échanger des formats communs. 4. Absence de discrimination: Les standards ouverts et les organisations qui les développent et les administrent ne doivent favoriser aucun implémenteur si ce n’est pour attester qu’une implémentation est certifiée en conformité avec le standard, ce qui ne constitue aucunement une discrimination mais la reconnaissance d’un fait porteur d’avantages tant pour l’implémenteur que pour son client. Les activités de certification de base doivent être aussi peu coûteuses que possible, mais il est admissible d’organiser des activités de certification assorties de tests de performance qui deviennent alors plus complexes et donc légitimement plus coûteuses. 5. Extension ou Restrictions : Les implémentations de standards ouverts peuvent être étendues par ajout de fonctionnalités aux standard ou au contraire être proposées en tant que réalisation simplifiée, en relation avec un profil restreint du standard. Cependant des implémentations partielles d’un standard peuvent se voir refuser leur certification tandis que des exigences peuvent être faites à l’endroit des extensions qui font l’objet du 6. 6. Interdiction des pratiques de prédateur : Les standards ouverts peuvent utiliser (inclure) des formulations qui protègent contre des manoeuvres de subversions employant des tactiques d’enveloppement-extension (embrace-and-extend tactics telles que celles dont Internet fit l’objet). Les licenses attachées au standard peuvent requérir la publication des informations de référence d’une extension afin de permettre à des tiers de créer, distribuer et vendre des solutions elles aussi compatibles avec une extension. A cette exception près, un standard ouvert ne doit pas interdire des extensions. Signalons enfin que de nombreux organismes de standardisation, et notamment IETF, ISO, IEC, ITU-T, OASIS autorisent les titulaires de brevets à imposer des royalties à des conditions raisonnables et non discriminatoires.

Venons-en aux logiciels Open Source dont Wikipedia donne la définition : « La désignation open source (au Québec : « code source libre ») s’applique aux logiciels dont la licence respecte des critères précisément établis par l’ Open Source Initiative, c’est-à-dire la possibilité de libre redistribution, d’accès au code source et de travaux dérivés. Souvent, un logiciel libre est qualifié d’« open source », car les licences compatibles open source englobent les licences libres selon la définition de la FSF Free Software Foundation. Le terme open source est en concurrence avec le terme « free software » recommandé par la FSF. Le terme « freeware » ou gratuiciel désigne des logiciels gratuits qui ne sont ni nécessairement ouverts, ni libres ».

Venons-en maintenant à l’interopérabilité dans un contexte d’échanges électroniques inter organisations. Elle ne peut résulter que de standards ouverts au moins tant qu’on veut inscrire un système dans un cadre de réseau ouvert d’organisations en situation d’échange. Pour être ouverts ces réseaux doivent être en mesure d’accueillir toute organisation souhaitant faire part du réseau en y participant à sa façon. Dans ce cas particulier, les standards ouverts définissent des processus publics qui s’exécutent dans des environnements d’exploitation qui peuvent très différents auxquels peuvent correspondre des urbanisations de systèmes d’information fort variées. Les processus publics constituent la figure imposée que des processus de traitement privés doivent exécuter. Ces processus consistent à échanger des e-Documents dans le cadre de séquences d’échanges constituant un processus de bout en bout, lequel se déroule suivant une chorégraphie prédéterminée par les standards ouverts. Compte tenu de l’exécution identique des processus publiques par tous les partenaires d’un réseau d’échanges il y a bien entendu grand cas à faire des solutions open source qui permettent une fois pour toutes de développer les outils qui seront mis à profit par tous ces partenaires, à charge pour chacun de définir les correspondances entre ses processus privés et le processus publique agréé par ses partenaires. N’oublions pas que les processus d’échange requièrent non seulement la définition de standards ouverts concernant la Vue Opérationnelle des Affaires mais aussi la définition de standards ouverts pour la définition des protocoles fiables de télécommunication et les services d’authentification, de cryptage, de non répudiation (Vue Fonctionnelle des Services). Dans tous les cas l’usage de standards ouverts et de logiciels open source est fort utile et permet de réaliser des économies d’échelle très importantes. L’utilisation de gratuiciels pourrait être utile car préservant l’intégrité des solutions et évitant les ruptures d’inter opérabilité (puisque le code source n’est pas révélé) mais elle ne permet alors ni de disposer des moyens de tenir compte facilement des obligations d’interfacer processus publics et processus privés, ni de la nécessité de tenir compte des évolutions qu’impose la vie économique, car on ne peut figer les systèmes d’échanges ni ignorer qu’une entreprise appartiendra souvent à plusieurs réseaux ou communautés d’intérêt. Les solutions Open Source sont donc – dans ce cas particulier des systèmes d’échanges inter organisations – une contribution de premier plan à l’économie des déploiements mais l’intérêt d’une discipline dans les évolutions des solutions doit être bien compris, faute de quoi des brèches d’inter opérabilité pourront apparaitre.

Tagged:

Comments are closed.

Rémy Marchand : Standards ouverts, Open Source, Interopérabilité

Commençons pas les standards ouverts. Il n’existe pas d’accord universel quant à leur définition. Les adresses suivantes recensent de nombreuses acceptions du terme Open Standard ou Standard ouvert. http://en.wikipedia.org/wiki/Open_standard http://xml.coverpages.org/openStandards.html Nous n’allons pas examiner toutes ces définitions et nous retiendrons celles qui présentent un intérêt plus spécial du point de vue des systèmes d’échanges électroniques entre les organisations. Mentionnons à ce sujet qu’il existe des standards ouverts qui spécifient des formats, ce qui est bien le cas dans les échanges électroniques pour lesquels on définit le Vue Opérationnelle des Affaires comme y invite le modèle conceptuel pour l’EDI ouvert. En effet, pour que deux entités puissent échanger des informations susceptibles d’être traitées par des applications de part et d’autre, il faut bien définir un processus public, s’accorder sur les formats des documents échangés, sur l’ordre suivant lequel s’exécutent les conversations électroniques qui dépend de l’état respectif des systèmes d’information des partenaires : je reçois une commande, ma réponse dépendra de mes stocks et de mes productions en cours etc.. Ceci ayant été dit, il nous faut bien une définition de standards ouvert et nous avons donc fait un choix orienté par le sujet qui nous intéresse ici, à savoir les systèmes d’échanges électroniques d’informations structurées. Cette définition est celle de Bruce Perrens, par ailleurs bien connu pour son engagement envers les logiciels Open Source.

Cette définition considère qu’un standard est ouvert s’il a les caractéristiques suivantes : 1. Disponible pour quiconque veut le consulter et l’implémenter. Cette disponibilité doit être totale. Si – par exemple – on masque certains composants d’un standard, par exemple les codes des valeurs acceptables pour une donnée, cela ne permet pas de qualifier de standard ouvert une publication ainsi amputée d’informations indispensables en vue d’une implémentation. 2. Maximiser le choix de l’utilisateur : il s’agit de créer un marché concurrentiel, loyal et équitable pour ceux qui entendent implémenter le standard. Le client ne doit pas être à la merci d’un groupe ou d’un vendeur ou d’un service particulier. Il arrive hélas que le modèle économique soit invoqué pour justifier la création d’un service monopolistique, mais en ce cas des contrôles sont à prévoir pour ne pas faciliter la constitution de rentes. 3. Pas de Royalties : Les standards ouverts sont gratuits pour ceux qui veulent les implémenter et aucun paiement pour les obtenir ou les utiliser n’est à acquitter. En revanche la certification de conformité – assurée par des bancs de tests – est légitimement payante mais là encore il ne doit pas être crée d’obstacles dirimants tels que des coûts de certification de conformité prohibitifs. Ajoutons que dans le cas des systèmes d’échange la certification de conformité ne suffit pas. Il faut y ajouter une certification d’interopérabilité qui associe deux ou n implémentations devant échanger des formats communs. 4. Absence de discrimination: Les standards ouverts et les organisations qui les développent et les administrent ne doivent favoriser aucun implémenteur si ce n’est pour attester qu’une implémentation est certifiée en conformité avec le standard, ce qui ne constitue aucunement une discrimination mais la reconnaissance d’un fait porteur d’avantages tant pour l’implémenteur que pour son client. Les activités de certification de base doivent être aussi peu coûteuses que possible, mais il est admissible d’organiser des activités de certification assorties de tests de performance qui deviennent alors plus complexes et donc légitimement plus coûteuses. 5. Extension ou Restrictions : Les implémentations de standards ouverts peuvent être étendues par ajout de fonctionnalités aux standard ou au contraire être proposées en tant que réalisation simplifiée, en relation avec un profil restreint du standard. Cependant des implémentations partielles d’un standard peuvent se voir refuser leur certification tandis que des exigences peuvent être faites à l’endroit des extensions qui font l’objet du 6. 6. Interdiction des pratiques de prédateur : Les standards ouverts peuvent utiliser (inclure) des formulations qui protègent contre des manoeuvres de subversions employant des tactiques d’enveloppement-extension (embrace-and-extend tactics telles que celles dont Internet fit l’objet). Les licenses attachées au standard peuvent requérir la publication des informations de référence d’une extension afin de permettre à des tiers de créer, distribuer et vendre des solutions elles aussi compatibles avec une extension. A cette exception près, un standard ouvert ne doit pas interdire des extensions. Signalons enfin que de nombreux organismes de standardisation, et notamment IETF, ISO, IEC, ITU-T, OASIS autorisent les titulaires de brevets à imposer des royalties à des conditions raisonnables et non discriminatoires.

Venons-en aux logiciels Open Source dont Wikipedia donne la définition : « La désignation open source (au Québec : « code source libre ») s’applique aux logiciels dont la licence respecte des critères précisément établis par l’ Open Source Initiative, c’est-à-dire la possibilité de libre redistribution, d’accès au code source et de travaux dérivés. Souvent, un logiciel libre est qualifié d’« open source », car les licences compatibles open source englobent les licences libres selon la définition de la FSF Free Software Foundation. Le terme open source est en concurrence avec le terme « free software » recommandé par la FSF. Le terme « freeware » ou gratuiciel désigne des logiciels gratuits qui ne sont ni nécessairement ouverts, ni libres ».

Venons-en maintenant à l’interopérabilité dans un contexte d’échanges électroniques inter organisations. Elle ne peut résulter que de standards ouverts au moins tant qu’on veut inscrire un système dans un cadre de réseau ouvert d’organisations en situation d’échange. Pour être ouverts ces réseaux doivent être en mesure d’accueillir toute organisation souhaitant faire part du réseau en y participant à sa façon. Dans ce cas particulier, les standards ouverts définissent des processus publics qui s’exécutent dans des environnements d’exploitation qui peuvent très différents auxquels peuvent correspondre des urbanisations de systèmes d’information fort variées. Les processus publics constituent la figure imposée que des processus de traitement privés doivent exécuter. Ces processus consistent à échanger des e-Documents dans le cadre de séquences d’échanges constituant un processus de bout en bout, lequel se déroule suivant une chorégraphie prédéterminée par les standards ouverts. Compte tenu de l’exécution identique des processus publiques par tous les partenaires d’un réseau d’échanges il y a bien entendu grand cas à faire des solutions open source qui permettent une fois pour toutes de développer les outils qui seront mis à profit par tous ces partenaires, à charge pour chacun de définir les correspondances entre ses processus privés et le processus publique agréé par ses partenaires. N’oublions pas que les processus d’échange requièrent non seulement la définition de standards ouverts concernant la Vue Opérationnelle des Affaires mais aussi la définition de standards ouverts pour la définition des protocoles fiables de télécommunication et les services d’authentification, de cryptage, de non répudiation (Vue Fonctionnelle des Services). Dans tous les cas l’usage de standards ouverts et de logiciels open source est fort utile et permet de réaliser des économies d’échelle très importantes. L’utilisation de gratuiciels pourrait être utile car préservant l’intégrité des solutions et évitant les ruptures d’inter opérabilité (puisque le code source n’est pas révélé) mais elle ne permet alors ni de disposer des moyens de tenir compte facilement des obligations d’interfacer processus publics et processus privés, ni de la nécessité de tenir compte des évolutions qu’impose la vie économique, car on ne peut figer les systèmes d’échanges ni ignorer qu’une entreprise appartiendra souvent à plusieurs réseaux ou communautés d’intérêt. Les solutions Open Source sont donc – dans ce cas particulier des systèmes d’échanges inter organisations – une contribution de premier plan à l’économie des déploiements mais l’intérêt d’une discipline dans les évolutions des solutions doit être bien compris, faute de quoi des brèches d’inter opérabilité pourront apparaitre.

Tagged:

Comments are closed.