Unstract : extraire du JSON de documents non structurés avec des prompts, pas des templates

Le problème : un schéma par fournisseur, un template par variante

Le README pose le diagnostic sous forme de tableau comparatif. Sans Unstract, la définition du schéma passe par des expressions régulières et des templates écrits fournisseur par fournisseur ; l'arrivée d'un nouveau type de document se compte en jours de développement ; l'intégration d'un LLM suppose de construire son propre pipeline ; la sortie reste un bloc de texte non structuré. Le public visé est nommé explicitement : finance, assurance, santé, KYC et conformité. Ce sont des secteurs où le document arrive sous forme de PDF, d'image ou de scan, et où la cible n'est pas le texte mais un objet JSON insérable en base. La promesse tient en une phrase du README : écrire un prompt une fois, et laisser le système absorber les variations entre documents. C'est un pari sur la robustesse des modèles plutôt que sur la précision d'une expression régulière, et ce pari ne se vérifie qu'avec vos propres documents, pas avec la documentation.

Prompt Studio, API, ETL : trois sorties pour un même schéma

L'architecture décrite dans le README s'organise en quatre composants : Frontend, Backend, Worker et Platform Service. Le schéma d'extraction se construit dans Prompt Studio, en langage naturel. Une fois le prompt en place, le même schéma peut être exposé de trois façons. En API Deployment, on envoie un document par REST et on reçoit du JSON. En ETL Pipeline, le système va chercher les documents dans un dossier, les traite, puis les charge vers l'entrepôt de données. Un MCP Server permet enfin de brancher la plateforme sur des agents (Claude est cité) via le Model Context Protocol, et un node n8n existe pour l'insérer dans des automatisations déjà en place. Le point intéressant est que ces canaux ne redéfinissent pas le schéma : ils consomment celui de Prompt Studio. Le point à surveiller est l'inverse : faire évoluer un prompt après mise en production change le comportement de tous les canaux à la fois, sans qu'un versionnage de schéma soit décrit dans le matériel fourni.

Fournisseurs LLM : le choix reste à votre charge

Le README cite OpenAI, Anthropic, Bedrock et Ollama comme fournisseurs branchables, sans décrire de mécanisme de routage, de repli automatique ni de cache. Cela signifie que la qualité de l'extraction dépend du modèle que vous configurez, et que le coût par document dépend du fournisseur retenu. Ollama permet d'envisager un traitement local, ce qui compte pour les secteurs réglementés cités plus haut, mais aucune donnée de performance comparée n'est fournie dans le matériel. Il faut donc lire cette liste comme une liste d'intégrations possibles, pas comme une garantie d'équivalence entre elles. Un schéma qui fonctionne avec un grand modèle peut échouer avec un modèle local plus petit, et rien dans la documentation fournie n'indique comment mesurer cet écart avant déploiement.

Installation : une commande, mais deux prérequis à ne pas rater

Le démarrage tient en deux commandes : git clone https://github.com/Zipstack/unstract.git, puis ./run-platform.sh. L'interface est ensuite accessible sur http://frontend.unstract.localhost, avec les identifiants unstract / unstract. Les prérequis sont explicites : Linux ou macOS (Intel ou série M), Docker et Docker Compose, 8 Go de RAM minimum, Git. Le script accepte plusieurs options documentées : -v pour épingler un tag de version, -u pour mettre à jour une installation existante, -b pour construire les images localement, -d pour le mode détaché, -e pour ne générer que les fichiers d'environnement, -p pour ne faire que le tirage des images, -h pour l'aide. Ces combinaisons peuvent s'enchaîner, par exemple ./run-platform.sh -u -b -v current pour une mise à jour construite depuis la branche de travail. Le README signale un piège concret : la valeur de ENCRYPTION_KEY, présente dans backend/.env ou platform-service/.env, chiffre les identifiants des adaptateurs. La perdre rend les adaptateurs existants inaccessibles. C'est le seul avertissement de sécurité du document, et il mérite d'être traité avant la première extraction, pas après.

La licence AGPL-3.0 change la question du déploiement

Unstract est publié sous AGPL-3.0. Cette licence impose des obligations dès lors que le logiciel modifié est mis à disposition d'utilisateurs sur un réseau, ce qui est précisément le cas d'un déploiement en API. Une équipe qui se contente d'utiliser la plateforme telle quelle et de consommer l'API ne se trouve pas dans la même situation qu'une équipe qui modifie le code et l'expose à ses clients. Le README renvoie vers une offre Enterprise sur unstract.com/pricing/, et mentionne un accord de contribution (CLA) via cla-assistant.io, ce qui indique une intention de garder la main sur les contributions. Ce texte n'est pas un conseil juridique : la qualification exacte dépend de votre usage, et un déploiement en API interne ou externe n'a pas les mêmes conséquences. À vérifier avec votre juriste avant de bâtir un produit dessus.

Le rythme de publication impose de figer les versions

Les releases fournies montrent v0.188.0 le 9 septembre 2026, v0.187.2 le 3 septembre, v0.187.1 le 1er septembre. Trois publications en huit jours, sur une numérotation 0.x, avec un dernier push sur main le 9 septembre. Ce rythme a une conséquence pratique : une installation lancée sans option -v récupère ce que le script considère comme la dernière version disponible, et une mise à jour -u peut faire passer plusieurs versions d'un coup. La montée de version n'est donc pas un non-événement. Le matériel ne fournit ni notes de migration ni politique de compatibilité entre versions, ce qui laisse la question ouverte. La seule mesure défendable, avec ce que l'on sait, est d'épingler un tag de release précis dans vos scripts de déploiement et de tester la mise à jour sur une instance séparée avant de toucher la production.

Face à une chaîne OCR puis LLM assemblée à la main

L'alternative la plus directe n'est pas un produit concurrent mais une chaîne construite soi-même : un OCR, un appel à un modèle, un parseur de sortie et un connecteur vers la base. Cette approche donne un contrôle total sur chaque étape et ne dépend d'aucune plateforme. Elle coûte ce que le tableau du README chiffre en jours de développement à chaque nouveau type de document, et elle laisse à l'équipe la charge du traitement des échecs, des relances et de la validation du JSON. Unstract déplace ce travail vers Prompt Studio et vers un déploiement conteneurisé. Le compromis est net : vous échangez du code que vous maîtrisez contre une plateforme que vous exploitez, avec quatre composants à faire tourner, une clé de chiffrement à gérer et une licence copyleft. Pour un seul format de document bien connu, la chaîne maison reste probablement plus légère. Pour une dizaine de formats qui bougent, la plateforme se défend.

Conclusion éditoriale

Unstract convient aux équipes qui traitent des documents hétérogènes (finance, assurance, santé, conformité KYC) et veulent remplacer des templates par des prompts, à condition d'accepter Docker, 8 Go de RAM et une licence AGPL-3.0. Il ne convient pas à qui cherche une bibliothèque Python légère appelable depuis un script existant : le produit se déploie comme une plateforme complète. Avant d'adopter, vérifiez deux points précis : que la valeur de ENCRYPTION_KEY lue dans backend/.env ou platform-service/.env est sauvegardée hors du dépôt, et que la version des images tirée par ./run-platform.sh -v est épinglée sur un tag de release plutôt que sur la branche main.

Sources officielles

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. Zipstack/unstract on GitHub