La carte réglementaire que tout dirigeant du secteur public doit connaître

Une agence d'État chargée du chômage dans l'Ohio veut déployer un seul outil d'IA : un chatbot qui filtre les demandes d'allocations et signale les fraudes probables. Assez simple, jusqu'à ce qu'on compte les corpus de règles qu'il touche. L'EU AI Act s'applique si le modèle du fournisseur a été entraîné ou proposé par un fournisseur lié à l'UE. Un executive order fédéral encadre la façon dont l'agence l'achète. Les règles de l'Ohio sur l'algorithmic accountability régissent son usage auprès des résidents. Trois régimes réglementaires, un chatbot, et un calendrier de conformité qu'aucun service ne pilote entièrement.

Cette collision est désormais banale. Les dirigeants du secteur public ne choisissent pas leur corpus de règles. Ils doivent savoir où tous se recoupent, et où ils se contredisent.

Pourquoi un seul déploiement déclenche plusieurs régimes

La régulation de l'IA suit trois logiques différentes selon la juridiction :

• L'UE régule par catégorie de risque. L'EU AI Act (en vigueur depuis août 2024, avec des obligations qui entrent progressivement en application jusqu'en 2026-2027) classe les systèmes d'IA en risque inacceptable, élevé, limité et minimal. Les usages du secteur public comme la détection de fraude, l'éligibilité aux prestations et la police prédictive sont explicitement désignés « à haut risque » (Annexe III). Haut risque signifie évaluations de conformité obligatoires, supervision humaine, journalisation et enregistrement dans une base de données de l'UE avant déploiement.
• Les États-Unis régulent par action de l'exécutif et des agences, pas par une loi unique. Il n'existe pas de loi fédérale sur l'IA équivalente à l'EU AI Act. Les orientations viennent d'executive orders présidentiels (qui changent avec chaque administration ; l'executive order Biden de 2023 sur « Safe, Secure, and Trustworthy AI » a été abrogé et remplacé par un executive order Trump de 2025 qui privilégie l'innovation et l'allègement des restrictions) et de guidance propres aux agences, comme les mémorandums de l'OMB (Office of Management and Budget) sur l'usage de l'IA par les agences fédérales.
• Les États américains comblent le vide avec leurs propres lois. L'AI Act du Colorado (première loi d'État américaine complète, dont l'entrée en vigueur était prévue pour 2026 et a fait l'objet de votes de report), l'Illinois et d'autres imposent des obligations aux « deployers » de systèmes de décision automatisée « à haut risque », définis État par État, sans seuil cohérent.

Un même outil peut relever du risque minimal dans un cadre et du haut risque dans un autre, simplement parce que les définitions ne coïncident pas.

La collision à trois, concrètement

Reprenons le chatbot de l'Ohio.

