IA autonome : comment les DSI maîtrisent les risques de la boîte noire

05.05.2026

7 min de lecture

37 pour cent des CIO affirment avoir une visibilité complète sur tous les outils d’intelligence artificielle utilisés dans leur organisation. Le reste prend des décisions de gouvernance sur un système qu’ils ne maîtrisent pas entièrement. L’IA autonome aggrave ce manque de visibilité : lorsque les modèles décident seuls, il ne manque souvent pas seulement l’explicabilité – c’est l’intégralité du cheminement décisionnel qui fait défaut.

Les points clés en bref

L’IA fantôme est le problème fondamental. Les outils d’IA fonctionnent dans la plupart des entreprises en dehors du contrôle informatique – la gouvernance intervient alors structurellement trop tard.
Explicabilité et traçabilité ne sont pas identiques. L’XAI explique des décisions ponctuelles, mais ne documente pas l’historique des décisions. Les CIO ont besoin des deux, mais n’obtiennent souvent que l’un.
L’AI Act de l’UE fixe le cadre, mais ne le remplit pas. La classification « à haut risque » est un point de départ, pas une finalité. Le véritable travail de gouvernance commence après.

En lien :Les CIO sous pression : 62 % en matière de gouvernance de l’IA / Rapport CIO Logicalis 2026 : Seuls 37 % ont une visibilité complète

La question que les CIO posent trop tard

Qu’est-ce que l’IA autonome ? Un système d’IA est considéré comme autonome lorsqu’il prend des décisions opérationnelles ou déclenche des actions sans qu’un humain n’ait à valider chaque cas individuel. Le critère n’est pas la technologie, mais le processus : les décisions de crédit, la détection d’anomalies dans les installations de production ou la présélection de personnel peuvent tous fonctionner de manière autonome – le fait qu’ils le fassent dépend de l’architecture, pas du modèle.

L’IA autonome prend des décisions. C’est là que réside le changement. Il ne s’agit plus de dire que l’IA « soutient » les décisions – ce langage appartient à la phase pilote. La question « Avons-nous une gouvernance de l’IA ? » survient souvent un ou deux ans après la question « Avons-nous une IA autonome ? ». C’est précisément cette lacune qui est critique.

Le règlement européen sur l’IA (AI Act) classe les systèmes selon leur niveau de risque. Les applications à haut risque – décisions de crédit, outils RH, infrastructures critiques – doivent fournir une documentation de transparence, faire l’objet de tests réguliers et être supervisées par un humain. Cela ressemble à une exigence de conformité. Mais c’est d’abord une question d’ingénierie : qui a la maîtrise de ce qui est décidé – et qui peut le reconstituer ?

37 %

des CIO affirment avoir une visibilité complète sur tous les outils d’IA utilisés dans leur organisation.

Source : Rapport CIO Logicalis 2026

Trois points où la gouvernance échoue structurellement

Le premier problème est celui du Shadow AI. Les employés utilisent des outils d’intelligence artificielle via des extensions de navigateur, des comptes SaaS ou des accès API qui n’apparaissent jamais dans les achats informatiques. Ce n’est pas de la mauvaise volonté, c’est de l’efficacité. Lorsque ces outils prennent des décisions ou fournissent des bases décisionnelles, ils n’existent pourtant pas aux yeux de la gouvernance.

Trois questions permettent d’évaluer le risque : existe-t-il des contenus générés par l’IA qui s’intègrent à des processus métiers documentés sans être identifiés comme tels ? Les accès aux outils d’IA sont-ils facturés via des comptes personnels afin d’éviter les circuits d’achat informatique ? L’équipe IT a-t-elle découvert au cours des six derniers mois un outil d’IA dont elle ignorait l’existence ? Une seule réponse par « oui » suffit : la gouvernance intervient alors structurellement trop tard.

Le deuxième problème réside dans la confusion entre explicabilité et traçabilité. Les méthodes d’explicabilité comme SHAP ou LIME permettent de comprendre pourquoi un modèle a pris une décision dans un cas précis. C’est utile, mais ce n’est pas un audit-trail. Un audit-trail doit documenter : quel modèle, quelle version, quelles données, quel horodatage, et qui a utilisé la décision ? En pratique, les DSI mettent en œuvre l’XAI et croient ainsi avoir résolu la question de l’explicabilité.

L’explicabilité est une fonctionnalité. La traçabilité est une exigence. Ces deux notions sont trop souvent confondues dans le cadre de la gouvernance.

Le troisième problème survient plus tard, mais frappe plus fort : le verrouillage fournisseur (vendor lock-in) sur les modèles d’IA. Celui qui affine un modèle fondamental (foundation model) d’un fournisseur cloud se retrouve avec des poids propriétaires sur une infrastructure propriétaire. Changer de fournisseur implique l’exportation des données, un nouvel entraînement, une nouvelle validation et une recertification. Pour les systèmes à haut risque, cela prend généralement entre six et dix-huit mois. Ce n’est pas un problème en phase pilote. Cela devient critique si le fournisseur modifie ses conditions ou ne répond plus aux exigences de conformité.

Ce que prévoit le règlement européen sur l’IA – et ce qu’il ne prévoit pas

