J’écris depuis Chiba City. Ce n’est pas une image. Ce n’est pas un effet de style. C’est un lieu réel, et c’est précisément parce qu’il est réel qu’il permet de relire autrement l’un des grands imaginaires du cyber contemporain.

From Chiba City, with Ghosts

Dans Neuromancer, William Gibson a fait de Chiba City un seuil : le lieu du corps abîmé, de l’accès perdu, de la clinique, du trafic, du réseau, de l’intelligence artificielle et de la survie dans le cyberspace. La Chiba réelle n’est évidemment pas celle du roman. Mais la fiction n’a jamais eu besoin de coïncider avec la géographie pour produire une vérité. Elle suffit parfois à condenser des forces que le présent met plus longtemps à nommer.

Depuis Chiba City, le cyberpunk cesse d’être une esthétique. Il devient une méthode de lecture.

Il permet de voir que la cybersécurité ne protège plus seulement des machines. Elle protège des continuités : continuité des identités, des accès, des traces, des corps, des modèles, des chaînes logicielles, des infrastructures, des décisions. Elle protège ce qui permet à une organisation, une ville, un hôpital, une armée ou une entreprise de continuer à agir dans un monde devenu instable.

À l’approche du Forum INCYBER Japon, consacré à la cybersolidité, cette question prend une forme très concrète. La cybersolidité ne peut plus signifier seulement la résistance d’un système à un incident. Elle doit désigner la capacité d’un monde numérique à rester intelligible sous contrainte. Voir encore. Nommer encore. Révoquer encore. Isoler encore. Restaurer encore. Décider encore.

Le cyberpunk aide à comprendre pourquoi cet objectif est devenu si difficile.

Car le monde numérique est désormais peuplé de ghosts.

Le ghost n’est plus une métaphore

Le ghost n’est pas un motif décoratif.

Dans le cyber contemporain, le ghost est une catégorie technique.

C’est ce qui continue d’agir après avoir disparu de la représentation officielle du système. C’est l’accès non révoqué, le compte dormant, le secret exposé, le token oublié, l’identité de service jamais auditée, la dépendance logicielle abandonnée, le connecteur SaaS conservé par habitude, le dépôt ancien qui contient encore une clé, le bucket mal configuré, la machine virtuelle orpheline, l’image de conteneur vulnérable, le log qui conserve ce qu’il n’aurait jamais dû enregistrer.

Un système moderne ne se contente pas de fonctionner. Il se souvient mal.

Il garde trop. Il oublie mal. Il réplique. Il copie. Il journalise. Il met en cache. Il transforme. Il indexe. Il entraîne. Il propage. Il laisse derrière lui des présences techniques qui ne sont plus pleinement visibles, mais qui restent capables de produire des effets.

C’est là que le ghost apparaît.

Un ancien prestataire conserve un accès VPN. L’organisation ne le voit plus comme un acteur. Pourtant, son accès existe encore.

Un compte de service dispose de privilèges trop larges. Personne ne l’utilise directement. Pourtant, il peut agir.

Une clé API a été publiée dans un dépôt privé, puis copiée dans un fork, puis indexée par un outil interne, puis oubliée. On pense l’avoir supprimée. Elle continue de survivre ailleurs.

Un modèle d’IA a été entraîné sur des données que l’on ne sait plus isoler. Il ne conserve pas ces données comme une base classique. Il en conserve des influences. Il peut les restituer, les déformer, les faire réapparaître sous une autre forme.

Une dépendance open source n’est plus maintenue. Elle reste pourtant embarquée dans une chaîne de production. Elle devient un fantôme de logiciel : morte en maintenance, vivante en production.

Ces ghosts sont dangereux parce qu’ils contredisent la fiction administrative des systèmes.

La documentation dit que l’accès est clos.
La réalité dit qu’un token survit.

Le registre dit que le composant est secondaire.
La réalité dit qu’il est dans le chemin critique.

La gouvernance dit que le modèle est contrôlé.
La réalité dit qu’il parle avec des données dont personne ne connaît plus exactement la trajectoire.

La politique de sécurité dit que les privilèges sont maîtrisés.
La réalité dit qu’une chaîne d’assumptions entre rôles cloud permet une escalade invisible.

La cybersécurité n’est donc plus seulement l’art de fermer des portes. Elle devient l’art de rechercher ce qui n’aurait pas dû rester ouvert.

Il faut alors déplacer la question centrale.

Il ne suffit plus de demander : où est la faille ?

Il faut demander : qu’est-ce qui continue d’agir ?

