Pourquoi une navigation par graphe ?

Derrière chaque fonctionnalité de PanelWave, il y a une décision prise avant la première ligne de code : un chapitre n’est pas une suite de pages, c’est un graphe orienté. Les cases sont des nœuds. Les arêtes disent quelle case peut suivre laquelle, sous quelle condition, avec quelle transition. Tout ce que voient lecteurs et créateurs, du simple bouton « suivant » au mystère à embranchements, découle de ce choix. Ce billet explique pourquoi nous l’avons fait, ce qu’auraient coûté les alternatives, et pourquoi une BD linéaire n’en paie pas le prix. Pour la mécanique, voyez Navigation par graphe dans la documentation ; ici, place au raisonnement.

Trois façons de décider de la suite

La BD numérique suit en général l’un de deux modèles. Le premier est le modèle imprimé : une BD est une liste ordonnée de pages, et lire consiste à les tourner. Il préserve le dessin et la composition ; mais sur un téléphone, il oblige à pincer et à zoomer, et il n’a aucun vocabulaire pour un choix : on ne peut qu’avancer ou reculer. Le second est le modèle vidéo, le motion comic : les cases deviennent des plans sur une timeline, avec son et mouvement, et le fichier se lit tout seul. Il gagne le mouvement et l’ambiance, mais perd complètement le lecteur. Quelqu’un d’autre tient l’horloge, le dessin est en concurrence avec l’animation, et il n’y a aucune porte à ouvrir.

Le troisième modèle, c’est le graphe. Chaque case est un nœud, avec des arêtes vers les cases qui peuvent la suivre. Une histoire linéaire est une chaîne d’arêtes sans condition ; un choix, un nœud avec au moins deux arêtes sortantes aux conditions différentes. Rien dans le modèle ne privilégie une forme plutôt que l’autre, et c’est tout l’intérêt : le format n’a pas un mode normal plus un mode interactif à part. Il a une seule primitive, qui décrit les deux.

Ce qu’un graphe apporte aux lecteurs

L’expérience de lecture découle du modèle plus directement qu’on ne le croirait.

• Le rythme. Un nœud est une halte. On avance quand on le décide, ou on laisse la lecture automatique le faire, selon une durée fixée par la case ou par soi-même. Le dessin reste immobile tant qu’on le regarde, contrairement à un plan sur une timeline.
• Le chemin. Un détour, c’est une arête qui quitte la ligne principale et une autre qui la rejoint. Scènes facultatives, ruelles et pièces secrètes ne demandent aucune mécanique particulière, et il reste toujours un chemin pour revenir à l’intrigue.
• Le retour. Comme chaque pas est une arête, revenir en arrière, c’est parcourir la même arête dans l’autre sens, transition comprise. L’historique et le retour en arrière fonctionnent de la même façon pour les histoires linéaires et à embranchements.
• Le choix. Une zone interactive sur une porte enregistre dans une variable ce qu’on a fait ; les arêtes sortantes du nœud suivant interrogent cette variable. Le choix appartient au lecteur, et le format s’en souvient.
• La vue. Le même graphe s’affiche case par case sur un téléphone ou en page composée sur un grand écran. La vue page montre la composition voulue par le créateur ; la vue case parcourt les nœuds. On passe librement de l’une à l’autre, et la documentation de l’interface de lecture décrit ce que fait chaque vue de « suivant » et « précédent ».

Ce qu’un graphe apporte aux créateurs

Pour la personne qui crée l’œuvre, le graphe remplace les cas particuliers par des données. Un embranchement n’est pas un script : c’est une arête avec une condition écrite en JSON Logic, une petite règle qui se lit comme une phrase. Les choix sont des zones interactives qui définissent des variables typées, à la portée déclarée. Et le langage de conditions qui oriente les arêtes peut aussi remplacer le contenu d’une case par une variante, ou masquer une seule bulle. Un seul langage, appris une fois.

Les pages n’ont pas disparu. Un chapitre peut toujours définir des mises en page, avec placements et ordre de lecture : la composition imprimée survit, et l’export pour l’impression fonctionne toujours. Ce qui change : la page décrit la disposition des cases, le graphe décrit la progression de l’histoire. Les deux sont volontairement séparés ; la référence du format explique leur coexistence sous vue page et vue case. Réordonner les cases d’une page change leur ordre de lecture, jamais le graphe.

