Warning: UPDATE command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_cache' query: UPDATE mafeco_cache SET data = 'a:180:{s:13:\"theme_default\";s:4:\"deco\";s:13:\"filter_html_1\";i:1;s:18:\"node_options_forum\";a:1:{i:0;s:6:\"status\";}s:18:\"drupal_private_key\";s:64:\"cf9d40a987180a23d720b38259dda6bf06f22eb01553d46a91d434993991f57e\";s:10:\"menu_masks\";a:18:{i:0;i:62;i:1;i:61;i:2;i:59;i:3;i:58;i:4;i:31;i:5;i:30;i:6;i:29;i:7;i:24;i:8;i:21;i:9;i:15;i:10;i:14;i:11;i:11;i:12;i:7;i:13;i:6;i:14;i:5;i:15;i:3;i:16;i:2;i:17;i:1;}s:12:\"install_task\";s:4:\"done\";s:13:\"menu_expanded\";a:0:{}s:9:\"site_name\";s:6:\"Mafeco\";s:11:\"site_slogan\";s:28:\"Ma femme est une économiste\";s:9:\"site_mail\";s:21:\"mafeco.blog@gmail.com\";s:21:\"date_default_timezone\";s:4:\"7200\";s:23:\"user_ in /home/mafeco/www/includes/database.mysql.inc on line 128

Warning: INSERT command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_watchdog' query: INSERT INTO mafeco_watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:1023:\"UPDATE command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_cache'\nquery: UPDATE mafeco_cache SET data = 'a:1918:{s:2:\\"MB\\";s:2:\\"Mo\\";s:3:\\"php\\";s:3:\\"php\\";s:14:\\"MySQL database\\";s:22:\\"Base de données MySQL\\";s:8:\\"Password\\";s:12:\\"Mot de passe\\";s:18:\\"Save configuration\\";s:28:\\"Enregistrer la configuration\\" in /home/mafeco/www/includes/database.mysql.inc on line 128

Warning: INSERT command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_watchdog' query: INSERT INTO mafeco_watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:1023:\"UPDATE command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_cache'\nquery: UPDATE mafeco_cache SET data = 'a:56:{s:6:\\"blocks\\";a:7:{s:11:\\"description\\";s:62:\\"Stores block settings, such as region and visibility settings.\\";s:6:\\"fields\\";a:13:{s:3:\\"bid\\";a:3:{s:4:\\"type\\";s:6:\\"serial\\";s:8:\\"not null\\";b:1;s:11:\\"description\\";s:29:\\ in /home/mafeco/www/includes/database.mysql.inc on line 128

Warning: INSERT command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_watchdog' query: INSERT INTO mafeco_watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:1023:\"UPDATE command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_cache_filter'\nquery: UPDATE mafeco_cache_filter SET data = '<p style=\\"text-align:justify\\">Retour sur un événement survenu il y a quelques semaines, avec mes excuses pour le retard. Le 12 avril donc l’incident de Fukushima a franchi le niveau 7 de l’échelle INES, après avoir franchi les uns après les autres les 7 échelons. Le tout dans une certaine suspicion quant au fait que sûrement « on » nous cache quelqu in /home/mafeco/www/includes/database.mysql.inc on line 128

Warning: INSERT command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_watchdog' query: INSERT INTO mafeco_watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:1023:\"UPDATE command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_cache'\nquery: UPDATE mafeco_cache SET data = 'a:146:{s:24:\\"block_admin_display_form\\";a:7:{s:8:\\"template\\";s:38:\\"modules/block/block-admin-display-form\\";s:4:\\"file\\";s:29:\\"modules/block/block.admin.inc\\";s:9:\\"arguments\\";a:1:{s:4:\\"form\\";N;}s:4:\\"type\\";s:6:\\"module\\";s:10 in /home/mafeco/www/includes/database.mysql.inc on line 128

Warning: INSERT command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_watchdog' query: INSERT INTO mafeco_watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:906:\"UPDATE command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_cache_filter'\nquery: UPDATE mafeco_cache_filter SET data = '<p>L\\'échelle INES correspond exactement à l\\'hypothèse que vous faîtes : chaque niveau de problème correspond à un niveau de risque \\"acceptable\\", le passage d\\'un niveau de problème à un autre correspondant à une probabilité d\\'occurence divisée/multipliée par 10.</p>\\n<p>Par contre in /home/mafeco/www/includes/database.mysql.inc on line 128

Warning: INSERT command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_watchdog' query: INSERT INTO mafeco_watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:1023:\"UPDATE command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_cache_filter'\nquery: UPDATE mafeco_cache_filter SET data = '<p>Merci pour cette remarque, pour l\\'exposition j\\'ai préféré coller au modèle standard de cheap-talk, mais c\\'est vrai qu\\'effectivement l\\'échelle INES est plus détaillée en haut qu\\'en bas en termes de fréquence des événements. Ce que j\\'avais en tête, et qui doit être à peu près similaire en term in /home/mafeco/www/includes/database.mysql.inc on line 128

Warning: INSERT command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_watchdog' query: INSERT INTO mafeco_watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:1023:\"UPDATE command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_cache_filter'\nquery: UPDATE mafeco_cache_filter SET data = '<p>Léna, je veux bien croire que l\\'échelle INES a été construit avec une probabilité d\\'occurence divisée / multipliée par 10, mais il y a dans ce cas un vrai problème.</p>\\n<p>Si on reprend la liste des incidents (bien sûr pas exhaustive mais sans doute représentative au moins pour les derniers niveaux) on à 2 incidents ni in /home/mafeco/www/includes/database.mysql.inc on line 128

Warning: INSERT command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_watchdog' query: INSERT INTO mafeco_watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:495:\"UPDATE command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_cache_filter'\nquery: UPDATE mafeco_cache_filter SET data = '<p>Un billet qui me rappelle celui sur les cascades informationnelles que j\\'avais dévoré à la découverte du blog [RCE à l\\'époque] . Vraiment bon.</p>\\n', created = 1487816795, expire = 1487903195, headers = '', serialized = 0 WHERE cid = '2:f5f30b48a7555285c984ecace867ff9b'\";s:5:\"%file\ in /home/mafeco/www/includes/database.mysql.inc on line 128

Warning: INSERT command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_watchdog' query: INSERT INTO mafeco_watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:407:\"INSERT command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_captcha_sessions'\nquery: INSERT into mafeco_captcha_sessions (uid, sid, ip_address, timestamp, form_id, solution, status, attempts) VALUES (0, 'bb192ce256f60672fec7b4ee7033040a', '54.144.194.161', 1487816795, 'comment_form', '3e26f9ff14c8010a2870a92a5bd91228', 0, 0)\";s:5:\"%file\";s:44:\"/home/mafeco/www/modules/captcha/captcha.inc\";s:5:\"%line\";i:99;}' in /home/mafeco/www/includes/database.mysql.inc on line 128

Warning: INSERT command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_watchdog' query: INSERT INTO mafeco_watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:224:\"UPDATE command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_captcha_sessions'\nquery: UPDATE mafeco_captcha_sessions SET token='2da523dcd36d59eab6e94c8fa6b8c1da' WHERE csid=0\";s:5:\"%file\";s:47:\"/home/mafeco/www/modules/captcha/captcha.module\";s:5:\"%line\";i:216;}', 3, '', 'http://www.mafeco.fr/?q=node/250', '', '54.144.194.161', 1487816795) in /home/mafeco/www/includes/database.mysql.inc on line 128

Warning: INSERT command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_watchdog' query: INSERT INTO mafeco_watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:222:\"UPDATE command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_captcha_sessions'\nquery: UPDATE mafeco_captcha_sessions SET timestamp=1487816795, solution='8iCmd' WHERE csid=0\";s:5:\"%file\";s:44:\"/home/mafeco/www/modules/captcha/captcha.inc\";s:5:\"%line\";i:111;}', 3, '', 'http://www.mafeco.fr/?q=node/250', '', '54.144.194.161', 1487816795) in /home/mafeco/www/includes/database.mysql.inc on line 128

Warning: INSERT command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_watchdog' query: INSERT INTO mafeco_watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:7:\"warning\";s:8:\"%message\";s:97:\"array_map() [<a href=\'function.array-map\'>function.array-map</a>]: Argument #2 should be an array\";s:5:\"%file\";s:45:\"/home/mafeco/www/modules/system/system.module\";s:5:\"%line\";i:958;}', 3, '', 'http://www.mafeco.fr/?q=node/250', '', '54.144.194.161', 1487816795) in /home/mafeco/www/includes/database.mysql.inc on line 128

Warning: INSERT command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_watchdog' query: INSERT INTO mafeco_watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:7:\"warning\";s:8:\"%message\";s:107:\"array_keys() [<a href=\'function.array-keys\'>function.array-keys</a>]: The first argument should be an array\";s:5:\"%file\";s:35:\"/home/mafeco/www/includes/theme.inc\";s:5:\"%line\";i:1712;}', 3, '', 'http://www.mafeco.fr/?q=node/250', '', '54.144.194.161', 1487816795) in /home/mafeco/www/includes/database.mysql.inc on line 128

