L’interopérabilité logicielle, c’est à dire la capacité de deux logiciels à parler « la même langue », a souvent été évoquée dans le Framablog.

La plupart du temps, il s’agissait pour nous de traiter de bureautique (« Pourquoi mon fichier LibreOffice est-il mal ouvert par cette saleté de Word ?! ») ou de web (« Pourquoi ce site est-il moins bien affiché avec Firefox qu’avec Chrome ? »).

Comme la langue française a besoin de règles de grammaire et d’orthographe, de dictionnaires, etc, les formats de fichiers ont besoin de spécifications, de normes, et d’être correctement implémentés.

Or, quand un format n’a pas de spécification publique et librement implémentable, cela nous rend dépendant⋅e de l’éditeur du logiciel. Un peu comme si un petit groupe de personnes pouvait décréter que vous ne pouviez pas utiliser le mot « capitalisme » parce que ça ne l’arrangeait pas, ou imposait l’interdiction du mot « autrice » (parce que « auteure » n’aurait été acceptée qu’après 2006). Ce serait assez fou, non ? Oh, wait…

Et bien certains formats de fichiers sont clairement verrouillés. Par exemple les fichiers .DWG du logiciel de dessin Autocad sont dans un format fermé. Alors évidemment, d’autres éditeurs ont essayé de « deviner » comment fonctionnait le format .DWG afin de pouvoir ouvrir et enregistrer des fichiers compatibles AutoCAD avec leur logiciel. C’est ce qu’on appelle de la rétro-ingénierie, mais c’est souvent du bricolage, et l’éditeur original peut régulièrement changer la spécification de son fichier pour embêter ses concurrents, voir aller jusqu’à leur intenter des procès.

Or, s’il existe un domaine où les formats de fichiers devraient bien être ouverts, c’est celui de la construction. Nous interagissons toutes et tous avec des bâtiments au quotidien. Qu’il s’agisse de notre logement, de notre lieu de travail, d’un bâtiment public, etc, nous passons d’un bâtiment à l’autre en permanence.

Or, aussi étonnant que cela puisse paraître, il n’existe pas de format de fichiers de description des données utiles à la construction qui soit à la fois public ET largement utilisé. Le logiciel AutoCAD (et son format .DWG) et le logiciel REVIT (pour le processus BIM et ses formats .rfa, .rvt) de la société Autodesk, dominent largement le marché. Et les conséquences sont loin d’être négligeables. Cela « force la main » des différents corps de métiers (architectes, ingénieurs, constructeurs, artisans, etc) à utiliser ces logiciels et entretient le quasi-monopole d’Autodesk sur le marché. Utiliser d’autres logiciels reste possible, mais imaginez les conséquences si ce logiciel fait une « erreur » en ouvrant le fichier « immeuble-de-12-étages.dwg » à cause d’une erreur dans l’interprétation de la spécification….

Par ailleurs, en dehors des descriptions des murs, des calculs de poids de structures, il faut aussi intégrer des éléments comme les chauffages, les canalisations, les circuits électriques, les fenêtres, etc. Les données générées par un bâtiment (ou autre bâti, tel un pont ou une route) sont donc extrêmement nombreuses. La page wikipédia « Liste des logiciels CAO pour l’architecture, l’ingénierie et la construction » est d’ailleurs plus que conséquente, et sa section logiciels libres est plutôt réduite…

Il existe bien des formats standardisés pour gérer la modélisation du bâti immobilier, appelée « BIM ». Ainsi, l’IFC est un format de fichier standardisé (norme ISO 16739) orienté objet utilisé par l’industrie du bâtiment pour échanger et partager des informations entre logiciels. Mais il est assez peu utilisé et souvent décrit en format natif, ce qui rend l’interopérabilité entre logiciels complexe à réaliser malgré l’existence de l’IFC.

Il apparaît donc essentiel de disposer de formats qui soient ouverts (pour permettre l’interopérabilité), et normalisés (validés et éprouvés par les professionnels du métier) pour nos constructions.

Nous avons rencontré les membres de l’association Alliance Bâtiment qui met à la disposition des maîtres d’ouvrage, maîtres d’œuvre, entreprises, artisans et fabricants PME, TPE, un format ouvert et partagé. Cela permet de normaliser la donnée d’entrée dans les logiciels métiers et rendre les maquettes IFC interopérables. L’accès au processus BIM et l’usage des logiciels BIM est ainsi fortement simplifié !

Bonjour ! Pouvez-vous vous présenter ?

Jean-Paul BRET, Président de l’association : Ma longue carrière professionnelle dans la promotion immobilière à l’OPAC 38, le plus gros bailleur social de l’Isère, et comme Président de la Communauté d’Agglomération du Pays Voironnais (38) durant 12 ans m’incite à penser que le secteur de la construction doit impérativement accélérer sa transition numérique.

J’ai pu constater en engageant de nombreuses opérations de construction que les nombreux acteurs autour d’un projet avaient souvent du mal à se coordonner voire se comprendre. C’est une banalité de parler de retard de travaux, de dépassements budgétaires, de malfaçons pouvant conduire à des conflits et de documents descriptifs des ouvrages difficilement exploitables pour la maintenance des ouvrages.

Thierry LEHNEBACH, Administrateur Délégué : Très tôt, j’ai été motivé par la protection de l’environnement, ce qui m’a conduit à m’engager pour l’écologie. Cela m’a amené à avoir un parcours d’élu, conseiller régional, puis maire et vice président de l’intercommunalité. Dans le même temps, mon activité professionnelle s’est organisée autour de la communication orientée vers le numérique et l’informatique en opensource, puis une dernière activité dans une entreprise artisanale.

Je mets en œuvre ces acquis au service de l’association en tant que cheville ouvrière : communication, animation, gestion.
La transformation numérique de la société ouvre de nouvelles frontières qui donne un avantage disproportionné aux plus puissants qui s’approprient le réel grâce au contrôle de la donnée. Le problème est que la culture de la donnée n’est pas encore développée et qu’il y a une grande naïveté chez tous les décideurs, utilisateurs et simples citoyens.

