Il construit ce qui ne peut pas s’écrire : un moteur de recherche dans un fichier de cent mille lignes, une carte que le lecteur interroge. Journaliste d’abord, développeur ensuite.
En un mot. Celui qui programme les outils et les publications interactives d’une rédaction.
Définition
Le développeur-journaliste conçoit des applications éditoriales : moteurs de recherche dans des bases, cartes interactives, visualisations, outils internes de collecte et de nettoyage. Il exerce un métier technique à l’intérieur d’un raisonnement journalistique.
Pourquoi c’est important
Certaines informations ne se racontent pas, elles s’explorent. Un fichier de cent mille lignes ne devient une information pour le lecteur que s’il peut y chercher sa commune, son école, son hôpital. Aucun texte ne remplace cela.
Comment ça marche
Le partage des rôles décide de la qualité. Un développeur qui reçoit une commande finie produit un objet techniquement correct et éditorialement plat ; un développeur associé dès l’exploration des données trouve souvent l’angle, parce qu’il est le premier à voir ce que le fichier contient vraiment.
Méthode, étape par étape
Associer le développeur à l’exploration des données, pas seulement à la restitution.
Vérifier les données avant de construire : un outil propre sur des données fausses trompe mieux.
Documenter la provenance et les limites du jeu de données, et les publier.
Concevoir pour le téléphone d’abord : la majorité des consultations s’y font.
Prévoir l’accessibilité : une visualisation illisible au lecteur malvoyant n’informe pas.
Prévoir la maintenance : une application non maintenue devient fausse en silence.
Publier la méthode et, quand c’est possible, les données.
Archiver ce qui ne sera plus maintenu, plutôt que le laisser en ligne.
Un cas concret
Une application non maintenue ne tombe pas en panne : elle continue d’afficher les chiffres de l’an dernier comme s’ils étaient actuels. C’est plus dangereux qu’une erreur visible, et c’est le mode de défaillance normal de ces publications.
Les erreurs à éviter
Recevoir une commande finie au lieu d’explorer les données.
Construire sur des données non vérifiées.
Publier sans documenter la provenance et les limites.
Laisser en ligne une application qui n’est plus mise à jour.