Et comme le graphe est une donnée dans un manifeste JSON, et non une logique enfouie dans un programme, on peut le valider. Cases inaccessibles, impasses, points d’entrée manquants, cycles : autant de questions structurelles auxquelles un outil répond avant qu’un lecteur ne tombe dessus. Le Graph Editor du CMS dessine le graphe comme une carte, signale ces problèmes et permet de simuler n’importe quel chemin ; avant publication, la validation Preflight vérifie à nouveau que chaque case est atteignable.

Pourquoi pas un ordre de pages avec des sauts ?

L’alternative évidente, et moins chère : garder les pages et ajouter une instruction de saut, du genre « aller à la page 14 si le lecteur a pris la clé ». Les outils de fiction interactive fonctionnent ainsi depuis des décennies, et pour le texte, ça marche bien. Pour la BD, cela casse à deux endroits. D’abord, un saut est une exception à l’ordre, pas une partie du modèle : chaque outil qui comprend les pages doit apprendre les sauts à part, et le retour en arrière exige sa propre comptabilité. Ensuite, les sauts sont en général du code, ce qui met l’embranchement derrière une barrière que la plupart des artistes ne veulent pas franchir. Dans un graphe, l’arête est l’ordre. Il n’y a rien à ajouter, et un éditeur visuel peut la dessiner sans que personne n’écrive de script.

Pourquoi pas une timeline ?

La timeline est tentante : elle apporte gratuitement le son et le mouvement, et PanelWave utilise d’ailleurs des timelines à l’intérieur d’une case, pour l’animation et l’audio. L’erreur serait d’en faire la colonne vertébrale de l’histoire. Une timeline n’a qu’une direction et qu’une vitesse : l’interactivité doit y être greffée sous forme de pauses et de menus, et le dessin n’a jamais le droit de rester immobile. Le graphe remet la timeline à sa place : un nœud peut avoir du mouvement, du son, voire de la vidéo, et rester un endroit où l’on s’arrête, explore et repart à son rythme. Le mouvement sert la case au lieu de la remplacer.

Ce que paient les histoires linéaires

Rien. C’était le test que la conception devait réussir. Une BD classique dans PanelWave est une chaîne d’arêtes sans condition, que le CMS crée automatiquement au fil des cases ajoutées. Le lecteur la parcourt exactement comme une histoire à embranchements : rassembler les arêtes sortantes, évaluer leurs conditions, prendre la gagnante. Avec une seule arête sans condition par case, l’évaluation est triviale, et le public voit une BD qui se lit du début à la fin. Vous ne payez la complexité que là où vous l’utilisez, et vous pouvez ajouter un premier embranchement au chapitre trois sans restructurer les chapitres un et deux.

Un graphe, trois couches

Le graphe permet aussi à un écosystème ouvert de partager une seule définition de l’histoire. Le format définit le graphe comme une donnée, le lecteur l’évalue pendant la lecture, et le CMS le dessine et le valide. Aucun n’a besoin de s’accorder sur quoi que ce soit au-delà du manifeste, et tout lecteur tiers qui applique les mêmes règles obtient la même histoire. C’est ce que nous entendons quand nous appelons le format « le contrat » (voir Architecture). Le manifeste lui-même est assez court pour être lu ; l’exemple annoté montre une œuvre complète en une page.

C’est aussi ce modèle qui nous rend sereins face à la suite. Des variantes de case qui changent de contenu selon l’état, des zones interactives qui agissent, des paywalls placés à des endroits précis de l’histoire, une vue de lecture où l’espace entre les cases devient visible : tout cela s’ajoute à un graphe sans changer ce qu’est un graphe. Avec un ordre de pages ou une timeline, il aurait fallu un nouveau modèle à chaque fois.

Pour aller plus loin

• Navigation par graphe : l’anatomie d’un graphe, les conditions, les transitions et les mutations.
• Graphe : chaque propriété des objets graphe, arête et mutation.
• Chapitres et pages : comment les mises en page et le graphe coexistent.
• Variables : l’état que lisent les conditions d’arête.
• Graph Editor : dessiner, valider et simuler le graphe dans le CMS.