Didier BALAGUER : Après une première création d’entreprise d’ingénierie spécialisée en acoustique en 1994, j’ai créé datBIM, éditeur de solutions numériques collaboratives pour la construction, en 2000. J’ai identifié dès l’origine qu’une clé de la coopération est l’échange fluide et fiable de données entre les acteurs indépendamment des outils logiciels utilisés, ce qui a amené datBIM à créer le format opendthX.

Faire en sorte que tout type de données soit exploitable dans tout type d’applications à l’image du secteur des télécommunications où 2 correspondants peuvent communiquer indépendamment de la marque de leur téléphone ou des opérateurs de services auxquels ils souscrivent respectivement leur abonnement. La valeur induite par l’interopérabilité des données avec les applications à l’échelle d’un secteur tel la construction Française est estimée à plusieurs dizaines de milliards d’euros par an.

Qu’est-ce qui vous a incité à vous investir en tant que bénévoles dans cette nouvelle association ALLIANCE DU BATIMENT pour le BIM ?

Didier BALAGUER : Ouvrir le format était une évidence, le concéder à ALLIANCE DU BATIMENT, association loi 1901 gouvernée par les acteurs volontaires de la filière, un moyen d’apporter la confiance pour permettre aux acteurs de maîtriser leur devenir numérique pour répondre collectivement aux enjeux de notre société : transition écologique, liberté d’expression et d’entreprendre tout en renforçant la compétitivité de notre économie.

Jean- Paul BRET : Lorsque Didier BALAGUER m’a proposé de créer l’ALLIANCE DU BATIMENT pour le BIM, avec pour objectif de faciliter la transition numérique de la filière avec les outils mis à disposition en opensource, j’ai tout de suite accepté. Cela a conduit au transfert à l’association de la gestion et la gouvernance du format opendthX initialement développé par la société datBIM pour en faire un bien commun, libre d’usage.

L’absence de langage commun et d’interopérabilité entre les données et les outils pénalise souvent la qualité des projets et l’efficacité de toute la filière constructive. Le BIM qui est la numérisation du processus de construction peut améliorer cette situation. C’est un moyen de le faire depuis la phase de conception d’un projet jusqu’à celle de la déconstruction en passant par la construction et l’exploitation.

Mais il ne doit pas être réservé aux grands acteurs de la filière et conduire à une plateformatisation et une appropriation de la valeur par quelques acteurs dominants ou des plateformes de type GAFAM. Or c’est ce qu’il se passe avec les formats propriétaires des logiciels de CAO adaptés pour le BIM.
Il doit être facilement accessible aux PME, TPE et artisans qui représentent environ 95% des entreprises de la filière constructive.

Pour cela nous allons mettre à leur disposition de nouvelles solutions d’interopérabilité qui faciliteront leur manière d’accéder à la donnée sur les objets. Elles leur permettront de contribuer à la production de la maquette numérique. L’enjeu est important puisqu’en cas de succès l’ALLIANCE DU BATIMENT pourrait avoir valeur d’exemple. Cela pourrait à ce titre, être décliné bien au-delà nos frontières.

Nous sommes d’autant plus motivés que ce projet, qui vise à faciliter la coopération au sein de la filière BTP, est totalement en phase avec les objectifs du plan gouvernemental BIM 2022 qui reposent sur le principe directeur du BIM POUR TOUS. Enfin, pour moi le BIM n’est pas seulement une démarche qui permet d’optimiser l’échange d’information et la collaboration entre acteurs d’un projet constructif. C’est aussi un outil au service de la transition écologique puisqu’il permet une véritable traçabilité environnementale.

Dans les deux cas, les enjeux sont cruciaux tant sur le plan de la compétitivité économique que des aspects sociétaux.

Thierry LEHNEBACH : ALLIANCE DU BATIMENT ouvre un front dans le secteur de la construction qui concerne, en terme d’échange de données relatives à l’objet constructif, 25 % du PIB quand on prend en compte l’ensemble des acteurs (BTP, banques, assurances, etc..) en considérant que la donnée numérique doit être un commun dans cette filière.

Pouvez-vous nous expliquer un peu plus ce qu’est le BIM ?

Thierry LEHNEBACH : Le BIM ou Building Information Modeling est la modélisation des informations de la construction. C’est l’utilisation d’une représentation numérique partagée d’un actif bâti. Le BIM facilite les processus de conception, de construction et d’exploitation. Ces actifs bâtis sont des bâtiments, ponts, routes, tunnels, voies de chemin de fer, usines,…
Le processus produit un livrable numérique, le building information model, en français la maquette numérique. C’est le support et en même temps le document numérique du processus qui doit permettre à tous les acteurs de collaborer.

Pouvez-vous nous parler du projet de l’association ?

Thierry LEHNEBACH : ALLIANCE DU BATIMENT pour le BIM met à disposition librement le format opendthX dont elle a acquis les droits exclusifs d’exploitation. Ce format a été développé par la société datBIM pour structurer des bibliothèques d’objets pour le BIM et les diffuser en permettant l’interopérabilité entre tous les logiciels.

La maquette numérique englobe la géométrie de la construction, les relations spatiales, les informations géographiques. Elle englobe également les quantités, ainsi que les propriétés des éléments et sous-éléments de construction. Le format IFC (NF EN ISO 16739) permet de classer ces informations de manière logique selon une arborescence spatiale. Cette arborescence est définie par projet, site, bâtiment, étage, espace, composant.

La maquette numérique standardisée au format international IFC rassemble une bonne partie des informations. Elle rassemble les formes et matériaux, les calculs énergétiques pour le chauffage, la climatisation, la ventilation. Cela comprend également les données sur l’aéraulique, l’hydraulique, l’électricité, radio et télécommunications, levage, emplacement des équipements, alarmes et sécurité, maintenance, etc.

Mais le format IFC n’est pas suffisant pour permettre la réalisation d’un processus BIM abouti. Il y a deux problèmes majeurs :

• Le premier est que les objets au sein de la maquette IFC sont généralement structurés par des formats propriétaires et donc non interopérables. Les différents logiciels métiers utilisés sur un même projet utilisent des formats de données natifs. Ces formats concernent les objets avec des données décrites de différentes manières. L’écosystème BIM est un système multi-entrées dans lequel on introduit des données qui sont doublonnées et redondantes. Celles-ci constituent alors obligatoirement une donnée d’entrée de mauvaise qualité. Par conséquent elle amène à produire collectivement un résultat de piètre qualité. Ce phénomène pénalise des échanges fluides avec les logiciels des autres corps de métiers.
• Le second problème est que les formats propriétaires permettent aux acteurs les plus puissants de s’approprier le contrôle des données, ce qui créé des barrières et ouvre la voie à des situations de monopole de type GAFAM.

