Portabilité
Importer et exporter : votre histoire doit rester la vôtre
Voici une autre raison pour laquelle j’aime autant les navigateurs et le web. Grâce à leur évolution, en 2026 une même histoire peut fonctionner dans un navigateur, une archive autonome et des applications Windows ou macOS sans maintenir plusieurs moteurs de jeu séparés.
Avant le lancement de l’import et de l’export en août 2026, Romergo souffrait depuis longtemps d’un problème de vendor lock-in : on pouvait créer dans le système, mais difficilement repartir avec son travail. Ce n’est plus le cas. Le propriétaire peut désormais télécharger une archive .romergo documentée ou préparer un jeu autonome pour le web, Windows, macOS et le Microsoft Store. Le projet doit appartenir à son auteur, même s’il quitte un jour Romergo.
C’est pourquoi je me suis occupé de l’import et de l’export.
Pourquoi le web a réduit le problème
Romergo possédait déjà un Player runtime commun pour les scènes, branches, images, musiques, vidéos, traductions, langues RTL et sauvegardes locales. Il charge normalement une publication depuis le service, mais peut aussi être livré avec l’histoire et fonctionner sans réseau.
La version web place index.html à la racine du ZIP. Windows et macOS enveloppent le même Player dans une coque Electron sécurisée. Microsoft Store reçoit le même jeu dans un MSIXUpload. La logique narrative n’est pas réécrite quatre fois : seul l’emballage autour du runtime change.
Les certificats, signatures, notarization et règles des boutiques restent nécessaires. Mais la partie la plus coûteuse n’est plus dupliquée: construire et maintenir un client différent par plateforme.
Comment fonctionne l’export
Romergo part d’un brouillon enregistré à l’état Saved ou d’une version précise de publication. Le runtime et les médias sont figés par révision. Si le projet change pendant la construction, la tâche recommence au lieu de mélanger anciennes scènes et nouveaux fichiers.
Le premier résultat est toujours .romergo, un ZIP documenté contenant manifest, projet, chapitres, scènes, graphe, variables, présentation, médias, crédits et checksums SHA-256. Il conserve les noms affichés et les rôles, jamais les emails ni les identifiants internes.
brouillon enregistré ou publication
↓
runtime et médias cohérents
↓
archive .romergo documentée
↓
builder de plateforme isolé
↓
ZIP ou MSIXUpload privé pendant 7 joursChaque média est lu, haché puis vérifié à nouveau. L’archive est envoyée en streaming vers un stockage R2 privé, sans charger un projet gigantesque dans la mémoire d’un Worker.
Pour créer un jeu, un conteneur Linux sans accès Internet valide .romergo, ajoute le Player autonome et produit Web/itch.io, Windows x64, deux applications macOS pour Apple Silicon et Intel, ou un MSIXUpload. Romergo ne demande jamais les identifiants Steam, l’Apple Developer ID, les certificats ou les mots de passe. La signature et la publication restent dans les comptes de l’auteur.
Le coût m’a également surpris. « La Tempête de neige » contient 101 médias pour environ 30 MB. Même après les ressources Cloudflare incluses, sa construction ne coûte que quelques centimes. Le principal coût n’était ni R2 ni le trafic, mais le temps pendant lequel le conteneur restait actif après le packaging.
Vous pouvez jouer à la version publiée de « La Tempête de neige » dans votre navigateur : il s’agit du même projet que celui utilisé pour cette estimation.
L’import était plus difficile
Il existe plus d’une dizaine d’éditeurs et de moteurs. Certains auteurs viennent de Twine, ink, Yarn Spinner ou Ren’Py ; d’autres écrivent dans un carnet, Obsidian ou Notion. On reçoit aussi des PDF, Markdown, tableaux, mémos vocaux, vidéos et dossiers d’images.
Les formats se comptent par milliers et changent chaque année. Un importeur natif par format deviendrait vite un cimetière de parsers ne comprenant qu’une version d’un produit tiers.
La réponse était déjà là : les agents IA.
Un agent peut recevoir HTML, Markdown, PDF, audio, images et liens, retrouver l’ordre, reconnaître les personnages, signaler les branches ambiguës et poser des questions. L’auteur guide le processus et vérifie le résultat.
Romergo prenait déjà en charge MCP. Au lieu de lui apprendre tous les formats du monde, j’ai gardé une cible stable : les outils avec lesquels un agent crée et vérifie un projet Romergo normal.
Le flux d’import avec un agent
fichiers et liens sources
↓
agent MCP de l’utilisateur
↓
inventaire, aperçu, questions et avertissements
↓
outils de création MCP Romergo
↓
relecture persistée et validation
↓
contrôle final dans BuilderL’agent inventorie chapitres, scènes, personnages, lieux, médias et langues. Pour HTML, Markdown, TXT et PDF textuels, romergo_inspect_story_source et romergo_import_story_source permettent un transfert littéral et linéaire sans inventer de branches.
Pour Twine, ink, Yarn Spinner et Ren’Py, passages, knots, nodes, dialogues, choix et variables simples deviennent généralement des chapitres, scènes et liens. Macros, Python, commandes Unity, screens, CSS/JS et fonctions externes deviennent des avertissements nécessitant une décision humaine.
Après l’aperçu, l’agent crée un nouveau projet, importe les pièces jointes par lot, écrit le graphe et les scènes. Les gros médias vont directement vers R2. Il relit ensuite les données avec romergo_get_chapter, lance romergo_validate_project et ne termine qu’après romergo_verify_quest_change.
L’IA ne remplace pas la vérification
Un agent comprend le sens, mais une déduction n’est pas un fait. Un audio peut nécessiter une transcription externe, un lien ne donne aucun droit de copie et une macro peut être un programme entier. L’import montre donc un aperçu et des avertissements, puis demande de confirmer les droits.
L’importeur natif accepte uniquement .romergo. C’est volontaire : notre format doit être importé de façon déterministe et sûre ; le monde ouvert des sources tierces exige un outil capable de raisonner et de questionner.
Un pari sur les cinq prochaines années
Les formats et les agents changeront, mais la frontière peut rester stable : tout type de travail humain d’un côté, .romergo documenté et les outils MCP de l’autre.
Si un nouvel éditeur devient populaire, un agent pourra étudier ses fichiers, montrer ce qu’il a compris et écrire le résultat via le même contrat. Et si un auteur quitte Romergo, il gardera une archive ouverte et un jeu autonome.
Romergo doit être un endroit pratique pour créer des histoires, pas une cage qui empêche de les emporter.