Un analyste a conçu avec Claude un éditeur UML avec schémas GOST : première version en 2 heures

Un analyste système avait besoin d'un éditeur UML accessible depuis la Russie et qui n'exige rien d'installé sur son poste de travail. Faute de solution toute faite, il a construit la sienne avec Claude. La première version fonctionnelle d'umleditor.ru est apparue en deux heures. Le site propose aujourd'hui des logigrammes conformes aux GOST avec un moteur de rendu dédié, un éditeur JSON et une référence de 70+ pages. Les diagrammes sont générés par un serveur PlantUML déployé à Moscou.

D'où vient le besoin

Les diagrammes UML font partie du quotidien d'un analyste système. Le site officiel plantuml.com ne s'ouvre pas depuis la Russie. Il reste les options locales : Java, un plugin d'IDE, un VPN. L'auteur ne voulait ni l'une ni l'autre, surtout pas sur un ordinateur d'entreprise.

La solution est simple : un éditeur dans le navigateur. Le code PlantUML s'écrit à gauche, le schéma s'affiche immédiatement à droite. Pas d'inscription. L'auteur insiste par ailleurs sur la confidentialité. Le rendu se fait sur son propre serveur à Moscou, et le texte des diagrammes, qui contient souvent des noms de systèmes, d'intégrations et de services internes, n'atterrit pas sur des plateformes tierces. Pour un analyste qui dessine des schémas de projets professionnels, cet argument pèse plus lourd que le confort de l'interface.

Qui a fait quoi

L'auteur décrit la répartition du travail sans détour. Claude a écrit l'interface, la partie serveur, les scripts pour le serveur et même les textes de la référence. Lui-même expliquait ce qu'il voulait, examinait le résultat et demandait des corrections. Il s'est aussi chargé de ce qu'un réseau de neurones ne peut pas faire : payer l'hébergement, acheter le domaine, saisir les mots de passe.

Ce dernier point compte plus qu'il n'y paraît. Le modèle couvre presque tout le cycle de développement, mais l'accès à l'argent, aux comptes et à l'infrastructure reste entre les mains de l'humain. C'est généralement à cette frontière que passe la responsabilité d'un projet.

Paramètres clés du projet, d'après la description de l'auteur :

• première version fonctionnelle : environ deux heures ;
• format : éditeur UML web, le schéma se met à jour au fil de la saisie du code ;
• rendu : serveur PlantUML maison à Moscou ;
• inscription : non requise ;
• ajouts : logigrammes conformes aux GOST avec leur propre moteur de rendu, éditeur JSON ;
• référence : 70+ pages ;
• auteur du code : Claude, y compris les scripts serveur et les textes.

Le point le plus intéressant

D'après la description, la partie la moins triviale du projet est celle des logigrammes conformes aux GOST. PlantUML dessine d'origine les schémas dans son propre style, alors que les normes russes imposent des formes et une mise en page précises. L'auteur a donc eu besoin d'un moteur de rendu distinct. Pour les analystes système qui remettent de la documentation selon les exigences d'un client ou de projets publics, c'est un vrai point de friction : il faut redessiner le schéma à la main dans un autre éditeur.

L'article original sur Habr promet du code et des chiffres sur l'architecture du service. L'annonce n'en contient pas : impossible donc, pour l'instant, d'évaluer la charge, le coût du serveur ou la qualité du moteur de rendu GOST. On ignore aussi comment le service gère un fort volume de requêtes et quelles mesures de protection sont en place sur ce serveur de rendu public. Ce sont les questions habituelles posées à tout serveur PlantUML ouvert.

Ce qu'il faut en retenir

Le projet illustre un scénario praticable pour un spécialiste sans équipe de développement. On prend une tâche précise de son métier, on la décrit au modèle et on vérifie le résultat à la main. Le seuil d'entrée est bas : deux heures jusqu'à la première version.

Conclusions pratiques :

• si un outil de travail est inaccessible à cause de sanctions ou de blocages, l'auto-hébergement de PlantUML sur un petit serveur reste le moyen le plus simple de conserver ses habitudes de travail ;
• avant d'envoyer des diagrammes à un moteur de rendu public, vérifiez qu'ils ne contiennent ni noms de systèmes internes ni adresses ;
• en vibe coding, décidez à l'avance de ce que vous faites vous-même : paiement, domaines, secrets et accès, mieux vaut ne pas les confier au modèle ;
• les schémas GOST méritent d'être testés sur des documents réels avant d'être remis au client.

L'auteur promet une analyse technique complète dans son article sur Habr.