La mise en œuvre du BIM doit être simple pour un déploiement généralisé. L’association met à disposition des acteurs le format opendthX et participe aux développements d’outils pour permettre l’accès au BIM à tous les acteurs.

Comment fonctionnent ces outils ?

Didier Balaguer : Le processus collaboratif proposé par ALLIANCE DU BATIMENT s’appelle le BIM CIQO (Collaboration In – Quality Out). Il est basé sur la normalisation de la donnée d’entrée introduite dans les logiciels métiers de la construction et l’enrichissement des « objets » pour permettre la contribution de tous au processus BIM. C’est la raison d’être du format Open dthX.

Le processus CIQO, ou BIM universel, est le traitement du GIGO (Garbage In Garbage Out), caractéristique du BIM complexe multi-formats natifs.

On peut le mettre en œuvre avec eveBIM, logiciel de visualisation / enrichissement de maquettes IFC développé par le CSTB ou en mode saas en cours de développement (bim-universel.com) pour définir des objets BIM sur la base de modèles génériques de type POBIM (Propriétés des objets BIM ), qui est une bibliothèque de 300 modèles d’objets génériques à partir d’un dictionnaire de 3200 propriétés, définies selon la norme NF XP P 07150 devenue en 2020 NF EN ISO 23386.

Cette bibliothèque à été réalisée dans le cadre des travaux du plan de transition numérique du Bâtiment (PTNB) accessible depuis kroqi.MydatBIM.com, plateforme d’objets labellisée par l’AMI (appel à manifestation d’intérêt) kroqi, plateforme de gestion de projets BIM de référence du Plan gouvernemental BIM 2022. Il existe également d’autres bibliothèques :

• POBIM : DCE
• ATELIER BIM VIRTUEL : APS-APD-PRO-DOE Logement collectif
• PCBIM : Autorisations d’urbanisme
• FEDENE : DOE tertiaire & industrie

Comment est organisée votre association ?

Jean-Paul BRET : L’association est structurée par 6 collèges, dont les deux principaux piliers sont les organisations professionnelles telles que des CAPEB et des syndicats qui représentent des acteurs petits et moyens de la filière, et de maîtres d’ouvrage publics et privés. Il y a également des collèges association, organismes de formation, entreprises et citoyens.

Le modèle économique repose sur des adhésions, des financements sur projets et sur le produit de la formation par le biais de modules destinés à être mis en œuvre par des organismes de formation que l’association labellise.

 

C’est une structure légère qui a vocation à le rester tout en se professionnalisant pour s’inscrire dans la durée.

Selon vous, quels sont les enjeux d’un « BIM libre » ?

Le BIM libre permet à tous les acteurs de la filière des garder leur autonomie sans être rendus dépendants par des outils qu’ils ont eux même développés avec leur compétence mais dans un format qu’ils ne maîtrisent pas. L’interopérabilité complète permet aussi d’envisager le développement de savoir-faire partagés par l’ensemble de la filière pour faire monter celle-ci en efficacité. Il est possible par exemple d’imaginer de mettre en œuvre l’intelligence artificielle pour extraire de plusieurs projets des règles pour optimiser l’efficacité énergétique d’un type de construction.

L’accès à ce processus pour tous les acteurs est aussi un élément important pour les maîtres d’ouvrage qui veulent garder un écosystème d’entreprises de proximité. C’est une garantie pour la résilience des territoires et une sécurité contre la concentration qui conduit aux monopoles de fait.

Quelles sont les particularités de ce format Open dthx ?

Le format Open dthX a été développé par la société datBIM à partir de 2011 dans le cadre d’une collaboration avec l’école Centrale de Lyon et des experts en modélisation de la connaissance et ingénierie des systèmes. Les travaux ont bénéficié du soutien de la région Rhône-Alpes et l’Ademe (Innov’R) ainsi que de l’Europe (GreenConserve pour l’innovation de services à valeur ajoutée pour la construction durable et Eurostars).

L’enjeu de départ est de permettre aux acteurs du bâtiment (fournisseurs de matériaux, architectes, ingénieurs, …) de s’échanger – dès les premières phases du projet – les caractéristiques techniques des produits mis en œuvre dans la construction.

Un Dictionnaire Technique Harmonisé (DTH) a été mis en place à cette fin de nature dynamique afin que la sémantique puisse s’enrichir en fonction des besoins sans perturber les usages du format. Il maintient une liste de propriétés dans différents domaines (géométrique, acoustique, thermique, incendie, environnement, administratif…) en définissant pour chaque propriété un identifiant unique et une unité de mesure standard.

En 2015, la documentation du format est rendue publique, en faisant un format ouvert. Il est proposé à la normalisation entraînant la création d’un groupe d’experts sur les formats d’échange à la commission de normalisation, Afnor PPBIM. En 2019, il permet la distribution de la première bibliothèque d’objets génériques POBIM (propriétés des objets pour le BIM) décrit à partir d’un dictionnaire national de 3200 propriétés issues des travaux réalisés dans le cadre du plan gouvernemental de transition numérique du bâtiment (PTNB). En 2021, le plan gouvernemental BIM 2022 l’expérimente pour la réalisation d’un référentiel d’objets pour produire une maquette numérique contenant les informations nécessaires à l’instruction des autorisations d’urbanisme.

Normaliser la donnée d’entrée dans les logiciels métiers pour produire collectivement un livrable numérique de qualité (au sens interopérabilité du terme : exploiter le livrable qui est une base de données dans une application autre que celle qui l’a produite) et assurer l’enrichissement des objets à l’avancement du projet pour permettre la contribution de tous au processus BIM indépendamment des logiciels utilisés.

Quelle est la licence retenue pour la spécification de ce format ?

L’usage du format Open dthX est soumis à l’acceptation des termes de la licence « Creative Commons Attribution Pas de Modification 3.0 France ».
Sa principale valeur c’est justement qu’il soit unique afin d’assurer l’interopérabilité d’où le choix de ce type de licence. Des variantes porteraient préjudices à l’interopérabilité.

