Pourquoi il faut créer un microlangage de programmation pour journalistes

1. Le besoin

Vous le savez, nous tentons de faire vivre les articles du Temps le plus longtemps possible. A cet effet, nous avons développé Zombie, un outil qui identifie les contenus evergreen et nous indique le moment opportun pour les remettre en circulation. Se pose alors une question: lorsqu’on ressort un article de nos archives, faut-il l’actualiser? Jusqu’où ose-t-on le modifier? Quel temps investir dans ce travail?

Et si, au lieu de nous interroger après parution, nous concevions dès le départ certains articles dont des parties s’adaptent avec le temps, ou selon d’autres critères, aux attentes du lecteur? Sans parler de modifications substantielles, il s’agit de ces petits éléments de langage qu’il faut adapter, sans quoi ils font d’un texte un objet daté ou lui font perdre sa pertinence.

Et si nous imaginions un langage de programmation pour journalistes, expressément dédié à cet usage?

2. Le constat

Rien. Lorsqu’on cherche un langage de programmation qui soit adapté à ce cas de figure, on ne trouve rien. Il y a bien toujours un collègue pour assurer que le New York Times l’a créé, mais impossible de mettre la main dessus. L’idée n’est ni de transformer le journaliste en développeur – Python et PHP seraient alors les premiers sur la liste – ni de se restreindre à un langage de balisage (markup language) qui ne permet que de contrôler la mise en forme. On cherche quelque chose entre deux: des balises dans le texte qui modifient le contenu ou le génèrent. Si vous avez mieux cherché que moi, je suis preneur de tous les liens en commentaire.

Le but de ce «microlangage» serait de combler un vide. Entre les articles entièrement concoctés par des machines (le robot du Monde qui génère un texte pour les élections départementales, les articles automatiques fondés sur les sondages présidentiels américains, le remplaçant informatique du localier, etc) et ceux écrits et édités à l’ancienne (depuis les années 1980, le processus d’écriture n’a pas fondamentalement changé, à l’inverse de la manière de collecter l’info et de la diffuser), il n’y a rien. Or, on sent dans les salles de rédaction qu’une bonne partie des équipes possède des notions de programmation (au Temps, je dirais que c’est de l’ordre de 20% des effectifs) ou s’y intéresse. Ce «microlangage» serait accessible et exploitable dans un rythme quotidien, à l’inverse des vrais outils de programmation qui servent dans le cas d’enquêtes au long cours pour de la collecte et de l’analyse de données ou dans le cadre de vrais projets sur plusieurs semaines.

3. Quelques cas de figure

Les dates

«La 51e édition du Montreux Jazz festival a commencé hier», «Le 51e Montreux Jazz Festival s’est déroulé le mois passé»,«Le 51e Montreux Jazz Festival s’est terminé il y a 6 mois», etc.: tout journaliste web (romand) connaît les affres de l’actualisation de ces entames de papier. La plupart du temps, on opte pour une stratégie d’évitement: on élimine ces tournures pour éviter la modification de l’article. Et l’on perd alors ces petites accroches textuelles qui pourtant permettent au lecteur de se situer (c’est alors à lui de refaire le calcul dans sa tête: il déteste ça, je crois).

Imaginons pouvoir rendre dynamique le texte qui indique le temps qui s’est écoulé entre une date et le moment où l’article est lu:

Le 35e Montreux Jazz Festival s'est terminé [[affiche durée depuis: 16.07.2017]]. Son bilan est excellent.

La partie entre crochets sera remplacée pour le lecteur par l’affichage d’un texte:

Le 35e Montreux Jazz Festival s'est terminé hier.

Le 35e Montreux Jazz Festival s'est terminé avant-hier.

Le 35e Montreux Jazz Festival s'est terminé il y a 5 jours.

Le 35e Montreux Jazz Festival s'est terminé il y a 1 mois.

Le 35e Montreux Jazz Festival s'est terminé il y a un an.

Les conditions

Mais il y a une limite: difficile de demander à un langage de programmation d’adapter le temps des verbes ou les tournures d’un texte sans entrer dans une grande complexité technique. Et pourtant, c’est l’un des autres points que l’on remanie sans cesse lors de l’édition de contenus numériques: «Le Montreux Jazz festival commencera le 2 juillet 2017. Juste avant cette édition, nous avons interviewé son directeur.» On devra revoir ce début de texte si on estime que l’interview garde sa valeur après l’édition du festival et doit rester accrocheuse.

