L'évaluation multiniveau des demandes d'IA est la discipline opérationnelle consistant à orienter chaque demande d'IA vers un niveau de révision proportionnel à son risque - généralement réparti sur quatre niveaux, du libre-service au restreint. Elle remplace le processus d'examen à filière unique qui s'effondre lorsque le volume de gouvernance se heurte à la vitesse d'adoption. Elle constitue le pilier de tout programme de gouvernance de l'IA opérant à l'échelle de l'entreprise.

Points clés

Le principe de proportionnalité. Chaque grand cadre réglementaire de l'IA — la loi européenne sur l'IA (EU AI Act), la norme ISO/CEI 42001 et le NIST AI RMF — converge vers la même exigence opérationnelle : l'examen appliqué à un système d'IA doit être proportionnel au risque qu'il présente. L'évaluation multiniveau est la méthode de mise en œuvre de cette exigence à l'échelle de l'entreprise.

Le modèle à quatre niveaux. Libre-service / Évaluation légère / Évaluation complète / Restreint. Chaque niveau possède un profil de risque, un processus d'évaluation et un approbateur définis. Cette structure s'aligne parfaitement sur la catégorisation des risques à quatre niveaux de la loi européenne sur l'IA et sur les contrôles basés sur les risques de la norme ISO 42001.

L'évaluation comme discipline continue. L'évaluation n'est jamais finalisée pour tout système supérieur au niveau 1. Les déclencheurs de modifications substantielles, les mises à jour des modèles des fournisseurs et les changements de portée des cas d'usage imposent tous une réévaluation. Les programmes qui traitent l'évaluation comme une formalité unique échouent à grande échelle.

L'évaluation : le pilier de tout programme de gouvernance

Chaque composante d'un programme de gouvernance de l'IA — l'inventaire de l'IA, la bibliothèque d'évaluation, le rythme de surveillance, la documentation réglementaire, la piste d'audit — dépend de l'évaluation initiale. Sans elle, le programme ne gouverne que ce qu'il connaît, et ce qu'il connaît s'écarte de ce qui est en production en l'espace d'un trimestre. Ce schéma est systématique chez les entreprises ayant franchi la première vague d'adoption de l'IA : le mode de défaillance est rarement flagrant. La gouvernance devient si lente qu'elle finit par être contournée.

Ce contournement progressif se manifeste de deux manières distinctes. Le premier cas, le goulot d'étranglement, apparaît lorsqu'un processus d'examen unique est appliqué à chaque demande d'IA, créant ainsi des files d'attente. Une équipe marketing de produits de grande consommation soumettant une demande pour un outil de rédaction d'IA attend derrière un système de classement des candidats qui requiert légitimement une évaluation de conformité de plusieurs semaines. Après que les responsables opérationnels ont subi ce retard à plusieurs reprises, ils commencent à contourner le processus : les comptes personnels sont utilisés, des services d'IA publics gratuits absorbent le travail, et des fonctionnalités SaaS intégrées sont activées en toute confidentialité. La surface de l'IA fantôme (shadow AI) s'étend en proportion inverse du débit d'évaluation, et l'inventaire reflète de plus en plus ce qui a été approuvé plutôt que ce qui est réellement en production.

La surface de l'IA fantôme s'étend en proportion inverse du débit d'évaluation.

Le second cas est celui de la défaillance par inadéquation. Un processus d'examen unique, opérant au niveau de profondeur qu'exige réellement un système à haut risque, devient une contrainte administrative excessive pour les outils à faible risque. Les choix se limitent alors à deux issues également insatisfaisantes : soit la profondeur de l'évaluation est diluée au point de ne plus satisfaire au régime réglementaire, soit le programme perd sa crédibilité interne en exigeant du service marketing qu'il remplisse le même questionnaire de 200 questions que celui utilisé pour les modèles d'octroi de crédit. Dans les deux cas, le programme est moins efficace qu'il n'y paraît sur le papier.

L'évaluation multiniveau répond à ces deux problématiques. Ce principe est validé par tous les grands régimes réglementaires de l'IA : l'article 6 de la loi européenne sur l'IA,[4] la clause 6.1.4 de la norme ISO 42001 lue conjointement avec les clauses 6.1.2 et 8.2 de la même norme,[2] ainsi que la fonction de gouvernance (Govern) du NIST AI RMF.[3] Elle est également réalisable sur le plan opérationnel à l'échelle de l'entreprise.

Le modèle à quatre niveaux : adapter l'examen au risque

Figure 1 : Le modèle d'évaluation de la gouvernance de l'IA à quatre niveaux. L'analyse s'adapte en fonction du risque, la répartition de chaque niveau dans un programme éprouvé étant d'environ 60-70 % pour le niveau 1, 20-25 % pour le niveau 2, 5-15 % pour le niveau 3 et un pourcentage faible mais non nul pour le niveau 4.

