Le connectome d’une drosophile met à l’épreuve les démonstrations d’AppSec
Le connectome d’une drosophile met en lumière un principe de sécurité : une démonstration ne constitue pas une preuve tant que des contrôles ne montrent pas ce que le système présenté apporte réellement.
Au-delà de l’ASPM
Une AppSec fondée sur la preuve pour les équipes qui développent avec l’IA
Plexicus utilise AI Swarm Pentest pour explorer des chemins d’application autorisés, valider ce qui est exploitable et fournir les preuves nécessaires pour prioriser la remédiation.
Découvrir AI Swarm PentestUne démonstration de sécurité peut donner l’impression qu’une affirmation non vérifiée est établie. La question utile est de savoir ce que le système a réellement causé — et ce que l’ingénieur lui a fourni.
La cartographie du système nerveux d’une drosophile rend cette question très concrète.
La carte 2026 du système nerveux central d’une drosophile mâle recense environ 166 700 neurones, 11 710 types de neurones et 125 millions de contacts synaptiques (projet MaleCNS ; dépôt de Cambridge ; Google Research).
Un connectome répertorie les neurones reliés entre eux par des synapses.
Les données v1.0 ont été publiées en juin ; l’article Cell associé a paru le 3 septembre 2026 (article).
Un connectome est une carte structurelle, pas l’enregistrement des pensées d’une mouche vivante ni une spécification complète permettant de la faire fonctionner. Les simulations ajoutent des hypothèses sur la dynamique neuronale, les entrées sensorielles et les commandes de sortie.
Les ingénieurs qui choisissent ces éléments peuvent largement façonner ce que le public voit.
L’image principale est une illustration éditoriale de Plexicus représentant les expériences en ligne ; ce n’est ni une image scientifique ni une capture d’écran validée d’une mouche jouant à ces jeux.

