Open API oder von Lego lernen

Il n’est pas étonnant que la frustration s’installe. Mais heureusement, nous n’en sommes qu’à la phase 1. Une amélioration se profile à l’horizon et, plutôt que de se résigner, il vaut la peine de jeter un coup d’oeil à d’autres secteurs – par exemple à celui des banques. La numérisation y a déjà fait son entrée il y a vingt ans. Cela se voit bien au fait que nous sommes habitués depuis longtemps, en tant que clients des banques, à effectuer nos transactions quotidiennes de manière purement numérique via une application, un portail ou un distributeur automatique, ou à y consulter des documents et le solde de nos comptes. Désormais, nous devons même payer un supplément si nous souhaitons par exemple recevoir un relevé de compte au format papier.

Dans les banques aussi, la première phase de l’introduction des technologies numériques a consisté à augmenter l’efficacité des processus existants au sein de grands systèmes. Mais nous sommes ensuite entrés dans la phase 2 : l’open banking était la suite logique de la numérisation. L’open banking décrit une évolution par laquelle des mondes de systèmes auparavant fermés sont ouverts au sein d’un établissement bancaire, afin que des systèmes internes puissent échanger des données de manière automatisée avec des applications d’autres fournisseurs – dans le respect bien sûr de toutes les règles de protection des données et avec l’accord des clients. Cela a permis, par exemple, à une nouvelle catégorie de fournisseurs de présenter de manière automatisée et numérique la consolidation de tous les avoirs déposés auprès de différentes banques, c’est-à-dire une fortune globale.

Cela devient possible dès lors que les logiciels sont construits de telle sorte qu’ils peuvent être facilement reliés à d’autres applications par le biais de principes généralement acceptés. « Relier » signifie ici échanger des données de manière standardisée et en temps réel, et déclencher des processus dans d’autres applications. Dans le monde des logiciels, on parle d’Application Programming Interfaces (API). Il ne s’agit pas du simple téléchargement de données au format Excel ou CSV et de leur chargement « du jour au lendemain » dans un autre système, ce qui est encore trop souvent considéré comme une « interface ». Dans un univers API, l’objectif est que chaque système puisse déclencher directement des processus dans d’autres systèmes. Par exemple de manière qu’une plateforme de locataires puisse, à partir de la déclaration de sinistre d’un habitant, créer directement un mandat dans un système en aval d’un gestionnaire ou d’un artisan et déclencher des processus consécutifs, sans qu’un collaborateur ou une collaboratrice du gestionnaire doive copier les données d’une application à une autre.

Pour simplifier les choses, on peut comparer cela aux Lego : ce qui compte le plus sur les briques Lego, ce sont les picots. Quiconque achète des Lego sait qu’il n’a pas à se soucier de savoir si les briques vont s’assembler. Jaune, rouge, verte, bleue, droite ou oblique – l’aspect d’une brique n’a aucune importance. Tout s’emboîte facilement grâce aux picots bien connus.

Les API sont les picots du monde des logiciels. Et pour reprendre l’image de la « legoïsation » : si les picots sont standardisés, il est possible de construire les plus belles nouvelles réalisations. De même, le mouvement de l’open banking a donné naissance à de nombreux nouveaux modèles commerciaux au profit des clients – les modèles commerciaux inefficaces étaient déjà sous pression depuis longtemps. Ce n’est pas pour rien que l’Association suisse des banquiers déclare que l’« open banking […] est appelé à influencer et à transformer durablement le secteur bancaire. L’Association suisse des banquiers considère qu’il recèle un fort potentiel pour la place financière. »

Le besoin d’Open API et d’un mouvement « Open Real Estate » correspondant est évident. Les tâches gigantesques dans le domaine du développement durable ou l’évolution vers une économie circulaire ne peuvent se passer d’une disponibilité continue des données. Mais les utilisatrices et utilisateurs des biens immobiliers profiteront aussi massivement de la possibilité de relier entre eux les différents systèmes techniques. Enfin, les professionnels de l’immobilier susmentionnés seront moins perdus s’ils savent que leurs systèmes fonctionnent correctement ensemble.

Dans l’environnement bancaire, l’évolution vers des interfaces ouvertes a été soutenue par la réglementation, ce qui montre l’importance de l’ouverture des systèmes fermés, même du point de vue du régulateur. Par exemple, la 2e Directive sur les services de paiement (PSD2) a largement contribué à l’évolution vers des API ouvertes, afin que les utilisateurs puissent consolider leurs données de compte dans différents systèmes. Dans l’environnement immobilier, une telle pression réglementaire n’est pas manifeste, mais peut-être pas non plus nécessaire.

Au fond, que faut-il pour créer un monde logiciel ouvert ? Pas grand-chose, étonnamment. Les développeurs de logiciels savent depuis longtemps ce que sont les API ouvertes. Cela peut être décrit en quelques pages. Du côté des fournisseurs, nous n’avons donc aucun problème de compréhension. En revanche, du côté des donneurs d’ordre, les API ouvertes doivent faire partie intégrante de chaque appel d’offres afin d’amener le secteur immobilier vers un monde plus ouvert. Et si les donneurs d’ordre ne disposent pas des compétences nécessaires, il est possible de les acheter ou même de les centraliser via des organisations sectorielles. Car une chose est claire : si une orientation vers des interfaces ouvertes devient le critère principal de toute acquisition de système, le monde des fournisseurs s’y adaptera automatiquement – ou alors le tri se fera naturellement.

Après sept ans de numérisation, déclarons donc pour les sept prochaines années l’ère de la légoïsation dans le secteur immobilier ! Pour qu’à la fin de cette décennie, il soit normal que les propriétaires et les prestataires de services immobiliers se procurent des modules de logiciels individuels en fonction de leurs préférences personnelles et qu’ils n’aient plus du tout à se demander, grâce aux picots existants sous forme d’API, si ces modules peuvent être assemblés pour former un bel ensemble.