La clinique de Chiba
Il faut parfois partir d’une fiction pour construire une situation utile.
Non pour prédire.
Pour tester.
La scène pourrait se dérouler à Chiba City, dans un futur très proche. Pas dans la Chiba noire de Neuromancer. Pas non plus dans une ville entièrement imaginaire. Dans un Japon légèrement déplacé, où les infrastructures de santé, les interfaces corporelles, les assistants IA, les chaînes logicielles et les systèmes de supervision se sont rapprochés sans que les catégories de sécurité aient suivi au même rythme.
Une clinique privée de neuro-réhabilitation y propose un service haut de gamme : récupération fonctionnelle après accident, assistance motrice, traitement de troubles neurologiques, accompagnement de patients augmentés, rééducation par interfaces immersives. Les patients portent des dispositifs connectés. Certains utilisent des implants médicaux. D’autres disposent d’exosquelettes légers. Les séances sont suivies par des capteurs. Les données sont analysées par des modèles d’IA. Les praticiens utilisent un assistant interne pour synthétiser les dossiers, proposer des protocoles, planifier les mises à jour et coordonner les équipes.
La clinique est moderne.
Elle est efficace.
Elle est donc vulnérable.
Son infrastructure paraît maîtrisée. Les dispositifs médicaux sont certifiés. Les mises à jour sont signées. Les accès sont fédérés. Le cloud est sécurisé. Les journaux remontent dans une plateforme de supervision. Les équipes utilisent un outil de ticketing. Les fournisseurs sont contractuellement encadrés. L’assistant IA est présenté comme un soutien, non comme un décideur. La documentation dit que l’humain reste dans la boucle.
Puis les premiers signes apparaissent.
Rien de spectaculaire.
Un patient signale une sensation de décalage dans la réponse de son dispositif. Un autre évoque une fatigue anormale après une séance. Un praticien remarque que certaines recommandations de l’assistant IA sont plus agressives qu’à l’habitude. Un technicien observe une différence entre deux versions de firmware pourtant supposées identiques. Un log disparaît d’un tableau de bord, puis réapparaît dans une autre vue. Un fournisseur assure que la mise à jour est saine. La clinique n’a aucune preuve claire du contraire.
L’incident commence comme commencent beaucoup de crises cyber sérieuses : par une incohérence.
Pas une panne.
Pas une alerte rouge.
Une incohérence.
La direction hésite. Faut-il suspendre les séances ? Faut-il désactiver les dispositifs connectés ? Faut-il prévenir les patients ? Faut-il accuser le prestataire ? Faut-il isoler l’assistant IA ? Faut-il couper les accès cloud ? Faut-il basculer sur un protocole manuel ? Chaque option crée un risque. Continuer expose les patients. Suspendre panique le public. Accuser trop tôt détruit une relation contractuelle. Attendre augmente la surface de dommage.
La clinique découvre alors que sa modernité n’est pas un ensemble de technologies.
C’est une chaîne d’action.
Dispositifs corporels, firmware, capteurs, passerelles réseau, cloud, modèles d’IA, identité fédérée, comptes de service, pipelines de mise à jour, registres logiciels, logs, outil de ticketing, prestataires, praticiens, patients : aucun élément ne suffit à expliquer la situation. L’incident circule entre eux.
C’est précisément ce qui rend la situation intéressante.
Elle n’est pas seulement médicale.
Elle n’est pas seulement cyber.
Elle est cyber-physique, logicielle, identitaire, juridique, cognitive et organisationnelle.
C’est une situation Neuromancer.
Pas parce qu’elle imite le roman. Mais parce qu’elle reprend sa structure profonde : le corps devient interface, l’accès devient capacité d’existence, la clinique devient lieu de transformation technique, l’IA devient puissance ambiguë, le réseau devient milieu de survie.
La question n’est plus : quelle machine est compromise ?
La question devient : où le monde a-t-il été altéré ?
La situation : quand le corps devient endpoint
Dans cette clinique de Chiba, le corps est le premier terminal.
C’est le point le plus difficile à accepter pour les architectures traditionnelles. Elles savent protéger des postes, des serveurs, des applications, des bases de données, des terminaux mobiles. Elles savent moins bien penser une prothèse, un implant, un exosquelette, un dispositif de stimulation, un environnement de rééducation immersive comme partie d’une surface cyber globale.
Pourtant, c’est exactement ce qu’ils sont.
Un dispositif corporel connecté possède un firmware, une configuration, une télémétrie, une identité, une politique de mise à jour, une dépendance fournisseur, une chaîne de maintenance, une surface radio ou réseau, une interface de supervision, parfois une application mobile, parfois un jumeau numérique, parfois une intégration cloud. Il n’est jamais seulement un objet médical. Il est un nœud.
Et lorsqu’un nœud agit sur le corps, la cybersécurité change de gravité.
Une erreur de recommandation dans un tableau de bord financier peut coûter de l’argent. Une erreur de commande dans un dispositif de rééducation peut modifier un geste, une fatigue, une douleur, une récupération, une confiance corporelle. La disponibilité, l’intégrité et la confidentialité ne suffisent plus à décrire le risque. Il faut ajouter la sécurité physique, la responsabilité clinique, la continuité de soin, le consentement, la preuve et la réversibilité.
Dans cette situation, l’attaque ne commence pas par une prise de contrôle visible du dispositif. Elle commence plus haut, dans la chaîne logicielle.
Un package utilisé par un sous-traitant du fournisseur a été compromis. Il ne contient pas une charge malveillante évidente. Il modifie légèrement un script de préparation des builds. Ce script n’altère pas tous les firmwares. Il ne crée pas non plus une porte dérobée classique. Il introduit une divergence minime dans la manière dont certains paramètres de calibration sont empaquetés, signés, puis distribués à une catégorie précise de dispositifs.
La signature est valide.
Le processus semble propre.
Les logs ne montrent pas d’intrusion directe.
L’attaque ne ressemble pas à une attaque.
Elle ressemble à une production normale.
C’est le premier enseignement : la supply chain logicielle est devenue un espace de manipulation du réel.
Dans une architecture ancienne, le logiciel était livré, installé, utilisé. Dans une architecture moderne, le logiciel se transforme en continu. Il dépend de pipelines, de runners, de secrets, de registres, d’artefacts, de dépendances, de signatures, d’environnements de test, de politiques de déploiement. La compromission ne vise donc plus seulement le produit final. Elle vise le processus qui décide ce qui devient produit.
L’adversaire n’a pas besoin de briser la porte si la chaîne lui fabrique une clé.
La clinique ne voit pas immédiatement cette attaque parce que ses contrôles portent sur les éléments visibles : disponibilité des services, validité des certificats, statut des mises à jour, conformité fournisseur, absence d’alerte EDR majeure. Elle voit le système tel qu’il se déclare. Elle ne voit pas encore le système tel qu’il se produit.
Le deuxième niveau concerne l’identité.
Le partenaire technique dispose de comptes de service pour pousser certaines mises à jour et collecter des télémétries. Ces comptes sont limités en théorie. Mais l’un d’eux possède des privilèges historiques maintenus pour compatibilité avec d’anciens dispositifs. Ce droit n’apparaît plus dans les diagrammes de l’architecture courante. Il existe pourtant dans la configuration effective.
C’est un ghost.
Un droit sans récit.
Un accès sans mémoire.
Une survivance technique.
L’adversaire l’utilise non pour tout contrôler, mais pour rester dans les limites du vraisemblable. Il ne veut pas déclencher d’alerte. Il veut produire une anomalie suffisamment faible pour être interprétée comme un problème clinique, une erreur de calibration, une variabilité patient ou un bug fournisseur.
C’est le deuxième enseignement : l’attaque cyber moderne cherche parfois moins à entrer qu’à se faire accepter comme explication normale.
Le troisième niveau concerne l’IA.
L’assistant interne de la clinique n’a pas été conçu pour commander les dispositifs. Il synthétise, suggère, classe, priorise. Il a accès aux dossiers, aux historiques de séances, à la documentation technique, aux tickets d’incident, aux recommandations fournisseurs. Il fonctionne avec un système de retrieval interne. Les praticiens le consultent pour gagner du temps.
Après la compromission de certains artefacts, l’assistant commence à proposer des protocoles légèrement différents. Rien d’absurde. Rien qui ressemble à une hallucination grotesque. Des ajustements subtils. Des recommandations compatibles avec la documentation telle qu’il la consulte. Mais cette documentation a été partiellement altérée dans un espace secondaire de synchronisation.
L’IA n’invente pas l’erreur.
Elle la stabilise.
Elle transforme une altération documentaire en recommandation clinique crédible.
C’est le troisième enseignement : dans une organisation augmentée, l’IA peut devenir un amplificateur de compromission douce.
Elle ne fait pas l’attaque. Elle lui donne une interface humaine. Elle la rend lisible, acceptable, professionnelle. Elle réduit la friction cognitive qui aurait pu sauver l’organisation. Un praticien aurait peut-être douté d’un paramètre isolé. Il doute moins lorsque l’assistant lui présente une synthèse cohérente, contextualisée, conforme au style habituel.
Le quatrième niveau concerne les traces.
Les logs existent. Ils sont nombreux. Trop nombreux. Ils remontent dans plusieurs plateformes : supervision médicale, SIEM, outil fournisseur, ticketing, monitoring cloud, journaux de l’assistant IA. Chaque source donne une partie du monde. Aucune ne donne le monde.
Certaines traces contiennent des identifiants techniques. D’autres masquent les détails pour des raisons de confidentialité médicale. Les logs du fournisseur ne sont pas accessibles en temps réel. Les journaux de l’assistant IA conservent les prompts et réponses, mais pas toujours les documents sources récupérés au moment exact de la recommandation. Les logs de build existent, mais dans l’environnement du sous-traitant.
La clinique voit beaucoup.
Mais elle ne voit pas juste.
C’est le quatrième enseignement : la visibilité n’est pas la compréhension.
Un système peut être saturé de logs et rester aveugle. La cybersécurité ne consiste pas seulement à collecter. Elle consiste à corréler, hiérarchiser, préserver l’intégrité des traces, connaître leur contexte et pouvoir reconstruire une chronologie exploitable. Sans cela, la trace devient bruit. Et dans une crise cyber-physique, le bruit coûte du temps, donc potentiellement des corps.
L’analyse : ce que la fiction rend visible
Cette situation inspirée de Neuromancer n’a pas pour but de produire une histoire spectaculaire. Elle sert à tester une architecture de pensée.
Elle montre d’abord que le corps est devenu une surface cyber.
Cette phrase doit être prise techniquement. Un corps augmenté, appareillé, assisté, mesuré ou interfacé n’est pas seulement un sujet de philosophie ou d’éthique. Il devient un point d’articulation entre firmware, données, identité, télémétrie, responsabilité et soin. La sécurité du corps dépend alors de chaînes qui ne sont pas dans le corps : cloud, fournisseur, pipeline, documentation, modèle, accès, logs.
Le corps n’est pas isolé.
Il est le dernier état d’une chaîne technique.
C’est pourquoi la sécurité des dispositifs cyber-physiques doit être pensée au-delà du device. Il faut auditer les mises à jour, les dépendances, les secrets, les identités de service, les environnements de build, les droits fournisseurs, les mécanismes de rollback, les logs, les accès de maintenance, les processus de validation clinique. La certification initiale ne suffit pas. Le risque vit dans le cycle de vie.
La situation rappelle ensuite que l’IA peut devenir un vecteur de normalisation de l’anomalie.
Beaucoup de discours sur l’IA en cybersécurité se concentrent sur les attaques directes : prompt injection, extraction de données, empoisonnement, jailbreak, hallucination. Ces risques sont réels. Mais il existe une menace plus subtile : l’IA peut rendre une erreur crédible parce qu’elle la reformule dans le langage de l’organisation.
Un document altéré peut devenir synthèse.
Une synthèse peut devenir recommandation.
Une recommandation peut devenir protocole.
Un protocole peut devenir action sur le corps.
La chaîne est courte.
C’est pourquoi les systèmes d’IA connectés à des environnements métiers critiques doivent être traités comme des composants de sécurité. Il faut tracer les sources utilisées. Versionner les documents. Contrôler les connecteurs. Limiter les droits. Séparer recommandation et action. Conserver les contextes de génération. Tester les scénarios d’altération documentaire. Prévoir un mode dégradé sans assistant.
L’IA ne doit pas être seulement évaluée sur la qualité de ses réponses.
Elle doit être évaluée sur sa capacité à ne pas devenir l’avocat élégant d’une compromission.
La situation montre aussi que l’identité est le vrai cœur de la crise.
L’attaque réussit parce qu’un droit ancien subsiste. Ce n’est pas un exploit spectaculaire. C’est une mémoire mal entretenue. Un privilège historique, conservé pour compatibilité, devient passage. Cette banalité est justement inquiétante. Beaucoup de crises ne naissent pas d’un coup de génie adverse. Elles naissent d’un droit oublié qui rencontre une chaîne trop complexe.
L’ingénierie cyber doit donc devenir beaucoup plus sévère sur le cycle de vie des identités. Comptes de service, rôles cloud, accès fournisseurs, certificats, tokens, secrets de pipeline, accès de maintenance : tout doit avoir un propriétaire, une durée, une justification, une trace, une limite, une procédure de révocation. L’absence de propriétaire est déjà un risque. Le droit sans mémoire est déjà un ghost.
Ce scénario révèle enfin que la réponse de crise doit être préparée comme une doctrine cyber-physique.
Dans une clinique, couper n’est pas simple. Suspendre les dispositifs peut protéger certains patients et en fragiliser d’autres. Désactiver l’assistant IA peut ralentir les praticiens. Revenir au manuel peut être nécessaire, mais seulement si les équipes l’ont pratiqué. Informer les patients trop tôt peut paniquer. Les informer trop tard peut détruire la confiance. Accuser le fournisseur peut être prématuré. Ne rien dire peut devenir intenable.
La technique ne supprime pas le dilemme.
Elle le rend plus dense.
Il faut donc prévoir des exercices spécifiques : compromission de firmware, altération de documentation, assistant IA non fiable, logs contradictoires, fournisseur indisponible, patient exposé, presse alertée, régulateur saisi. Ces scénarios doivent être joués par les équipes techniques, médicales, juridiques, communication, direction et fournisseurs. Sinon, chacun découvrira son rôle au moment de la crise.
Une doctrine de cybersolidité cyber-physique devrait donc comporter au minimum huit capacités.
Première capacité : inventaire précis des dispositifs, versions, dépendances et chemins de mise à jour.
Deuxième capacité : contrôle fort des identités fournisseurs et comptes de service.
Troisième capacité : signature, vérification et traçabilité des artefacts logiciels.
Quatrième capacité : SBOM et suivi des dépendances jusqu’aux sous-traitants critiques.
Cinquième capacité : journalisation intégrée entre dispositif, cloud, assistant IA, fournisseur et SIEM.
Sixième capacité : mode dégradé clinique permettant de continuer sans assistant IA ni mise à jour distante.
Septième capacité : procédure de révocation rapide des accès, tokens, certificats et connecteurs.
Huitième capacité : exercice de crise cyber-physique incluant patients, régulateur, fournisseur et direction.
Ce sont des capacités concrètes.
C’est là que la fiction devient utile.
Elle ne vaut pas parce qu’elle raconte un futur séduisant. Elle vaut parce qu’elle force l’architecture à se révéler. Elle oblige à regarder les points de jonction : entre corps et logiciel, entre IA et documentation, entre fournisseur et clinique, entre logs et preuve, entre accès et souveraineté, entre sécurité technique et décision humaine.
Une situation Neuromancer n’est donc pas une imitation de Gibson.
C’est un banc d’essai.
Elle prend l’intuition du roman — le corps comme interface, l’accès comme existence, la clinique comme lieu de transformation, l’IA comme puissance ambiguë, le réseau comme milieu — et la transforme en problème cyber.
C’est peut-être cela, la méthode la plus utile : prendre une fiction non pour la commenter, mais pour la mettre au travail.
La fiction pose le monde.
L’ingénierie révèle les chaînes.
La cybersécurité identifie les ghosts.
La crise teste les décisions.
La capacité reste.
Dans cette clinique de Chiba, l’incident n’était pas seulement une attaque. C’était une question posée à notre manière de concevoir les systèmes. Que devient la sécurité lorsque le logiciel touche le corps ? Que devient la preuve lorsque les logs sont fragmentés ? Que devient l’identité lorsque les agents humains, machines et IA partagent des droits ? Que devient la responsabilité lorsque la recommandation passe par un modèle ? Que devient la confiance lorsque la chaîne de production du logiciel devient elle-même le champ de bataille ?
Ces questions ne sont plus de la fiction.
Elles arrivent avec les implants, les assistants IA, les dispositifs médicaux connectés, les chaînes logicielles, les villes intelligentes, les robots, les interfaces immersives et les infrastructures cyber-physiques.
Neuromancer avait placé Chiba City au seuil du cyberspace.
Nous pouvons aujourd’hui y placer une autre question : comment défendre un monde où le corps, le logiciel, l’identité et l’IA appartiennent à la même surface ?
La réponse ne sera pas seulement technique.
Mais sans ingénierie cyber rigoureuse, elle ne sera rien.
La clinique de Chiba n’existe pas encore.
Ses ghosts, eux, existent déjà.