Warning: INSERT command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_watchdog' query: INSERT INTO mafeco_watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:7:\"warning\";s:8:\"%message\";s:39:\"Invalid argument supplied for foreach()\";s:5:\"%file\";s:35:\"/home/mafeco/www/includes/theme.inc\";s:5:\"%line\";i:1712;}', 3, '', 'http://www.mafeco.fr/?q=node/250', '', '54.144.194.161', 1487816795) in /home/mafeco/www/includes/database.mysql.inc on line 128

Warning: INSERT command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_watchdog' query: INSERT INTO mafeco_watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:1023:\"UPDATE command denied to user &#039;mafeco&#039;@&#039;10.0.95.113&#039; for table &#039;mafeco_cache_menu&#039;\nquery: UPDATE mafeco_cache_menu SET data = &#039;a:2:{s:4:\\&quot;tree\\&quot;;a:7:{i:134;a:2:{s:4:\\&quot;link\\&quot;;a:37:{s:14:\\&quot;load_functions\\&quot;;s:0:\\&quot;\\&quot;;s:16:\\&quot;to_arg_functions\\&quot;;s:0:\\&quot;\\&quot;;s:15:\\&quot;access_callback\\&quot;;s:11:\\&quot;user_access\\&quot;;s:16:\\&quot;access_arguments\\&quot;;s:32:\\&quot;a:1:{i:0;s:14: in /home/mafeco/www/includes/database.mysql.inc on line 128

