Allez, commençons par une banalité, en notant que dans la vie ordinaire, comme dans la vie économique, il faut décider sans jamais tout savoir. Toute décision engage une part d’incertitude, donc une part de risque. Certains risques sont petits, absorbables, et on n’y prête même plus attention. D’autres peuvent avoir des conséquences financières telles qu’on préfère les transférer à un tiers, en payant une prime pour qu’un assureur les prenne à sa charge. C’est, au fond, une des fonctions les plus concrètes de l’assurance. Mais une question au moins aussi intéressante surgit lorsque ce transfert devient impossible, ou du moins impossible à un prix raisonnable. C’est ce qu’on appelle “inassurabilité”, que l’on rencontre déjà face à certains risques naturels, lorsque les pertes deviennent trop corrélées, trop massives, trop difficiles à mutualiser, comme je l’évoquais dans Assureurs et IA, un risque systémique et dans Assurer l’IA. Nouveaux risques ? Nouveaux modèles ?. Et désolé d’utiliser ce terme parapluie, “IA”, que je n’aime pas trop, mais je vais simplifier un peu sinon je ne finirais jamais ce billet…

Avant hier, Thomas Claburn écrivait dans AI still doesn’t work very well in business, businesses are faking it, and a reckoning is coming

Another looming problem is that large insurers have become wary of underwriting policies that cover companies against AI risk.

(merci @flomaraninchi et @ugo de me l’avoir pointé) et j’ai l’impression qu’il est important de bien comprendre ce que ça signifie… Si de grands assureurs deviennent réticents à couvrir les usages de l’IA, ce n’est peut être pas simplement une de ces nombreuses anecdotes venant du marché, ni une précaution juridique de plus, c’est probablement un signal. Un signal important quand on fait des modèles prédictifs, qu’on s’intéresse à l’incertitude et à l’ambiguïté, parce que bien souvent, un assureur n’a pas besoin d’être prophète pour devenir méfiant. C’est peut être ce qui s’appelle la culture du risque… Il lui suffit d’estimer qu’il ne comprend pas suffisamment le risque, qu’il ne peut pas l’observer correctement, qu’il ne sait pas en reconstruire la chaîne de responsabilité, ou qu’il doute de pouvoir le porter à un prix soutenable. Autrement dit, si on voit les assureurs reculer, ça devrait nous obliger à nous demander si l’IA est réellement maîtrisée. On touche ici à des questions très classiques d’économie de l’information, de mesure imparfaite, d’incitations mal alignées et de preuve insuffisante, bien plus qu’à une simple querelle sur le niveau actuel de la technologie.

1. Le récit de productivité commence souvent par une erreur de mesure

Le premier problème, avec l’IA en entreprise, n’est peut-être pas l’erreur technique elle-même, c’est souvent plus profond. À mon avis, c’est avant tout parce qu’on mesure mal ce qu’on prétend améliorer. Dès qu’une organisation adopte un nouvel outil, elle cherche des indicateurs rapides pour objectiver son efficacité. On comptera le nombre de lignes de code, le nombre de présentations produites, le nombre de tickets fermés, le temps gagné sur une tâche, le volume de texte généré, etc. Ce sont des métriques assez faciles à faire remonter dans un tableau de bord, faciles aussi à présenter à une direction générale. Mais ce sont souvent de très mauvaises mesures de la qualité réelle du travail livré. Dans Les conséquences de la loi de Goodhart, je rappelais qu’une mesure cesse d’être une bonne mesure dès lors qu’elle devient un objectif, parce qu’elle rétroagit sur les comportements et finit par déformer le processus qu’elle était censée décrire. Une fois la cible fixée, les acteurs apprennent à améliorer l’indicateur plutôt que la réalité qu’il résumait imparfaitement.

