IA responsable : encadrer ne suffit pas à garder la maîtrise

IA responsable : encadrer ne suffit pas à garder la maîtrise

Une charte "Responsible AI" tient facilement sur une page. Transparence, équité, sécurité, supervision humaine : les principes sont désormais connus.

Le problème commence juste après.

Qui sait exactement quels systèmes d'IA sont déjà utilisés dans l'entreprise ? Quels documents partent vers un fournisseur externe ? Quel modèle alimente telle fonction ? Qui vérifie une réponse lorsqu'elle devient une décision ? Que se passe-t-il si le fournisseur modifie son modèle, augmente ses prix ou devient indisponible ? Et si un agent connecté à une API interprète mal une instruction, quelle action peut-il réellement exécuter avant qu'un humain ne l'arrête ?

Le cinquième dossier de cette série part de la question "Comment adopter l'IA de manière responsable ?" et aboutit à quelque chose de beaucoup moins abstrait : la responsabilité commence lorsque l'organisation peut encore expliquer, limiter, vérifier et arrêter ce qu'elle a déployé.

Commencer par le problème, pas par le modèle

La première erreur est presque banale : acheter l'outil avant d'avoir décrit le besoin.

"Nous devons mettre de l'IA dans le support", "nous voulons un agent", "nous allons connecter un LLM à nos documents" sont des décisions techniques prises avant la question essentielle : quel problème essaie-t-on de résoudre, pour qui, et comment saura-t-on que le nouveau système fait mieux que l'ancien ?

Le NIST AI Risk Management Framework propose une structure utile : Govern, Map, Measure, Manage. Le risque y est traité comme un processus continu à travers le cycle de vie du système, et le cadre reste volontaire et adaptable aux organisations.

Avant de choisir un modèle, il faudrait pouvoir documenter la finalité, les utilisateurs, les personnes affectées, les données traitées, les décisions influencées, le niveau d'autonomie, le coût d'une erreur et la possibilité de revenir en arrière.

Gouverner ce que l'on ne voit pas est impossible

L'IA n'entre plus seulement dans une organisation par un contrat signé avec un fournisseur spécialisé. Elle arrive dans la suite bureautique, le CRM, le navigateur, l'éditeur de code, la visioconférence, les extensions, les comptes personnels et les API ouvertes par une équipe projet.

Le dossier Deep Search insiste sur la "Shadow AI". Les pourcentages disponibles varient fortement selon les enquêtes et reposent souvent sur des données produites par des vendeurs de sécurité. Je ne les reprends donc pas comme mesure universelle.

Le mécanisme, lui, est clair : interdire un outil ne permet pas de savoir s'il n'est plus utilisé.

Une organisation devrait donc tenir un registre vivant, pas seulement des logiciels achetés, mais des cas d'usage : résumé de réunions, aide au code, analyse documentaire, réponse client, recrutement, génération d'images, agent connecté au CRM, etc.

Résumer un document public et sélectionner un candidat à un emploi n'ont évidemment pas le même niveau de risque.

Le droit européen oblige à distinguer les calendriers

En septembre 2026, le cadre européen a encore évolué.

Le règlement (UE) 2026/1744 a repoussé au 2 décembre 2027 les obligations des sections 1, 2 et 3 du chapitre III pour les systèmes à haut risque relevant de l'article 6(2) et de l'annexe III. Pour ceux relevant de l'article 6(1) et de l'annexe I, l'échéance est fixée au 2 août 2028.

En revanche, tout n'a pas été reporté.

Les obligations de transparence de l'article 50 font partie du droit applicable depuis août 2026. Lorsqu'un système est destiné à interagir directement avec une personne, celle-ci doit en principe être informée qu'elle échange avec une IA, sauf lorsque cela ressort clairement du contexte. Pour les systèmes générant des contenus synthétiques déjà sur le marché avant le 2 août 2026, le règlement 2026/1744 prévoit une transition jusqu'au 2 décembre 2026 pour l'obligation technique de l'article 50(2).

Autre correction importante : la modification de l'article 4 n'a pas supprimé l'obligation des fournisseurs et déployeurs en matière de maîtrise de l'IA. Le texte actuel leur demande toujours de prendre des mesures pour favoriser le développement de la maîtrise de l'IA de leur personnel, sans leur imposer de garantir un niveau individuel précis.

