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.1 · septembre 2026

Avant-propos

La plupart des outils de gouvernance de 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 registre vivant, où les systèmes, les obligations, les preuves et les actions revues 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 registre qui classe vos systèmes d'IA et relie les obligations applicables, les preuves et les actions revues qui les étayent, les exports qu'un vérificateur peut contrôler, la surveillance qui guette de nouvelles lacunes, ainsi que l'évaluation de préparation et les agents d'IA qui diagnostiquent les pratiques de l'organisation.

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. L'espace de gouvernance
5. La surveillance continue
6. L'évaluation de préparation
7. Les agents d'IA
8. Le parcours utilisateur
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 (le nom vient d'Enterprise AI Readiness Index) est une plateforme de gouvernance de l'IA et de preuves, conçue autour du règlement européen sur l'IA. Elle aide une organisation à répondre à cinq questions, dans l'ordre :

En complément du registre, une évaluation de préparation sur 8 piliers, comparée à votre secteur, diagnostique les pratiques de l'organisation ; la synthèse hebdomadaire de conformité, le journal des évolutions réglementaires et les rappels avant les échéances d'attestation maintiennent le dossier à jour. Le résultat n'est pas un PDF unique : systèmes, obligations, preuves, actions revues, analyses d'impact sur les droits fondamentaux, documentations techniques et scores de préparation restent versionnés et exportables.

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. Chaque système enregistré est classé par des règles, et ses obligations découlent de cette classification. 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 autour d'un seul dossier. Chaque couche a son propre modèle de données et ses propres surfaces d'interface, et toutes lisent et écrivent le même registre.

À côté des couches, l'évaluation de préparation (8 piliers, 40 questions), les bilans de rythme et les agents d'IA diagnostiquent les pratiques de l'organisation. L'enregistrement ne requiert pas d'évaluation ; un système peut, en option, être rattaché à une évaluation terminée.

4. L'espace de gouvernance

C'est le cœur d'E-ARI : le dossier qu'une autorité de contrôle, un client ou votre propre audit interne réclamera. L'espace de gouvernance relie vos systèmes d'IA au règlement européen sur l'IA et produit les pièces qui étayent chaque obligation applicable.

4.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
• Profil d'inventaire — le type de système (assistant, fonction d'IA, modèle, agent), son étape de cycle de vie, l'équipe qui l'exploite, les données qu'il touche et leur provenance ; pour un agent, jusqu'où il agit seul et ce à quoi il accède (§4.16)

La formule Gratuite enregistre jusqu'à 3 systèmes d'IA et Pro jusqu'à 25 ; Enterprise n'a pas de plafond.

4.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).

4.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.

4.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.

4.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.

4.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

4.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é

4.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 (§4.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.

4.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.

4.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.

4.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.

4.12 API publique

L'API fait partie de la formule Enterprise, en lecture et en é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.

4.13 Actions et décisions revues

Le travail de gouvernance a besoin d'un responsable et d'une trace de ce qui a été décidé. Une action peut naître d'une question d'évaluation, d'une obligation ou d'un contrôle sur un système, d'une preuve, d'un contrat ou d'un incident. Chaque source porte une clé stable : la demander deux fois ouvre la même action, jamais un doublon. Une action a une personne assignée, une échéance, ses preuves à l'appui et un résultat ; une fois le travail soumis, un propriétaire ou un administrateur le revoit.

Chaque revue terminée ajoute un enregistrement qui ne sera jamais réécrit : la décision et la justification de la personne, séparées de la recommandation du système, avec le réviseur, la version des règles, un instantané de la source, les références des preuves et leurs empreintes, et la date de la prochaine revue. Les décisions sur les contrats et les risques acceptés doivent fixer cette date. Une revue étayée par des preuves peut clore un constat d'obligation enregistré ; accepter un risque ne le clôt pas, et ni l'une ni l'autre ne modifie la couverture déterministe ou la classification juridique.

Une décision ne vaut que par les faits sur lesquels elle repose. Lorsqu'ils changent (le coût, le responsable ou les liens d'un contrat, l'état du fournisseur, le contexte de gouvernance du système, les preuves ou leur fraîcheur, la tranche d'utilisation, la recommandation en cours), la décision apparaît aussitôt comme à revoir, et la tâche quotidienne de surveillance de la conformité rouvre la même action. Un enregistrement renommé ou une observation plus récente ne suffit pas, à lui seul, à invalider une décision. La vue d'ensemble et la synthèse hebdomadaire placent en tête les constats critiques, le travail en retard et les décisions à revoir.