Depuis quelle identité ?
Avec quel secret ?
Par quel compte de service ?
Dans quel pipeline ?
À travers quelle dépendance ?
Avec quel modèle ?
Dans quel log ?
Depuis quelle trace ?
Sous quelle autorité apparente ?
Dans quel état réel du système ?

La faille n’est pas toujours un trou.

Elle est parfois une survivance.

C’est précisément ce que le cyberpunk permet de penser. Chez Gibson, l’accès n’est jamais neutre. Il est une condition d’existence. Perdre l’accès au cyberspace n’est pas seulement perdre un outil. C’est perdre une capacité d’agir dans le monde. L’accès devient presque corporel. Il détermine ce que l’on peut faire, voir, atteindre, détourner, réparer, vendre, voler ou devenir.

Nos architectures contemporaines ont rejoint cette intuition.

Une identité numérique n’est plus un simple identifiant. C’est une délégation d’action. Un compte compromis ne donne pas seulement accès à des fichiers. Il donne une voix, une autorité, une position dans une chaîne de confiance. L’adversaire ne force pas toujours le système depuis l’extérieur. Il parle parfois depuis l’intérieur avec une identité légitime.

C’est pourquoi l’IAM est devenu un champ de bataille central.

Utilisateurs humains, comptes de service, identités machines, certificats, tokens temporaires, clés SSH, secrets applicatifs, bots, agents IA, workloads, fonctions serverless : chacun peut devenir un ghost s’il échappe au cycle normal de contrôle. L’identité est devenue le périmètre, mais elle est aussi devenue le brouillard.

Une architecture solide n’est pas celle qui prétend supprimer tout risque. C’est celle qui sait maintenir une lisibilité stricte de ses droits d’action.

Qui peut faire quoi ?
Depuis où ?
Pour combien de temps ?
Avec quelle justification ?
Avec quelle trace ?
Avec quelle révocation possible ?
Avec quelle détection d’anomalie ?

La même logique vaut pour les chaînes logicielles.

Nous ne déployons plus seulement du code. Nous déployons des généalogies. Un logiciel contemporain transporte avec lui des dépendances, des bibliothèques, des images, des scripts, des artefacts, des registres, des environnements de build, des mainteneurs, des signatures, des vulnérabilités connues ou inconnues, des scripts d’installation, des secrets potentiellement exposés.

Une compromission de supply chain ne vise pas seulement une application.

Elle vise le devenir du logiciel.

Elle attaque le moment où le code se transforme en produit, où le produit se transforme en artefact, où l’artefact se transforme en déploiement, où le déploiement devient environnement de production. Elle ne casse pas seulement un système. Elle contamine une chaîne de confiance.

C’est pourquoi le SBOM, la signature des artefacts, la gestion des secrets, l’isolation des runners CI/CD, le contrôle des dépendances, l’analyse des images de conteneurs, la séparation des environnements et la vérification des permissions ne sont pas des détails d’ingénierie. Ce sont des instruments de chasse aux ghosts.

Ils servent à rendre visible ce qui agit en dessous.

L’IA ajoute une autre couche.

Elle ne crée pas seulement de nouveaux usages. Elle crée de nouvelles survivances. Les données peuvent être absorbées, vectorisées, résumées, indexées, transformées en embeddings, réutilisées dans des systèmes RAG, enregistrées dans des traces d’exécution, déplacées vers des outils tiers, reprises par des agents, exposées par des prompts ou rappelées indirectement par un modèle.

Dans une base de données classique, la suppression garde encore un sens relativement identifiable.

Dans un système d’IA, la suppression devient plus trouble.

Que retire-t-on exactement ?
La donnée ?
Son embedding ?
Sa trace ?
Sa reformulation ?
Son influence sur le comportement du modèle ?
Son usage dans un prompt ?
Sa présence dans un log ?
Son apparition dans un outil connecté ?

L’IA fabrique des ghosts statistiques, sémantiques et opérationnels.

C’est pourquoi elle doit être traitée comme une architecture cyber complète, et non comme un simple outil conversationnel. Un agent IA connecté à la messagerie, au CRM, au code, au ticketing et à la documentation interne n’est pas un assistant. C’est une identité opérationnelle. S’il accède, il doit être limité. S’il agit, il doit être journalisé. S’il déclenche des actions, il doit être gouverné. S’il utilise des outils, ses permissions doivent être réduites. S’il manipule des données sensibles, il doit être traité comme une surface critique.

L’IA ne rend pas le système plus immatériel.

Elle multiplie les présences.

Et certaines deviennent invisibles.