C’est exactement l’intuition que l’on retrouve dans l’article de Thomas Claburn. Dans AI still doesn’t work very well in business, …, le point important, je pense que ce n’est pas que l’IA produise beaucoup de code ou beaucoup de contenu. Le point important, c’est qu’on ne sait pas très bien quels indicateurs regarder pour savoir si ce supplément de production améliore vraiment les résultats qui importent. Les auteurs cités dans l’article rappellent que les lignes de code, ou le nombre de pull requests, ne sont pas des mesures d’excellence en ingénierie. Ce qui compte, ce sont plutôt des variables comme la fréquence de déploiement, le délai de mise en production, le taux d’échec des changements, le temps de rétablissement, la sévérité des incidents. Dès lors, une partie de l’optimisme contemporain vient peut-être d’une confusion très simple: on confond ce qui est facile à compter avec ce qui est réellement important. C’est corrélé, certes, mais c’est le problème des proxys qui ne capturent pas les liens causaux (c’est un peu plus subtile, d’accord… cf Corrélation et causalité,). Ici, l’assurance c’est le canari dans le mine de charbon (j’avais déjà utilisé cet argument dans “Notre maison brûle et….” dans le contexte des catastrophes naturelles). Un assureur, lui, ne se contente pas d’observer le volume de production. Il veut comprendre la fréquence probable des erreurs, leur coût, leur corrélation, leur traçabilité, et la possibilité d’identifier après coup qui a fait quoi, dans quelles conditions. En ce sens, les assureurs regardent souvent un système avec de meilleures métriques que ceux qui le célèbrent dans un techno-optimisme béat.

2. Ce qui paraît correct localement peut dégrader le système dans son ensemble

Le second problème prolonge le premier. Même lorsqu’un résultat semble correct à petite échelle, cela ne dit presque rien de ses effets sur le système dans son ensemble. Là encore, l’exemple donné dans  AI still doesn’t work very well in business, …, est intéressant. Un code peut avoir la bonne apparence, passer des tests, sembler propre à première vue, et pourtant être profondément défaillant une fois replacé dans un environnement réel. L’article évoque ainsi une réécriture de SQLite en Rust avec de l’IA qui aurait produit beaucoup plus de lignes de code tout en étant massivement moins performante que l’original. Peu importe ici le détail exact de l’exemple. Ce qui compte, c’est l’idée générale. Une validation locale ne garantit pas une performance globale. Une sortie seulement plausible n’est pas une preuve de robustesse. Un livrable convaincant n’est pas forcément un bon livrable. À partir du moment où l’on oublie cela, on remplace l’évaluation par une simple esthétique du résultat.

Tout ça a été plus ou moins par exemple dans Announcing the 2024 DORA report. Ce rapport suggère que l’adoption de l’IA peut s’accompagner d’améliorations sur certaines dimensions intermédiaires, par exemple la documentation ou la rapidité perçue sur quelques tâches, tout en coexistant avec une baisse du “cadence de livraison” (“delivery throughput“) et de la stabilité d’ensemble. Autrement dit, des signaux locaux peuvent s’améliorer pendant que la performance globale se détériore. C’est une tension essentielle pour comprendre ce qui se passe aujourd’hui. L’IA peut donner aux équipes le sentiment d’aller plus vite, de produire plus, de fluidifier certains gestes, tout en dégradant les propriétés du système qui importent vraiment lorsqu’on raisonne en production, en responsabilité, ou en assurance. C’est aussi pour cela que le sujet ne se réduit pas à la seule qualité technique d’un modèle. Il touche à la manière dont une organisation observe ses propres résultats, à la façon dont elle confond parfois les conditions apparentes de la performance avec la performance elle-même, et à son incapacité éventuelle à voir qu’elle a simplement déplacé le coût du travail vers l’aval, vers la maintenance, la vérification, les incidents, puis finalement le sinistre.

3. Beaucoup de services produits avec l’IA ressemblent à des biens de crédence

