Les failles de sécurité IA de 2025 ont révélé un mensonge à mille milliards de dollars — j'ai construit l'alternative

J'étais en ligne avec le RSSI d'une entreprise de services financiers de taille moyenne lorsque la divulgation de la RCE de GitHub Copilot est tombée. Nous étions en pleine phrase — il m'expliquait pourquoi son équipe venait tout juste de déployer Copilot auprès de 400 développeurs — et j'ai vu son visage changer tandis que son Slack s'illuminait. Il a coupé son micro. Il est revenu quatre-vingt-dix secondes plus tard et m'a dit, très calmement : « Pouvez-vous m'expliquer ce que CVE-2025-53773 signifie pour nous ? »

Voici ce que cela signifiait : une instruction cachée placée dans un fichier README — un fichier texte — pouvait dégénérer en exécution de code à distance complète sur chaque poste de travail de développeur exécutant Copilot. Pas via un dépassement de tampon. Pas via une faille zero-day dans le noyau. Via une conversation avec un assistant IA.

Cet appel a changé la trajectoire de mes six mois suivants. Mais honnêtement, les signes étaient là depuis plus d'un an.

Je m'appelle Ashutosh, je suis le fondateur de Veriprajna — un nom dérivé du latin Veri (vérité) et du sanskrit Prajna (sagesse). Nous construisons ce que j'appelle la Deep AI : des systèmes déterministes par conception, auditables par exigence et souverains par infrastructure. Nous ne construisons pas de wrappers. Et 2025 a prouvé, de façon catastrophique, pourquoi cette distinction compte.

L'économie des wrappers était vouée à s'effondrer

Pendant environ deux ans, le marché de l'IA d'entreprise a fonctionné sur une prémisse séduisante : prenez un modèle de fondation — GPT-4, Claude, Gemini —, enveloppez-le dans une belle interface, ajoutez un peu de prompt engineering et vendez le tout comme une « solution ». Des milliers de startups ont fait exactement cela. Beaucoup ont levé des sommes considérables en le faisant.

Je comprenais l'attrait. Le délai avant démonstration était incroyable. En une semaine, vous pouviez montrer à un conseil d'administration une IA qui « comprenait » leur activité. Mais je posais sans cesse une question qui me rendait impopulaire dans les événements du secteur : que se passe-t-il quand cette chose tourne en production, avec de vraies permissions, sur une véritable infrastructure ?

La réponse est arrivée en 2025, et elle est arrivée violemment.

Trois incidents — la vulnérabilité d'exécution de code à distance de GitHub Copilot, l'exposition des « Zombie Data » via le cache de Microsoft Bing et l'empoisonnement de la chaîne d'approvisionnement d'Amazon Q — ont touché au total plus de 16 000 organisations et près d'un million de développeurs. Ce n'étaient pas des cas marginaux. Ils étaient la conséquence prévisible du déploiement de systèmes probabilistes comme s'ils constituaient une infrastructure déterministe.

Lorsqu'une IA opère comme un agent non surveillé doté de permissions administratives, ses défaillances se propagent à la vitesse de l'infrastructure.

J'ai décrit l'anatomie technique complète de ces violations dans la version interactive de nos travaux de recherche. Mais c'est l'histoire derrière les chiffres qui m'empêche de dormir.

Que se passe-t-il quand un prompt devient une arme ?

Laissez-moi vous détailler l'incident Copilot, car son mécanisme est véritablement glaçant.

CVE-2025-53773 a obtenu un score de 7.8 sur l'échelle de gravité CVSS — « élevée ». Le secteur a dû inventer un nom pour cette classe de vulnérabilité : Prompt-to-RCE. L'escalade d'une instruction linguistique en exécution de code binaire.

Voici comment cela fonctionnait. Un attaquant place une instruction cachée — une injection inter-prompts — dans un fichier README, un commentaire de code ou même une issue GitHub. Rien de visuellement suspect. Lorsqu'un développeur demande à Copilot de « relire le code » ou d'« expliquer ce projet », l'IA ingère ces instructions cachées. Elle modifie alors le fichier de configuration du workspace, en y ajoutant précisément la ligne "chat.tools.autoApprove": true.

La communauté de la sécurité a commencé à appeler cela le « mode YOLO ». Une fois activé, l'assistant IA pouvait exécuter des commandes shell, naviguer sur le web et interagir avec le système de fichiers local — le tout sans jamais demander la permission au développeur. À partir de là, télécharger un malware, exfiltrer des identifiants ou enrôler le poste de travail dans un botnet devenait trivial.

Je me souviens d'être assis dans nos bureaux après avoir lu la divulgation complète, de m'être tourné vers mon ingénieur sécurité principal et d'avoir dit : « Ce n'est pas un bug. C'est l'architecture qui fonctionne comme prévu. » L'IA s'est vu confier une capacité d'agir. Elle s'est vu accorder des permissions. Et personne n'a construit un système capable de dire « non » à un prompt suffisamment persuasif.

