Bilan annuel 2025 de MaraDocs - Et nos projets pour l'avenir

La naissance de MaraDocs

De l'idée à un prototype complètement différent

Nos premières esquisses et nos plans pour ce qui allait devenir MaraDocs ont commencé au printemps 2024.

J'avais cette idée qu'il fallait automatiser ces fastidieux traitements de photos et de fichiers e-mails qui prenaient tant de temps. J'étais simplement frustré par ma propre activité d'avocat face au temps et à la complexité générés par le format des envois numériques des clients dans notre cabinet.

J'ai commencé par des croquis grossiers du processus optimal et j'ai parallèlement commencé à me pencher sur le machine learning. Je me souviens de ma résistance intérieure : serais-je capable, en tant que non-mathématicien, de développer mes propres modèles ML et de les utiliser dans un produit sérieux ? (Oui - cela a demandé beaucoup de travail d'apprentissage, mais c'est possible...)

Assez rapidement, le premier prototype a vu le jour : MaraMail était né. Nous avions construit une API e-mail conforme à la protection des données, à laquelle on pouvait envoyer l'un de ces e-mails problématiques, et MaraMail extrairait toutes les pièces jointes, découperait les documents, effectuerait la reconnaissance de texte et créerait ensuite des PDF propres. Ensuite, il renvoyait un e-mail avec les résultats à l'expéditeur.

Nous avons besoin d'interaction !

Il est rapidement devenu clair que l'envoi à une adresse e-mail et l'attente d'un résultat constituaient une interface utilisateur relativement inhabituelle pour un programme. Et Raui et moi avons assez vite réalisé qu'un tel produit (où il n'y a rien à voir) serait également difficile à commercialiser.

Je devais donc développer une application utilisable. Quelque chose de tangible.

Jusqu'alors, je n'avais que des connaissances rudimentaires en développement d'interfaces utilisateur. Mon premier projet hobby de frontend était une application React écrite en JavaScript pur (donc pas de TypeScript), avec laquelle je pouvais contrôler différents appareils domotiques comme des lumières. Mais je n'étais ni designer ni n'avais de réelles connaissances approfondies sur les applications web complexes.

Fin octobre 2024, j'ai commencé à écrire les premières lignes de la partie aujourd'hui visible de MaraDocs. Ce devait être un voyage d'apprentissage incroyablement passionnant. Et beaucoup plus de travail que je n'aurais pu l'imaginer dans ma naïveté initiale.

Quelques détails techniques du développement...

La stack est définie

Comme j'avais déjà écrit une application avec React, il était logique que MaraDocs soit également écrit en React. J'aimais le modèle général : les données circulent toujours dans une seule direction du component tree. On écrit du code déclaratif et React se charge de re-rendre l'interface visible lors des mises à jour des données.

React seul ne suffit pas pour un tel projet. Il faut des données persistantes quelque part : qui sont mes clients ? Qui peut se connecter ? Qui a acheté quelle licence ? Etc...

Ici, nous avons opté pour NextJs (avec ServerActions) et Prisma ORM sur une base de données PostgreSQL auto-hébergée. NextJs est de toute façon le choix le plus évident quand on utilise React. Je ne regrette pas cette décision à ce jour. Elle m'a permis d'itérer très rapidement sur les différentes idées et approches et a été effectivement relativement rapide à apprendre.

Les bibliothèques de state et la puissance du middleware

Je connaissais déjà, grâce à mon projet hobby précédent, la problématique du « state transmis en profondeur » et je savais que pour un projet plus complexe comme MaraDocs, je devais recourir à une bibliothèque de state qui me permettrait une sorte de gestion centralisée des données dans le frontend.

Il est difficile, en tant que débutant absolu dans ce domaine, de prendre la bonne décision ou sélection, et en même temps ce choix précoce mais nécessaire d'une technologie détermine fortement tout le déroulement ultérieur du développement. Après quelques jours de recherche, j'ai opté pour Redux RTK. C'est certainement une décision controversée : Redux est relativement ancien et est souvent critiqué sur Internet dans les forums de développeurs pertinents (Reddit, etc...).

Sans entrer trop dans les détails : Redux est basé sur une architecture de données ou de processus dans laquelle les composants visibles dépendent du state et se mettent à jour en cas de modifications. La seule façon de modifier ces données passe par des dispatchers qui reçoivent ou exécutent des actions et modifient ainsi le state. (state signifie quelque chose comme données actuelles).

Là encore, je ne regrette pas cette décision. Redux impose un certain modèle architectural. Les structures de données et les fonctions qui les modifient (actions) sont définies en un seul endroit, ce qui crée automatiquement une certaine structure dans le projet. On pourrait dire que Redux est relativement opinionated quant à la structuration de son propre code.

De plus, l'architecture des actions offre une puissante possibilité d'intervention : le Middleware.

Via un ou plusieurs niveaux de middleware, nous pouvons intervenir dans les actions envoyées ou exécuter d'autres tâches à partir de celles-ci. Un exemple : dans le frontend, l'utilisateur clique sur « Importer image » et sélectionne une image de son disque dur. Le component dans le frontend reçoit l'image et envoie (dispatch) ensuite une action addImage, qui contient des informations sur l'image importée. Dans le middleware, nous interceptons cette action, générons un ID unique, extrayons l'image et l'envoyons via api call à l'API MaraDocs, puis transmettons l'action avec des informations enrichies au store.

C'est là que la boucle est bouclée : la partie visible du site web voit maintenant dans le store qu'il y a une autre image et l'affiche sur la base des données stockées dans le store.

Cela fonctionne vraiment très bien.

Socket.io - quand on pense que ça doit aller vite

Une décision erronée précoce a été qu'au début du développement de MaraDocs, nous avons décidé de communiquer avec les processus serveur de traitement de fichiers via socket.io.

Petite explication de base : normalement, les sites web sont toujours demandés par le navigateur. Si vous ouvrez Wikipédia par exemple, votre navigateur demande la page à Wikipédia. Pas l'inverse. Cela signifie cependant aussi que Wikipédia ne peut pas vous envoyer de mises à jour pendant votre visite sur le site. (Ce n'est peut-être pas nécessaire pour Wikipédia...)