À partir du moment où la qualité globale devient difficile à observer, on entre dans un type de marché bien connu en économie de l’information. Rudolf Kerschbamer et Matthias Sutter rappellent dans Economics of Credence Goods que certains biens ou services ont une propriété particulière. L’acheteur ne sait pas toujours quelle qualité lui conviendrait le mieux, et il peut même rester incapable de vérifier, après coup, la qualité effectivement reçue. C’est le cas typique des soins, de certaines réparations, du conseil juridique ou du conseil financier. Cette catégorie (les “Credence Goods“, assez proche des “Lemons” de Georges Akerlof, sauf que pour lui, le problème central est surtout la sélection adverse entre biens de bonne et de mauvaise qualité, alors que dans les credence goods, le problème porte davantage sur la relation d’expertise : le vendeur ne connaît pas seulement mieux la qualité du bien, il diagnostique aussi ce dont l’acheteur a besoin, recommande une prestation, puis la facture) est intéressante, parce qu’elle permet de décrire assez explicitement ce que deviennent beaucoup d’usages professionnels de l’IA générative. Un rapport stratégique, une note de synthèse, une recommandation de conformité, une présentation commerciale, un avis préparatoire ou même une portion de code noyée dans un système plus vaste peuvent tous paraître convaincants sans que leur qualité réelle soit immédiatement observable. On ne parle donc pas seulement d’un outil qui produit plus vite, on parle peut être avant tout d’un dispositif qui risque de multiplier des livrables dont l’apparence est souvent facile à juger, mais dont la valeur effective devient plus difficile à établir. C’est exactement la définition d’un bien de crédence, au sens de Darby et Karni dans Free Competition and the Optimal Amount of Fraud, lorsque la qualité est coûteuse à évaluer même après usage.

Et pour revenir à l’article de Thomas Claburn (AI still doesn’t work very well in business, …), on peut y voir une portée plus générale que la simple critique de notre société actuelle. Lorsqu’il explique que les grands cabinets de conseil utilisent déjà l’IA à grande échelle pour rédiger des PowerPoint ou d’autres livrables, et que les erreurs dans le travail de bureau risquent d’être plus difficiles à détecter que dans le code faute de tests de référence comparables, il parle d’autre chose que d’une faiblesse technique. Il décrit une économie de services dans laquelle la qualité devient opaque au client. Et pas que lui, parfois même à l’organisation qui vend le service. Or c’est précisément dans ce type de situation que le risque assurantiel devient intéressant. Car l’assureur, lui, ne couvre pas une belle apparence ni une promesse de fluidité. Il couvre les conséquences d’une erreur lorsqu’elle finit par produire un dommage. Plus la qualité est difficile à observer au moment de la livraison, plus le risque de sinistre tardif augmente, et plus la question de la preuve devient centrale. L’IA ne fait donc pas qu’accélérer la production. Elle accroît aussi la probabilité que des services difficiles à évaluer soient mis en circulation à grande échelle, puis ne révèlent leurs défauts qu’au moment où ils ont déjà été intégrés dans une décision, un contrat ou un “workflow”.

4. Le problème principal n’est pas seulement l’erreur, mais l’incitation à ne pas la voir

Lorsque la qualité est difficile à observer, la question économique n’est plus celle de la fiabilité technique de l’outil, mais elle va porter sur la recherche des incitations des acteurs qui l’utilisent. La bonne nouvelle, c’est qu’il y a déjà des éléments de réponse. En particulier, dans l’article (AI still doesn’t work very well in business, …), Dorian Smiley (cofondateur et CTO de Codestrap) décrit une chaîne d’incitations assez simple : le partner veut plus de marge et plus de chiffre d’affaires, le directeur lui veut aller plus vite, avec moins d’interactions et moins de travail “junior”, l’associate lui veut terminer plus tôt. Bref, dans un tel système, personne n’est spontanément rémunéré pour relire sérieusement toutes les sorties d’un modèle. Ce n’est pas qu’un individu particulier agirait mal, c’est juste que l’organisation entière peut devenir rationnellement aveugle à la dégradation de la qualité, parce que le coût immédiat de la vigilance pèse sur ceux qui doivent livrer vite, alors que le coût du dommage est reporté plus tard, parfois sur d’autres équipes, parfois sur le client, parfois sur l’assureur. Le problème n’est donc pas seulement technologique, il est (surtout) organisationnel, comptable, et économique.