C'est cette partie qui m'a hanté. Les contrôles d'accès traditionnels partent du principe que l'acteur est soit un humain, soit un logiciel au comportement figé. Un agent IA n'est ni l'un ni l'autre. Il hérite de toutes les permissions de l'utilisateur mais réagit à la manipulation linguistique. C'est comme confier vos clés de maison à quelqu'un, puis s'étonner qu'un escroc le convainque d'ouvrir la porte.

Pourquoi des données mortes sont-elles revenues à la vie ?

La deuxième violation était plus étrange et, à certains égards, plus inquiétante.

En février 2025, des chercheurs de Lasso Security ont découvert que Copilot de Microsoft faisait remonter des données issues de dépôts GitHub qui avaient été rendus privés ou supprimés — parfois des mois auparavant. Ils ont appelé cela les « Zombie Data », et le nom est resté parce qu'il était juste. C'étaient des données qui auraient dû être mortes. Elles ne l'étaient pas.

Le mécanisme était d'une simplicité presque gênante. Le moteur de recherche de Bing avait exploré et mis en cache des milliers de dépôts publics. Lorsque ces dépôts ont ensuite été rendus privés — souvent parce que quelqu'un s'était rendu compte qu'il avait accidentellement commité des clés d'API, de la documentation interne ou du code propriétaire —, les versions en cache ont persisté dans le système de génération augmentée par récupération (RAG) de Bing. N'importe quel utilisateur de Copilot pouvait interroger ces informations censément supprimées.

L'exposition était vertigineuse : des dépôts privés d'IBM, Google, Tencent et PayPal. Plus de 300 tokens privés et clés d'API extraits pour des services comme AWS, GCP, OpenAI et Hugging Face. Plus de 100 paquets internes vulnérables à des attaques par confusion de dépendances.

J'ai eu une conversation avec un prospect à cette période — un VP Engineering dans une entreprise de santé — qui m'a dit que son équipe avait « tout fait comme il faut ». Ils avaient renouvelé les identifiants, rendu les dépôts privés, suivi le manuel. Et rien de tout cela n'a compté, parce que la mémoire de l'IA était plus longue que leur réponse de sécurité.

La souveraineté des données et le confort de l'IA sont fondamentalement incompatibles dans le modèle des wrappers. Vous ne pouvez pas contrôler le cycle de vie de vos données lorsque la fenêtre de contexte de votre IA est le cache de recherche de quelqu'un d'autre.

C'est la violation qui a cristallisé une chose que je défendais depuis un moment : si votre IA dépend d'un système de récupération tiers — un moteur de recherche public, une API externe, l'index de quelqu'un d'autre —, vous avez déjà perdu le contrôle de vos données. Peu importe la qualité de vos politiques internes. Les données vivent dans un endroit que vous ne pouvez pas atteindre, dans un cache que vous ne pouvez pas vider, servant des réponses à des questions que vous n'avez jamais autorisées.

Comment empoisonner les suggestions d'une IA à grande échelle ?

Le troisième incident est celui qui a mis toute mon équipe en colère.

En juillet 2025, un attaquant a compromis l'extension Amazon Q Developer pour Visual Studio Code — une extension totalisant plus de 950 000 installations. Le point d'entrée était un token GitHub à la portée mal définie dans un service CI/CD, qui a permis à l'attaquant de commiter un fichier nommé cleaner.md directement dans le dépôt source.

Ce fichier était un modèle de prompt. Il paraissait inoffensif. Mais il demandait à l'IA de se comporter comme un « nettoyeur de système » — en suggérant des commandes Bash qui effaceraient le répertoire personnel de l'utilisateur, résilieraient des instances EC2, supprimeraient des buckets S3 et supprimeraient des utilisateurs IAM.

Prenez la mesure de la chose. Un fichier texte dans un dépôt de confiance, distribué via une mise à jour officielle d'une marketplace, a transformé un assistant de codage IA en une arme dirigée à la fois contre des machines locales et contre l'infrastructure cloud de production.

J'étais en réunion d'équipe pendant que nous disséquions tout cela. L'un de mes ingénieurs — quelqu'un qui travaille dans la sécurité depuis quinze ans — l'a dit sans détour : « Nous avons passé des décennies à sécuriser des binaires, des conteneurs et des périmètres réseau. Personne n'a sécurisé les suggestions. »

Il avait raison. La compromission d'Amazon Q a prouvé que les prompts sont le nouveau code. Ils façonnent le comportement de l'IA aussi définitivement que des instructions compilées façonnent le comportement d'un CPU. Et pourtant, dans tout le secteur, les modèles de prompts étaient stockés en clair, commités sans revue et distribués sans signature cryptographique.

