Cartographie des usages
Outils, équipes, données, décisions, sorties et dépendances.
DOSSIER 1101
Gouvernance IA opérationnelle
Donner aux équipes la liberté d’utiliser l’IA sans rendre invisibles les données, les décisions et les responsabilités.
Brief opérationnelPOLICYrègles lisibles
RISKusages classés
HUMANresponsabilité claire
Brief opérationnel
Gouverner l’usage, pas seulement l’outil.
Les risques apparaissent dans les pratiques réelles : copier des données, déléguer une décision, publier sans contrôle ou dépendre d’un fournisseur. La gouvernance doit être compréhensible, testable et applicable au quotidien.
AR / DOSSIER 1101ANALYSE INDÉPENDANTE
ATELIER DE MESURE
Un agent à 80 % de réussite peut ne réussir que 64 % du programme
Le dénominateur change la lecture. Sur 50 essais prévus, 40 sont terminés et 32 réussissent : la réussite parmi les essais terminés atteint 80 %, mais la réussite sur le programme entier reste à 64 %. Les 10 essais non terminés doivent rester visibles.
Illustration générée par IA
Exemple fictif · aucune mesure du site ou d’un client
| Indicateur | Calcul ou repère | Ce que le résultat permet de dire |
|---|---|---|
| Achèvement du programme | 40 / 50 × 100 = 80 % | 40 / 50 = 80 % : dix essais sont encore sans résultat terminé. |
| Réussite sur tous les essais prévus | 32 / 50 × 100 = 64 % | 32 / 50 = 64 % : un essai non terminé n’est pas une réussite. |
| Réussite parmi les essais terminés | 32 / 40 × 100 = 80 % | 32 / 40 = 80 % : ce taux conditionnel exclut les dix essais non terminés. |
Du relevé à la décision
Définir la réussite avant l’essai
Écrivez le résultat attendu, les accès autorisés, le temps maximal et les erreurs critiques.
Garder tous les essais
Séparez réussite, échec terminé et non-achèvement. Un échec critique est un sous-ensemble des échecs terminés.
Relire les cas critiques
Examinez chaque incident et la reprise possible. Une moyenne favorable ne suffit pas à autoriser un déploiement.
SYSTÈME SOUS CONTRÔLE
L’automatisation reste une responsabilité.
Sources, permissions, évaluations, validations, journaux et conditions d’arrêt sont conçus avec le système. La performance ne vaut que si les données, les décisions et la réversibilité restent gouvernables.
Scène illustrative.
02 / Axes d’intervention
Axes d’intervention
Classification des risques
Impact, sensibilité, autonomie, destinataires et possibilité de correction.
Politique d’usage
Actions autorisées, supervisées, interdites et obligations de traçabilité.
Évaluation
Qualité, robustesse, biais, sécurité, coût et comportement hors périmètre.
Contrôle humain
Moments de validation, compétences nécessaires et droit d’interrompre.
Gestion d’incident
Détection, arrêt, conservation des traces, notification et correction.
03 / NOTES DE TERRAIN
Quand formaliser la gouvernance
Dès que l’usage dépasse l’expérimentation individuelle et touche des données, des clients ou des décisions.
01DIFFUSION
Outils déjà partout
Les équipes utilisent plusieurs assistants sans cadre commun ni inventaire.
02AUTOMATISATION
Actions externes
Un système peut publier, envoyer, modifier une donnée ou déclencher un processus.
03DONNÉES
Informations sensibles
Les invites ou documents contiennent des éléments personnels, stratégiques ou contractuels.
04FOURNISSEUR
Dépendance croissante
Une fonction importante repose sur un modèle, une API ou des conditions susceptibles de changer.
04 / LIVRABLES
Cadre de gouvernance
Des règles courtes, un registre maintenu et des évaluations concrètes valent mieux qu’une charte impossible à appliquer.
Registre des usages
Finalité, outil, propriétaire, données, risque et statut.
Politique IA
Principes, cas autorisés, interdictions et obligations de validation.
Matrice de risque
Critères communs et niveaux de contrôle proportionnés.
Fiche fournisseur
Données, rétention, juridiction, sécurité, coûts et réversibilité.
Protocole d’évaluation
Jeux de tests, seuils, échecs critiques et fréquence.
Plan d’incident
Arrêt, escalade, preuve, correction et retour d’expérience.
DOCUMENTS DE TRAVAIL
Ce que le dossier doit rendre vérifiable
Trois supports concrets pour passer du diagnostic à une décision traçable.
Registre des usages
Contenu minimal : Pour chaque usage : finalité, responsable, données, fournisseur, personnes concernées et décision automatisée éventuelle.
À vérifier : Un usage nouveau a-t-il été introduit sans propriétaire ?
Carte des contrôles
Contenu minimal : Reliez risque identifié, garde-fou, preuve de fonctionnement, fréquence de contrôle et responsable de correction.
À vérifier : Le contrôle existe-t-il en production ou seulement dans une politique ?
Dossier d’incident
Contenu minimal : Tracez déclencheur, effets, décision d’arrêt, personnes informées, reprise et leçon incorporée.
À vérifier : Peut-on démontrer ce qui s’est passé et empêcher une répétition proche ?
05 / Méthode
Une gouvernance applicable
Le cadre est conçu avec les utilisateurs, testé sur des cas réels et révisé lorsque les outils ou les risques évoluent.
- 01Inventorier les usages
- 02Nommer les propriétaires
- 03Classer les données
- 04Évaluer les risques
- 05Définir les validations
- 06Tester les systèmes
- 07Former les utilisateurs
- 08Réviser périodiquement
REPÈRES DE DÉCISION
Arbitrages à documenter
Deux vérifications qui changent la prochaine décision.
Les usages réels échappent à l’inventaire
Interrogez les équipes sur les données transmises, les décisions aidées et les outils connectés. Classez les cas par effet possible avant de choisir leurs contrôles.
Une exception est demandée
Documentez le motif, le périmètre, le responsable et la date d’expiration. Réexaminez-la après incident ou changement de modèle ; une dérogation permanente contourne la politique.
Deux approches à distinguer
Deux approches à distinguer
Le bon dispositif dépend de la question et de la décision attendue.
Politique d’usage
Énonce les données, tâches, outils et responsabilités autorisés. Elle donne un cadre commun mais ne montre pas seule que les usages réels respectent ces règles.
Contrôle en situation
Échantillonne des tâches réelles, journaux, exceptions et incidents. Vérifie permissions, qualité des sorties et reprise humaine; ses résultats conduisent à modifier le cadre ou l’outil.
Plan de travail proposé
Trame à adapter au périmètre convenu. Ce plan décrit une méthode proposée, sans attester une mission réalisée, un résultat mesuré ni un délai garanti. Les champs de suivi du JSON sont vides.
Illustration générée par IA
À préparer avant de commencer
Les usages envisagés, acteurs responsables, données utilisées et fournisseurs connus. Identifier les décisions sensibles et les mécanismes de recours.
Cadrer le travail
Inventorier chaque usage avec finalité, propriétaire et populations concernées. Faire apparaître les dépendances et les informations encore inconnues.
Dérouler la méthode
Associer risques, contrôles et responsable de validation. Préparer les règles d’escalade et d’arrêt avant de lancer le dispositif.
Vérifier et transmettre
Revoir incidents, modifications et résultats des contrôles à une échéance définie. Conserver la décision prise et la justification des exceptions.
Conditions de pause ou de révision
Un usage sans propriétaire ou contrôle vérifiable reste non validé. Le registre de gouvernance ne constitue pas une certification de conformité.
06 / FAQ
Questions fréquentes
Réponses claires sur le périmètre, les limites, les méthodes et les conditions d’intervention.
Faut-il interdire les outils publics ?
Pas systématiquement. Les usages et données doivent être classés, avec des alternatives adaptées.
Qui doit porter la gouvernance ?
Une responsabilité partagée, avec un décideur identifié et des propriétaires métier, technique et sécurité.
Une charte suffit-elle ?
Non. Il faut un inventaire, des contrôles, des évaluations et un mécanisme d’incident.
Comment gérer les modèles qui changent ?
Par des tests réguliers, une surveillance des versions et des seuils de réévaluation.
Le contrôle humain garantit-il la qualité ?
Seulement si la personne dispose du temps, des compétences et de l’information nécessaires.
Peut-on utiliser des données personnelles ?
Selon la finalité, la base juridique, les contrats, la sécurité et les règles applicables ; une analyse spécialisée peut être requise.
Comment éviter de bloquer l’innovation ?
En concentrant les contrôles sur les usages risqués et en offrant des chemins sûrs pour expérimenter.
Références méthodologiques
Documents officiels pour approfondir les méthodes, les critères de contrôle et leurs limites. Ces références ne constituent ni une certification de la prestation ni une garantie de classement.
08 / CONTACT
Ouvrir un canal privé
Présentez le contexte et l’objectif. Une première lecture claire vous sera retournée.
APPROFONDISSEMENT / PRATIQUE
Attribuer les responsabilités autour d’un usage IA
Un usage IA doit être décrit par sa tâche, son périmètre et les moyens de contrôler ses sorties. La qualité de la réponse et la maîtrise des actions doivent être examinées ensemble.
Complément éditorial ajouté le .
Situation de départ
Un outil est adopté par plusieurs équipes sans règle commune. La gouvernance commence par l’inventaire des usages, des informations traitées et des décisions qui peuvent être affectées.
Vérifications prioritaires
Définir propriétaire de l’usage, utilisateur, responsable de validation et personne chargée des incidents. Documenter les catégories de données et les conditions de maintien ou d’arrêt.
Pièges d’interprétation
Une politique générale peut rester abstraite si elle ne précise pas qui contrôle les sorties. Une validation humaine sans information suffisante peut devenir une simple formalité.
Document de travail à conserver
Le registre d’usages relie finalité, données, outil, responsabilité et contrôle. Les incidents et changements de périmètre déclenchent une réévaluation du dispositif.
Prévoir une décision de retrait avant le déploiement
Définir les usages autorisés, le responsable de contrôle et les situations qui imposent une suspension. Exemple : un assistant documentaire peut proposer une synthèse, mais une référence inexistante déclenche une vérification avant diffusion. L’acceptation repose sur des tâches représentatives et des conséquences explicites.
Le cadre AI RMF du NIST relie gouvernance, contexte, mesure et gestion des risques. En pratique, documenter aussi les changements de modèle, les incidents et les possibilités de retour à une procédure maîtrisée. Un bon résultat ponctuel ne suffit pas à autoriser tous les usages.
CAS PRATIQUE / EXEMPLE PÉDAGOGIQUE
La sortie IA est validée sans lecture des sources
Ce cas pédagogique examine un usage IA à travers ses entrées, ses permissions et ses contrôles. Il ne décrit pas une performance garantie ; il aide à construire une évaluation adaptée aux conséquences possibles de la tâche.
Contexte de l’exemple
Une équipe impose une validation humaine, mais le responsable ne dispose ni des documents utilisés ni des limites du système. L’accord devient une formalité plutôt qu’un contrôle.
Démarche proposée
Définir la décision soumise à validation et les informations nécessaires. Donner accès aux sources et au contexte utile. Prévoir un statut pour les cas qui ne peuvent pas être vérifiés.
Conclusion et prochaine étape
Le rôle humain devient une opération décrite et réalisable. Les usages dont la sortie ne peut pas être contrôlée sont réexaminés selon leur portée et leurs conséquences.
Liste de contrôle pour appliquer cet exemple
- Relier les permissions aux actions nécessaires à la tâche autorisée.
- Tester informations manquantes, contradictions et demandes hors périmètre.
- Définir les reprises humaines et les résultats jugés acceptables.
- Conserver les erreurs, les versions et les contrôles après modification.
Questions pour approfondir la pratique
Que doit contenir une validation humaine utile ?
Une question claire, les éléments à vérifier et un résultat attendu. Le validateur doit pouvoir comprendre la sortie, repérer les limites et refuser ou demander un complément lorsque les preuves manquent.
Comment décider si un dispositif IA est prêt pour un usage plus large ?
Examiner les cas représentatifs, les erreurs importantes et les conditions de reprise. Le résultat doit montrer ce qui a été testé, avec quels critères et quelles limites. Un élargissement de tâche, de données ou de permissions nécessite une nouvelle lecture du risque et des contrôles, même lorsque le comportement initial était satisfaisant.
Pourquoi versionner les cas d’évaluation et les règles de contrôle ?
Les entrées, les outils et les consignes peuvent évoluer. Conserver les versions permet d’expliquer pourquoi un comportement a changé et de comparer des exécutions compatibles. Les cas ajoutés à la suite d’une erreur documentent aussi les situations désormais surveillées, sans faire disparaître les limites du jeu d’évaluation précédent.
ATELIER DÉTAILLÉ / MISE EN APPLICATION
Rendre les responsabilités de validation opérationnelles
Cet atelier propose une séquence en cinq étapes pour appliquer les repères de la page. Les entrées, les observations et la conclusion sont conservées ensemble afin de faciliter la vérification et la reprise du travail.
01 / Préparer les informations utiles
Identifier usages, sorties, personnes responsables et décisions affectées. Relever les documents nécessaires à une validation et les situations où ils ne sont pas disponibles.
02 / Exécuter la démarche
Décrire ce que chaque responsable examine et peut décider. Tester un cas ambigu, une erreur et une demande de complément. Vérifier que le validateur dispose du contexte et des éléments de preuve.
03 / Examiner une situation alternative
Si la validation consiste seulement à confirmer une sortie incompréhensible, revoir le contrôle. Une responsabilité utile doit correspondre à une opération réalisable avec des informations suffisantes.
04 / Décider de la suite
La gouvernance est exploitable lorsque les usages, permissions et incidents ont des responsables identifiables. Les changements de périmètre disposent d’une étape explicite de réévaluation.
05 / Transmettre les éléments de contrôle
Transmettre un registre finalité, données, décision et contrôle. Les équipes peuvent comprendre leurs obligations pratiques sans reconstruire le dispositif à partir d’une politique générale.
LIVRABLE COMMENTÉ / GRILLE DE LECTURE
Un registre d’usages avec contrôles réellement exécutables
Le registre associe usage, données, décision, responsable et validation. Il décrit les éléments dont le validateur dispose et les conditions de maintien, de révision ou d’arrêt.
Sur petit écran, faites défiler la grille pour lire les trois colonnes.
| Élément observé | Interprétation permise | Suite à prévoir |
|---|---|---|
| Le responsable peut vérifier la sortie et ses sources. | La validation correspond à une opération réalisable et documentée. | Tester cas ambigus et incidents puis conserver les décisions. |
| La validation est demandée sans éléments suffisants. | La responsabilité humaine risque de devenir formelle. | Définir les informations nécessaires et une reprise en cas d’incertitude. |
| Le périmètre de données change sans revue. | Les contrôles antérieurs ne couvrent pas nécessairement le nouvel usage. | Réexaminer permissions, responsabilités et cas d’évaluation concernés. |
Relecture du livrable
Le relecteur doit savoir qui décide et avec quelles informations. Une politique générale peut orienter le dispositif, mais ne remplace pas les opérations de contrôle décrites pour chaque usage.
RESTITUTION / EXEMPLE DE FORMULATION
Restitution : Attribuer les responsabilités autour d’un usage IA
Point à clarifier
Une validation humaine doit préciser les éléments qu’elle permet réellement d’examiner.
Avant de transmettre
Vérifier que responsabilité, accès aux preuves et pouvoir de décision sont cohérents.
Exemple de conclusion qualifiée
Le responsable dispose des informations nécessaires au contrôle décrit. Les cas qui ne peuvent pas être vérifiés sont signalés et suivent la reprise prévue.