Ariane est le projet le plus récent sur lequel j'ai pu travailler chez Valeco. Initialement, il était conçu comme une fonctionnalité de génération de quittances pour ACT (gestionnaire d'actifs fonciers). Cependant, notre volonté de transition progressive de ce projet vers une architecture micro-services associée à l'envie de les implémenter dans le reste de nos outils nous a poussé à en faire un applicatif à part entière. Suite à cette décision, ce qui était autrefois une simple édition de quittances d'indemnités foncières est devenu un service complet de publipostage et de génération de documents, utilisant NestJS plutôt que Next qui ne serait pas très pertinent pour une application ne disposant pas de front-end.
Ayant moi-même conçu le prototype de page de validation et de génération de quittances au format .docx sur ACT, c'est tout naturellement que j'ai été désigné comme référent pour ce service de publipostage et que je me suis attelé au développement de celui-ci après une réunion de conception expliquant les tenants et aboutissants, et les objectifs de ce service. Le but de celui-ci était à terme d'uniformiser pour tous nos applicatifs la génération de documents, qu'il s'agisse de documents Word ou de PDF, ainsi que l'envoi de mails automatiques aux collaborateurs de Valeco.
Même si l'application immédiate, et la première fonctionnalité à implémenter pour Ariane était la génération à partir de données reçues d'un document Word, il était essentiel pour nous d'avoir une vision des évolutions possibles de ce service. Cela a permis à toute l'équipe d'entrevoir l'ensemble du potentiel de l'outil et comment il pourrait s'intégrer dans chacun de nos projets en cours de développement avant même le début de sa création.
Suite à cette phase de conception, nous avons pris conscience que si je souhaitais pouvoir adapter Ariane à un maximum d'applications actuelles et futures de l'entreprise, il allait falloir designer un système d'interprétation des données reçues qui serait à la fois robuste et le plus générique possible. Sachant que j'avais comme contrainte, pour conserver au maximum l'indépendance du micro-service, d'utiliser le moins de bibliothèques externes possible, j'ai voulu opter pour un système de templating à la syntaxe simple et compréhensible afin de limiter la documentation à produire et le temps de compréhension pour les autres développeurs qui seraient amenés à interagir avec.
Ainsi, il leur suffirait grâce à une route d'API dédiée d'uploader un template et sa description sur le serveur, le template en question étant un fichier du type à générer (par exemple, pour les quittances, un fichier .docx) contenant l'ensemble des parties statiques du document, qui seront identiques à chaque génération, ainsi que des variables. Celles-ci sont notées entre doubles accolades pour les chaînes de caractères et entre crochets pour les éléments à insérer dans un tableau. Ce template serait à la fois stocké sur le serveur en chiffrant son nom pour des raisons de sécurité, et référencé en base de données, avec une description exhaustive de chaque variable attendue. Il suffit ensuite à l'utilisateur de faire une requête vers l'endpoint de génération de documents, de préciser le template qu'il souhaite utiliser, et d'envoyer les données à y insérer, et le document final leur serait renvoyé.
En parallèle du développement d'Ariane, un système complexe de détection d'anomalies était en pleine conception pour ACT. Ces anomalies devaient fatalement générer des notifications pour les utilisateurs, sous peine d'être ignorées, et les principaux concernés souhaitaient pouvoir recevoir ces alertes sans avoir à se connecter à l'outil, certains services ne l'utilisant que sporadiquement mais devant tout de même garder un œil sur son contenu. J'ai donc logiquement poursuivi le développement d'Ariane pour y inclure la possibilité d'envoyer automatiquement des mails contenant les données détaillées de ces anomalies et des objets qui y sont liés.
Cette partie a présenté un challenge supplémentaire. En effet, si on pourrait penser qu'un simple mail avec une structure HTML serait plus simple à gérer qu'un fichier plus complexe, les fichiers générés par Word sont en réalité de simples fichiers XML à la structure très normalisée, ce qui permet d'assez facilement manipuler leur contenu. Cependant, là où le système de templating pour un document Word pouvait se permettre d'être assez basique, avec des éléments de textes à remplacer, et des tableaux à une seule profondeur (on ne s'attendrait pas vraiment dans un document textuel à rencontrer un tableau dans un tableau), la structure des données à insérer dans un mail pouvait tout à fait se montrer plus complexe.
En l'occurrence, il a fallu jouer intelligemment avec le typage des données attendues pour pouvoir recevoir des tableaux à la profondeur potentiellement illimitée, sans pour autant briser la cohérence de la structure de données. Il fallait aussi améliorer le système de templates afin de pouvoir afficher intelligemment et efficacement toutes les données reçues. Étant donné qu'un template de mails était logiquement un fichier HTML/CSS, je suis parti du principe que ce serait la responsabilité des développeurs de créer et maintenir ces templates.
J'ai donc opté pour une syntaxe et un fonctionnement général proche de celui utilisé par nos outils et frameworks, tout en restant le plus simple et compréhensible possible. Il est ainsi possible, dans le template HTML, de déclarer via un commentaire qu'une certaine portion du template est rattachée à un tableau donné. Cette partie sera alors répétée pour chaque élément du tableau en question, cherchant à l'intérieur de ceux-ci les propriétés souhaitées. Ces propriétés peuvent alors elles-mêmes être des tableaux, répétant à nouveau une partie du code, afin de permettre des structures de données plus complexes. Bien entendu, de par la nature récursive de ce processus de génération, une limite de cinq a dû être fixée à la profondeur des données (le nombre de tableaux contenus dans des tableaux, eux-mêmes contenus dans des tableaux, …) afin d'éviter que des structures de données malencontreuses ne créent des problèmes de mémoire et de boucles infinies.
Aujourd'hui, Ariane est utilisé sur bon nombre de nos applications grâce à son système de templating à la fois simple à utiliser et appréhender et totalement adaptable. ACT est la première application à laquelle il a été intégré, mais d'autres ont rapidement suivi, l'envoi de mail et la génération de documents étant un besoin assez commun au sein de l'entreprise. Il est même envisagé de l'intégrer à des outils qui ne sont plus aujourd'hui en développement actif, comme Otis, afin de finir d'harmoniser ces fonctionnalités au sein de toute l'entreprise.
En tant que responsable de ce micro-service, j'ai la charge de former les autres développeurs à son utilisation, de rédiger et faire évoluer la documentation en fonction des besoins, et de le maintenir pour s'assurer qu'il continue de fonctionner correctement. Les retours de mes collègues sur celui-ci m'ont déjà amené à y apporter des modifications mineures, et je continuerai certainement de le faire évoluer à l'avenir pour faciliter son intégration à de futurs projets, qu'il convienne au mieux aux nouveaux usages qui pourront lui être trouvés et qu'il s'accorde au maximum avec la vision ambitieuse que nous avions pour lui dès sa conception.