Le règlement sur l’IA impose aux systèmes à haut risque : une documentation technique, un système de gestion des risques, la documentation des jeux de données, la journalisation, une supervision humaine et des métriques de précision. C’est le cadre réglementaire minimal.

Ce que le règlement n’apporte pas : un cadre de gouvernance pour l’organisation elle-même. Qui, en interne, est responsable d’un système à haut risque ? Quel processus décide si un nouvel outil d’IA est à haut risque ? Que se passe-t-il lorsqu’un système est utilisé pour une nouvelle application qui est ultérieurement classée comme à haut risque ? Chaque organisation doit répondre seule à ces questions. Le règlement sur l’IA est une barrière d’entrée, pas un cadre complet.

Ce qui aide structurellement

Un inventaire des usages d’IA avec classification des cas d’usage, mis à jour au moins trimestriellement
Une responsabilité claire : un nom par système, pas un département
Un journal de décision sur les versions de modèles, avec date de déploiement et contexte d’utilisation
Des vérifications régulières de dérive par rapport à un seuil de précision défini
Des clauses contractuelles garantissant la portabilité en cas de décision critique avec un fournisseur

Ce qui relève du théâtre de la gouvernance

Un comité d’éthique sur l’IA sans pouvoir de décision sur les déploiements concrets
Une autorisation de cas d’usage sans vérification technique de l’architecture réelle
Un tableau de bord XAI ouvert uniquement en cas de réclamation
Une politique IA sans processus défini pour traiter les cas de Shadow AI
Des évaluations de risque ponctuelles sans intervalle de répétition fixé

Trois questions avant toute mise en œuvre d’une IA autonome

Première question : Quelles décisions le système prend-il – et quelles en sont les conséquences ? Pas : « Quel problème résout-il ? », mais : Que se passe-t-il si le système se trompe ? Qui assume les conséquences – sur le plan juridique, opérationnel, réputationnel ?

Deuxième question : Qui peut interrompre la décision ? Tout système autonome doit disposer d’un parcours d’escalade clairement défini. En l’absence de tel parcours, la décision sera prise jusqu’à ce qu’un incident grave se produise.

Troisième question : Combien de temps faudrait-il pour remplacer le système ? Répondez à cette question avant la mise en production. Une fois le système déployé, la réponse n’a plus d’importance.

Les registres de risques pour les IA autonomes sont utiles à condition que quelqu’un les consulte réellement, et que les questions qu’ils contiennent portent sur des systèmes concrets, et non sur des catégories abstraites. Le NIST AI Risk Management Framework offre ici une entrée pratique qui va au-delà du niveau minimum exigé par l’AI Act.

Foire aux questions

Qu’est-ce qu’un système d’IA « autonome » au sens de la gouvernance ?

Un système est considéré comme autonome lorsqu’il prend des décisions ou déclenche des actions sans qu’un humain n’examine chaque cas individuel. Le critère n’est pas la technologie, mais le processus : si un employé reprend systématiquement la décision du système sans la vérifier sur le fond, le système fonctionne de facto de manière autonome.

Quelles applications d’IA sont classées comme à haut risque selon l’AI Act de l’UE ?

L’annexe III de l’AI Act énumère huit domaines : identification biométrique, infrastructures critiques, éducation, emploi, services essentiels, forces de l’ordre, gestion des frontières, justice. Dans ces domaines, c’est l’usage concret qui détermine le classement. La plupart des entreprises sous-estiment le nombre de leurs outils internes potentiellement concernés.

Quelle est la différence entre l’XAI et une piste d’audit (audit trail) ?

Les méthodes XAI (SHAP, LIME, contre-factuels) expliquent pourquoi un modèle a pris telle décision dans un cas précis. Une piste d’audit, en revanche, documente l’intégralité du processus décisionnel : version du modèle, données d’entrée, horodatage, utilisateur. Les deux sont nécessaires – l’un ne remplace pas l’autre. Les DSI qui n’implémentent que l’XAI ne disposent pas d’une traçabilité conforme aux exigences de conformité.

Comment gérer l’IA fantôme (Shadow AI) au sein de mon organisation ?

Commencez par inventorier plutôt que sanctionner. Les employés utilisent des outils d’IA par souci d’efficacité, pas pour saboter les politiques informatiques. Une approche pragmatique combine des processus réguliers d’auto-déclaration (déclaration trimestrielle des outils utilisés), une surveillance via extensions de navigateur, et une communication claire sur les outils autorisés. Les politiques de tolérance zéro, sans alternative, poussent l’IA fantôme encore plus loin dans l’ombre.

Quelles sont les étapes concrètes recommandées pour mettre en place un cadre de gouvernance de l’IA ?

Quatre étapes, dans cet ordre : (1) Établir un inventaire des IA – tous les systèmes utilisés, leurs responsables, leurs finalités. (2) Classer les risques selon l’AI Act – quels systèmes relèvent des catégories à haut risque ? (3) Désigner des responsables – un nom par système, pas « le service informatique ». (4) Mettre en place des cycles de revue – mise à jour trimestrielle de l’inventaire, évaluation annuelle des risques, revue immédiate en cas de modification du système ou de son usage.