La littérature sur les biens de crédence (pour proposer une traduction au terme “Credence Goods“) permet justement de donner à cette intuition une forme plus générale. Kerschbamer et Sutter montrent que les asymétries d’information créent des incitations à la sur-prestation, à la sous-prestation et à la surfacturation. Ils rappellent aussi qu’il existe, en théorie, deux grands correctifs institutionnels, la responsabilité et la vérifiabilité. Mais ils ajoutent immédiatement que la vérifiabilité est souvent difficile à satisfaire en pratique, ce qui est important si on veut penser sérieusement l’IA en entreprise. Beaucoup d’organisations croient aujourd’hui résoudre le problème en ajoutant quelques checklists, un peu de documentation, et la formule rassurante du human in the loop. Mais ce bricolage documentaire ne suffit pas toujours à produire une véritable responsabilité. Il permet parfois de raconter qu’un contrôle existe sans garantir que quelqu’un sera effectivement comptable (ils utilisent le terme “being accountable“, devoir rendre des comptes) de la qualité finale du service rendu. Or tant qu’il n’existe pas une chaîne crédible de responsabilité, l’erreur reste non seulement possible, mais structurellement tentante à ignorer. Et forcément, ça posera des problème si on cherche à s’assurer : un risque devient très difficile à couvrir lorsque ni le client, ni le prestataire, ni l’assureur ne savent clairement qui devait voir l’erreur, à quel moment, et selon quelle procédure.

5. Le coût caché de l’IA n’est pas la génération, c’est la vérification

On raconte souvent l’IA comme une machine à produire plus vite. Mais cette manière de présenter les choses repose sur une omission systématique. On compte volontiers le temps gagné au moment de la première production, beaucoup moins le temps nécessaire pour transformer cette première version en un objet réellement fiable. Et c’est sans doute là que se trouve le vrai coût. Dans AI still doesn’t work very well in business, … Thomas Claburn rappelle qu’un modèle peut produire une sortie plausible sans disposer pour autant de la capacité de vérifier son propre travail, je l’ai déjà dit tout à l’heure. Mais il insiste aussi sur le fait qu’un modèle ne sait pas si la réponse qu’il a donnée est juste, et que des millions de lignes de code générées par l’IA ne seront jamais relues par des humains. Dès lors, chaque gain apparent de vitesse déplace en réalité une charge vers l’aval. Il faut relire, comparer, tester, contextualiser, parfois réécrire. Et si personne n’assume sérieusement ce travail, le coût ne disparaît pas. Il réapparaît plus tard sous forme d’erreur, de correction en urgence, de perte de confiance, puis éventuellement de contentieux. Ce que l’on présente comme un gain de productivité n’est donc souvent qu’un déplacement comptable. On économise au début sur la production, pour dépenser plus tard sur le contrôle, ou sur les conséquences de son absence.

Mais là encore, rien de bien nouveau, plusieurs personne nous ont déjà mis en garde. Dans Closing the AI accountability gap…, Inioluwa Deborah Raji, Andrew Smart et leurs coauteurs rappellent que les audits externes arrivent souvent après le déploiement, lorsque le système a déjà produit ses effets négatifs. Ils en concluent que si on veut vraiment prévenir plutôt que simplement constater, il faut accepter un audit interne qui soit « boring, slow, meticulous and methodical ». Mine de rien, c’est mot pour mot l’inverse du récit dominant sur l’itération rapide. La preuve, au sens fort, ne se résume pas à quelques checklists ou à un vague human in the loop. Elle exige une infrastructure documentaire, une collecte d’artefacts, des procédures de test, des moments de réflexion, bref tout un appareil organisationnel qui ralentit. Ce ralentissement n’est pas un défaut du système, il en est la condition de crédibilité ! Tant qu’une organisation célèbre les gains de vitesse sans financer sérieusement cette infrastructure de vérification, elle sous-estime nécessairement le coût complet du système. Et elle produit, sans toujours s’en rendre compte, les conditions d’un risque de moins en moins assurable.

6. La dette technique devient très vite une dette de gouvernance