Appliqué à une demande concrète, ce modèle s'avère particulièrement fluide. Prenons l'exemple d'une équipe RH sollicitant un système de classement des candidats basé sur l'IA auprès d'un fournisseur tiers. Ce cas d'usage relève de l'annexe III de la loi européenne sur l'IA[6] (emploi), qui constitue le seuil d'accès au niveau 3. Le système prend des décisions importantes concernant des personnes (emploi), ce qui confirme l'affectation au niveau 3. Les données sont sensibles (les CV contiennent des données personnelles, parfois des données de catégorie particulière), ce qui la confirme à nouveau. Chaque critère converge ; la demande est orientée vers le niveau 3 avec une évaluation complète, un examen multipartite, une documentation technique conforme à l'annexe IV[7] et des déclencheurs de réévaluation définis, liés aux mises à jour de modèles du fournisseur.

À l'inverse, considérons un outil grammatical interne utilisé uniquement sur des textes marketing déjà publiés. Aucune donnée personnelle, aucune décision importante, aucun impact externe. Les critères convergent vers le niveau 1. L'évaluation se résume à un formulaire d'inscription rempli en deux minutes ; le système apparaît dans l'inventaire avant la fin de la journée ; aucun évaluateur humain n'intervient sur la demande, sauf si une exception est signalée.

C'est la présence du niveau 4 qui donne toute sa crédibilité au reste de la structure.

Sans une option de refus explicite, le processus d'évaluation accepte implicitement chaque demande comme étant à terme gouvernable, et les dispositions relatives aux usages interdits des régimes applicables deviennent invisibles pour le programme. Une inscription au niveau 4 doit figurer dans la piste d'audit avec un refus documenté — ce dossier constitue en lui-même une preuve de maturité de la gouvernance auprès d'un régulateur.

