L’AI Act n’est plus un sujet réservé aux directions juridiques. Depuis le 2 février 2025, les entreprises déployant des systèmes d’IA dans l’Union européenne doivent notamment prendre en compte l’obligation de développer la AI literacy, c’est-à-dire les compétences nécessaires à une utilisation maîtrisée de ces systèmes. Depuis le 2 août 2025, les règles applicables aux modèles d’IA à usage général ont également commencé à s’appliquer, tandis que les obligations de transparence sont devenues un jalon central en 2026.
La méthode efficace ne consiste pas à attendre un audit ou à empiler des chartes. Elle consiste à recenser les usages, classer les risques, attribuer des responsabilités, documenter les décisions et intégrer des contrôles dans chaque projet. Cette discipline devient d’autant plus stratégique que Demis Hassabis estime désormais que l’AGI, une intelligence artificielle générale capable de réaliser un large éventail de tâches intellectuelles, pourrait apparaître dans deux à trois ans.
Voici une méthode opérationnelle pour transformer la régulation en système de pilotage, plutôt qu’en exercice administratif ponctuel.
La première étape consiste à établir la carte réelle de vos usages d’IA
Une stratégie de conformité commence par un inventaire complet, pas par une liste des outils officiellement validés. Les collaborateurs utilisent souvent des assistants conversationnels, des services de transcription, des fonctions de génération de code ou des outils intégrés aux logiciels métiers sans que la direction des systèmes d’information dispose d’une vision consolidée.
L’inventaire doit couvrir les systèmes achetés, développés en interne, intégrés par un fournisseur et utilisés de manière informelle. Il doit également distinguer les modèles utilisés directement par les équipes des fonctionnalités d’IA activées à l’intérieur d’un logiciel déjà référencé.
Pour chaque usage, renseignez au minimum :
- le nom du système et de son fournisseur ;
- le service responsable ;
- la finalité opérationnelle ;
- les catégories de données traitées ;
- les personnes concernées ;
- le niveau d’autonomie du système ;
- la possibilité d’une intervention humaine ;
- le pays de déploiement et les utilisateurs visés ;
- les dépendances à un modèle ou à une API externe ;
- les preuves disponibles : contrat, documentation, tests et journalisation.
Cette cartographie doit inclure les projets expérimentaux. Un prototype qui analyse des candidatures ou résume des dossiers clients peut présenter un risque réglementaire avant même son passage en production.
Le registre doit suivre le cycle de vie du système
Un inventaire statique devient rapidement obsolète. Un changement de modèle, de fournisseur, de jeu de données ou de cas d’usage peut modifier le profil de risque d’un système sans changement apparent dans l’interface.
Attribuez donc un identifiant à chaque système et prévoyez une mise à jour lors de cinq événements : lancement, changement de modèle, changement de données, extension du périmètre et incident. Le registre doit être exploitable par les équipes produit, sécurité, juridique, conformité et audit interne.
À retenir : un système absent du registre ne peut pas être correctement classé, contrôlé ou défendu lors d’un contrôle.
La classification par risque doit guider les décisions d’investissement
L’AI Act adopte une approche fondée sur le risque. Le travail de l’entreprise consiste à traduire cette logique juridique en décisions concrètes : interdire, encadrer, surveiller ou autoriser sous conditions.
Les systèmes doivent d’abord être examinés au regard des pratiques interdites. Les usages liés à la manipulation, à certaines formes de catégorisation biométrique ou à l’exploitation de vulnérabilités peuvent relever des interdictions prévues par le règlement. Les équipes ne doivent pas attendre la phase de déploiement pour réaliser cette analyse.
Les systèmes utilisés dans des domaines sensibles nécessitent ensuite une attention renforcée. Les cas d’usage liés à l’emploi, à l’éducation, à l’accès à des services essentiels, aux infrastructures critiques, à la biométrie ou à la justice font partie des catégories citées dans les analyses de mise en œuvre de l’AI Act.
Les systèmes d’IA à usage général doivent être traités dans une catégorie distincte. Une entreprise qui utilise un modèle fourni par un tiers n’assume pas nécessairement les mêmes obligations que le fournisseur du modèle, mais elle doit comprendre les conditions d’utilisation, les limites documentées, les mesures de sécurité et la manière dont ses propres usages influencent ses responsabilités.
Une grille interne simple accélère l’arbitrage
Le classement réglementaire doit être complété par une grille de risque métier. Elle permet de comparer des projets qui appartiennent à la même catégorie juridique mais qui n’ont pas les mêmes conséquences opérationnelles.
| Niveau interne | Exemple d’usage | Décision de gouvernance | Contrôles attendus |
|---|---|---|---|
| Faible | Reformulation de contenus internes sans données sensibles | Déploiement encadré | Charte d’usage et formation |
| Modéré | Synthèse de documents commerciaux ou assistance au support | Validation du responsable métier | Revue humaine et contrôle des données |
| Élevé | Analyse de candidatures ou recommandation influençant une décision individuelle | Validation juridique et comité IA | Évaluation des biais, traçabilité et recours humain |
| Critique | Décision automatisée dans un domaine sensible ou traitement de données hautement sensibles | Autorisation exécutive formelle | Évaluation d’impact, surveillance continue et plan d’arrêt |
Cette grille ne remplace pas la qualification juridique. Elle sert à déterminer la profondeur des contrôles, le budget nécessaire et le niveau d’approbation interne.
Le calendrier 2026 doit être traduit en feuille de route d’entreprise
Le calendrier réglementaire de l’Union européenne s’étale sur plusieurs années. L’obligation de développer la AI literacy et les interdictions ont commencé à produire leurs effets le 2 février 2025. Les règles relatives aux modèles d’IA à usage général ont commencé à s’appliquer le 2 août 2025.
Le 2 août 2026 constitue un autre jalon majeur : l’AI Act devient largement applicable, notamment pour les obligations de transparence concernant des systèmes comme les chatbots. Les entreprises doivent notamment être capables d’informer les personnes lorsqu’elles interagissent avec un système d’IA dans les situations couvertes par le règlement.
Le calendrier des systèmes à haut risque a toutefois fait l’objet d’évolutions en 2026. Des analyses de mise en œuvre indiquent que le Digital Omnibus adopté le 27 juillet 2026 a déplacé certaines échéances, notamment pour des systèmes autonomes relevant de l’annexe III, avec une échéance reportée au 2 décembre 2027, tandis que les systèmes à haut risque intégrés à certains produits sont associés à une échéance au 2 août 2028.
Ces reports ne justifient pas l’inaction. Ils offrent une période supplémentaire pour construire les processus, tester les contrôles et éviter une mise en conformité précipitée.
Organisez la feuille de route en trois horizons
Horizon immédiat, de 0 à 90 jours
- nommer un responsable de la gouvernance de l’IA ;
- recenser les systèmes et les fournisseurs ;
- suspendre les usages non documentés dans les domaines sensibles ;
- publier une politique provisoire d’utilisation ;
- lancer la formation des équipes exposées ;
- vérifier les mécanismes de transparence des chatbots et contenus générés.
Horizon de consolidation, de 3 à 6 mois
- classer les cas d’usage selon le risque ;
- intégrer des clauses IA dans les achats et contrats fournisseurs ;
- formaliser les évaluations de risques et d’impact ;
- organiser la validation des données et des résultats ;
- définir les procédures d’incident et de retrait ;
- mettre en place des indicateurs de suivi.
Horizon de maturité, au-delà de 6 mois
- auditer les systèmes à risque élevé ;
- tester régulièrement la robustesse et les biais ;
- intégrer la gouvernance dans les méthodes produit ;
- préparer les contrôles externes ;
- réévaluer les usages à chaque changement de modèle ou de périmètre.
La gouvernance doit réunir métier, technique et direction
Une politique portée uniquement par le service juridique ne résiste pas à la vitesse des projets. Le juridique interprète les obligations, mais les équipes métier connaissent les décisions prises, les équipes techniques contrôlent les flux et la sécurité surveille les attaques, les fuites et les accès.
Le modèle le plus robuste repose sur une instance transverse. Elle peut être un comité IA dédié ou une extension d’un comité des risques existant. Sa mission doit être écrite : elle approuve les cas sensibles, définit les niveaux de preuve attendus, arbitre les exceptions et suit les incidents.
Les responsabilités doivent être séparées :
- la direction fixe le niveau de risque acceptable ;
- le responsable métier justifie la finalité et les bénéfices attendus ;
- la direction technique décrit l’architecture et les dépendances ;
- la sécurité évalue les menaces et les contrôles d’accès ;
- le juridique qualifie les obligations applicables ;
- la conformité vérifie les preuves ;
- les utilisateurs signalent les erreurs, biais et comportements inattendus.
ISO 42001 et NIST AI RMF peuvent structurer le dispositif
ISO/IEC 42001 est une norme de système de management dédiée à l’IA. Elle fournit un cadre certifiable comprenant une politique, des rôles, une évaluation des risques et des impacts, des contrôles opérationnels, un audit interne, une revue de direction et une logique d’amélioration continue.
Le NIST AI RMF, ou cadre de gestion des risques liés à l’IA du NIST, organise le travail autour de quatre fonctions : Govern, Map, Measure et Manage. Il s’agit d’un cadre volontaire qui sert de checklist pratique pour identifier et traiter les risques.
L’AI Act, ISO/IEC 42001 et le NIST AI RMF n’ont pas le même statut. L’AI Act constitue une obligation juridique pour les systèmes concernés par son champ d’application, ISO/IEC 42001 est une norme certifiable volontaire et le NIST AI RMF est un cadre volontaire de gestion des risques.
| Référentiel | Fonction dans la stratégie | Utilisation recommandée |
|---|---|---|
| AI Act | Détermine les obligations légales selon le risque | Qualification réglementaire et plan d’action |
| ISO/IEC 42001 | Structure un système de management de l’IA | Gouvernance, audit et amélioration continue |
| NIST AI RMF | Organise l’identification et le traitement des risques | Méthode opérationnelle pour les équipes |
Une entreprise peut utiliser le NIST AI RMF pour construire ses processus, ISO/IEC 42001 pour formaliser son système de management et l’AI Act pour vérifier les obligations applicables en Europe.
Les contrats fournisseurs doivent devenir des contrôles de conformité
Le risque ne disparaît pas parce qu’un modèle est fourni par une entreprise externe. Le contrat doit permettre de comprendre le service, les données, les changements et les responsabilités.
Les négociations doivent couvrir au moins :
- les lieux de traitement et de stockage ;
- les catégories de données utilisées pour fournir le service ;
- la réutilisation éventuelle des entrées et sorties ;
- les sous-traitants ;
- les engagements de disponibilité et de sécurité ;
- la notification des incidents ;
- la documentation du modèle et de ses limites ;
- les modalités de changement de modèle ;
- les capacités d’export et de réversibilité ;
- les droits d’audit et de vérification.
Une clause générale affirmant que le fournisseur « respecte la réglementation » ne suffit pas à piloter un risque. Le client doit obtenir des éléments vérifiables : documentation technique, résultats de tests, procédure d’incident, conditions de conservation des données et historique des changements significatifs.
Évaluez le fournisseur avant l’achat, pas après l’incident
Le processus d’achat doit intégrer un questionnaire IA adapté au niveau de risque. Un outil de génération de slogans ne nécessite pas la même diligence qu’un système qui classe des candidats ou aide à attribuer un crédit.
Pour les usages sensibles, la validation doit être conditionnée à la disponibilité de preuves. Le fournisseur doit notamment expliquer comment sont traitées les données, quelles limitations sont connues et comment le client peut suspendre l’usage.
Les achats doivent aussi éviter la dépendance silencieuse à un modèle unique. Un changement de prix, d’API ou de comportement peut affecter un processus critique. La réversibilité devient donc une exigence stratégique, même lorsqu’aucune obligation réglementaire ne l’impose directement.
La preuve doit être produite au fil du projet
La conformité devient défendable lorsque chaque décision importante laisse une trace datée, attribuée et compréhensible. Il ne s’agit pas de remplir des documents pour eux-mêmes, mais de pouvoir expliquer pourquoi le système a été choisi, comment il a été testé et dans quelles limites il est utilisé.
Le dossier de chaque système devrait regrouper :
- la finalité et le périmètre ;
- la classification réglementaire et interne ;
- l’analyse des données ;
- les tests de précision, robustesse et sécurité ;
- l’évaluation des biais lorsque des personnes sont concernées ;
- les règles de supervision humaine ;
- les informations communiquées aux utilisateurs ;
- les incidents et mesures correctives ;
- les validations et dates de réexamen.
La journalisation doit être proportionnée au risque. Pour un système sensible, l’entreprise doit pouvoir reconstruire la chaîne de décision : version du modèle, données d’entrée pertinentes, sortie produite, intervention humaine et décision finale.
Mesurez la qualité avec des indicateurs utiles
Un tableau de bord limité au nombre de formations suivies ne montre pas si le dispositif fonctionne. Les indicateurs doivent relier conformité, sécurité et performance opérationnelle.
Exemples d’indicateurs :
- part des systèmes recensés dans l’inventaire ;
- délai moyen de validation d’un nouveau cas d’usage ;
- proportion des systèmes classés par niveau de risque ;
- taux de fournisseurs évalués avant contractualisation ;
- nombre d’incidents liés aux données ou aux sorties ;
- délai de détection et de correction ;
- part des systèmes sensibles disposant d’une revue humaine documentée ;
- fréquence des réévaluations après changement de modèle.
Un indicateur doit être associé à un responsable et à un seuil d’action. Si le nombre d’incidents augmente, le comité doit savoir qui peut suspendre le système et dans quel délai.
L’horizon de l’AGI impose de concevoir une gouvernance adaptable
Demis Hassabis estime que l’AGI pourrait apparaître dans deux à trois ans, après avoir précédemment évoqué des horizons plus longs. Il propose également un conseil de supervision des modèles, financé par l’industrie mais placé sous contrôle gouvernemental, afin d’évaluer certains modèles avant leur mise à disposition.
Hassabis associe cette discussion au « test d’Einstein », une proposition visant à évaluer si un système entraîné uniquement sur des connaissances antérieures à une période donnée pourrait produire une avancée scientifique comparable à celle d’Einstein. Les descriptions publiées présentent ce test comme une référence méthodologique, et non comme un benchmark déjà réussi par un système.
Cette perspective ne permet pas de fixer une date certaine pour l’AGI. Elle justifie en revanche une architecture de gouvernance capable d’absorber des modèles plus autonomes, plus polyvalents et plus difficiles à évaluer avec les seuls indicateurs de précision actuels.
Préparez trois scénarios sans les confondre avec des prédictions
Une entreprise peut planifier sans présenter un scénario comme une certitude :
- Scénario d’assistance : les modèles génèrent des contenus, du code ou des synthèses, avec validation humaine systématique ;
- Scénario d’orchestration : les modèles enchaînent plusieurs outils et exécutent des tâches sous des permissions limitées ;
- Scénario d’autonomie accrue : les modèles poursuivent des objectifs sur une durée plus longue et prennent davantage d’initiatives.
Chaque scénario doit préciser les permissions, les limites budgétaires, les données accessibles, les mécanismes d’arrêt et le niveau de supervision. Le principe essentiel reste identique : plus un système peut agir seul, plus la gouvernance doit contrôler ses objectifs, ses outils et ses effets.
À retenir : la régulation ne doit pas seulement vérifier ce qu’un modèle produit. Elle doit aussi contrôler ce qu’il peut décider, déclencher et modifier.
Notre avis : la bonne stratégie consiste à gouverner avant de certifier
En 2026, les entreprises qui attendent une obligation définitive pour structurer leurs pratiques prennent un retard opérationnel. Les échéances européennes, les exigences de transparence, la montée des modèles à usage général et les discussions sur l’AGI rendent nécessaire un registre central, une classification par risque, une validation transverse et une preuve continue.
La priorité n’est pas de créer un comité supplémentaire sans pouvoir. Elle est de donner à une instance identifiée le droit d’autoriser, de refuser et de suspendre un système. Sans ce pouvoir, la gouvernance reste consultative et les risques se déplacent vers les équipes qui utilisent les outils au quotidien.
La trajectoire recommandée est claire : cartographier maintenant, traiter les usages sensibles en premier, contractualiser les contrôles, adopter un référentiel de risques et intégrer la conformité au cycle produit. Dans les six prochains mois, l’avantage reviendra aux entreprises capables de démontrer non seulement qu’elles utilisent l’IA, mais qu’elles savent expliquer où, pourquoi, avec quelles limites et sous quelle responsabilité.
La question stratégique n’est donc plus de savoir si la régulation ralentira l’IA, mais si votre organisation saura transformer ses exigences en capacité de déploiement fiable avant que les modèles ne deviennent plus autonomes.