Warning: INSERT command denied to user 'mafeco'@'10.0.95.113' for table 'mafeco_watchdog' query: INSERT INTO mafeco_watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:375:\"UPDATE command denied to user &#039;mafeco&#039;@&#039;10.0.95.113&#039; for table &#039;mafeco_cache_menu&#039;\nquery: UPDATE mafeco_cache_menu SET data = &#039;a:2:{s:4:\\&quot;tree\\&quot;;a:0:{}s:10:\\&quot;node_links\\&quot;;a:0:{}}&#039;, created = 1487816795, expire = 0, headers = &#039;&#039;, serialized = 1 WHERE cid = &#039;links:secondary-links:page:node/250:1&#039;\";s:5:\"%file\";s:35:\"/home/mafeco/www/includes/cache.inc\";s:5:\"%line\";i:109;}', 3, '', 'htt in /home/mafeco/www/includes/database.mysql.inc on line 128
Cheap talk et communication sur les risques nucléaires | Mafeco

Cheap talk et communication sur les risques nucléaires

Retour sur un événement survenu il y a quelques semaines, avec mes excuses pour le retard. Le 12 avril donc l’incident de Fukushima a franchi le niveau 7 de l’échelle INES, après avoir franchi les uns après les autres les 7 échelons. Le tout dans une certaine suspicion quant au fait que sûrement « on » nous cache quelque chose en cherchant depuis le début à minimiser la gravité de l’incident.

Cette suspicion est en soi problématique : si en cas d’accident nucléaire modéré les autorités compétentes annoncent un accident modéré, et que tout le monde panique en étant persuadé que pour annoncer cela les autorités doivent être au courant de quelque chose de bien plus grave, que faire ? Annoncer quelque chose d’encore moins grave, au risque de renforcer encore la suspicion ?

Nous sommes devant un cas que les économistes qualifient de « cheap talk » : un agent (ici les autorités) détient une information sur un événement, et doit envoyer un message à un deuxième agent (ici la population) qui selon l’événement qui s’est produit va prendre telle ou telle décision (par exemple fuir Tokyo dans l’hypothèse la plus grave, les environs plus ou moins éloignés sinon). Les autorités ont intérêt à informer au moins partiellement la population. Si l’incident est suffisamment grave elles peuvent désirer évacuer les lieux dans un certain rayon autour de la centrale, et donc communiquer un certain niveau de gravité. Mais il est probable aussi que la population soit prête à prendre un peu moins de risque que les autorités, et à un niveau d’alerte donné prenne de leur point de vue trop de précautions (à l’extrême les habitants de Tokyo s’enfuient dans la panique générale).

Autrement dit les intérêts des deux « joueurs », autorités et population, sont alignés, mais imparfaitement : la population réagit un peu plus que les autorités ne le voudraient, ce qui fonde les soupçons que les autorités essaient de minimiser l’incident.

L’article classique étudiant ce genre de problèmes est celui de Crawford et Sobel (« Strategic Information Transmission », Econometrica, 1982), qui étudie le problème général d’un « envoyeur » et d’un « receveur » (de messages), le premier correspondant ici aux autorités et le deuxième à la population. On peut penser à d’autres exemples : la notation de titres financiers, ou de copies, les avis d’experts sur différentes questions, certains cas de communication politique…

Toute une « littérature » s’est développée suite à l’article original, qui contient déjà de nombreuses idées intéressantes. La première est qu’il existe toujours dans ce type de situation un équilibre « babbling » (qu’on pourrait traduire par « babillant », ou « blablateur »), qui caractérise souvent la communication politique : partant du principe que « les chiffres on leur fait dire ce qu’on veut », on peut n’accorder qu’une faible crédibilité aux chiffres mesurant l’évolution du chômage ou de la criminalité. Justement cela n’incite guère à ne pas les tripatouiller puisque de toute façon leur crédibilité est faible, et le tripatouillage en retour justifie une attitude sceptique. Un autre exemple proche est celui de l’inflation des notes : si on met A ou très éventuellement B à tous les étudiants, comme apparemment dans beaucoup d’endroits aux Etats-Unis, les recruteurs n’accorderont qu’une faible importance au signal qu’est la note et regarderont d’autres critères (par exemple animation ou non de camps scouts pendant les vacances, et autres révélateurs de qualités essentielles en entreprise). Sachant que les notes n’ont aucune importance, les professeurs ont alors tout intérêt à mettre A ou B à tout le monde, ça fait plaisir aux étudiants et ça évite de passer trop de temps à corriger les copies. Du coup il est rationnel pour les recruteurs de ne pas faire attention aux notes, et la boucle est bouclée.

Un tel équilibre existe toujours, la question est de savoir si l’on peut faire mieux. Un premier résultat est qu’on ne peut jamais arriver à la situation optimale (pour la population au moins), qui serait de toujours révéler exactement l’information. Prenons l’exemple du décompte d’une manifestation par un syndicat (ou par la police, en inversant les incitations) : supposons que le syndicat donne toujours le chiffre exact des manifestants. Dans ce cas si un syndicat annonce 200.000 manifestants, il faut croire ce chiffre. Mais le syndicat sait qu’en annonçant plutôt 201.000 il sera cru aussi, et il sera bien difficile de mettre en cause ce chiffre. Il est toujours très facile de gonfler un tout petit peu les chiffres. Mais une personne entendant le chiffre de 201.000 devrait précisément anticiper cette incitation, et donc toujours réduire un peu le chiffre annoncé. Ce qui ne fait que donner encore plus d’incitations à annoncer un chiffre élevé, etc.

Deuxième idée importante donc : un message (ici des chiffres) trop précis ne peut pas être totalement crédible, il y a toujours trop d’incitations à mentir « un peu ». Rappelons au passage que les agences de notation délivrent toujours des notes sur une grille discrète (AA, BB etc.) alors même qu’elles disposent d’outils leur donnant une mesure continue (typiquement une probabilité estimée qu’une entreprise ou un Etat donnés fassent défaut à un horizon d’un an). C’est un héritage de l’époque où de telles mesures continues n’existaient pas, mais peut-être perdure-t-il parce que les investisseurs ne se font pas trop d’illusions sur les incitations des agences de notation à ne pas essayer de baisser un peu leurs estimations de quelques points de pourcentage.