La cybersolidité comme chasse aux présences invisibles

La cybersolidité ne doit donc pas être comprise comme une promesse d’invulnérabilité.

Cette promesse serait fausse.

Un système moderne est trop distribué, trop dépendant, trop automatisé, trop traversé par des tiers et des modèles pour prétendre à la pureté. Il accumule des exceptions, des héritages, des droits, des contournements, des dépendances, des raccourcis, des outils temporaires devenus permanents. Il vieillit. Il se transforme. Il oublie les raisons de ses propres configurations.

La solidité cyber ne consiste pas à nier cette réalité.

Elle consiste à rester capable de la gouverner.

Une organisation cybersolide sait d’abord ce qu’elle possède. Pas en théorie. En continu. Elle connaît ses actifs, ses identités, ses dépendances, ses secrets, ses chemins d’accès, ses fournisseurs, ses modèles, ses données sensibles, ses systèmes exposés, ses environnements critiques. Elle réduit le nombre de ghosts possibles parce qu’elle refuse de laisser le système se peupler sans mémoire.

Une organisation cybersolide sait ensuite révoquer. C’est un point fondamental. Beaucoup de systèmes savent accorder. Beaucoup savent mal retirer. Or la sécurité se mesure autant à la qualité de la révocation qu’à celle de l’autorisation. Un droit temporaire qui devient permanent est déjà une faille en attente. Un accès non retiré est une présence future. Un compte oublié est une invitation silencieuse.

Une organisation cybersolide sait aussi isoler. Le monde numérique moderne est un monde de propagation. Une compromission ne devient crise que lorsqu’elle trouve des chemins. Segmentation réseau, séparation des environnements, moindre privilège, durcissement des accès, cloisonnement des données, contrôle des flux sortants, isolation des workloads : tout cela n’a qu’un but réel, empêcher un ghost de devenir souveraineté.

Elle sait journaliser sans se mettre en danger. Les logs sont les yeux du système. Sans eux, il n’y a pas d’enquête. Mais les logs peuvent eux-mêmes devenir des dépôts de secrets, des cartes d’architecture, des archives de comportements sensibles. La visibilité est une force, mais elle doit être gouvernée. Trop peu de traces rendent aveugle. Trop de traces mal protégées créent une autre surface d’attaque.

Elle sait restaurer. Une sauvegarde non testée est une croyance. Une restauration testée est une capacité. La différence est immense. Dans une crise cyber, la question n’est pas seulement de savoir si des sauvegardes existent. Il faut savoir si elles sont saines, isolées, récentes, testées, priorisées, compatibles avec les dépendances réelles, et si l’organisation sait restaurer dans l’ordre qui maintient une continuité d’activité.

Elle sait enfin décider. C’est peut-être le point le plus négligé. Une crise cyber n’est pas seulement une crise technique. C’est une crise de preuve, de confiance, de responsabilité, de communication, de temps. Faut-il couper ? Faut-il communiquer ? Faut-il accuser un fournisseur ? Faut-il prévenir les clients ? Faut-il isoler une filiale ? Faut-il suspendre un modèle ? Faut-il désactiver un assistant IA ? Faut-il revenir à un mode manuel ? Faut-il reconnaître que l’on ne sait pas encore ?

La cybersolidité se mesure dans ces moments-là.

Non pas lorsque tout fonctionne.

Mais lorsque le monde se déforme.

C’est ici que Chiba City, Gibson et le motif du ghost redeviennent utiles. Ils nous rappellent que le cyber n’est pas seulement une infrastructure technique. C’est un environnement de présences. Des humains, des comptes, des agents, des scripts, des modèles, des bots, des dépendances, des logs, des traces, des adversaires, des fournisseurs, des héritages, des erreurs y coexistent. Certains sont visibles. D’autres non. Certains sont légitimes. D’autres l’ont été et ne devraient plus l’être. Certains sont morts administrativement mais actifs techniquement.

Le cyber est peuplé.

Cette idée change la sécurité. Elle oblige à penser les systèmes comme des milieux vivants de droits, de traces, de décisions et de restes. Elle oblige à sortir d’une vision trop propre de l’architecture. Les schémas sont nécessaires, mais les schémas mentent par simplification. Ils montrent les composants. Ils montrent moins les survivances.

La vraie cartographie cyber doit donc chercher les ghosts.

Où sont les accès qui n’ont plus de propriétaire ?

Où sont les secrets dont personne ne sait s’ils ont été copiés ?

Où sont les dépendances dont personne ne vérifie la maintenance ?

