Recherche et développement

Une IA d’architecture sûre et vérifiable

État au 21 octobre 2026

Brancher une IA sur les outils d’une entreprise pose deux problèmes que les démonstrations passent sous silence : elle peut être détournée par le contenu de ces outils, et elle peut inventer des chiffres avec aplomb. Pour un DSI ou un RSSI, l’un comme l’autre est rédhibitoire. Ekera a été conçu autour de ces deux risques.

Le problème

Une carte du système d’information se nourrit de sources que personne ne contrôle entièrement : le nom d’un serveur dans l’inventaire, la description d’un ticket, un document d’architecture, un champ libre dans l’annuaire. Une seule de ces chaînes peut contenir une consigne cachée adressée à l’IA. C’est l’injection indirecte, classée au premier rang des risques des applications de modèles de langage par l’OWASP. Le second risque est la confabulation : un modèle produit avec assurance une information fausse, par exemple une perte en euros ou un score de conformité.

Filtrer les consignes suspectes ou demander au modèle d’être prudent réduit le risque sans l’éliminer. Ekera part d’un autre principe : rendre ces erreurs impossibles par construction, et le prouver par des mesures.

Quatre innovations

1. Une console qui ne lit pas vos données

Quand un DSI pose une question à sa carte, l’IA choisit des opérations de lecture dans un répertoire fermé et décide de leur ordre, sans jamais voir le contenu de la carte. C’est un programme ordinaire qui exécute ces opérations et rédige les phrases de la réponse. Une consigne cachée dans un nom de serveur n’atteint donc jamais le modèle : elle reste une donnée. Les absences et les informations non renseignées sont toujours dites, pour qu’une recherche vide ne passe jamais pour une preuve.

2. Aucun chiffre sans calcul, aucun fait sans source

Les chiffres d’Ekera (perte annuelle attendue, rayon d’impact, score NIS2) viennent d’un moteur de calcul déterministe, pas du modèle. Avant qu’un rapport ou une réponse sorte, chaque chiffre est recalculé sur la carte finale, et chaque affirmation sur le système d’information doit citer sa source, vérifiée mot pour mot. Si une seule vérification échoue, le rapport n’est pas produit : Ekera répond qu’il ne peut pas l’établir et dit ce qui manque.

3. Rien n’est écrit chez vous sans validation

Ekera peut proposer des corrections dans les outils du client : un ticket, une mise à jour d’inventaire, une preuve de conformité. Chaque écriture est validée par une personne authentifiée à l’instant, et la plateforme recalcule elle-même ce qu’elle va écrire au lieu de faire confiance à l’écran qui le lui demande. Ce qui est écrit est exactement ce que la personne a vu, une seule fois, et tout est tracé. Rien ne s’efface : une erreur se corrige par une opération inverse.

4. Aucune porte entrante chez vous

Pour lire les outils installés dans le réseau du client, un petit collecteur ne fait que sortir : il n’ouvre aucun port, ne fait que lire, et ne contacte que les machines que le client a lui-même autorisées pour chaque source. Les mots de passe restent dans le coffre du client : ni Ekera ni le navigateur ne les voient.

L’état de l’art, et ce qu’Ekera y ajoute

L’idée de séparer celui qui planifie de celui qui lit les données non fiables a été formalisée par des chercheurs de Google DeepMind en 2025 (« Defeating Prompt Injections by Design », dit CaMeL). Ekera applique ce principe à un domaine où il est particulièrement exigeant : la carte complète d’un système d’information, faite de milliers de chaînes venues d’outils hétérogènes. Ekera y ajoute la rédaction par le code plutôt que par le modèle, l’obligation de dire ce qui manque, et le recalcul systématique des chiffres par un moteur indépendant. Les guides de l’ANSSI et du NIST sur l’IA générative vont dans le même sens : ne pas faire confiance aux sorties d’un modèle sans contrôle.

La méthode : mesurer, et ne pas se tromper soi-même

Comme un examen : on n’entraîne jamais l’élève sur les questions du sujet. Seule la note sur les mondes de mesure, jamais vus pendant le réglage, prédit ce qu’Ekera fera chez un vrai client.

Dix entreprises fictives complètes, de quelques dizaines à quelques milliers de salariés, dans des secteurs variés (industrie, agroalimentaire, santé, transport, mutuelle, hôtellerie, négoce, travaux publics). Pour chacune, une vérité terrain : la carte exacte, les défauts d’architecture introduits exprès, ce que seul le DSI sait.
Un banc d’essai qui compare la carte produite par Ekera à la vérité, famille par famille, et compte les erreurs critiques.
Des mondes mis de côté : trois entreprises ne servent qu’à mesurer, jamais à régler. Aucun seuil, aucune règle, aucune consigne n’est choisi en les regardant, et des tests automatiques le vérifient. L’une d’elles est même gardée hors du dépôt de code par le seul rôle chargé de l’évaluation.
Des modèles ouverts hébergés en France : aucune donnée de client ne passe par un modèle américain. Les mesures sont rejouables.
Une relecture de sécurité indépendante de chaque changement sensible, par un rôle qui n’a pas écrit le code.

Les résultats mesurés

Mondes mis de côté (évaluation indépendante du 20 octobre 2026) : score moyen du banc de 0,81 à 0,83 selon le modèle, sans aucune erreur critique sur les trois entreprises.
Mondes de réglage : 16 mesures sur 21 atteignent au moins 80 % sans erreur critique avec un modèle ouvert hébergé en France ; les erreurs critiques passent de 15 à 2 entre deux versions.
Citations : toutes les citations retenues sont exactes, au mot près.
Entretien avec le DSI : quand la lecture des pièces est complète, quelques questions bien choisies ramènent la perte annuelle attendue, le rayon d’impact et le score NIS2 exactement à la vérité, sur les quatre entreprises mesurées ; les questions sans effet sur le calcul ne sont pas posées.
Sécurité : plus de 1 100 tests automatiques, des contrôles de sécurité à chaque changement, et les constats bloquants de chaque relecture corrigés avant fusion.

Au moins 30 % de chaque abonnement sont réservés à la recherche, à la qualité et à la sécurité : un budget commun à tous les clients, qui finance un banc d’essai de centaines d’entreprises fictives, puis des audits et des tests d’intrusion à mesure que le nombre de clients grandit (voir le détail).

Ekera et les entreprises de cybersécurité

Ekera teste lui-même la justesse de son IA, sécurise son propre code et fera vérifier sa sécurité par des prestataires extérieurs. Il ne fait pas de test d’intrusion chez ses clients : il le cible, puis surveille entre deux campagnes (voir le détail).

Les limites, et la suite

La lecture des pièces reste le maillon faible : certaines entreprises fictives, aux documents pauvres, sont encore mal lues sans modèle.
La console d’interrogation est conçue et relue par la sécurité ; elle est en cours de développement.
Ces résultats portent sur des entreprises fictives. Le test décisif, ce sont les premiers clients, et un audit de sécurité externe est prévu avant l’offre en libre-service.

Innovations propres à Ekera, développées et testées par l’équipe ; dossier détaillé sous accord de confidentialité, sur demande à contact@ekera.ai.