Why we should create a markup language for journalists

1. What we need

As you know, we’re trying to keep articles alive for as long as possible at Le Temps, a Swiss newspaper. That’s why we developed Zombie, a tool that identifies evergreen articles and lets us know when we should republish them. But when we pull an article from our archives, do we need to update it? How much can we change? And how much time should we put into this?

Instead of asking these questions once the articles have been published, what if we could create articles that already contained sections that could adapt to readers’ expectations over time or other criteria? Here, I’m not referring to changes in substance but rather smaller language-related aspects that need to be modified to prevent the text from becoming outdated or irrelevant.

And what if there were a programming language for journalists designed specifically for this purpose?

2. What we already have

Nothing. If you look for a programming language that serves this purpose, you won’t find one. You’ll find a colleague who assures you that the New York Times has created one, but there’s no way you’ll be able to get your hands on it. The idea is not to turn journalists into IT developers – if that were the case, Python or PHP could provide the solution – or to simply create a markup language that merely verifies the layout. I’m looking for something in-between: a programming language that can modify or generate content. If your search was more fruitful than mine, then I’ll happily take any links in comments.

The aim of this micro-language would be to fill the void between articles that are generated entirely by machine (like the articles that were automatically generated based on the results of presidential polls in the USA, or the software that replaced the journalist in charge of local news) and those written and edited in the conventional way (since the 1980s, the writing process has not changed in any fundamental way, unlike the processes for collecting and distributing information). Most journalist team members have some programming skills (at Le Temps, I’d say it’s around 20% of staff) or are interested in learning. This micro-language would be easy to use on a daily basis, unlike real programming tools that are better for long-running investigations to collect and analyze data or in real IT projects lasting several weeks.

3. Some examples


“The 51st edition of the Montreux Jazz Festival began yesterday”; “The 51st edition of the Montreux Jazz Festival was held last month”; “The 51st edition of the Montreux Jazz Festival ended six months ago”. Any web journalist knows how painful it is to update these opening statements. Most of the time, we simply sidestep the issue: we remove these turns of phrase to avoid having to update the article. As a result, we no longer have these little teasers that help readers find their bearings – instead the readers have to work things out on their own, which I’m sure they don’t like.

But what if we could make the text dynamic, so that it indicated the time that had passed between the date of an event and the moment the article is read? For example:

The 35th edition of the Montreux Jazz Festival ended [[display time since: July 16, 2017]]. It was a huge success.

The text between the square brackets would change as follows:

The 35th edition of the Montreux Jazz Festival ended yesterday.

The 35th edition of the Montreux Jazz Festival ended the day before yesterday.

The 35th edition of the Montreux Jazz Festival ended five days ago.

The 35th edition of the Montreux Jazz Festival ended one month ago.

The 35th edition of the Montreux Jazz Festival ended one year ago.


But there’s a limit: it’s difficult to get a programming language to change the verb tense or turns of phrase without it all getting too technically complex. But that’s something else we’re always constantly having to rework when editing digital content: “The Montreux Jazz Festival will start on July 2, 2017. We interviewed festival director Mathieu Jaton just before this year’s event kicked off.” The beginning of this text will need to be reworked if we decide that the article is still of value once this year’s festival has ended and if we want the article to remain appealing.

The following block of text is displayed if the article is viewed before July 2, 2017:

[[display if date < July 2, 2017]] The Montreux Jazz Festival will start on July 2, 2017. We interviewed festival director Mathieu Jaton just before this year’s event kicked off [[end]]. - Jaton: “This is a transition year for the festival.”

And after that date:

[display if date > July 2, 2017] Mathieu Jaton, the director of the Montreux Jazz Festival, spoke to Le Temps just a few days before the start of the festival’s 51st edition[[end]]. - Jaton: “This is a transition year for the festival.”

Geographical proximity

Geographical proximity is a slightly cynical principle – but one that all journalist teams are familiar with. According to this principle, journalists have to speak about things close to home in order to try to appeal to the reader. The French call it “death close to home,” meaning that one dead person within ten miles of the reader has as much news value as ten dead people 1,000 miles away. Without getting into an ethical debate, we can use a bit of technology to make the reader feel closer to the text. With modern web browsers, it is easy to find out the reader’s location quite accurately. The text can then be adapted accordingly:

Hurricane Harvey struck Texas on August 25, 2017. It made landfall at Corpus Christi, some [[display distance between reader.location and “Corpus Christi”]] from [[reader.location]].

“Reader.location” is used here as a way of geolocating the reader.


Hurricane Harvey struck Texas on August 25, 2017. It made landfall at Corpus Christi, some 200 miles from Houston.


We often provide amounts in euros or dollars and sometimes their equivalent in Swiss francs, but never the other way around. Readers in France (around 30% of Le Temps’ online readership) will never get the Swiss-franc amount expressed in euros.

On Monday, the French subsidiary of Swiss banking group UBS completed its acquisition of Banque Leonardo France for [[USD 3.2 billion in reader.currency]]

For a reader in Switzerland, the text would be as follows:

On Monday, the French subsidiary of Swiss banking group UBS completed its acquisition of Banque Leonardo France for CHF 3 billion

And for a reader in France:

On Monday, the French subsidiary of Swiss banking group UBS completed its acquisition of Banque Leonardo France for EUR 2.7 billion

[Note for later: the calculation must be based on the exchange rate at the time of publication, even if this distorts the information if exchange rates change significantly down the line.]

Depending on the text, the author will also have to decide whether to display the amount both in the newspaper’s local currency and the reader’s currency (i.e., CHF 20, or EUR XX) or provide the amount only in the reader’s currency. To do this, a condition has to be added:

I paid CHF 5.50 [[display if reader.currency IS NOT CHF]]([[CHF 5.5 in reader.currency]]) [[end]] for my beer. Scandalous!

4. Advanced functions

Information about the reader

We could go even further by using a data management platform (DMP), a tool that collects data on visitors to a site (Tealium is used at Le Temps). Here, there’s a more obvious ethical dilemma: to what extent can you adapt a text to the reader’s (presumed) profile? It is possible to determine a reader’s gender, approximate age, etc. and adapt the text accordingly. A reader who lived through Reagan’s presidency, for instance, wouldn’t need any explanation of certain details of his presidency. On the other hand, older readers might need explanations when we talk about younger celebrities or technologies like Snapchat. So:

On July 26, 2017, Rihanna [[display if reader.age > 20]], the Barbados-born R&B singer who was the first artist to break the Beatles’ record when her songs spent a total of 60 weeks at the top of the US charts, [[end]] dressed in a rather unusual outfit as she visited the Palais de l’Elysée to try and persuade President Emmanuel Macron to finance her humanitarian fund for education.

[Note for later: take into account the reader’s age at the time of publishing rather than at the time of reading.]

Variables added by the journalist

Once journalist teams have gotten used to the initial options offered by this programming language, we could enter phase two, which would involve making the programming slightly more complicated by adding variables. Let’s imagine a text about unemployment in various French-speaking countries. The author wants the text to be reader-centric: the text must be based on the reader’s country of residence, and it’s the journalist-programmer’s job to make sure that all the information refers to it – that’s the point of the article. This could be done by making the unemployment data variable:

Canada.unemployment.March.2017 = 6.7%
Switzerland.unemployment.March.2017 = 3.7%
France.unemployment.March.2017 = 9.8%
Belgium.unemployment.March.2017 = 6.9%

Canada.unemployment.March.2016 = 14%
Switzerland.unemployment.March.2016 = 2%
France.unemployment.March.2016 = 10%
Belgium.unemployment.March.2016 = 5.8%

We could then begin the article with data from the right country:

Unemployment in [[reader.location.country]] stood at [[reader.location.country.unemployment.March.2017]] in March 2017. It was [[difference between reader.location.country.unemployment.March.2017 and reader.location.country.unemployment.March.2016]] compared with the previous year.

This would result in:

Unemployment in France stood at 9.8% in March 2017. It was down 0.2% compared with the previous year.

We could take it even further if we added conditions such as country comparisons:

[[Display if reader.location.country.unemployment.March.2017 > *.unemployment.March.2017]] Unemployment in [[reader.location.country]] is the highest of any French-speaking country.[[end]]

[[Display if reader.location.country.unemployment.March.2017 < *.unemployment.March.2017]] Unemployment in [[reader.location.country]] is the lowest of any French-speaking country.[[end]]