Cas particuliers notables. Certains systèmes se situent à la frontière des niveaux. Un système de niveau 2 dont le cas d'usage s'étend de manière significative (par exemple, un assistant conversationnel de support client dont le rôle s'élargit pour inclure des décisions de remboursement) doit être réévalué et peut passer au niveau 3. Inversement, un système de niveau 3 opérationnel avec une supervision humaine substantielle depuis deux ans et dont le profil de risque s'est avéré stable peut faire l'objet d'un passage au niveau 2 avec maintien de la surveillance. Les changements de niveau doivent résulter d'une décision documentée et non d'un processus automatique. La question à se poser est la suivante : un régulateur accepterait-il cette nouvelle classification compte tenu des éléments disponibles ?

Les systèmes d'agents autonomes constituent le point d'inflexion que ce modèle doit gérer

Le modèle à quatre niveaux n'est pas une nouveauté. Ce qui est nouveau, c'est la vitesse à laquelle les systèmes de niveau 3 apparaissent, principalement sous l'impulsion de l'IA d'agents autonomes, cette classe de systèmes autorisés à mener des actions autonomes plutôt qu'à produire de simples résultats validés par un humain. L'évaluation des systèmes d'agents autonomes diffère structurellement sur trois points que le modèle à quatre niveaux doit intégrer.

Premièrement, le facteur d'autonomie impose un positionnement par défaut au niveau 3, quel que soit le cas d'usage sous-jacent. Une IA d'agent qui traite des questions internes relatives aux notes de frais se classe au niveau 2 par sa sensibilité d'utilisation, mais dès qu'elle reçoit l'autorisation de soumettre de véritables notes de frais ou de planifier des remboursements, elle bascule dans le niveau 3. Le profil de risque ne réside pas dans la « nature de la décision » mais dans la « nature de l'action ».

Deuxièmement, l'évaluation de ces systèmes doit définir explicitement les limites d'autorité. Une évaluation pour un agent de niveau 3 doit établir les outils que l'agent peut solliciter, les actions qu'il peut exécuter sans validation humaine, les conditions d'escalade qui déclenchent un transfert de témoin et la surveillance qui encadre son comportement entre deux validations. Rien de tout cela ne correspond à la structure de questionnaire classique adaptée aux systèmes d'IA statiques ; les formulaires d'évaluation des agents requièrent généralement 30 à 40 % de critères supplémentaires, centrés sur le champ d'action plutôt que sur le traitement des données.

Troisièmement, la notion de modification substantielle s'interprète différemment. Pour un système d'IA statique, les mises à jour de modèles constituent le principal déclencheur de réévaluation. Pour un système d'agents, l'extension de la liste d'autorisations d'action (permettre à l'agent d'appeler une nouvelle API, d'écrire dans un nouveau système d'archivage ou de transférer des fonds dans une nouvelle catégorie) constitue une modification substantielle qui peut dépasser entièrement la portée de l'évaluation initiale, sans que cela soit nécessairement visible dans le modèle lui-même. Le processus d'évaluation des systèmes d'agents de niveau 3 doit exiger l'enregistrement explicite de la liste des actions autorisées lors du déploiement et une réévaluation lors de toute modification de cette liste.

Pour les systèmes d'agents autonomes, la question n'est pas « quel type de décision » mais « quel type d'action ».

Classifier les systèmes de manière cohérente : les sept dimensions

L'attribution d'un niveau doit aboutir au même résultat pour un profil de risque identique, quel que soit l'évaluateur qui traite la demande. Un processus de classification mal conçu génère des dérives ; un processus performant applique un ensemble de dimensions cohérentes à chaque demande et l'oriente de façon déterministe. Un formulaire d'évaluation bien conçu pose cinq à huit questions réparties sur les dimensions ci-dessous et exploite les réponses pour orienter le flux de manière automatisée. Une intervention manuelle reste possible pour les cas limites réels ; une classification manuelle systématique engendre des incohérences.

Pour les entreprises de services financiers réglementées en particulier, la dimension de gestion des risques liés aux modèles (MRM) dépasse le simple cadre d'une donnée d'entrée ; elle déclenche un cycle de vie parallèle (validation du modèle, surveillance continue, recertification périodique) que l'évaluation initiale doit transférer à la fonction MRM existante plutôt que de la réexécuter. Le dossier d'évaluation d'un système d'IA concerné par la MRM doit faire référence à l'identifiant MRM correspondant, et non reproduire la procédure MRM.

En cas de conflit entre les dimensions. Les dimensions convergent généralement vers la même direction, mais il arrive parfois que non. Un système de maintenance prédictive dans une usine peut traiter un minimum de données personnelles, ne prendre aucune décision importante concernant des individus et être entièrement réversible, tout en faisant partie d'un produit de l'annexe I (machines) dont l'intégration de l'IA est considérée comme à haut risque en vertu de l'article 6, paragraphe 1, de la loi européenne sur l'IA.[4] La seule catégorie de cas d'usage impose alors le niveau 3, indépendamment de ce que suggèrent les autres dimensions. La règle consiste à retenir le niveau le plus élevé indiqué par l'une des dimensions et à documenter ce choix.

L'exception de l'article 6, paragraphe 3. La loi européenne sur l'IA autorise un fournisseur à déterminer lui-même qu'un système de l'annexe III ne présente pas de risque élevé si ce système effectue une tâche purement procédurale ou préparatoire, ou s'il améliore le résultat d'une activité humaine préalablement achevée sans influer sur la décision finale. Cette exception est particulièrement restreinte.[13] Un outil d'IA qui reformate des CV selon une mise en page standardisée pour un recruteur humain peut y prétendre. En revanche, un outil d'IA qui classe ces mêmes CV selon une estimation d'adéquation ne le peut pas, même si la décision finale d'embauche revient à un humain ; le classement influe sur la décision d'une manière que le législateur considère comme significative. L'usage abusif de l'exception 6(3) constitue en soi un risque de non-conformité. Le processus de classification doit considérer les décisions relatives à l'article 6(3) comme des conclusions formelles nécessitant une justification solide, et non comme de simples facilités opérationnelles.

La transparence de l'article 50, et l'intérêt d'en faire une dimension spécifique. L'article 50 de la loi européenne sur l'IA[15] impose des obligations de transparence pour les systèmes d'IA qui interagissent avec des humains, génèrent du contenu synthétique ou produisent des deepfakes, indépendamment du cas d'usage ou du secteur. Un assistant de support client de niveau 2 relève de l'article 50 dès lors qu'un client ne peut pas le distinguer d'un agent humain sans mention explicite. Le formulaire d'évaluation doit tester directement les déclencheurs de l'article 50 ; aborder cette dimension tardivement, lors d'une évaluation de conformité de l'annexe III qui ne l'avait pas anticipée, crée des failles documentaires qui apparaîtront lors des audits. À compter du 2 août 2026, il s'agira d'une obligation stricte pour les fournisseurs et les utilisateurs de ces systèmes, qui devra figurer dans la décision d'évaluation.

L'acquisition par une banque d'un assistant de support client tiers illustre l'interaction de ces critères. Le fournisseur présente son système comme présentant un « risque limité » car les réponses sont conversationnelles et les agents humains gèrent les escalades. Le processus d'évaluation de la banque applique ses critères : catégorie du cas d'usage (relation client, pas de seuil lié à l'annexe III) ; sensibilité des données (les transcriptions peuvent contenir des informations de compte - augmente le niveau) ; impact décisionnel (informatif uniquement - pas de hausse) ; réversibilité (les réponses peuvent être rectifiées - pas de hausse) ; degré d'autonomie (réponses sans validation humaine de chaque message - augmente le niveau vers un profil de type agent) ; déclencheurs de transparence (l'article 50 s'applique - mention obligatoire de l'assistant) ; déclencheurs sectoriels (contexte de services financiers - augmente encore) ; déclencheurs MRM (aucun modèle sous-jacent directement régi par SR 11-7 / SS1/23 pour un assistant tiers - informatif) ; source (achat tiers - nouvelle évaluation nécessaire). Le système est classé dans la tranche haute du niveau 2, voire au niveau 3 selon l'évaluation de la sensibilité des données.

La qualification de « risque limité » par le fournisseur n'a pas de valeur ; seule la classification de l'organisation utilisatrice fait foi.

