Le manuel E-ARI

Un guide complet de la plateforme — ce qu'elle fait, comment elle fonctionne et pourquoi elle est construite ainsi.

Version 1.0 · mai 2026

Avant-propos

La plupart des outils de « préparation à l'IA » sont des tableurs déguisés. Ils posent quelques questions, tracent un diagramme en radar et vous remettent un PDF qui vieillit à l'instant où votre direction financière le lit.

E-ARI a été construit pour faire quelque chose de plus difficile : transformer la réalité désordonnée, réglementée et mouvante de l'adoption de l'IA en entreprise en un seul espace de travail vivant, où la mesure, les preuves et la conformité se cumulent dans le temps. Un chiffre sur un tableau de bord, c'est facile. Une piste d'audit défendable qui survivra à l'examen d'un organisme notifié dans trois ans, non.

Ce document explique chaque partie de la plateforme — le moteur d'évaluation qui note votre préparation, les six agents d'IA qui transforment des scores en récit, l'autopilote de conformité qui relie vos systèmes d'IA au règlement européen sur l'IA, et la couche de surveillance qui guette de nouvelles lacunes pendant que vous dormez.

Lisez-le d'un bout à l'autre ou allez directement à la section qu'il vous faut. Un glossaire figure à la fin si un terme vous semble inhabituel.

Table des matières

1. Ce qu'est E-ARI
2. Le problème que nous résolvons
3. Comment E-ARI est structuré
4. Couche 1 — Le moteur d'évaluation
5. Couche 2 — Les six agents d'IA
6. Couche 3 — L'autopilote de conformité
7. Couche 4 — La surveillance continue
8. Le parcours utilisateur en quatre étapes
9. Méthodologie et notation
   • Notre méthodologie, énoncée honnêtement
10. Vie privée, sécurité et traitement des données
11. Formules et tarifs
12. À qui cela s'adresse
13. Feuille de route
14. Glossaire

1. Ce qu'est E-ARI

E-ARI — abréviation d'Enterprise AI Readiness Index — est une plateforme conçue autour du règlement européen sur l'IA, qui aide une organisation à répondre à quatre questions, dans l'ordre :

Le résultat n'est pas un PDF unique. C'est un espace de travail vivant : scores, analyses d'impact sur les droits fondamentaux, documentations techniques, rapports de lacunes et couverture des obligations restent versionnés, exportables et prêts pour un audit.

2. Le problème que nous résolvons

2.1 Le paysage de la conformité a changé en 2024

Le règlement européen sur l'IA est entré en vigueur le 1er août 2024, avec une application par étapes, tel que modifié par le Digital Omnibus sur l'IA (règlement (UE) 2026/1744, en vigueur le 27 juillet 2026) :