Ce bloc de texte s’affiche seulement si l’article est consulté avant le 2 juillet 2017:

[[affiche si date < 02.07.2017]]Le Montreux Jazz festival commencera le 2 juillet 2017. Juste avant cette édition, nous avons interviewé son directeur[[fin]]. - Mathieu Jaton, le festival vit une année charnière.

Et celui-ci après cette même date:

[affiche si date > 02.07.2017]Le directeur du Montreux Jazz Festival s'est livré au Temps quelques jours avant la 51e édition de la manifestation[[fin]]. - Mathieu Jaton, le festival vit une année charnière.

Les lieux

Le principe cynique du mort kilométrique, connu de toutes les rédactions, enjoint le journaliste qui cherche à attirer son lecteur de parler d’abord de phénomènes proches. Sans entrer dans le débat éthique, on peut utiliser un peu de technologie pour renforcer le sentiment de proximité: avec l’apparition des navigateurs modernes, il est facile de connaître assez précisément la position du lecteur. Cela permettrait d’adapter le texte:

Un tremblement de terre de magnitude 4,3 sur l'échelle de Richter s'est produit samedi matin près de Château-d'Œx, à [[affiche distance entre lecteur.lieu et "Château-d'Œx, Suisse"]] de [[lecteur.lieu]].

«Lecteur.lieu» est ici une manière de demander la géolocalisation du lecteur.

Résultat de ce code:

Un tremblement de terre de magnitude 4,3 sur l'échelle de Richter s'est produit samedi matin près de Château-d'Œx, à 89 kilomètres de Sion.

La monnaie

Souvent, on exprime les montants en euros, dollars, puis parfois leur équivalent en francs. Jamais l’inverse. Si le lecteur est en France (environ 30% du lectorat numérique du Temps), il n’aura jamais accès à un montant suisse exprimé en euros.

La filiale française du groupe bancaire suisse UBS a finalisé lundi l'acquisition de Banque Leonardo France pour [[3,2 millards $ en lecteur.monnaie]]

Ce qui aurait pour résultat pour un lecteur situé en Suisse:

La filiale française du groupe bancaire suisse UBS a finalisé lundi l'acquisition de Banque Leonardo France pour 3 millards de francs

Ou, pour un lecteur en France:

La filiale française du groupe bancaire suisse UBS a finalisé lundi l'acquisition de Banque Leonardo France pour 2,7 millards d'euros

[Note pour plus tard: le calcul du change doit se faire au moment de la publication, sous peine de fausser l’information en cas de fluctuation du taux.]

Il faudra aussi que l’auteur juge, en fonction du texte, s’il affiche le montant à la fois dans sa monnaie de base et dans celle du lecteur («20 francs suisses soit xx euros») ou s’il ne l’exprime que dans la monnaie du lecteur. Pour ce faire, il faudra utiliser une condition:

J'ai payé ma bière 5 francs 50[[affiche si lecteur.monnaie = CHF]](soit [[5.5CHF en lecteur.monnaie]]) [[fin]]. Un scandale!

4. Des fonctions plus avancées

Les informations sur le lecteur

L’utilisation d’une DMP, ces outils qui collectent des informations sur les visiteurs d’un site (au Temps, c’est Tealium), permettrait d’aller beaucoup plus loin. Ici, le débat éthique devient plus évident: jusqu’à quel point adapte-t-on un texte au profil (supposé) du lecteur? On peut connaître le sexe du lecteur, une estimation de son âge, etc. et adapter le texte en fonction de ces informations. A un lecteur qui a connu la présidence de Mitterand ou le «Non à l’Europe», il ne sera pas utile d’expliquer ces événements. A l’inverse, certains lecteurs plus âgés auront besoin d’explications lorsque l’on parle de Snapchat ou Rihanna. Ainsi:

Le mercredi 26 juillet 2017, Rihanna[[affiche si lecteur.age > 20]],la chanteuse de R&B née à la Barbade et première artiste à détrôner les Beatles en portant à 60 semaines le temps total passé en tête du classement américain avec ses chansons, [[fin]] enveloppée dans un costume pour le moins atypique, a été reçue à l'Elysée pour essayer de convaincre le président Emmanuel Macron de financer son fonds humanitaire pour l'éducation.

[Note pour plus tard: prendre en compte l’âge du lecteur à la parution de l’article et pas au moment de la lecture.]

Des variables déclarées par le journaliste