Pour en savoir plus sur la gestion des risques liés aux fournisseurs de cette nature, consultez notre guide d'évaluation des risques liés aux fournisseurs d'IA tiers.

Le processus en cinq étapes, adapté à chaque niveau

La procédure d'évaluation suit un schéma en cinq étapes bien défini, quel que soit le niveau. Le niveau détermine le degré d'analyse requis à chaque étape.

Schéma présentant le processus d'évaluation de la gouvernance de l'IA en cinq étapes : Étape 1 Identifier le cas d'usage, Étape 2 Consulter l'inventaire, Étape 3 Évaluation du risque, Étape 4 Examen, Étape 5 Décision. Cette structure s'applique à tous les niveaux ; la profondeur de chaque étape étant adaptée à la classification par niveau.

Ce schéma en cinq étapes s'applique à tous les niveaux. C'est l'exigence de traitement de chaque étape qui varie selon le niveau. Un dossier de niveau 1 peut être entièrement traité en vingt minutes ; une demande de niveau 3 exige généralement de quatre à six semaines pour la seule phase d'évaluation, puis deux semaines supplémentaires pour la phase d'examen et d'approbation. Les rôles doivent être ainsi définis par niveau : au niveau 1, le demandeur agit en qualité de propriétaire désigné et le système est intégré automatiquement à l'inventaire ; au niveau 2, l'approbateur désigné au sein de l'équipe juridique ou des risques assume la décision, et le demandeur reste responsable du suivi opérationnel ; au niveau 3, le comité d'évaluation multipartite détient le pouvoir décisionnel, un évaluateur indépendant désigné prend en charge l'examen de la documentation technique, et le responsable opérationnel demeure garant de l'usage effectif.

La modification substantielle constitue le fait générateur qui motive le retour à l'étape 3. L'article 3(23) de la loi européenne sur l'IA définit la modification substantielle comme un changement apporté à un système d'IA après sa mise sur le marché qui affecte sa conformité ou sa destination initiale.[14] Des principes équivalents figurent dans la norme ISO 42001 (qui considère tout changement important de nature à motiver une réévaluation au sein du système de management de l'IA) ainsi que dans le NIST AI RMF (pour qui un changement matériel doit déclencher une nouvelle analyse des risques). Exemples concrets : un fournisseur déploie une mise à jour d'un modèle de fondation modifiant le comportement d'un outil ; la liste des actions autorisées d'un système autonome s'étend à une nouvelle API ; le rôle d'un assistant de support client s'élargit aux décisions de remboursement ; les données d'apprentissage d'un modèle affiné (fine-tuned) s'enrichissent de nouvelles sources. Chacun de ces cas correspond à une modification substantielle potentielle nécessitant une réévaluation selon le niveau requis, non dans un but bureaucratique mais car l'analyse de risque initiale peut s'avérer caduque.

Imaginons un établissement de santé ayant déployé un outil d'aide au diagnostic par IA en 2025, à l'issue d'une évaluation de niveau 3 établie sur une version précise du modèle de données de l'époque. En avril 2026, le fournisseur annonce une mise à jour de version du modèle intégrant de nouvelles données d'apprentissage et un processus d'inférence perfectionné. Selon les règles relatives aux modifications substantielles, l'établissement de santé doit réactiver le processus d'évaluation ; l'analyse effectuée l'année précédente n'intégrant pas les nouveaux comportements du modèle mis à jour. Cette réévaluation peut conclure qu'aucun changement n'est requis, mais cette conclusion doit être formellement documentée.

Du manuel à l'automatisé : le point d'inflexion qui impose une solution logicielle

Passer de quatre heures de traitement par cas d'usage à moins d'une heure. À effectif constant. Sous les mêmes exigences réglementaires. En six mois.

Telle est la réalité opérationnelle d'une entreprise de biens de consommation qui a remplacé ses processus manuels — basés sur des échanges d'e-mails et des formulaires Google Forms — par un système automatisé d'évaluation multiniveau. Si la réduction du temps de traitement constitue l'indicateur le plus visible, la transformation structurelle s'avère plus déterminante. Avant ce changement, l'équipe de gestion des risques représentait un goulot d'étranglement pour toutes les demandes d'IA, quel que soit leur niveau de risque. Désormais, les demandes à faible risque n'interfèrent plus avec celles à haut risque, les comités d'examen se concentrent sur les systèmes qui le réclament réellement, et la constitution de la piste d'audit est conforme aux exigences réglementaires par défaut, plutôt que d'être reconstituée a posteriori.

Un processus multiniveau peut fonctionner manuellement. C'est ainsi que débute la majorité des initiatives : formulaires d'e-mails, tableurs partagés, réunions régulières d'examen. Cette organisation convient pour le traitement des premières dizaines de demandes.

Cependant, le passage à l'automatisation s'impose au-delà d'un certain volume. Les symptômes de saturation sont d'ailleurs prévisibles. L'évaluation manuelle tend à diverger selon les évaluateurs — un même système se voit attribuer des niveaux distincts selon la personne chargée du dossier. Les pistes d'audit par e-mail se fragmentent entre collaborateurs, canaux de projets et répertoires partagés, sans possibilité d'établir une source unique d'information exploitable pour un régulateur. Les échéances de réévaluation sont oubliées car aucun outil n'assure leur suivi à grande échelle. Les demandes de niveau 1, qui devraient être automatisées, se retrouvent bloquées dans la même file que celles de niveau 3 car les règles d'orientation résident uniquement dans l'esprit d'un collaborateur qui se trouve être absent.

Les fonctionnalités indispensables se révèlent alors évidentes : un inventaire partagé sécurisé auquel plusieurs équipes peuvent collaborer, une classification multiniveau automatisée reposant sur les réponses fournies, l'orientation automatique des dossiers vers les bons évaluateurs, l'édition de rapports conformes aux exigences réglementaires et une traçabilité pérenne face aux réorganisations internes.

Opter pour un traitement manuel ou automatisé revient à décider du niveau de charge réglementaire que l'organisation accepte de supporter à mesure qu'elle déploie l'IA. Un processus structuré retarde le point d'inflexion mais ne l'élimine pas. Les entreprises qui choisissent l'automatisation dès le départ considèrent l'investissement dans une plateforme comme une condition préalable indispensable au déploiement de l'IA, bien avant d'atteindre ce point critique ; celles qui attendent d'y être acculées se résignent à faire des compromis.

Comment l'évaluation s'intègre au sein de l'architecture GRC existante

L'évaluation se montre réellement performante dès lors qu'elle devient le point d'accès unique vers les autres dispositifs GRC de l'entreprise — évaluation des tiers, achats, validation sécurité, conformité RGPD — plutôt qu'une démarche parallèle. Créer un nouveau processus déconnecté des structures déjà en place génère des doubles saisies et des sources d'information contradictoires, au détriment du programme de gouvernance.

Le résultat de l'évaluation doit se traduire par une fiche d'information unique à laquelle tous les acteurs clés (achats, juridique, sécurité et conformité) se réfèrent au titre de leurs obligations propres :

• La gestion des risques tiers s'appuie sur la fiche d'évaluation pour déterminer les clauses contractuelles requises relatives aux usages d'IA (délais de notification de modifications, droits d'audit, communication de fiches de modèles).