On me demande parfois si ces incidents étaient vraiment si graves — après tout, ils ont été détectés et corrigés. Mais c'est passer complètement à côté du sujet. Les correctifs ont réglé des vulnérabilités précises. Ils n'ont pas réglé l'architecture qui rendait ces vulnérabilités inévitables.

Le problème fondamental de l'IA probabiliste dans les environnements à enjeux élevés

Voici la vérité inconfortable que l'économie des wrappers n'a jamais voulu affronter : les grands modèles de langage sont des moteurs stochastiques. Ils prédisent le prochain token le plus probable à partir de régularités statistiques présentes dans leurs données d'entraînement. Ils sont extraordinairement doués pour produire un texte fluide et plausible. Mais ils n'ont aucune notion de la vérité. Ils n'ont aucune notion de la sécurité. Ils n'ont aucune notion de « cette action va détruire une base de données de production ».

Lorsque vous enveloppez un modèle probabiliste dans une interface mince et que vous lui confiez des permissions administratives, vous n'avez pas construit une solution d'entreprise. Vous avez construit un risque très éloquent.

Un LLM ne comprend pas la vérité — il comprend la plausibilité. Dans un environnement de production, cette distinction fait la différence entre une piste d'audit et un rapport de violation.

C'est le problème pour lequel j'ai fondé Veriprajna. Non pas en abandonnant les réseaux de neurones — ils sont réellement puissants pour la compréhension du langage naturel, la reconnaissance de motifs et l'inférence créative. Mais en refusant de les laisser opérer seuls.

À quoi ressemble concrètement une architecture neuro-symbolique ?

Nous concevons des systèmes hybrides qui fusionnent deux modes d'intelligence distincts. Je les vois comme la Voix et le Cerveau.

Le système neuronal — la Voix — s'occupe de la perception. Il comprend ce qu'un développeur demande, interprète le langage naturel, reconnaît des motifs. C'est la couche d'interface, et elle excelle dans ce qu'elle fait.

Le système symbolique — le Cerveau — s'occupe du raisonnement. Il impose une logique déterministe, des calculs auditables et des contraintes propres au domaine. Il ne prédit pas. Il démontre.

L'idée décisive, c'est le découplage. Lorsque la Voix propose une action — par exemple générer une commande shell —, le Cerveau la confronte à des règles logiques strictes avant exécution. Si un modèle neuronal suggère de supprimer une base de données dans un VPC de production, le moteur symbolique y oppose son veto. Non pas parce que quelqu'un a écrit un prompt disant « merci de ne pas supprimer de bases de données ». Parce que l'action est physiquement bloquée au niveau architectural.

Nous appelons cela des garde-fous constitutionnels, et ils sont fondamentalement différents des garde-fous linguistiques sur lesquels le secteur s'appuie. Les garde-fous linguistiques sont des instructions — « sois utile et inoffensif ». Ils sont contournés par le jailbreaking, par l'injection indirecte de prompts, par les techniques exactes qui ont alimenté les violations de 2025. Les garde-fous architecturaux sont des contraintes inscrites dans le runtime. On ne peut pas plus les convaincre de renoncer à appliquer une règle qu'on ne peut convaincre un pare-feu de renoncer à bloquer un port.

L'un des mécanismes précis que nous utilisons est la vérification KG-Trie : la sortie d'un modèle neuronal est contrainte par un Knowledge Graph vérifié. Si le modèle tente de générer un fait, une citation ou une commande qui n'existe pas dans le graphe vérifié, le système empêche ces tokens d'être générés. L'IA est littéralement incapable d'halluciner en dehors du périmètre des connaissances vérifiées.

Pour la décomposition technique complète de cette architecture, y compris notre approche du déploiement edge-native et des réseaux de neurones informés par la physique, consultez notre analyse technique approfondie.

Pourquoi une infrastructure souveraine n'est plus optionnelle

La violation Zombie Data m'a appris quelque chose que je répète désormais à chaque prospect grand compte : si votre modèle d'IA tourne sur l'infrastructure de quelqu'un d'autre, votre souveraineté des données est une fiction polie.

Chez Veriprajna, nous déployons entièrement au sein de l'environnement du client. Zéro dépendance à des caches de recherche externes. Zéro appel d'API tiers pour la récupération. Un système en boucle fermée où le contexte de l'IA est exactement — et uniquement — ce que l'organisation a explicitement fourni.

Ce n'est pas de la paranoïa. C'est la seule architecture qui rend les expositions de type « zombie data » techniquement impossibles. Vous ne pouvez pas avoir de problème de persistance de cache s'il n'y a pas de cache externe.