Qui utilise ce format de fichier Open dthx aujourd’hui ? Avec quels logiciels ?

Les utilisateurs du format Open dthX sont les acteurs de la construction : architectes, ingénieurs, entreprises, fabricants, maîtres d’ouvrage qui utilisent des logiciels de CAO tels Revit, ArchiCAD et de visualisation tels eveBIM, ciqo.eu…

De quoi avez-vous besoin aujourd’hui ? Et à plus long terme ?

Le premier enjeux est de faire connaître le projet de l’association. C’est assez difficile car la conscience de l’enjeu est très peu développé chez les décideurs et la communication des leaders du BIM qui vantent la puissance de leurs outils impose l’idée que leurs solutions sont le BIM alors que ces solutions n’en sont qu’une partie et que celle-ci est inadaptée à une approche data performante généralisable.

Nous cherchons aussi des partenaires qui mettent en œuvre ces outils. Nous sommes convaincus que les bénéfices de ces réalisations se diffuseront très rapidement auprès des décideurs vigilants sur les questions de maîtrise des données.

Enfin, nous voulons mettre en place un modèle qui nous permette de nouer des partenariats avec des développeurs qui peuvent proposer des développements qui utilisent le format pour des solutions correspondantes à des besoins métier liés à la construction.

Un mot ou une question à ajouter ?

Nous proposons à tous les décideurs en matière de construction de les accompagner pour mettre en œuvre le BIM universel de façon à avoir le plus grand nombre de références et de cas d’usage à diffuser pour propager la démarche.

 

Ressource à consulter :

• Site internet de Alliance du Bâtiment : alliance-batiment.org
• Article « C’est quoi, l’interopérabilité, et pourquoi est-ce beau et bien ? »

« Il est évidemment plus qu’urgent de réguler les GAFAM pour leur imposer l’interopérabilité. » écrit Laurent Chemla. Diable, il n’y va pas de main morte, le « précurseur dans le domaine d’Internet » selon sa page Wikipédia.

Nous reproduisons ici avec son accord l’article qu’il vient de publier sur son blog parce qu’il nous paraît tout à fait intéressant et qu’il est susceptible de provoquer le débat : d’aucuns trouveront sa proposition nécessaire pour franchir une étape dans la lutte contre des Léviathans numériques et le consentement à la captivité. D’autres estimeront peut-être que sa conception a de bien faibles chances de se concrétiser : est-il encore temps de réguler les Gafam ?

Nous souhaitons que s’ouvre ici (ou sur son blog bien sûr) la discussion. Comme toujours sur le Framablog, les commentaires sont ouverts mais modérés.

« Interopérabilité » : ce mot m’ennuie. Il est moche, et beaucoup trop long.

Pourtant il est la source même d’Internet. Quasiment sa définition, au moins sémantique puisqu’il s’agit de faire dialoguer entre eux des systèmes d’information d’origines variées mais partageant au sein d’un unique réseau de réseaux la même « lingua franca » : TCP/IP et sa cohorte de services (ftp, http, smtp et tant d’autres) définis par des standards communs. Des machines « interopérables », donc.

Faisons avec.

L’interopérabilité, donc, est ce qui a fait le succès d’Internet, et du Web. Vous pouvez vous connecter sur n’importe quel site Web, installé sur n’importe quel serveur, quelle que soit sa marque et son système d’exploitation, depuis votre propre ordinateur, quelle que soit sa marque, son système d’exploitation, et le navigateur installé dessus.

Avant ça existaient les silos. Compuserve, AOL, The Microsoft Network en étaient les derniers représentants, dinosaures communautaires enterrés par la comète Internet. Leur volonté d’enfermer le public dans des espaces fermés, contrôlés, proposant tant bien que mal tous les services à la fois, fut ridiculisée par la décentralisation du Net.

Ici vous ne pouviez échanger qu’avec les clients du même réseau, utilisant le même outil imposé par le vendeur (« pour votre sécurité »), là vous pouviez choisir votre logiciel de mail, et écrire à n’importe qui n’importe où. Interopérabilité.

Ici vous pouviez publier vos humeurs, dans un format limité et imposé par la plateforme (« pour votre sécurité »), là vous pouviez installer n’importe quel « serveur web » de votre choix et y publier librement des pages accessibles depuis n’importe quel navigateur. Interopérabilité.

Bref. Le choix était évident, Internet a gagné.

Il a gagné, et puis… Et puis, selon un schéma désormais compris de tous, le modèle économique « gratuité contre publicité » a envahi le Web, en créant – une acquisition après l’autre, un accaparement de nos données après l’autre – de nouveaux géants qui, peu à peu, se sont refermés sur eux-mêmes (« pour votre sécurité »).

Il fut un temps où vous pouviez écrire à un utilisateur de Facebook Messenger depuis n’importe quel client, hors Facebook, respectant le standard (en l’occurrence l’API) défini par Facebook. Et puis Facebook a arrêté cette fonctionnalité. Il fut un temps où vous pouviez développer votre propre client Twitter, qui affichait ses timelines avec d’autres règles que celles de l’application officielle, pourvu qu’il utilise le standard (encore une API) défini par Twitter. Et puis Twitter a limité cette fonctionnalité. De nos jours, il devient même difficile d’envoyer un simple email à un utilisateur de Gmail si l’on utilise pas soi-même Gmail, tant Google impose de nouvelles règles (« pour votre sécurité ») à ce qui était, avant, un standard universel.

On comprend bien les raisons de cette re-centralisation : tout utilisateur désormais captif devra passer davantage de temps devant les publicités, imposées pour pouvoir utiliser tel ou tel service fermé. Et il devra – pour continuer d’utiliser ce service – fournir toujours davantage de ses données personnelles permettant d’affiner son profil et de vendre plus cher les espaces publicitaires. Renforçant ainsi toujours plus les trésoreries et le pouvoir de ces géants centralisateurs, qui ainsi peuvent aisément acquérir ou asphyxier tout nouveau wanabee concurrent, et ainsi de suite.

