Le droit opère à travers des personnes et des institutions
Les systèmes d’IA ne se situent pas en dehors de la reddition de comptes ordinaire. Les développeurs, les déployeurs, les fournisseurs, les dirigeants, les agences publiques, et les utilisateurs prennent des décisions sur l’entraînement, l’accès, l’intégration, et la réponse. Le droit peut attribuer des obligations, exiger des preuves, créer des recours, et autoriser les régulateurs à intervenir. Son efficacité dépend de sa portée, de la capacité d’application, de la compétence technique, et de si les obligations atteignent l’acteur qui peut réellement prévenir le préjudice.
La réglementation n’est pas automatiquement plus rapide ni plus fiable que la pression publique, et la pratique volontaire n’est pas automatiquement inutile. L’élaboration de règles et les litiges peuvent être lents ; les normes et les marchés publics peuvent avancer plus vite mais peuvent manquer de reddition de comptes démocratique. Une stratégie durable combine des planchers exécutoires avec une mise en œuvre technique flexible et un examen public.
Adapter la règle au cycle de vie
Une règle d’entraînement pourrait exiger un signalement, une sécurité, ou une évaluation pour les entraînements de développement exceptionnellement grands ou capables. Une règle sur les poids de modèle pourrait imposer une protection ou une diffusion contrôlée là où le vol ou la copie sans restriction crée un risque sévère. Une règle de déploiement peut régir les utilisateurs, les garde-fous, et la surveillance des incidents d’un service hébergé. Une règle d’inférence ou d’usage peut restreindre une application dans l’emploi, la santé, le crédit, l’infrastructure, ou les armes.
Ces règles ne sont pas interchangeables. Interdire un déploiement n’efface pas les poids. Un seuil de calcul d’entraînement peut manquer un modèle plus petit renforcé par des outils ou du calcul au moment de l’inférence. Une règle d’application peut protéger les personnes concernées sans réguler la recherche générale. Une bonne loi identifie l’acteur, la surface de contrôle, le déclencheur fondé sur des preuves, et le recours.
Le paysage actuel n’est plus « seulement volontaire »
L’AI Act de l’Union européenne crée des obligations contraignantes. Les obligations des fournisseurs d’IA à usage général ont commencé à s’appliquer le 2 août 2025, incluant la documentation technique, l’information pour les fournisseurs en aval, une politique de droit d’auteur, et un résumé du contenu d’entraînement. Les fournisseurs de modèles classés comme présentant un risque systémique font face à des obligations supplémentaires d’évaluation, d’atténuation, de signalement d’incidents, et de cybersécurité (aperçu de la Commission européenne sur l’IA à usage général). Les pouvoirs d’application pertinents de l’AI Office ont commencé à s’appliquer le 2 août 2026 (cadre d’application de l’UE).
Aux États-Unis, le décret exécutif 14110 a été révoqué en janvier 2025, si bien que les articles ne devraient pas présenter son programme de signalement comme la politique fédérale actuelle (décret exécutif de 2025). La politique fédérale reste répartie entre les agences existantes, le droit sectoriel, les marchés publics, les contrôles à l’exportation, et les règles d’État, plutôt que dans une loi unique et complète sur l’IA.
La Californie a promulgué le SB 53, qui exige des grands développeurs de pointe couverts qu’ils publient des cadres, traitent des seuils et des atténuations de risque catastrophique, signalent des incidents spécifiés, et protègent les lanceurs d’alerte couverts (directives du procureur général de Californie sur le SB 53). Le RAISE Act de New York et ses amendements de 2026 ont créé des exigences supplémentaires de transparence et de signalement pour les modèles de pointe ; le registre officiel du projet de loi montre que l’amendement a été signé en mars 2026 (Sénat de New York S8828). Ces lois sont plus étroites qu’une garantie générale de sécurité, mais elles réfutent l’affirmation selon laquelle il n’existerait aucune gouvernance contraignante des modèles de pointe.
Responsabilité et recours
La responsabilité peut rendre coûteux un préjudice évitable, mais les slogans sur l’attribution de tout le coût à « la partie la mieux placée » laissent des questions difficiles. Un développeur peut contrôler l’entraînement et les garde-fous ; un hôpital ou un employeur contrôle le contexte et la révision humaine ; un fournisseur en aval contrôle l’ajustement fin ; un utilisateur malveillant peut violer toutes les règles. La responsabilité peut être partagée.
Des régimes utiles définissent des normes de diligence, préservent les preuves, permettent aux personnes lésées d’obtenir des explications ou de contester des décisions, et évitent une immunité générale pour un usage abusif prévisible. Dans le même temps, une responsabilité illimitée peut décourager une recherche ouverte bénéfique ou concentrer le marché parmi les entreprises capables de s’assurer. Des refuges légaux peuvent récompenser des tests documentés et une réponse rapide aux incidents sans devenir une immunité pour avoir simplement coché une case.
Les recours devraient correspondre au préjudice : compensation, correction, suppression, injonction, rappel de produit, restriction de licence, sanction civile, ou application pénale pour une faute intentionnelle. Les systèmes à enjeux élevés ont aussi besoin d’appels administratifs rapides, car des années de litige ne peuvent pas restaurer un bénéfice manqué ou une décision médicale urgente.
Les marchés publics peuvent créer des normes opérationnelles
Les gouvernements et les grandes entreprises peuvent exiger des protections avant l’achat. Les directives de l’Office of Management and Budget des États-Unis pour l’acquisition fédérale d’IA appellent à une planification transversale, une surveillance de la performance, des considérations sur les données et la propriété intellectuelle, et une gestion des risques proportionnelle à l’impact (OMB M-25-22).
Un contrat solide devrait préciser :
- le modèle approuvé et si le fournisseur peut le changer automatiquement ;
- les tests préalables au déploiement pertinents et l’accès à une évaluation indépendante ;
- les journaux d’audit, la documentation, la conservation des données, et la vie privée ;
- les délais de notification des violations et incidents liés à l’IA ;
- les permissions d’outils et les points d’approbation humaine ;
- le retour en arrière, la suspension, la révocation d’identifiants, et le retrait sûr de service ;
- l’exportation des données, l’interopérabilité, et l’assistance à la transition ;
- les dépendances envers les sous-traitants et le cloud ;
- les recours quand la performance ou les garde-fous échouent.
Les conditions des marchés publics peuvent se répandre dans le marché car les fournisseurs réutilisent leurs capacités pour plusieurs clients. Elles peuvent aussi enraciner les acteurs en place si les exigences sont vagues, propriétaires, ou disproportionnément coûteuses. Des normes ouvertes, des ressources de test partagées, et des obligations échelonnées aident les petits fournisseurs à rivaliser.
Les audits ont besoin d’accès et de conséquences
Un audit ne vaut que ce que vaut sa portée. Un examen sur dossier ne peut pas valider le comportement en conditions réelles. Les auditeurs ont besoin de la configuration réellement déployée, de la documentation, des journaux, des incidents connus, et de l’autorité de tester des conditions de défaillance plausibles. L’indépendance, la compétence, la divulgation des conflits, et la protection des informations sensibles comptent toutes.
Les constats d’audit devraient être reliés à des délais de remédiation, des limites de déploiement, des tests de suivi, et des résumés publics adaptés au risque. Un rapport complet confidentiel peut être nécessaire pour des raisons de sécurité ou de confidentialité, mais le secret ne devrait pas permettre à une entreprise de se présenter comme « auditée » sans préciser ce qui a été examiné.
Les régulateurs ont aussi besoin de personnel technique et d’un accès sécurisé. Exiger des rapports qu’aucune agence ne peut interpréter crée du théâtre de conformité. Des frais imposés aux entités régulées peuvent financer la supervision s’ils sont structurés de façon à préserver l’indépendance institutionnelle.
La politique de concurrence a un véritable arbitrage de sécurité
La concentration dans les puces, le cloud, les données, la distribution, et les modèles fondationnels peut créer une dépendance envers un fournisseur, des points de défaillance partagés, et un pouvoir politique privé. L’étude de 2025 de la FTC sur les partenariats cloud-IA a identifié l’accès au calcul et au talent, les coûts de changement, l’exclusivité, et le partage d’informations sensibles comme des préoccupations de concurrence (rapport du personnel de la FTC).
Davantage de concurrence peut réduire la dépendance et permettre aux utilisateurs de quitter des fournisseurs peu sûrs. Elle peut aussi intensifier les courses au lancement, multiplier les dépôts de poids mal sécurisés, et rendre plus difficiles des garde-fous coordonnés. Un unique grand fournisseur peut investir davantage dans la sécurité tout en créant un point unique de défaillance catastrophique. La politique de concurrence devrait donc protéger la contestabilité, l’interopérabilité, la mobilité de la main-d’œuvre, et l’accès aux intrants essentiels, sans supposer que la plus grande ou la plus petite structure de marché soit automatiquement la plus sûre.
La coordination de sécurité entre concurrents peut être bénéfique — formats d’incident partagés, méthodes de référence, ou renseignement de sécurité — mais peut aussi dissimuler une exclusion ou une coordination des prix. Le DOJ et la FTC ont sollicité en 2026 des directives publiques actualisées sur la collaboration entre concurrents, incluant explicitement la tarification algorithmique et le partage d’informations (consultation DOJ/FTC). Des règles claires peuvent permettre une coopération de sécurité authentique tout en préservant la concurrence.
Réponse aux incidents et autorité d’urgence
Les organisations devraient avoir des obligations légales de préserver les journaux, de notifier les autorités compétentes et les parties concernées, de contenir le préjudice, et de coopérer à travers les dépendances. Les régulateurs ont besoin de pouvoirs gradués : demander des informations, exiger une atténuation, restreindre une fonction, ou ordonner une suspension lorsque les preuves montrent un danger urgent.
Les mesures d’urgence ont besoin d’une procédure régulière. Elles devraient identifier le décideur, le seuil, la portée, la durée, la révision, et les conditions de restauration. Un « arrêt de l’IA » large et indéfini n’est ni techniquement cohérent ni compatible avec un gouvernement responsable.
La conclusion pratique
Le levier juridique est le plus solide lorsqu’il est spécifique. Il transforme « soyez responsable » en obligations attachées à l’entraînement, aux poids, au déploiement, à l’inférence, aux marchés publics, et à l’usage à fort impact. Il donne aux personnes concernées des recours, et donne aux opérateurs une autorité claire pour auditer, révoquer des privilèges, revenir en arrière sur des systèmes, et répondre aux incidents.
Aucune juridiction n’a résolu la gouvernance de l’IA. Mais d’ici septembre 2026, les obligations contraignantes de pointe de l’UE et des États, les règles fédérales de marchés publics, l’application de la politique de concurrence, et le droit sectoriel fournissent de vrais outils. La tâche consiste à améliorer leurs preuves, leur interopérabilité, leur application, et leur légitimité démocratique — pas à décrire le domaine comme un choix entre des promesses volontaires et une confrontation spectaculaire.