• Les achats s'y réfèrent pour veiller à ce que la structure contractuelle soit alignée sur la classification de risque du système et l'usage prévu. Dans la pratique, la coordination avec les achats s'avère la plus délicate : les solutions d'achats classiques (OneTrust, ServiceNow VRM, ProcessUnity) gèrent l'application des modèles de contrats, et les bibliothèques de clauses spécifiques à l'IA doivent être intégrées à ces flux plutôt que gérées séparément.

• La sécurité l'exploite pour évaluer les répercussions sur les droits d'accès, analyser les flux de données requis et établir le plan de modélisation des menaces concerné.

• La protection des données y recourt pour décider des analyses d'impact (AIPD) requises, apprécier l'incidence sur les droits des usagers et anticiper les transferts de données transfrontaliers.

Le coût de fonctionnement de deux systèmes de gouvernance parallèles est structurel, et non marginal.

La fiche d'évaluation constitue la source d'information commune à l'ensemble des acteurs. En pratique, cela exige de concevoir ou de choisir un outil d'évaluation disposant d'interfaces d'intégration éprouvées avec l'écosystème GRC de l'entreprise. Le préjudice d'une approche scindée s'accroît à mesure que les données de référence se désynchronisent.

L'évaluation des solutions d'un fournisseur d'IA par une banque offre un exemple concret d'intégration réussie. L'évaluation déclenche automatiquement les tâches nécessaires : l'équipe risques tiers reçoit le dossier d'évaluation et y apporte des compléments spécifiques à l'IA ; l'équipe juridique examine la révision des clauses contractuelles de prévisibilité et d'audit ; la sécurité récupère la cartographie des flux pour son analyse des menaces ; la conformité RGPD élabore l'AIPD à l'aide des données catégorisées en amont. Aucun de ces acteurs ne sollicite à nouveau les mêmes informations ; tous s'alimentent du dossier d'évaluation. Pour le fournisseur d'IA, l'organisation s'exprime d'une voix unifiée et non par des demandes redondantes de multiples divisions.

Les mécanismes de défaillance de l'évaluation multiniveau (et leurs solutions)

Le modèle multiniveau peut défaillir selon sept schémas identifiés. Les cinq premiers apparaissent généralement dans les dix-huit premiers mois ; les deux derniers surviennent lors des deuxième et troisième années, compromettant discrètement des démarches qui avaient pourtant surmonté les premières difficultés. Chacun possède un indicateur caractéristique détectable lors des revues de gouvernance et peut être résolu par des corrections de structure.