Une fois que les équipes éditoriales se seront faites aux premières options proposées par ce langage de programmation, on pourra passer à la phase 2: entrer un peu plus dans la programmation avec la déclaration de variables. Imaginons un texte consacré au chômage de différents pays francophones. L’auteur voudra que le texte soit «lecteur-centrique»: la base du texte doit être son pays de résidence et c’est au journaliste-programmeur de faire en sorte que toutes les informations s’y référent: ce sera l’étalon de l’article. Je propose de le faire en définissant les données de chômage dans des variables:

Canada.chomage.mars.2017 = 6.7%
Suisse.chomage.mars.2017 = 3.7%
France.chomage.mars.2017 = 9.8%
Belgique.chomage.mars.2017 = 6.9%

Canada.chomage.mars.2016 = 14%
Suisse.chomage.mars.2016 = 2%
France.chomage.mars.2016 = 10%
Belgique.chomage.mars.2016 = 5.8%

On pourra ensuite entamer l’article avec le bon pays:

Le taux de chômage en [[lecteur.position.pays]] s'est établi à [[lecteur.position.pays.chomage.mars.2017]] en mars 2017. C'est [[difference entre lecteur.position.pays.chomage.mars.2017 et lecteur.position.pays.chomage.mars.2016]] par rapport à l'année précédente.

Ce qui donnera:

Le taux de chômage en France s'est établi à 9.8 en mars 2017. C'est 0.2% de moins par rapport à l'année précédente.

Avec des conditions, on peut évidemment aller plus loin. Par exemple, comparer les pays entre eux:

[[Affiche si lecteur.position.pays.chomage.mars.2017 > *.chomage.mars.2017]]Le chômage en [[lecteur.position.pays]] est le plus élevé des pays francophones.[[fin]]

[[Affiche si lecteur.position.pays.chomage.mars.2017 < *.chomage.mars.2017]] [[lecteur.position.pays]] a le plus bas taux de chômage parmi les pays francophones.[[fin]]

Pour que cela fonctionne – pour que les journalistes utilisent cette fonction relativement complexe — il faudra que le langage soit assez souple et s’accommode de différentes manières de nommer, définir et retrouver les variables.

[Note pour plus tard: il faudra gérer le cas où le lecteur ne se situe pas dans un pays connu et proposer alors un texte «standard». Le plus simple est sans doute de dire, dans le cas du Temps, qu’on opte pour une approche «helvético-centrique»: tout lecteur dans un pays inconnu sera considéré comme étant suisse.]

5. Un point de départ technique

Après avoir discuté avec plusieurs développeurs sur Facebook, il semble y avoir un consensus: le point de départ serait de programmer un parseur en Python, puisqu’on ne cherche pas à développer un langage complet et évolué. En PHP, on pourrait aussi imaginer programmer un module WordPress ou Drupal qui permettrait à tout auteur de blog d’introduire quelques éléments automatisés dans son texte. Une partie du code pourrait aussi tourner en Javascript, côté client. Idéalement, à l’édition d’un texte, l’outil devrait fournir une assistance au rédacteur: auto-complétion, volet d’aide, etc.

La plupart des fonctions et options qui nous intéressent sont des versions simplifiées de celles qui sont proposées dans les langages de programmation courants (Datediff(), now(), if, etc.). Les variables sont en général livrées par un DMP ou le navigateur et accessibles en Javascript. Il est crucial d’ajouter un peu d’intelligence sur la donnée brute qui est fournie: si le temps qui s’est écoulé entre un événement et la date de lecture est très court, on peut l’exprimer en jours; puis on donnera des mois; enfin, des années. Idem pour les distances: on les exprime en centaines de mètres si elles sont courtes, ensuite en kilomètres, puis on arrondira à la dizaine de kilomètres. Et ainsi de suite.

6. Et l’unicité du texte, dans tout ça?

