Typst passe service de plein droit : le rendu documentaire comme service de la suite
Les universités vivent au rythme des documents : mémoires, sujets d'examen, supports de cours, certificats et courriers administratifs. La plupart sont encore produits à la main ou avec des outils locaux fragiles. Avec le sprint d'intégration qui vient de s'achever, Typst, un système de composition à base de balisage et l'alternative moderne à LaTeX, devient un service openEduSuite de plein droit, prêt à piloter une production documentaire déterministe fondée sur des modèles.
Pourquoi la composition a sa place dans la suite
La suite couvre déjà l'édition collaborative grâce à ses services bureautiques et éditeurs. Ce qui manquait, c'était la composition de production : la capacité de compiler un document à partir d'un modèle et de données, de façon reproductible, sur le serveur. C'est un autre métier : des sujets d'examen générés depuis un registre, des certificats produits en série, des courriers rendus à partir de données structurées. Cela demande un moteur de composition plutôt qu'un éditeur interactif.
Un fork suivi en amont, pas une scission
La suite utilise tobias-weiss-ai-xr/typst, un fork de typst/typst régi par une politique de séparation stricte :
- Synchronisation amont hebdomadaire : un flux de travail planifié fusionne le
mainamont dans le fork. Les conflits de fusion font échouer le pipeline bruyamment, afin qu'un humain les résolve au lieu de les enterrer silencieusement. - Le code spécifique au fork reste dans son couloir : tout ce que nous ajoutons vit sous
render-service/et.github/workflows/, ce qui garde les futures fusions amont sans conflit. - Les versions suivent l'amont : la version actuelle,
v0.15.1, reprend le numéro de version amont et est réinitialisée à chaque synchronisation.
L'objectif est de rester un fork fin et bien élevé : nous apportons de la valeur de déploiement, pas de divergence du moteur.
Un service de rendu aux bords durs
Le nouveau service de rendu est un petit wrapper HTTP volontairement minimal autour de la CLI typst, écrit uniquement avec la bibliothèque standard Python : pas de framework, pas de dépendances à auditer :
POST /render {"source": "= Hello", "format": "pdf|png|svg",
"assets": {"data.csv": "..."}} -> octets du document
GET /healthz -> {"status": "ok", "typst": "typst 0.15.1 ..."}
La frontière de confiance est appliquée dans le processus lui-même :
- Limites de requête (corps de 5 Mo, source de 2 Mo) et un délai de compilation de 60 secondes.
- Les noms d'assets sont restreints à des identifiants plats, sans traversal de chemin.
- La compilation s'exécute dans un répertoire temporaire isolé avec confinement de racine ; le compilateur n'a aucun accès réseau.
- La concurrence de compilation est limitée pour protéger les nœuds du cluster d'une saturation CPU.
- Le conteneur exécute le service sous un utilisateur sans privilège.
- Les polices Liberation sont intégrées à l'image, couvrant les familles métriquement compatibles Arial/Times/Courier que supposent la plupart des modèles institutionnels.
Une petite leçon du sprint : même un wrapper sans dépendances a besoin de vrais tests d'API. Une incohérence d'arguments nommés dans le chemin de compilation a été détectée et corrigée ; un test de régression HTTP de bout en bout la surveille désormais.
Des images qui se livrent seules
Chaque version publie deux images multi-architectures (linux/amd64 et linux/arm64) dans la GitHub Container Registry :
ghcr.io/tobias-weiss-ai-xr/typst: la CLI typst pristineghcr.io/tobias-weiss-ai-xr/typst-render: le service de rendu
Le flux de version construit, teste (smoke) et publie les deux images automatiquement ; le résultat du test de fumée est ancré au digest de l'image : ce qui a été testé est démontrablement ce qui a été livré.
Déploiement sur les deux piles
| Pile | Câblage |
|---|---|
| Kubernetes (enseignement supérieur) | Chart Helmfile épinglé à un tag de version |
| Docker Compose (PME) | Profil de service dédié dans la pile compose |
Les deux déploiements suivent la même discipline que tout autre service de la suite : un chemin réseau interne uniquement, une sonde de vivacité fondée sur /healthz et des images épinglées par tag de version. Le service est machine-facing par conception : pipelines de modèles, outils d'administration et backends de portail appellent l'API ; les humains rédigent les documents ailleurs (voir ci-dessous).
L'écriture interactive, entièrement FOSS
L'éditeur Typst hébergé sur typst.app est un logiciel propriétaire, jamais une option pour une suite qui promet l'open source de bout en bout. Le sprint a donc livré deux surfaces d'écriture auto-hébergées et entièrement ouvertes :
1. Un éditeur web durci sur le service de rendu (typst.openedusuite.org, derrière le SSO Keycloak). Le même wrapper sans dépendances sert désormais un éditeur mono-page avec aperçu SVG/PDF en direct, documents d'exemple intégrés, choix du format et UX clavier ; zéro CDN externe, zéro dépendance côté client à auditer. Un bug de streaming de réponse (double lecture du corps du rendu) est apparu lors des tests et est désormais couvert par un test de régression.
2. TOSS, le Typst Open-Source Server (toss.openedusuite.org), pour l'écriture collaborative. TOSS (AGPL-3.0, pku-typst/TOSS) est un espace de travail collaboratif auto-hébergeable : édition multi-utilisateur en temps réel avec présence, compilation directement dans le navigateur via Typst WASM (aperçu instantané, sans aller-retour serveur), versionnage Git et galerie de modèles. La suite le déploie nativement avec PostgreSQL, stockage Git sur volume persistant et, contrairement aux autres services du catalogue, fédération OIDC directe avec Keycloak au lieu d'une passerelle oauth2-proxy : TOSS parle OIDC nativement, toss.openedusuite.org se connecte donc avec la même identité institutionnelle que tous les autres services.
Désormais, l'écriture interactive ne quitte jamais la pile open source : le rendu rapide d'un fichier unique se fait dans l'éditeur web, les projets documentaires multi-utilisateurs vivent dans TOSS, et la production par lots déterministe passe par l'API de rendu.
La suite
- Un dépôt de modèles pour les documents institutionnels (sujets d'examen, certificats, courriers), consommé par l'API de rendu et la galerie de modèles de TOSS.
- Des intégrations de pipelines, par exemple la génération de certificats depuis les données du registre selon un calendrier.
- Le suivi amont se poursuit : la synchronisation hebdomadaire garde le fork à jour dans l'écosystème Typst, qui avance vite.
Appel à l'action
- Pour en savoir plus : les détails techniques sont documentés dans l'article compagnon Typst Document Rendering Architecture.
- Essayer : pointez un pipeline de modèles vers l'API de rendu, rédigez votre prochaine feuille d'exercices dans l'éditeur web, ou invitez des co-auteurs dans un espace TOSS.
- Participer : rejoignez la communauté openEduSuite et aidez à construire le dépôt de modèles.
La composition déterministe, déployée comme n'importe quel autre service ; les documents aussi sont de l'infrastructure.
Avis de marque : Typst est un produit de typst (typst.app). Cet article est indépendant et n'est ni affilié à typst ni approuvé ou sponsorisé par celui-ci. Tous les autres noms de produits sont des marques de leurs propriétaires respectifs.