Éclairage sur l'anomalie initiale la plus courante. Considérer l'évaluation comme une étape unique constitue le piège dans lequel tombent la majorité des organisations à l'origine, et celui dont le coût cumulé est le plus préjudiciable. L'indicateur caractéristique : une revue trimestrielle d'inventaire révèle trois ou quatre systèmes modifiés en profondeur depuis leur validation originelle — le fournisseur a procédé à une mise à jour majeure du modèle, les cas d'usage se sont étendus, de nouveaux flux de données sont exploités — sans réactiver le processus d'évaluation. Après un an d'exercice, les classifications de risques de l'inventaire ne correspondent plus à la réalité ; après dix-huit mois, la traçabilité ne représente plus fidèlement le fonctionnement des systèmes déployés. La réponse est structurelle : chaque système au-delà du niveau 1 doit bénéficier d'une périodicité de réévaluation définie (annuelle pour le niveau 2, semestrielle pour le niveau 3) et d'un inventaire d'événements déclencheurs imposant une réévaluation précoce. Ces deux aspects doivent être formalisés dès la décision initiale de validation et non ajoutés ultérieurement.

L'incidence critique des deux défaillances de deuxième année. Le désengagement de la direction générale et la dérive bureaucratique des comités d'examen représentent les véritables écueils des programmes à maturité. Ces défaillances demeurent invisibles lors des revues courantes ; elles ne se révèlent qu'à la suite d'un incident significatif forçant l'organisation à attester de la pertinence de sa gouvernance au moment de la validation d'un outil. Les réponses structurelles — indicateurs valorisés d'exposition pour le conseil d'administration, renouvellement régulier des évaluateurs indépendants, avis contradictoires formalisés — relèvent de la pratique opérationnelle et non d'un changement culturel ; elles se doivent d'être ancrées au cœur du fonctionnement du système, sous peine d'être perçues par le régulateur comme un simple apparat de conformité.

Pour en savoir plus sur l'organisation de l'inventaire sous-jacent à ces signaux, rejoignez notre guide pour la constitution d'un inventaire de systèmes d'IA.

Indicateurs d'évaluation de l'An 1

Les données statistiques ci-dessous définissent le profil de fonctionnement ciblé pour un système d'évaluation multiniveau durant les 12 à 18 premiers mois, ainsi que le niveau de maturité espéré au cours de la troisième année. Ces plages d'objectifs de référence s'appuient sur les parcours constatés des programmes de la clientèle d'Enzai.[16] Chaque démarche se nuance selon la maturité de départ, le secteur réglementaire et le degré d'automatisation des évaluations — ces critères modélisent un profil de référence plutôt qu'un engagement absolu de rendement. Un dispositif s'évaluant en deçà de ces valeurs après un an d'exercice souffre généralement de l'absence de l'un des correctifs présentés auparavant.

Un programme qui n'enregistre aucune demande de niveau 4 échoue probablement à identifier les cas à exclure ; un système qui oriente l'intégralité des requêtes vers le niveau 3 s'est affranchi de l'effort de classification et opère une sur-classification protectrice au détriment de l'agilité métier. Ces deux situations révèlent que le moteur de règles de conformité mérite une révision.

La mise en pratique du principe de proportionnalité

Chaque projet d'évaluation multiniveau retranscrit de manière rigoureuse le principe de proportionnalité exigé par tous les cadres réglementaires contemporains de l'IA : la matrice à quatre niveaux apporte le cadre formel, les huit caractéristiques d'analyse modélisent la logique d'orientation, la méthodologie en cinq étapes dessine la déclinaison opérationnelle par niveau et les indicateurs d'évaluation valident l'efficacité de la démarche.

L'évaluation multiniveau permet ainsi de générer une clarté documentaire que les processus papier ne peuvent garantir. Avec un dispositif opérationnel fluide, les initiatives d'IA peuvent se multiplier sans perdre la maîtrise des enjeux majeurs : les usages critiques à risques confirmés sont orientés dès l'entrée, les projets courants se déploient rapidement sans contraintes indues et l'historique d'audit ainsi généré est directement diffusable à un régulateur sans préparation spécifique.

Le principal piège consiste à confondre la rigueur opérationnelle avec l'accumulation documentaire — une dérive fréquente constatée par les autorités de contrôle. Un programme de conformité doté d'analyses très précises mais dénué d'exclusion réelle au niveau 4 s'apparente à une simple formalité administrative plutôt qu'à une démarche de gouvernance. Le principe de proportionnalité n'est pleinement efficace qu'à la condition qu'un refus justifié fasse partie intégrante des pratiques opérationnelles ordinaires au même titre qu'un examen de conformité approfondi.

Pour en savoir plus sur l'encadrement des agents autonomes d'IA à intégrer en complément des processus d'évaluation des niveaux supérieurs, lisez notre Guide de référence de gouvernance des agents autonomes d'IA.

Foire aux questions

Qu'est-ce que l'évaluation multiniveau de la gouvernance d'IA ?

