Un outil pour les auteurs des documents
Chez GYS, la demande initiale concernait la migration de plusieurs fonds documentaires vers GitLab. J’ai proposé d’en faire un logiciel de conversion utilisable par les collègues qui créent ces documents. Ils savent ce qui reste pertinent, ce qui doit être corrigé et dans quel projet le classer. L’application devait leur permettre de conserver leurs habitudes bureautiques tout en préparant une documentation commune.
J’ai construit le parcours autour du dépôt de fichiers, de la conversion en Markdown avec les images et pièces jointes, du traitement par lots et de l’aperçu. Les résultats restent accessibles dans le stockage local ; la personne peut les revoir, les restructurer puis préparer leur publication.
Choisir le traitement adapté au document
Je pensais d’abord utiliser Marker pour tous les formats. À la demande de mon tuteur, j’ai développé un convertisseur natif pour comparer les résultats. Lire directement les objets d’une présentation permet de conserver du texte éditable ; interpréter une page rendue répond à un autre problème, notamment pour les PDF.
J’ai conservé les deux approches. Sur PowerPoint, un score de complexité oriente le traitement entre extraction des éléments et capture de la diapositive. L’étude du fonds couvre 981 diapositives : 74 % sont sous le seuil de capture intégrale. Ce chiffre décrit le choix de traitement, pas un taux de fidélité. J’ai aussi ajouté LibreOffice comme moteur de rendu pour les postes sans PowerPoint.
Restructurer avec un workflow inspectable
J’ai conçu un graphe LangGraph pour transformer les fragments de diapositives en chapitres suivis. Il décrit les images, prépare un plan, rédige par parties avec une mémoire de résumé, puis construit et contrôle les diagrammes. Les diagrammes sont rattachés aux diapositives d’origine afin de conserver une référence pour leur composition.
Les contrôles portent sur la couverture du plan, les ressources et la structure des sorties. Les prompts demandent de préserver les valeurs absentes et les incertitudes techniques. Un inspecteur permet de consulter étapes, prompts, modèles, consommations et résultats intermédiaires. La revue humaine reste nécessaire pour juger le contenu réécrit ; la conversion initiale est conservée à côté.
Faire évoluer les moteurs et les usages
J’ai séparé les moteurs Python de l’interface Tauri, développée avec Rust et React. Le même parcours peut ainsi utiliser Marker localement, sur un serveur interne ou dans un environnement GPU distant. La restructuration accepte aussi un serveur de modèles interne compatible avec son interface d’appel.
Cette séparation permet de maintenir les moteurs sans reprendre toute l’application. Les fichiers restent la référence du stockage, tandis que les historiques et les archives de workflows rendent les traitements consultables après leur fin.
Revoir puis publier
La publication est un module séparé des convertisseurs. GitLab est la destination actuelle ; d’autres connecteurs peuvent être ajoutés sans reprendre la conversion ni le parcours de revue.
La préparation GitLab présente les pages à ajouter, modifier, déplacer ou supprimer avant l’envoi. Un registre associe le commit publié à une empreinte du Markdown et de ses images : une image modifiée suffit à identifier une nouvelle version.
L’application a été livrée à GYS et constitue le sujet de mon mémoire de fin d’études. Le code appartient à l’entreprise et reste privé.