J'avais détaillé la logique de ce calendrier dans AI Act 2026-2028 : le calendrier ne suffit plus, place à la gouvernance des usages.

L'essentiel est ailleurs : un report réglementaire n'est pas une raison pour reporter l'inventaire, les tests ou la sécurité.

"Pas utilisé pour l'entraînement" ne veut pas dire "pas conservé"

Un fournisseur peut promettre de ne pas utiliser les données d'un client pour entraîner ses modèles. Cette promesse ne répond pas automatiquement aux autres questions : les données sont-elles conservées ? Combien de temps ? Où ? Qui peut y accéder ? Quels sous-traitants interviennent ? Comment s'effectue la suppression ?

Le choix responsable n'est donc pas automatiquement "cloud", "local" ou "open source". Chacune de ces architectures déplace les responsabilités.

Un modèle local peut réduire l'exposition à un tiers, mais transfère la responsabilité des mises à jour, vulnérabilités, journaux et infrastructures vers l'organisation. Une API professionnelle peut au contraire apporter des engagements contractuels plus précis qu'un service grand public. Aucun mode de déploiement n'est sûr par nature.

La CNIL rappelle que lorsque l'IA traite des données personnelles, les principes du RGPD restent applicables : finalité déterminée, explicite et légitime, minimisation, limitation de conservation et sécurité adaptée aux risques.

Le meilleur flux de données est souvent celui que l'on n'envoie pas.

L'agent change la nature du risque

Un chatbot qui rédige une réponse et un agent qui peut l'envoyer n'appartiennent pas à la même catégorie.

Ajoutons la possibilité de modifier un CRM, déclencher un remboursement, exécuter un script, supprimer une donnée ou appeler une API, et l'on ne parle plus seulement de qualité de génération. On parle de droits d'action.

L'OWASP GenAI Security Project a renforcé ce sujet en 2026 avec ses travaux sur les applications agentiques et l'Agent Control Standard. L'idée la plus utile reste classique en cybersécurité : le moindre privilège.

Un modèle n'a aucune raison de disposer par défaut de l'ensemble des droits de l'utilisateur humain qui l'a lancé.

Mettre un humain dans la boucle ne suffit pas

"Human in the loop" est devenu une formule rassurante.

Elle ne signifie pourtant rien si l'humain n'a ni le temps, ni les informations, ni l'autorité pour contredire le système.

Zana Buçinca, Maja Barbara Malaya et Krzysztof Gajos l'ont montré expérimentalement en 2021. Dans une étude portant sur 199 participants, des mécanismes de "cognitive forcing" conçus pour obliger l'utilisateur à réfléchir davantage réduisent la surconfiance dans les recommandations de l'IA. Mais les interfaces les plus efficaces pour réduire cette dépendance sont aussi celles que les utilisateurs apprécient le moins.

Une supervision réellement utile introduit donc parfois de la friction.

Si le contrôle humain se résume à cliquer cent fois par jour sur "Valider", l'organisation a techniquement placé un humain dans la boucle tout en supprimant progressivement les conditions de son jugement.

Cette fatigue de supervision rejoint directement AI Brain Fry : quand la supervision des IA nous grille le cerveau.

La bonne question n'est donc pas "y a-t-il un humain ?", mais "cet humain peut-il réellement détecter, comprendre et refuser une erreur ?"

Tester son cas d'usage, pas le classement du fournisseur

Un modèle peut être excellent sur un benchmark public et médiocre sur votre processus.

L'adoption responsable implique donc un jeu d'évaluation représentatif du contexte réel : cas normaux, cas rares, documents incomplets, demandes ambiguës et situations dans lesquelles le système devrait refuser de répondre.

Puis viennent les tests adversariaux.

Pour un système connecté à des documents ou à des outils, il faut tester précisément les comportements interdits : instruction cachée dans un PDF, restitution d'un secret, dépassement de droits, appel d'outil inattendu ou sortie non validée transmise en aval.

La CNIL rappelle que la sécurité des traitements de données personnelles est une obligation du RGPD et doit être proportionnée aux risques. OWASP fournit de son côté une taxonomie technique utile des vulnérabilités propres aux applications LLM et agentiques.