Le texte de David Sculley et al., Hidden Technical Debt in Machine Learning Systems, montrer que la dette des systèmes d’apprentissage ne se loge pas seulement dans le code, mais dans l’ensemble des relations qui entourent le modèle. Les auteurs rappellent que développer et déployer un système de machine learning est souvent relativement rapide et peu coûteux en apparence, alors que sa maintenance dans le temps devient difficile et chère. Et cette dette est dangereuse parce qu’elle s’accumule silencieusement, elle se déplace à l’échelle du système tout entier. C’est le principe CACE, Changing Anything Changes Everything, dans les undeclared consumers qui réutilisent discrètement les sorties d’un modèle, dans les pipeline jungles qui transforment la préparation des données en enchevêtrement opaque, et jusque dans la dette de processus ou la dette culturelle quand les organisations continuent à récompenser la vitesse et la précision locale davantage que la reproductibilité et la stabilité. Je pense que c’est un important parce qu’il rappelle que le problème n’est pas seulement celui d’un modèle imparfait, c’est celui d’un système devenu progressivement plus difficile à comprendre, donc plus difficile à corriger proprement.

Et dans ce cas, la dette technique devient une dette de gouvernance. À mesure que les dépendances se multiplient, que les sorties sont réutilisées ailleurs sans déclaration explicite, que les corrections s’empilent sur les corrections et que les chaînes de traitement deviennent plus opaques, la question n’est plus seulement de savoir si le système fonctionne aujourd’hui. La question devient de savoir qui sera capable, demain, d’expliquer pourquoi une erreur s’est produite, quel changement l’a déclenchée, quels autres composants ont été affectés, et qui devra en répondre. Closing the AI accountability gap complète si bien le texte de David Sculley et al. (Hidden Technical Debt …). Inioluwa Deborah Raji et ses coauteurs définissent l’accountability comme le fait d’être responsable ou “answerable for a system, its behavior and its potential impacts.” Ils rappellent aussi que les algorithmes eux-mêmes ne peuvent pas être tenus pour responsables, seules les organisations le peuvent à travers leurs structures de gouvernance. Si on comprend ça, on comprend la question de l’assurabilité. Plus la dette technique s’épaissit, plus la chaîne explicative devient fragile. Plus la chaîne explicative devient fragile, plus l’attribution de responsabilité se brouille. Et plus cette responsabilité se brouille, plus le risque devient difficile à porter, à tarifer, et parfois même simplement à comprendre.

7. L’automatisation ne supprime pas l’erreur, elle la déplace

Un autre point important, c’est qu’on dit souvent que l’automatisation réduit l’erreur humaine. C’est parfois vrai, mais la formule est trompeuse, parce qu’elle laisse entendre que l’erreur disparaîtrait avec l’intervention de la machine. Or c’est exactement l’inverse que suggèrent Raja Parasuraman et Victor Riley dans Humans and Automation: Use, Misuse, Disuse, Abuse. Leur idée n’est pas que l’automatisation serait bonne ou mauvaise en soi, c’est forcément plus subtile. L’automatisation reconfigure le rôle de l’humain, déplace son attention, transforme les conditions de sa vigilance, et fait apparaître de nouvelles formes d’usage excessif, de sous-usage, ou d’abus organisationnel. Ils définissent ainsi le “misuse” comme une surconfiance dans l’automatisation, le “disuse” comme sa sous-utilisation, et le “abuse” comme une mise en œuvre décidée par les concepteurs ou par le management sans tenir suffisamment compte des conséquences sur la performance humaine. Plus généralement, ils rappellent que les erreurs associées à l’automatisation peuvent venir de l’opérateur, du designer, ou même du management.

Il faut garder ça en tête quand on essaye de réfléchir au déploiement de l’IA générative en entreprise. Lorsqu’un outil produit vite, avec une apparence de cohérence et une forme souvent très convaincante, il ne supprime pas le besoin de jugement. Il le déplace vers des tâches plus diffuses et plus ingrates, surveiller, douter, relire, intervenir seulement lorsque quelque chose paraît étrange. Or Parasuraman et Riley rappellent (dans Humans and Automation) que le monitoring humain fonctionne mal dans les environnements à forte charge, dans les systèmes très autonomes, ou lorsque les opérateurs ont trop peu d’occasions de pratiquer eux-mêmes la tâche manuelle. Ils ajoutent que l’automatisation remplace souvent l’opérateur par le designer, et parfois même par le manager. Dès lors, une erreur de présentation, de recommandation, de priorisation ou de raisonnement n’est pas nécessairement la faute d’un utilisateur inattentif. Elle peut être le produit d’un système dans lequel on a retiré aux humains les conditions mêmes d’un contrôle effectif, tout en continuant à leur demander d’en assumer la responsabilité finale. Pour l’assureur, c’est une situation compliquée, parce qu’elle brouille à la fois la prévention du dommage et l’attribution de la faute.

8. Sans audit interne, la preuve arrive toujours trop tard

Et l’audit? Pas l’audit comme supplément éthique ou comme geste cosmétique, mais comme condition minimale d’une preuve crédible. Dans Closing the AI accountability gap…, Inioluwa Deborah Raji, Andrew Smart et leurs coauteurs expliquent que les audits externes arrivent souvent après le déploiement, lorsque le système a déjà produit des effets négatifs (je l’ai déjà dit), et ils sont de surcroît limités par leur manque d’accès aux processus internes, aux modèles intermédiaires ou aux données d’entraînement, souvent protégés comme secrets industriels. Leur proposition consiste donc à penser un audit interne conduit tout au long du cycle de développement, de façon à produire des documents, des traces, des critères d’évaluation et, plus largement, un véritable rapport d’audit permettant d’identifier plus tôt les écarts entre ce qu’un système était censé faire et ce qu’il risque effectivement de produire.

J’ai l’impression que dans leur article, ils renversent la hiérarchie spontanée des valeurs. Ils rappellent qu’un système peut être techniquement fiable au sens étroit de l’assurance qualité classique, tout en échouant à satisfaire les attentes plus larges que l’organisation prétend pourtant porter. C’est pourquoi l’audit interne n’a pas seulement pour fonction de vérifier la performance d’un système avant son lancement. Il sert aussi à rendre le développement lui-même auditable, à créer une véritable “transparency trail”, à faire apparaître les parties prenantes, les décisions prises, les écarts constatés et les arbitrages retenus. Sans ce travail lent et documentaire, la preuve reste toujours ex post. Elle surgit au moment de l’incident, du litige ou du sinistre, c’est-à-dire précisément au moment où elle coûte le plus cher et aide le moins à prévenir. Et c’est bien pour cela que, du point de vue de l’assurance, une organisation sans audit interne robuste ressemble très vite à une organisation devenue difficile à couvrir à un prix raisonnable.

9. Le sinistre lié à l’IA sera souvent tardif, diffus, et donc difficile à attribuer

J’en parlais un peu dans mon article la semaine dernière, Fukushima : 15 ans après…, mais l’image est importante quand on veut penser la catastrophe. On imagine volontiers le risque technologique comme un accident spectaculaire, immédiat, et visible de tous. J’avais dit que sur le risque nucléaire, c’était plus compliqué, en en fait, une grande partie des dommages liés à l’IA en entreprise risque au souvent de prendre une forme beaucoup plus discrète. C’est d’ailleurs un des points les plus intéressants dans AI still doesn’t work very well in business, … Thomas Claburn explique que les problèmes seront probablement plus difficiles à repérer dans les usages de bureau que dans le code, faute de tests de référence comparables pour évaluer des conseils hallucinés, des présentations plausibles mais fausses, ou des livrables dont personne ne suit vraiment la qualité. L’article évoque aussi des défauts de qualité qui pourraient n’apparaître qu’au bout de huit ou neuf mois chez les gros utilisateurs, puis des contentieux lorsque de mauvais conseils auront effectivement produit leurs effets. Le dommage n’apparaît donc pas nécessairement au moment de la génération. Il apparaît plus tard, au moment où un rapport a servi à décider, où une recommandation a été suivie, où un document a été diffusé, ou où un morceau de code a été intégré dans une chaîne de production. Le risque n’est pas seulement celui d’une erreur. C’est celui d’un délai entre la production, la circulation du livrable, son appropriation par l’organisation, puis la manifestation concrète du dommage.

Lors que j’ai écrit Assureurs et IA, un risque systémique  j’insistais surtout sur l’accumulation, sur la corrélation et sur la possibilité de milliers de pertes simultanées lorsqu’une même dépendance technologique se diffuse partout. Thomas Claburn rappelle qu’il ne s’agit plus seulement du choc massif et synchronisé, il s’agit aussi d’une traîne longue, de défauts qui restent longtemps invisibles parce qu’ils se confondent avec du travail ordinaire, avec des documents banals, avec des recommandations professionnelles apparemment acceptables. Et, il me semble que c’est précisément ce qui rend le sujet si inconfortable pour l’assurance. Un risque tardif, diffus, difficile à détecter et encore plus difficile à attribuer complique à la fois la prévention, la tarification, la constitution de la preuve et, finalement, le règlement du sinistre. On retrouve alors, sous une autre forme, le même malaise assurantiel. L’IA ajoute aux scénarios de pertes corrélées une famille entière de sinistres lents, opaques, et coûteux à reconstituer après coup.

10. Le marché envoie déjà un signal de doute que le discours public n’assume pas encore

On peut enfin arriver à la citation que je mettais en introduction, parce que si l’IA était vraiment un gain de productivité clair, robuste, mesurable et maîtrisable, alors le marché devrait la récompenser sans ambiguïté. Or ce n’est pas ce qui se passe. Certes, il y a l’hyper valorisation boursière de ces compagnies. Mais que penser de la pression sur les prix lorsque les clients apprennent qu’un prestataire utilise l’IA pour produire ses livrables, comme le mentionne AI still doesn’t work very well in business, … ? Il y est aussi question d’une multiplication possible des poursuites lorsque de mauvais conseils causent effectivement des dommages. Et surtout, il y est question d’assureurs qui cherchent à retirer ou à limiter la couverture lorsque l’IA intervient sans chaîne claire de responsabilité. Une même technologie peut être présentée en interne comme un gain de productivité, être interprétée par le client comme une baisse de valeur, et être analysée par l’assureur comme une hausse du risque. On le voit (et c’était un peu le but de mon billet), c’est un faux paradoxe… Plus une entreprise explique qu’elle a automatisé sa production, plus elle peut fragiliser à la fois la valeur perçue de son travail, l’exposition de sa responsabilité professionnelle, et l’assurabilité même du service qu’elle vend.

Dans Assurer l’IA. Nouveaux risques ? Nouveaux modèles ?, je rappelais que beaucoup de risques liés à l’IA sont déjà présents dans les portefeuilles d’assurance sous forme de couvertures silencieuses, et que sans responsabilité financière réelle, l’audit, la certification et la conformité risquent de devenir de simples exercices de cases à cocher. J’y insistais aussi sur un point très classique en assurance, à savoir qu’un assureur ne peut observer la prudence qu’au prix d’un coût de vérification, et que des coûts de contrôle trop élevés peuvent rendre un risque pratiquement inassurable. Et AI still doesn’t work very well in business, …  me permet de fermer la boucle (temporairement j’imagine). Parce que si les clients veulent payer moins, si les prestataires s’exposent davantage aux litiges, et si les assureurs cherchent à sortir du risque, alors le marché envoie déjà un signal de doute très net. Derrière le récit public d’efficacité, il existe un doute peu exprimé, mais qui se traduit de manière monétaire, contractuel et assurantiel. Et c’est peut-être ce doute-là qu’il faut prendre au sérieux, parce qu’en général les prix, les exclusions, les franchises et les refus de couverture disent plus sincèrement l’état réel des croyances que les discours triomphants sur la révolution en marche.

Bref, on a peut-être beaucoup parlé de “nouveaux risques” en lien avec l’intelligence artificielle, mais comme bien souvent (et c’était aussi la conclusion dans Assurer l’IA. Nouveaux risques ? Nouveaux modèles ?), quand on creuse un peu, on voit qu’il s’agit avant tout d’une vieille histoire d’économie de l’information, de mauvaises métriques, de contrôle imparfait et de responsabilité diffuse…

---

---