Enfin, est-il possible de révéler de l’information « pas trop précise » ? La réponse est oui. L’idée est de forcer les autorités si elles mentent à mentir vraiment beaucoup, tellement qu’elles n’ont jamais envie de le faire. Dans le cas de la sécurité nucléaire on pourrait à l’extrême envisager une échelle avec seulement deux niveaux : le deuxième ne serait atteint qu’en cas d’explosion imminente, le premier irait de la situation normale jusqu’à des incidents très graves mais ne nécessitant pas une évacuation immédiate. Avec seulement ces deux messages à leur disposition, les autorités n’ont jamais envie de mentir : tant qu’effectivement la situation ne nécessite pas une évacuation immédiate elles n’ont pas de raison de provoquer une panique, inversement quand cette évacuation est nécessaire elles n’ont plus de raison de minimiser l’incident.

On peut faire mieux, avec davantage de niveaux d’alerte, et donc une communication plus précise. L’un des résultats de Crawford et Sobel est que pour soutenir un équilibre avec un plus grand nombre de niveaux d’alerte, il faut que les intérêts de « l’envoyeur » et du « receveur » soient davantage alignés. En effet plus on multiplie les niveaux, plus on augmente la tentation de mentir un petit peu en choisissant le niveau d’alerte juste en-dessous de celui correspondant à la situation réelle.

Un autre résultat qu’il serait intéressant d’appliquer au cas présent est que les différents niveaux ne sont pas symétriques. Ici il va falloir détailler un peu plus. Supposons que le vrai risque puisse être estimé assez précisément par les autorités sur une échelle de 1 à 100, mais que celles-ci ne communiquent qu’un indicateur allant de 1 à 5. Par exemple quand le risque est entre 90 et 100, les autorités annoncent l’indicateur maximal de 5. La tentation est forte de mentir quand le risque est exactement de 90, en quel cas annoncer un indicateur de 5 affolera la population plus que de raison (celle-ci pensera que le risque est quelque part entre 90 et 100, alors qu’il est juste de 90). Si le risque est uniformément réparti (espérons que ce ne soit pas le cas pour les risques nucléaires), les autorités annonceront l’indicateur prévu lorsque le vrai risque est de 90 seulement à condition que mentir et annoncer 4 soit beaucoup trop loin de la réalité. Toujours sous l’hypothèse d’une distribution uniforme il faut que le niveau 4 corresponde à une gamme plus étendue de risques, par exemple entre 75 et 90. En annonçant 4 les autorités feraient croire que le risque est en moyenne de 82,5, ce qui est peut-être beaucoup plus bas que ce que les autorités désirent. Si leur incitation à mentir est plus forte, il faut encore augmenter l’intervalle, entre 65 et 90 par exemple. Mais le problème se repose au niveau 4 : là encore si 4 est censé correspondre à 75-90, lorsque le vrai risque est de 75 la tentation est forte d’annoncer 3. Pour éviter cette tentation, il faut que 3 corresponde à des risques encore plus bas, par exemple 55-75. Et ainsi de suite.

Au final, une échelle crédible devra ressembler à quelque chose comme ça, notons que dans cette échelle par exemple on ne signalerait jamais à la population un petit écart à la normale :

A comparer avec l’échelle INES :

Bien sûr dans l’exemple de la sécurité nucléaire il faut beaucoup complexifier le modèle : distribution non uniforme des risques, information plus importante à faire passer à certains niveaux plus qu’à d’autres etc. On en retire tout de même l’idée que lorsque les autorités ont une incitation à sous-estimer le risque, une échelle servant de base à la communication pour être crédible devrait être très détaillée pour les niveaux de risque les plus élevés, et beaucoup plus vague pour les niveaux de risque faibles. Or il me semble que dans le cas présent c’est exactement le contraire : on met dans le même sac Fukushima et Tchernobyl, mais on distingue plusieurs niveaux sans danger sanitaire pour la population.

On comprend facilement pourquoi il en est ainsi : l’échelle INES était probablement au départ destinée aux ingénieurs, afin de classer les cas possibles en fonction d’événements faciles à observer, et prévoir des procédures à appliquer rapidement dans chaque cas. De ce point de vue il n’était pas très utile de détailler au-dessus du niveau 7 car il s’agit d’événements très rares qui ne pourront vraisemblablement être traités qu’au cas par cas, alors que les accidents mineurs seront plus fréquents, et il sera peut-être plus important de pouvoir y réagir très vite avec des procédures codifiées. Le problème c’est que les journalistes, toujours à chercher la façon la plus rapide et la plus directe de communiquer l’information (et il faut les en remercier, imaginez le temps qu’on perdrait sans ça…) sont assez prompts à publier ce type d’indicateurs, qui dès lors deviennent des enjeux de communication politique. Or une échelle construite de cette manière est justement d’après le modèle évoqué plus haut très peu crédible dès lors que des possibilités de manipulation existent.