Le débat suscité par ce genre de projets concerne parfois la problématique de l’archivage: comment peut-on garder une trace d’un contenu qui n’est pas statique? Comment les lecteurs peuvent-ils comparer leur lecture d’un texte (par exemple dans leur discussion Facebook) s’ils n’ont pas accès au même, comment des chercheurs peuvent-ils citer un texte qui par nature sera mouvant? Au terme d’une passionnante discussion avec le professeur Frédéric Kaplan, à la tête du laboratoire des humanités digitales de l’EPFL, en 2016, j’ai obtenu des réponses.  Mené hors du cadre de ce projet, cet échange m’a convaincu que la question se poserait de plus en plus, même sans l’apparition de textes algorithmiques:

  • un texte est déjà, depuis quelques années, modifié plusieurs fois après sa mise en ligne initiale. Sans tenir de comptes précis, je pense qu’au Temps nous modifions un texte en moyenne 4 à 5 fois après sa première publication. Cela peut être beaucoup plus pour un evergreen, sans parler des «live» qui, par nature, sont évolutifs
  • des facteurs exogènes font que l’expérience de lecture sera différente pour chacun: navigateur utilisé, taille d’écran, réseau, présence d’un bloqueur de publicité, etc. On ne lira donc pas le contenu dans un même écrin, ce qui a un impact sur la lecture
  • des aspects propres au site web où le contenu est publié influeront aussi sur sa mise en ligne: quelle publicité a été livrée au moment de la lecture? Quels contenus liés ont été présentés en fin d’article, voire à l’intérieur? Des modifications dans la programmation du site ont-elles changé la mise en forme du contenu? Y a-t-il une nouvelle présence d’éléments disparates dans le texte (zone d’inscription à une newsletter, par exemple)?

La conclusion du professeur Kaplan? On devrait se pencher sur l’archivage d’une expérience de consultation et pas sur une essence de texte. Un peu comme on peut rejouer à un ancien jeu vidéo mais pas en archiver une partie…

Reste une question déontologique: doit-on indiquer au lecteur qu’une partie du texte a été créée de manière algorithmique? D’un côté, il me semble que la question n’intéresserait que les experts. De l’autre, j’estime que cela relève de la transparence nécessaire à l’instauration d’une confiance dans ces textes «semi-automatiques».

7. Une liste non exhaustives de fonctions, de variables et de conditions

Voici une première liste des options que devrait proposer ce «microlangage»:

1. [affiche nombre années | jours | mois depuis : 16.08.1983]
2. [affiche si date < 12.06.2017]
bla bla
[fin affiche]
1. [affiche si lecteur.position =vaud]
bla bla
[fin affiche]
2. [affiche distance entre lecteur.lieu et gland]
3. [si device = portable | ordinateur | tablette]
4. [si lecteur.age < 20].
5. [si écart entre dateparution et lecteur.date > 20]
6. [affiche 90CHF en lecteur.monnaie]

Les variables lecteur
1. lecteur.abonne
2. lecteur.sexe
3. lecteur.position
4. lecteur.lieu
5. lecteur.monnaie
… sont nourries par le navigateur, le DMP, les données du compte utilisateur.

Les variables techniques
1. navigateur.systeme
2. navigateur.device

La déclaration de variables: Jean = “1” ou Jean = homme.

8. Vos contributions

Pour le moment, ces quelques idées n’ont pas débouché sur un véritable projet. Elles ne sont pas mûres. Il y a certainement d’autres manières d’approcher la question, d’autres pistes de développement. C’est la raison d’être de cette note de blog: c’est avec votre aide que cette idée peut avoir un débouché.

Merci à Pat Jayet, Frédéric Sidler, Stéphane Koch pour leurs contributions.

Gaël Hurlimann

Gaël Hurlimann

Rédacteur en chef du numérique pour Le Temps et L'Hebdo

