Univer 1.0 : six éditeurs Office embarquables, pensés pour les agents
Publiée le
Sorti le 24 septembre, Univer 1.0 réunit tableur, texte, slides, tableau blanc, base structurée et PDF dans un SDK open source. Un SDK dédié permet à un agent de lire, modifier et vérifier visuellement un document, puis de le soumettre à relecture humaine.
Ce que c'est. Univer est un SDK open source pour embarquer des éditeurs de type Office dans ton propre produit, plutôt que d'envoyer tes utilisateurs vers Google Sheets ou Excel. La version 1.0, publiée le 24 septembre 2026 après cinq mois de travail, passe d'un tableur à six éditeurs : Sheets, Docs, Slides, Boards (diagrammes, import Mermaid), Bases (données structurées avec vues grille, kanban, calendrier, Gantt) et PDFs. Ils partagent un même moteur de formules, un même système de plugins, et peuvent s'imbriquer : un tableur éditable dans un document, un diagramme dans une slide. Ce qui est nouveau pour un CTO, c'est le troisième SDK, dit « AI SDK » : une bibliothèque TypeScript pour construire une ligne de commande que ton agent utilise pour charger un document, l'inspecter, exécuter du code sur son contenu, en prendre une capture d'écran pour vérifier la mise en page, puis travailler dans un brouillon isolé (un « worktree ») qu'un humain accepte ou renvoie depuis l'interface web. Import et export XLSX, DOCX et PPTX passent par le SDK serveur, en Node.js.
Pourquoi c'est sympa. Le dépôt est dans les tendances GitHub ce week-end. Surtout, le découpage ressemble à ce qu'on fait déjà pour le code : l'agent édite dans une branche, produit une preuve visuelle, et un humain fusionne. Appliqué à un devis, un rapport ou un tableau de bord, c'est un circuit de relecture que la plupart des outils métier n'ont pas. Le tableur gagne au passage des références 3D et inter-classeurs, des tableaux croisés et des graphiques liés.
À quoi ça sert. Tu as un outil interne où les commerciaux exportent un fichier Excel pour construire un devis, le retouchent à la main et le renvoient par mail. Avec Univer, le devis vit dans ton produit ; un agent le pré-remplit à partir du CRM, vérifie que les totaux tiennent, joint une capture, et le commercial valide en un clic. Même logique pour un rapport mensuel généré depuis des données, avec une relecture avant envoi.
Pour quels projets. Les produits SaaS et outils internes qui ont du contenu Office au cœur du flux, et une équipe front capable d'intégrer un SDK lourd (rendu Canvas, plugins). À vérifier avant d'adopter : la 1.0 casse des API par rapport à la 0.25, le README annonce encore les PDF « bientôt » alors que la release les liste, et une partie des briques (conversion de fichiers, collaboration) vit dans des paquets « pro ». Ce n'est pas un outil pour l'utilisateur final : c'est une brique pour construire le tien.
La partie qui m'intéresse, c'est le worktree pour documents : l'agent bosse dans un brouillon, un humain fusionne. C'est exactement le flux que je défends pour le code, et je n'avais pas vu de brique propre pour l'appliquer à un devis ou un rapport. Reste à voir ce que pèse le SDK dans un vrai front. En tout cas, je suis vraiment fan !