Sous l'EU AI Act : si le modèle sous-jacent provient d'un fournisseur établi dans l'UE, ou si le résultat est utilisé pour affecter des personnes situées dans l'UE (peu probable ici, mais pertinent pour des agences fédérales détenant des données de citoyens de l'UE), il peut entrer dans le champ avec des obligations de haut risque : une évaluation d'impact sur les droits fondamentaux, une documentation technique et une supervision humaine intégrée à la conception.

Sous les règles fédérales américaines : s'il s'agit d'une agence fédérale (ce n'est pas le cas ici, mais imaginez un équivalent de l'IRS), la guidance OMB applicable exigerait une évaluation d'impact IA et la validation d'un Chief AI Officer désigné avant déploiement. Les agences d'État ne sont pas directement liées par les executive orders fédéraux, mais adoptent souvent des modèles similaires parce que les financements fédéraux (par exemple, du Department of Labor pour les systèmes d'assurance chômage) sont de plus en plus assortis de conditions d'usage de l'IA.

Sous la loi de l'Ohio ou une loi d'État comparable : l'agence, en tant que « deployer », peut devoir conduire une évaluation d'impact algorithmique, informer les demandeurs qu'une IA intervient dans la décision et offrir une voie de recours humaine, des obligations calquées sur l'approche du Colorado et de l'Illinois même là où la loi de l'Ohio est en retard.

Résultat : l'agence a besoin de trois évaluations qui se recoupent sans être identiques, de trois jeux de documentation, et n'a aucun régulateur unique à appeler pour obtenir une réponse définitive.

Un tableau de décision simple

Les risques IA de fond qui structurent les trois cadres

Retirez les étiquettes juridictionnelles et les risques sous-jacents sont partout les mêmes. C'est la partie à mémoriser, car elle se transpose à toutes les lois que vous rencontrerez ensuite :

1. Biais et impact disparate. Un modèle entraîné sur des données historiques de demandes peut encoder des discriminations passées (par exemple, signaler les demandeurs de certains codes postaux comme plus à risque de fraude parce que les contrôles y étaient historiquement concentrés).
2. Opacité (risque « boîte noire »). Si les agents instructeurs ne peuvent pas expliquer pourquoi le système a signalé quelqu'un, les droits de la défense sont difficiles à respecter. C'est pourquoi l'« explicabilité » apparaît dans presque tous les cadres.
3. Data drift et dégradation du modèle. Un modèle entraîné sur les schémas de demandes de 2022 peut se tromper sur ceux de 2026 (nouveaux montages frauduleux, nouvelles conditions économiques) s'il n'est jamais réentraîné ni surveillé.
4. Biais d'automatisation. Les relecteurs humains valident machinalement les recommandations de l'IA au lieu de les examiner réellement, ce qui vide de sa substance l'exigence de « supervision humaine » que tous les régulateurs réclament sur le papier.
5. Risque fournisseur et supply chain. La plupart des agences publiques achètent l'IA, elles ne la construisent pas. Les données d'entraînement du fournisseur, son cycle de mise à jour et ses sous-traitants deviennent aussi l'exposition réglementaire de l'agence.

Les 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 → à mettre en place avant déploiement

Une checklist pratique de pré-déploiement, utilisable quelle que soit la paperasse juridictionnelle que vous remplissez :

• Classez d'abord le cas d'usage. Décide-t-il ou influence-t-il significativement l'éligibilité, les prestations ou une action coercitive à l'encontre d'une personne ? Si oui, partez du principe d'un traitement haut risque dans le cadre applicable.
• Menez une évaluation d'impact documentée. Pas une formalité, une véritable analyse de qui pourrait être lésé et comment (bien faite, elle satisfait simultanément les modèles UE, fédéraux et de la plupart des États).
• Exigez un human-in-the-loop doté d'une réelle autorité pour passer outre, pas d'un simple tampon. Journalisez chaque override pour l'audit.
• Réclamez la documentation du modèle aux fournisseurs avant signature : provenance des données d'entraînement, modes de défaillance connus, résultats des tests de biais et calendrier de mise à jour/réentraînement. Le NIST AI Risk Management Framework américain (gratuit, chez NIST) est un bon modèle de questionnaire fournisseur.
• Construisez une voie de recours et d'information pour les personnes concernées, puisque presque toutes les lois d'État et l'EU AI Act l'exigent sous une forme ou une autre.
• Surveillez après déploiement, pas seulement avant le lancement. Le drift et les biais peuvent apparaître après la mise en production même si l'audit initial était propre.

# Simple pre-deployment risk flag (illustrative, not a compliance tool)
def flags_high_risk(use_case):
    triggers = [
        use_case.affects_benefits_eligibility,
        use_case.affects_law_enforcement,
        use_case.lacks_human_override,
        use_case.uses_protected_class_proxies
    ]
    return any(triggers)  # un seul True → traiter comme haut risque dans tous les régimes

Pourquoi cela concerne les dirigeants, pas seulement les équipes conformité

L'erreur que commettent la plupart des dirigeants du secteur public est de déléguer entièrement la « régulation de l'IA » au juridique ou à l'IT. Mais la collision décrite plus haut est un problème de conception de la gouvernance, pas un problème de paperasse. Décider qui pilote l'évaluation d'impact, qui détient l'autorité d'override et comment les contrats fournisseurs répartissent la responsabilité, ce sont des décisions de direction. Si elles ne sont prises qu'au moment de la revue juridique, il est en général trop tard pour reconcevoir le système à moindre coût.

Points clés

• Aucune loi unique ne régit l'IA du secteur public. Attendez-vous à ce que l'EU AI Act, la guidance de l'exécutif fédéral américain et les lois d'État sur les algorithmes s'appliquent simultanément au même outil, avec des définitions différentes du « haut risque ».
• Construisez la conformité autour du standard applicable le plus strict plutôt que de chercher à satisfaire chaque cadre séparément ; c'est moins coûteux et plus défendable.
• Les risques sous-jacents (biais, opacité, data drift, biais d'automatisation, risque fournisseur) sont constants d'une juridiction à l'autre même quand le langage juridique diffère. 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 →îtrisez les risques, pas seulement les textes.
• Traitez les évaluations d'impact, l'autorité d'override humain et la documentation fournisseur comme des décisions de direction prises avant l'achat, pas comme de la paperasse de conformité ajoutée après.
• Les cadres réglementaires évoluent vite (les executive orders américains en particulier). Bâtissez des processus de gouvernance qui survivent à un changement d'administration ou au report d'une loi d'État, plutôt que des processus arrimés au texte exact d'une réglementation donnée.