L’essentiel
- L’explicabilité, c’est la capacité à dire, dans des termes qu’une personne peut comprendre, pourquoi un système d’IA a produit telle sortie. Elle ne se confond pas avec l’interprétabilité, qui porte sur le fonctionnement interne du modèle.
- Avec le règlement européen sur l’IA, l’explicabilité passe de la bonne pratique à l’obligation juridique : l’article 13 impose aux systèmes à haut risque une transparence suffisante, et l’article 86 ouvre aux personnes concernées un droit à l’explication à compter du 2 août 2026.
- Le cadre de gestion des risques du NIST range l’IA explicable et interprétable parmi ses sept caractéristiques d’une IA digne de confiance, et la norme ISO/IEC 42001 attend que l’explicabilité soit gérée et documentée.
- Un programme de gouvernance doit produire plusieurs formes d’explication, couvrant la justification, la responsabilité, les données, l’équité, la sécurité et l’impact, et non un seul relevé technique.
- L’explicabilité est auditable. Le vrai travail consiste à documenter quelles explications vous fournissez, à qui, et comment vous les assurez tout au long du cycle de vie de l’IA.
Ce que recouvre l’explicabilité en IA (et ce qu’elle n’est pas)
L’explicabilité désigne la faculté de décrire le comportement d’un système d’IA dans une langue accessible à un être humain. La distinction la plus utile pour s’y retrouver revient sans cesse dans les pages qui dominent la recherche. Comme le formule Splunk, l’explicabilité répond à la question du pourquoi un modèle a produit un résultat, tandis que l’interprétabilité répond au comment le modèle fonctionne en interne. Les deux notions sont liées, on les confond souvent, mais elles ne sont pas interchangeables. Une seconde distinction affine le tableau. L’Alan Turing Institute sépare la transparence, le fait d’être ouvert sur la manière dont un système est utilisé et sur les raisons de son usage, de l’explicabilité, le fait de pouvoir donner des raisons claires et accessibles pour une sortie précise. La transparence est une posture. L’explicabilité est un livrable : un récit qu’un public identifié peut réellement exploiter. Il faut aussi distinguer les explications globales des explications locales. Une explication globale décrit le comportement d’un modèle en général, sur l’ensemble de son espace d’entrée. Une explication locale rend compte d’une décision précise, le prêt refusé ou la transaction signalée. Les questions de conformité sont presque toujours locales, parce que la personne concernée veut comprendre son cas, et non le modèle dans l’abstrait. Une plateforme de gouvernance de l’IA doit prendre en charge les deux, sans jamais les confondre.
Explicabilité et interprétabilité
S’il ne fallait retenir qu’une distinction de ce guide, ce serait celle-ci, car la demande de recherche à son sujet ne faiblit pas et l’enjeu réglementaire en dépend. L’interprétabilité est une propriété du modèle. Une régression linéaire ou un arbre de décision court sont interprétables parce qu’une personne peut suivre le chemin de l’entrée vers la sortie en lisant le modèle lui-même. L’explicabilité est plus large. C’est l’aptitude à produire un récit compréhensible d’un résultat, même lorsque le modèle est un réseau profond dont nul ne peut lire directement les poids internes. Le cadre de gestion des risques liés à l’IA du NIST propose une formulation que les équipes de gouvernance peuvent reprendre : l’explicabilité concerne les mécanismes qui sous-tendent le fonctionnement d’un système d’IA, tandis que l’interprétabilité concerne le sens de sa sortie au regard de sa finalité. Dans la pratique, on traite souvent l’interprétabilité comme un sous-ensemble de l’explicabilité. On peut disposer d’un récit explicable pour un modèle non interprétable, et c’est précisément la situation de la plupart des entreprises.
Pourquoi l’explicabilité devient une exigence de conformité
Pendant des années, l’explicabilité a vécu dans les articles de recherche et les manifestes sur l’IA responsable. Elle vit désormais dans la loi et dans des normes certifiables, ce qui change qui doit s’en préoccuper et pourquoi. Le cadre du NIST nomme l’IA explicable et interprétable comme l’une des sept caractéristiques d’une IA digne de confiance, aux côtés de la validité et la fiabilité, la sûreté, la sécurité et la résilience, la responsabilité et la transparence, la protection de la vie privée, et l’équité avec maîtrise des biais préjudiciables. Le NIST est volontaire, mais il est devenu le langage commun du risque lié à l’IA, et la plupart des programmes d’entreprise y rattachent leurs contrôles. L’ISO/IEC 42001, première norme certifiable de système de management de l’IA, transforme ce langage en quelque chose d’auditable. L’organisation qui vise la certification doit démontrer que l’explicabilité est gouvernée : qu’elle est prise en compte au moment de choisir les modèles, que des explications sont produites là où les parties prenantes en ont besoin, et que la preuve existe pour l’attester. Le NIST dit quoi traiter ; l’ISO 42001 fournit un système de management pour prouver que vous l’avez traité. Les deux sont complémentaires, et de nombreux programmes font tourner le cadre à l’intérieur de la norme. Le basculement décisif est juridique. Le règlement sur l’IA fait d’un degré suffisant d’explication une obligation contraignante pour les systèmes à haut risque, et il offre aux individus un moyen d’en réclamer une. On est loin d’une simple liste de bonnes pratiques, et c’est la raison pour laquelle l’explicabilité relève désormais d’une feuille de route de conformité plutôt que d’un seul arriéré de travail pour les data scientists.
Ce qu’exige le règlement sur l’IA, par rôle et par niveau de risque
Le règlement n’impose pas une obligation uniforme. Il attribue des devoirs distincts aux fournisseurs et aux déployeurs, et il les module selon le niveau de risque. Bien établir cette correspondance, c’est la différence entre un programme défendable et un exercice de paperasse.
Fournisseurs de systèmes à haut risque (article 13)
L’obligation centrale pèse sur celui qui met un système à haut risque sur le marché. L’article 13, paragraphe 1 dispose que « les systèmes d’IA à haut risque sont conçus et développés de manière à garantir que leur fonctionnement est suffisamment transparent pour permettre aux déployeurs d’interpréter la sortie d’un système et de l’utiliser de manière appropriée ». Le verbe interpréter est délibéré : le déployeur doit pouvoir donner un sens à ce que le système indique. Ce devoir passe surtout par la notice d’utilisation. L’article 13 exige qu’elle soit concise, complète, exacte et claire, et son paragraphe 3 énumère ce qu’elle doit contenir, dont les caractéristiques du système, son niveau d’exactitude, ses limites connues et ses capacités techniques à expliquer sa sortie. L’explication n’est donc pas un supplément ; elle fait partie de la documentation que le fournisseur livre. Elle soutient aussi l’article 14 sur le contrôle humain, car une personne ne peut pas réellement superviser un système dont elle ne sait pas interpréter la sortie.
Déployeurs et droit à l’explication (article 86)
Le règlement atteint aussi l’organisation qui utilise le système. L’article 86 prévoit que toute personne concernée faisant l’objet d’une décision prise par un déployeur sur la base de la sortie d’un système à haut risque énuméré à l’annexe III, lorsque cette décision produit des effets juridiques ou l’affecte de manière significative et défavorable pour sa santé, sa sécurité ou ses droits fondamentaux, « a le droit d’obtenir du déployeur des explications claires et utiles sur le rôle du système d’IA dans la procédure décisionnelle et sur les principaux éléments de la décision prise ». C’est un droit détenu par les individus et dû par les déployeurs, et il devient applicable le 2 août 2026. Une banque, un assureur ou un employeur qui exploite un système à haut risque doit pouvoir expliquer une décision défavorable précise à la personne qui la subit, en termes clairs, sur demande. C’est une explication locale, à la demande, avec une échéance.
La transparence de l’article 50 n’est pas l’explicabilité
Un piège mérite d’être nommé. L’article 50 impose des devoirs de transparence à certains systèmes à risque limité, par exemple signaler à une personne qu’elle dialogue avec un agent conversationnel ou marquer les contenus de synthèse. Ce sont des obligations de divulgation, et elles ne valent pas explication d’une décision. Un système peut satisfaire la divulgation de l’article 50 sans rien devoir au titre des articles 13 ou 86, et inversement. Traitez les deux comme des lignes distinctes de votre programme de conformité, pour qu’une bannière d’information ne soit jamais prise pour une explication.
Les six types d’explication qu’un programme de gouvernance doit produire
La plupart des contenus concurrents s’arrêtent à une seule explication technique, un graphique d’importance des variables, et considèrent la tâche accomplie. Un programme de gouvernance en demande davantage, car des publics différents ont besoin de récits différents d’une même décision. L’Alan Turing Institute propose six types d’explication qui, réunis, donnent une image complète, et qui recoupent assez bien ce que réclament les régulateurs et les personnes concernées.
- La justification : les raisons d’un résultat, exprimées en termes accessibles plutôt qu’à travers les rouages du modèle.
- La responsabilité : qui répond du système et comment une personne peut contester une décision ou en demander le réexamen.
- Les données : quelles données ont été utilisées, d’où elles viennent et comment elles ont pesé sur le résultat.
- L’équité : les mesures prises pour garantir une décision non discriminatoire, ce qui relie directement l’explicabilité à la maîtrise des biais.
- La sécurité : l’exactitude, la fiabilité, la sécurité et la robustesse derrière la sortie.
- L’impact : l’effet de la décision sur l’individu et sur la société.
La même source structure la discipline autour de quatre maximes : être transparent, être responsable, tenir compte du contexte, et réfléchir aux impacts. Ce sont des engagements opérationnels plutôt que des slogans. Ils invitent une équipe à adapter chaque explication à son public, à attribuer une responsabilité claire, et à peser les conséquences du fait de donner, ou de refuser, une explication. Un régulateur qui examine une décision défavorable se contentera rarement d’une justification ; il voudra aussi les récits de responsabilité, de données et d’équité.
Techniques d’explicabilité et arbitrages de gouvernance
Les explications viennent de quelque part, et la méthode retenue emporte des conséquences de gouvernance. Il existe deux grandes familles. L’explicabilité intrinsèque provient de l’usage d’un modèle interprétable par construction, comme un modèle linéaire, un modèle additif généralisé ou un arbre de décision peu profond. L’explication est le modèle lui-même. L’arbitrage tient au fait que ces modèles peuvent être moins performants sur des problèmes complexes. L’explicabilité a posteriori se greffe sur un modèle opaque. Des techniques comme SHAP et LIME approchent les variables qui ont pesé sur une prédiction donnée. Les explications contrefactuelles décrivent le plus petit changement qui aurait modifié le résultat, souvent le récit le plus intuitif pour une personne concernée, car il répond à la question de ce qui aurait dû être différent. Les modèles de substitution et les méthodes d’importance des variables offrent une vue globale du comportement. L’arbitrage majeur oppose la performance prédictive à la facilité d’explication. Le réflexe consistant à choisir le modèle le plus exact puis à y greffer un explicateur se comprend, mais les explications a posteriori sont des approximations qui peuvent induire en erreur si on les prend pour la vérité. Le choix de gouvernance n’est pas de savoir quelle technique est la meilleure dans l’abstrait, mais laquelle donne au public en face de vous, un régulateur, un auditeur ou une personne concernée, un récit fiable pour cette décision. Consignez la méthode, ses limites et la raison de son choix.
Faire de l’explicabilité un contrôle auditable
L’écart entre un principe d’IA responsable et un audit réussi, c’est la documentation. L’explicabilité devient un contrôle quand vous pouvez montrer, pour un système donné, quelles explications vous fournissez, à qui, par quelle méthode, et qui a validé. L’Alan Turing Institute associe son principe d’explicabilité à un modèle de gestion de l’assurance d’explicabilité, un outil itératif pour planifier, mettre en oeuvre et documenter les activités d’explication sur tout le cycle de vie, afin que la clarification des sorties aux parties prenantes concernées soit consignée plutôt qu’improvisée. La structure compte plus que le gabarit précis. Un contrôle viable comporte quatre volets : un relevé des types d’explication que chaque système doit fournir et à quels publics ; la technique employée pour produire chacun ; la preuve que l’explication était bel et bien disponible au bon moment ; et un responsable nommé qui la réexamine à mesure que le modèle évolue. C’est là que l’explicabilité cesse d’être une affaire de data science pour devenir un programme. Rattacher chaque système à haut risque à ses obligations au titre des articles 13 et 86, y joindre les artefacts d’explication et tenir la preuve à jour au fil des réentraînements, voilà exactement le travail qu’une plateforme de gouvernance de l’IA est faite pour porter. Réalisé une fois, à la main, c’est un projet. Réalisé en continu, sur tout un portefeuille, cela exige un système de référence.
Questions fréquentes
Quelle est la différence entre explicabilité et interprétabilité ? L’interprétabilité est une propriété du modèle : un modèle simple, dont une personne peut lire la logique directement, est interprétable. L’explicabilité est l’aptitude plus large à donner un récit compréhensible d’un résultat, même pour un modèle complexe que nul ne peut lire directement. Un raccourci courant dit que l’interprétabilité répond au comment fonctionne le modèle, tandis que l’explicabilité répond au pourquoi telle sortie est survenue. En gouvernance, vous pouvez devoir une explication pour un modèle qui n’est lui-même pas interprétable, ce qui est le cas de la plupart des entreprises. Le droit à l’explication du règlement sur l’IA est-il déjà en vigueur ? Pas encore. L’article 86, le droit des personnes concernées d’obtenir du déployeur des explications claires et utiles sur une décision à haut risque, devient applicable le 2 août 2026. Les obligations de transparence de l’article 13 pour les fournisseurs de systèmes à haut risque suivent le calendrier prévu pour ces exigences. Les organisations qui exploitent des systèmes à haut risque ont intérêt à préparer dès maintenant la capacité d’explication, plutôt qu’à attendre l’échéance. L’explicabilité s’applique-t-elle à tout système d’IA ? Non. Les obligations contraignantes du règlement visent les systèmes à haut risque. Les systèmes à risque limité portent des devoirs de divulgation au titre de l’article 50, comme indiquer qu’un contenu est généré par IA, ce qui diffère de l’explication d’une décision. Les systèmes à risque minimal ne portent aucun devoir d’explicabilité spécifique au titre du règlement. Cela dit, le NIST et l’ISO 42001 traitent l’explicabilité comme une caractéristique générale d’une IA digne de confiance, de sorte que la plupart des programmes matures en appliquent une version proportionnée à tout le portefeuille. Qu’est-ce qu’une bonne explication aux yeux d’un régulateur ? Un simple graphique d’importance des variables suffit rarement. Un régulateur qui examine une décision défavorable veut en général plusieurs récits réunis : la justification du résultat, qui en est responsable et comment le contester, quelles données ont servi, les mesures d’équité prises et la base de sécurité de la sortie. Adapter l’explication au public et la documenter compte autant que la méthode technique sous-jacente. Peut-on se contenter de SHAP ou LIME et appeler cela de l’explicabilité ? Ces techniques sont utiles, mais ce sont des approximations a posteriori d’un modèle opaque, pas l’explicabilité dans son ensemble. Elles peuvent induire en erreur si on les prend pour une vérité exacte, et elles répondent à une question technique, non aux questions de gouvernance sur la responsabilité, les données et l’impact. Utilisez-les comme une entrée parmi d’autres, consignez leurs limites, et associez-les à la documentation et à la responsabilité qui rendent l’explicabilité auditable. Quel est le lien entre explicabilité et contrôle humain ? Il est étroit. L’article 14 du règlement exige un contrôle humain effectif des systèmes à haut risque, et une personne ne peut pas réellement superviser un système dont elle ne sait pas interpréter la sortie. L’explicabilité est la condition préalable du contrôle : sans récit compréhensible du pourquoi le système a produit un résultat, l’humain dans la boucle approuve des sorties à l’aveugle.
Conclusion
L’explicabilité a franchi le pas du principe vers l’obligation. Il ne suffit plus de dire qu’un modèle est exact ; au titre du règlement sur l’IA, du NIST et de l’ISO 42001, une organisation doit pouvoir dire pourquoi un système est parvenu à une décision, en des termes que le bon public peut exploiter, et le prouver. Les équipes qui abordent cela comme un problème de documentation et de gouvernance, et non comme un tour technique ponctuel, seront prêtes pour l’article 86 en 2026 et pour les audits qui suivront. Le premier pas concret est modeste : recensez vos systèmes à haut risque, décidez des explications que chacun doit fournir et à qui, et commencez à conserver la preuve. Découvrez comment la plateforme AI Sigil en fait un contrôle reproductible.