Où sont les agents IA qui disposent de droits supérieurs à ce que leur statut suggère ?

Où sont les données sensibles reprises dans des outils secondaires ?

Où sont les logs qui enregistrent plus que nécessaire ?

Où sont les environnements de test connectés à la production par négligence ?

Où sont les exceptions devenues normes ?

Où sont les scripts écrits pour une urgence et jamais supprimés ?

Où sont les corps techniques qui continuent de vivre après la mort de leur justification ?

C’est cela, la question des ghosts.

Elle est cyber, mais elle est aussi organisationnelle. Une organisation fabrique ses ghosts par fatigue, par urgence, par dette, par croissance, par externalisation, par manque de mémoire. Elle ajoute un fournisseur, puis un autre. Elle ouvre un accès temporaire. Elle déploie une API. Elle teste un outil IA. Elle connecte un SaaS. Elle crée un compte d’administration. Elle intègre un package. Elle accélère un pipeline. Elle corrige un incident. Elle oublie ensuite de refermer.

La plupart des ghosts ne naissent pas de la malveillance.

Ils naissent de la continuité.

C’est pourquoi la cybersécurité doit être pensée comme discipline de la mémoire active. Non pas seulement mémoire de l’incident, mais mémoire de l’architecture. Mémoire des droits accordés. Mémoire des dépendances acceptées. Mémoire des exceptions. Mémoire des données. Mémoire des modèles. Mémoire des décisions techniques.

Sans cette mémoire, l’organisation devient étrangère à ses propres systèmes.

Elle continue à les utiliser.

Mais elle ne sait plus qui les habite.

Le cyberpunk avait vu cela. Il avait compris que le réseau ne serait pas seulement un outil, mais un espace de pouvoir. Il avait compris que le corps ne resterait pas extérieur à la machine. Il avait compris que les identités deviendraient des surfaces. Il avait compris que les intelligences artificielles ne seraient pas seulement des instruments, mais des présences ambiguës. Il avait compris que les mégastructures privées pourraient devenir des souverainetés techniques. Il avait compris que le crime et l’infrastructure partageraient parfois les mêmes couches.

Il avait surtout compris que le futur numérique ne serait pas propre.

Nous y sommes.

Nos systèmes ne sont pas propres. Ils sont fonctionnels. Ce n’est pas la même chose. Ils tiennent par corrections successives, dépendances empilées, automatisations partielles, exceptions contrôlées plus ou moins bien, identités héritées, outils interconnectés, modèles intégrés, fournisseurs critiques. Leur stabilité est réelle, mais provisoire. Leur cohérence est utile, mais fragile. Leur sécurité est possible, mais jamais définitive.

Le ghost est le nom de cette fragilité persistante.

Depuis Chiba City, ce mot prend une densité particulière. Il renvoie à Gibson, au cyberspace, à la ville-matrice, au corps réparé, à l’accès perdu. Il renvoie aussi à l’imaginaire japonais du corps cybernétique, de l’identité fragmentée et de la présence dans la machine. Mais il ne s’arrête pas à l’imaginaire. Il devient une catégorie de travail pour la cybersécurité contemporaine.

Identifier les ghosts.

Réduire les ghosts.

Empêcher les ghosts de devenir des adversaires.

Construire des architectures capables de continuer à voir lorsqu’ils apparaissent.

Voilà peut-être une définition exigeante de la cybersolidité.

Elle ne promet pas un monde sans faille.

Elle promet une organisation qui ne devient pas aveugle à ce qui l’habite.

La cybersécurité ne protège plus seulement contre l’intrusion. Elle organise la chasse aux présences invisibles. Elle cherche ce qui agit encore dans les systèmes, ce qui parle avec une identité légitime, ce qui survit dans les logs, ce qui circule dans les modèles, ce qui se cache dans les dépendances, ce qui reste dans les droits, ce qui hante les architectures.

Depuis Chiba City, les ghosts ne sont plus des métaphores.

Ils sont déjà dans les systèmes.

Restez informés en temps réel
S'inscrire à
la newsletter
En fournissant votre email vous acceptez de recevoir la newsletter de Incyber et vous avez pris connaissance de notre politique de confidentialité. Vous pourrez vous désinscrire à tout moment en cliquant sur le lien de désabonnement présent dans tous nos emails.
Restez informés en temps réel
S'inscrire à
la newsletter
En fournissant votre email vous acceptez de recevoir la newsletter de Incyber et vous avez pris connaissance de notre politique de confidentialité. Vous pourrez vous désinscrire à tout moment en cliquant sur le lien de désabonnement présent dans tous nos emails.