Dan Zarzar, ingénieur dans l’équipe Office Web Apps de Microsoft, Microsoft 365 Blog :

As a next step, we are excited to introduce the upcoming preview availability of Microsoft Fluid components. Right from an email in Outlook for the Web, create connected components that allow you to express your ideas and solve business problems. Fluid Components come in many forms – tables, charts, task lists, and more. […] Because Fluid Components stay updated no matter where they are hosted across Office apps, the information stays updated and relevant. But, unlike a document, a Fluid component is “a little atomic unit of productivity” and fully rendered inline. You do not click on a component and go to another browser tab. You see the entire component in context and can immediately start editing.

Dans les années 1990, Microsoft rêvait déjà des « objets liés et distribués » avec OLE, suivie par Apple avec OpenDoc et les AppleEvents1. Plus récemment, Google Wave et Notion, pour ne citer qu’une paire d’exemples, ont remis cette vieille idée au gout du jour. J’aimerais dire que cette fois, avec des modules open source et une architecture cloud first, c’est la bonne.

Je dois pourtant dire qu’une fois encore, la solution cherche son problème. Microsoft prétend « casser les barrières entre les apps », mais élude la question fondamentale de la nature des objets liés. C’est qu’elle s’inquiète plutôt de la lente dérive du web, qui n’est plus un système de distribution de documents, mais n’est pas encore un système d’exploitation.

C’est un vrai problème, avec des implications cruciales pour une entreprise qui anticipe l’obsolescence du modèle qui a fait sa fortune, au profit d’applications bien à l’étroit dans le cadre étriqué du navigateur. Mais que l’on ne dise pas que la solution « améliore la collaboration », « dégage de la valeur », ou toute autre formule qui démange le bas-ventre des petits chefs.

Non, si Microsoft veut mettre des tableaux dans les textes, c’est qu’il est difficile d’ouvrir un tableur à côté d’un traitement de texte dans une fenêtre du navigateur. Slack et Notion sont parvenues aux mêmes conclusions, toutes les applications finissent par ressembler à Excel, all that is old is new again. Et puis tant pis s’il faut toujours trimer pour collecter les données qui doivent remplir le tableau, ou même avoir l’idée d’un tableau.

Le système de communication interprocessus intégré aux systèmes d’Apple apporte une solution convaincante au problème de la liaison et de la distribution des fonctions. Reste à régler le problème de la liaison et de la distribution des données, autrement dit le problème du memex, qui n’est pas seulement un dépôt « de petites unités atomiques de productivité », mais un système actif et proactif de gestion des connaissances.

Nous en sommes encore loin : les travaux de Roam Research et de Stephen Wolfram sont passionnants, mais exigent que l’homme se mette au service de la machine, et non l’inverse. Sans attendre le renfort des « intelligences artificielles », nous ferions déjà un grand pas en atomisant vraiment les données, qui pourraient être liées directement et arbitrairement2. La donnée l’emporterait sur le fichier, alors que même avec Fluid, c’est bien le fichier qui justifie la donnée.


  1. Ou bien précédée par Apple avec Hypercard, selon votre interprétation de l’expression « objets liés et distribués »↩︎

  2. Oui, je sais, je ne suis pas loin de décrire une base de données relationnelle. ↩︎