C’est un cercle vertueux (pour les GAFAM) et vicieux (pour nos vies privées et nos démocraties), mais c’est surtout un cercle « normal » : dès lors que rien n’impose l’interopérabilité, alors – pour peu que vous soyez devenu assez gros pour vous en passer – vous n’avez plus aucun intérêt à donner accès à d’autres aux données qui vous ont fait roi. Et vous abandonnez alors le modèle qui a permis votre existence au profit d’un modèle qui permet votre croissance. Infinie.

Imaginez, par exemple, qu’à l’époque des cassettes vidéo (respectant le standard VHS) un fabricant de magnétoscopes ait dominé à ce point le marché qu’on ait pu dire qu’il n’en existait virtuellement pas d’autres : il aurait évidemment modifié ce standard à son profit, en interdisant par exemple l’utilisation de cassettes d’autres marques que la sienne (« pour votre sécurité »), de manière à garantir dans le temps sa domination. C’est un comportement « normal », dans un monde libéral et capitaliste. Et c’est pour limiter ce comportement « normal » que les sociétés inventent des régulations (standards imposés, règles de concurrence, lois et règlements).

Et il est évidemment plus qu’urgent de réguler les GAFAM pour leur imposer l’interopérabilité.

Nous devons pouvoir, de nouveau, écrire depuis n’importe quel logiciel de messagerie à un utilisateur de Facebook Messenger, pourvu qu’on respecte le standard défini par Facebook, comme nous devons écrire à n’importe quel utilisateur de Signal en respectant le standard de chiffrement de Signal. Il n’est pas question d’imposer à Signal (ou à Facebook) un autre standard que celui qu’il a choisi (ce qui empêcherait toute innovation), pourvu que le standard choisi soit public, et libre d’utilisation. Mais il est question de contraindre Facebook à (ré)ouvrir ses API pour permettre aux utilisateurs d’autres services d’interagir de nouveau avec ses propres utilisateurs.

Au passage, ce point soulève une problématique incidente : l’identité. Si je peux écrire à un utilisateur de Messenger, celui-ci doit pouvoir me répondre depuis Messenger. Or Messenger ne permet d’écrire qu’aux autres utilisateurs de Messenger, identifiés par Facebook selon ses propres critères qu’il n’est pas question de lui imposer (il a le droit de ne vouloir admettre que des utilisateurs affichant leur « identité réelle », par exemple : ce choix est le sien, comme il a le droit de limiter les fonctionnalités de Messenger pour lui interdire d’écrire à d’autres : ce choix est aussi le sien).

Il est donc cohérent d’affirmer que – pour pouvoir écrire à un utilisateur de Messenger depuis un autre outil – il faut avoir soi-même un compte Messenger. Il est donc logique de dire que pour pouvoir lire ma timeline Twitter avec l’outil de mon choix, je dois avoir un compte Twitter. Il est donc évident que pour accéder à mon historique d’achat Amazon, je dois avoir un compte Amazon, etc.

L’obligation d’avoir une identité reconnue par le service auquel on accède, c’est sans doute le prix à payer pour l’interopérabilité, dans ce cas (et – au passage – c’est parce que la Quadrature du Net a décidé d’ignorer cette évidence que j’ai choisi de quitter l’association).

Ce qui ne doit évidemment pas nous obliger à utiliser Messenger, Amazon ou Twitter pour accéder à ces comptes: l’interopérabilité doit d’accéder à nos contacts et à nos données depuis l’outil de notre choix, grâce à l’ouverture obligatoire des API, pourvu qu’on dispose d’une identité respectant les standards du service qui stocke ces données.

On pourrait résumer ce nouveau type de régulation avec cette phrase simple :

« si ce sont MES données, alors je dois pouvoir y accéder avec l’outil de MON choix ».

Je dois pouvoir lire ma timeline Twitter depuis l’outil de mon choix (et y publier, si évidemment j’y ai un compte, pour que les autres utilisateurs de Twitter puissent s’y abonner).

Je dois pouvoir consulter mon historique d’achats chez Amazon avec l’outil de mon choix.

Je dois pouvoir écrire à (et lire les réponses de) mes contacts Facebook avec l’outil de mon choix.

Il y aura, évidemment, des résistances.

On nous dira (« pour votre sécurité ») que c’est dangereux, parce que nos données personnelles ne seront plus aussi bien protégées, dispersées parmi tellement de services décentralisés et piratables. Mais je préfère qu’une partie de mes données soit moins bien protégée (ce qui reste à démontrer) plutôt que de savoir qu’une entreprise privée puisse vendre (ou perdre) la totalité de ce qui est MA vie.

On nous dira que c’est « excessivement agressif pour le modèle économique des grandes plateformes », alors qu’évidemment c’est justement le modèle économique des grandes plateformes qui est excessivement agressif pour nos vies privées et nos démocraties, d’une part, et que d’autre part l’interopérabilité ne modifie en rien ce modèle économique : dès lors qu’elles stockent toujours une partie de nos données elles restent (hélas) en capacité de les vendre et/ou de les utiliser pour « éduquer » leurs IA. Tout au plus constateront-elles un manque-à-gagner comptable, mais ne gagnent-elles pas déjà largement assez ?

À ce jour, l’interopérabilité s’impose comme la seule solution réaliste pour limiter le pouvoir de nuisance de ces géants, et pour rétablir un peu de concurrence et de décentralisation dans un réseau qui, sinon, n’a plus d’autre raison d’être autre chose qu’un simple moyen d’accéder à ces nouveaux silos (qu’ils devraient donc financer, eux, plutôt que les factures de nos FAI).

À ce jour, l’ARCEP, la Quadrature du Net (même mal), l’EFF, le Sénat, et même l’Europe (Margrethe Vestager s’est elle-même déclarée en faveur de cette idée) se sont déclarés pour une obligation d’intéropérabilité. C’est la suite logique (et fonctionnelle) du RGPD.

Qu’est-ce qu’on attend ?

Édit. de Laurent suite à la publication de l’article sur son blog

Suite à ce billet des discussions sur Twitter et Mastodon, indépendamment, m’ont amené à préciser ceci : prenons par exemple mamot.fr (l’instance Mastodon de la Quadrature) et gab.ai (l’instance Mastodon de la fachosphère). Mamot.fr, comme nombre d’autres instances, a refusé de se fédérer avec Gab. C’est son droit. En conséquence, les utilisateurs de Gab ne peuvent pas poster sur Mamot, et inversement.

Pour autant, les deux sont bel et bien interopérables, et pour cause : elles utilisent le même logiciel. Gab pourrait parfaitement développer un bout de code pour permettre à ses utilisateurs de publier sur Mamot, pour peu qu’ils s’y soient identifiés (via une OAuth, pour les techniciens) prouvant ainsi qu’ils en acceptent les CGU.

Ce qu’elles ne sont pas, c’est interconnectées : il n’est pas possible de publier sur l’une en s’identifiant sur l’autre, et inversement.

Je crois qu’au fond, les tenants de l’idée qu’on devrait pouvoir publier n’importe quoi n’importe où, sans identification supplémentaire, confondent largement ces deux notions d’interconnexion et d’interopérabilité. Et c’est fort dommage, parce que ça brouille le message de tous.

 

Pour aller plus loin dans la technique, vous pouvez aussi lire cette réponse de Laurent dans les commentaires de NextINpact.

Protocole, HTTP, interopérabilité, ça vous parle ? Et normes, spécifications, RFC, ça va toujours ? Si vous avez besoin d’y voir un peu plus clair, l’article ci-dessous est un morceau de choix rédigé par Stéphane Bortzmeyer qui s’est efforcé de rendre accessibles ces notions fondamentales.

---

Protocoles

Le 21 mai 2019, soixante-neuf organisations, dont Framasoft, ont signé un appel à ce que soit imposé, éventuellement par la loi, un minimum d’interopérabilité pour les gros acteurs commerciaux du Web.

« Interopérabilité » est un joli mot, mais qui ne fait pas forcément partie du vocabulaire de tout le monde, et qui mérite donc d’être expliqué. On va donc parler d’interopérabilité, de protocoles, d’interfaces, de normes, et j’espère réussir à le faire tout en restant compréhensible (si vous êtes informaticien·ne professionnel·le, vous savez déjà tout cela ; mais l’appel des 69 organisations concerne tout le monde).

Le Web, ou en fait tout l’Internet, repose sur des protocoles de communication. Un protocole, c’est un ensemble de règles qu’il faut suivre si on veut communiquer. Le terme vient de la communication humaine, par exemple, lorsqu’on rencontre quelqu’un, on se serre la main, ou bien on se présente si l’autre ne vous connaît pas, etc. Chez les humains, le protocole n’est pas rigide (sauf en cas de réception par la reine d’Angleterre dans son palais, mais cela doit être rare chez les lectrices et lecteurs du Framablog). Si la personne avec qui vous communiquez ne respecte pas exactement le protocole, la communication peut tout de même avoir lieu, quitte à se dire que cette personne est bien impolie. Mais les logiciels ne fonctionnent pas comme des humains. Contrairement aux humains, ils n’ont pas de souplesse, les règles doivent être suivies exactement. Sur un réseau comme l’Internet, pour que deux logiciels puissent communiquer, chacun doit donc suivre exactement les mêmes règles, et c’est l’ensemble de ces règles qui fait un protocole.

Un exemple concret ? Sur le Web, pour que votre navigateur puisse afficher la page web désirée, il doit demander à un serveur web un ou plusieurs fichiers. La demande se fait obligatoirement en envoyant au serveur le mot GET (« donne », en anglais) suivi du nom du fichier, suivi du mot « HTTP/1.1 ». Si un navigateur web s’avisait d’envoyer le nom du fichier avant le mot GET, le serveur ne comprendrait rien, et renverrait plutôt un message d’erreur. En parlant d’erreurs, vous avez peut-être déjà rencontré le nombre 404 qui est simplement le code d’erreur qu’utilisent les logiciels qui parlent HTTP pour signaler que la page demandée n’existe pas. Ces codes numériques, conçus pour être utilisés entre logiciels, ont l’avantage sur les textes de ne pas être ambigus, et de ne pas dépendre d’une langue humaine particulière. Cet exemple décrit une toute petite partie du protocole nommé HTTP (pour Hypertext Transfer Protocol) qui est le plus utilisé sur le Web.

Il existe des protocoles bien plus complexes. Le point important est que, derrière votre écran, les logiciels communiquent entre eux en utilisant ces protocoles. Certains servent directement aux logiciels que vous utilisez (comme HTTP, qui permet à votre navigateur Web de communiquer avec le serveur qui détient les pages désirées), d’autres protocoles relèvent de l’infrastructure logicielle de l’Internet ; vos logiciels n’interagissent pas directement avec eux, mais ils sont indispensables.

Le protocole, ces règles de communication, sont indispensables dans un réseau comme l’Internet. Sans protocole, deux logiciels ne pourraient tout simplement pas communiquer, même si les câbles sont bien en place et les machines allumées. Sans protocole, les logiciels seraient dans la situation de deux humains, un Français ne parlant que français, et un Japonais ne parlant que japonais. Même si chacun a un téléphone et connaît le numéro de l’autre, aucune vraie communication ne pourra prendre place. Tout l’Internet repose donc sur cette notion de protocole.

Le protocole permet l’interopérabilité. L’interopérabilité est la capacité à communiquer de deux logiciels différents, issus d’équipes de développement différentes. Si une université bolivienne peut échanger avec une entreprise indienne, c’est parce que toutes les deux utilisent des protocoles communs.

 

Seuls les protocoles ont besoin d’être communs : l’Internet n’oblige pas à utiliser les mêmes logiciels, ni à ce que les logiciels aient la même interface avec l’utilisateur. Si je prends l’exemple de deux logiciels qui parlent le protocole HTTP, le navigateur Mozilla Firefox (que vous êtes peut-être en train d’utiliser pour lire cet article) et le programme curl (utilisé surtout par les informaticiens pour des opérations techniques), ces deux logiciels ont des usages très différents, des interfaces avec l’utilisateur reposant sur des principes opposés, mais tous les deux parlent le même protocole HTTP. Le protocole, c’est ce qu’on parle avec les autres logiciels (l’interface avec l’utilisateur étant, elle, pour les humain·e·s.).

La distinction entre protocole et logiciel est cruciale. Si j’utilise le logiciel A parce que je le préfère et vous le logiciel B, tant que les deux logiciels parlent le même protocole, aucun problème, ce sera juste un choix individuel. Malgré leurs différences, notamment d’interface utilisateur, les deux logiciels pourront communiquer. Si, en revanche, chaque logiciel vient avec son propre protocole, il n’y aura pas de communication, comme dans l’exemple du Français et du Japonais plus haut.

