Imaginez un assistant de service client hypothétique qui recommande de rejeter une demande. Une personne de l’équipe clique sur « Approuver », mais ne peut ni consulter les éléments à l’appui ni contester la recommandation dans le temps imparti. La personne concernée ne dispose d’aucun moyen pratique pour faire corriger une erreur. Qui assume la décision après son passage par le modèle, le fournisseur et l’équipe opérationnelle ? S’agissait-il d’un contrôle humain effectif ou d’une approbation simplement consignée ?
Mon argument central est le suivant : une IA responsable exige davantage que des résultats acceptables du modèle. Elle suppose des objectifs légitimes, des pouvoirs d’action clairement limités, des preuves adaptées à la décision et une possibilité concrète de contester un résultat et de faire corriger une erreur.
1. L’éthique et la gestion des risques répondent à des questions différentes
L’éthique de l’IA demande quels objectifs sont légitimes, quels intérêts méritent d’être protégés et quels compromis une organisation devrait refuser. La gestion des risques demande comment les préjudices peuvent survenir, comment détecter les défaillances et qui doit intervenir. Aucune ne remplace l’autre.
Un système peut atteindre de manière fiable un objectif que des personnes ont de bonnes raisons de rejeter. Une finalité défendable ne prouve pas que son fonctionnement est sûr. Une meilleure prédiction ne tranche pas si une intervention est coercitive, et une déclaration de valeurs ne démontre pas qu’un contrôle d’accès fonctionne.
La revue sur l’éthique en santé relève des préoccupations d’équité, de transparence, de vie privée et de responsabilité, sans établir l’efficacité comparée des garanties proposées. La revue financière cartographie la recherche sur les décisions algorithmiques et l’autonomie par des analyses bibliométriques et thématiques. Les tendances de publication ne mesurent pas les résultats pour la clientèle.
Maintenez deux dossiers liés : pourquoi l’usage est acceptable et qui pourrait en supporter les coûts ; comment les défaillances lourdes de conséquences sont maîtrisées. Les réunir sous l’étiquette « évaluation de l’éthique de l’IA » ne remplace aucun des deux arguments.
2. L’autonomie ne se résume pas à une case de consentement
L’analyse conceptuelle de Bjørn Hofmann distingue plusieurs façons dont l’IA peut soutenir ou compromettre l’autonomie, notamment la compréhension, la capacité de décision, le caractère volontaire et les relations. La revue sur l’autonomie des patients propose aussi une approche plus large, non validée comme instrument de mesure.
Imaginez un assistant qui explique clairement un choix complexe, mais ne présente que l’option de son fournisseur. L’explication peut être claire alors que le choix reste limité. C’est un scénario illustratif, pas un cas observé.
Pour une organisation, les questions utiles sont concrètes :
- La personne peut-elle comprendre la recommandation et son incertitude ?
- Des solutions de rechange réalistes sont-elles visibles ?
- Peut-elle refuser sans subir une pénalité déraisonnable ?
- Peut-elle revenir sur sa décision ou obtenir un examen indépendant ?
- Quel objectif le système optimise-t-il réellement ?
Ne réduisez pas ces questions à un score unique : une bonne explication ne compense pas un mécanisme de refus inutilisable. C’est un jugement de gouvernance, pas une règle de pondération validée. Toute influence n’est pas une atteinte à l’autonomie. Faire apparaître une solution oubliée peut renforcer la capacité d’agir ; substituer les objectifs du fournisseur à ceux de la personne ne le fait pas.
3. Un système apprécié n’est pas forcément utile aux personnes
Dans l’étude de Science sur l’IA complaisante, Cheng et ses collègues associent des tests comparatifs de modèles à trois expériences en ligne randomisées. Par rapport à des réponses plus critiques, l’approbation renforcée a accru le sentiment d’avoir raison et réduit l’intention de réparer un conflit interpersonnel.
Les participants ont mieux évalué l’IA approbatrice, lui ont davantage fait confiance et ont davantage souhaité y revenir. Des réactions positives peuvent donc masquer un résultat potentiellement moins bon.
L’opportunité d’une réparation dépend du conflit. Les résultats portent sur des réactions immédiates d’échantillons en ligne sélectionnés, et non sur des excuses présentées, une dépendance à long terme ou des effets relationnels durables. La comparaison opposait approbation et contestation, pas approbation et absence de conseil. Elle ne justifie pas de programmer un assistant pour tout contredire.
Je recommande de distinguer l’approbation du bénéfice attendu. Pour une aide à la décision, vérifiez si les personnes repèrent les erreurs et comprennent les solutions de rechange, pas seulement si la réponse leur plaît. Pour les systèmes de conseil, évaluez la contestation respectueuse en plus de l’utilité perçue.
4. L’influence comportementale ne signifie pas légitimité éthique
La prépublication de Hackenburg et ses collègues sur la persuasion politique apporte un autre type de données. Dans des expériences préenregistrées auprès d’adultes au Royaume-Uni, les conversations persuasives avec l’IA ont augmenté la signature de pétitions par rapport aux conversations avec l’IA sur des sujets neutres.
Les hausses rapportées étaient de 12,8 points de pourcentage dans la première étude et de 19,7 points en moyenne dans la deuxième. Ce sont des différences absolues pour le résultat expérimental, pas des hausses relatives, des estimations d’influence électorale ou des résultats représentatifs de toute une population.
Le comparateur neutre ne démontre pas une supériorité sur une persuasion humaine tout aussi engageante ou un bon message statique. La participation rémunérée, les sujets sélectionnés et les actions peu coûteuses limitent la transposition à la communication politique ordinaire. Une hausse du passage à l’action ne constitue pas un jugement éthique.
Pour les usages persuasifs, j’évaluerais la liberté de choix, la transparence, la vulnérabilité et les conflits d’intérêts, en plus de la conversion. L’efficacité doit aussi être justifiée sur le plan éthique.
5. La responsabilité doit survivre à la délégation
La revue sur la responsabilité en IA médicale propose un modèle à plusieurs niveaux couvrant les acteurs cliniques, institutionnels et réglementaires avant et après le déploiement. Elle cartographie les responsabilités, sans démontrer de meilleurs résultats pour les patients.
L’article sur l’« agentic loafing » avance l’hypothèse que la conformité aux attentes de performance, la fragmentation des responsabilités et la légitimation par les chiffres pourraient affaiblir l’examen critique. Ce sont des hypothèses tirées du discours, pas des taux mesurés de complaisance. Le profil de risque proposé n’est pas validé.
Une réponse pratique consiste à attribuer les responsabilités à la décision réelle :
- Une personne responsable de la décision détermine si le cas d’usage doit être mis en service et accepte un risque résiduel défini.
- Une personne responsable du système maintient sa configuration, ses permissions et ses tests.
- Une personne chargée de l’examen peut contester ou arrêter les actions lourdes de conséquences.
- Une personne responsable des contestations et des corrections peut examiner et corriger les résultats pour les personnes concernées.
- Une fonction de contrôle indépendante peut remettre le déploiement en question lorsque des intérêts commerciaux découragent son interruption.
Il s’agit d’une organisation opérationnelle proposée, pas d’une répartition juridique de la responsabilité. Ces rôles ne comptent que s’ils disposent de preuves, de ressources et d’autorité.
6. Évaluer le déploiement, pas seulement le modèle
Une évaluation au niveau du modèle laisse de côté les outils, les permissions, les informations externes, la mémoire persistante et les relais humains. La perspective des défaillances de sécurité cachées examine ensemble les mécanismes techniques et organisationnels.
Imaginez un assistant qui lit un document affirmant qu’un client a autorisé l’envoi d’une pièce jointe confidentielle à une nouvelle adresse. Ce document peut-il conférer une autorisation qui devrait provenir d’un processus d’approbation de confiance ? C’est une défaillance hypothétique du déploiement, pas seulement une réponse inexacte.
La synthèse sur la sécurité des assistants de programmation désigne les dépôts, les « skills », les métadonnées des outils et les interactions entre protocoles comme surfaces d’attaque. Les taux rapportés proviennent de données secondaires hétérogènes et ne sont pas des estimations directement comparables des risques associés aux produits. La revue plus large inclut aussi des démonstrations avec des classificateurs d’images, pas des mesures de compromission d’agents LLM déployés. Un résultat sur l’IA agentique ne constitue pas à lui seul une preuve du risque d’un flux de travail agentique.
La formulation du risque que je recommande est précise : un destinataire non autorisé reçoit une pièce jointe confidentielle ; une modification générée est exécutée avec des privilèges excessifs ; une recommandation incorrecte déclenche une action irréversible. Pour chaque scénario, identifiez le point d’entrée, l’autorité requise, la conséquence et la voie de rétablissement.
7. Un score de test comparatif est un élément de preuve, pas un certificat de sécurité
La prépublication sur la taxonomie des tests de sécurité distingue 40 tests comportementaux et cinq ressources d’évaluation connexes hors de ce noyau. La comparaison empirique des classements ne porte que sur quatre tests et trois catégories de risque, pas sur tout l’inventaire.
Un test unique ne prouve pas la sécurité d’un déploiement entier, surtout si des résultats manquent ou si les méthodes de notation diffèrent.
Dans la prépublication sur l’injection contextuelle, l’expérience adaptative couvre 150 scénarios et jusqu’à 45 tentatives par scénario. Le taux de réussite de 96,7 % signifie que cette recherche limitée a permis de déclencher un appel non autorisé à un outil d’envoi de courriels. Ce n’est ni une probabilité d’échec en une tentative ni un taux observé de divulgation dans le monde réel.
Un test distinct de 100 scénarios construits associait des actions internes autorisées à des courriels externes non autorisés. Des limites explicites de communication ont éliminé les violations observées pour deux modèles testés et les ont réduites pour un autre. Cela ne prouve pas une sécurité universelle, mais contredit l’idée que toute défense serait vaine.
Avant d’utiliser un score, j’examinerais la tâche, le dénominateur, la configuration du modèle, le budget de l’attaquant, la comparaison, les angles morts et l’utilité légitime. Bloquer toute action ne convient pas à un travail autorisé.
8. Réduire les examens inutiles, pas la capacité d’intervenir
La supervision adaptative réserverait l’attention humaine aux décisions qui en ont besoin. Quelles preuves justifieraient la suppression d’un contrôle ?
Kumar et Singh évaluent une architecture sur des tâches synthétiques, face à un exécutant autonome et à une vérification universelle simulée par un modèle auquel les bonnes réponses sont fournies. Il s’agit d’une hypothèse d’ingénierie, pas d’une comparaison de sécurité en situation réelle.
L’article modifie plusieurs caractéristiques à la fois, comporte des incohérences non résolues entre tableaux et interprète une différence non significative comme une équivalence sans protocole adapté. Moins d’interruptions ne prouvent ni une sécurité équivalente ni des économies de personnel.
La perspective de Gjergji et Enkelejda Kasneci demande si les personnes chargées de l’examen ont l’expertise, le temps, les preuves, l’autorité et la protection organisationnelle nécessaires à un jugement indépendant. Ce sont des exigences proposées, pas des contrôles validés expérimentalement.
Testez si les personnes chargées de l’examen détectent et corrigent les mauvaises décisions sous une pression temporelle réaliste avant de réduire les contrôles. Mesurez les erreurs lourdes de conséquences qui passent inaperçues, pas seulement la vitesse d’approbation, et vérifiez qu’une objection arrête l’action. Une supervision réelle préserve la capacité d’intervenir lorsque les conséquences le justifient.
9. Le suivi exige une personne responsable et une réponse
La revue de portée sur l’IA clinique organise les données autour de la robustesse après le développement, du suivi après le déploiement et de la gouvernance du cycle de vie. Elle n’établit pas l’efficacité d’un programme de surveillance particulier.
La perspective des défaillances cachées propose des indicateurs comme les exécutions non autorisées d’outils, la détection d’erreurs d’examen introduites délibérément et leur correction avant une action en aval. Leur validité reste à évaluer.
Tout signal de suivi important devrait entraîner une réponse opérationnelle. Précisez ce qu’il mesure, son dénominateur et sa période d’observation, les groupes concernés, ses angles morts, le seuil d’enquête et la personne habilitée à intervenir.
Une défaillance contrôlée et sans danger peut montrer si l’alerte parvient à la bonne personne, si celle-ci peut restreindre l’action et si la correction atteint tous les cas concernés. C’est un test proposé, pas un ensemble de contrôles validé. Une hausse des incidents peut signifier une meilleure détection ; une baisse des contestations peut révéler une procédure moins accessible. La journalisation peut aussi entraîner des coûts pour la vie privée.
10. Transformer les principes en processus décisionnel opérationnel
La séquence ci-dessous est ma synthèse de la revue, proposée pour un essai local. Ce n’est ni une norme validée, ni une décision de conformité juridique, ni un calendrier optimal établi empiriquement.
Les 30 premiers jours : définir les décisions lourdes de conséquences
Choisissez quelques cas d’usage. Cartographiez ce que chaque système peut influencer et faire, les personnes concernées, les accès aux données, les destinations externes, l’état persistant et les actions irréversibles.
Consignez le bénéfice attendu, les résultats inacceptables et les conflits de valeurs importants. Nommez les responsables de la décision et du traitement des contestations et corrections. Examinez une recommandation contestée, un refus et une erreur découverte après l’action.
Produisez une carte des décisions et des responsabilités, pas seulement un inventaire de modèles.
Jours 31 à 60 : remettre les hypothèses en question
Testez l’utilité légitime, les actions non autorisées et les scénarios de défaillance pertinents. Évaluez si les personnes comprennent la recommandation, peuvent la contester et obtenir une correction.
Mettez à l’épreuve les limites des permissions. Le cas échéant, incluez de fausses affirmations externes d’autorisation, des données modifiées, des erreurs d’outils et une délégation ambiguë. Vérifiez si le suivi détecte les défaillances contrôlées et si les personnes chargées de l’examen peuvent arrêter l’action.
Distinguez « non testé », « testé ailleurs », « testé avec des défaillances » et « preuves indisponibles ». L’absence de preuves est une incertitude, pas un résultat positif.
Jours 61 à 90 : prendre une décision révisable
Comparez les constats aux résultats jugés inacceptables au départ. Approuvez un usage délimité, restreignez ses permissions, repensez-le ou suspendez-le dans l’attente de meilleures preuves.
Consignez l’incertitude restante, la personne qui l’accepte et les conditions qui invalideraient l’approbation : un nouveau modèle ou outil, des permissions plus lourdes de conséquences, des personnes utilisatrices différentes ou un objectif modifié.
Vérifiez la voie de rétablissement. Qui peut contenir une défaillance ? Que deviennent les actions en attente et l’état persistant ? Comment les personnes concernées obtiennent-elles une correction ? Un plan de retour arrière non testé reste une hypothèse.
Le vrai test : ce qui se passe quand le système se trompe
Éthique et gestion des risques se rejoignent lorsqu’une organisation relie une finalité acceptable à des preuves, des limites, des décisions assumées et des possibilités de correction. Testez un cas difficile : quelqu’un peut-il repérer une erreur, la contester avec des preuves, arrêter l’action et obtenir une correction pour la personne concernée ?
Un humain dans la boucle n’est pas la même chose qu’un humain aux commandes. La différence ne tient pas à l’étiquette, mais à la capacité pratique de changer la suite des événements.
Il s’agit de questions pratiques de gouvernance, et non d’une définition juridique du contrôle humain. Les obligations applicables dépendent de l’usage et du droit concerné ; les règles suivantes sont les repères les plus fréquents pour les organisations en Suisse et dans l’UE.
Repères juridiques (CH/UE)
- Décisions automatisées : selon l’art. 21 LPD, le responsable du traitement informe la personne concernée de toute décision prise exclusivement sur la base d’un traitement automatisé qui a des effets juridiques pour elle ou l’affecte de manière significative ; sur demande, elle peut faire valoir son point de vue et exiger que la décision soit revue par une personne physique. Ces obligations ne s’appliquent pas lorsque la décision est en relation directe avec la conclusion ou l’exécution d’un contrat avec la personne et que sa demande est satisfaite, ou lorsque la personne a expressément consenti à ce que la décision soit prise de manière automatisée (art. 21, al. 3, LPD). L’art. 22 RGPD donne le droit de ne pas faire l’objet d’une telle décision fondée exclusivement sur un traitement automatisé, sous réserve d’exceptions assorties de garanties. La Cour de justice a jugé dans l’arrêt SCHUFA (C‑634/21) qu’une valeur de probabilité de solvabilité établie automatiquement peut constituer une telle décision lorsqu’en dépend de manière déterminante le fait qu’un tiers établisse, exécute ou mette fin à une relation contractuelle avec la personne, et dans l’arrêt Dun & Bradstreet Austria (C‑203/22, 27 février 2025) que la personne peut, au titre du droit d’accès prévu à l’art. 15, par. 1, let. h, RGPD, exiger une explication de la procédure et des principes concrètement appliqués.
- Contrôle humain de l’IA à haut risque : selon le règlement européen sur l’IA, les fournisseurs conçoivent les systèmes à haut risque de manière à permettre un contrôle effectif par des personnes, notamment, dans la mesure où cela est approprié et proportionné, pour remplacer la sortie ou arrêter le système (article 14), et les déployeurs confient ce contrôle à des personnes disposant des compétences, de la formation, de l’autorité et du soutien nécessaires (article 26, paragraphe 2). Selon l’article 113, modifié par le règlement (UE) 2026/1744, ces obligations s’appliquent à compter du 2 décembre 2027 pour les systèmes de l’annexe III et du 2 août 2028 pour les systèmes relevant de l’article 6, paragraphe 1, liés à des produits de l’annexe I, section A. En vertu de l’article 2, paragraphe 2, aucun de ces deux articles ne s’applique aux systèmes liés à des produits de l’annexe I, section B, pour lesquels seuls l’article 6, paragraphe 1, l’article 60 bis et les articles 102 à 112 s’appliquent ; des actes délégués adoptés en vertu de l’article 2, paragraphe 13, peuvent limiter l’article 14 pour les systèmes de la section A. Les systèmes mis sur le marché ou mis en service avant ces dates ne sont concernés que dans les conditions prévues à l’article 111, paragraphe 2. Règlement consolidé
- Analyse d’impact : l’art. 22 LPD impose une analyse d’impact préalable lorsque le traitement envisagé est susceptible d’entraîner un risque élevé pour la personnalité ou les droits fondamentaux de la personne concernée. Les responsables du traitement privés en sont déliés ou peuvent y renoncer dans les cas prévus à l’art. 22, al. 4 et 5, LPD, à savoir en cas d’obligation légale de traiter les données, de recours à un système, un produit ou un service certifié, ou de respect d’un code de conduite remplissant les conditions requises.
- Règles suisses sur l’IA : selon la Chancellerie fédérale, la Suisse ne dispose pas encore d’une législation générale spécifique à l’IA. Le 12 février 2025, le Conseil fédéral s’est prononcé en faveur de la ratification de la Convention-cadre du Conseil de l’Europe sur l’intelligence artificielle, que la Suisse a signée le 27 mars 2025. Un projet destiné à la consultation, notamment en matière de transparence, de protection des données, de non-discrimination et de surveillance, doit être prêt d’ici fin 2026.
Sources et portée
Ces sources étayent les descriptions précises des travaux ci-dessus, dans les limites propres à chaque étude. Les rôles, les tests et la séquence sur 30 à 90 jours constituent ma synthèse proposée, et non des exigences validées par les articles cités.
- Wubineh et ses collègues, éthique et garanties dans le secteur de la santé
- Bhatti, décisions algorithmiques et autonomie dans la finance
- Hofmann, autonomie artificielle et paternalisme algorithmique
- Mohammadnejad et ses collègues, revue sur l’autonomie des patients
- Cheng et ses collègues, expériences sur l’IA complaisante
- Hackenburg et ses collègues, expériences sur l’action politique
- Martinho et ses collègues, responsabilité en IA médicale
- Issa et ses collègues, agentic loafing
- Kasneci et Kasneci, défaillances de sécurité cachées
- Maloyan et Namiot, synthèse des injections visant les assistants de programmation
- Radanliev, Santos et Maple, menaces agentiques et classificateurs d’images
- Li et ses collègues, taxonomie des tests de sécurité
- Abdelnabi et Bagdasarian, expériences sur l’injection contextuelle
- Kumar et Singh, architecture de supervision adaptative
- El Arab et ses collègues, revue sur le suivi de l’IA clinique