Nouveauté - Mode démo MaraDocs et architecture logicielle

Nous avons profité du week-end de Pâques pour développer et publier un mode démo pour MaraDocs.

Le blog MaraDocs est un mélange de plateforme d'annonces d'événements liés à MaraDocs, mais aussi un espace pour mettre par écrit des réflexions juridiques et techniques.

Nous sommes incroyablement fiers...

Raui et moi avons travaillé intensivement sur MaraDocs l'année dernière. Après quelques mois de travail préparatoire de ma part, nous avons certainement consacré 8 mois au développement pur du produit. Toujours avec un objectif en tête : créer la solution de traitement de documents pour les cabinets d'avocats qui nous libère tous de la souffrance liée à la qualité de plus en plus médiocre du courrier entrant.

Nous avons collaboré avec quelques cabinets partenaires (merci à Me Bafteh du cabinet BSvH !) pour nous assurer de ne pas développer à côté des besoins des utilisateurs finaux. Et nous avons reçu de nombreux conseils très utiles : par exemple, l'aperçu des documents a été largement développé grâce aux retours d'une utilisatrice précoce (avocate en droit de la famille à Fribourg, merci beaucoup :)) et aux commentaires des collaboratrices du secrétariat du cabinet Kurtz & Lynen (https://kanzlei-kurtz.net).

...et pourtant, il reste encore beaucoup à faire

Un bon produit ne suffit pas à faire un produit à succès. MaraDocs est excellent et est utilisé quotidiennement et apprécié par ceux qui l'utilisent pour leur travail quotidien. Mais ceux qui ne l'utilisent pas encore ne le connaissent généralement pas.

Dans un monde surchargé d'informations, il n'est pas facile d'obtenir l'attention de clients potentiels.

Le parcours du client potentiel est long :

• Il y a quelque chose là...

• Je vais essayer ça...

• Je vais effectivement sur le site web...

• Je m'inscris avec mon adresse e-mail...

• Je clique sur le lien de connexion que j'ai reçu par e-mail...

• J'ouvre l'application et j'ajoute des pièces jointes d'e-mails à optimiser et je réalise que le produit est génial.

Raccourcis vers l'application

Avec le mode démo, nous pouvons réduire drastiquement ce parcours et offrir aux clients potentiels une expérience précoce, simple et authentique pour essayer MaraDocs. MaraDocs est agréable à utiliser : l'interface claire et le déplacement et la combinaison de pages pour créer de nouveaux PDF ont quelque chose de ludique.

En même temps, le mode démo ne nous coûte rien. Pour comprendre le contexte, il faut savoir que le téléchargement de fichiers réels et de pièces jointes d'e-mails génère des coûts dans notre infrastructure. Nous devons maintenir certaines ressources pour traiter rapidement et de manière réactive les demandes de traitement des utilisateurs. Un mode démo qui enverrait de vrais fichiers à nos serveurs sans même nécessiter d'inscription pourrait facilement conduire à une surcharge de nos serveurs par un grand nombre de requêtes, ce qui pénaliserait nos clients réels.

Implémentation technique

Nous utilisons React / NextJs pour le frontend. L'application React qui s'exécute dans le navigateur communique en mode normal avec nos serveurs responsables du traitement des fichiers via WebSocket (WebSocket est une connexion bidirectionnelle qui permet au serveur d'envoyer également des résultats au navigateur de manière autonome, c'est-à-dire sans requête du navigateur).

Il était important pour moi de développer le mode démo de manière à ce qu'il reflète toujours l'état actuel du développement de MaraDocs et ne constitue pas un nouveau système supplémentaire qui devrait être développé de manière indépendante.

Middleware Redux

Une grande partie de la logique de flux interne de l'application est contrôlée par des middlewares Redux. En fin de compte, on peut imaginer l'application comme une énorme machine à états, où différents événements déclenchent des processus prédéfinis et modifient la représentation interne des données.

Un événement peut être par exemple le clic sur un bouton (ex : faire pivoter cette page PDF) ou encore l'insertion d'un fichier dans l'application ou même un message WebSocket du serveur avec les résultats d'un PDF optimisé.

J'avais décidé d'implémenter les parties asynchrones des actions consécutives à ces événements, c'est-à-dire l'envoi de données via WebSocket au serveur, mais aussi certains des traitements PDF extensifs que nous effectuons dans le navigateur, dans la logique du middleware. Ce(s) middleware(s) écoute(nt) et réagit(ssent) à certains événements et exécute(nt) ensuite la logique correspondante.

Hot-Swapping de Middlewares

En mode démo, notre application normale est donc lancée. Lors de l'enregistrement des différents middlewares, celui qui gère normalement la communication WebSocket est cependant remplacé par un middleware de démonstration qui, lors d'événements correspondants, affiche des résultats simulés (préfabriqués) avec un petit temps d'attente.

Ces fichiers n'ont donc pas besoin d'être analysés et optimisés à chaque fois par nos serveurs, mais seulement une seule fois. Ensuite, ils peuvent être chargés à plusieurs reprises depuis notre cache statique et ne génèrent ainsi pratiquement aucun coût.

Réflexions générales sur Redux

Redux est une façon particulière de gérer l'état dans les applications Javascript. L'idée sous-jacente est que seules les actions, qui doivent être exécutées d'une manière bien définie, peuvent modifier les données d'état présentes dans l'application. React, par exemple, peut ainsi s'assurer que les parties visibles de l'application réagissent aux changements d'état.

La bibliothèque Redux, qui a popularisé ce modèle logiciel au moins dans le monde du frontend (Redux), est parfois considérée comme trop complexe et est remplacée dans de nombreux projets plus récents par des alternatives plus légères. Nous avons cependant soigneusement évalué son utilisation pour notre cas. En particulier, la puissante structure de middleware nous a permis d'intégrer une application aussi complexe que MaraDocs dans le navigateur.

Le mode démo et la facilité avec laquelle nous pouvons l'activer et le désactiver en remplaçant un seul « module » (le middleware) confirment pour moi que nous avons misé sur le bon cheval.

Conclusion

Je me réjouis particulièrement des collègues du barreau qui partagent avec moi la passion pour la numérisation et le développement logiciel.

L'article d'aujourd'hui était un peu plus technique. Mais c'est comme ça parfois : on commence de manière anodine et on finit par plonger un peu plus profondément dans les sujets.

Retours / Feedback / Questions très volontiers via LinkedIn ou par e-mail à info@maradocs.io.