9 réponses à “Pourquoi il faut créer un microlangage de programmation pour journalistes

  1. Très intéressant, quelques remarques/avis.
    Les langages de markup sont exclus pour éviter certaines limitations, mais en fait au jugé des exemples cités, un langage de markup contextuel pourrait faire l’affaire. En fait ce serait plutôt du “templating” (contexte + formatage).

    Concernant la transparence, ce serait vraiment bien de mentionner les articles “augmentés” (avis perso).

    1. C’est bien de templating dont on parle.

      La principale difficulté technique à résoudre est “quand les variables sont évaluées”.
      Certaines peuvent l’être “coté serveur” (tout ce qui est lié au temps par exemple), et donc le serveur pourra renvoyer le “bon” contenu en HTML.

      D’autres sont à évaluer préférablement “coté client” (navigateur, OS), et nécessitent donc l’utilisation de javascript dans le navigateur pour afficher le bon texte.

      D’autres encore peuvent l’être de l’un ou de l’autre coté (client ou serveur) selon les choix techniques et éthiques (utilisation de la DMP, géolocation coté client ou coté serveur).

      Bref, un tel système de templates doit pouvoir donc générer en sortie du HTML et du javascript, tout en permettant une lecture correcte de l’article avec Javascript désactivé (pour l’accessibilité et le SEO).

      Une piste possible serait de tout faire en javascript (en utilisant une boite à outil de rendu coté client, de type React/Angular/VueJS), ce qui simplifierait la partie codage/gestion du système de template. Mais cette piste peut introduire pas mal de changements (et donc de travail) : nécessité de mettre en place un rendu React/Angular/VueJS coté serveur pour ne pas perdre en SEO/Accessibilité

  2. Passionant; cela pose aussi la question: à partir de quand et sous quels critères un article reste-il actuel (ou non daté), et quels articles doivent être considérés comme un momentum “-archivé” et ne gardant sa pertinence que “daté” (au même sens que contextualisé); les articles doivent-ils avoir une “migros data”? Cela demande un vrai travail d’édition dont la décision de base ne pourra jamais être déléguée à l’informatique.

  3. Il faut penser à des générateurs de périphrases et de lieux communs automatiques. Que serait le journaliste sans les périphrases et les lieux communs :
    “c’est un véritable séisme dans le landerneau des telecoms hexagonales. Le trublion Xavier Niel a lancé une offre mobile qui a littéralement bluffé ses concurrents en lançant un véritable pavé dans la mare, etc …”
    ou encore un lancement d’émission éco (les multilples virgules pour illustrer ce ton si,,,, caractéristique !):
    “A trente-huit ans,,,, Gaëtan pichard,,, est un homme heureux!
    Belle maison,,, voiture de sport,,, il a réussi.
    En effet, Gaëtan Pichard,,, est,,, ce qu’il est convenu d’appeler,,,, un véritable self-made-man!
    A vingt ans,,,, il part en voyage sac au dos,,, en Thaîlande.
    Et là!,,,,,,,,,,,,,,,,il a l’idée!
    Il achète,,,,, sa première usine”

    et bien sûr :
    “l’espadrille, retour sur les recettes d’un succès à la françaises qui a le vent en poupe”

    Ouaip, y’a des choses à faire pour créer un langage de programmation pour automatiser tout ça, mais quand je vois le niveau des journalistes, je me dis que ça n’est pas bien compliqué.

  4. Merci, c’est effectivement très intéressant.
    Sans entrer dans des questions, disons déontologiques, je suggère que vous regardiez les possibilités offertes par les langages de programmation pour l’IA, dont Wikipedia donne une liste quasi exhaustive (“https://en.wikipedia.org/wiki/List_of_programming_languages_for_artificial_intelligence”). Python y est cité en bonne place…

    Pour élargir le cercle de réflexion, vous pourriez poser votre question sous Qora, sur l’exemple de “https://www.quora.com/What-is-best-programming-language-for-Artificial-Intelligence-projects”.

  5. J’arrive un peu tard pour commenter ton post. Sur le plan technique, des personnes bien plus compétentes que moi ont déjà proposé des solutions, ou au moins des pistes.
    Il y a quelques années, un collègue à l’UNIL était responsable de rédiger un rapport tous les six mois dans lequel les chiffres pouvaient changer, mais la méthode pour les interpréter serait toujours la même. Je me souviens qu’il a consacré pour un de ces rapports deux fois plus de temps et l’a fait en Sweave (R + LaTeX). Les rapports suivants lui ont ensuite pris un temps ridicule et peut-être qu’il l’utilise encore. Dans le cas qui nous occupe, l’analogie que je vois est qu’en consultant le même article à deux dates différentes, même si la différence dans le texte est minime, il pourrait ne plus s’agir du même article… Est-ce qu’un article que l’on consulterait dix ans plus tard ne pourrait pas donner un résultat bizarre par exemple ? Plus le temps passe, plus il y aura d’éléments du texte à changer… Comment gérer ceci ?
    D’autres questions me viennent à l’esprit : comment créer une interface compréhensible pour les collaboratrice et collaborateurs ? Comment les convaincre de l’utiliser ? Quels codes utiliser pour que l’audience comprenne ce qui se passe ? (Indication en début d’article, formatage différent des parties dynamiques, etc.)
    Je vois déjà un très fort potentiel en matière d’easter egg qu’il serait dommage de ne pas exploiter. Au moins, tant qu’il y aura la version papier, on peut envisager que celle-ci serve d’archive de référence et que la version numérique soit plus laboratoire.
    (À discuter une prochaine fois !)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *