Blog
•
37 min de lecture
Le processus de demande IA par niveaux est la discipline opérationnelle qui consiste à soumettre chaque demande d’IA à une revue d’une profondeur proportionnée à son risque, généralement selon quatre niveaux allant du niveau Libre-service au niveau Restreint. Il remplace le circuit de revue unique, qui cède dès que le volume de gouvernance rencontre la vitesse d’adoption, et constitue la pièce maîtresse de tout programme de gouvernance de l’IA mené à l’échelle de l’entreprise.
Points clés
Le principe de proportionnalité. Tous les grands cadres réglementaires de l’IA, à savoir l’EU AI Act, l’ISO/IEC 42001 et le NIST AI RMF, convergent vers la même exigence opérationnelle : le niveau d’examen appliqué à un système d’IA doit être proportionné au risque qu’il présente. Le processus de demande par niveaux permet de mettre en œuvre cette exigence à l’échelle de l’entreprise.
Le modèle à quatre niveaux. Libre-service / Revue allégée / Revue complète / Restreint. Chaque niveau a un profil de risque, un processus de revue et un approbateur définis. Cette structure correspond directement à la classification des risques en quatre catégories de l’EU AI Act et aux contrôles fondés sur les risques de l’ISO 42001.
Le processus de demande, une discipline continue. Pour tout système au-delà du niveau 1, le processus de demande n’est jamais « terminé ». Les déclencheurs de modification substantielle, les mises à jour des modèles par les fournisseurs et les changements de périmètre des cas d’usage imposent tous une réévaluation. Les programmes qui traitent la demande comme une étape ponctuelle échouent à grande échelle.
Le processus de demande, pièce maîtresse de tout programme de gouvernance
Chaque composante d’un programme de gouvernance de l’IA repose sur le processus de demande : l’inventaire IA, la bibliothèque d’évaluations, la fréquence de surveillance, la documentation réglementaire, la piste d’audit. Sans lui, 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. Le schéma se répète dans toutes les entreprises qui ont franchi la première vague d’adoption de l’IA : l’échec est rarement spectaculaire. La gouvernance devient assez lente pour qu’on la contourne.
Ce contournement progressif prend deux formes distinctes. La première, le mode d’échec par goulet d’étranglement, apparaît lorsqu’un circuit de revue unique s’applique à toutes les demandes d’IA et crée des files d’attente. L’équipe marketing d’une entreprise de produits de grande consommation qui demande un outil d’IA de rédaction publicitaire attend derrière un système de classement de candidats qui exige à juste titre une évaluation de la conformité de plusieurs semaines. Après avoir subi ce délai trois ou quatre fois, les responsables métier commencent à contourner le processus : ils utilisent des comptes personnels, confient le travail à des services d’IA publics gratuits, activent sans le déclarer des fonctionnalités intégrées à leurs SaaS. Le périmètre de l’IA fantôme s’étend en proportion inverse de la capacité de traitement des demandes, et l’inventaire reflète de plus en plus ce qui a été approuvé plutôt que ce qui est en production.
Le périmètre de l’IA fantôme s’étend en proportion inverse de la capacité de traitement des demandes.
La seconde est le mode d’échec par lacune. Un circuit de revue unique calibré sur la profondeur qu’exige réellement un système à haut risque devient une charge punitive pour les outils à faible risque. Il ne reste alors que deux options, aussi mauvaises l’une que l’autre : soit la profondeur est diluée jusqu’à ne plus satisfaire au régime réglementaire, soit le programme perd sa crédibilité en interne, parce qu’il demande au marketing de remplir la même évaluation de 200 questions que pour les modèles de notation de crédit. Dans les deux cas, le programme est moins efficace qu’il n’y paraît sur le papier.
Le processus de demande par niveaux répond à ces deux écueils. Son principe est consacré par tous les grands régimes réglementaires de l’IA : l’article 6 de l’EU AI Act[4], l’article 6.1.4 de l’ISO 42001, lu conjointement avec les articles 6.1.2 et 8.2 de la même norme[2], et la fonction Govern du NIST AI RMF[3]. Il est en outre réalisable en pratique à l’échelle de l’entreprise.
Le modèle à quatre niveaux : un examen à la mesure du risque
Niveau | Profil de risque | Exemples | Processus | Approbateur |
|---|---|---|---|---|
1 - Libre-service | Aucune donnée personnelle, aucune décision aux conséquences importantes, aucun impact externe | Transcription interne, complétion de code non sensible, outils de correction grammaticale, chatbots internes fondés sur la documentation publiée | Formulaire d’enregistrement succinct, approbation automatique sur la base d’une liste d’autorisation publiée, ajout automatique à l’inventaire | Automatique |
2 - Revue allégée | Interfaces exposées aux clients, données personnelles limitées, conséquences opérationnelles modérées | Chatbots de support client, générateurs de contenus marketing, analyse des appels commerciaux, outils IA de synthèse de réunions utilisés sur des transcriptions clients | Questionnaire structuré couvrant 15 à 25 dimensions, fréquence de surveillance définie, documentation proportionnée | Un approbateur nommément désigné au sein du service juridique ou des risques |
3 - Revue complète | Catégories de l’annexe III, décisions aux conséquences importantes pour les personnes, systèmes agentiques capables d’agir de manière autonome, régimes sectoriels à haut risque | Classement de candidats, notation de crédit, identification biométrique, aides au diagnostic médical, agents d’achat autonomes, souscription d’assurance pilotée par l’IA | Évaluation complète des risques et de la faisabilité, documentation technique complète selon chaque régime réglementaire applicable, revue multipartite, déclencheurs de réévaluation définis | Comité de revue multipartite (juridique, risques, sécurité, responsable métier, évaluateur indépendant le cas échéant) |
4 - Restreint | Interdit par la législation applicable, ou catégoriquement inacceptable au regard de la politique de l’organisation | Identification biométrique en temps réel dans l’espace public, visée à l’article 5 de l’EU AI Act[5], systèmes de notation sociale, reconnaissance des émotions sur le lieu de travail | Arrêt au stade de la demande. Refus documenté et motivé adressé au demandeur. Une voie d’escalade existe pour les cas exceptionnels | Revue par la direction, pour les seuls cas exceptionnels |
Figure 1 : le modèle de demande à quatre niveaux pour la gouvernance de l’IA. Le niveau d’examen croît avec le risque ; dans un programme mature, la répartition est d’environ 60 à 70 % au niveau 1, 20 à 25 % au niveau 2, 5 à 15 % au niveau 3, avec une part faible mais non nulle au niveau 4.
Appliqué à une demande concrète, le modèle donne une réponse nette. Prenons une équipe RH qui demande un système de classement de candidats fondé sur l’IA, proposé par un fournisseur tiers. Le cas d’usage relève de l’annexe III[6] de l’EU AI Act (emploi), ce qui fixe le niveau 3 comme plancher. Le système prend des décisions aux conséquences importantes pour les personnes (emploi), ce qui confirme le niveau 3. Les données sont sensibles (les CV contiennent des données personnelles, parfois des catégories particulières de données), ce qui le confirme encore. Toutes les dimensions convergent : la demande est orientée vers le niveau 3, avec évaluation complète, revue multipartite, documentation technique conforme à l’annexe IV[7] et déclencheurs de réévaluation définis, liés aux mises à jour du modèle par le fournisseur.
Comparons avec un outil interne de correction grammaticale utilisé uniquement sur des textes marketing publiés. Aucune donnée personnelle, aucune décision aux conséquences importantes, aucun impact externe. Les dimensions convergent vers le niveau 1. La demande se résume à un formulaire d’enregistrement rempli en deux minutes ; le système figure dans l’inventaire avant midi ; aucun évaluateur humain n’intervient, sauf signalement d’une exception.
C’est l’existence du niveau 4 qui rend le reste de la structure crédible.
Sans voie de refus explicite, le processus de demande considère implicitement que toute demande finira par être gouvernable, et les dispositions des régimes applicables relatives aux usages interdits deviennent invisibles pour le programme. Une demande de niveau 4 doit figurer dans la piste d’audit avec un refus documenté : aux yeux d’un régulateur, cet enregistrement constitue en lui-même une preuve de maturité de la gouvernance.
Les cas limites à connaître. Certains systèmes se situent à cheval sur deux niveaux. Un système de niveau 2 dont le cas d’usage s’élargit sensiblement (par exemple, un chatbot de support client dont le périmètre s’étend aux décisions de remboursement) doit être réévalué et peut passer au niveau 3. À l’inverse, un système de niveau 3 exploité depuis deux ans sous une supervision humaine substantielle, et dont le profil de risque est resté manifestement stable, peut être candidat à un passage au niveau 2, avec maintien de la surveillance. Tout changement de niveau doit être une décision documentée, et non un automatisme. La question à se poser : un régulateur accepterait-il la nouvelle classification au vu des preuves disponibles ?
Les systèmes agentiques, point de bascule que ce modèle doit absorber
Le modèle à quatre niveaux n’a rien de nouveau. Ce qui est nouveau, c’est le rythme auquel arrivent les systèmes de niveau 3, porté principalement par l’IA agentique, c’est-à-dire la catégorie de systèmes autorisés à agir de manière autonome, et non plus seulement à produire des résultats revus par un humain. Le processus de demande des systèmes agentiques diffère structurellement sur trois points que le modèle à quatre niveaux doit intégrer.
Premièrement, la dimension d’autonomie impose par défaut le niveau 3, quel que soit le cas d’usage sous-jacent. Une IA agentique qui répond aux questions internes sur les notes de frais relève du niveau 2 au regard de la sensibilité du cas d’usage, mais dès qu’elle est autorisée à soumettre réellement des notes de frais ou à programmer des remboursements, elle bascule au niveau 3. Le profil de risque ne dépend pas du « type de décision », mais du « type d’action ».
Deuxièmement, le processus de demande des systèmes agentiques doit définir explicitement les limites de leur pouvoir d’action. Une demande agentique de niveau 3 doit établir quels outils l’agent peut appeler, quelles actions il peut effectuer sans confirmation humaine, quelles conditions d’escalade déclenchent un transfert à un humain, et quelle surveillance couvre son comportement entre deux confirmations. Rien de tout cela ne correspond à la structure de questionnaire qui fonctionnait pour les systèmes d’IA statiques ; les formulaires de demande agentiques comptent généralement 30 à 40 % de dimensions supplémentaires, centrées sur l’espace d’action plutôt que sur le traitement des données.
Troisièmement, la modification substantielle s’interprète différemment. Pour un système d’IA statique, les mises à jour du modèle sont le principal déclencheur de réévaluation. Pour un système agentique, l’élargissement de la liste des actions autorisées (permettre à l’agent d’appeler une nouvelle API, d’écrire dans un nouveau système de référence ou de déplacer des fonds dans une nouvelle catégorie) constitue une modification substantielle qui peut dépasser entièrement le périmètre de l’évaluation initiale, sans forcément être visible dans le modèle lui-même. Pour les systèmes agentiques de niveau 3, le processus de demande doit exiger l’enregistrement explicite de la liste des actions autorisées lors du déploiement, et être relancé à chaque modification de cette liste.
Pour les systèmes agentiques, la question n’est pas « quel type de décision », mais « quel type d’action ».
Classer les systèmes de façon cohérente : les sept dimensions
L’attribution d’un niveau doit produire la même réponse pour un même profil de risque, quel que soit l’évaluateur qui traite la demande. Un processus de classification mal conçu engendre des dérives ; un processus bien conçu applique à chaque demande un ensemble cohérent de dimensions et l’oriente de façon déterministe. Un formulaire de demande bien conçu pose cinq à huit questions couvrant les dimensions ci-dessous et s’appuie sur les réponses pour orienter la demande de façon déterministe. La dérogation manuelle est réservée aux véritables cas limites ; la classification manuelle par défaut engendre des dérives.
Dimension | Ce qu’elle évalue | Niveau minimal induit |
|---|---|---|
Catégorie de cas d’usage | Classification au titre de l’annexe III, définition de « consequential decision » du Colorado AI Act[8], régimes sectoriels à haut risque (services financiers, santé, secteur public) | Niveau 3 |
Sensibilité des données | Données personnelles, catégories particulières au sens du RGPD, données financières ou de santé sensibles | Relève le niveau en proportion |
Impact des décisions | Concerne l’emploi, le crédit, l’assurance, le logement, la santé, la justice, les services essentiels | Niveau 3 |
Réversibilité | Les actions de l’IA peuvent-elles être annulées sans préjudice ? | L’irréversibilité relève le niveau ; les systèmes agentiques aux actions irréversibles relèvent par défaut du niveau 3 |
Niveau d’autonomie | Revue humaine de chaque résultat, ou action autonome en plusieurs étapes ? | L’autonomie opérationnelle impose par défaut le niveau 3, quel que soit le cas d’usage sous-jacent |
Déclencheurs de transparence | Obligations de l’article 50 de l’EU AI Act : IA qui interagit avec des personnes, génère des contenus synthétiques ou produit des hypertrucages ; déclencheurs équivalents d’information des consommateurs au titre des règles ADMT de Californie | Relève le niveau dès lors que des obligations d’information s’appliquent, quel que soit le cas d’usage |
Déclencheurs sectoriels | IA appliquée à l’emploi au titre de la NYC LL144[11], règles ADMT de Californie[12], Colorado AI Act ; régimes sectoriels complémentaires (services financiers, santé, secteur public) | Les obligations sectorielles relèvent le niveau de tout système entrant dans leur champ |
Déclencheurs liés à la gestion du risque de modèle | UK PRA SS1/23[9], US Fed SR 11-7[10], équivalents sectoriels en matière de MRM pour les services financiers réglementés | Pour les services financiers réglementés, la MRM suit un cycle de vie parallèle au processus de demande IA ; le niveau minimal est le niveau 3, avec des correspondances MRM documentées |
Origine | Développé en interne, acheté, ou intégré à des SaaS existants | L’IA intégrée par un fournisseur exige une nouvelle demande, quelle que soit l’approbation d’achat initiale |
Pour les établissements de services financiers réglementés en particulier, la dimension de gestion du risque de modèle est plus qu’un simple critère de niveau minimal : elle déclenche un cycle de vie parallèle (validation des modèles, surveillance continue, recertification périodique) que le processus de demande doit confier à la fonction MRM existante plutôt que de le reproduire. Le dossier de demande d’un système d’IA relevant de la MRM doit renvoyer à l’identifiant MRM correspondant, sans dupliquer le processus MRM.
Quand les dimensions divergent. Les dimensions vont généralement dans le même sens ; parfois, ce n’est pas le cas. Un système de maintenance prédictive dans une usine peut ne traiter que très peu de données personnelles, ne prendre aucune décision aux conséquences importantes pour les personnes et être entièrement réversible, tout en faisant partie d’un produit relevant de l’annexe I (machines) dont l’intégration d’IA est à haut risque au sens de l’article 6(1) de l’EU AI Act[4]. La seule catégorie de cas d’usage impose alors le niveau 3, quoi que suggèrent les autres dimensions. La règle : retenir le niveau le plus élevé indiqué par l’une quelconque des dimensions, et documenter le raisonnement.
L’exception de l’article 6(3). L’EU AI Act permet à un fournisseur de déterminer lui-même qu’un système relevant de l’annexe III n’est pas à haut risque s’il exécute une tâche purement procédurale ou préparatoire, ou s’il améliore le résultat d’une activité humaine préalablement réalisée sans influencer la décision finale. L’exception est étroite[13]. Un outil d’IA qui remet en forme des CV selon une présentation standardisée à l’intention d’un évaluateur humain peut en bénéficier. Un outil d’IA qui classe ces mêmes CV selon l’adéquation prévue au poste n’en bénéficie pas, même si un humain prend la décision finale d’embauche : le classement influence la décision d’une manière que le régulateur juge significative. Le recours abusif à l’exception de l’article 6(3) constitue en soi une exposition réglementaire. Le processus de classification doit traiter les déterminations fondées sur l’article 6(3) comme des conclusions documentées et justifiées, et non comme un raccourci d’orientation.
La transparence au titre de l’article 50, et pourquoi elle mérite sa propre dimension. L’article 50 de l’EU AI Act[15] impose des obligations d’information aux systèmes d’IA qui interagissent avec des humains, génèrent des contenus synthétiques ou produisent des hypertrucages, quels que soient le cas d’usage sous-jacent ou le secteur. Un chatbot 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 conseiller humain sans information explicite. Le formulaire de demande doit tester directement les déclencheurs de l’article 50 ; aborder cette dimension tardivement, dans une évaluation de la conformité au titre de l’annexe III qui ne l’avait pas envisagée, crée des lacunes dans les preuves qui apparaissent lors de l’audit. À compter du 2 août 2026, il s’agit d’une obligation ferme pour les fournisseurs et les déployeurs des systèmes concernés, qui doit apparaître dans le dossier de décision de la demande.
L’achat par une banque d’un chatbot de support client auprès d’un tiers illustre l’interaction entre les dimensions. Le fournisseur présente le système comme « à risque limité », car les réponses sont conversationnelles et des conseillers humains traitent les escalades. Le processus de demande de la banque applique les dimensions : catégorie de cas d’usage (exposé aux clients, pas de plancher au titre de l’annexe III) ; sensibilité des données (les transcriptions peuvent contenir des informations de compte, ce qui relève le niveau) ; impact des décisions (purement informatif, pas de relèvement) ; réversibilité (les réponses peuvent être rétractées, pas de relèvement) ; niveau d’autonomie (répond sans revue humaine de chaque message, ce qui relève le niveau dans un sens proche de l’agentique) ; déclencheurs de transparence (l’article 50 s’applique, l’information sur la nature du chatbot est obligatoire) ; déclencheurs sectoriels (contexte des services financiers, nouveau relèvement) ; déclencheurs MRM (aucun modèle sous-jacent directement encadré par SR 11-7 ou SS1/23 pour un chatbot fourni par un tiers, à titre informatif) ; origine (achat auprès d’un tiers, nouvelle demande requise dans tous les cas). Le système se classe dans le haut du niveau 2, voire au niveau 3 selon l’évaluation de la sensibilité des données.
Le qualificatif « à risque limité » avancé par le fournisseur est sans importance : c’est la classification propre à l’organisation qui déploie le système qui fait foi.
Pour la discipline plus large de gestion des risques fournisseurs qui encadre ce type de demande, consultez notre guide d’évaluation des risques liés aux fournisseurs d’IA tiers.
Le flux de travail en cinq étapes, modulé selon le niveau
Le processus de demande suit une structure reconnaissable en cinq étapes, quel que soit le niveau. Le niveau détermine l’ampleur du processus à chaque étape.
Étape | Niveau 1 | Niveau 2 | Niveau 3 |
|---|---|---|---|
1. Identifier le cas d’usage | Soumission par le demandeur via un formulaire succinct : problème métier, résultat attendu, outil d’IA proposé | Soumission par le demandeur via un formulaire structuré : mêmes éléments, plus une première indication du risque | Soumission par le demandeur avec contexte complet : problème métier, résultat attendu, population d’utilisateurs visée, première appréciation du risque, identification du responsable |
2. Rechercher les cas d’usage existants | Rapprochement automatique avec les outils approuvés de l’inventaire | Rapprochement automatique avec l’inventaire | Revue manuelle des systèmes similaires et des possibilités de consolidation |
3. Évaluation des risques et de la faisabilité | Formulaire de cinq questions couvrant les sept dimensions de classification | Questionnaire structuré (15 à 25 dimensions) couvrant les données, la responsabilité du fournisseur, l’usage prévu | Évaluation complète produisant la documentation technique exigée par le régime réglementaire applicable : annexe IV[7] pour les systèmes à haut risque au titre de l’EU AI Act, déclaration d’applicabilité pour l’ISO 42001[2], etc. |
4. Revue | Automatique, sur la base de la liste d’autorisation | Un approbateur nommément désigné au sein du service juridique ou des risques | Comité de revue multipartite doté de droits de décision définis |
5. Décision | Le jour même, souvent en quelques minutes ; consignée dans l’inventaire | Sous une semaine ; consignée avec la fréquence de surveillance | Sous un mois pour les cas standard ; consignée avec des déclencheurs de réévaluation liés aux modifications substantielles |
Schéma du flux de travail de demande en cinq étapes pour la gouvernance de l’IA : étape 1, identifier le cas d’usage ; étape 2, vérifier l’inventaire ; étape 3, évaluation des risques ; étape 4, revue ; étape 5, décision. La structure reste la même à chaque niveau ; la profondeur de chaque étape s’adapte au niveau attribué.
La structure en cinq étapes vaut pour tous les niveaux ; ce qui varie avec le niveau, c’est l’ampleur du processus à chaque étape. Une demande de niveau 1 peut franchir les cinq étapes en vingt minutes ; une demande de niveau 3 exige généralement quatre à six semaines pour la seule évaluation, puis deux de plus pour le cycle de revue et d’approbation. Les rôles doivent être attribués par niveau : au niveau 1, le demandeur est le responsable désigné et le système entre automatiquement dans l’inventaire ; au niveau 2, l’approbateur désigné au sein du service juridique ou des risques porte la décision, et le demandeur reste responsable de l’exploitation courante ; au niveau 3, le comité de revue multipartite détient les droits de décision, un évaluateur indépendant désigné est chargé de la revue de la documentation technique, et le responsable métier reste responsable de l’usage effectif.
La modification substantielle est le déclencheur qui ramène à l’étape 3. L’article 3(23) de l’EU AI Act définit la modification substantielle comme une modification apportée à un système d’IA après sa mise sur le marché, qui affecte sa conformité ou sa destination[14]. On trouve des équivalents dans l’ISO 42001 (qui traite un changement substantiel comme un déclencheur de réévaluation au sein du système de management de l’IA) et dans le NIST AI RMF (qui traite un changement significatif comme un déclencheur de nouvelle cartographie des risques). Exemples concrets : un fournisseur déploie une nouvelle version d’un modèle de fondation qui modifie le comportement d’un outil ; la liste des actions autorisées d’un système agentique est élargie à une nouvelle API ; le périmètre d’un chatbot de support client s’étend aux décisions de remboursement ; les données d’entraînement d’un modèle affiné sont actualisées avec de nouvelles sources. Chacun de ces cas est une modification substantielle potentielle, et le processus de demande doit être relancé au niveau de profondeur approprié, non comme un exercice bureaucratique, mais parce que l’évaluation des risques précédente peut ne plus être valable.
Prenons un établissement de santé qui a déployé en 2025 une aide au diagnostic fondée sur l’IA après une revue de niveau 3, l’évaluation initiale reposant sur une version précise du modèle, entraînée sur un jeu de données précis. En avril 2026, le fournisseur annonce une mise à jour du modèle intégrant de nouvelles données d’entraînement et un pipeline d’inférence affiné. En vertu des règles relatives aux modifications substantielles, le processus de demande de l’établissement doit être relancé : l’évaluation réalisée un an plus tôt peut ne pas couvrir les nouveaux comportements du modèle mis à jour. La réévaluation peut conclure qu’aucun changement n’est nécessaire, mais cette conclusion doit être documentée, et non tacite.
Du manuel à l’automatisé : le point de bascule qui impose le choix d’une plateforme
De quatre heures par cas d’usage à moins d’une. Même équipe. Même exigence réglementaire. Six mois.
C’est la réalité opérationnelle d’une entreprise de biens de consommation qui a remplacé son processus de demande manuel, fondé sur des formulaires par e-mail et Google Forms, par un flux de travail automatisé et hiérarchisé par niveaux. La réduction du temps de traitement est l’indicateur visible ; le changement structurel est le plus important. Avant la transition, l’équipe risques était le goulet d’étranglement de chaque demande d’IA, quel que soit son profil de risque. Après la transition, les demandes à faible risque n’entraient plus en concurrence avec les demandes à haut risque, les comités de revue multipartites consacraient leur temps aux systèmes qui l’exigeaient réellement, et la piste d’audit était prête pour le régulateur par défaut, sans travail de reconstitution.
Un processus de demande par niveaux peut être géré manuellement. La plupart des programmes commencent ainsi : formulaires par e-mail, tableurs partagés, réunions de revue régulières. Le modèle tient pour la première ou les deux premières douzaines de demandes d’IA.
Au-delà d’un certain volume, le passage à l’automatisation devient une nécessité plutôt qu’une option. Les symptômes sont prévisibles. La classification manuelle varie d’un évaluateur à l’autre : un même système reçoit des niveaux différents selon la personne de permanence. Les pistes d’audit tenues dans des fils d’e-mails se fragmentent entre les membres de l’équipe, les canaux projet et les espaces partagés, sans source unique de vérité qu’un régulateur pourrait demander. Les déclencheurs de réévaluation passent inaperçus car personne ne les suit à grande échelle. Les demandes de niveau 1, qui devraient être automatisées, finissent dans la même file d’attente que celles de niveau 3, car la logique d’orientation n’existe que dans la tête de quelqu’un, et ce quelqu’un est en vacances.
Les capacités qui deviennent indispensables n’ont rien d’exotique : un inventaire centralisé que plusieurs équipes peuvent modifier en toute sécurité ; une classification déterministe des niveaux, fondée sur les réponses au formulaire de demande ; l’orientation des demandes vers les bons évaluateurs ; la génération de documents au regard des exigences réglementaires ; une piste d’audit qui résiste aux changements d’organisation.
Choisir entre un processus de demande manuel et automatisé, c’est choisir la charge de gouvernance que l’organisation absorbe à mesure qu’elle étend l’adoption de l’IA. Un processus par niveaux retarde le point de bascule, sans le supprimer. Les organisations qui passent tôt à l’automatisation considèrent l’investissement dans une plateforme comme une condition structurelle du passage à l’échelle de l’IA, en amont du point de bascule ; celles qui attendent que le passage à l’échelle ait déjà échoué se voient imposer le choix d’une plateforme dans des conditions de compromis.
La place du processus de demande dans l’ensemble de la pile GRC
Le processus de demande fonctionne lorsqu’il sert de porte d’entrée aux processus GRC que l’organisation applique déjà (risques fournisseurs, achats, revue de sécurité, évaluation de la protection des données), et non de circuit parallèle concurrent. Un nouveau processus de demande qui fonctionne à côté des fonctions de revue existantes produit des efforts redondants et des référentiels concurrents, deux batailles que le programme finira par perdre.
Le processus de demande doit produire un dossier unique auquel les achats, le juridique, la sécurité et la protection des données peuvent chacun se référer pour leurs obligations respectives :
La gestion des risques fournisseurs s’appuie sur le dossier de demande pour définir les clauses contractuelles relatives à l’usage de l’IA : délais de notification des changements, droits d’audit, obligations de communication des fiches de modèle
Les achats s’y réfèrent pour vérifier que la structure du contrat correspond à la classification des risques et à l’usage prévu du système. En pratique, le relais vers les achats est le plus difficile : les plateformes de TPRM existantes (OneTrust, ServiceNow Vendor Risk Management, ProcessUnity) gèrent l’héritage des modèles de contrat, et les bibliothèques de clauses propres à l’IA doivent être greffées sur ce flux de travail plutôt que maintenues en parallèle.
La sécurité s’y réfère pour les implications du système en matière de contrôle d’accès, les flux de données qu’il requiert et le modèle de menaces applicable
La protection des données s’y réfère pour l’AIPD ou l’évaluation de l’intérêt légitime (LIA) requise par le système, les incidences sur les droits des personnes concernées et les questions de transferts transfrontaliers de données
Le coût de deux systèmes de gouvernance parallèles est structurel, et non marginal.
Le dossier de demande alimente chacune de ces fonctions en amont. Concrètement, le processus de demande est conçu ou choisi avec des points d’intégration explicites vers la pile GRC existante. Le coût s’accroît à mesure que les référentiels des deux systèmes divergent avec le temps.
Le processus de demande d’une banque pour un fournisseur d’IA tiers illustre concrètement ce fonctionnement. La demande déclenche automatiquement des actions en aval : l’équipe risques fournisseurs reçoit le dossier de demande et applique son évaluation standard des tiers, complétée de volets propres à l’IA ; le juridique examine le contrat au regard du délai de notification des changements et des clauses de droit d’audit ; la sécurité reçoit la spécification des flux de données et applique son modèle de menaces ; la protection des données réalise l’AIPD à partir des classifications de données recueillies lors de la demande. Aucune de ces équipes ne redemande les mêmes informations ; chacune puise dans le dossier de demande. Le fournisseur reçoit un ensemble d’exigences cohérent plutôt que quatre processus parallèles posant des questions qui se recoupent.
Comment le processus de demande par niveaux échoue (et comment y remédier)
Le processus de demande par niveaux échoue selon sept schémas reconnaissables. Les cinq premiers apparaissent au cours des dix-huit premiers mois ; les deux derniers surviennent la deuxième et la troisième année, et mettent discrètement fin à des programmes qui avaient survécu aux premiers échecs. Chacun présente un signal de diagnostic visible lors des revues de gouvernance courantes, et appelle une correction structurelle qui traite la cause sous-jacente.
Mode d’échec | Signal de diagnostic | Correction structurelle |
|---|---|---|
Traiter le processus de demande comme ponctuel | Des systèmes de niveau 2 approuvés tournent avec de nouvelles capacités jamais réévaluées | Fréquence de réévaluation par niveau, avec des événements déclencheurs définis liés aux modifications substantielles, aux mises à jour des modèles des fournisseurs et aux changements de périmètre |
Attribuer les niveaux par équipe plutôt que par risque | Demandes d’IA du marketing orientées par défaut vers le niveau 1 ; celles de l’ingénierie, par défaut vers le niveau 3 | Le niveau comme propriété du système, attribué selon les dimensions de classification, quelle que soit l’équipe demandeuse |
Passer à côté de l’IA fantôme | L’inventaire progresse nettement moins vite que les dépenses informatiques en outils d’IA | Associer le processus de demande à des revues des déclarations des fournisseurs, à l’analyse du trafic API et à des fenêtres d’amnistie périodiques |
Ne pas s’intégrer à la GRC existante | Les achats, la sécurité et les risques mènent des revues IA distinctes sur les mêmes systèmes | Le processus de demande comme porte d’entrée, produisant un dossier unique auquel se réfèrent toutes les fonctions en aval |
Multiplier les niveaux | Cinq ou six niveaux, chacun avec une instance de revue différente | Quatre niveaux au maximum ; trois pour les organisations comptant moins de quelques centaines de systèmes d’IA |
Perte du soutien de la direction la deuxième année | La participation au comité de pilotage baisse ; la capacité de niveau 3 s’érode ; les décisions glissent du défendable vers l’expédient | Revue trimestrielle par la direction, adossée à un chiffre quantifié d’exposition au risque ; indicateur visible au niveau du conseil d’administration sur le débit des demandes et le taux de capture |
Des comités de revue de niveau 3 réduits à des chambres d’enregistrement | Les taux d’approbation approchent 100 %, les durées moyennes de revue s’effondrent, les comptes rendus des discussions raccourcissent d’un trimestre à l’autre | Faire tourner les évaluateurs indépendants, exiger un avis contraire documenté sur un échantillon défini, instaurer une note préparatoire structurée pour le comité |
Diagnostic détaillé de l’échec précoce le plus courant. Traiter le processus de demande comme ponctuel est le premier écueil dans lequel tombent la plupart des entreprises, et celui dont le coût cumulé est le plus élevé. Le signal : une revue trimestrielle de l’inventaire révèle trois ou quatre systèmes qui ont sensiblement changé depuis leur dernière évaluation (un fournisseur a déployé une mise à jour du modèle, un cas d’usage s’est élargi, une nouvelle source de données a été intégrée) sans que le processus de demande ait été relancé. Au douzième mois, les classifications des risques de l’inventaire relèvent de la fiction ; au dix-huitième mois, la piste d’audit ne reflète plus fidèlement ce que font les systèmes déployés. La correction est structurelle : chaque système au-delà du niveau 1 a une fréquence de réévaluation définie (généralement annuelle pour le niveau 2, semestrielle pour le niveau 3) et une liste d’événements déclencheurs qui imposent une réévaluation anticipée, quelle que soit cette fréquence. Les deux doivent être fixés dès la décision initiale, et non ajoutés après coup.
Pourquoi les deux échecs de la deuxième année comptent plus que les premiers. La perte du soutien de la direction et les comités de revue réduits à des chambres d’enregistrement sont les modes d’échec qui tuent les programmes matures. Tous deux sont invisibles lors des revues de fonctionnement habituelles ; tous deux n’apparaissent que lorsqu’un incident significatif oblige le programme à démontrer que sa posture de gouvernance était défendable au moment où un système a été approuvé. Les corrections structurelles (indicateurs d’exposition quantifiés au niveau du conseil, rotation des évaluateurs indépendants, avis contraires documentés) sont opérationnelles et non culturelles ; elles doivent être intégrées au programme avant d’être nécessaires, car les mettre en place après un échec est précisément ce que les régulateurs interprètent comme la preuve d’une gouvernance de façade.
Pour la discipline d’inventaire plus large qui sous-tend les signaux d’échec ci-dessus, consultez notre guide pour constituer un inventaire des systèmes d’IA.
À quoi ressemble un bon programme : repères de la première année
Les indicateurs ci-dessous décrivent le profil de fonctionnement d’un programme de demande par niveaux au cours des 12 à 18 premiers mois, ainsi que le profil de maturité que la plupart atteignent d’ici la troisième année. Les fourchettes cibles reflètent les trajectoires observées dans l’ensemble des programmes clients d’Enzai[16]. Chaque programme varie selon sa maturité initiale, son secteur et son niveau d’automatisation du processus de demande : ces repères décrivent le profil d’un programme opérationnel, et non un résultat garanti. Lorsqu’un programme reste nettement en deçà des chiffres de la première année au douzième mois, il lui manque généralement l’une des corrections structurelles ci-dessus.
Indicateur | Mois 1 à 6 | Mois 12 à 18 | Maturité en année 3 |
|---|---|---|---|
Taux de capture (% des initiatives d’IA en production passées par le processus de demande) | 70 à 85 %, le temps que le processus de demande rattrape le parc existant | ≥ 95 % en régime établi | ≥ 99 % ; l’IA fantôme est véritablement résiduelle et non plus systémique |
Délai de décision (niveau 1) | Le jour même, souvent en quelques minutes | Approbation en temps réel pour les systèmes clairement couverts par la liste d’autorisation | Temps réel sur l’ensemble de la liste d’autorisation ; quelques minutes pour les cas limites |
Délai de décision (niveau 2) | Sous une à deux semaines | Sous une semaine | Sous trois jours ; questionnaire structuré en grande partie prérempli à partir de systèmes similaires antérieurs |
Délai de décision (niveau 3) | Sous un à deux mois pour les cas standard | Sous un mois pour les cas standard | Sous trois semaines ; documentation générée par le flux d’évaluation plutôt que rédigée de zéro |
Répartition entre les niveaux (programme mature type) | En cours de stabilisation ; prévoir une surclassification au niveau 3 au cours des 6 premiers mois | 60 à 70 % au niveau 1, 20 à 25 % au niveau 2, 5 à 15 % au niveau 3, une part faible mais non nulle au niveau 4 | Stable, les mouvements entre niveaux étant suivis comme un indicateur de maturité en soi |
Exhaustivité de la piste d’audit | Par système : demandeur, niveau attribué, preuves à l’appui, approbateur désigné, date de la prochaine réévaluation | En plus : historique des réévaluations et journal des modifications substantielles | En plus : liens avec la GRC en aval, dossier de preuves prêt pour le régulateur, constituable en moins d’une heure |
Un programme sans aucune demande de niveau 4 ne détecte probablement pas les cas qu’il devrait détecter ; un programme où chaque demande aboutit au niveau 3 a cessé de classer et pratique une surclassification défensive au détriment de la vélocité opérationnelle. Dans les deux cas, la logique de classification doit être revue.
Le principe de proportionnalité, en pratique
Le processus de demande par niveaux est l’expression opérationnelle du principe de proportionnalité que tous les grands régimes réglementaires de l’IA intègrent désormais : le modèle à quatre niveaux lui donne sa structure, les huit dimensions de classification fournissent la logique d’orientation, le flux de travail en cinq étapes en constitue la trame, modulée selon le niveau, et les repères servent d’outil de diagnostic.
Le processus de demande par niveaux apporte la visibilité qu’une gouvernance sur le papier ne peut offrir. Avec un processus par niveaux opérationnel, l’empreinte IA peut croître sans que le programme perde de vue ce qui compte le plus : les cas à détecter le sont dès la demande, les cas qui doivent avancer vite le font sans friction inutile, et la piste d’audit produite au passage est de celles qu’un régulateur peut examiner sans préparation.
Le travers à éviter est celui que les régulateurs constatent le plus souvent : substituer la documentation à la discipline. Un programme doté d’évaluations détaillées et d’un niveau 4 vide n’est pas un programme de gouvernance ; c’est un programme de paperasse. Le principe de proportionnalité ne fonctionne que si le refus proportionné fait partie de la discipline opérationnelle, au même titre que la revue proportionnée.
Pour la question plus large des contrôles agentiques, qui jouxte le processus de demande par niveaux aux niveaux les plus élevés, consultez le guide de référence de la gouvernance de l’IA agentique.
Questions fréquentes
Qu’est-ce que le processus de demande par niveaux en gouvernance de l’IA ?
Le processus de demande par niveaux est la discipline opérationnelle qui consiste à soumettre chaque demande d’IA à une revue d’une profondeur proportionnée à son risque. La plupart des programmes d’entreprise retiennent quatre niveaux (Libre-service, Revue allégée, Revue complète et Restreint), chacun ayant son propre processus de classification, son approbateur, son degré de documentation et sa fréquence de réévaluation. Ce modèle remplace le circuit de revue unique, qui cède dès que le volume de gouvernance rencontre la vitesse d’adoption de l’IA.
Combien de niveaux un programme de gouvernance de l’IA d’entreprise doit-il compter ?
Quatre est le maximum pratique pour la plupart des entreprises. Les programmes qui gouvernent moins de quelques centaines de systèmes d’IA peuvent souvent fonctionner avec trois (en fusionnant Revue allégée et Revue complète, avec des questionnaires plus approfondis dans cette dernière). Cinq ou six niveaux sont le signe d’une sur-ingénierie : chaque niveau supplémentaire crée une ambiguïté d’orientation à la frontière entre niveaux adjacents et ajoute un coût de coordination entre instances de revue, sans bénéfice proportionné en matière de couverture des risques.
Quels systèmes d’IA doivent relever automatiquement du niveau 3 ?
Tout système relevant de l’annexe III de l’EU AI Act, tout système prenant des décisions aux conséquences importantes pour les personnes (emploi, crédit, assurance, logement, santé, justice, services essentiels), tout déclencheur d’un régime sectoriel à haut risque, et tout système agentique capable d’agir de manière autonome, quel que soit le cas d’usage sous-jacent. La règle : retenir le niveau le plus élevé indiqué par l’une quelconque des dimensions de classification, et documenter le raisonnement.
Comment le processus de demande par niveaux traite-t-il l’IA agentique ?
Les systèmes agentiques relèvent par défaut du niveau 3, car l’autonomie opérationnelle élève le profil de risque quel que soit le cas d’usage. Le processus de demande des systèmes agentiques doit consigner explicitement la liste des actions autorisées, les conditions d’escalade qui déclenchent un transfert à un humain, et la surveillance qui couvre le comportement entre deux transferts. L’élargissement de la liste des actions autorisées est en soi un déclencheur de modification substantielle qui relance le processus de demande.
Qu’est-ce qui déclenche la réévaluation d’un système d’IA approuvé ?
La modification substantielle, définie à l’article 3(23) de l’EU AI Act comme une modification apportée à un système d’IA après sa mise sur le marché, qui affecte sa conformité ou sa destination. Parmi les déclencheurs concrets figurent les mises à jour de modèles par les fournisseurs, l’élargissement de la liste des actions autorisées d’un agent, les changements de périmètre du cas d’usage, l’actualisation des données d’entraînement des modèles affinés et les hausses significatives de la population d’utilisateurs ou de l’étendue géographique du déploiement. Les systèmes de niveau 2 sont généralement réévalués chaque année, ainsi qu’en cas de déclencheur ; les systèmes de niveau 3, généralement tous les six mois, ainsi qu’en cas de déclencheur.
Combien de temps faut-il pour bâtir un processus de demande par niveaux à partir de zéro ?
Trois à six mois pour fonctionner en mode manuel sur la première cohorte de demandes ; neuf à quinze mois pour atteindre les objectifs de référence de la première année ; dix-huit à vingt-quatre mois pour atteindre le profil de maturité de la troisième année. Au-delà d’un certain volume, le passage du manuel à l’automatisé devient une nécessité plutôt qu’une option : généralement entre 50 et 200 systèmes d’IA sous gouvernance, selon le rythme d’arrivée des nouvelles demandes.
Le processus de demande par niveaux remplace-t-il les processus GRC existants, comme la gestion des risques fournisseurs et les achats ?
Non. Il se situe en amont de ces processus. Le dossier de demande est la source unique de vérité à laquelle la gestion des risques fournisseurs, les achats, la sécurité et la protection des données se réfèrent chacune pour leurs obligations respectives ; aucune de ces équipes ne repose les mêmes questions. L’erreur la plus courante consiste à faire fonctionner le processus de demande comme un circuit parallèle à la GRC existante ; le bon modèle fait du processus de demande la porte d’entrée qui produit un dossier unique, exploité en aval.
Quelle est la place d’Enzai par rapport à des plateformes comme ServiceNow ou OneTrust ?
Enzai fait office de couche de gouvernance propre à l’IA, située en amont des piles GRC d’entreprise comme ServiceNow, OneTrust et ProcessUnity, et intégrée à celles-ci. Le dossier de demande produit dans Enzai alimente les flux de travail que ces plateformes exécutent déjà ; la profondeur d’évaluation propre à l’IA et la couverture des cadres réglementaires relèvent d’Enzai. La plupart des clients utilisent Enzai aux côtés de leur infrastructure GRC existante, sans la remplacer.
La place d’Enzai
Ce guide décrit la discipline opérationnelle. Enzai fournit la plateforme qui la met en œuvre : le modèle à quatre niveaux, la classification fondée sur les dimensions, le flux de travail en cinq étapes et la piste d’audit intégrée, le tout fonctionnant comme une infrastructure plutôt que comme un processus. Si vous êtes au point de bascule et souhaitez situer votre programme par rapport aux repères de ce guide, prenez contact avec nous : nous ferons passer l’un de vos cas d’usage réels par le modèle.
Lire le guide complet : The Essential Guide to AI Governance - From Policy to Practice couvre le processus de demande par niveaux, ainsi que l’élaboration des politiques, les cadres de conformité, la gestion de l’inventaire, la conception des évaluations et la surveillance continue. Téléchargez le guide.
Enzai est la plateforme de référence en matière de gouvernance de l’IA d’entreprise, conçue spécifiquement pour aider les organisations à passer de politiques abstraites à une supervision opérationnelle. Notre plateforme de gestion des risques liés à l’IA fournit l’infrastructure spécialisée nécessaire pour assurer la gouvernance de l’IA agentique, tenir un inventaire IA complet et garantir la conformité à l’EU AI Act. En automatisant les flux de travail complexes, Enzai permet aux entreprises de déployer l’IA à grande échelle en toute confiance, tout en restant alignées sur des normes internationales telles que ISO 42001 et NIST.
Références
Règlement (UE) 2024/1689 du Parlement européen et du Conseil établissant des règles harmonisées concernant l’intelligence artificielle (règlement sur l’intelligence artificielle). Journal officiel de l’Union européenne, juillet 2024. eur-lex.europa.eu/eli/reg/2024/1689/oj
ISO/IEC 42001:2023, Technologies de l’information - Intelligence artificielle - Système de management. Organisation internationale de normalisation, décembre 2023. iso.org/standard/81230.html
NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1. National Institute of Standards and Technology, janvier 2023. nist.gov/itl/ai-risk-management-framework
Règlement (UE) 2024/1689, article 6 : règles relatives à la classification de systèmes d’IA comme systèmes à haut risque.
Règlement (UE) 2024/1689, article 5 : pratiques interdites en matière d’IA.
Règlement (UE) 2024/1689, annexe III : systèmes d’IA à haut risque visés à l’article 6, paragraphe 2.
Règlement (UE) 2024/1689, annexe IV : documentation technique visée à l’article 11, paragraphe 1.
Colorado SB 24-205, Concerning Consumer Protections for Artificial Intelligence, promulguée en mai 2024. leg.colorado.gov/bills/sb24-205
Prudential Regulation Authority de la Bank of England, Supervisory Statement SS1/23, « Model risk management principles for banks », mai 2023. bankofengland.co.uk
Board of Governors of the Federal Reserve System, SR Letter 11-7, « Supervisory Guidance on Model Risk Management », avril 2011. federalreserve.gov
New York City Local Law 144 de 2021, Automated Employment Decision Tools. nyc.gov/site/dca/about/automated-employment-decision-tools.page
California Privacy Protection Agency, projet de réglementation sur les technologies de prise de décision automatisée (ADMT). cppa.ca.gov/regulations/
Règlement (UE) 2024/1689, article 6, paragraphe 3 : exception applicable aux systèmes de l’annexe III ne présentant pas de risque important.
Règlement (UE) 2024/1689, article 3, point 23 : définition de la modification substantielle.
Règlement (UE) 2024/1689, article 50 : obligations de transparence pour les fournisseurs et les déployeurs de certains systèmes d’IA.
Les objectifs de taux de capture, de répartition entre les niveaux et de délai de décision pour la première année présentés dans cette section reflètent les observations consolidées d’Enzai sur des programmes de gouvernance de l’IA d’entreprise ayant au moins 12 mois de fonctionnement d’un processus de demande par niveaux. Les trajectoires varient selon la maturité initiale, le secteur et le niveau d’automatisation du processus de demande ; les chiffres cités décrivent le profil d’un programme opérationnel, et non un résultat garanti.
Certifié ISO 27001 depuis 2023, audité chaque année par NQA
Traitement des données aligné sur le RGPD
Données clients hébergées sur AWS dans plusieurs régions
Utilisez votre propre modèle d’IA via une connexion privée
Identifiez l’IA utilisée par vos équipes, examinez-la avant sa mise en service, évaluez-la au regard des règles applicables et contrôlez ce que les agents peuvent faire. Conçu pour les organisations réglementées.