Compter automatiquement les mots prononcés sur les chaînes d'information continue

Posté par  . Édité par Benoît Sibaud, Arkem, Xavier Teyssier, Pierre Jarillon et palm123. Modéré par NeoX. Licence CC By‑SA.
Étiquettes :
100
31
déc.
2021
Audiovisuel

Cette dépêche, issue d'un journal, traite d'un système d’acquisition, de reconnaissance vocale et une base de donnée des mots prononcés sur les chaînes d’information continue de la Télévision Numérique Terrestre française (TNT). Je présente aussi des résultats obtenus sur quelques candidats à l'élection présidentielle française et quelques thèmes d'actualité.

Le code est disponible sous licence AGPL.

Sommaire

Introduction

Ces dernières années en France, le traitement de l’information par les médias grand public a fait l’objet de virulents débats, notamment durant la crise des gilets jaunes. Il est souvent reproché aux médias d’être inféodés aux élites politiques ou économiques et de pousser leur propre agenda. En conséquence, une partie des citoyens se sont détournés de ces médias au profit des réseaux sociaux ou bien de médias alternatifs. Cependant, les chaînes d’information continue restent une des sources principales d’information d’une partie des français et la concurrence est rude entre elles. Cela les amène parfois à faire de la surenchère sur des sujets clivants pour générer du buzz et grignoter des parts de marché.

Nous sommes actuellement en France en période de campagne pour l’élection du président de la république. C’est un moment d’effervescence médiatique car il s’agit, dans les institutions actuelles, de l’élection reine qui risque de donner la ligne politique des cinq prochaines années.

J’ai pensé que cette période était une bonne occasion pour mener une petite expérience. Il s’agit de compter durant une période de 17 jours (du 6 décembre 2021 au 22 décembre 2021) automatiquement tous les mots et noms prononcés. L’objectif est de regarder si on peut distinguer des tendances sur leur traitement de l'information.

Le système

Schéma global du système

Capturer les chaînes

Pour pouvoir compter automatiquement les mots sur des chaînes de télévision, il faut déjà avoir un moyen d’acquérir le signal diffusé par ces chaînes. Celles qui nous intéressent sont disponibles sur la TNT (Télévision Numérique Terrestre) française. Elles sont sans doute aussi disponibles en streaming depuis leur site Web ou bien sur le réseau de mon FAI mais j’ai pensé que c’était potentiellement plus rigolo et fiable de passer par le signal hertzien.

La TNT en France utilise la norme DVB-T (norme Digital Video Broadcasting version terrestre). Les chaînes sont diffusées sous format numérique à l’intérieur de multiplexes. Chaque multiplex est diffusé sur sa propre fréquence. Lorsque l’on souhaite regarder une chaîne, le tuner DVB-T se régle sur la fréquence du multiplex et commence à recevoir toutes ses données. Ces dernières sont ensuite démultiplexées pour sélectionner le ou les chaînes qui nous intéressent. Les flux vidéos sont encodés au format MPEG-4 AVC (H.264) tandis que les flux audios sont encodés en Dolby E-AC-3.

Pour les chaînes qui nous concernent, CNEWS et BFM TV sont diffusées sur le même multiplex tandis que Franceinfo et LCI sont diffusées chacune sur un autre multiplexeba. Pour analyser ces quatre chaînes, nous avons donc besoin de 3 tuners DVB-T.

Chose intéressante pour nous, il existe dans le commerce des cartes PCI express DVB-T 4 tuners. Ces cartes sont généralement bien supportées sous Linux par l’intermédiaire de l’API Video for Linux (V4L) car elles ont beaucoup d’utilisations professionnelles. J’ai donc opté pour une Hauppauge WinTV-quadHD. Sans trop me poser de questions, j’ai installé son driver propriétaire ainsi qu’un firmware pour que ça tombe en marche.

Pour contrôler les tuners de la carte DVB-T, j’ai choisi d’utiliser le programme dvbv5-zap du projet V4L. Son rôle est simple, par l’intermédiaire de l’API V4L du noyau, il va commander à chaque tuner de se régler sur une fréquence donnée, capturer tout le multiplex et le transmettre à FFMPEG par l’intermédiaire d’un pipe nommé (FIFO).

