A propos de Andrea Ferrario/Joshua Hatherley, Update Opacity: Epistemic Accessibility and Governance Under AI System Change, 27 avril 2026 (https://arxiv.org/abs/2606.00037):

L’article d’Andrea Ferrario et Joshua Hatherley porte sur le problème de  l’« opacité des mises à jour » ou « update opacity ». Il s’agit de la situation dans laquelle un système d’IA, après modification de son modèle ou d’un élément qui influence ce modèle, donne une réponse différente pour une même entrée, sans que l’utilisateur puisse comprendre de manière suffisante pourquoi ce changement s’est produit ni comment il doit adapter sa confiance dans le système.

Les auteurs ne traitent donc pas seulement de l’opacité classique des modèles d’apprentissage automatique, c’est-à-dire de la difficulté à expliquer une décision algorithmique à un moment donné. Leur sujet est temporel: comment un système change au fil du temps, comment ces changements affectent l’usage humain, et comment les rendre compréhensibles sans noyer les utilisateurs sous des informations inutiles.

Le point de départ est que les systèmes d’IA déployés ne restent pas stables. Les modèles sont régulièrement recalibrés, réentraînés, adaptés à de nouvelles données, corrigés après détection d’une dérive statistique, ou modifiés en raison de changements d’infrastructure, d’interface, de pipeline de données ou de procédures de supervision humaine. Ces mises à jour sont souvent nécessaires. Dans des environnements changeants, ne jamais mettre à jour un modèle peut entraîner une dégradation rapide de ses performances et une perte d’adéquation avec la réalité. Mais les mises à jour créent un autre risque: l’utilisateur avait appris à se fier au système d’une certaine manière, et cette compréhension pratique peut devenir obsolète sans qu’il s’en rende compte.

Les auteurs insistent sur cette idée de « calibration » humaine. Un médecin, un analyste de crédit, un juge, un agent administratif ou un professionnel de la conformité apprend progressivement comment un outil d’IA se comporte, dans quels cas il est fiable, quand ses alertes doivent être prises au sérieux, quand elles doivent être relativisées, et comment ses recommandations s’intègrent dans le raisonnement professionnel. Cette connaissance n’est pas seulement théorique. Elle résulte de l’usage répété du système dans un contexte institutionnel concret. Si le système change, mais que l’utilisateur continue à l’interpréter selon son ancien comportement, la confiance peut devenir mal fondée. L’opacité des mises à jour menace donc la fiabilité pratique de l’usage humain, même si le système demeure techniquement performant.

L’article propose de comprendre ce phénomène comme un problème d’accessibilité épistémique diachronique. En termes simples, les changements pertinents du système doivent rester accessibles aux humains dans une forme qui leur permette de comprendre, d’ajuster leur confiance et d’agir correctement, compte tenu de leur rôle, de leur niveau d’expertise, de leur temps disponible et de leurs obligations institutionnelles. L’information peut manquer pour plusieurs raisons. Elle peut ne pas avoir été enregistrée correctement. Elle peut exister mais être dispersée dans des documents techniques, inaccessible au moment de la décision ou réservée à d’autres services. Elle peut aussi être disponible mais trop détaillée, trop abstraite ou trop technique pour être utile à l’utilisateur concerné. La transparence n’est donc pas seulement une question d’existence de l’information. Elle suppose que l’information soit utilisable.

Les auteurs distinguent ensuite ce problème de l’explicabilité classique de l’IA. Les méthodes d’explication cherchent souvent à rendre intelligible une décision individuelle prise par un modèle à un moment donné. Certaines approches traitent aussi de la perte de validité des explications ou des recours lorsque le modèle change. Mais l’opacité des mises à jour vise autre chose: la relation entre plusieurs versions d’un système et les effets de cette évolution sur la possibilité, pour les utilisateurs, de maintenir une confiance correctement ajustée. La question n’est pas seulement « pourquoi le modèle a-t-il donné cette réponse ? », mais « qu’est-ce qui a changé depuis la version précédente, pourquoi ce changement compte-t-il pour moi, et comment dois-je modifier mon usage du système ? ».

Cette approche conduit les auteurs à formuler le problème comme un problème de gouvernance. Il ne suffit pas de dire qu’il faut plus de transparence. Tout révéler serait contre-productif: les systèmes d’IA subissent de nombreux ajustements, dont certains sont insignifiants pour l’utilisateur. Une obligation de divulguer chaque modification produirait un bruit documentaire qui affaiblirait la compréhension au lieu de l’améliorer. Mais ne rien divulguer est également inadmissible, car des changements silencieux peuvent affecter la confiance, la sécurité, la responsabilité et l’audit. L’enjeu devient donc de déterminer quels changements doivent être portés à la connaissance de quels acteurs, à quel moment, et sous quelle forme.

Pour construire leur réponse, les auteurs combinent deux cultures de gouvernance. La première est celle de l’AI Act européen (RIA). Même si l’article s’adresse plus largement à la gouvernance de l’IA, les auteurs utilisent l’AI Act comme modèle parce qu’il impose, pour les systèmes à haut risque, une logique de cycle de vie: évaluation de conformité avant mise sur le marché, documentation technique, gestion des risques, gouvernance des données, transparence envers les déployeurs, supervision humaine, robustesse, cybersécurité, traçabilité et surveillance après mise sur le marché. L’AI Act permet ainsi de définir un périmètre réglementaire du changement pertinent. Il distingue les modifications qui restent dans l’enveloppe initialement évaluée et celles qui constituent une modification substantielle, par exemple parce qu’elles changent la destination du système ou affectent sa conformité aux exigences applicables.

Cette logique est utile, mais insuffisante. L’AI Act permet de dire quand une modification est suffisamment importante pour déclencher de nouvelles obligations de conformité. Il fixe donc un seuil juridique ou réglementaire. Mais beaucoup de changements ne franchissent pas ce seuil tout en étant importants pour les utilisateurs. Un modèle peut rester dans son enveloppe de conformité, ne pas changer de destination, ne pas perdre son statut réglementaire, et pourtant modifier certaines recommandations, certains sous-groupes de performance ou certaines pratiques de travail. L’AI Act indique ce qui menace la conformité du système, mais pas toujours ce qui doit être rendu compréhensible aux utilisateurs pour maintenir une confiance correcte.

La seconde culture mobilisée est celle du MLOps, c’est-à-dire l’ensemble des pratiques techniques permettant de concevoir, déployer, surveiller, mettre à jour et maintenir des systèmes d’apprentissage automatique. Le MLOps repose notamment sur l’automatisation, la reproductibilité, le versionnement, la surveillance continue, les registres de modèles, les journaux de métadonnées, les tests, les alertes et les boucles de retour. Il est particulièrement utile pour détecter les dérives: les données reçues après déploiement peuvent s’écarter des données d’entraînement, les distributions peuvent changer, les relations entre variables peuvent évoluer, et le modèle peut devoir être réentraîné ou recalibré. Les pratiques MLOps fournissent donc l’infrastructure opérationnelle pour suivre les changements dans le temps.

Mais le MLOps ne résout pas non plus le problème à lui seul. Il est conçu d’abord pour les ingénieurs et les équipes techniques. Il permet de mesurer, comparer, enregistrer et déclencher des actions, comme une alerte, un réentraînement, un retour en arrière ou une validation supplémentaire. Il ne dit pas, en revanche, quelles informations sont significatives pour un médecin, un responsable de risques, un auditeur, un avocat, un agent de conformité ou un utilisateur final. Les artefacts produits par le MLOps peuvent être parfaitement adéquats techniquement tout en étant inutilisables pour les personnes qui doivent prendre des décisions opérationnelles. Les auteurs résument ainsi la complémentarité des deux approches: l’AI Act donne un cadre normatif pour dire quels changements comptent au regard de la conformité et de la fiabilité globale du système; le MLOps donne les outils pour observer et comparer ces changements; mais il manque encore un mécanisme pour déterminer quels changements internes à l’enveloppe admissible doivent être communiqués aux utilisateurs.

Le cœur de la proposition des auteurs repose sur la notion de « profil de fiabilité digne de confiance » du système, ou trustworthiness profile. Il ne faut pas regarder uniquement la performance du modèle, par exemple son taux d’exactitude. Un système d’IA digne de confiance dépend de plusieurs dimensions: performance prédictive, robustesse, qualité et intégrité des données, traçabilité, cybersécurité, transparence, efficacité de la supervision humaine, stabilité des sous-groupes, qualité de l’interface ou encore respect du contexte d’usage. Ces dimensions doivent être définies à l’avance, mesurées selon des protocoles documentés, et suivies dans le temps. Le système n’est pas seulement un modèle mathématique: c’est un ensemble socio-technique dont les modifications peuvent affecter la manière dont les humains doivent interpréter ses sorties.

Les auteurs introduisent ensuite l’idée de niveaux de trustworthiness. Les mesures du profil sont agrégées ou interprétées de manière à situer le système dans un niveau discret: par exemple un niveau pleinement admissible, un niveau nécessitant vigilance, ou un niveau imposant escalade, correction ou réévaluation. Cette logique par niveaux évite une gouvernance trop instable, dans laquelle la moindre variation numérique déclencherait une réaction. Tant que le système reste sur le même plateau de confiance, il demeure dans son enveloppe admissible. Si une limite est franchie, il y a changement de niveau et il faut envisager une action plus lourde: réévaluation, correction, retrait ou nouvelle conformité.

Toutefois, les auteurs soulignent que l’essentiel de l’opacité des mises à jour se situe précisément à l’intérieur de ces plateaux. Un système peut rester dans le même niveau général, donc continuer à être admissible, tout en changeant assez pour affecter l’usage humain. C’est pourquoi ils proposent un mécanisme de divulgation fondé sur des seuils. On compare l’état actuel du profil de trustworthiness à l’état de référence, par exemple celui du déploiement initial ou de la dernière mise à jour significative. Si la distance entre les deux états dépasse un seuil prédéfini, même sans changement de niveau, une divulgation doit être déclenchée. Ce seuil n’est pas un seuil de conformité, mais un seuil de matérialité épistémique: il indique que le changement est suffisamment important pour risquer de perturber la confiance, les attentes de travail ou la responsabilité.

L’exemple médical utilisé par les auteurs rend cette proposition concrète. Ils imaginent un système d’aide au triage des AVC aux urgences, qui combine images médicales, données cliniques et autres variables pour recommander de traiter sur place, transférer vers un centre spécialisé, ou surveiller et réévaluer. Dans un tel contexte, le temps manque. Le médecin ne peut pas analyser l’historique technique du modèle. Il se fie à une compréhension accumulée du système. Supposons qu’après une mise à jour du firmware des scanners CT, le fournisseur réentraîne le modèle pour corriger une dérive. Les performances globales s’améliorent légèrement, le système reste dans son enveloppe de conformité et aucun changement substantiel n’est déclenché. Pourtant, le comportement change pour certains patients âgés, les recommandations de transfert deviennent plus fréquentes pour certains profils, et des cas limites basculent plus souvent d’une catégorie à l’autre. Pour les cliniciens, ce changement est matériel, même s’il ne remet pas en cause la conformité globale du système.

Dans ce cas, selon les auteurs, la divulgation ne doit pas prendre la forme d’un long rapport technique déposé quelque part dans un répertoire. Elle doit être intégrée au flux de travail. L’interface pourrait afficher une indication brève signalant que le modèle a été mis à jour, que les recommandations de transfert pour les patients de plus de 75 ans peuvent différer du comportement antérieur, et qu’un résumé détaillé est disponible. Le clinicien aurait besoin d’une information courte, située au point d’usage, centrée sur l’impact pratique. Le responsable de gouvernance ou l’auditeur aurait besoin d’un dossier plus complet: métadonnées de mise à jour, justification, résultats de validation, effets par sous-groupe, preuves de surveillance post-marché et documentation de conformité. La même information ne doit donc pas être donnée de la même manière à tous.

Cette dimension est centrale pour les auteurs. La bonne transparence n’est pas maximale, mais sélective. Elle doit communiquer ce qui est pertinent pour le rôle de l’utilisateur. Les utilisateurs de première ligne ont besoin d’informations brèves, opérationnelles et intégrées dans leur environnement de décision. Les responsables internes ont besoin de synthèses structurées permettant d’organiser la surveillance et les mesures correctrices. Les auditeurs, autorités et personnes chargées de la responsabilité ont besoin d’une documentation complète, traçable et reliée aux preuves techniques. Ces couches d’information doivent être liées, mais non confondues. Un médecin ne doit pas être submergé par des annexes techniques; un auditeur ne doit pas se contenter d’une bannière vague.

L’article rattache enfin ce mécanisme à la responsabilité. Dans l’exemple médical, si un patient est mal trié quelques jours après une mise à jour, le fournisseur pourrait démontrer que le système était toujours dans son enveloppe de conformité, et l’hôpital pourrait démontrer que le personnel avait été formé lors du déploiement. Mais si le médecin n’avait pas reçu d’information exploitable sur le changement de comportement du système, il subsiste un vide de responsabilité. Qui devait rendre le changement compréhensible ? Le mécanisme proposé vise à fermer cette lacune. Lorsque le seuil de matérialité est franchi, le fournisseur doit divulguer, le déployeur doit recevoir et reconnaître l’information, et l’utilisateur de première ligne doit être informé dans une forme adaptée à son rôle. La responsabilité épistémique devient ainsi traçable.

La conclusion de l’article est que la gouvernance des mises à jour d’IA ne se réduit ni à la maintenance technique ni à la conformité juridique. Elle consiste aussi à préserver les conditions dans lesquelles un système changeant reste suffisamment intelligible pour être utilisé correctement. Les auteurs proposent une architecture pragmatique: définir à l’avance les dimensions pertinentes de trustworthiness, les mesurer dans le temps, distinguer les changements qui sortent de l’enveloppe admissible de ceux qui restent dans cette enveloppe, puis déclencher une divulgation lorsque ces derniers deviennent matériellement pertinents pour les utilisateurs. Le mérite principal de l’approche est d’éviter deux excès: l’illusion d’une transparence totale, qui produirait surtout de la surcharge, et l’opacité silencieuse, qui laisserait les utilisateurs se fier à un système dont le comportement a changé sans qu’ils puissent ajuster leur jugement.

Me Philippe Ehrenström, avocat, LLM, CAS en Droit et Intelligence artificielle, CAS en Protection des données