Mon métier m'a appris à ne jamais commencer un travail sans être certain d'avoir compris les raisons pour lesquelles on me demande de le faire. J'aurai sans doute l'occasion d'en reparler plus longuement une autre fois ; disons simplement ici que je suis convaincu qu'identifier et formuler le « pourquoi » d'un projet de développement (et sans doute de design en général) est une étape cruciale de sa préparation.
Il aurait été dommage de ne pas appliquer à moi ce conseil que je répète depuis des années à mes clients. La refonte de mon site a donc été l'occasion de me poser plusieurs questions.
Premièrement : à quoi sert brrd.fr ?
Brrd.fr est consacré à mon activité professionnelle. Il me sert donc avant tout à présenter mon métier, un métier parfois difficile à comprendre parce qu'il se situe à mi-chemin entre le secrétariat d'édition et le développement web. Il permet aussi de décrire mes domaines d'expertise, mes centres d'intérêt professionnels et les valeurs dans lesquelles j'aime inscrire mon travail. Il fait également office de point de contact. Enfin j'aimerais que ce site m'aide à accompagner, voire prolonger mon travail, un peu comme le ferait un site de documentation, une FAQ ou un journal de bord.
Deuxièmement : à qui brrd.fr s'adresse-t-il ?
Le site s'adresse d'abord à mes clients actuels et futurs, qui sont souvent des éditeurs, responsables de publications, chercheurs, documentalistes ou plus généralement chargés de projets. Mais aussi à mes collègues secrétaires d'édition et développeurs, aux acteurs et usagers du logiciel libre et de l'accès ouvert, ou plus largement aux personnes que ces sujets intéressent.
L'ancien site ne répondait pas vraiment à toutes ces préoccupations. Il était volontairement très (trop ?) épuré, et finalement rarement mis à jour. C'est la raison pour laquelle j'ai démarré la refonte qui nous intéresse ici.
Premier constat : l'ancienne version de brrd.fr ne disait pas grand chose à propos des mes réalisations. Or quoi de mieux pour présenter un métier que montrer ce qu'il produit ?
Concrètement une grande partie de mon travail quotidien est réalisée dans le cadre de mon activité au sein du collectif Edinum et apparaît donc déjà sur edinum.org. Dès lors la question se posait de savoir comment présenter ici mes projets sans créer de doublon.
J'ai choisi d'y répondre en créant une nouvelle page « Projets » qui donne une vision plus personnelle de mon travail. Je n'y présente pas le détail de toutes mes missions, mais plutôt les grands projets et orientations qui les regroupent et donnent de la consistance à mon activité. J'ai par exemple choisi de mettre en avant la maquette Nova plutôt que les sites qu'elle m'a permis de construire.
Cette page est aussi une occasion de montrer plusieurs initiatives personnelles qui témoignent de mon attachement au logiciel libre.
J'ai beaucoup hésité avant de me décider à inclure un système de billets au site. Je n'ai aucune prédisposition pour ce format d'écriture. J'ai aussi appris à me méfier des projets entièrement construits autour d'une idée de micro-parutions périodiques, car je sais que cela implique à long terme des ressources, du temps et de l'endurance que l'on a souvent tendance à sous-estimer. Je ne compte malheureusement plus les projets où l'on m'a demandé de concevoir un fil d'actualités ou un espace de blogging qui n'ont finalement jamais été utilisés. Or quoi de plus contre-productif qu'une publication périodique laissée à l'abandon ?
D'un autre côté il me manquait vraiment un espace où écrire. Quand une partie de votre travail consiste à expliquer vos choix techniques à des dizaines de personnes différentes, vous finissez fatalement par vous répéter tôt ou tard. Certaines questions reviennent d'un projet à l'autre, d'un partenaire à l'autre. Il n'y a rien de surprenant à cela, l'édition électronique et le web sont des domaines hermétiques à bien des égards.
Le nouveau système de billets est un moyen de mettre mes réponses à toutes ces questions à la disposition de tout le monde. C'est un gain de temps pour moi (j'arrête de copier-coller des mails) et si cela peut en prime être utile à quelqu'un d'autre alors je ne vois pas de raison de s'en priver. Je perçois un peu ces billets comme un complément à la documentation d'Edinum, l'idée étant de proposer le même type d'informations, toujours sans contrainte de périodicité mais sous une forme plus libre et plus personnelle.
Bien que les retours que j'ai reçus à propos de la charte graphique de brrd.fr aient toujours été positifs, j'ai pensé qu'il était temps d'en changer. Ainsi pendant trois mois début 2022, le site a expérimenté une nouvelle charte très différente de la précédente… avant de revenir (à peu près) à l'identité visuelle initiale. Celle-ci a tout de même finalement beaucoup évolué pour répondre aux nouveaux besoins du site, qui s'est enrichi de plusieurs pages et de textes longs.
Au final je suis globalement satisfait de cette presque-refonte graphique, qui apporte un rafraîchissement bienvenu sans pour autant m'obliger à imprimer de nouvelles cartes de visite :-)
La pertinence des mesures d'audience sur le web avait déjà été impactée par la démocratisation de la directive « Do Not Track » (quand elle était respectée par les hébergeurs). Le règlement général sur la protection des données (RGPD) appliqué en Europe depuis 2018 a confirmé cette tendance en posant des contraintes importantes à la collecte des statistiques de visites. Le visiteur doit maintenant pouvoir refuser de figurer dans les statistiques collectées. Si c'est une bonne nouvelles pour la protection des données personnelles, cela entraîne un travail supplémentaire non négligeable pour les concepteurs.
S'est donc posée la question de la collecte des statistiques sur brrd.fr. En y réfléchissant, je me suis aperçu que je ne consultais presque jamais ces mesures d'audience. Ce qui m'intéresse en réalité est moins le nombre de visiteurs qui ont lu le site que celui de ceux qui l'ont apprécié, utilisé ou qui s'en serviront un jour pour prendre contact avec moi.
J'ai donc décidé de supprimer toutes les mesures d'audience de brrd.fr. Cela garantit à mes visiteurs que leur vie privée sera respectée tout en me permettant de réduire la page « Politique de confidentialité » à son strict minimum, m'épargnant ainsi la rédaction du charabia légal qu'induit fatalement la collecte des données personnelles. Je ne récupère donc aujourd'hui plus aucune information concernant les visiteurs de mon site. Souriez, vous n'êtes pas pisté !
Le point négatif est bien sûr qu'il devient plus difficile de savoir quelles pages intéressent mes lecteurs, or c'est une information très utile pour définir une ligne éditoriale. Je réfléchirai peut-être a une solution alternative (comme un bouton « Applause » ?). En attendant, si vous appréciez ce que vous lisez ici alors n'hésitez pas à m'écrire pour me le dire !
Finissons comme il se doit avec les considérations techniques ennuyeuses mais indispensables. Ce nouveau site est rédigé en Markdown et publié avec Eleventy, un générateur de sites statiques pour Node.js qui se distingue par sa grande flexibilité. C'est la première fois que j'utilise Eleventy en production et je n'hésiterai pas à renouveler l'expérience si l'occasion se présente, même si cela reste à mon avis une solution à réserver (pour l'instant ?) aux bricoleurs qui apprécient gérer eux-mêmes tous les aspects de leur publication, du code à la rédaction.
Disons pour conclure que je suis satisfait de cette nouvelle version de brrd.fr comme de la manière dont elle a été conçue. Développer un site personnel peut à première vue sembler une perte de temps, mais je m'aperçois avec le recul que cela m'a permis de (re)voir la conception web d'un autre œil, celui du commanditaire. Ce rafraîchissement a donc également été celui d'un regard que je porte sur mon travail.
Il ne me reste qu'à vous souhaiter de prendre autant de plaisir à parcourir ces pages que j'ai eu à les créer.
Bienvenue !
]]>De 2015 à 2021, j'ai développé avec OpenEdition le plugin Checklist qui permet aux rédacteurs d'effectuer un contrôle qualité de l'ensemble de leur site Lodel. Les critères vérifiés (nommés « règles ») sont prédéfinis d'après une liste de problèmes basiques fréquemment rencontrés sur les sites.
Checklist s'inspire d'un autre outil plus ancien que j'avais conçu pour un usage interne à l'époque où je travaillais chez OpenEdition. Celui-ci était conçu pour pouvoir s'adapter à des besoins très spécifiques tout en conservant la capacité de couvrir la plupart des situations classiques.
Même si Checklist se destine clairement à une utilisation plus cadrée et homogène que son prédécesseur, il m'a semblé important d'y conserver une certaine forme de souplesse. J'ai donc veillé à ce qu'il soit possible de personnaliser son fonctionnement à plusieurs niveaux.
Pour comprendre la suite vous aurez besoin d'une connaissance minimale de JavaScript et HTML. La bibliothèque jQuery est également utilisée.
Jetons un œil au code de Checklist. En simplifiant un peu, son chargement dans la page ressemble à ça :
<!-- Insertion de Checklist -->
<script src="checklist.js"></script>
<!-- Initialisation de Checklist -->
<script>
var config = {
// La configuration de Checklist
// ...
}
window.checklist.init(config)
.then(function () {
checklist.run();
}
.catch(console.error);
</script>
La configuration de Checklist (décrite ici) contient entre autres les éléments qu'il nous sera possible de personnaliser :
langs
et translations
),buttonsCreator
),types
et defaultType
),filters
),ratings
) et la fonction qui se charge de leur calcul (computeRating
),context
),rules
).Lorsque la fonction checklist.init
est exécutée, elle vérifie d'abord que la variable checklistUserConfig
existe dans le contexte global. Le cas échéant elle la fusionne avec la configuration par défaut.
Il est ainsi possible de surcharger la configuration par défaut du plugin en ajoutant un script avant l'appel de cette fonction (qui a lieu à la fin du <body>
).
On peut par exemple insérer le script suivant à la fin du <head>
de la page :
window.checklistUserConfig = {
rules: [
{
id: "lipogramme-en-z",
name: {
fr: "Paragraphe(s) contenant un z.",
},
description: {
fr: "<p>Un ou plusieurs paragraphes du texte contiennent la lettre z, ce qui est gênant si vous souhaitez écrire un lipogramme.</p>",
},
condition: "textes",
type: "warning",
displayCount: true,
action: function ($) {
var fieldName = "texte";
var $p = $("[data-field='texte'] .ckl-field-value p");
var $bad = $p.filter(function () {
return $(this).text().indexOf("z") > -1;
});
var marker = {
name: {
fr: "Lettre z",
},
target: $bad,
position: "prepend",
highlight: false,
};
this.resolve($bad.length, marker);
},
},
],
};
Ce morceau de code déclare une règle qui détectera la présence de la lettre « z » dans les paragraphes du champ « texte » des articles. Cette nouvelle fonction sera exécutée en plus des règles habituelles.
La syntaxe des règles est décrite dans la documentation de Checklist. Les règles par défaut distribuées avec le plugin peuvent également servir d'exemple pour en écrire de nouvelles.
Comment faire à présent si nous n'avons pas la possibilité de modifier directement la maquette de Checklist sur le serveur ? C'est par exemple le cas si notre revue est hébergée sur OpenEditon Journals.
L'idée est d'exécuter le même script directement dans notre navigateur plutôt que depuis le serveur. Il faut pour cela installer l'extension de navigateur Tampermonkey et y créer le script utilisateur suivant :
// ==UserScript==
// @name Personnalisation de Checklist
// @namespace https://brrd.fr
// @version 0.1
// @description Ce script ajoute une nouvelle règle à Checklist.
// @author Thomas
// @match https://journals.openedition.org/*/?do=_checklist_view*
// @grant none
// @run-at document-start
// ==/UserScript==
(function () {
"use strict";
window.checklistUserConfig = {
rules: [
{
id: "lipogramme-en-z",
name: {
fr: "Paragraphe avec un z.",
},
description: {
fr: "<p>Un ou plusieurs paragraphes du texte contiennent la lettre z, ce qui est gênant si vous souhaitez écrire un lipogramme.</p>",
},
condition: "textes",
type: "warning",
displayCount: true,
action: function ($) {
var fieldName = "texte";
var $p = $("[data-field='texte'] .ckl-field-value p");
var $bad = $p.filter(function () {
return $(this).text().indexOf("z") > -1;
});
var marker = {
name: {
fr: "Lettre z",
},
target: $bad,
position: "prepend",
highlight: false,
};
this.resolve($bad.length, marker);
},
},
],
};
})();
Ici le code de la règle elle-même n'a pas changé. Seul l'enrobage a été modifié par rapport à l'exemple précédent pour correspondre aux prérequis de Tampermonkey.
Notons la présence de deux lignes importantes dans l'en-tête du script :
@match https://journals.openedition.org/*/?do=_checklist_view*
indique que le script s'exécutera pour tous les sites du domaine journals.openedition.org
. Si vous souhaitez limiter l'exécution à un seul site, il faudra le préciser dans l'URL à la place du premier astérisque.@run-at document-start
est nécessaire pour que le script soit exécuté avant l'initialisation de Checklist, ce qui est indispensable comme nous l'avons déjà vu.Pour comprendre les autres lignes de l'en-tête, n'hésitez pas à consulter la documentation de Tampermonkey.
Attention ! Tampermonkey s'exécute uniquement dans votre navigateur. Par conséquent votre code peut entraîner des comportements qui seront indétectables pour les administrateurs de votre site. N'oubliez pas de désactiver ces scripts quand vous ne les utilisez plus.
Vous avez écrit votre première règle personnalisée pour Checklist.
Notez que cette méthode n'est pas limitée aux règles : elle rend possible la modification de n'importe quel élément de la configuration de Checklist, comme les traductions, les menus contextuels, les notes… De quoi étendre Checklist pour en faire un outil totalement adapté à vos priorités éditoriales.
]]>En 2016 nous donnions naissance au collectif Edinum, qui regroupait les compétences de plusieurs prestataires indépendants spécialisés dans l'édition imprimée et électronique. Edinum a contribué à des dizaines de travaux en proposant aux éditeurs scientifiques un panel très large de services, de la préparation documentaire à l'hébergement de sites web en passant par la PAO et la formation.
Au gré de l'évolution du paysage de l'édition publique de SHS et de l'avènement des pépinières de revues, le travail d'Edinum s'est progressivement consolidé autour de deux axes principaux que sont le suivi éditorial et le développement web. Ce que nous avions envisagé initialement comme une offre de services à 360 degrés s'est ainsi polarisé en deux grand projets distincts entre lesquels les passerelles se sont avérées plus rares que prévu.
En sept ans les situations professionnelles des différents membres du collectif Edinum (qui, rappelons-le, n'a jamais été une entreprise) ont aussi beaucoup changé. Certains ont poursuivi et confirmé leur parcours de freelance quand d'autres ont réduit leur implication pour se consacrer à de nouveaux projets, voire parfois travaillé bénévolement pour le collectif.
Face à ces évolutions, notre organisation originelle s'est avérée rigide et peu lisible. Une mise à jour était nécessaire.
Afin de mieux traduire ces nouvelles réalités nous avons décidé ensemble de transformer le projet Edinum en deux nouveaux collectifs complémentaires.
Le collectif Eutypo est spécialisé dans le support à l'édition scientifique. Il propose des prestations de préparation documentaires pour Lodel, de PAO et de traduction.
Associés sous la bannière de Chapitre neuf, Nahuel et moi poursuivons quant à nous le travail démarré avec la conception de sites web pour les revues et les plateformes éditoriales. Nous nous présentons comme des « développeurs de livres », c'est-à-dire des techniciens qui comprennent le langage et les besoins des professionnels du livre : éditeurs, auteurs, chercheurs, documentalistes…
Concrètement rien ne change et chacun continue son travail comme avant : la partie web d'Edinum (notamment l'hébergement et la gestion des projets open source) est transférée à Chapitre neuf tandis qu'Eutypo continuera de prendre en charge les prestations éditoriales. Pour nos différents partenaires il s'agit donc avant tout d'un changement d'adresse.
Au-delà du changement cosmétique, l'avènement de Chapitre neuf coïncide avec de nouveaux enjeux personnels.
En premier lieu il s'agit de viser la pérennisation de notre activité en envisageant à terme les alternatives à l'auto-entreprenariat, dont je commence personnellement à percevoir les faiblesses après sept ans d'activité.
Chapitre neuf représente également une opportunité de réaffirmer notre engagement à l'égard du logiciel libre et de trouver un positionnement plus efficace sur ces questions faces aux institutions publiques. J'espère trouver le temps d'écrire davantage à ce sujet dans les semaines à venir, car les questions posées sont à mon avis nombreuses et complexes.
Enfin cette nouvelle étape est une occasion de diversifier notre travail en nous intéressant à de nouvelles techniques, de nouveaux logiciels et de nouveaux services. Notre maîtrise de Lodel ne doit pas nous faire oublier la richesse de l'écosystème technique qui se développe autour de la publication en ligne.
Au risque d'être un peu solennel je voudrais terminer ce billet avec des remerciements sincères.
Merci à mes collègues et (surtout) amis François, Arnaud et Nahuel pour avoir mis autant d'énergie dans Edinum pendant plus de sept ans. J'ai énormément appris au contact de chacun d'eux. Le fonctionnement horizontal du collectif n'a pas toujours été un long fleuve tranquille mais nous avons réussi à garder le cap jusqu'au bout.
Merci également à tou.te.s les client.e.s, partenaires et institutions qui nous ont fait confiance pendant toutes ces années et continuent à manifester de l'intérêt pour notre travail. Cela représente pour moi une source essentielle de satisfaction et de motivation. Nous continuons dans la lancée.
Merci enfin à tou.te.s les collègues qui insufflent du dynamisme dans nos métiers, cultivent un esprit d'ouverture et nous permettent d'inscrire notre travail dans un ensemble cohérent. Je pense notamment aux membres du réseau Médici (mais pas uniquement).
Merci… et à bientôt !
]]>Le CMS Lodel a longtemps été difficile à utiliser hors de son environnement technique de prédilection, notamment parce qu'un certain nombre de ressources indispensables à son bon fonctionnement n'étaient pas disponibles ou maintenues à jour.
La maquette (composée de templates) correspond à la brique logicielle responsable de l'affichage des pages et des interfaces. Lodel est dans sa version actuelle distribué avec une maquette qui n'est plus maintenue depuis les débuts du projet, cette partie du code ne faisant plus l'objet d'une publication sous licence libre par OpenEdition.
Or depuis une dizaine d'années, l'utilisation de Lodel par les plateformes d'édition universitaire en ligne a ouvert de nouvelles perspectives et problématiques. En s'emparant du logiciel pour l'adapter à leur utilisation les pépinières scientifiques ont favorisé l'expression de nouveaux besoins parmi lesquels le développement d'une nouvelle maquette moderne pour permettre la publication de revues électroniques avec Lodel est rapidement apparu comme une priorité.
Nombre d'aspects dépendent (totalement ou partiellement) de la maquette d'un site : l'accessibilité, le confort de lecture, l'habillage graphique, l'exposition des métadonnées, la sécurité, l'interopérabilité et la compatibilité avec les différents appareils, systèmes et navigateurs. La conception d'une maquette est donc un chantier long et complexe qui advient à l'intersection d'un faisceau de besoins, d'attentes et de contraintes techniques.
Lorsque plusieurs sites répondent au même cahier des charges comme c'est le cas pour les pépinières de revues scientifiques, une approche efficace consiste à concevoir une maquette générique qui servira ensuite de modèle personnalisable lors de la création de chaque site. C'est le fonctionnement pour lequel nous avons opté.
Dans le cadre de l'offre d'hébergement d'Edinum, nous avions développé en 2016 une première maquette générique (nommée Prima) adaptée à la lecture d'articles scientifiques sur les différents types de terminaux (ordinateur, mobile, tablette…).
Cette première expérience nous a permis de répondre à une demande formulée quelques années plus tard par la plateforme Prairial (Pôle éditorial Lyon Saint-Étienne) en développant avec Yolaine de Villeneuve et Arnaud Cordier la maquette Nova.
Nous avons choisi de publier ce projet sous licence libre afin d'en favoriser la réutilisation par toutes et tous. Initialement la Nova reprend une partie du code de la maquette Prima tout en adoptant une interface plus proche de ce qui est proposé par OpenEdition Journals en termes d'ergonomie et de fonctionnalités.
En quelques années la maquette Nova a été adoptée par un nombre croissant de plateformes et de revues scientifiques. Ce rayonnement nous a donné l'opportunité de recueillir des retours d'expériences riches et multiples tout en nous confrontant à une diversité de nouveaux besoins.
De nouvelles préoccupations ont aussi émergé durant les quelques années de vie de cette première version. L'obligation d'accessibilité s'est confirmée pour les sites publics (services de l'État ou collectivités territoriales), renforçant la nécessité de se conformer au Référentiel général d’amélioration de l’accessibilité (RGAA). C'est dans ce contexte que la plateforme Péren (Université de Lille) a commandé un audit d'accessibilité de la Nova, puis a sollicité Edinum pour travailler sur les axes d'amélioration qui sont ressortis de cette étude.
Il est rapidement apparu que la mise en conformité de la maquette Nova aux normes du RGAA nécessiterait la réécriture d'une partie conséquente de son code source. Devant ce constat et par souci de limiter la fréquence des ruptures de compatibilité qu'entraînent de tels changements, j'ai pris la décision de profiter de ce chantier pour réécrire une grande portion du code de la maquette afin de corriger plusieurs autres problèmes. Cette partie du travail n'a pas été rémunérée.
Le premier axe a consisté à revoir intégralement l'ergonomie des interfaces. Les feuilles de styles ont été réécrites pour mettre en pratique un maximum de bonnes pratiques. La typographie et le layout des pages ont été intégralement revus pour permettre un meilleur confort de lecture, en augmentant notamment la taille des polices conformément aux recommandations répétées des spécialistes et des agences de santé. Un certain nombre d'interfaces ont été ajoutées (barre de navigation en haut de page, liens vers les sections de la page contre la barre latérale de défilement…) ou repensées (sélecteur de langue, onglets linguistiques, affichage des tableaux…). Une légère refonte graphique a enfin été entreprise pour favoriser une meilleure harmonisation des couleurs et des différents niveaux de gris, tout en préservant un aspect visuel dans la continuité de la première version.
Un second aspect concerne la modularité et le confort d'utilisation dans le cadre des personnalisations de maquettes. Bien qu'il s'agisse du changement le moins visible, c'est peut-être ici que se trouve l'évolution la plus importante de la Nova.
L'adoption massive de la maquette par les pépinières a ajouté une dimension supplémentaire à son évolution en nécessitant toujours davantage de besoins de personnalisation et en augmentant la complexité de la maintenance technique du projet, qui doit présenter la souplesse suffisante pour satisfaire les besoins propres de chaque plateforme tout en préservant un code source unique et redistribuable.
Plusieurs leviers ont été mobilisés pour atteindre cet objectif : la réduction de la spécificité des styles CSS pour faciliter les surcharges, l'ajout de variables et mixins LESS pour simplifier les personnalisations, la suppression des webfontes embarquées par défaut, la multiplication des options de maquette, des macros LodelScripts et des hooks, l'amélioration du mode de développement, etc.
La liste complète des modifications effectuées est publiée sur Github. On pourra également consulter le guide de migration et le site de démonstration de la maquette Nova.
La Nova est ainsi devenue un outil flexible, plus aisé à manipuler, maintenir et modifier.
Si les appellations « Nova 1 » et « Nova 2 » peuvent donner l'impression que le développement du projet s'est fait par sursauts à l'occasion de grands chantiers, sa maintenance et sa mise à niveau représentent en réalité un travail très régulier qui s'est étalé sur plusieurs années. De nombreux patchs et correctifs ont donné lieu à une cinquantaine de versions intermédiaires depuis la première publication de la maquette, soit en moyenne un peu plus d'une version par mois.
La maintenance de la Nova est aujourd'hui assurée par le collectif Chapitre neuf. On peut grossièrement estimer à 800 le nombre d'heures de développement réalisées par les quatre personnes qui ont participé à la maintenance du projet. La rémunération directement perçue pour ce travail (principalement pour les grands chantiers de conception des versions majeures 1 et 2) couvre environ un quart de ce temps de travail, le reste étant donc réalisé sur les ressources propres d'Edinum / Chapitre neuf.
Car ce projet a aussi été l'occasion d'imaginer et tester un modèle économique voulu en cohérence avec la libération du code que nous avions fixée comme l'un de nos objectifs. Pour contrebalancer le manque à gagner dû à une activité de maintenance qu'il est impossible de facturer, nous proposons un hébergement clé en main de revues et intervenons auprès des plateformes qui ne disposent pas des ressources nécessaires pour réaliser elles-mêmes l'installation de nos outils. J'aurai l'occasion de faire plus largement le bilan de cette expérimentation dans un autre billet.
Conçue initialement il y a quatre ans, la maquette Nova est aujourd'hui utilisée par neuf plateformes pour diffuser plusieurs dizaines de revues en accès ouvert. Sa publication est l'aboutissement d'années de travail et d'expérience en édition électronique à destination des revues savantes. À force d'ajustement et de mises à jour, nous avons a atteint un niveau qualitatif qui fait de cet outil une option robuste pour la publication en ligne d'articles scientifiques en accès ouvert.
Son avenir reste cependant inextricablement lié à celui de Lodel, dont on sait qu'une nouvelle version verra prochainement le jour. Comment dès lors envisager le prolongement de la maquette Nova dans le contexte d'un passage à Lodel 2 ?
Si les spécifications techniques de Lodel 2 n'ont pas encore été rendues publiques, il a été confirmé à plusieurs reprises par OpenEdition que cette nouvelle version s'appuierait sur le framework Symfony. Ce changement induit un certain nombre de ruptures techniques, dont l'abandon de LodelScript et le passage à Twig pour le rendu des templates. Il est également probable que des variations soient introduites dans la structure des données. On peut en déduire que les maquettes et plugins développés pour Lodel 1 ces dernières années ne seront plus compatibles avec la version 2.
OpenEdition a annoncé que Lodel 2 serait distribué sous licence libre à la fin de son développement mais nous savons peu de choses sur le périmètre de ce qui sera compris dans cette distribution. Les maquettes d'OpenEdition seront-elles fournies avec le logiciel ou faudra-t-il développer de nouveaux templates comme nous l'avons fait pour Lodel 1 ? Le programme sera-t-il par défaut adapté à une utilisation en dehors de l'infrastructure technique d'OpenEdition ? Enfin toutes les fonctionnalités proposées sur les plateformes d'OpenEdition (recherche avancée, génération automatique des formats détachables, serveur OAI-PMH, architecture de plugins, etc.) seront-elles présentes dans le package distribué ?
Toutes ces questions font qu'il nous est impossible à ce jour de prédire en quoi consisteront les développements à effectuer pour les pépinières lors de la publication de Lodel 2.
L'expérience acquise ces dernière années peut toutefois servir de boussole : lorsque nous avons commencé à travailler avec Lodel il y a huit ans, les ressources disponibles pour les plateformes étaient rares, voire inexistantes si l'on se limite aux logiciels libres. Les quelques plateformes qui existaient en dehors d'OpenEdition utilisaient alors des solutions maison éparses plus ou moins évoluées. Il nous aura fallu plusieurs années pour développer un environnement technique unifié réunissant un panel de fonctionnalités d'un périmètre et d'une qualité louables.
Combien faudra-t-il de temps pour atteindre le même niveau de diversité et de robustesse avec Lodel 2 ? Difficile de le prédire avec certitude. Mais on peut supposer que Lodel 1 et la maquette Nova resteront des outils utiles durant tout le temps de cette transition.
]]>