Zéro chiffre inventé : pourquoi le moteur d’Ekera recalcule tout ce que dit l’IA

21 octobre 2026 · 4 min de lecture

Une perte estimée en euros ou un score NIS2 inventés par une IA paraissent aussi solides que des chiffres calculés. Ekera a pris le parti inverse : le modèle ne calcule rien, et tout ce qui sort est recalculé et sourcé.

Le problème : une IA qui se trompe avec assurance

Les modèles de langage produisent du texte plausible, pas du texte vrai. Le NIST appelle ce phénomène la confabulation : un système d’IA générative présente avec assurance une information fausse. Pour une question de culture générale, c’est gênant. Pour une estimation de perte en cas de cyberattaque ou un score de conformité NIS2, c’est inacceptable : un directeur financier ou un assureur décidera sur la base de ces chiffres, et un chiffre inventé paraît aussi solide qu’un chiffre calculé.

Demander au modèle de « ne pas inventer » ou de citer ses sources n’y change rien de fondamental : il peut aussi inventer la source, ou mal recopier un nombre trouvé dans un document.

Le principe d’Ekera : le modèle ne calcule rien

Chez Ekera, les chiffres ne viennent jamais du modèle de langage. La perte annuelle attendue, le rayon d’impact d’une panne, les points uniques de défaillance ou le score NIS2 sont produits par un moteur de calcul déterministe, à partir de la carte du système d’information et des comptes de l’entreprise. Le même calcul, sur la même carte, donne toujours le même résultat, et chaque résultat se recalcule.

L’IA a un autre rôle : lire les documents, poser les bonnes questions au DSI, proposer des travaux. Elle peut se tromper dans ces tâches ; c’est pourquoi rien de ce qu’elle produit n’est publié sans contrôle.

Des garde-fous qui bloquent, pas qui avertissent

Avant qu’un rapport sorte, trois vérifications automatiques ont lieu. Chaque chiffre est relié à son calcul, et ce calcul est refait par le moteur sur la carte finale : s’il ne tombe pas juste, le rapport n’est pas produit. Chaque affirmation sur le système d’information doit citer sa source, et la citation est vérifiée mot pour mot dans la pièce d’origine. Enfin, aucune recommandation ne peut contredire une contrainte posée par le client, par exemple une exigence d’hébergement souverain.

Ces garde-fous sont bloquants : en cas d’échec, Ekera ne publie pas un rapport « à peu près juste », il indique qu’il ne peut pas établir la réponse et ce qui manque pour le faire. Sur le banc d’essai d’Ekera, toutes les citations retenues sont exactes au mot près, et l’entretien avec le DSI ramène la perte, le rayon d’impact et le score NIS2 exactement à la vérité quand la lecture des pièces est complète.

Pourquoi c’est important pour un auditeur ou un assureur

Un chiffre recalculable change la conversation. Devant un auditeur NIS2, la question n’est plus « d’où sort ce montant ? » mais « quelles hypothèses ont servi au calcul ? », et ces hypothèses sont écrites, datées et modifiables. Un assureur peut refaire le calcul avec ses propres paramètres et obtenir un résultat comparable d’une entreprise à l’autre. Et lorsque la carte change, parce qu’un serveur a été remplacé ou qu’une sauvegarde a été déplacée, les chiffres se mettent à jour par le même moteur, sans dépendre de l’humeur d’un modèle.

Sources

1. NIST, AI 600-1, « Generative Artificial Intelligence Profile », juillet 2024
2. OWASP, « LLM01:2025 Prompt Injection », 2025
3. ANSSI, « Recommandations de sécurité pour un système d’IA générative », 29 avril 2024

Article de l’équipe Ekera. Ekera cartographie le SI des ETI, chiffre ce qu’une attaque arrêterait et prépare les preuves NIS2. Méthode et résultats : recherche et développement.