4.14 Dépenses IA et décisions de déploiement

Dépenses IA (Pro et Enterprise) est un registre des contrats d'IA que vous payez : l'outil, sa catégorie, la tarification au siège ou à l'usage, le coût annuel, la devise, la date de renouvellement, le préavis, le responsable, le fournisseur et les systèmes qu'il fait tourner. Pour chaque contrat, il répond à une seule question : le garder, le supprimer, le corriger d'abord, ou choisir entre deux outils qui font le même travail. La réponse de gouvernance passe en premier : un usage interdit, un système non classifié ou un accord de traitement des données manquant s'affiche au-dessus du nombre de sièges.

Les chiffres restent traçables. Le coût par personne active est le coût annuel divisé par le nombre de personnes comptées dans l'export d'usage du fournisseur lui-même ; rien n'est converti entre devises et rien n'est projeté. Les imports d'usage conservent des comptes par période, jamais par personne : les personnes sont dédoublonnées par un identifiant stable ou une adresse e-mail, puis ces identifiants sont supprimés. Les lignes agrégées exigent de confirmer explicitement que les groupes réunissent des personnes différentes, importer deux fois le même fichier ne change rien, et remplacer un rapport qui en chevauche un autre demande une confirmation et conserve l'ancien comme historique remplacé. Un usage périmé ou impossible ne produit ni coût par utilisateur ni chiffre de sièges inutilisés.

Les règles recommandent ; une personne décide. La décision est enregistrée comme décision revue (§4.13), avec une note et une date de prochaine revue. Les rappels tombent à la date de renouvellement moins le préavis enregistré. Lorsque le préavis est inconnu, la date de renouvellement est utilisée à la place et signalée comme non confirmée.

4.15 Rapports de gouvernance

Les rapports (/portal/reports) capturent l'ensemble de l'espace de travail tel qu'il est, indépendamment de toute évaluation. Un rapport de gouvernance unique sert la direction, et des références de source numérotées, chacune renvoyant à l'enregistrement d'origine, appuient le suivi d'audit. Il couvre les points qui demandent attention, l'inventaire des systèmes et leurs responsables, le programme de gouvernance (les instances de gouvernance et le contrôle avant la mise en production, la politique d'IA et ses confirmations, le registre des risques, les évaluations d'impact et, une fois établie, la déclaration d'applicabilité ISO/IEC 42001), la couverture candidate des obligations, l'assurance sur les preuves et les revues, les actions et décisions, les observations enregistrées sur la période choisie, l'exposition aux fournisseurs et aux contrats, et le contexte des évaluations enregistrées. Il ne contient aucun récit rédigé par un modèle ni aucun score de gouvernance composite.

Un rapport est un instantané de l'état actuel, pas une reconstitution du passé : la date de la période d'activité ne filtre que les observations de surveillance enregistrées. Le contenu capturé est conservé avec son empreinte SHA-256, qui l'identifie sans constituer une signature indépendante ; les exports scellés des systèmes restent le livrable d'assurance spécialisé. Chaque rapport est comparé au précédent de la même édition. L'édition partagée exclut les coûts des contrats et leurs justifications privées ; l'édition restreinte les inclut, et seuls les propriétaires et les administrateurs peuvent l'ouvrir.

