Surface d'attaque réduite, pas nulle : l'approche honnête d'Elosia

Ce que le Local First change vraiment et ce qu’il ne peut pas faire

Pourquoi nous avons choisi la transparence plutôt que le marketing

Dans le secteur de la cybersécurité, tout le monde promet le risque zéro. Les éditeurs de logiciels rivalisent de superlatifs : « 100 % sécurisé », « données inviolables », « protection totale ». Et pourtant, selon le rapport IBM 2025 sur le coût des violations de données, le coût moyen d’une brèche atteint 4,44 millions de dollars, et les incidents liés à l’IA ont bondi de 56,4 % en un an (Stanford AI Index 2025).

La réalité, c’est que le risque zéro n’existe pas. Ni pour nous, ni pour personne.

Ce que nous pouvons faire et ce que nous faisons c’est réduire au maximum la surface d’attaque grâce à des choix architecturaux concrets. Cet article vous explique exactement ce que l’architecture Local First d’Elosia protège, ce qu’elle ne couvre pas, et pourquoi cette honnêteté est elle-même un avantage concurrentiel en matière de sécurité IA en entreprise.

Le problème structurel des outils IA cloud : deux surfaces d’attaque au lieu d’une

Pour comprendre ce qu’Elosia change, il faut d’abord comprendre ce que les outils IA cloud classiques exposent.

Quand vous utilisez ChatGPT, Perplexity ou la plupart des assistants IA du marché, vos conversations sont stockées sur des serveurs distants, souvent aux États-Unis, parfois sans garantie de localisation précise. Cela crée mécaniquement deux surfaces d’attaque distinctes :

Surface d’attaque n°1 : le serveur de l’éditeur

Si l’éditeur subit une fuite de données, une mauvaise configuration de stockage, ou une attaque ciblée, vos données partent avec. Ce n’est pas une hypothèse : en juin 2025, des chercheurs ont documenté la vulnérabilité EchoLeak exposant des données sensibles de Microsoft 365 Copilot sans aucune interaction utilisateur (Harvard Business Review, janvier 2026). Oracle a également confirmé deux incidents distincts en 2025 impliquant des serveurs cloud exposés.

Surface d’attaque n°2 : vos propres identifiants

Si un infostealer vole vos identifiants de connexion à votre outil IA, l’attaquant peut se connecter à votre compte depuis n’importe où dans le monde et accéder à l’intégralité de votre historique de conversations. Vos briefs clients, vos analyses financières, vos stratégies internes : tout ce que vous avez confié à l’IA depuis des mois.

Selon Verizon DBIR 2025, l’implication de tiers dans les violations de données a doublé en un an. Et selon IBM, seulement 17 % des entreprises disposent de contrôles techniques capables d’empêcher leurs collaborateurs d’uploader des données confidentielles vers des outils IA publics.

C’est dans ce contexte que l’architecture d’Elosia prend tout son sens.

Ce que l’architecture Local First d’Elosia protège concrètement

Elosia a fait un choix architectural fondamental : vos données ne quittent jamais votre appareil. Pas par promesse commerciale mais par construction technique.

Voici les six mécanismes concrets qui traduisent ce choix :

1. OPFS & IndexedDB : un stockage souverain dans le navigateur

Vos conversations et bases de connaissances sont stockées via l’Origin Private File System (OPFS) et IndexedDB, deux APIs natives du navigateur, isolées par conception. Seul le domaine Elosia peut y accéder. Aucun serveur tiers n’a accès à ces fichiers.

C’est comme stocker vos documents dans un coffre-fort intégré à votre bureau, plutôt que de les envoyer dans un entrepôt dont vous ne connaissez pas l’adresse.

2. Zero Data Retention (ZDR) : zéro persistance côté modèles

Quand vous interagissez avec les modèles IA (GPT, Claude, Gemini…), Elosia utilise des endpoints ZDR : vos requêtes sont traitées en temps réel et immédiatement supprimées, elles ne sont ni stockées, ni utilisées pour entraîner des modèles tiers. C’est la même garantie qu’Anthropic, OpenAI, Gemini proposent aux entreprises via leurs programmes Enterprise, mais appliquée par défaut sur Elosia.

3. Vectorisation locale : vos documents ne quittent pas votre machine

Le moteur d’embedding E5-small et BGE-M3 tourne directement dans votre navigateur via ONNX Runtime WebAssembly. Quand vous importez un contrat, un rapport ou des notes internes pour les analyser avec l’IA, aucun octet ne transite vers un serveur distant. La vectorisation, l’opération qui permet à l’IA de « comprendre » vos documents, se fait entièrement en local.

4. Mode 100 % hors-ligne : zéro transit réseau

Via WebGPU, le modèle Phi-3.5 Mini (3,8 milliards de paramètres, contexte 128K tokens) tourne entièrement dans votre navigateur. En mode hors-ligne, aucune donnée ne transite sur le réseau, ce qui rend toute interception réseau impossible par construction. C’est comme utiliser une solution Ollama ou AnythingLLM mais avec moins de complexité d’installation.