Il serait intéressant soit de réfléchir au problème de la crédibilité lors de la construction même de l’échelle (on peut aussi penser aux niveaux d’alerte Vigipirate, aux alertes météo…), soit d’avoir deux échelles : une à destination du public, et une à usage interne, mais dont le secret devrait être jalousement gardé (sans quoi la bonne échelle chasserait la mauvaise, ce qui rendrait mauvaise la bonne, selon la loi de Gresham des échelles).

L'échelle INES correspond

L'échelle INES correspond exactement à l'hypothèse que vous faîtes : chaque niveau de problème correspond à un niveau de risque "acceptable", le passage d'un niveau de problème à un autre correspondant à une probabilité d'occurence divisée/multipliée par 10.

Par contre, concernant la coexistence de deux échelles, est-ce qu'elle ne risque pas d'alimenter la paranoïa (du genre "ils disent que c'est normal ou écart alors qu'en interne ils parlent d'incident !) ?

Bonne remarque

Merci pour cette remarque, pour l'exposition j'ai préféré coller au modèle standard de cheap-talk, mais c'est vrai qu'effectivement l'échelle INES est plus détaillée en haut qu'en bas en termes de fréquence des événements. Ce que j'avais en tête, et qui doit être à peu près similaire en termes de résultats, c'est qu'elle est bien plus détaillée en bas qu'en haut pour ce qui concerne la gravité des événements et la réaction de la population. En gros de 1 à 2 voire 3 même les voisins de la centrale n'ont rien à changer dans leur comportement, ce qui donne beaucoup d'incitations à attendre un peu pour déclarer une incident sur l'échelon 1 en espérant qu'il soit très vite réglé. Inversement tout en haut de l'échelle si on distinguait entre un niveau Fukushima et Tchernobyl il est probable que les autorités ne souhaiteraient pas minimiser un incident de type Tchernobyl en le faisant passer pour un Fukushima (difficile de justifier l'ampleur des évacuations nécessaires), et inversement. En ce sens je pense qu'on peut trouver l'échelle "trop détaillée en bas, pas assez en haut" pour être crédible. Evidemment pour le prouver il faudrait étendre le modèle à des distributions non uniformes et des fonctions objectif assez spécifiques.

Pour la coexistence de deux échelles c'est évidemment un gros problème. Il faudrait peut-être que même l'existence de l'échelle secrète soit secrète, ce qui pose aussi d'autres problèmes...

Léna, je veux bien croire que

Léna, je veux bien croire que l'échelle INES a été construit avec une probabilité d'occurence divisée / multipliée par 10, mais il y a dans ce cas un vrai problème.

Si on reprend la liste des incidents (bien sûr pas exhaustive mais sans doute représentative au moins pour les derniers niveaux) on à 2 incidents niveau 7, 1 incident niveau 6 et 5 incidents niveau 5 : http://en.wikipedia.org/wiki/International_Nuclear_Event_Scale

Plus fondamentalement, j'ai du mal à comprendre l'intérêt d'établir ses échelles. Avec l’échelle, les autorités sont liées. Grosso-modo, à chaque niveau, il faut prendre un certain nombre de mesures particulières potentiellement couteuses. Inversement, les habitants attendent des autorités qu’elles prennent les mesures qui s’imposent en fonction du niveau retenu.

A Fukushima, on a eu le contraire. Un relèvement progressif de la gravité de l’incident, non pas en fonction de ce qui se passait sur le terrain, mais de la capacité des autorités à exécuter les mesures prévues.

Un billet qui me rappelle

Un billet qui me rappelle celui sur les cascades informationnelles que j'avais dévoré à la découverte du blog [RCE à l'époque] . Vraiment bon.

Poster un nouveau commentaire

Le contenu de ce champ ne sera pas montré publiquement.
CAPTCHA
Devant la recrudescence des spams j'ai dû augmenter la difficulté des Captchas. Veillez à enregistrer votre commentaire avant de soumettre votre réponse, au risque de perdre ce que vous avez écrit !
CAPTCHA visuel
Entrez les caractères (sans espace) affichés dans l'image.