For this to work – i.e., for journalists to actually use this relatively complicated function – the language needs to be quite flexible and easily adaptable to different ways of naming, defining and finding variables.

[Note for later: a standard text would have to be available for situations in which the reader is in an unknown country. For Le Temps, the easiest option would no doubt be for a Swiss-centric approach: any reader in an unknown country would be considered Swiss.]

5. A technical starting point

After chatting with several developers on Facebook, there seems to be a consensus about the proper starting point. The best thing to do would be to program a parser using Python, given that the idea is not to develop a comprehensive, evolved language. PHP could also be used to program a WordPress or Drupal module that would enable any blogger to add automated pieces of information into their text. Part of the code could also be run in Javascript, on the reader’s side. In addition, the tool should help the author write the text by offering auto-complete, help bubbles, etc.

Most of the functions and options that would be of interest are simplified versions of what is already offered by standard programming languages (e.g., Datediff(), now(), if, etc.).  The variables are usually provided by a DMP or the browser and are accessible in Javascript. The raw data would have to be used intelligently: if the time between an event and the reading date is very short, it should be expressed in days, followed by months and finally years. The same is true for distances: they should be expressed in hundreds of feet if they are short, then miles, and finally rounded to the nearest ten miles. And so on and so forth.

6. The challenge of archiving evolving content

One of the issues that is a cause for debate in these types of projects is how to archive content that is not static. How can readers compare their reading of a text (e.g., in Facebook chats) if they don’t have access to the same text? And how can researchers quote a text that is always changing? I had a fascinating discussion with Professor Frédéric Kaplan, who heads the laboratory of digital humanities at EPFL, back in 2016, and it brought some answers to my questions. Although the exchange wasn’t directly about this project, it made me realize that these types of questions will keep coming up, even without algorithm-based texts. Here’s why:

  • Texts are now modified several times after they are initially put online, and this has been the case for several years now. Although I have not kept a precise record, I’d say that at Le Temps we change a text on average four or five times after its initial publication. The figure is much higher for an evergreen text, not to mention live content, which by definition is changing all the time.
  • Outside factors mean that the reading experience is different for everyone. It will depend on the browser, screen size, internet connection, whether the reader has an ad blocker, etc. As we don’t read the content in the same setting, our reading experience is not the same.
  • Certain aspects of the website on which the content is published will influence how it is presented online. What ads were on screen when reading? What related content was provided at the end – or within – the article? Have changes in programming altered how the content is presented? Have new elements been added in the text (such as a subscription form for a newsletter)?

So what does Professor Kaplan think about all this? His view is that we should look at archiving in terms of a viewing experience and not in terms of the essence of the text, sort of like the way that you can play an old video game again but can’t archive part of it.

There is an ethical question in all this: should we tell the reader that part of the text was created using an algorithm? On the one hand, I think only experts are interested in this kind of question. But on the other hand, I think that kind of transparency is needed if we want to build readers’ trust in semi-automatic texts.

7. A non-exhaustive list of functions, variables and conditions

Here’s an initial list of options that could form part of this micro-language:

1. [display number of years | days | months since: 16 August 1983]
2. [display if date < 12 June 2017]
blah blah
[end display]
1. [display if reader.location = california]
blah blah
[end display]
2. [display distance between reader.place and los angeles]
3. [if device = smartphone | computer | tablet]
4. [if reader.age < 20]
5. [if gap between publication.date and reading.date > 20]
6. [display CHF 90 in reader.currency]

Reader variables
1. reader.subscriber
2. reader.gender
3. reader.location
4. reader.town
5. reader.currency
…provided by the browser, DMP or the user’s account info.

Technical variables
1. browser.system
2. browser.device

Stating variables: John = “1” or John = man.

8. Your input

For the moment, I haven’t been able to turn my ideas into a real project – they still need to be developed further. There are almost certainly other ways of approaching the subject and other avenues to explore. That’s why I created this blog post: I’d like your help to get things moving, so please feel free to contribute.

My thanks to Pat Jayet, Frédéric Sidler and Stéphane Koch for their input.

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

united-kingdom-flag-2-iconRead in English

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.