FFMPEG va ensuite démultiplexer les données du multiplex empaquetées au format MPEG-TS pour sélectionner juste les pistes audio des chaînes qui nous intéressent. Il va aussi décompresser ces pistes audio et les transmettre dans un format PCM brut au module de reconnaissance vocale.

Reconnaissance vocale

L’idée est ici de convertir nos données audio en mots pour pouvoir les stocker et les rechercher facilement dans une base de donnée.

J’ai dans un premier temps testé le projet DeepSpeech de Mozilla. Cette solution repose sur un réseau de neurone profond décrit dans le papier DeepSpeech de Baidu. Il est possible de trouver un modèle entraîné pour reconnaître du Français. Cependant les performances sur mes flux audio de chaînes de télévision ne se sont pas révélées qualitativement satisfaisantes.

J’ai donc testé dans un second temps le projet Vosk. Vosk repose sur le réseau de neurones nnet3 de Kaldi. Le projet Vosk distribue un modèle assez récent (octobre 2020) pour le français adapté du projet français LinTO qui est distribué sous licence AGPL. À noter que LinTO est un projet issu du « Programme d’investissements d’avenir », donc financé (en partie ?) par des fonds de l’état français. Il est piloté par la société Linagora.
Les résultats du modèle Vosk LinTO se sont révélés être de bien meilleure qualité. Le modèle est même assez fort pour reconnaître des noms propre de personnalités (ce que l'on va bien utiliser par la suite) et les ressortir avec la bonne orthographe. Je n’ai pas cherché mais je suppose qu’il a été au moins en partie entraîné avec des données d’actualités. Mais ces données d’entraînement ne doivent pas non plus être très récentes car il ne reconnaît pas du tout le mot "covid"…

Lemmatisation

La lemmatisation consiste à trouver pour un mot sa forme lexicale racine. Elle enlève toute conjugaison à un verbe ou bien les accords pour un adjectif. Par exemple le lemme de jolis, jolies, jolie ou joli sera joli.
La lemmatisation est souvent utilisée en analyse de texte car elle permet de regrouper ensemble des mots qui ont le mêmes sens. Pour notre système, on pourra ainsi compter l’utilisation d’adjectifs ou de verbes sans se soucier de leurs accords ou conjugaisons. La bibliothèque Spacy accompagnée d’un modèle pour le français permet de facilement faire cette opération.
Les noms propres ne seront bien sûr pas lemmatiser.

Stockage en base de donnée

J’ai choisi d’utiliser le framework Python de développement Web Django comme ORM simplement parce-que c’est le seul que je connaisse. Derrière, j’ai connecté une base de donnée PostgreSQL. La structure de la base de donnée est très simple. Une table principale « Words » stocke pour chaque entrée le mot, son lemme, sa date et heure de prononciation ainsi que la chaîne de télévision sur laquelle il a été prononcé.

Je me suis posé la question de savoir si un moteur de recherche comme Elasticsearch n’était pas plus adapté pour ce genre de tâches mais comme je ne connais pas bien… meh… flemme de chercher plus… Peut-être avez-vous une idée sur la question ?

Requêtage

La recherche se fait ensuite par l’intermédiaire d’une page Web aussi servie par Django. Vous noterez le soin mis dans le design de la page…

Interface de requêtage

L’interrogation de la base de donnée se fait aussi avec l’ORM de Django. La subtilité est que pour chercher des groupes de mots avec mon YOLO design de base de donnée, il faut faire des sous-requêtes par mots - chercher les mots X qui sont suivis juste après par le mot Y qui sont suivis juste après par le mot Z - avant d’agréger à la fin sous forme de comptes par dates et chaînes. Cependant, avec les bons indexes dans la base, ça fonctionne pour le moment avec des temps de réponse acceptables. Meh… On va dire que ça ira…
Comme résultats, la page affiche des graphes générés avec la bibliothèque Matplotlib.

Le code

Le code est disponible sur Github sous licence AGPL ici. Je m’excuse pour la faible quantité de documentation. Mais, comme ce projet repose sur pleins de superbes briques libres, il y a au final assez peu de code.

Comment ça tourne ?

Ce bazar a tourné étonnamment sans trop de problèmes pendant 68 jours avec un load de 1.5 sur une station de travail Dell T3600 équipée d’un Xéon E5-1620 à 3.60GHz et de 32 Go de RAM qui tourne sous Ubuntu server 20.04. J’ai récupéré cette machine grâce à un célèbre site de vente d’occasions entre particuliers. Mais, comme je n'avais pas bien testé (bah oui YOLO programming…), je me suis rendu compte au moment de publier la première version de ce journal qu'il y avait un gros bug dans l'enregistrement de la date et l'heure des mots. Cela rendait les graphes générés faux même si les comptes totaux étaient justes.

J'ai donc relancé une expérience d'acquisition. Cette dernière s'est interrompue toute seule un matin au bout de 17 jours par une série de messages se terminant par:
EXT4-fs (sda2): I/O error while writing superblock
J'imagine qu'il est possible de traduire ça en français par:
Cher père Noël, pourrais-tu s'il te plaît me déposer une nouveau SSD sous le sapin ?
Les données de la base semblant encore être lisibles (pour le moment), cela m'a permis tout de même de générer les graphes suivants.

Les résultats sur quelques candidats à la présidentielle

Le Conseil Supérieur de l'Audiovisuel (CSA) produit des rapports sur les temps de parole de chaque intervenant politique. Cependant, ils ne semblent pas s'intéresser aux nombres de fois qu'ils sont mentionnés. Comme je l’évoquais plus haut, le modèle de reconnaissance est qualitativement performant même sur les noms propres. On peut donc tenter de compter le nombre de fois que les candidats à l’élection présidentielle sont mentionnés.

Je tiens tout de même à préciser ici que les résultats suivants ne sont que des estimations. Le modèle reconnaissance vocale n’est pas parfait. Les comptes reportés ne sont donc certainement pas exacts.
Vosk fourni des chiffres d’évaluation du modèle mais je n’ai pas réalisé d’évaluation sur mes données.
Cependant, pour ma défense, je dirais qu’il n’y a à priori pas non plus de raison que le modèle fonctionne plus mal sur une chaîne que sur une autre. Je pense donc que l’on peut assez sereinement faire des comparaisons de chiffres entre chaînes.

Je vous propose donc de nous intéresser à 4 chaînes d'information continue de la TNT:

  • BFM TV chaîne privée du groupe Altice Média,
  • CNEWS chaîne privée du groupe Canal+,
  • France Info chaîne publique du groupe France Télévisions,
  • LCI chaîne privée du groupe TF1.

Voici les résultats sur quelques candidats à l’élection présidentielle par ordre alphabétique. Ces chiffres sont ensuite repris dans un tableau récapitulatif.

Arthaud

Arthaud

Hidalgo

Hidalgo

Jadot

Jadot

Le Pen

Le Pen

Macron

Macron

Mélenchon

Mélenchon

Montebourg

Montebourg

Pécresse

Pécresse

Poutou

Poutou

Roussel

Roussel

Zemmour

Zemmour

Récapitulatif

On peut aussi mettre tous ces chiffres dans un tableau pour tenter d’avoir une vision plus globale.

Orientation BFMTV CNEWS franceinfo LCI Total
Macron CD 3408 3737 3144 6296 16585
Zemmour D 2952 4724 2229 4826 14731
Pécresse D 2249 2514 1763 4794 11320
Le Pen D 832 1127 746 1659 4364
Hidalgo G 972 754 942 1231 3899
Mélenchon G 894 701 811 1084 3490
Jadot G 686 204 544 898 2332
Montebourg G 382 269 255 293 1199
Roussel G 104 76 190 97 467
Poutou G 74 14 10 30 128
Arthaud G 4 8 7 14 33
Total 12557 14128 10641 21222 58548

La première chose que semble nous indiquer ce tableau, est que LCI accorde plus d’importance que les autres chaînes aux candidats de l’élection présidentielle. À l’opposé, c’est France Info qui semble le moins en parler.
Ensuite, si l’on fait des groupes de candidats (gauche, centre droit et droite), et que l'on fait les comptes par groupe, on obtient le résultat suivant:

Gauche Centre droit Droite
11548 16585 30415

Même si l'on inclut pas le président en exercice, la balance semble pencher amplement du côté droit. Ce déséquilibre était aussi visible au travers des résultats de ma première expérience de 68 jours sur une période précédente ; celle à moitié plantée par mon bug.

Les résultats sur quelques thèmes d'actualité

Il est aussi possible de tester des thèmes d'actualité. Voici quelques exemples que j'ai jugé indicatifs:

Nucléaire
Immigration
Islam
Ukraine

Et la suite ?

Pour continuer cette étude, il pourrait être intéressant de s'intéresser aux cooccurrences de termes. Par exemple, combien de fois sur une chaîne le mot immigration est prononcé proche du mot sécurité. Le système pourrait aussi être étendu à d’autres chaînes de télévision et de radio, et pourquoi pas même aux sites Web d’information. Il devrait aussi être possible de rendre accessible à tous l’interface de recherche pour que chacun puisse faire ses analyses.

Et vous, qu’est-ce que cela vous inspire ?

P.S. : Si vous souhaitez que je teste une requête sur une personnalité, un mot ou une expression particulière, je pourrai mettre le résultat dans les commentaires si mon SSD veut bien encore un peu coopérer…

Divers

N. D. M. : quelques commentaires sous sur le journal résumés ici :

  • les candidats déclarés le sont en attendant l'officialisation et les 500 signatures de parrainages requises
  • une suggestion : classer les occurrences par heure, pour voir ceux qui trichent en accordant plus de temps à certaines personnes en pleine journée, et à d'autres à 3h du mat' (exemple)
  • taille de la base de données PostgreSQL : ~11 Go pour 17 jours, soit ~30 Mo / heure pour les 4 chaînes (SELECT pg_size_pretty( pg_database_size('lexicometer_db') );)
  • une autre suggestion : utiliser aussi le sous-titrage, lorsque disponible
  • une troisième suggestion : ajouter le canal R4 pour France2 + France5 + Arte
  • le choix d'AGPL vient du fait du modèle de reconnaissance vocale pour le français de Vosk

Aller plus loin

  • # Très intéressant !

    Posté par  . Évalué à 10.

    Article excessivement intéressant.

    En revanche, je n'ai pas compris si tous les mots étaient sauvegardés, même des "le", "je" ou "nuage" ou s'il y avait une liste de mots que le programme essayait de reconnaître.

    En tout cas, clairement une interface publique et une plus grande couverture de chaîne serait très intéressant à avoir.

    Si besoin d'aide pour la partie dev, contactez moi :)

    • [^] # Re: Très intéressant !

      Posté par  . Évalué à 4. Dernière modification le 03 janvier 2022 à 09:18.

      Article excessivement intéressant.

      Merci beaucoup !

      En revanche, je n'ai pas compris si tous les mots étaient sauvegardés, même des "le", "je" ou "nuage" ou s'il y avait une liste de mots que le programme essayait de reconnaître.

      Tous les mots reconnus par Vosk avec leur lemme sont enregistrés dans la base de donnée.

      En tout cas, clairement une interface publique et une plus grande couverture de chaîne serait très intéressant à avoir.

      Je pense aussi que ce sont les prochaines étapes. En revanche, j'hésite encore sur la forme que doit prendre l'interface publique :

      • une interface de recherche comme présentée ici. Mais, vu la conception de la base, j'ai peur que ça soit compliqué à héberger correctement pour que ça soit utilisable.
      • ou bien une interface qui affiche les tendances par interval de temps. Dans ce cas, les chiffres seraient pré-calculés.
      • [^] # Re: Très intéressant !

        Posté par  . Évalué à 4. Dernière modification le 04 janvier 2022 à 08:22.

        Tous les mots reconnus par Vosk avec leur lemme sont enregistrés dans la base de donnée.

        Petite question, puisque tu parles de lemmatisation, as-tu essayé celle intégrée dans PostgreSQL (voir la fonction ts_vector par exemple), puisque c'est là que tu stockes les résultats en fin de compte? Est-ce que Spacy, que je ne connaissais pas, donne des résultats sensiblement meilleurs?
        En plus ts_vector a le bon goût de supprimer les mots vides (articles, conjonctions, etc.) pour que ne garder que les lemmes réellement significatifs.

        A la base les lemmatiseurs de PostgreSQL sont basés sur Snowball, une bibliothèque de lemmatiseurs utilisée un peu partout, mais tu peux aussi intégrer ISpell à condition de télécharger les dictionnaires séparément.

      • [^] # Re: Très intéressant !

        Posté par  (Mastodon) . Évalué à 5.

        J'ai eu connaissance par hasard d'une étude de même type réalisée par un chercheur de l'INA (voir https://www.herve.name/presidentielle).

        Y a-t-il un lien entre les deux initiatives ?

      • [^] # Re: Très intéressant !

        Posté par  (site web personnel) . Évalué à 3.

        Au niveau moteur de recherche https://quickwit.io/ semble bien indiqué pour chercher des mots dans des To de données.

        "La première sécurité est la liberté"

  • # Contenu idéal pour une TSDB

    Posté par  . Évalué à 5.

    Étude très intéressante. Pour le stockage des données je pense qu'une base de données de séries temporelles (TSDB) serait idéale, elle permettrait de faire facilement tout un tas de manipulation comme la proximité des termes, la densité, etc etc.

    À disposition si l'expérimentation vous tente.

    • [^] # Re: Contenu idéal pour une TSDB

      Posté par  (site web personnel) . Évalué à 5.

      Je ne vois pas pourquoi Postgresql ne conviendrait pas. Les procédures stockées permettent de dater automatiquement les événements. Quelques lignes de plpgsql pour faire un trigger et le tour est joué.

      • [^] # Re: Contenu idéal pour une TSDB

        Posté par  . Évalué à 4.

        Les aggregations et les materialized views de postgres ne sont pas magiques. Un bon remplacement peut etre https://www.timescale.com/, notamment parce que c'est base sur postgres, mais attention ce n'est pas libre. J'imagine que le portage depuis un projet django devrait etre assez simple.

        Une autre bonne alternative c'est ClickHouse, mais je ne sais pas si il y a des integrations depuis django.

        • [^] # Re: Contenu idéal pour une TSDB

          Posté par  . Évalué à 4. Dernière modification le 01 janvier 2022 à 23:03.

          Un bon remplacement peut etre https://www.timescale.com/, notamment parce que c'est base sur postgres, mais attention ce n'est pas libre.

          https://www.timescale.com/legal/licenses

          TimescaleDB Open Source is made available under the Apache 2.0 License

          • [^] # Re: Contenu idéal pour une TSDB

            Posté par  . Évalué à 6. Dernière modification le 02 janvier 2022 à 16:51.

            Franchement, ta réponse n'est pas honnête. Voici le texte en entier :

            TimescaleDB available under the following licenses:

            TimescaleDB Open Source is made available under the
            Apache 2.0 License
            TimescaleDB Community is made available under the
            Timescale License ("TSL")

            Tu as clairement tronqué la partie intéressante, car évidemment la TSL n'est pas libre, mais contient les morceaux les plus intéressants. Désolé, mais c'est difficile de ne pas y voir de la mauvaise foi.

            C'est une attitude que je trouve vraiment pénible sur LinuxFr, honnêtement, je la trouve pas tellement sur d'autres forums, et je vois pas trop quoi faire pour lutter contre ça a part être désagréable.

            • [^] # Re: Contenu idéal pour une TSDB

              Posté par  (site web personnel) . Évalué à 4.

              Pour ceux qui se demandent

              Voilà leur comparaison des fonctions dispo ou pas selon les versions

              https://docs.timescale.com/timescaledb/latest/timescaledb-edition-comparison/#feature-comparison

            • [^] # Re: Contenu idéal pour une TSDB

              Posté par  . Évalué à 5.

              Wow. C'est pas de la mauvaise foi. J'étais pressé et j'ai juste mis un lien rapide avec juste le minimum.

              J'utilise Timescale sur un projet et en voyant ton message j'ai eu peur d'avoir raté quelque-chose sur la licence donc je suis allé voir et j'ai été rassuré.

              Effectivement, la version libre n'a pas toutes les fonctionnalités, je sais pas si je dois m'en inquiéter ou pas sur le long terme.

              En tout cas mon message n'était pas plus faux que le tien qui disait que c'était pas libre, quand-même. J'ai juste pas pris le temps de détailler.

              • [^] # Re: Contenu idéal pour une TSDB

                Posté par  . Évalué à 5.

                Wow. C'est pas de la mauvaise foi. J'étais pressé et j'ai juste mis un lien rapide avec juste le minimum.

                J'utilise Timescale sur un projet et en voyant ton message j'ai eu peur d'avoir raté quelque-chose sur la licence donc je suis allé voir et j'ai été rassuré.

                Ca marche, j'ai peut etre sur-reagi. Avec ton explication, j'ai l'impression que tu as vu un vague truc en licence apache, et tu en conclus que c'est bon.

                En realite, si tu es parti directement sur l'image docker ou les paquets fournis sur le site officiel, pour moi ca utilise la version non libre et tu devrais prendre connaissance de la licence TSL.

                En tout cas mon message n'était pas plus faux que le tien qui disait que c'était pas libre, quand-même.

                Pas de package fourni pour la version open-source, pas de refresh en continu des materialized views et les 3/4 des aggregates ont ete enleves. En gros, la version open-source c'est les aggregates first et last… En vrai, autant partir sur postgres.

                Pour moi, on est dans un joli exemple bien trompeur d'open source/freeware a licence proprietaire. Mais bon, on commence a s'habituer dans le monde des bases de donnees.

                • [^] # Re: Contenu idéal pour une TSDB

                  Posté par  . Évalué à 3.

                  Effectivement, c'était confus pour moi. Je viens de vérifier et le paquet fourni dans leurs dépôts (celui que j'utilise) est bien celui de la version "Community", qui est couvert par leur licence "TSL".

                  Je crois pas utiliser les fonctionnalités supplémentaires et je sais pas si j'en aurai besoin un jour, mais en tout cas j'utilise le packaging officiel.

                  Au final, je rentre dans le cadre de la version TSL : j'utilise la base dans une application, potentiellement je pourrais vendre un service utilisant l'application, mais je vends pas de la base de données.

                  Reste que c'est pas 100% libre, OK.

                  Peut-être qu'on aurai pu partir sur postgres. Pour être honnête, j'ai pas fait de benchmark. Et on était intéressés par certaines fonctionnalités, notamment time_bucket (qui est dans la version libre).

                  • [^] # Re: Contenu idéal pour une TSDB

                    Posté par  . Évalué à 6.

                    Au final, je rentre dans le cadre de la version TSL : j'utilise la base dans une application, potentiellement je pourrais vendre un service utilisant l'application, mais je vends pas de la base de données.

                    Reste que c'est pas 100% libre, OK.

                    Un point pas clair dans cette licence, c'est si tu veux héberger ton service on-prem chez le client. Ca ne semble pas être un souci avec cette licence tant que le client ne fait pas de requête lui même, mais je n’étais pas assez confiant personnellement dans mon anglais juridique pour faire tourner un projet avec ca.

                    Au final, on est partis sur un postgres, et tant pis si les perfs sont moins bonnes, on fait avec et au moins c'est libre.

  • # Epatant

    Posté par  . Évalué à 7.

    Formidable article! plein de bonnes idées dedans. Mille merci pour ce travail inspirant.

  • # Un très grand bravo pour le travail accompli

    Posté par  . Évalué à 9.

    J'ignore si le CSA dispose d'outils équivalents mais quels que ce soient ces outils je me doute qu'ils lui sont revenus à plusieurs millions d'euros.
    Alors qu'en faisant simple, astucieux et open source on parvient au même résultat et à un résultat tout aussi professionnel en investissant modérément (pour une plateforme plus solide).

    Bref, il serait intéressant de profiter de la plateforme afin d'effectuer pas mal de statistiques.

    Ainsi, outre la notion de distance entre 2 mots prononcés et l'étude par horaire et jour (ouvrés, non ouvrés) qui ont été suggérés, je pense à la tonalité d'une chaîne.
    Rien de sensationnel, on les connaît.
    Mais bon, chiffré cela prend une dimension plus concrète.

    Déjà on note que les sujets clivants (islam, immigration) sont portés par certaines chaînes et pas du tout par d'autres.
    On pourrait ainsi distinguer les chaînes dont l'activité s'appuie essentiellement sur la polémique, celles dont l'activité s'appuie sur le documentaire, sur la science, sur l'information, etc.

    Ensuite, je pense à des analyses plus fines comme l'analyse contextuelle. Cette analyse venant apporter de l'eau au moulin de l'analyse précédente.

    Ainsi, utiliser un mot comme couteau n'a pas la même portée s'il est prononcé dans un journal ou dans un reportage sur la coutellerie à Thiers.

    Autres suggestions :
    - le faire dans d'autres langues et comparer ;
    - attribuer une note.

    Voilà,
    Encore bravo !
    db

  • # classification des candidats d'extrême droite

    Posté par  . Évalué à 2.

    Félicitations pour ce projet important, pour ne pas dire de salubrité publique.

    Une question sur un point qui me gène néanmoins : est-il raisonnable de classer M. Le Pen et E. Zemmour à droite plutôt qu'à l'extrême droite ?

    S'il s'agit d'une volonté de simplification, pourquoi alors avoir choisi de nuancer la classification d'E. Macron au centre droit plutôt qu'à droite, sans avoir classé poir autant par exemple A. Hidalgo ou Y. Jadot au centre gauche ?

    • [^] # Re: classification des candidats d'extrême droite

      Posté par  . Évalué à 3.

      Si on classe G, C, D, ED, ça donne environ G: 11000, C: 16000, D: 11000, ED: 19000 (dont 4000 pour Le Pen). Du coup c'est équilibré si on retire Zemmour (en admettant un bonus "normal" pour l'exécutif).

      Ce qui me surprend le plus, c'est la synchronisation des courbes. Chaque chaîne a un biais, non seulement en terme de temps total accordé à la politique, mais aussi en équilibre droite-gauche. Par contre, toutes les chaînes sont synchro sur les politiques dont on parle le plus, ça veut dire que leur agenda est principalement dicté par l'actualité : Zemmour quand il montait dans les sondages, Pecresse lors de la primaire, etc. Les lignes éditoriales n'ont pas l'air très originales.

  • # Quelques biais...

    Posté par  . Évalué à 5.

    Alors, ici une liste de biais qui peuvent altérer les résultats. Je n'ai aucune idée de leur impact réel, c'est juste des points qui me viennent en tête.

    1) la publicité

    Je soupçonne que France Info en diffuse moins, voire beaucoup moins. Et que donc les sujets d'actualité sont moins noyés dans la masse. Plus une chaîne va diffuser de la publicité, plus la dilution sera conséquente. Peut-être est-il possible de gommer la publicité - j'imagine qu'il existe des outils pour ça ?

    2) ratios vs. valeurs absolues

    En lien direct avec le point précédent, compter le nombre de mots prononcés n'est pas nécessairement aussi pertinent que d'afficher des ratios. Évidemment, si le temps réel d'antenne (hors publicité, passage à une autre chaîne dans le cas de FranceInfo, défaillance technique, émission sportive) est plus faible, alors le nombre de mot sera plus faible. C'est donc la proportion qui est intéressante.

    Et dans ce cas, le filtrage du bruit (tous les mots de liaisons, les articles, etc…) devient essentiel j'imagine.

    3) les dépêches

    BFM, CNews ont une tendance à passer beaucoup d'informations en les diffusant sous forme de dépêches "textuelles" dans le bas de l'écran. Et avec un choix éditorial qui peut être très appuyé.

    D'ailleurs, je me demande bien ce que le CSA fait avec ça en période de campagne officielle. Quand un candidat est interrogé, et qu'ensuite pendant 2 ou 3 heures, les chaînes reprennent le message en bas d'écran toutes les 10 minutes pendant 1 minute, c'est du temps de parole ou pas ?

    En tout cas, c'est souvent du matraquage, donc dommage de ne pas pouvoir en tenir compte d'une façon ou d'une autre.

    4) le ton

    Quand dans un débat un participant reprend des idées mais en ironisant, le terme est certes utilisé, mais avec un effet "négatif". Par exemple, "cet autocrate ne sait parler que d'immigration et de sécurité" par un candidat d'extrême gauche, comment devrait-on le compter ?

    J'imagine que pour plusieurs de ces points, il peut être difficile voire impossible de trouver des solutions, et qu'il faut alors se contenter des résultats, mais en ayant conscience de ces biais avant de tirer des conclusions.

    • [^] # Re: Quelques biais...

      Posté par  . Évalué à 3.

      C'est clair que si tu passe sur le moment Meurice sur France info, tu vas entendre parler d'Islam, d'immigration et autre termes récurent de la droite, mais pas sur leur plus beau jour ;) C'est drôle, mais aussi désolant de voir qu'il est si facile de trouver des gens comme ça.

      Il ne faut pas décorner les boeufs avant d'avoir semé le vent

      • [^] # Re: Quelques biais...

        Posté par  (site web personnel) . Évalué à 4.

        mais pas sur leur plus beau jour ;)

        Je n'ai pas franchement l'impression qu'un discours de Ciotti en donne un meilleur profil.

        Adhérer à l'April, ça vous tente ?

      • [^] # Re: Quelques biais...

        Posté par  . Évalué à 2. Dernière modification le 03 janvier 2022 à 11:23.

        Mais il n’empêche que le sujet "immigration" est abordé. je ne vois aucun biais dans le comptage des mots dans les chroniques humoristiques ou non. Si le sujet est abordé c'est qu'il dans "l'air du temps".

        Petite digression. je suis fan des chroniques de Meurice, mais encore plus du "Journal de campagne" de Pierre Emmanuel Barré sur sa chaine YT.

        • [^] # Re: Quelques biais...

          Posté par  . Évalué à 4.

          Tout à fait, mais il faut en avoir conscience quand on lit les résultats.

          Ce n'est pas nécessairement un biais dans la collecte des données, mais dans leur interprétation.

  • # Je veux bien un Dump

    Posté par  (site web personnel) . Évalué à 5.

    Ce serait chouette d'avoir un dump à dispo, histoire de pouvoir manipuler un peu les données.

  • # Analyses suivantes

    Posté par  (site web personnel) . Évalué à 4.

    Superbe boulot, bravo!

    Quelques analyses supplémentaires qui ne devraient pas être trop dures à ajouter je pense:
    - Analyse de sentiment par sujet. Typiquement pour le nucléaire, il manque de savoir si c'est un sentiment d'angoisse qui en ressort, ou un sentiment d'espoir, ou autre
    - Analyse de sentiment global. (Est-ce que CNEWS est plus angoissant que France Info?)
    - Analyse par heure. Comme déjà mentionné un certain nombre de chaînes sont connues pour tricher leurs stats CSA en utilisant des horaires au milieu de la nuit

    Plus dur, et probablement moins utile:
    - Détection du sexe des interlocuteurs
    - Identification de la voix pour voir qui réutilise en permanence les mêmes "experts"
    - Détection de l'age basé sur la voix

  • # Très cool

    Posté par  . Évalué à 0.

    La question qui me turlupine au vu des stats sur les sujets, c'est: CNews est devenu réac… mais de quoi parle BFMTV?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.