Toute personne qui peut modifier l'espace de travail peut créer un rapport. En créer un consomme l'allocation mensuelle de rapports (§11.1) ; télécharger un rapport enregistré ne la consomme pas. Un rapport commence comme brouillon. Un propriétaire ou un administrateur le finalise après l'avoir lu, avec une note obligatoire ; le PDF du brouillon d'origine est conservé, et les changements ultérieurs demandent une nouvelle version. Finaliser n'est ni une certification réglementaire ni une approbation des décisions que contient le rapport. Le contenu des rapports est en anglais pour l'instant ; les commandes qui l'entourent suivent votre langue.

4.16 Le profil d'inventaire

Un registre qui nomme un système sans dire ce qu'il est, où il en est ni ce qu'il touche ne répond pas aux questions pour lesquelles on tient un inventaire. Chaque système peut indiquer son type (un assistant ou chatbot, une fonction d'IA intégrée à un produit, un modèle que l'organisation entraîne ou héberge, ou un agent qui agit), son étape de cycle de vie (prévu, pilote, en production, retiré), l'équipe ou l'unité qui l'exploite, les catégories de données qu'il touche (catégories particulières, données biométriques, données d'enfants, données personnelles, données du personnel, données confidentielles ou informations publiques uniquement) et leur provenance. Pour un agent, il indique aussi jusqu'où l'agent agit seul, ce qu'il peut faire et ce à quoi il accède.

Aucun de ces champs ne modifie la classification au titre du règlement sur l'IA, qui lit la finalité, la description, le secteur et les personnes concernées : les modifier ne rend donc jamais une qualification provisoire. Ils alimentent le contrôle de mise en production, les règles de données de la politique et la déclaration ISO/IEC 42001, et le registre peut être filtré par agents, données personnelles et systèmes en production. Le profil fait partie du registre dans toutes les formules.

4.17 La structure de gouvernance et le contrôle de mise en production

La gouvernance (Pro et Enterprise) indique qui décide. Les instances de gouvernance — un comité, un conseil, un groupe désigné — ont un mandat, un rythme de réunion, des membres et les décisions qui leur reviennent (mises en production, acceptation des risques, politique d'IA, demandes d'outils). Leurs membres n'ont pas besoin de compte : un propriétaire ou un administrateur enregistre la décision de l'instance en son nom, et l'enregistrement indique qui l'a saisie. Chaque système désigne un responsable, la personne chargée du contrôle humain en utilisation (art. 14 ; art. 26, par. 2, pour les déployeurs) et l'approbateur de sa mise en production.

Le contrôle de mise en production dit ce qui doit être vrai avant qu'un système passe en production. Chaque point lit un enregistrement que le produit tient déjà : un responsable désigné, un contrôle humain attribué, une classification non provisoire, aucun écart critique ouvert, une FRIA et une documentation technique finalisées là où le moteur d'obligations les applique, une évaluation d'impact terminée, un registre des risques sans risque élevé ou critique dépourvu de traitement, une politique d'IA publiée et une approbation. L'organisation choisit les points exigés et peut ajouter ses propres points, qu'une personne confirme pour chaque système. Le contrôle est indicatif par défaut ; imposé, le registre refuse le passage en production tant que les points exigés ne sont pas remplis et indique lesquels manquent.

L'approbation est une décision revue (§4.13). Elle enregistre la liste telle qu'elle était, et elle se périme dès qu'un élément change, comme toute autre décision revue.

4.18 La politique d'IA

La politique d'IA (Pro et Enterprise) réunit les règles de travail du personnel : les outils approuvés et pour quoi, l'information la plus sensible que chacun peut voir, ce qui peut être saisi dans un outil d'IA selon la catégorie d'information, ce qui n'est jamais autorisé (y compris les pratiques interdites par l'art. 5), la vérification et le signalement des contenus produits par l'IA, la formation à la maîtrise de l'IA exigée, qui approuve les nouveaux outils et comment signaler une préoccupation. L'organisation fait chaque choix dans un brouillon ; E-ARI rédige le document à partir de ces choix en anglais, français, portugais, espagnol ou allemand. Le modèle écrit des phrases ; il ne décide d'aucune règle.