L'évaluation multiniveau représente le cadre d'entreprise visant à orienter chaque projet d'IA vers une démarche d'examen de conformité proportionnelle à sa criticité de risques. La majorité des organisations retiennent une structure découpée en quatre niveaux — libre-service, évaluation légère, évaluation complète et restreint —, chacun de ces niveaux encadrant ses propres exigences de classification, de validation, de complétude documentaire et sa périodicité de réévaluation. Ce modèle remplace les grilles d'examen uniformes qui saturent quand le volume d'initiatives se confronte au rythme d'adoption d'IA.

Combien de niveaux de conformité un programme de gouvernance d'IA doit-il intégrer ?

Une structure découpée en quatre niveaux s'avère le seuil optimal pour la majorité des entreprises. Les organisations qui pilotent moins d'une centaine d'usages s'orientent fréquemment vers une grille simplifiée à trois niveaux (combinant l'évaluation légère et l'évaluation complète avec des questionnaires plus ciblés pour cette dernière). Dépasser cinq ou six niveaux alourdit inutilement le dispositif : chaque niveau additionnel crée de la confusion à la frontière des autres catégories d'analyse et génère des coûts de coordination entre services sans valeur ajoutée pour la gestion des risques.

Quels sont les systèmes d'IA de niveau 3 par défaut ?

Tout système d'IA qualifié dans l'annexe III de la loi européenne sur l'IA, tout outil prenant des décisions impactantes sur des individus (recrutement, octroi de crédits, tarification d'assurance, accès au logement, santé, justice, services d'utilité publique), tout usage déclenchant une réglementation sectorielle de risques, et l'intégralité des architectures d'agents autonomes dotés de capacités d'action directe, quel que soit le cas d'usage concerné. La règle : retenir le niveau le plus élevé identifié par l'un des critères d'évaluation de la grille et consigner formellement l'argumentaire associé.

Comment le processus d'évaluation multiniveau cadre-t-il l'IA d'agents autonomes ?

Les systèmes d'agents autonomes d'IA sont affectés d'autorité au niveau 3 car leur degré d'autonomie opérationnelle élève de conception la nature des risques encourus, quel que soit l'usage cible. L'évaluation de ces structures d'IA requiert de détailler formellement la liste des actions autorisées, de spécifier les cas d'escalade exigeant une intervention humaine et de formaliser le dispositif d'analyse de comportement entre ces interventions. L'extension de la liste des actions autorisées correspond à une modification substantielle imposant une réévaluation d'office.

Quels éléments imposent la réévaluation d'un système d'IA validé au préalable ?

Une modification substantielle — définie par l'article 3(23) de la loi européenne sur l'IA comme tout écart ou modification apporté à un dispositif d'IA postérieurement à son introduction sur le marché de nature à influer sur sa conformité réglementaire ou sa destination cible. Les motifs d'alerte opérationnels courants comprennent : les mises à jour majeures du modèle par le fournisseur d'IA, l'évolution de la liste d'actions validées d'un agent autonome, l'élargissement de l'usage cible, l'ajout de nouvelles sources de d'apprentissage pour des modèles affinés ou l'augmentation significative du bassin d'usagers ou des zones géographiques d'utilisation. Les solutions de niveau 2 font l'objet d'un examen annuel régulier ou sur déclenchement d'alerte ; celles de niveau 3 s'examinent sur un rythme semestriel régulier ou sur déclenchement d'alerte.

Combien de temps faut-il pour concevoir un de ces systèmes d'évaluation à partir de zéro ?

Comptez de trois à six mois d'exercice régulier pour éprouver le processus en mode manuel sur la première sélection d'usages ; de neuf à quinze mois pour atteindre le niveau d'efficacité des objectifs de référence de première année ; et d'un an et demi à deux ans d'exercice pour se projeter vers la maturité de la troisième année. La transition d'un traitement manuel vers l'automatisation s'impose de fait au-delà d'un effectif d'usages ciblé — généralement situé entre 50 et 200 systèmes d'IA sous contrôle selon le débit d'arrivée des nouvelles demandes.

L'évaluation multiniveau a-t-elle pour objet de remplacer les structures GRC d'achats et de conformité fournisseurs existantes ?

Non, l'un s'organise en amont des autres. Le dossier d'évaluation d'IA constitue la source d'information partagée unique de référence que la gestion des risques tiers, les achats, la sécurité et la RGPD exploitent pour instruire leurs obligations réglementaires propres ; aucun service ne sollicite ainsi de nouvelles explications redondantes. L'écueil de gouvernance classique consiste à mettre en place l'évaluation de conformité IA comme un dispositif détaché du reste ; le modèle performant s'appuie sur l'évaluation d'IA en tant que guichet d'entrée central d'informations alimentant les processus GRC en aval.

Où se situe Enzai vis-à-vis d'outils d'entreprise de type ServiceNow ou OneTrust ?

Enzai s'établit comme la structure logicielle dédiée à la gouvernance de l'IA de haute spécificité se plaçant en amont de vos architectures GRC d'entreprise telles que ServiceNow, OneTrust et ProcessUnity, avec lesquelles elle communique. Le dossier de conformité IA initié au sein d'Enzai alimente les flux opérationnels déjà en place dans ces suites logicielles ; l'analyse approfondie propre à l'IA d'entreprise et les référentiels de règles d'envergure réglementaires sont hébergés et gérés par Enzai. La majorité de nos clients exploitent les fonctionnalités d'Enzai en articulation avec leurs solutions GRC existantes plutôt qu'en remplacement.