Visualisation MaleCNS montrant une cellule représentative de chaque type de neurone annoté. Crédit : FlyEM Project Team/HHMI Janelia, Cambridge Connectomics Group et Google Research. Galerie originale et contexte.
L’expérience témoin est au cœur du sujet
Intezer a testé si un connectome de drosophile pouvait aider à classer 12 716 de ses propres alertes de sécurité.
Seules 606 alertes (4,8 %) ont été escaladées ; les 12 110 autres ont été marquées « aucune action nécessaire ». Face à ce déséquilibre des classes, Intezer rapporte à la fois le ROC-AUC et l’aire sous la courbe précision-rappel (PR-AUC).
Le connectome réel a obtenu 0,887 ROC-AUC et 0,300 PR-AUC. Intezer précise que chaque modèle a utilisé les mêmes découpages stratifiés en cinq plis et la même grille de régularisation.
Les témoins ont obtenu de meilleurs scores : câblage mélangé 0,910 / 0,385, réservoir aléatoire 0,918 / 0,426, et régression logistique sur les jetons d’alerte hachés 0,922 / 0,476 (ROC-AUC / PR-AUC).
Il s’agit de résultats rapportés par l’entreprise, et non d’une réplication indépendante ou évaluée par les pairs. Le connectome réel contenait des informations exploitables, mais n’a pas surpassé les témoins présentés.
Cette comparaison est plus instructive qu’une démonstration fonctionnelle à elle seule : l’élément présenté apporte-t-il plus qu’un réseau mélangé, un réservoir aléatoire ou un classificateur plus simple ?
Les représentations diffèrent : le connectome reçoit 121 canaux olfactifs, tandis que la meilleure référence linéaire utilise un ensemble de jetons hachés de dimension 4 096.
Ce choix de représentation compte pour interpréter la comparaison. Les scores ne permettent pas d’établir les performances des connectomes pour d’autres tâches.
CVE-FLY donne un angle AppSec
CVE-FLY étudie l’utilisation d’une politique neuronale pour orienter l’équilibre d’un fuzzer entre l’exploration de nouveaux chemins et l’exploitation de pistes prometteuses.
Le dépôt utilise un modèle de cerveau femelle, et non MaleCNS, et indique avoir atteint un débordement de tas délibérément introduit dans un programme C de démonstration après 3 458 exécutions.
Cela ne signifie pas qu’une mouche a piraté un programme. Le README indique que la cible de démonstration utilise un score de progression synthétique, tandis que le générateur pseudo-aléatoire de Python modifie toujours les octets d’entrée.
Le dépôt ne rapporte aucun benchmark statistique face à des politiques aléatoires ou fixes, ni face à AFL++. Cette exécution unique prouve le fonctionnement de l’architecture, pas des gains réels en couverture de code mesurée par instrumentation du compilateur ni une supériorité sur les fuzzers établis.
Ce que la carte et les démonstrations montrent — et ne montrent pas
La reconstruction MaleCNS de 2026 couvre le cerveau, les lobes optiques et le cordon nerveux ventral.
Elle prolonge des travaux antérieurs : le connectome FlyWire du cerveau d’une drosophile femelle publié en 2024 comptait 139 255 neurones et environ 54,5 millions de synapses, et une carte du cerveau et du cordon nerveux ventral femelle a également été publiée.
Un schéma de connexions ne spécifie ni le potentiel membranaire de chaque neurone, ni la force fonctionnelle de chaque synapse, ni l’état neuromodulateur de l’animal, ni la réaction de son corps.
Les développeurs doivent fournir une dynamique et décider comment les événements externes stimulent le modèle.
Le modèle de Shiu et ses collègues publié dans Nature en 2024 a montré qu’un modèle relativement simple fondé sur le connectome pouvait faire des prédictions utiles sur les circuits de l’alimentation et du toilettage.
Cela justifie l’étude des calculs réalisés par le câblage ; cela n’établit pas une reconstitution fidèle de l’expérience d’une mouche individuelle.
Les intégrations de jeux rendent ces choix de conception plus visibles :
État du jeu → encodage sensoriel conçu par des humains → activité neuronale simulée sur un câblage mesuré → lecture neuronale sélectionnée → commandes de jeu conçues par des humains.
Un mod Minecraft associe les stimuli du jeu à des populations sensorielles, exécute un graphe dérivé de MaleCNS avec une dynamique simplifiée, puis décode l’activité en mouvements.
Sa documentation décrit des seuils et une couche corporelle conçue manuellement.
Fly64 applique une idée similaire à Super Mario 64, avec une perspective visuelle virtuelle et des groupes neuronaux sélectionnés pour contrôler les mouvements et les sauts.
Son créateur présente le projet comme éducatif et non validé ; les notes techniques précisent que le câblage mesuré ne prouve pas le rétablissement de la physiologie, du comportement, de l’expérience ou de la conscience.
Dans Doom, DOOMFLY relie une arène de jeu en direct à l’activité de MaleCNS : les images du jeu stimulent les neurones visuels modélisés, et certaines sorties deviennent des commandes de déplacement et de tir.
Sa revue neuroscientifique décrit une simulation de connectome en boucle fermée tout en qualifiant d’approximations le mappage sensoriel, la dynamique neuronale et le décodeur moteur.
Ses notes d’entraînement rapportent l’échec des étapes de validation ; la capacité acquise à survivre n’a pas été démontrée.
Un extrait de Beat Saber, largement diffusé, a nourri le mème, mais une vidéo courte ne montre ni le modèle, ni le mappage des commandes, ni la validation.
La vignette Beat Saber de l’image principale représente ce mème, et non un résultat vérifié indépendamment.
La démonstration de mouche virtuelle d’Eon Systems de mars 2026 est distincte de ces jeux ; elle utilisait une ancienne carte FlyWire femelle, une dynamique simplifiée et un corps simulé par la physique.
La note technique d’Eon expose ces limites, tandis que la réponse de Carboncopies estime que le terme « transfert » va au-delà des preuves disponibles ; ni l’une ni l’autre ne démontre le transfert de l’esprit d’une mouche individuelle.
Une liste de contrôle pour tester une démonstration de sécurité par IA
Prenez l’expérience sur la mouche comme exemple, puis posez les mêmes questions pour une démonstration de pentest par IA ou d’agent autonome :
| Expérience sur la mouche | Démonstration de pentest par IA ou d’agent autonome |
|---|---|
| Périmètre et anatomie : Quelles parties du système nerveux reconstruit étaient incluses, filtrées ou recadrées ? | Périmètre et cible : Quels hôtes, code, identités et chemins d’attaque étaient dans le périmètre, et qu’est-ce qui en était exclu ? |
| Script fixe, dynamique apprise ou intervention humaine : Quels comportements neuronaux ont été modélisés, et où les développeurs ont-ils fixé des règles ou sont-ils intervenus ? | Script, modèle ou intervention humaine : Quelles étapes relevaient d’une automatisation fixe, de décisions du modèle, d’instructions ou d’actions de l’opérateur ? |
| Mappage des entrées et interface : Qui a traduit l’état du jeu en entrées sensorielles et les sorties neuronales en commandes ? | Mappage des entrées et interface : Quelles données l’agent a-t-il reçues, quels outils pouvait-il utiliser, et la démonstration a-t-elle contourné le parcours annoncé ? |
| Témoins : Le câblage mesuré a-t-il surpassé le câblage mélangé, le réservoir aléatoire ou un modèle plus simple ? | Témoins : Le système a-t-il surpassé un outil plus simple, une politique aléatoire ou un humain sur la même cible et avec le même budget ? |
| Retest du résultat et du correctif : Le comportement a-t-il résisté à des tests sur des données mises de côté pour l’évaluation, à une ablation et à une reproduction indépendante ? | Retest du résultat et du correctif : Le résultat est-il reproductible, et le correctif proposé réussit-il un nouveau test ? |
Un mode de défaillance courant en AppSec est qu’un scanner signale un sink dangereux dans le code, alors qu’aucun chemin contrôlé par un attaquant ne peut y accéder.
Un sink est une opération susceptible de causer un dommage. L’atteignabilité demande si une entrée contrôlée par un attaquant peut y parvenir ; l’exploitabilité, si elle peut avoir un impact réel. Une preuve de concept peut démontrer les deux.
Ne qualifiez le résultat de faux positif qu’après avoir vérifié qu’aucun autre chemin contrôlé par un attaquant ne mène à ce sink.
Demandez la comparaison
Relier un jeu à un câblage de mouche simulé produit une démonstration saisissante. Les témoins d’Intezer et les limites de CVE-FLY montrent pourquoi il faut vérifier l’apport annoncé, plutôt que de le déduire de la vidéo.
Quand un fournisseur vous présente une démonstration de sécurité par IA, demandez : à quoi l’a-t-elle été comparée, et que se passe-t-il si l’on retire le composant vendu ?