Rédiger une charte de gouvernance de l'IA qui résiste à un audit

En 2024, le groupe de travail de la ville de New York sur les systèmes de décision automatisés, puis le bureau du Comptroller de la ville, ont constaté que plusieurs agences municipales utilisaient des outils algorithmiques (de la détection de fraude au tri des candidatures) sans inventaire cohérent, sans revue de risque documentée et sans propriétaire identifié en cas de problème. Un inspecteur général examinant le déploiement d'un chatbot dans une agence n'a trouvé personne capable de produire une trace de qui l'avait approuvé, de quelles données l'avaient entraîné, ni de la façon dont les réclamations étaient traitées. C'est cet écart, et non la technologie elle-même, que les auditeurs relèvent en premier.

Cette leçon construit le document interne qui comble cet écart : une charte de gouvernance de l'IA. Pas une affiche de principes. Un fichier de travail qu'un auditeur, un inspecteur général (IG, le bureau indépendant qui enquête sur les gaspillages, les fraudes et la mauvaise gestion au sein d'un organisme public) ou une commission de contrôle du conseil municipal peut prendre et suivre ligne par ligne.

Pourquoi une « charte » et pas seulement une « politique »

Une politique énonce des principes (« nous utiliserons l'IA de façon responsable »). Une charte attribue la responsabilité : qui décide, qui vérifie, qui valide, et ce qui se passe quand un système échoue à un contrôle. Les auditeurs n'auditent pas les intentions. Ils auditent les pistes documentaires et les droits de décision.

Le Government Accountability Office (GAO) américain et les inspecteurs généraux des agences citent systématiquement le même schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → de défaillance dans leurs revues de supervision de l'IA : des outils acquis sans évaluation formelle des risques, aucun responsable nommément désigné, aucun registre d'incidents (GAO AI Accountability Framework, 2021, toujours la référence pour les revues du secteur public). Votre charte existe précisément pour éviter cette conclusion.

Clause centrale 1 : inventaire des systèmes et classement par niveau de risque

Tout système d'IA utilisé par l'agence ou pour son compte (y compris les outils fournisseurs intégrés dans les logiciels d'achat) doit être enregistré avant déploiement. Champs minimaux :

• Nom du système, fournisseur, finalité
• Données en entrée (touche-t-il des données personnelles, l'éligibilité à des prestations, des casiers judiciaires ?)
• Impact décisionnel : purement informatif, ou affecte-t-il l'accès d'une personne à un service, à une prestation, ou une action de contrôle ?
• Niveau de risque : faible (aide à la rédaction interne), moyen (aide à la décision avec revue humaine), élevé (affecte matériellement l'éligibilité, les prestations, le maintien de l'ordre ou le recrutement)

Cela reprend la logique de classement de l'AI Act européen (règlement (UE) 2024/1689, entré en vigueur en août 2024), qui interdit purement et simplement certains usages et classe comme « à haut risque » les systèmes utilisés dans le maintien de l'ordre, la migration, l'emploi et les services publics essentiels, déclenchant des évaluations de conformité obligatoires avant déploiement. Les agences américaines recourent de plus en plus à un classement similaire, à titre volontaire, en se référant au mémo OMB M-24-10 (2024) de l'Office of Management and Budget de la Maison-Blanche, qui impose aux agences fédérales de désigner un Chief AI Officer et de réaliser des évaluations de risque pour les cas d'usage de l'IA « safety-impacting » et « rights-impacting ».

Formulation de la clause :

« Aucun système d'IA ne peut passer du pilote à la production sans une entrée dans l'inventaire des systèmes d'IA et un niveau de risque attribué, revu au minimum une fois par an ou lors de toute mise à jour matérielle du modèle. »

Clause centrale 2 : des rôles nommés, pas des directions

Le constat d'audit le plus fréquent est le vide de responsabilité. Corrigez-le avec des rôles nommés, pas « la DSI » :

• Responsable redevable de l'IA : valide avant déploiement ; personnellement comptable lors d'un audit. Dans les agences fédérales, il s'agit souvent du rôle de Chief AI Officer exigé par l'OMB M-24-10.
• Réviseur du risque modèle : indépendant de l'équipe qui a construit ou acheté le système ; vérifie les biais, la qualité des données et le drift (dégradation de la précision d'un modèle à mesure que les conditions réelles s'écartent de ses données d'entraînement).
• Data StewardData StewardUn responsable côté métier, garant de la qualité, de la cohérence et du bon usage des données de son domaine.Voir la définition complète → : confirme quelles données ont entraîné ou alimentent le système, et si elles incluent des catégories protégées exigeant une vigilance renforcée au titre de lois comme le Fair Housing Act ou le Title VII, si le système touche des décisions de logement ou d'emploi.
• Responsable des archives publiques : s'assure que la documentation (voir clause 4) est conservée conformément au droit des archives publiques de l'État et de la municipalité, les logs de décision d'IA étant de plus en plus considérés comme soumis aux demandes d'accès aux documents publics (comme plusieurs tribunaux d'État l'ont jugé pour les outils de police prédictive).

Clause centrale 3 : chemin d'escalade avant et après déploiement

Avant déploiement, définissez un point d'arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êt obligatoire : tout système classé en risque « moyen » ou « élevé » ne peut être mis en service sans validation écrite du réviseur du risque modèle et du responsable redevable.

Après déploiement, définissez l'échelle d'incident :

1. Un agent de terrain ou un citoyen signale une anomalie (refus de prestation injustifié, signalement biaisé).
2. Enregistrement sous 48 heures auprès du Data Steward.
3. Le réviseur du risque modèle évalue sous 5 jours ouvrés : erreur isolée ou schéma systémique ?
4. Si c'est systémique, le responsable redevable décide : suspendre, corriger ou réentraîner, avec décision documentée et datée.
5. Toute suspension affectant un service au public déclenche une notification à l'organe de contrôle (commission du conseil municipal, groupe de travail IA du législateur d'État, ou bureau de l'IG, selon la juridiction).

C'est cette échelle que teste réellement un audit d'IG : non pas « aviez-vous une politique » mais « avez-vous suivi votre propre chemin d'escalade la dernière fois qu'un problème est survenu ».

Clause centrale 4 : des standards de documentation qui tiennent

Les auditeurs veulent des artefacts, pas des récits. Documentation minimale par système :

/ai-system-record/
  01_intake_form.pdf        (purpose, vendor, data sources)
  02_risk_assessment.pdf    (tier, bias testing results, sign-off dates)
  03_human_review_log.csv   (every override of an AI recommendation)
  04_incident_log.csv       (date, description, resolution, owner)
  05_annual_review.pdf      (re-certification or retirement decision)

La durée de conservation doit correspondre au droit des archives publiques de votre juridiction, typiquement le même calendrier que celui appliqué à la fonction publique sous-jacente (dossiers de prestations, dossiers d'achats, dossiers du personnel). Il ne s'agit pas d'archivage facultatif : plusieurs rapports d'IG municipaux et d'État ont explicitement pointé l'absence de calendrier de conservation comme un manquement d'audit, des dossiers incomplets empêchant de reconstituer la façon dont une décision contestée a été prise.

Garde-fousGarde-fousRègles et contrôles qui maintiennent un système d'IA dans des limites sûres, légales et conformes à la marque, en bloquant les sorties et actions hors cadre.Voir la définition complète → à exécuter avant tout déploiement

Avant qu'un système ne franchisse le point d'arrêt de la clause 1, effectuez ces vérifications :

1. Test de biais et d'impact disparate : comparez les résultats entre groupes démographiques quand les données le permettent, avec des métriques d'équité établies (par exemple demographic parity, equalized odds).
2. Contrôle de provenance des données : confirmez que les sources de données d'entraînement et d'entrée sont légalement obtenues et correctement délimitées (aucune donnée personnelle non autorisée).
3. Confirmation du human-in-the-loop : pour tout niveau à risque élevé, un humain doit pouvoir revoir et annuler la décision avant qu'elle ne prenne effet sur une personne, pas après.
4. Contrôle de transparence fournisseur : le contrat donne-t-il à l'agence un droit d'audit sur la logique du modèle et l'historique de ses mises à jour ? Beaucoup d'échecs d'achat remontent à des contrats fournisseurs qui bloquent ce droit.
5. Contrôle de notification publique : la juridiction exige-t-elle la divulgation publique de l'usage d'un système de décision automatisé (comme la Local Law 144 de New York l'exige pour les outils automatisés de décision d'embauche) ?

À quoi cela ressemble en pratique

Imaginez une ville de taille moyenne déployant un outil d'IA pour trier par urgence les demandes de service 311 (réclamations citoyennes non urgentes). Sous la charte : il entre dans l'inventaire en risque moyen (il affecte l'ordre de traitement mais pas l'éligibilité ni des droits). Le réviseur du risque modèle le teste pour détecter un biais au niveau des quartiers, le scoring d'urgence pouvant systématiquement déprioriser les zones à faibles revenus. Le responsable redevable valide, un régulateur humain conservant le pouvoir d'annulation. Trois mois plus tard, le bureau d'un élu du conseil signale un schéma : les réclamations d'un district sont systématiquement dépriorisées. L'échelle d'incident se déclenche, le schéma est confirmé, et le modèle est réentraîné avec justification consignée. Lorsque le bureau du Comptroller de la ville auditera ensuite le programme, chaque étape aura un horodatage et un nom associés.

🎬 [VIDEO: "How Government Agencies Are Regulating AI" - youtube.com - cherchez les explainers du GAO ou de la Brookings Institution sur les cadres fédéraux de supervision de l'IA et les structures de redevabilité des agences]

Points clés

• Une charte de gouvernance attribue une redevabilité nommée et des points de décision documentés ; une déclaration de principes ne survivra pas à un audit.
• Classez chaque système d'IA par risque (faible, moyen, élevé) avec un framework cohérent avec l'OMB M-24-10 (fédéral américain) ou les catégories de risque de l'AI Act européen (pour les juridictions qui s'y réfèrent).
• Construisez un chemin d'escalade en deux parties : un point d'arrêt avant déploiement exigeant une validation, et une échelle d'incident après déploiement avec des délais de réponse fixes.
• La documentation doit être fondée sur des artefacts (logs, validations, revues datées) et conservée selon le droit des archives publiques, ces dossiers étant de plus en plus soumis aux demandes d'accès et aux revues d'IG.
• Testez les biais, la provenance des données, la capacité d'annulation humaine et les droits d'audit sur le fournisseur avant la mise en service, pas après qu'une réclamation ait imposé la question.