• 2 février 2025 — les articles 5 (pratiques interdites) et 4 (maîtrise de l'IA) s'appliquent.
• 2 août 2025 — gouvernance, obligations relatives aux modèles d'IA à usage général, sanctions et désignation des organismes notifiés.
• 2 août 2026 — les obligations de transparence de l'article 50 s'appliquent (les personnes doivent savoir qu'elles interagissent avec une IA, et les contenus générés par IA doivent être marqués).
• 2 décembre 2026 — deux interdictions supplémentaires (images intimes non consenties ; matériel pédopornographique) et obligations de marquage pour les systèmes de contenu synthétique déjà sur le marché avant le 2 août 2026.
• 2 décembre 2027 — les obligations relatives au haut risque s'appliquent aux systèmes autonomes de l'annexe III. Le Digital Omnibus a reporté cette date du 2 août 2026 — c'est du temps de construction supplémentaire pour une analyse d'impact sur les droits fondamentaux et une documentation technique au titre de l'annexe IV, non une raison d'attendre.
• 2 août 2028 — obligations relatives au haut risque pour l'IA intégrée à des produits réglementés (annexe I).

Les sanctions atteignent 35 M€ ou 7 % du chiffre d'affaires mondial pour les violations des pratiques interdites. Il n'existe pas de version « on s'en occupera au prochain trimestre » de ce sujet.

2.2 Les outils existants échouent de trois façons prévisibles

2.3 Ce qu'E-ARI optimise

Trois propriétés que nous considérons comme non négociables :

1. Défendabilité — chaque recommandation, chaque classification, chaque lacune est traçable jusqu'à une clause d'un règlement, une phrase d'une preuve ou une question de l'évaluation. Aucun verdict opaque produit par un modèle de langage.
2. Cumul — le travail fait à un endroit alimente le suivant. Votre base d'évaluation classe vos systèmes d'IA. Une preuve téléversée pour une obligation se rattache automatiquement à d'autres. Combler une lacune sur un système met à jour la surveillance de tout le portefeuille.
3. Discipline du périmètre — nous n'essayons délibérément pas d'être un outil de gestion de projet, un géant du GRC ou un registre de modèles. E-ARI se place entre votre équipe stratégie et vos autorités de contrôle.

3. Comment E-ARI est structuré

La plateforme est bâtie en quatre couches coopérantes. Chaque couche a son propre modèle de données, ses propres surfaces d'interface et ses propres points d'intégration — mais elles partagent une source unique de vérité.

Une évaluation de référence est le germe. À partir de là, chaque système d'IA que vous enregistrez est rattaché à cette référence, de sorte que son profil de conformité hérite automatiquement du contexte organisationnel (secteur, taille, maturité de la gouvernance).

4. Couche 1 — Le moteur d'évaluation

4.1 Les 8 piliers

Nous évaluons la préparation sur huit piliers, avec des pondérations issues de la littérature de recherche sur les facteurs de succès de l'adoption de l'IA. La somme des pondérations vaut 1,00.

Chaque pilier comporte exactement 5 questions sur une échelle de Likert (1–5). 40 questions au total. Durée médiane de réalisation : environ 15 minutes.

4.2 Niveaux de maturité

Une fois pondéré, le score global (0–100) se rattache à l'un de quatre niveaux :

Les niveaux sont volontairement plus larges qu'un centile — ils sont faits pour orienter des comportements (où investir), non pour flatter.

4.3 Ce que vous récupérez

Une évaluation achevée produit un enregistrement Assessment structuré :

• Score global (0–100, pondéré par secteur) et score de référence (non pondéré) par souci de transparence
• Scores par pilier avec le détail au niveau des questions et les ajustements d'interdépendance appliqués
• Niveau de maturité avec une interprétation en langage clair
• Constats X-Ray — schémas de risque structurels détectés à partir de combinaisons de réponses (voir §9.4), chacun avec sa gravité, sa piste de preuves, son impact métier et une action concrète
• Application de la pondération sectorielle — quels piliers ont été accentués pour votre secteur et pourquoi
• Comparaison sectorielle (vos scores face à des moyennes sectorielles curées)
• Matrice forces / faiblesses — les trois meilleurs piliers et les trois derniers
• Cartographie réglementaire initiale — les piliers qui correspondent aux réglementations applicables (RGPD, règlement européen sur l'IA, ISO 42001, NIST AI RMF)
• Analyse de levier — le pipeline est rejoué en améliorant chaque réponse d'un cran, classant chaque action possible selon son gain exact sur le score global (y compris la levée de règles d'interdépendance et la pondération sectorielle), plus un chemin glouton simulé vers le niveau de maturité suivant

Cet enregistrement est le germe de tout le reste. Point essentiel : les constats X-Ray sont ce sur quoi chaque agent en aval ancre son récit — le rapport que vous recevez est donc arrimé à vos schémas structurels précis, et non à une paraphrase générique de vos chiffres.

5. Couche 2 — Les six agents d'IA

Lorsqu'une évaluation se termine, un orchestrateur exécute un pipeline de six agents. Chaque agent a une seule tâche, et les sorties des agents antérieurs alimentent les entrées des suivants.

Le pipeline s'exécute en quatre étapes séquentielles :

5.1 Agent de notation

Déterministe, sans intervention d'un modèle de langage, s'exécute en premier. Il déroule un pipeline en huit étapes :

1. Valider — chaque question requise est répondue, une annotation « Je ne sais pas » ou « Non applicable » comptant comme une réponse ; un pilier dont moins de trois des cinq questions sont notées est refusé (E_INSUFFICIENT_PILLAR_COVERAGE), et un pilier sans aucune note est refusé avec E_NO_PILLAR_COVERAGE
2. Normaliser — chaque pilier est ramené de sa somme de Likert à 0–100, sur les seules questions réellement notées : les bornes suivent le nombre de réponses, de sorte qu'une question annotée ne tire pas le pilier vers le bas et ne le gonfle pas non plus
3. Ajuster — six règles documentées d'interdépendance entre piliers se déclenchent (§9.2)
4. Composite de référence — le global non pondéré est conservé par transparence
5. Pondération sectorielle — les pondérations des piliers sont rééquilibrées pour le secteur de l'organisation et renormalisées à 1,0 (§9.3)
6. Composer et classer — score global final, niveau de maturité, signalement des défaillances critiques
7. Détection X-Ray — huit détecteurs structurels balaient les combinaisons de réponses (§9.4). Un détecteur dont les entrées déclarées comprennent une question annotée ne s'exécute pas et est signalé comme « n'a pas pu être évalué », jamais comme un détecteur qui aurait tourné sans rien trouver
8. Simulation de levier — l'ensemble du pipeline est rejoué en relevant chaque réponse d'un cran, produisant un classement exact du gain de score de chaque amélioration possible et un chemin glouton simulé vers le niveau suivant. Le moteur étant déterministe, ce sont des faits reproductibles et non des estimations — la propriété même qui permet à un client d'auditer son score lui permet d'auditer sa feuille de route

L'arithmétique de notation est ouverte et reproductible. C'est la seule étape déterministe du pipeline — tous les autres agents ancrent leurs sorties sur ce résultat de notation et sur ses constats X-Ray, ce qui signifie que les hallucinations d'un modèle de langage ne peuvent pas déplacer votre score, et que le récit ne peut pas s'éloigner de vos schémas structurels réels.

5.2 Agent Insight

Propulsé par un modèle de langage, il produit des analyses narratives ancrées dans le résultat de notation. Pour chaque pilier :

• Une interprétation du score en langage métier, en deux ou trois phrases
• Deux risques précis si le score reste où il est
• Deux opportunités précises que débloque le passage au niveau de maturité suivant

Les sorties passent par un vérificateur d'ancrage — les affirmations qui ne se rattachent pas à un score chiffré du résultat de notation sont retirées avant affichage.

5.3 Agent Discovery

S'exécute en parallèle d'Insight, leurs entrées ne se recoupant pas. Discovery répond à la question « à quoi votre organisation ressemble-t-elle réellement vue de l'extérieur ? » :

• Classe automatiquement votre secteur via un appel de 30 jetons à un modèle de langage (pas de contamination entre secteurs)
• Récupère des signaux publics via Tavily Search et Extract (actualités récentes, dépôts réglementaires, tendances publiques de recrutement)
• Synthétise une note contextuelle : tendances du secteur, annonces de pairs, pression réglementaire observée
• Les citations sont en ligne, [S1], [S2] — pas de source, pas d'affirmation

Si le signal public est faible ou peu fiable, Discovery renonce à synthétiser plutôt que de fabriquer une lecture « de confiance moyenne ».

5.4 Agent Rapport

Compile tout ce qui précède en un document de direction structuré :

• Synthèse pour la direction (une page, pondérée par votre contexte sectoriel)
• Approfondissement pilier par pilier, avec analyses et risques
• Les trois actions recommandées, chacune rattachée à des piliers et à des obligations précises
• Section de comparaison avec le contexte sectoriel issu de Discovery
• Annexe : réponses complètes, notes de méthodologie, cartographie réglementaire

Disponible en vue applicative, en téléchargement .docx et en PDF optimisé pour l'impression.

5.5 Agent Literacy

Adaptatif, s'exécute après le Rapport. Il regarde vos piliers les plus faibles et assemble un mini-programme personnalisé :

• Articles ciblés du hub Literacy
• Questionnaires calibrés sur votre niveau de maturité
• Parcours d'apprentissage recommandés (p. ex. « De Suiveur à Poursuivant sur la gouvernance » — 4 modules, environ 3 heures)

Contrairement à une base de connaissances statique, Literacy ne recommande jamais de contenu sur des piliers où vous êtes déjà solide. Il gagne sa place dans le pipeline parce qu'il est personnalisé.

5.6 Agent Assistance

À la demande, après le pipeline. Une interface de dialogue ancrée, disposant d'un accès en lecture seule à votre évaluation, vos systèmes d'IA, vos preuves et votre couverture d'obligations.

• On lui demande : « Qu'est-ce qui nous empêche d'être Poursuivant ? »
• Elle refuse de répondre aux questions hors de son périmètre de données (pas de conseil général sur l'IA — uniquement ce qui est ancré dans l'état de votre plateforme)
• Toutes les citations renvoient à des enregistrements précis de votre compte

6. Couche 3 — L'autopilote de conformité

C'est ici qu'E-ARI cesse d'être un outil de mesure pour devenir un moteur de défendabilité. L'autopilote de conformité relie vos systèmes d'IA au règlement européen sur l'IA et produit les pièces qu'une autorité de contrôle (ou votre propre audit interne) réclamera.

6.1 Le registre des systèmes d'IA

Chaque système d'IA que vous exploitez ou déployez est enregistré avec :

• Nom et finalité — description en langage clair
• Rôle de déploiement — fournisseur, déployeur, importateur, distributeur (déterminant pour les obligations applicables)
• Secteur et populations concernées — pilote la logique de classification du risque
• Lien vers votre base de préparation — hérite automatiquement de votre contexte organisationnel

Un compte unique peut enregistrer un nombre illimité de systèmes sur les formules Growth et Enterprise.

6.2 Le classificateur de risque

Pour chaque système enregistré, un classificateur s'exécute face à la taxonomie de risque du règlement :

Chaque classification est livrée avec une justification : les articles précis qui ont déclenché le niveau, les orientations publiques qui les interprètent, et l'ambiguïté résiduelle (afin que votre DPO puisse passer outre si la position de l'autorité évolue).

6.3 Le coffre à preuves

Un magasin d'objets typé pour les preuves de conformité :

• Contrats, analyses d'impact relatives à la protection des données, fiches de modèles, documentation des jeux de données, registres de formation, audits de sécurité, rapports d'équité, etc.
• Preuves au niveau de l'organisation (valables pour tous les systèmes) et preuves par système
• Versionnées — remplacer une preuve crée une nouvelle version, l'ancienne restant liée aux analyses d'impact historiques
• Stockées dans Vercel Blob en accès privé ; URL présignées pour le téléchargement (environ 5 minutes de validité)

Au téléversement, deux choses se produisent automatiquement :

1. Classification — un modèle de langage catégorise le type de document (analyse d'impact, fiche de modèle, rapport d'audit, etc.)
2. Extraction de clauses — le document est découpé et un modèle de langage identifie quelles clauses ou phrases correspondent à quel article du règlement. Ces correspondances sont enregistrées comme EvidenceClause et deviennent réutilisables d'une obligation à l'autre.

Une analyse d'impact téléversée pour un système peut satisfaire automatiquement des parties de trois obligations différentes sur deux systèmes.

6.4 Le générateur d'analyses d'impact sur les droits fondamentaux (article 27)

Pour les systèmes à haut risque, l'analyse d'impact sur les droits fondamentaux est obligatoire.

Le générateur d'E-ARI :

1. Récupère les métadonnées de votre système d'IA (finalité, populations concernées, rôle de déploiement)
2. Récupère les clauses de preuve déjà rattachées aux articles relatifs aux droits fondamentaux
3. Produit une analyse structurée couvrant : description du processus, périodes, fréquence, catégories de personnes physiques concernées, risques précis de préjudice, dispositifs de gouvernance, mécanismes de réclamation
4. Fait apparaître les lacunes dans le texte (p. ex. « Aucune preuve trouvée sur la conception du contrôle humain — exigence de l'article 14 »)
5. Exporte en PDF et .docx avec citations de source intégrées

Vous ne pouvez finaliser une analyse d'impact que lorsque toutes les sections requises sont étayées par des preuves. Les analyses incomplètes sont conservées comme brouillons.

6.5 Le générateur de documentation technique (annexe IV)

La documentation technique de l'annexe IV est le document formel qu'un organisme notifié ou une autorité de surveillance demandera en premier.

E-ARI produit la structure complète exigée par l'annexe IV :

1. Description générale du système d'IA
2. Description détaillée (méthodes de développement, outils tiers, jeux de données d'entraînement)
3. Informations sur la surveillance, le fonctionnement et le contrôle
4. Documentation du système de gestion des risques
5. Journal des évolutions du cycle de vie
6. Indicateurs de performance, seuils d'exactitude, tests de robustesse
7. Liste des normes harmonisées appliquées
8. Déclaration de conformité (modèle)
9. Plan de surveillance après commercialisation

Chaque section puise dans votre coffre à preuves et votre plan de surveillance. Les sections sans preuve à l'appui sont clairement signalées, pour que vous sachiez exactement ce qui manque.

6.6 Le radar de lacunes

Une vue en direct de ce qui manque :

• Par obligation : nombre total de clauses requises face aux clauses actuellement étayées
• Pondéré par gravité (une lacune sur la gestion des risques de l'article 9 pèse bien plus qu'une lacune sur la journalisation de l'article 53 pour un système qui n'est pas à usage général)
• Vieillissement — les lacunes ouvertes depuis plus de 30 jours remontent en tête
• Chaque lacune dispose d'un parcours « Résoudre » en un clic, qui demande le type de preuve précis attendu

6.7 Le dossier de soumission

Un seul export .zip, prêt à remettre à un organisme notifié, à un auditeur ou à votre propre service juridique :

• Documentation technique de l'annexe IV (PDF)
• Analyse d'impact sur les droits fondamentaux (PDF, si haut risque)
• Tous les fichiers de preuve cités
• Rapport de couverture des obligations
• Plan de surveillance
• Manifeste avec sommes de contrôle SHA-256 comme preuve d'intégrité

6.8 Découverte de l'IA fantôme

La plupart des organisations découvrent des outils d'IA dont elles ignoraient l'usage : un export d'utilisation d'applications les liste, mais rien ne lit cette liste au regard d'un modèle de risque. Discovery comble cet écart sans aucun travail d'intégration : exportez votre liste d'usage d'applications depuis Google Workspace, Okta ou Microsoft Entra (ou une liste de commerçants depuis votre outil de notes de frais), téléversez le CSV, et E-ARI le rapproche d'un catalogue curé d'outils d'IA — chaque entrée annotée avec le fournisseur, la catégorie, l'indication de savoir si l'outil s'entraîne par défaut sur les données clients, et sa pertinence au regard du règlement européen sur l'IA.

Les outils reconnus apparaissent comme non déclarés jusqu'à leur enregistrement. Un clic promeut un outil découvert dans le registre des systèmes d'IA (§6.1), le fournisseur étant créé automatiquement dans le module de risque fournisseur — à partir de là, le pipeline habituel s'applique : classification du risque, obligations, preuves.

6.9 Risque lié aux fournisseurs d'IA tiers

Tout produit d'IA tiers est le modèle de quelqu'un d'autre et les conditions de données de quelqu'un d'autre. Le module de risque fournisseur envoie à chaque fournisseur un questionnaire versionné d'environ 10 minutes (traitement des données, sécurité, spécificités IA, aspects juridiques) via un lien signé — aucun compte n'est nécessaire de leur côté. La notation est déterministe : chaque réponse porte des points, les questions sans réponse comptent au pire cas, et les signaux critiques (pas d'accord de traitement, entraînement sur les données clients, pas de voie de suppression) imposent une note critique quel que soit le score chiffré. Les documents fournisseurs (accords de traitement, rapports SOC 2, listes de sous-traitants ultérieurs) sont téléversés dans le coffre à preuves et passent par la même extraction de clauses que les preuves système.

6.10 Conformité à l'article 4 sur la maîtrise de l'IA

L'article 4 du règlement — en vigueur depuis le 2 février 2025 — exige que le personnel dispose d'une maîtrise de l'IA suffisante pour son rôle. E-ARI livre un programme versionné (fondamentaux de l'IA, essentiel du règlement, protection des données, usage responsable), attribué aux membres de l'équipe via des liens magiques personnels expirant au bout de 30 jours. Les achèvements enregistrent le score du questionnaire et un condensé d'attestation SHA-256 liant le membre, le module, l'horodatage et la version du contenu. L'ensemble du suivi s'exporte en rapport de preuve prêt pour une autorité ; les membres en retard sont relancés automatiquement chaque semaine.

6.11 Contrôles continus

La vue des contrôles répond à la question qu'un auditeur pose vraiment : quelles obligations respectez-vous en ce moment ? Chaque obligation applicable à vos systèmes enregistrés reçoit un état en direct — satisfaite (étayée par au moins une clause de preuve extraite), non satisfaite (une lacune critique ou élevée ouverte) ou en attente (applicable mais pas encore étayée) — ainsi que des alertes pour les attestations dues sous 30 jours. Les états sont dérivés du coffre à preuves et du radar de lacunes, jamais auto-déclarés. Une synthèse hebdomadaire ne vous est envoyée que si une action est nécessaire.

6.12 API publique

À partir de Growth, l'accès en lecture ; Enterprise obtient l'écriture. Les points de terminaison sous /api/v1/ exposent les évaluations, le registre d'IA, les résultats de risque fournisseur et les états de contrôle dérivés, authentifiés par des clés révocables à portée limitée. La référence se trouve sur /developers.

7. Couche 4 — La surveillance continue

La conformité n'est pas un projet. C'est un processus qui tourne indéfiniment.

7.1 Bilans de rythme

Points mensuels légers, ciblant les questions les plus sensibles à la dérive (gouvernance, sécurité, talents). Prend 3 à 5 minutes. Produit un rapport d'écart par rapport à votre dernière évaluation complète.

7.2 Journal des évolutions réglementaires et surveillance de la conformité

E-ARI n'aspire pas un flux réglementaire. Les dates réglementaires proviennent d'une source unique, curée et versionnée — le journal des évolutions réglementaires, qui publie le texte consolidé du règlement sur lequel il travaille — et chaque moteur lit ses dates dans cette source.

Une tâche planifiée quotidienne (/api/cron/compliance-monitoring) vérifie vos plans de surveillance et envoie un rappel d'attestation due lorsque la prochaine attestation d'un système tombe dans les 30 jours — au plus un courriel de rappel par système et par semaine, plus une notification dans l'application. La synthèse hebdomadaire (§7.4) couvre les contrôles non satisfaits, les preuves en attente et les attestations dues.

7.3 Calendrier des attestations

L'annexe IV exige des attestations périodiques pour les systèmes à haut risque. La plateforme suit :

• Les échéances de réévaluation annuelle de conformité
• Les fenêtres de rafraîchissement des analyses d'impact relatives à la protection des données (tous les 24 mois pour les systèmes évolutifs)
• Les échéances des rapports de surveillance après commercialisation
• Les cycles de revue interne (configurables par système)

Lorsqu'une échéance tombe dans les 30 jours, la tâche quotidienne de conformité envoie un rappel d'attestation due — au plus un par système et par semaine — et crée une notification dans l'application. C'est le comportement de rappel livré ; il n'existe pas de cadence échelonnée à 60/30/7/1 jours.

7.4 Notifications par courriel et dans l'application

Toutes les notifications passent par le système de modèles unifié :

• Synthèse hebdomadaire de conformité (formules payantes — envoyée uniquement si une action est nécessaire)
• Détection de dérive planifiée avec alertes au changement — les bilans de rythme et le moteur de surveillance signalent les régressions de score ; les alertes se déclenchent au changement, non en continu

Désabonnement et gestion des préférences sur /portal/preferences.

8. Le parcours utilisateur en quatre étapes

Chaque utilisateur vit la plateforme comme quatre étapes successives. Le tableau de bord le rend explicite avec un bandeau de progression.

Étape 1 — Évaluer

Réalisez l'évaluation sur 8 piliers. Environ 15 minutes. Elle produit une base qui ancre tout le travail de conformité en aval.

Étape 2 — Vérifier

Enregistrez vos systèmes d'IA, téléversez les preuves, laissez le classificateur s'exécuter. La plateforme vous indique exactement quelles obligations s'appliquent à chaque système.

Étape 3 — Se conformer

Produisez les analyses d'impact et les documentations techniques. Comblez les lacunes. Exportez des dossiers de soumission lors d'un audit.

Étape 4 — Surveiller

Lisez le journal des évolutions réglementaires. Respectez le calendrier des attestations. Faites des bilans de rythme trimestriels pour repérer tôt les dérives.

La progression est représentée dans votre portail par une frise horizontale unique — Évaluer → Vérifier → Se conformer → Surveiller — l'étape en cours étant mise en avant, avec un appel à l'action contextuel pointant vers la prochaine action concrète.

9. Méthodologie et notation

9.1 Normalisation des piliers

Pour chaque pilier p dont les questions q₁ … q₅ sont répondues sur une échelle de Likert de 1 à 5 :

pillar_score(p) = (Σ qᵢ - 5) / 20 × 100

Cela ramène la somme brute de 5 à 25 sur une échelle de 0 à 100.

9.2 Règles d'interdépendance

Six règles documentées se déclenchent sur les scores normalisés des piliers. Chaque règle a une justification publiée et est journalisée dans l'enregistrement d'évaluation, afin que tout ajustement soit reproductible.

Les règles s'appliquent dans l'ordre déclaré. Le score d'origine, le score ajusté et la règle déclenchée sont tous conservés dans l'évaluation pour rejeu d'audit.

Composition : les règles s'appliquent dans l'ordre à la valeur courante, de sorte que chaque règle agit sur ce que la précédente a laissé. Exemple chiffré : Gouvernance 25, Sécurité 25, Technologie 75 : R1 donne 52,50, puis R3 s'applique à 52,50 et donne 44,63. Si R3 avait agi sur le 75 d'origine au lieu de la valeur courante, elle aurait produit 63,75 — le journal d'audit enregistre l'entrée et la sortie de chaque règle, et c'est précisément ce qui rend la chaîne rejouable.

9.3 Pondération sectorielle

Les pondérations par défaut vivent dans le moteur (15 % Stratégie, 15 % Données, 12 % Technologie, 13 % Talents, 15 % Gouvernance, 10 % Culture, 10 % Processus, 10 % Sécurité). Après les ajustements d'interdépendance, des multiplicateurs sectoriels sont appliqués à ces pondérations et le résultat est renormalisé pour totaliser 1,00. Le score global reste ainsi sur l'échelle de 0 à 100 tout en reflétant ce qui compte réellement dans chaque secteur.

Le score global de référence non pondéré est conservé à côté du global pondéré par secteur, afin que les rapports puissent montrer comment le contexte sectoriel a déplacé le chiffre — et pourquoi.

9.4 Le moteur X-Ray — détection de schémas structurels

Un score est un chiffre. Un schéma est une histoire. Deux organisations peuvent toutes deux atteindre 47 % — l'une parce qu'elle est uniformément moyenne, l'autre parce qu'elle affiche une ambition agressive en IA sans socle de données. Les interventions pour ces deux cas n'ont rien à voir.

Le moteur X-Ray exécute huit détecteurs déterministes sur la carte des réponses et fait apparaître des modes de défaillance structurels qui émergent de la façon dont les questions interagissent entre piliers. Chaque constat porte une gravité (faible / moyenne / élevée / critique), les preuves au niveau des questions qui l'ont déclenché, l'impact métier en termes clairs et une seule action concrète recommandée.

Le bloc X-Ray est ensuite placé en tête de l'invite de chaque agent en aval. L'agent Insight doit rattacher chaque risque et chaque prochaine action qu'il produit à un identifiant de constat. L'agent Feuille de route doit neutraliser chaque constat CRITIQUE en phase 1 et chaque constat ÉLEVÉ en phase 2. L'agent Discovery doit refléter les constats dans ses indicateurs de lacunes. C'est ce qui donne au rapport son caractère sur mesure — les agents sont ancrés dans votre jeu de schémas précis, ils ne paraphrasent pas un chiffre.

9.5 Intervalle de confiance

Un résultat de notation comprend une bande de confiance dérivée de :

• Taux de complétion des questions — les évaluations partielles obtiennent des bandes plus larges
• Variance des réponses — des extrêmes hauts et bas sur des piliers voisins suggèrent une lassitude de questionnaire
• Cohérence du texte libre — quand une explication contredit le score de Likert, la confiance baisse

La bande est affichée dans l'interface sous forme d'intervalle (p. ex. « 68 ± 4 ») et conservée dans les exports.

9.6 Comparaisons sectorielles

Les comparaisons sont curées à partir de recherches publiques (rapports d'associations professionnelles, études académiques, statistiques publiées par des autorités). Elles sont explicitement étiquetées dans l'interface :

Les comparaisons sectorielles sont estimées par IA et destinées à une orientation indicative uniquement. La performance réelle du secteur peut varier.

Nous ne prétendons jamais qu'une comparaison est à jour — nous citons l'année des données sous-jacentes.

9.7 Pourquoi nous n'utilisons pas un « score de confiance » unique

Certaines plateformes compriment tout en un seul chiffre de 0 à 100 pour la « fiabilité ». Pas nous. Un chiffre unique masque le seul signal utile : quelle dimension défaille. Une organisation peut être Chef de file en stratégie et Retardataire en sécurité simultanément — c'est actionnable. Le moyenner en « Poursuivant, 62 » ne l'est pas.

Notre méthodologie, énoncée honnêtement

E-ARI demande à une organisation d'évaluer sa propre préparation à l'IA. La littérature publiée sur l'auto-évaluation est sans ambiguïté sur ce que cela peut et ne peut pas mesurer, et cette page énonce les deux. Chaque décision de conception ci-dessous nomme sa source.

Le modèle à trois niveaux

1. Auto-déclaré — le questionnaire tel qu'il a été répondu — une mesure de perception, étiquetée comme telle.
2. Étayé par des preuves — les réponses assorties d'artefacts dans le coffre — existence vérifiée, une borne inférieure de la préparation réelle.
3. Vérifié indépendamment — les réponses vérifiées par un auditeur ou par le moteur déterministe face au coffre à preuves — fonctionnement vérifié. Pas encore proposé.

Une évaluation achevée fait donc apparaître trois chiffres, non un seul : le score auto-déclaré (étiqueté « Auto-déclaré — une mesure de perception »), le score étayé par des preuves (étiqueté « Étayé par des preuves — uniquement les réponses avec artefacts au coffre ») et la part de couverture (« X % des réponses sont étayées par des preuves »). Lorsqu'aucune réponse ne porte de preuve, le score étayé n'est pas affiché du tout — un chiffre auto-déclaré sans rien derrière n'est pas un second avis, c'est le même avis.

Les réponses sans preuve comptent pour moitié dans le score étayé. Le 0,5 est notre choix, non une constante de la littérature. Ce que la recherche établit, c'est la direction : les auto-évaluations sont indulgentes d'environ un tiers d'écart-type (d = 0,32 ; Heidemeier & Moser, 2009), et l'acquiescement pousse vers le haut les réponses sur échelle d'accord (Krosnick, 1999). Ni l'une ni l'autre ne nous donne un nombre. Nous divisons par deux ce que nul ne peut vérifier, arrondissons volontairement pour que cela ne soit pas pris pour une mesure, et affichons la part de couverture à côté afin que vous voyiez sur quelle proportion du score ce poids agit réellement. Décoter la perception — non l'effacer — est ce que le modèle à niveaux revendique.

La conception multi-évaluateurs

Une seule personne répondant aux 40 questions constitue un dispositif à informateur unique. Conway & Huffcutt (1997) situent la fidélité inter-juges à ,50 pour les supérieurs, ,37 pour les pairs et ,30 pour les subordonnés — et l'accord ENTRE sources plus bas encore, ,22 entre soi et le supérieur. Même le meilleur cas laisse la moitié de la variance chez l'évaluateur plutôt que dans l'organisation. Le mode multi-évaluateurs invite jusqu'à quatre responsables fonctionnels — le directeur technique pour Technologie et Données, le DPO pour Gouvernance et Sécurité, le directeur des opérations pour Processus et Culture, le DRH pour Talents et Stratégie — à ne répondre qu'aux piliers que couvre leur rôle. Le score de consensus est la réponse médiane par question entre évaluateurs, notée par le même moteur déterministe. Les évaluations à un seul évaluateur sont signalées comme telles, avec cette réserve attachée.

La divergence entre évaluateurs est un signal, non une erreur — elle indique où les responsables fonctionnels ont des vues différentes de la préparation de l'organisation.

Je ne sais pas, non applicable, et le rôle du répondant

Une échelle d'accord à choix forcé ne laisse à une personne qui ignore réellement la réponse que de mauvaises options. Les honnêtes choisissent « Pas du tout d'accord » — et l'instrument enregistre un constat que la personne n'a jamais formulé : un déficit de gouvernance qui est en réalité une lacune de connaissance. Les expériences de Schuman & Presser (1981) sur les filtres « sans opinion » sont le résultat classique — les formulaires à choix forcé recueillent des pseudo-opinions auprès de gens qui n'en ont pas — citées ici pour la direction seulement : cette source N'EST PAS VÉRIFIÉE DE FAÇON INDÉPENDANTE, et aucun chiffre n'en est tiré. L'évaluation enregistre donc deux annotations qu'une réponse peut porter à la place d'une note — Je ne sais pas, et Non applicable — et toutes deux sont exclues de l'arithmétique de notation : le pilier renormalise sur ses questions répondues, si bien qu'un inconnu ne tire jamais un score vers le bas et ne le gonfle jamais. Elles sont au contraire signalées comme lacunes de couverture — par pilier, « x sur 5 répondues », avec les questions sans réponse nommées. Un pilier dont toutes les questions sont annotées est refusé purement et simplement (E_NO_PILLAR_COVERAGE) : un score calculé à partir d'aucune mesure n'est pas un score. La renormalisation est bornée pour la même raison — elle emprunte les questions répondues pour tenir lieu des manquantes — de sorte qu'un pilier dont moins de trois des cinq questions sont notées est refusé lui aussi (E_INSUFFICIENT_PILLAR_COVERAGE) plutôt que de laisser deux réponses tenir lieu d'un pilier. Sans borne, l'arithmétique atteignait sa limite à une réponse notée par pilier : huit sur quarante, toutes au sommet de l'échelle, produisaient un composite de 99,99 qui ressemblait exactement à un score calculé sur l'instrument entier. Les détecteurs X-Ray ne se déclenchent pas sur une question annotée, pour la même raison que les refus — leur déclencheur ne peut être évalué sur des données qui n'existent pas — et un détecteur qui n'a pas pu être évalué est signalé comme tel, jamais comme un détecteur qui aurait tourné sans rien trouver. C'est un changement de notation, non un ajout d'interface : une évaluation qui utilise les annotations se note différemment d'une évaluation où les mêmes questions sont répondues 1. Les annotations sont arrivées en SCORING_VERSION 5.5 et la borne de renormalisation en SCORING_VERSION 5.6, chacune avec des vecteurs de conformité redérivés ; la borne ne déplace aucun score, et les évaluations notées sans annotations restent identiques bit à bit à la 5.4.

« Évaluateur unique » est la version grossière d'une question plus fine : quel évaluateur ? Un directeur technique répondant aux 40 questions parle de première main de Technologie et Données, et de seconde main de Gouvernance et Culture ; le coût en fidélité ne se répartit pas également (Conway & Huffcutt, 1997 ; la pratique 360° consistant à apparier les évaluateurs à leurs domaines est Bracken, Timmreck & Church, 2001). Chaque évaluation enregistre donc le rôle fonctionnel du répondant, et les résultats nomment les piliers que ce rôle couvre de première main — les piliers de seconde main sont étiquetés comme tels, pour qu'un lecteur voie où la perception est la plus mince. Le rôle amorce aussi les invitations multi-évaluateurs : les rôles que le répondant n'occupe pas sont ceux qu'il vaut la peine d'inviter.

Le second instrument : les constructs réglementaires

L'audit de refonte a également demandé quel terrain réglementaire les 40 questions ne couvrent pas du tout, et a trouvé neuf constructs : un inventaire des systèmes d'IA avec les classifications de l'art. 6 consignées, les obligations de chaîne d'approvisionnement pour fournisseurs et modèles à usage général, la gestion des incidents, la journalisation, les modalités du contrôle humain, la surveillance après commercialisation, la profondeur des métriques de biais, et les boucles d'audit interne (9.2) et de revue de direction (9.3) de l'ISO/IEC 42001. Ils ne sont délibérément pas ajoutés à l'instrument noté — les 40 questions sont une méthodologie gelée (SCORING_VERSION 5.6), et ajouter des questions réécrirait toutes les évaluations jamais passées. Ils forment un second instrument : une liste de contrôle diagnostique répondue par oui / non / partiellement / je ne sais pas / non applicable, où non et partiellement sont des lacunes ouvertes, je ne sais pas est une lacune de connaissance, et non applicable est enregistré et exclu. Elle est restituée comme diagnostic et lacunes — jamais comme un score. Les obligations applicables sont décidées par le moteur de conformité ; les items renvoient à ses codes d'obligation pour montrer sur quel devoir une lacune fait pression, rien de plus.

La vérification à ancrage comportemental

Lorsqu'une question a une forme factuellement vérifiable (« Votre plan de réponse aux incidents traite-t-il spécifiquement des défaillances des systèmes d'IA ? » plutôt que « Quelle est la maturité de votre réponse aux incidents ? »), l'évaluation propose les deux : l'item de Likert d'origine, qui reste la réponse notée pour la compatibilité, et un contrôle « Vérifier cette réponse » avec Oui/Non/Partiellement. Un Oui vérifié compte à plein poids dans le score étayé par des preuves ; la réponse de Likert reste inchangée. C'est le schéma BARS : demander si une chose précise et observable est vraie plutôt que ce qu'on en ressent. Latham, Wexley & Pursell (1975) et Schwarz (1999) appuient le mécanisme — le format fixe le cadre de référence, et une question vérifiable est plus difficile à gonfler qu'une question globale. Aucun des deux ne rapporte de réduction en pourcentage, et les « ~40 % » que ce document affirmait auparavant ne figuraient dans ni l'un ni l'autre.

La recherche sur les biais sur laquelle cela s'appuie

• Podsakoff, MacKenzie & Podsakoff (2012). « Sources of Method Bias in Social Science Research and Recommendations on How to Control It. » Annual Review of Psychology 63, 539–569. — La variance de méthode commune — une même personne répondant des deux côtés — gonfle les relations observées sur des constructs subjectifs. La revue établit la direction et la façon de s'en prémunir par la conception ; elle ne donne pas de pourcentage unique, et les « 25–40 % » figurant ici auparavant étaient sans source.
• Kruger & Dunning (1999). « Unskilled and Unaware of It. » Journal of Personality and Social Psychology 77(6), 1121–1134. — Les personnes du quartile inférieur se situaient au 12e centile et se plaçaient elles-mêmes au 62e — 50 points, selon les termes mêmes de l'article. Les organisations les moins équipées pour gouverner l'IA sont les plus susceptibles de bien se noter, parce qu'elles ne peuvent pas voir à quoi ressemble la maturité.
• Heidemeier & Moser (2009). « Self–Other Agreement in Job Performance Ratings: A Meta-Analytic Test of a Process Model. » Journal of Applied Psychology 94(2), 353–370. — Sur 128 échantillons, l'accord soi-supérieur est de r = ,22 et les auto-évaluations sont indulgentes de d = 0,32 (Δ = ,49 corrigé) — environ un tiers d'écart-type, non la moitié précédemment indiquée ici.
• Latham, Wexley & Pursell (1975). « Training Managers to Minimize Rating Errors in the Observation of Behavior. » Journal of Applied Psychology 60(5), 550–555. — Les évaluateurs interrogés sur un comportement observable précis se trompent moins que ceux à qui l'on demande un jugement global. C'est une étude sur la formation des évaluateurs, non une comparaison BARS contre Likert, et elle ne rapporte aucun pourcentage — les « ~40 % » indiqués ici auparavant n'y figuraient pas.
• Schwarz (1999). « Self-Reports: How the Questions Shape the Answers. » American Psychologist 54(2), 93–105. — Le format de la question fixe le cadre de référence : « Quelle est la maturité de votre réponse aux incidents ? » invite à un jugement global ; « Votre plan de réponse aux incidents traite-t-il des défaillances des systèmes d'IA ? » convoque un fait vérifiable.
• Krosnick (1999). « Survey Research. » Annual Review of Psychology 50. — L'acquiescement — approuver quel que soit le contenu — est une menace connue pour les items à échelle d'accord, réduite lorsque les questions portent sur des faits plutôt que sur une adhésion. Aucun pourcentage n'est attribué ici : les « ~10–15 % » antérieurs étaient sans source, et un chiffre de cet ordre ne justifierait de toute façon pas de diviser une réponse par deux. La décote de 0,5 est notre propre choix conservateur, décrit ci-dessous.
• Conway & Huffcutt (1997). « Psychometric Properties of Multisource Performance Ratings: A Meta-Analysis of Subordinate, Supervisor, Peer, and Self-Ratings. » Human Performance 10(4), 331–360. — La fidélité diffère selon la source : supérieurs ,50, pairs ,37, subordonnés ,30 — le ,50 est le meilleur cas, non la moyenne. L'accord entre sources est plus bas encore (soi-supérieur ,22). Tout évaluateur unique laisse l'essentiel de la variance liée à l'évaluateur, d'où l'existence du mode multi-évaluateurs et du signalement « évaluateur unique ». Le gain obtenu en moyennant plusieurs évaluateurs relève de Spearman-Brown, c'est notre projection et non un résultat de cet article.
• Van der Heijden & Nijhof (2004). « The value of subjectivity: problems and prospects for 360-degree appraisal systems. » International Journal of Human Resource Management 15(3), 493–511. — La divergence entre évaluateurs venant de fonctions différentes est en elle-même un signal diagnostique valable — le fondement du choix de rapporter la divergence au lieu de la moyenner.
• Bracken, Timmreck & Church (2001). The Handbook of Multisource Feedback. Jossey-Bass. — La pratique 360° établie : les évaluateurs répondent à des ensembles de questions appariés à leur domaine d'expertise, et le désaccord est rapporté comme un constat.
• Oxford Insights (2024). Government AI Readiness Index Methodology. — Recourt autant que possible à des sources de données vérifiables de l'extérieur et présente les données d'enquête comme « fondées sur la perception » — le modèle d'honnêteté que suivent nos étiquettes de niveaux.
• Cisco (2024). AI Readiness Index Methodology. — Énonce sans détour : « This is a perception study reflecting business leaders' views » — une auto-évaluation étiquetée comme perception, non comme préparation objective.

Ce que nous pouvons affirmer

• « Le score auto-déclaré est une mesure de perception — nous l'étiquetons comme telle »
• « Le score étayé par des preuves ne compte que les réponses assorties d'artefacts au coffre — c'est une borne inférieure de la préparation réelle »
• « La part de couverture vous indique quelle proportion de l'auto-évaluation est étayée par des preuves vérifiables »
• « Le mode multi-évaluateurs fait apparaître le désaccord entre responsables fonctionnels comme un signal diagnostique »
• « Les réponses Je ne sais pas et Non applicable sont exclues du score et rapportées comme lacunes de couverture — jamais converties en la pire réponse »
• « Chaque évaluation enregistre le rôle fonctionnel du répondant, et les résultats nomment les piliers dont ce rôle parle de première main et ceux dont il ne parle pas »
• « L'instrument de constructs couvre neuf domaines réglementaires que l'instrument noté ne couvre pas, rapportés comme diagnostic et lacunes — jamais comme un score »

Ce que nous ne pouvons toujours pas affirmer

• « Un score E-ARI plus élevé prédit le succès des projets d'IA — aucune donnée de résultat »
• « L'instrument est validé de façon indépendante — aucune étude de validation publiée (il faut 50 organisations et plus, et 12 mois) »
• « Le score étayé par des preuves équivaut à une conformité auditée — il vérifie l'existence, non l'efficacité opérationnelle »

L'étude de validation

La collecte de données pour une étude de validation a commencé. Les organisations ayant consenti reçoivent un instantané mensuel de leurs scores — auto-déclaré, étayé par des preuves, part de couverture, carte des piliers, version de notation — et le versant résultats est consigné à côté : événements de projet, d'incident et d'audit auto-déclarés, ainsi que le registre d'exactitude du compte à rebours de conformité, joints aux scores seulement au moment de l'analyse. Un retrait supprime les instantanés et les résultats d'une organisation. Rien de tout cela ne change une affirmation : il n'existe aucun chiffre de validité, et la liste « ce que nous ne pouvons toujours pas affirmer » ci-dessus reste inchangée tant qu'une étude sur ces données n'est pas publiée. L'avancement de l'étude est publié sous forme de compteur — organisations et mois — partout où cette méthodologie est divulguée, afin que la distance restant à parcourir soit énoncée plutôt que sous-entendue.

Ces limites sont porteuses. Lorsque l'instrument disposera de données de résultat, d'une étude de validation publiée ou de la validation d'un auditeur derrière un niveau, la ligne concernée passera de « ne pouvons pas » à « pouvons » — et pas avant.

10. Vie privée, sécurité et traitement des données

10.1 Ce que nous stockons

10.2 Chiffrement

• En transit — TLS 1.3 partout, inscrit sur la liste de préchargement HSTS
• Au repos — AES-256 (fourni par Supabase et Vercel Blob)
• Mots de passe — bcrypt avec facteur de coût 12

10.3 Authentification

• Courriel et mot de passe (fournisseur d'identifiants NextAuth)
• Google OAuth (fournisseur Google de NextAuth)
• SSO (OIDC) sur la formule Enterprise — configuré avec votre fournisseur d'identité (Okta, Entra ID, Google Workspace, Keycloak). Le SSO ne peut pas encore être imposé ; la connexion par mot de passe reste disponible.

Les sessions utilisent des JWT avec des cookies HttpOnly, Secure et SameSite=Lax.

10.4 Localisation des données

Le calcul est fixé à une région de l'UE (Vercel, Francfort). La base de données tourne sur Supabase (AWS) et se trouve actuellement dans la région AWS us-east-1 ; une migration vers une région de l'UE figure sur la feuille de route. Nous ne revendiquons pas aujourd'hui une localisation des données dans l'UE ; les garanties encadrant les transferts hors frontières sont décrites dans l'accord de traitement des données.

10.5 Suppression des données

• La suppression du compte se fait en autonomie depuis /portal/preferences
• La suppression est définitive (non logique) — sous 30 jours, toutes les données du compte, y compris fichiers de preuve, évaluations, analyses d'impact et journaux, sont purgées
• La conservation du journal d'audit est indépendante et purgée au bout de 90 jours, quel que soit l'état du compte

10.6 Posture RGPD

• Accord de traitement des données disponible sur demande (hello@e-ari.com)
• Liste des sous-traitants ultérieurs tenue à jour sur /privacy#sub-processors
• Droit à l'effacement honoré sous 30 jours
• Droit à la portabilité — export complet du compte en JSON depuis /portal/preferences

10.7 Recours à des modèles de langage tiers

Nous utilisons plusieurs fournisseurs de modèles de langage (Gemini, GLM, modèles hébergés par NVIDIA). Tous les fournisseurs sont configurés en rétention de données nulle pour notre clé d'API. Nous n'utilisons pas les données clients pour entraîner un quelconque modèle. Les saisies en texte libre sont expurgées des motifs courants de données personnelles avant tout envoi vers un point de terminaison de modèle de langage.

11. Formules et tarifs

11.1 Ce qui est inclus par formule

11.2 Résiliation

Résiliable à tout moment. L'accès demeure jusqu'à la fin de la période de facturation. Le compte revient automatiquement à Starter — vos données sont conservées, vous perdez simplement l'accès aux fonctionnalités payantes.

12. À qui cela s'adresse

12.1 Trois profils principaux

Le responsable de programme IA dans une entreprise de taille intermédiaire (environ 500 à 5 000 salariés). Rattaché au directeur des opérations ou des systèmes d'information. Porte la feuille de route de la stratégie IA. A besoin d'E-ARI pour :

• démontrer les progrès à la direction, trimestre après trimestre
• traduire les lacunes de préparation en propositions d'investissement précises
• montrer au conseil que l'entreprise n'est pas en retard sur ses pairs

Le DPO ou responsable conformité dans toute organisation déployant de l'IA dans des juridictions de l'UE. A besoin d'E-ARI pour :

• classer automatiquement les systèmes d'IA au regard du règlement
• tenir un coffre à preuves vivant qui survivra à un audit
• produire analyses d'impact et documentations techniques sans mandater un grand cabinet d'avocats

L'auditeur interne préparant un audit externe, une certification ISO 42001 ou l'évaluation d'un organisme notifié. A besoin d'E-ARI pour :

• produire un dossier de soumission unique avec sommes de contrôle
• montrer les tendances de couverture dans le temps (rythme de comblement des lacunes)
• fournir des journaux infalsifiables pour toute modification d'un artefact

12.2 À qui cela ne s'adresse pas

Nous sommes explicites là-dessus. E-ARI n'est pas le bon outil s'il vous faut :

• un registre de modèles (utilisez MLflow, Weights & Biases ou une plateforme MLOps)
• un outil GRC généraliste couvrant SOC 2, ISO 27001, HIPAA (utilisez Vanta, Drata, Secureframe)
• un conseil juridique (E-ARI met au jour des obligations ; il ne remplace pas un avocat)
• la gestion de projet de la livraison IA (utilisez Linear, Jira, Asana)

Plus le périmètre est resserré, meilleur est l'outil.

13. Feuille de route

Axes de travail actuels (susceptibles d'évoluer) :

La feuille de route est publiée sur la plateforme et mise à jour chaque mois.

14. Glossaire

Règlement sur l'IA — Règlement (UE) 2024/1689 du Parlement européen et du Conseil établissant des règles harmonisées concernant l'intelligence artificielle. Entré en vigueur le 1er août 2024.

Annexe III — La liste des cas d'usage d'IA à haut risque énumérés à l'annexe III du règlement (biométrie, éducation, emploi, services essentiels, application de la loi, migration, justice).

Annexe IV — La structure de la documentation technique exigée pour les systèmes d'IA à haut risque.

Article 5 — Interdit certaines pratiques d'IA : manipulation subliminale, exploitation de vulnérabilités, notation sociale, identification biométrique en temps réel dans l'espace public.

Article 27 — Impose une analyse d'impact sur les droits fondamentaux pour les systèmes d'IA à haut risque utilisés par des autorités publiques ou des opérateurs de services essentiels.

Articles 50 à 53 — Obligations de transparence pour les systèmes à risque limité (agents conversationnels, hypertrucages, catégorisation biométrique, reconnaissance des émotions).

Évaluation de la conformité — La procédure par laquelle un système d'IA à haut risque démontre sa conformité aux exigences du règlement avant sa mise sur le marché de l'UE.

Déployeur — Toute personne physique ou morale, autorité publique ou agence utilisant un système d'IA sous son autorité. À distinguer du fournisseur (l'entité qui développe le système ou le fait développer).

AIPD — Analyse d'impact relative à la protection des données au titre de l'article 35 du RGPD. Souvent un préalable à l'analyse d'impact sur les droits fondamentaux.

AIDF — Analyse d'impact sur les droits fondamentaux au titre de l'article 27 du règlement sur l'IA.

Modèle d'IA à usage général — Modèle de fondation. Soumis à un régime d'obligations distinct au titre des articles 51 à 55.

Organisme notifié — Organisme désigné par un État membre de l'UE pour évaluer la conformité de certains systèmes d'IA à haut risque avant leur mise sur le marché.

Pilier — L'une des huit dimensions de préparation d'E-ARI (Stratégie, Données, Technologie, Talents, Gouvernance, Culture, Processus, Sécurité).

Bilan de rythme — Une évaluation mensuelle courte, ciblant les questions sensibles à la dérive.

Dossier de soumission — L'export .zip unique réunissant documentation technique de l'annexe IV, analyse d'impact, preuves et manifeste — prêt pour un organisme notifié ou un auditeur.

Documentation technique — Le dossier exigé par l'annexe IV pour les systèmes d'IA à haut risque. Doit être tenu à jour pendant toute la vie du système.

Annexe A — URL clés

Annexe B — Contact

E-ARI est exploité par l'équipe E-ARI. Le calcul applicatif est fixé à l'UE (Vercel, Francfort) ; la base de données tourne sur Supabase (AWS, us-east-1 aujourd'hui), une migration vers une région de l'UE figurant sur la feuille de route. Ce document fait foi à la date de version indiquée ci-dessus ; la version la plus récente est toujours servie sur https://www.e-ari.com/docs/e-ari-handbook.md.