Il est facile d’inscrire « fonctionne en local » à côté d’une douzaine d’autres points, comme s’il s’agissait d’une fonctionnalité parmi d’autres — quelque part entre les options d’exportation et le mode sombre. Nous pensons qu’elle relève d’une autre catégorie. L’endroit où un outil effectue son travail détermine ce qu’il est capable de vous promettre, et le local d’abord, c’est la différence entre une promesse à laquelle vous devez faire confiance et une promesse que vous pouvez vérifier.

C’est cette distinction qui constitue tout l’argument. Quantité de logiciels vous demandent de croire que vos données sont traitées avec soin quelque part où vous ne pouvez pas voir. Le local d’abord vous demande de croire bien moins, parce qu’il y a bien moins à croire. Lorsque le travail s’effectue là où vous êtes, les garanties cessent d’être des assurances sur le comportement d’un système lointain pour devenir des faits sur le vôtre.

Une promesse que vous pouvez vérifier

Lorsque le travail s’effectue sur votre propre machine, la confidentialité cesse d’être une politique pour devenir une propriété. Il n’y a aucune copie de vos données sur un serveur à protéger, à divulguer, à réquisitionner ou à réaffecter — parce qu’il n’y a aucune copie du tout. Aucun compte ne relie discrètement votre activité à votre nom, et aucune télémétrie ne mesure ce que vous faites en arrière-plan. On ne vous demande pas de croire que les données sont traitées avec soin quelque part hors de votre vue ; les données ne quittent tout simplement jamais votre vue.

C’est pourquoi nous refusons de traiter le « local » comme une fonctionnalité. Une fonctionnalité est quelque chose qu’un fournisseur peut vous donner et, tout aussi facilement, reprendre à la version suivante. Une promesse de ce type est structurelle : elle découle de l’endroit où s’effectue le calcul, et vous pouvez la confirmer de la même manière que vous confirmeriez quoi que ce soit de physique — en constatant que rien n’est parti. La vérification ne consiste pas à lire notre politique et à nous croire sur parole. Elle consiste à savoir où se trouvent les données, c’est-à-dire quelque part que vous contrôlez.

La résidence des données au choix du client

Le local d’abord ne signifie pas un arrangement unique et rigide. En milieu clinique, la position honnête est que le bon endroit pour les données dépend de l’établissement, et que c’est l’établissement — non le fournisseur — qui doit décider. Le principe auquel nous tenons est donc que la résidence des données relève du choix du client.

À travers notre plateforme clinique, les outils de périphérie et les pods peuvent être déployés sur site ou selon une configuration hybride, et ce choix s’adapte d’une petite clinique à un grand hôpital. Un cabinet qui souhaite que tout reste entre ses murs peut fonctionner sur site, avec le système d’information et l’archive installés sur du matériel qu’il possède et contrôle. Une organisation qui a des raisons de garder certaines fonctions centralisées et d’autres locales peut opter pour une configuration hybride et tracer la limite là où sa propre gouvernance, et non la nôtre, estime qu’elle doit se trouver. Le rôle de la plateforme est de rendre l’un et l’autre choix pleinement réalisables, plutôt que de pousser tout le monde vers celui qui est le plus commode à exploiter.

Les pods rendent cela concret. EndoPod, PathoPod et TomoPod apportent chacun le système d’information et l’archive là où se déroulent les soins — endoscopie, anatomopathologie, radiologie — et ils le font dans le cadre des normes que le reste de la médecine utilise déjà : DICOM et HL7, avec un traitement conforme à la HIPAA de bout en bout. Choisir le sur site ou l’hybride ne signifie pas sortir de l’écosystème ; cela signifie décider où résident vos données sans renoncer à l’interopérabilité avec tout le reste.

Pourquoi l’hybride tient toujours la promesse

Il serait plus simple d’affirmer que seul un déploiement entièrement sur site compte, et que tout ce qui touche au cloud a rompu la promesse. C’est trop tranchant pour être vrai, et prétendre le contraire ne rendrait pas service aux établissements qui ont des raisons légitimes d’utiliser les deux.

Si l’hybride peut tout de même tenir la promesse, c’est parce que l’échange entre la périphérie et tout ce qui est centralisé est asynchrone et délibéré, plutôt qu’une dépendance en temps réel qu’il faut atteindre avant de pouvoir travailler. Les outils au point de soins effectuent leur travail là où se trouvent les soins ; l’information circule entre la périphérie et le système plus large selon son propre calendrier. Ce choix de conception a deux conséquences qui comptent ici. La première est la résilience : les soins ne s’arrêtent pas parce qu’une connexion distante est lente ou hors service, car le système local n’attend pas un aller- retour pour fonctionner. La seconde est le contrôle : parce que le déplacement des données est quelque chose que l’établissement configure, et non quelque chose qui se produit implicitement à chaque action, la frontière reste là où le client l’a tracée.

L’hybride, mené de cette façon, n’est pas une brèche dans la promesse. C’est la promesse honorée sous un ensemble de contraintes différent — l’établissement décide toujours ce qui reste local et ce qui ne l’est pas, et le système fonctionne toujours lorsque le lien avec le monde extérieur est imparfait.

Confiance, résilience et équilibre des pouvoirs dans le temps

Le local d’abord modifie aussi l’équilibre des pouvoirs dans le temps. Un service situé quelque part peut changer ses règles, augmenter son prix ou fermer, et vous n’y pouvez pas grand-chose. Un outil qui fonctionne là où vous êtes continue de fonctionner selon vos conditions : aucune connexion à perdre au mauvais moment, rien qui cesse de vous appartenir parce qu’une entreprise a décidé de passer à autre chose. Cette indépendance est discrète, mais c’est tout l’enjeu.

Dans un environnement clinique, ce qui est en jeu avec cette indépendance dépasse le simple désagrément. Un flux de travail qui dépend d’un service distant est un flux de travail qui peut être interrompu par quelque chose d’entièrement extérieur au contrôle de la clinique. Garder le travail en local — et garder la résidence des données entre les mains de l’établissement — signifie que les personnes responsables des soins sont aussi celles qui contrôlent les conditions dans lesquelles ces soins se déroulent. La confiance, dans ce cadre, n’est pas un sentiment à l’égard d’un fournisseur. C’est une conséquence de l’endroit où les choses s’exécutent et de qui décide.

Le compromis que nous faisons à dessein

Rien de tout cela ne fait du local d’abord le choix le plus facile à construire. C’est plus difficile, et cela ferme certains raccourcis commodes. Nous acceptons ce compromis délibérément, parce que l’alternative demande aux personnes qui utilisent nos outils de faire plus confiance qu’elles ne le devraient. Une promesse que vous pouvez vérifier vaut davantage qu’une promesse qu’on vous demande simplement d’accepter sur la foi.

Voilà ce que nous voulons dire lorsque nous affirmons que le local d’abord est une promesse plutôt qu’une fonctionnalité. Une fonctionnalité est quelque chose que nous ajoutons. Une promesse est quelque chose que nous devons, et la façon dont nous la tenons est de construire de telle sorte que l’endroit où résident vos données soit votre décision et non la nôtre — afin que l’assurance la plus importante que nous donnons soit une assurance que vous n’avez jamais à accepter sur la foi, parce que vous pouvez simplement constater qu’elle est vraie.