Bunsho Engine produit les documents d’un site WordPress, et il les produit accessibles. Toute extension, tout thème, et l’assistante du site peuvent lui confier une demande ; il rend un PDF balisé qu’un lecteur d’écran traverse comme une page bien construite, et non comme une image de texte.
Des documents réellement accessibles
Chaque document sort conforme à la norme PDF/UA-1, et à PDF/A-3b quand l’archivage l’exige. Ce n’est pas une intention : l’arbre des balises porte les titres, les tableaux, les listes et les liens, aucun niveau de titre n’est sauté, les images décoratives restent hors de l’arbre, et la langue du document est déclarée. La conformité est mesurée à chaque livraison par un validateur indépendant.
L’accessibilité ne s’arrête pas au document : les écrans d’administration respectent le niveau AA des règles WCAG 2.1, se parcourent entièrement au clavier et s’annoncent correctement à un lecteur d’écran.
Trois circuits de production, au choix
Un service de conversion raccordé produit les documents les plus riches, par un navigateur sans écran ou par une suite bureautique. Un moteur embarqué en PHP pur produit les documents courts sans aucun service extérieur : un site sans serveur de conversion reste donc capable de produire ses documents. L’administrateur choisit son circuit, et une demande peut imposer le sien. Quand un service ne répond plus, le travail passe au suivant qui porte la même capacité, et le journal le dit.
Les factures électroniques
Une facture sort avec ses données structurées embarquées, au format Factur-X, dans un PDF/A-3b : elle est à la fois lisible par une personne et exploitable par un logiciel comptable. Les profils de la norme sont pris en charge, et le document reste accessible.
Des modèles rédigés dans l’administration
Un compositeur permet d’écrire ses propres modèles de document — contrats, attestations, conventions, courriers types — sans écrire une ligne de code. Un modèle porte ses parties, ses champs, ses articles et sous-articles numérotés, ses clauses conditionnelles et sa mise en page. Les valeurs se transmettent à la production, le texte reste celui du modèle, et chaque document produit garde la trace de la version du modèle qui l’a composé. Un modèle s’exporte et s’importe en JSON, ce qui permet de le préparer ailleurs ou de le partager entre sites.
Prêt pour la signature électronique
Un contrat peut porter, pour chaque partie, un champ de signature vide et balisé, nommé par l’appelant. Une extension de signature n’a plus qu’à le remplir : les validateurs classent alors chaque signature comme un remplissage de formulaire, et non comme une modification suspecte du document. Les champs portent leur nom accessible, et leur place dans l’ordre de lecture suit le libellé qui les annonce.
Quatorze mises en page, et votre identité
Quatorze modèles de mise en page couvrent la lettre, la facture, le relevé, le rapport, le compte rendu, le contrat et d’autres usages. L’identité de l’émetteur — raison sociale, adresse, mentions légales, logo — se règle une fois et sert tous les documents. Une extension tierce peut déclarer son propre habillage pour mettre les documents aux couleurs d’une marque, sans toucher à leur mise en page.
Pour les développeurs
Un contrat public stable est le seul point d’appui : ses fonctions ne changent pas de signature sans que sa version monte, et son historique est écrit dans le code. Un guide d’intégration, un guide des mises en page, un guide du compositeur et un relevé des vérifications accompagnent l’extension.
L’extension ne dépend d’aucune autre pour fonctionner. Elle s’intègre à l’assistante du site par treize capacités, qui lui permettent de produire un document, de le relire, de décrire un modèle ou de consulter le journal, selon les autorisations que l’administrateur accorde.
Exigences
WordPress 7.1 ou plus récent, PHP 8.3 ou plus récent. Les versions 8.3, 8.4 et 8.5 de PHP sont éprouvées. Un service de conversion est facultatif : sans lui, le moteur embarqué prend le relais.