Babel

Alors, est-ce que tous les logiciels utilisent des protocoles communs, permettant à tout le monde de communiquer avec bonheur ? Non, et ce n’est d’ailleurs pas obligatoire. L’Internet est un réseau à « permission facultative ». Contrairement aux anciennes tentatives de réseaux informatiques qui étaient contrôlés par les opérateurs téléphoniques, et qui décidaient de quels protocoles et quelles applications tourneraient sur leurs réseaux, sur l’Internet, vous pouvez inventer votre propre protocole, écrire les logiciels qui le parlent et les diffuser en espérant avoir du succès. C’est d’ailleurs ainsi qu’a été inventé le Web : Tim Berners-Lee (et Robert Cailliau) n’ont pas eu à demander la permission de qui que ce soit. Ils ont défini le protocole HTTP, ont écrit les applications et leur invention a connu le succès que l’on sait.

Cette liberté d’innovation sans permission est donc une bonne chose. Mais elle a aussi des inconvénients. Si chaque développeur ou développeuse d’applications invente son propre protocole, il n’y aura plus de communication ou, plus précisément, il n’y aura plus d’interopérabilité. Chaque utilisatrice et chaque utilisateur ne pourra plus communiquer qu’avec les gens ayant choisi le même logiciel. Certains services sur l’Internet bénéficient d’une bonne interopérabilité, le courrier électronique, par exemple. D’autres sont au contraire composés d’un ensemble de silos fermés, ne communiquant pas entre eux. C’est par exemple le cas des messageries instantanées. Chaque application a son propre protocole, les personnes utilisant WhatsApp ne peuvent pas échanger avec celles utilisant Telegram, qui ne peuvent pas communiquer avec celles qui préfèrent Signal ou Riot. Alors que l’Internet était conçu pour faciliter la communication, ces silos enferment au contraire leurs utilisateurs et utilisatrices dans un espace clos.

La situation est la même pour les réseaux sociaux commerciaux comme Facebook. Vous ne pouvez communiquer qu’avec les gens qui sont eux-mêmes sur Facebook. Les pratiques de la société qui gère ce réseau sont déplorables, par exemple en matière de captation et d’utilisation des données personnelles mais, quand on suggère aux personnes qui utilisent Facebook de quitter ce silo, la réponse la plus courante est « je ne peux pas, tou·te·s mes ami·e·s y sont, et je ne pourrais plus communiquer avec eux et elles si je partais ». Cet exemple illustre très bien les dangers des protocoles liés à une entreprise et, au contraire, l’importance de l’interopérabilité.

 

Mais pourquoi existe-t-il plusieurs protocoles pour un même service ? Il y a différentes raisons. Certaines sont d’ordre technique. Je ne les développerai pas ici, ce n’est pas un article technique, mais les protocoles ne sont pas tous équivalents, il y a des raisons techniques objectives qui peuvent faire choisir un protocole plutôt qu’un autre. Et puis deux personnes différentes peuvent estimer qu’en fait deux services ne sont pas réellement identiques et méritent donc des protocoles séparés, même si tout le monde n’est pas d’accord.

Mais il peut aussi y avoir des raisons commerciales : l’entreprise en position dominante n’a aucune envie que des acteurs plus petits la concurrencent, et ne souhaite pas permettre à des nouveaux entrants d’arriver. Elle a donc une forte motivation à n’utiliser qu’un protocole qui lui est propre, que personne d’autre ne connaît.

Enfin, il peut aussi y avoir des raisons plus psychologiques, comme la conviction chez l·e·a créat·eur·rice d’un protocole que son protocole est bien meilleur que les autres.

Un exemple d’un succès récent en termes d’adoption d’un nouveau protocole est donné par le fédivers. Ce terme, contraction de « fédération » et « univers » (et parfois écrit « fédiverse » par anglicisme) regroupe tous les serveurs qui échangent entre eux par le protocole ActivityPub, que l’appel des soixante-neuf organisations mentionne comme exemple. ActivityPub permet d’échanger des messages très divers. Les logiciels Mastodon et Pleroma se servent d’ActivityPub pour envoyer de courts textes, ce qu’on nomme du micro-blogging (ce que fait Twitter). PeerTube utilise ActivityPub pour permettre de voir les nouvelles vidéos et les commenter. WriteFreely fait de même avec les textes que ce logiciel de blog permet de rédiger et diffuser. Et, demain, Mobilizon utilisera ActivityPub pour les informations sur les événements qu’il permettra d’organiser. Il s’agit d’un nouvel exemple de la distinction entre protocole et logiciel. Bien que beaucoup de gens appellent le fédivers  « Mastodon », c’est inexact. Mastodon n’est qu’un des logiciels qui permettent l’accès au fédivers.

Le terme d’ActivityPub n’est d’ailleurs pas idéal. Il y a en fait un ensemble de protocoles qui sont nécessaires pour communiquer au sein du fédivers. ActivityPub n’est que l’un d’entre eux, mais il a un peu donné son nom à l’ensemble.

Tous les logiciels de la mouvance des « réseaux sociaux décentralisés » n’utilisent pas ActivityPub. Par exemple,  Diaspora ne s’en sert pas et n’est donc pas interopérable avec les autres.

Appel

Revenons maintenant l’appel cité au début, Que demande-t-il ? Cet appel réclame que l’interopérabilité soit imposée aux GAFA, ces grosses entreprises capitalistes qui sont en position dominante dans la communication. Tous sont des silos fermés. Aucun moyen de commenter une vidéo YouTube si on a un compte PeerTube, de suivre les messages sur Twitter ou Facebook si on est sur le fédivers. Ces GAFA ne changeront pas spontanément : il faudra les y forcer.