Aucun référentiel ne transforme toutefois un système en système "sûr". Il fournit des contrôles, pas une garantie.

Une mise en production n'est pas une fin

Un système d'IA peut changer sans que l'application change : nouvelle version du modèle, base documentaire qui dérive, nouveaux usages imprévus.

Il faut donc conserver des indicateurs après le lancement : erreurs, corrections humaines, escalades, incidents, coûts, latence, dérive et régressions lors d'un changement de modèle.

Lorsque le fournisseur permet d'utiliser une version précise, il est préférable de tester une nouvelle version avant migration plutôt que de considérer qu'elle est automatiquement meilleure pour le cas métier.

La reproductibilité parfaite reste souvent impossible avec des systèmes génératifs, mais l'absence de reproductibilité parfaite n'autorise pas l'absence de traçabilité.

La conformité ne remplace pas la capacité de sortie

Une organisation peut respecter un référentiel et rester profondément dépendante de son fournisseur.

Où sont stockées les connaissances ajoutées au système ? Les prompts système sont-ils documentés ? Les connecteurs dépendent-ils d'une API propriétaire ? Peut-on remplacer le modèle sans reconstruire tout le workflow ? Que devient le service si le fournisseur disparaît ?

ISO/IEC 42001 structure le management de l'IA et ISO/IEC 23894 la gestion du risque. Ces référentiels peuvent aider, mais ils ne prouvent pas à eux seuls qu'un système particulier respecte toutes les obligations ou produit de bons résultats.

La maîtrise doit donc inclure un plan de sortie : export des données, documentation de l'architecture, abstraction suffisante du fournisseur, mode dégradé et retour à un fonctionnement manuel lorsque la continuité l'exige.

Le droit de couper est un indicateur de maturité

Une gouvernance responsable ne définit pas seulement les conditions d'entrée en production. Elle définit les conditions de sortie.

Quel taux d'erreur déclenche une suspension ? Quelle fuite de données impose l'arrêt ? Qui possède l'autorité pour désactiver l'agent ? Peut-on continuer le service sans l'IA ?

La nouvelle directive européenne sur la responsabilité du fait des produits mérite également d'être suivie sans la surinterpréter. La directive (UE) 2024/2853 inclut les logiciels dans son champ, y compris certains systèmes d'IA. Mais au 19 septembre 2026, les États membres doivent encore la transposer au plus tard le 9 décembre 2026, et le nouveau régime vise les produits mis sur le marché ou en service après le 8 décembre 2026. Il serait donc inexact de présenter déjà ce régime comme pleinement applicable à tous les déploiements actuels.

La prudence juridique commence aussi par le calendrier.

Ma lecture

Adopter l'IA de manière responsable n'est pas ajouter une couche de conformité après le prototype.

C'est concevoir le système de telle manière que l'organisation puisse toujours répondre à sept questions :

1. Pourquoi utilisons-nous cette IA ?
2. Quelles données lui donnons-nous ?
3. Qu'a-t-elle réellement le droit de faire ?
4. Comment savons-nous que ses résultats restent suffisamment bons ?
5. Qui peut la contredire et avec quelles informations ?
6. Que conservons-nous pour comprendre un incident ?
7. Comment continuons-nous si nous devons l'arrêter ou la remplacer ?

Une organisation qui sait répondre à ces questions n'a pas éliminé le risque. Elle l'a rendu observable, discutable et contrôlable.

L'IA peut nous aider à travailler plus efficacement, décider, servir les clients et innover. Mais à chaque fois, le même déplacement apparaît : le gain n'existe pas automatiquement avec l'outil. Il dépend de la façon dont le système est intégré, mesuré, vérifié et limité.

La cinquième question devient donc moins "comment rendre l'IA responsable ?" que :

comment éviter qu'une organisation perde progressivement la maîtrise de ce qu'elle automatise ?

Pour aller plus loin

• AI Act 2026-2028 : le calendrier ne suffit plus, place à la gouvernance des usages
• AI Brain Fry : quand la supervision des IA nous grille le cerveau
• IA et dépendance technologique : le retour des forteresses du Web
• Intelligence économique et veille : du signal à la décision