Demandez à presque n’importe qui pourquoi un projet d’IA en santé a échoué, et l’on vous racontera une histoire de modèle. Il n’était pas assez précis. Il hallucinait. Il n’a pas tenu sur le nouveau site. C’est parfois vrai. Bien plus souvent, le modèle était bon et n’a jamais eu sa chance, parce qu’il n’a jamais été réellement branché à l’hôpital qu’il devait aider.
La démo tournait sur des données exportées. Le pilote, sur un échantillon propre préparé à la main. Et le système censé fonctionner chaque jour, sur des dossiers réels, là où le travail se fait vraiment, n’a tout simplement jamais été mis en production.
Cet échec a une adresse, et ce n’est pas le modèle. C’est la couche d’intégration. C’est l’argument que je défends depuis des années, et la raison pour laquelle nous avons construit Tietai ainsi. L’IA clinique n’échoue pas au niveau du modèle. Elle échoue en dessous, au niveau des données.
La taxe d’intégration
Un hôpital n’est pas un système. Ce sont des dizaines de systèmes, et presque aucun n’a été conçu pour dialoguer avec les autres. Le DPI parle un dialecte, le système d’information de laboratoire un autre. Les images circulent en DICOM. Les demandes de remboursement en X12. Les documents arrivent en CDA. L’analyseur de paillasse produit un format propriétaire que le fabricant préférerait qu’on ne touche jamais. HL7 v2 sur une interface, FHIR sur la suivante, et chaque système avec son propre désaccord silencieux sur ce à quoi doit ressembler un identifiant patient.
Tout projet d’IA ambitieux dans cet environnement se heurte au même mur. Avant que quiconque puisse faire quoi que ce soit d’intelligent, quelqu’un doit déplacer les données entre ces îlots, les réconcilier, les tenir à jour et les faire circuler quand l’un des îlots change de forme. Ce travail, c’est la taxe d’intégration, et en santé elle est énorme. C’est là que part le budget et que le calendrier dérape. C’est là que meurent la plupart des projets, non pas dans un échec spectaculaire, mais dans un chantier d’intégration de six mois qui épuise la patience de tous et chaque raison d’être du projet.
La vérité qui dérange, c’est qu’un modèle médiocre sur une excellente tuyauterie fera mieux qu’un modèle brillant sans aucune. Le secteur a passé des années à optimiser la mauvaise moitié du problème.
La couche qui paie la taxe
Tiet · Connect est la partie de la plateforme conçue pour faire disparaître cette taxe.
Il parle les langues que l’hôpital parle déjà : HL7 v2, FHIR R4 et R5, X12, DICOM, CDA et les protocoles sur mesure qui n’ont jamais intégré aucun standard. Il déplace les données en temps réel et par lots, entre DPI, PACS, laboratoires, pharmacie et appareils connectés, grâce à une bibliothèque de plus de 200 connecteurs natifs qui savent déjà comment ces systèmes se comportent. Ce qui commence normalement comme un projet d’ingénierie sur mesure commence, sur Tietai, comme une configuration.
Et il fait le travail de découverte pour vous. À mesure que chaque système source est branché, Connect détecte son standard et son authentification : la carte de ce qui est accessible grandit avec l’hôpital, sans nouveau projet d’intégration pour chaque appareil qui arrive dans le service.
Voilà ce que la plupart des plateformes d’intégration savent faire un bon jour. Voici la partie qui compte vraiment.
Une intégration qui reste intégrée
La plupart des intégrations sont construites une fois, puis se dégradent lentement. Une interface est reconfigurée pendant un week-end. Un fabricant pousse une mise à jour de firmware. Un schéma gagne un champ, ou en perd un. Le tuyau qui fonctionnait le vendredi transporte en silence des données cassées ou périmées le lundi, et personne ne s’en aperçoit avant qu’un système en aval ne donne une mauvaise réponse.
Connect est conçu pour considérer cela comme l’état normal du monde, et non comme une exception. Il valide en continu les intégrations dont il dépend et surveille les dérives : un endpoint modifié, un nouveau schéma, un contrat qui ne tient plus. Quand il en détecte une, il retient le flux concerné et signale le problème avant que quoi que ce soit n’agisse sur une information erronée. Dans un système où un agent peut agir réellement sur ce qu’il lit, cette autocorrection n’est pas un confort. C’est une propriété de sécurité.
C’est la différence entre une intégration et une intégration à laquelle on peut encore se fier le trimestre suivant. Un connecteur qui fonctionne aujourd’hui, c’est facile. Un connecteur qui dit toujours la vérité après que l’hôpital a changé autour de lui, c’est tout le travail.
Un connecteur n’est pas un tuyau
C’est ici que l’argument bascule, car l’intégration seule est un poids mort. Une connexion parfaitement entretenue qui déplace les données d’un système à un autre, et s’arrête là, a dépensé un effort énorme pour produire une version plus ordonnée de la même fragmentation. Les données circulent. Rien ne se passe.
L’intégration ne prend de la valeur qu’au moment où elle alimente un workflow. Pas un tableau de bord qu’il faut penser à consulter, mais un workflow qui détecte un événement réel, raisonne dessus et agit en réponse. C’est pourquoi nous n’avons jamais traité Connect comme un produit autonome. C’est le système nerveux des workflows qui reposent sur lui.
Ces workflows vivent dans Tiet · Studio, un éditeur visuel où les personnes qui comprennent un processus peuvent composer le workflow qui l’exécute, avec des agents Tiet · Agentic comme étapes là où le travail a besoin d’IA, sans attendre une équipe d’ingénierie. Un workflow construit là ne lit pas un export. Il s’abonne au flux d’événements en direct que publie chaque système connecté, et réécrit via la même couche de connecteurs que celle où il lit. Percevoir et agir ne sont pas des ambitions ajoutées après coup. Ce sont les mêmes appels d’API, dans deux directions.
Là où Connect et les workflows se rencontrent
Soyons concrets. Un analyseur de laboratoire publie un résultat. À lui seul, ce résultat est un message sur une interface, un parmi des milliers ce jour-là, qui n’a de sens que si la bonne personne regarde le bon écran au bon moment.
Branchez cette même interface sur Connect, et le résultat devient un événement sur une colonne vertébrale partagée dès l’instant où il existe. Un workflow de réconciliation y est déjà abonné. Il voit la nouvelle valeur, la compare à la prescription qui l’a demandée et au dossier auquel elle appartient, remarque que la prescription et le résultat divergent de façon significative, et signale l’écart à un humain avant qu’il ne se propage dans une note, un code ou une facture. Personne n’a eu besoin de surveiller. Le workflow surveillait, parce que l’intégration en dessous a rendu l’événement visible au moment même où il s’est produit.
Multipliez maintenant cela par chaque interface du bâtiment. Le même schéma, la même colonne vertébrale : une prescription restée sans suite, un appareil qui se décalibre, un document arrivé sans son équivalent structuré, une facturation fondée sur un code que le dossier ne justifie plus. Chacun de ces cas est invisible dans un monde de systèmes déconnectés et impossible à manquer dans un monde où une couche d’intégration alimente des workflows toujours en éveil. Les connecteurs rendent l’hôpital lisible. Les workflows le rendent réactif. Aucune des deux moitiés ne vaut grand-chose sans l’autre, et c’est tout l’enjeu.
Tout vous appartient
Placer une couche aussi centrale au cœur d’un hôpital ne fonctionne que si l’hôpital en garde le contrôle. Tietai fonctionne sur site, dans un cloud européen ou en hybride, avec une inférence locale là où vous en avez besoin. Les agents opèrent avec des accès explicitement délimités et n’atteignent que les systèmes et données qu’ils doivent toucher. L’hôpital possède la plateforme, les données et les workflows qui agissent dessus.
La résidence des données se gère là où elle doit l’être, à la frontière. Aux États-Unis, cela signifie un traitement des informations de santé protégées aligné sur HIPAA. En Europe, un traitement des données de santé au niveau du RGPD et une conception déjà préparée pour l’Espace européen des données de santé et ses exigences de 2027. Quand un workflow doit couvrir plusieurs sites, le maillage Tiet · Connect exécute chaque étape là où elle est autorisée et ne laisse franchir une frontière qu’à des résultats désidentifiés et dérivés : un réseau d’hôpitaux peut ainsi partager l’intelligence d’un workflow sans qu’aucun ne partage un dossier patient.
Pourquoi c’est la bonne direction
Nous n’y sommes pas arrivés en raisonnant devant un tableau blanc. Tietai est en production dans des hôpitaux publics et sur des plateformes de télémédecine. Le socle d’intégration est réel, en production, et fait chaque jour le travail ingrat.
Le secteur continue de chercher le modèle de rupture, le composant astucieux qui permettra enfin à l’IA en santé de tenir ses promesses. Le problème n’a jamais été là. Il a toujours été dans l’espace entre les systèmes, dans la taxe que personne ne voulait payer et les connexions que personne ne voulait entretenir. Comblez cet écart, maintenez-le comblé, posez par-dessus des workflows capables d’agir dès que quelque chose se produit, et l’intelligence dont vous disposez déjà commence à compter.
Le modèle n’a jamais été le plus difficile. L’intégration, si, et c’est exactement la partie que nous avons décidé de prendre en main.
Roberto Cruz
CEO, Tietai — The Healthcare Execution Platform
contact@tiet.ai