5. Hébergement en France : souveraineté de l’orchestration

L’orchestration des requêtes est hébergée à Paris. Aucune donnée ne transite vers des juridictions étrangères soumises au Cloud Act américain ou à des législations équivalentes.

6. Zéro tracking, zéro entraînement

Aucune analytique sur vos conversations. Aucune utilisation de vos données pour améliorer des modèles. Si vous annulez votre abonnement, vos données restent sur votre appareil, Elosia n’y a techniquement aucun accès.

Ce que l’architecture Local First ne peut pas faire et nous le disons clairement

La transparence, c’est aussi savoir nommer les limites.

1. La machine infectée reste le vecteur de risque ultime

Si votre ordinateur est compromis par un infostealer ou un malware, celui-ci peut théoriquement lire le contenu d’IndexedDB comme n’importe quelle autre donnée du navigateur, et l’exfiltrer. C’est une réalité technique que nous n’éludons pas.

Mais la différence avec une solution cloud est fondamentale :

Avec un outil cloud : credentials volés = accès à distance permanent à tout votre historique, depuis n’importe où, indéfiniment.
Avec Elosia : machine infectée = exposition strictement locale et temporelle une fois la session fermée, il n’y a rien à piller à distance.

2. IndexedDB n’est pas chiffré nativement

Les données stockées dans IndexedDB ne sont pas chiffrées par défaut par le navigateur. Elles sont isolées par origine (seul elosia.ai peut y accéder via le navigateur), mais un accès direct au système de fichiers de l’OS contourne cette isolation. C’est pourquoi la sécurité de votre machine reste indispensable.

3. Le transit des requêtes vers les modèles cloud

Même avec le ZDR actif, vos requêtes transitent vers les serveurs des fournisseurs de modèles (OpenAI, Anthropic, Google…) au moment du traitement. Elles ne sont pas stockées mais elles circulent. Pour les cas d’usage les plus sensibles, le mode hors-ligne (Gemma E2B, Ministral 3B, Llama 3.2 et Qwen 0.6B) sont les seules option à zéro transit.

La bonne équation de sécurité : des couches complémentaires

La sécurité n’est jamais une solution unique. C’est un empilement de couches complémentaires :

Machine saine : Antivirus/EDR à jour, MFA activé, pas de logiciels piratés, vigilance face aux faux CAPTCHA (technique ClickFix).
Outil IA Local First : Pas de serveur à pirater, pas d’historique accessible à distance, ZDR par défaut sur toutes les requêtes.
Mode hors-ligne pour le plus sensible : Gemma E2B, Ministral 3B, Llama 3.2 et Qwen 3.5 0.6B quatre modèles via WebGPU, zéro transit réseau, protection maximale pour les données critiques.

Elosia ne remplace pas la sécurité de votre poste. Elle élimine la surface d’attaque externe :

le serveur tiers,
la base de données centralisée,
l’historique accessible depuis n’importe quel point du globe,

pour que la seule variable restante soit votre machine. Et ça, c’est un changement structurel, pas cosmétique.

Pourquoi cette honnêteté est un avantage B2B

Dans un contexte où 83 % des entreprises n’ont aucun contrôle technique sur ce que leurs collaborateurs envoient aux outils IA publics (IBM 2025), et où les violations liées à l’IA ont doublé en un an, les DSI et les DPO ont besoin de deux choses :

Des garanties techniques vérifiables, pas des promesses marketing.
Une surface d’attaque documentée et maîtrisée, pas une boîte noire.

C’est exactement ce qu’offre l’architecture Elosia. Pas le risque zéro, personne ne peut l’offrir honnêtement. Mais la surface d’attaque la plus petite possible, documentée mécanisme par mécanisme, avec des limites clairement nommées.

« La confidentialité n’est pas une option. C’est l’architecture. »

Pour les avocats, les médecins, les consultants en stratégie et les équipes finance qui traitent des données hautement sensibles au quotidien, cette différence n’est pas marginale. Elle est fondamentale.

En résumé

Ce qu’Elosia élimine	Ce qu’Elosia ne couvre pas
✅ Fuite côté serveur Elosia	⚠️ Machine locale infectée
✅ Accès à distance via credentials volés	⚠️ IndexedDB non chiffré nativement
✅ Stockage de vos conversations par l’éditeur	⚠️ Transit des requêtes vers modèles cloud
✅ Entraînement de modèles sur vos données	⚠️ Risques liés au navigateur (XSS)
✅ Exposition à des juridictions étrangères	⚠️ Comportement utilisateur à risque

La sécurité absolue n’existe pas. Mais choisir des outils qui réduisent structurellement votre exposition, c’est la décision la plus responsable que vous puissiez prendre aujourd’hui.