Quel est le rôle d'Enzai

Ce référentiel pose les grands principes opérationnels. Enzai propose la plateforme logicielle qui les met en musique — l'arborescence à quatre niveaux, l'orientation de risques automatique selon vos critères d'analyse, le processus d'évaluation en cinq étapes et la traçabilité d'audit consolidée, l'ensemble fonctionnant comme une véritable infrastructure logicielle de conformité. Si vous vous situez à ce point d'inflexion opérationnel et souhaitez analyser la maturité de vos processus actuels face aux standards de notre guide, contactez nos équipes — nous serons ravis de soumettre à l'essai l'un de vos cas d'usage réels au sein de notre modèle.

Découvrez le document de synthèse complet : Le guide de référence de la gouvernance de l'IA — De l'ambition stratégique à l'encadrement opérationnel aborde la structure d'évaluation multiniveau en complément de la définition des politiques, des cadres de conformité, de la gestion d'inventaires d'usages, de la conception des évaluations et du suivi continu. Télécharger la documentation complète.

Enzai s'impose comme la solution de référence pour la gouvernance de l'IA en entreprise, spécialement conçue pour accompagner le passage de règles abstraites à un contrôle opérationnel éprouvé. Notre plateforme de pilotage des risques d'IA propose l'infrastructure spécialisée indispensable pour encadrer des IA d'agents autonomes, consolider un inventaire exhaustif et garantir la conformité aux exigences de la loi européenne sur l'IA (EU AI Act). Par l'automatisation des flux complexes de vérification, Enzai permet aux entreprises de déployer l'usage de l'IA avec prédictibilité tout en démontrant le respect des grands standards internationaux tels que l'ISO 42001 et le NIST.

Sources et Références

1. Règlement (UE) 2024/1689 du Parlement européen et du Conseil établissant des règles harmonisées concernant l'intelligence artificielle (loi sur l'intelligence artificielle). Journal officiel de l'Union européenne, juillet 2024. eur-lex.europa.eu/eli/reg/2024/1689/oj

2. ISO/CEI 42001:2023, Technologies de l'information — Intelligence artificielle — Système de management. Organisation internationale de normalisation, décembre 2023. iso.org/fr/standard/81230.html

3. NIST, Cadre de gestion des risques liés à l'intelligence artificielle (AI RMF 1.0), NIST AI 100-1. National Institute of Standards and Technology, janvier 2023. nist.gov/itl/ai-risk-management-framework

4. Règlement (UE) 2024/1689, Article 6 — Règles de classification pour les systèmes d'IA à haut risque.

5. Règlement (UE) 2024/1689, Article 5 — Pratiques interdites en matière d'intelligence artificielle.

6. Règlement (UE) 2024/1689, Annexe III — Systèmes d'IA à haut risque visés à l'article 6(2).

7. Règlement (UE) 2024/1689, Annexe IV — Documentation technique visée à l'article 11(1).

8. Colorado SB 24-205, Loi relative aux protections des consommateurs pour l'intelligence artificielle, promulguée en mai 2024. leg.colorado.gov/bills/sb24-205

9. Prudential Regulation Authority de la Banque d'Angleterre, Supervisory Statement SS1/23, « Principes de gestion des risques liés aux modèles pour les établissements bancaires », mai 2023. bankofengland.co.uk

10. Board of Governors of the Federal Reserve System, Lettre SR 11-7, « Directives de supervision sur la gestion des risques de modèles », avril 2011. federalreserve.gov

11. Loi locale de New York de 2021, Local Law 144, sur les outils d'aide automatisée aux décisions de recrutement (AEDT). nyc.gov/site/dca/about/automated-employment-decision-tools.page

12. California Privacy Protection Agency, Projets de règlements relatifs aux technologies de décision automatisée (ADMT). cppa.ca.gov/regulations/

13. Règlement (UE) 2024/1689, Article 6(3) — Dérogation pour les systèmes de l'annexe III ne présentant pas de risque sérieux.

14. Règlement (UE) 2024/1689, Article 3(23) — Définition d'une modification substantielle.

15. Règlement (UE) 2024/1689, Article 50 — Obligations de transparence pour les fournisseurs et les exploitants de certains systèmes d'IA.

16. Les cibles de taux de couverture de première année, de répartition des niveaux d'évaluation et de délais de prise de décision présentées dans cette étude s'appuient sur l'analyse de données consolidées de programmes opérationnels d'IA de clients d'Enzai ayant complété un exercice de 12 mois minimum de leur processus de validation multiniveau. Les tendances effectives de chaque projet varient en fonction du profil de départ, du contexte sectoriel et du degré d'automatisation des évaluations ; ces chiffres modélisent un profil type d'efficacité de processus plutôt qu'un engagement contractuel de performance.