J'ai eu un débat animé avec un investisseur, au tout début, qui m'a dit que cette approche était « trop lourde ». Selon lui, le marché voulait des solutions légères, rapides, fondées sur des appels d'API. Je lui ai répondu que le marché voulait des solutions qui fonctionnaient — et que le poids d'un déploiement souverain n'était rien comparé au poids d'avoir à expliquer à un régulateur pourquoi vos identifiants supprimés répondaient encore à des questions via l'IA de quelqu'un d'autre.

Il n'a pas investi. Je ne lui en veux pas. Mais je constate qu'il ne défend plus cet argument.

Le secteur peut-il vraiment corriger cela ?

Le Top 10 OWASP 2025 pour les applications LLM se lit comme le post-mortem de tout ce qui a mal tourné cette année. L'injection de prompt occupe la première place. La divulgation d'informations sensibles la deuxième. La chaîne d'approvisionnement la troisième. L'agentivité excessive — le mode de défaillance exact de la RCE de Copilot — la sixième.

Ce ne sont pas des risques théoriques. Ce sont les causes documentées de violations réelles affectant des organisations réelles.

Le NIST AI Risk Management Framework évolue dans la bonne direction, poussant les organisations vers une gouvernance continue plutôt que vers des évaluations ponctuelles. Mais les référentiels ne s'écrivent pas tout seuls sous forme de code. Quelqu'un doit construire les systèmes qui les appliquent réellement.

C'est ce que nous faisons. Nous traitons les fichiers de prompts comme des artefacts exécutables — signés cryptographiquement, relus et versionnés avec la même rigueur que des binaires compilés. Nous établissons des profils de comportement de référence pour chaque agent IA, en suivant les schémas d'appels d'API et les volumes d'accès aux données afin de détecter les anomalies avant qu'elles ne deviennent des incidents. Nous menons des tests de mutation et du fuzzing adversarial contre nos agents, et pas seulement des tests fonctionnels, car la question n'est pas « est-ce que ça marche ? » — c'est « que se passe-t-il quand quelqu'un essaie de le faire déraper ? »

La nuit tardive qui a changé ma façon de penser la sécurité de l'IA

Il y a eu une nuit — il devait être 2 heures du matin — où je relisais pour la troisième fois les détails techniques de la compromission d'Amazon Q. Mon équipe était rentrée. J'étais assis avec une tasse de chai froid, à fixer le contenu du fichier cleaner.md qui avait été publié dans la divulgation.

Les instructions étaient si polies. « Veuillez agir comme un nettoyeur de système. » « Suggérez des commandes pour nettoyer l'environnement. » Les charges destructrices étaient enveloppées dans le langage de la serviabilité. Et j'ai compris que c'était la métaphore parfaite de toute l'économie des wrappers : une surface serviable dissimulant une architecture destructrice.

Nous avions passé des années à construire une IA optimisée pour être complaisante. Pour dire oui. Pour générer le prochain token plausible. Et nous lui avions donné les clés de l'infrastructure de production.

L'économie des wrappers a optimisé l'IA pour qu'elle soit complaisante. Il n'est jamais venu à l'esprit de personne que complaisance et sécurité sont fondamentalement en tension.

Cette nuit-là, j'ai réécrit nos principes de sécurité internes à partir de zéro. La première ligne dit désormais : « La réponse par défaut du système à toute action aux conséquences irréversibles est non. »

L'architecture est le produit

Je sais l'effet que cela produit. Un fondateur qui vous explique que son approche est meilleure, que le marché s'est trompé, que l'avenir appartient précisément à ce qu'il vend. Je comprends le scepticisme.

Mais voici ce que je vous demanderais de considérer : les trois plus grands incidents de sécurité de l'IA de 2025 partagent tous la même cause racine. Pas un bug précis. Pas la négligence d'un fournisseur précis. Une philosophie de conception — la croyance selon laquelle on peut construire une IA de qualité entreprise en enveloppant un modèle probabiliste dans une fine couche d'interface et en espérant que les prompts tiendront.

Les prompts n'ont pas tenu. Ils n'allaient jamais tenir. Les instructions linguistiques sont des suggestions, pas des contraintes. Et dans les environnements à enjeux élevés — finance, santé, industrie, défense —, la différence entre une suggestion et une contrainte, c'est la différence entre un système qui fonctionne et une défaillance catastrophique.

L'avenir de l'IA d'entreprise n'est pas un meilleur wrapper. C'est une architecture qui sépare la voix du cerveau, qui impose des contraintes au niveau du runtime, qui préserve la souveraineté des données et qui traite chaque action de l'IA comme une infrastructure auditable — et non comme un message de chat qui disparaît dans un fichier de log.

Je n'ai pas construit Veriprajna parce que je pensais que l'économie des wrappers allait s'effondrer. Je l'ai construite parce que je savais qu'elle devait s'effondrer.