Avec MaraDocs, voici essentiellement ce qui se passe : vous ou le navigateur téléchargez par exemple un fichier photo (vous l'envoyez donc à notre serveur de traitement de fichiers) et attendez que celui-ci ait traité le fichier. Les résultats intermédiaires, dont dépend à son tour l'affichage sur le site web, sont par exemple :

• la photo contient un ou plusieurs documents
• les coordonnées des points d'angle des documents contenus
• les nouveaux fichiers image des documents découpés
• le résultat PDF avec reconnaissance de texte est prêt
• etc...

Nous voulons bien sûr que ces résultats intermédiaires soient renvoyés au navigateur le plus rapidement possible pour tous les fichiers téléchargés et affichés pour l'utilisateur.

Il est donc logique de recourir à une technologie adaptée à cette initiation de communication bidirectionnelle : Socket.io.

Socket.io établit une connexion permanente entre le navigateur et le serveur et permet également au serveur d'envoyer ses propres messages (events). Le programme dans le navigateur (MaraDocs) doit maintenant écouter les nouveaux events sur cette connexion et ensuite faire certaines choses en fonction de leur contenu.

Cela fonctionne fondamentalement bien - et MaraDocs a fonctionné jusqu'au 17 novembre 2025 selon exactement ce principe.

Un effet que j'avais sous-estimé était que nous nous sommes ainsi rapprochés architecturalement de ce qu'on appelle le event driven design. C'est bien sûr un modèle architectural établi dans le développement logiciel, mais je dirais qu'il apporte plus d'inconvénients que d'avantages pour une application web classique. En particulier, la séparation « spatiale » dans le code entre les fonctions d'envoi d'événements et les fonctions de traitement des résultats crée une complexité non négligeable. Des avantages comme la sécurité de type doivent être payés cher en utilisant des bibliothèques comme protobuf. Les tests sont également difficiles.

Nous avons finalement décidé, dans une grande (vraiment très grande) opération de restructuration, de faire nos adieux à socket.io et de revenir au paradigme le-navigateur-demande, en modélisant tous les events précédents comme de simples appels d'API REST, dans lesquels le serveur transmet le résultat directement sur l'appel. Plus de détails dans la section suivante.

L'API MaraDocs alias MaraDocs 2.0

Pour résoudre les problèmes que je rencontrais au printemps dans mon activité d'avocat avec les e-mails et fichiers envoyés par les clients, nous avons dû plonger assez profondément dans la boîte à outils technique à bien des égards.

Le traitement évolutif, sécurisé et parallèle de nombreux fichiers en utilisant différents modèles de machine learning sur nos propres serveurs est en soi une prouesse technique (le respect va à ce stade à Raui Ghazaleh, mon cofondateur).

Nous avons réalisé assez tôt dans le développement que le potentiel technique de notre logiciel allait bien au-delà de ce que représente l'application web MaraDocs.

L'application web MaraDocs utilisable est conçue précisément pour son cas d'usage et fonctionne brillamment à cet effet : un utilisateur fait glisser manuellement des e-mails dans le navigateur, trie les résultats en PDF finalisés et les télécharge.

Notre système peut cependant faire beaucoup plus : grâce à l'API MaraDocs que nous avons développée au cours des 4 derniers mois (août à novembre 2025), il devient possible d'utiliser l'automatisation (par exemple avec n8n) ou d'intégrer MaraDocs directement dans des logiciels tiers.

Nous sommes en discussion avec différentes entreprises qui souhaitent intégrer des fonctionnalités partielles de MaraDocs (par exemple l'extraction d'e-mails ou l'OCR) dans leur logiciel.

Nous sommes très curieux du développement futur de cette branche commerciale de notre entreprise.

Pour nous, il était cependant clair que nous voulions considérer l'application web MaraDocs elle-même comme un client de notre propre API. Nous avons donc complètement remplacé le modèle de traitement précédent avec socket.io par des appels d'API dédiés et nous n'utilisons maintenant avec MaraDocs que notre API MaraDocs publiquement disponible.

Ce système fonctionne de manière stable et en production depuis le 17 novembre 2025.

Et le business ?

Advotec à Berlin et RAExpo à Munich

Nous avons reçu un retour incroyablement positif dans la scène LegalTech et du logiciel juridique. MaraDocs était présent au salon Advotec (accompagnant le Congrès des avocats allemands) à Berlin et au RAExpo à Munich.

Ce qui était particulièrement intéressant, c'étaient les réactions des clients (potentiels) : lors de la démonstration de MaraDocs, il apparaît très rapidement si un cabinet a besoin de MaraDocs ou non. Pour moi personnellement, c'était toujours incroyablement gratifiant quand des collègues acquiesçaient (et visiblement éprouvés) :

« Oui, oui, exactement, horrible, ces mauvaises photos, tout mal orienté et puis encore les pieds dessus en bas ! »

MaraDocs sur le marché des logiciels juridiques

Mais au-delà du contact avec de nombreux collègues qui nous ont fourni des retours précieux tant sur les salons que lors de contacts clients ultérieurs, l'échange avec d'autres acteurs du marché des logiciels juridiques nous a énormément fait progresser.

Nous avons pu notamment bien nous mettre en réseau avec les collègues de stp.one et avons vu un grand chevauchement thématique. Cela se comprend aussi : par expérience personnelle, je sais que le logiciel de cabinet (le logiciel de gestion de dossiers) est le cœur de chaque cabinet. C'est l'endroit où les avocats et les employés « vivent » pratiquement lorsqu'ils travaillent.

Dans mon cabinet, nous utilisons avec succès depuis de nombreuses années Advoware de stp.one. Advoware et MaraDocs se complètent simplement extrêmement bien dans le quotidien du cabinet. Particulièrement pour les e-mails où les clients ont intégré des photos dans l'e-mail ou ont envoyé les images dans le format propriétaire Apple (.heic), MaraDocs brille et convertit tout cela en PDF optimaux, avec reconnaissance de texte, taille réduite, avec lesquels on peut ensuite continuer à travailler dans Advoware.

À ce stade : un grand merci aux collègues de stp.one. Nous nous réjouissons d'une année 2026 réussie ensemble avec vous.

Networking dans la scène

Mais au-delà du partenariat à souligner avec stp.one, nous avons noué de précieux nouveaux contacts avec de nombreuses entreprises, entrepreneurs et entrepreneures extraordinaires et sympathiques lors des salons.

Le contact avec les spécialistes SEO et marketing d'OMmatic, les fondateurs d'iurApp ou encore l'opportunité de présenter MaraDocs au RAExpo à d'autres éditeurs de logiciels comme Actaport ou aux poids lourds du secteur RA Micro et Wolters Kluwer nous ont fait progresser en tant qu'entrepreneurs mais aussi en tant qu'entreprise - et plus important encore : nous ont fait passer un excellent moment au salon ou lors de la visite au restaurant qui a suivi !

En tout cas, je suis curieux de ce qui en résultera pour MaraDocs l'année prochaine.

Merci beaucoup ! Nous nous réjouissons de vous retrouver en 2026 !

Ce que nous prévoyons pour l'année prochaine

Nous avons accompli énormément de choses avec MaraDocs en 2024 et 2025. Avec beaucoup de sueur (au moins sur le plan cognitif), de persévérance et de ténacité, nous avons développé à partir de rien un merveilleux logiciel que j'utilise moi-même volontiers chaque jour dans mon activité d'avocat.

Nous avons une très longue liste de fonctionnalités que nous voulons intégrer l'année prochaine :

• Amélioration visuelle des résultats de scan (suppression de l'arrière-plan)
• Réintroduction de la fonctionnalité MaraMail avec lien vers la session MaraDocs
• Plugin Outlook optionnel ou MaraDocs en tant qu'application native (installable)
• Compression améliorée des résultats / plus d'options de sélection
• Fonction de tampon PDF ou annotation de PDF
• et bien plus encore...

Sur le plan commercial, nous voulons bien sûr toucher beaucoup plus de cabinets et les convaincre de MaraDocs. Nous savons aussi que le marché des cabinets de conseil fiscal est similairement adapté et nous souhaitons gagner davantage de clients ici.

Un grand sujet pour nous est également l'internationalisation de MaraDocs. Actuellement, nous avons déjà des clients en Allemagne, en Autriche, en Suisse et en Pologne, mais nous ne prenons actuellement en charge aucune autre langue que l'allemand. Il y a donc encore beaucoup à faire pour réussir également sur les autres marchés européens.

En tout cas, nous regardons vers l'avenir avec beaucoup d'enthousiasme, d'idées fraîches et de bonne humeur 😀 !

Merci à tous ceux qui nous accompagnent sur ce chemin !

Martin et Raui de MaraDocs.

MaraDocs crée des PDF optimisés à partir de documents clients

Ceux qui reçoivent des images au lieu de PDF de la part de clients n'ont plus besoin de convertir manuellement. MaraDocs prend en charge l'ensemble du processus - rapidement, de manière fiable et sans perte de qualité.

• Importez simplement des e-mails entiers
• toutes les images sont automatiquement analysées et extraites
• vous obtenez au final des PDF optimisés

MaraDocs - comme si le client avait utilisé une application de scanner.

🚀 Essayez maintenant : Essayez MaraDocs gratuitement

---