Publier fige le brouillon enregistré comme version suivante : le texte rendu et un SHA-256 calculé dessus, avec une note de publication et une date de revue. Une version publiée ne change jamais ; une modification est une nouvelle version. Les personnes de l'équipe reçoivent un lien personnel, valable 30 jours et sans compte, pour lire la version et confirmer leur lecture. Chaque confirmation nomme la version lue et porte une empreinte à clé ; si une version plus récente est publiée pendant la lecture, la confirmation est refusée et la personne lit la nouvelle. Toute personne disposant d'un siège membre peut demander un outil que la politique n'approuve pas ; la demande est tranchée comme une décision revue, et l'approuver ajoute l'outil au brouillon, pas au texte publié.

4.19 Le registre des risques et les évaluations d'impact

Le registre des risques (Pro et Enterprise) consigne ce qui pourrait mal tourner avec chaque système. Une personne évalue la probabilité et l'impact de 1 à 5 ; le niveau est le produit des deux, réparti selon des seuils fixes affichés à côté de chaque score (1–4 faible, 5–9 moyen, 10–15 élevé, 16–25 critique). Chaque risque a une catégorie, un traitement (atténuer, accepter, transférer ou éviter), un plan de traitement, une évaluation après traitement facultative, un responsable et une date de revue. Accepter un risque, ou confirmer que son traitement a fonctionné, est une décision revue, et un risque tranché qui est réévalué ou reçoit un nouveau traitement se rouvre. Le registre montre tous les risques, score actuel le plus élevé en premier, avec une carte 5 × 5 avant et après traitement.

L'évaluation d'impact couvre chaque système, comme le demande l'ISO/IEC 42001 A.5 : qui le système concerne, comment il pourrait affecter des personnes et des groupes, ses effets plus larges sur la société, la gravité, l'étendue et la réversibilité de ces effets, comment on peut le superviser ou le contester, et ce qui est en place. Les réponses sont écrites par une personne ; le produit ne les note pas et n'en tire aucune conclusion. La terminer enregistre qui l'a terminée et la date de sa prochaine revue, et modifier une réponse la repasse en brouillon. Pour un système à haut risque soumis à l'analyse d'impact sur les droits fondamentaux de l'art. 27, la FRIA (§4.4) reste l'enregistrement légal.

4.20 La déclaration d'applicabilité ISO/IEC 42001