Il ne s’agit que de la communication externe. Cet appel est modéré dans le sens où il ne demande pas aux GAFA de changer leur interface utilisateur, ni leur organisation interne, ni leurs algorithmes de sélection des messages, ni leurs pratiques en matière de gestion des données personnelles. Il s’agit uniquement d’obtenir qu’ils permettent l’interopérabilité avec des services concurrents, de façon à permettre une réelle liberté de choix par les utilisateurs. Un tel ajout est simple à implémenter pour ces entreprises commerciales, qui disposent de fonds abondants et de nombreu·ses-x programmeur·e·s compétent·e·s. Et il « ouvrirait » le champ des possibles. Il s’agit donc de défendre les intérêts des utilisateurs et utilisatrices. (Alors que le gouvernement, dans ses commentaires, n’a cité que les intérêts des GAFA, comme si ceux-ci étaient des espèces menacées qu’il fallait défendre.)

Qui commande ?

Mais au fait, qui décide des protocoles, qui les crée ? Il n’y a pas de réponse simple à cette question. Il existe plein de protocoles différents et leurs origines sont variées. Parfois, ils sont rédigés, dans un texte qui décrit exactement ce que doivent faire les deux parties. C’est ce que l’on nomme une spécification. Mais parfois il n’y a pas vraiment de spécification, juste quelques vagues idées et un programme qui utilise ce protocole. Ainsi, le protocole BitTorrent, très utilisé pour l’échange de fichiers, et pour lequel il existe une très bonne interopérabilité, avec de nombreux logiciels, n’a pas fait l’objet d’une spécification complète. Rien n’y oblige développeurs et développeuses : l’Internet est « à permission facultative ». Dans de tels cas, celles et ceux qui voudraient créer un programme interopérable devront lire le code source (les instructions écrites par le ou la programmeur·e) ou analyser le trafic qui circule, pour essayer d’en déduire en quoi consiste le protocole (ce qu’on nomme la rétro-ingénierie). C’est évidemment plus long et plus difficile et il est donc très souhaitable, pour l’interopérabilité, qu’il existe une spécification écrite et correcte (il s’agit d’un exercice difficile, ce qui explique que certains protocoles n’en disposent pas).

Parfois, la spécification est adoptée formellement par un organisme dont le rôle est de développer et d’approuver des spécifications. C’est ce qu’on nomme la normalisation. Une spécification ainsi approuvée est une norme. L’intérêt d’une norme par rapport à une spécification ordinaire est qu’elle reflète a priori un consensus assez large d’une partie des acteurs, ce n’est plus un acte unilatéral. Les normes sont donc une bonne chose mais, rien n’étant parfait, leur développement est parfois laborieux et lent.

 

Toutes les normes ne se valent pas. Certaines sont publiquement disponibles (comme les normes importantes de l’infrastructure de l’Internet, les RFC – Request For Comments), d’autres réservées à ceux qui paient, ou à ceux qui sont membres d’un club fermé. Certaines normes sont développées de manière publique, où tout le monde a accès aux informations, d’autres sont créées derrière des portes soigneusement closes. Lorsque la norme est développée par une organisation ouverte à tous et toutes, selon des procédures publiques, et que le résultat est publiquement disponible, on parle souvent de normes ouvertes. Et, bien sûr, ces normes ouvertes sont préférables pour l’interopérabilité.

L’une des organisations de normalisation ouverte les plus connues est l’IETF (Internet Engineering Task Force, qui produit notamment la majorité des RFC). L’IETF a développé et gère la norme décrivant le protocole HTTP, le premier cité dans cet article. Mais d’autres organisations de normalisation existent comme le W3C (World-Wide Web Consortium) qui est notamment responsable de la norme ActivityPub.

Par exemple, pour le cas des messageries instantanées que j’avais citées, il y a bien une norme, portant le doux nom de XMPP (Extensible Messaging and Presence Protocol). Google l’utilisait, puis l’a abandonnée, jouant plutôt le jeu de la fermeture.

Difficultés

L’interopérabilité n’est évidemment pas une solution magique à tous les problèmes. On l’a dit, l’appel des soixante-neuf organisations est très modéré puisqu’il demande seulement une ouverture à des tiers. Si cette demande se traduisait par une loi obligeant à cette interopérabilité, tout ne serait pas résolu.

D’abord, il existe beaucoup de moyens pour respecter la lettre d’un protocole tout en violant son esprit. On le voit pour le courrier électronique où Gmail, en position dominante, impose régulièrement de nouvelles exigences aux serveurs de messagerie avec lesquels il daigne communiquer. Le courrier électronique repose, contrairement à la messagerie instantanée, sur des normes ouvertes, mais on peut respecter ces normes tout en ajoutant des règles. Ce bras de fer vise à empêcher les serveurs indépendants de communiquer avec Gmail. Si une loi suivant les préconisations de l’appel était adoptée, nul doute que les GAFA tenteraient ce genre de jeu, et qu’il faudrait un mécanisme de suivi de l’application de la loi.

Plus subtil, l’entreprise qui voudrait « tricher » avec les obligations d’interopérabilité peut aussi prétendre vouloir « améliorer » le protocole. On ajoute deux ou trois choses qui n’étaient pas dans la norme et on exerce alors une pression sur les autres organisations pour qu’elles aussi ajoutent ces fonctions. C’est un exercice que les navigateurs web ont beaucoup pratiqué, pour réduire la concurrence.

Jouer avec les normes est d’autant plus facile que certaines normes sont mal écrites, laissant trop de choses dans le vague (et c’est justement le cas d’ActivityPub). Écrire une norme est un exercice difficile. Si on laisse beaucoup de choix aux programmeuses et programmeurs qui créeront les logiciels, il y a des risques de casser l’interopérabilité, suite à des choix trop différents. Mais si on contraint ces programmeuses et programmeurs, en imposant des règles très précises pour tous les détails, on empêche les logiciels d’évoluer en réponse aux changements de l’Internet ou des usages. La normalisation reste donc un art difficile, pour lequel on n’a pas de méthode parfaite.

Conclusion

Voilà, désolé d’avoir été long, mais les concepts de protocole et d’interopérabilité sont peu enseignés, alors qu’ils sont cruciaux pour le fonctionnement de l’Internet et surtout pour la liberté des citoyen·ne·s qui l’utilisent. J’espère les avoir expliqués clairement, et vous avoir convaincu⋅e de l’importance de l’interopérabilité. Pensez à soutenir l’appel des soixante-neuf organisations !

Après

Et si vous voulez d’autres informations sur ce sujet, il y a :

• Si vous aimez le son plutôt que l’écrit, le podcast de l’APRIL a parlé de l’interopérabilité.