La déclaration d'applicabilité (Enterprise) liste les 38 mesures de l'annexe A de l'ISO/IEC 42001, regroupées par objectif. Pour chacune, l'organisation indique si elle s'applique — avec la justification que demande l'article 6.1.3 lorsqu'elle ne s'applique pas —, son niveau de mise en œuvre et la manière dont elle est remplie. E-ARI ne fixe jamais ce statut. À côté de chaque mesure, il liste les enregistrements de l'espace de travail qui s'y rapportent (la politique publiée et sa date de revue, les instances de gouvernance, les responsables et le contrôle humain, les évaluations d'impact, le personnel formé, les approbations de mise en production, les risques, les incidents, les évaluations et accords fournisseurs) sous forme de décomptes qui renvoient à leur source, ainsi que les preuves déposées sous les types d'artefacts correspondants. Une mesure sans rien derrière elle n'est pas prouvée dans E-ARI, ce qui n'équivaut pas à non mise en œuvre. La déclaration s'exporte en CSV. La certification relève d'un organisme de certification accrédité ; la correspondance entre enregistrements et mesures est propre à E-ARI.

5. La surveillance continue

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

5.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.

5.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 (§5.4) couvre les contrôles non satisfaits, les preuves en attente et les attestations dues.

5.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.

5.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.

6. L'évaluation de préparation

L'évaluation de préparation est un diagnostic d'appui des pratiques de l'organisation. L'enregistrement des systèmes ne la requiert pas, et ni son score ni son niveau de préparation ne constituent une détermination de conformité.

6.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.

6.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.

6.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.

7. Les 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 :

7.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.

7.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.

7.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 ».

7.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.

7.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é.

7.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

8. Le parcours utilisateur

La vue d'ensemble de votre portail suit ces quatre étapes et affiche d'abord la prochaine action.

Étape 1 — Enregistrer

Commencez par un système d'IA que vous utilisez réellement ; l'analyse d'IA fantôme repère les outils que personne n'a déclarés. Le classificateur par règles fixe le niveau de risque de chaque système et les obligations qui s'appliquent. L'enregistrement ne requiert pas d'évaluation de préparation.

Étape 2 — Gouverner

Revoyez les classifications, reliez les preuves aux obligations qu'elles étayent et traitez les actions d'amélioration suivies pour vos systèmes. Les contrôles indiquent pour chaque obligation si elle est étayée, en échec ou en attente de preuves.

Étape 3 — Évaluer

Répondez aux 40 questions de l'évaluation de préparation pour obtenir un score et un niveau de maturité sur 8 piliers — un diagnostic des pratiques de l'organisation dont les priorités deviennent des actions d'amélioration.

Étape 4 — Maintenir

Revoyez régulièrement systèmes, preuves et préparation. Suivez le journal des évolutions réglementaires et le calendrier des attestations, exportez des dossiers scellés qu'un vérificateur peut contrôler, et faites des bilans de rythme entre deux évaluations.

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

• Adresse e-mail professionnelle et mot de passe (fournisseur d'identifiants NextAuth). Les adresses de messagerie personnelles comme Gmail, Outlook.com ou Yahoo sont refusées à l'inscription, à la connexion et à l'invitation d'équipe.
• SSO (OIDC) sur la formule Enterprise — configuré avec votre fournisseur d'identité (Okta, Entra ID, Google Workspace, Keycloak). Lorsque le SSO est imposé, la connexion par mot de passe est refusée et les sessions hors SSO prennent fin, même si le fournisseur d'identité est injoignable ou non enregistré ; seul un opérateur qui désactive l'imposition rétablit l'accès par mot de passe.
• Aucune connexion via un compte grand public (Google, GitHub, X).

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 eu-central-2, Zurich) ; la Suisse n'est pas membre de l'UE mais bénéficie d'une décision d'adéquation de la Commission européenne. Le fournisseur de modèles par défaut traite les données en Chine et d'autres sous-traitants ultérieurs opèrent dans leurs propres régions (voir /security#subprocessors) : nous ne revendiquons donc pas une localisation des données exclusivement 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 publié sur /data-processing
• Registre des sous-traitants ultérieurs tenu à jour sur /security#subprocessors
• 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

Le fournisseur de modèles par défaut de la plateforme est DeepSeek, qui traite les données en Chine ; la Chine ne bénéficie d'aucune décision d'adéquation de la Commission européenne, les garanties de transfert doivent donc être évaluées. Les fonctions assistées par modèle sont la génération de textes, l'extraction de clauses des preuves téléversées, la rédaction de conformité et l'enrichissement des organisations ; le scoring de préparation et la classification des risques par règles n'utilisent aucun modèle de langage. Les conditions de conservation et d'entraînement suivent les conditions d'API du fournisseur : E-ARI ne revendique aucun engagement négocié de rétention nulle ou de non-entraînement, et n'entraîne aucun modèle propre sur les données clients. Le texte des preuves envoyé pour l'extraction de clauses est d'abord expurgé des données personnelles par expressions régulières.

11. Formules et tarifs

11.1 Ce qui est inclus par formule

Sur la feuille de route et pas encore disponibles : le provisionnement SCIM, les espaces multi-entités, les contrôles et référentiels personnalisés, et la collecte continue des preuves.

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 à la formule Gratuite — vos données sont conservées, vous perdez simplement l'accès aux fonctionnalités Pro.

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 eu-central-2, Zurich). 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.