Journal La petite histoire de la naissance d'un logiciel libre de Notes de Frais : DoliSCAN

Posté par  . Licence CC By‑SA.
35
30
mai
2020

Sommaire

Salut à toi Journal,
je vais te raconter une petite histoire, celle de la naissance d'un logiciel libre qui prends son envol et pour lequel j'ai envie de garder une trace avant qu'il ne soit trop tard ;-)

C'est "La petite histoire de DoliSCAN"

Après avoir développé plein d'outils en php3 il y a de (très) longues années, puis porté plus ou moins tout ça en php4 et maintenu du code pendant tout ce temps j'ai eu envie de me lancer dans un nouveau projet avec des technologies actuelles tout en restant sur PHP (je vois venir les sarcasmes "tu repassera pour les technologies actuelles avec ce vieux langage") :-)

J'ai passé quelques semaines à regarder les différents frameworks et me suis finalement posé sur Laravel, j'ai acheté le bouquin en français sur le sujet histoire d'avoir une vue d'ensemble et je me suis lancé dans l'aventure.

Après quelques micro-poc je me suis attelé à une idée un peu plus conséquente : créer un logiciel libre de notes de frais. Dolibarr mon compagnon historique propose bien un module en ce sens mais je souhaite "creuser une idée" un peu originale.

Et puis surtout j'ai croisé des gens qui utilisent des services "cloud" de gestion de notes de frais sans avoir aucune idée de l'exploitation probable des données qu'ils collectent … ça c'est pour ma motivation profonde, celle qui ne changera pas et qui n'a pas vraiment changée depuis plus de 20 ans (hé merde cher lecteur tu sais maintenant que je suis vieux).

J'ai eu pour idée de faire un modèle client/serveur "hybride" : backend en php et éventuellement frontend web mais surtout frontend "application sur smartphone" car ce qui m'intéresse est de pouvoir prendre en photo mon justificatif de frais au moment où il est entre mes mains au lieu de tout faire à la fin du mois et de perdre du temps à chercher mes facturettes, les scanner (et hurler contre ce papier et cette encre qui s'efface au bout de quelques semaines et je ne parle pas de leur capacité de froissage instantané ou de résistance à l'humidité).

Comme j'avais une petite expérience de cordova pour faire des appli simplissimes sur smartphone je me suis demandé s'il ne serait pas possible de mixer tout ça: cordova sur le smartphone et laravel sur le serveur + une interface web en complément.

Le dev serveur : laravel

Que dire de plus que "RAS" ou bien "ça marche, ça fait ce qu'on lui demande et c'est vraiment efficace" ? Lister les problèmes rencontrés ? Analyser les solutions ? Je ne sais pas ce qui pourrait vous intéresser donc je passe en revue rapide les éléments qui me semblent importants:

Si je résume laravel je vois ça non pas comme seulement un framework mais plus comme une énorme source de solutions … Par exemple j'ai envie de rédiger de la doc propre … direction https://github.com/saleem-hadad/larecipe ou de faire des requêtes sur des webservices ? https://github.com/guzzle/guzzle et ainsi de suite … au final on a certes un bon gros paquet de modules qui pèsent lourd et je pense que ça doit faire grincer les dents des puristes de la légèretés … mais du point de vue du développeur qui a déjà fort à faire c'est un énorme gain de temps !

Tiens un autre exemple, je lance mon application en pré-prod et je me dis que ça serait pas mal d'avoir des logs "applicatifs" pour savoir par exemple que la personne X (qui a les droits en modification sur les notes de frais de l'utilisateur Y) a modifié la note Z le 12 janvier à 18h pour remplacer le montant de la TVA qui était de 2,3€ par 23€ … disons même que c'est le genre de chose quasi indispensable dans ce genre d'outil … rapide recherche, analyse des différentes solutions et j'implémente ça en m'appuyant sur https://github.com/spatie/laravel-activitylog (ce sont les mêmes que pour la gestion des permissions).

De fil en aiguille le projet avance, il tourne et je commence à avoir des clients sans avoir fait de publicité, on est loin de l'équilibre par rapport au temps passé en R&D mais je compte sur toi journal pour lui donner une visibilité planétaire (francophone déjà ça serait bien) et me proposer des associés ou commerciaux … voir même des contributeurs :)

Le dev du client : cordova

Alors sur ce sujet j'ai lu tout et son contraire, ceux qui prédisent que cordova est foutu car apple et google poussent cette techno vers la sortie … ceux qui disent que ça marche et qu'il n'y a pas de raison que ça change …

Mon point de vue est clair : à partir du moment où on s'aventure sur ces écosystèmes on est forcément esclaves de ces deux géants. Alors autant tenter le coup avec une application multiplateforme et rapide à développer. Bon pour "rapide" vu le temps passé je pense qu'on pourrait en reparler mais en tout cas je n'ai pas à redévelopper la même chose en code natif objective-c d'un côté et kotlin de l'autre (de mémoire).

Au niveau de cordova, j'aurais bien aimé pouvoir utiliser OpenCV sur l'acquisition directe des images, ça semble vraiment complexe et lourdingue alors je suis resté le plus léger possible:

  • L'appli fait des photos via l'application photo que l'usager décide d'utiliser (merci cordova-plugin-camera), pour android je conseille très fortement l'excellente application OpenNoteScanner https://github.com/ctodobom/OpenNoteScanner qui permet de transformer la facturette en noir & blanc, léger à transporter sur le réseau et plus propre à envoyer dans un OCR quand ça sera prêt
  • Il faut quand même pouvoir découper (cropper) les photos, direction le plugin cordova-plugin-image-cropper
  • J'ai eu besoin de faire des tests DNS, le plugin cordova-plugin-dns apporte une solution
  • Du stockage "permanent" de données hop cordova-sqlite-storage

Et c'est tout, tout le reste est codé en html5 + jquery + l'excellent onsen.ui dont je suis absolument fan du nom à la française :-)

L'interface est sobre, dépouillée même, mon objectif n'est pas de faire sexy mais d'avoir un outil fonctionnel.

Je prévois quand même de faire une autre version avec un autre toolkit qui serait moins sur la voie de l'expulsion par Apple vu que j'ai des clients ça serait con de leur dire "pardon l'expérience se termine brutalement" :-)

L'offre commerciale

Même si mon but est qu'on puisse auto-héberger tout ça la demande en solution hébergée existe (et puis finalement auto-hébeger le serveur et mettre tout en place demande quand même pas mal de temps et de compétences).

C'est même elle qui permettra de continuer la petite histoire … le prix de départ est de 5€/mois/utilisateur. 5€ pour économiser des heures d'emmerdes à la fin du mois ça me semble être correct, dis moi toi lecteur quel est ton avis à ce sujet ?

Il faudra avoir un paquet de clients pour que ça puisse payer le salaire du développeur mais j'y crois :-)

Là où ça marque des points c'est que DoliSCAN génère le fichiers des écritures comptables et les envoie tout seul à ton expert comptable à la fin du mois, il n'a donc plus le tas de facturettes scotchées sur des feuilles A4 avec un tableau récapitulatif à re-saisir … il n'a qu'a importer le fichier et valider les écritures … gain de temps énorme et là c'est bien plus de 5€ qu'il économise …

La liberté dans tout ça, ça se prouve !

Ha oui pardon, je viens de mettre en place https://doliscan.org c'est même uniquement ça qui motive l'annonce sur linuxfr … jusqu'à présent j'avais tout sur ma forge logicielle (redmine auto hébergée) mais là on change de catégorie.

En résumé:

Une petite larme coule, la première ligne de code de doliscan remonte au 25/02/2019 pour le serveur et 05/02/2019 pour l'appli cliente … je laisse ici une petite trace dans le cosmos de linuxfr ,-)

  • # Bonne idée

    Posté par  (site Web personnel) . Évalué à 8 (+6/-0).

    Pour avoir récemment galéré avec des notes de frais pour une asso, je ne peux que saluer l'initiative. Prendre une photo et envoyer est effectivement une excellente idée. J'attends que Fdroid valide pour tester plus. Le lien vers Google Play n'est pas bon, par contre (ça pointe sur une erreur 400).

    Concernant ton site web, une petite suggestion : rajoute des captures d'écran, qu'on puisse se faire une idée de ce à quoi ressemble le logiciel. Ça aide à se décider à tester.

    Concernant l'installation sur le serveur, la doc dit :

    l'application DoliSCAN pour smartphone détectera automatiquement sa présence [du domaine] et permettra à vos utilisateurs ayant une adresse mail du type xxx@votredomaine.ext de s'authentifier directement sur votre serveur.

    Ça me pose deux questions. Déjà, ça veut dire que si on héberge un serveur, tous les possesseurs de l'application auront accès à son adresse ? Je n'ai pas forcément envie qu'on sache que maboite.fr ou test.org hébergent une instance où des notes de frais sont stockées. Avoir la possibilité de rentrer un domaine personnalisé dans l'application me semble mieux ?

    Deuxième souci, dans le cadre associatif par exemple, on ne fournit pas toujours du mail à nos membres, et ces derniers ne sont pas toujours motivés à multiplier les adresses mails. Je préfère, en tant qu'admin, dire "Machin de chez gmail.com a le droit de m'envoyer des notes de frais", plutôt que de forcer Machin à avoir un mail chez moi (et de devoir me farder la gestion d'une installation mail, accessoirement). Ceci dit, ça va être la même chose pour ton service, tes clients ont probablement déjà des adresses mails ailleurs ? Tu leur ouvre une boite à chaque fois ?

    • [^] # Re: Bonne idée

      Posté par  . Évalué à 4 (+3/-0). Dernière modification le 30/05/20 à 14:54.

      Hello,
      j'ai corrigé le lien, c'est le CMS qui tronque les uri?paramètres …

      Pour l'installation du serveur oui je m'appuie sur le test DNS pour que le end-user n'ai pas à choisir de serveur dans une liste où à faire une configuration compliquée … je ne sais pas si vous avez déjà vu un utilisateur face à l'appli jitsi par exemple, choisir un serveur c'est hors de portée de la majorité des gens.

      Il en va de même pour une autre appli que j'ai faite : clicpdf, lors du 1er lancement on demande sur quel serveur tu veux créer ton compte … et là c'est le drame, pour les tekkies comme nous pas de soucis mais pour les gens habitués à cliquer sans lire c'est la fin du monde.

      Pour de mauvaises raisons je suis tout à fait d'accord mais c'est ainsi, il faut donc trouver une solution absolument invisible ou transparente.

      Donc si ton adresse est toto@association.ext et que la résolution doliscan.association.ext marche alors l'application essaye de s'authentifier sur ton serveur doliscan.association.ext … oui ça demande à avoir une adresse pro mais c'est une appli pensée pour les pros.

      Et puis c'est pas si compliqué de dire à ton adhérent que son login sur ton application c'est adherent@association.ext … tout simplement. Et dans ton abonnement à ton nom de domaine tu gère des alias de mails …

      J'ai noté ta remarque sur le fait que ton serveur soit public, on ajoutera une clé dans la conf du serveur pour dire "serveur ouvert" ou "serveur fermé" pour qu'il accepte les créations de comptes et affiche un message spécial sur la page d'accueil.

      Et pour les captures d'écran il y a en a quelques unes sur https://doliscan.fr et beaucoup plus sur la doc https://doliscan.fr/docs/1.0/accueil mais oui je vais quand même en mettre sur le site communautaire.

      En fait je n'ai aucune idée de savoir si ça intéresse vraiment du monde et si ça peut donner lieu à une communauté et donc "investir du temps" dans la constitution du site et tout le bazaar ou pas du tout :-)

      eric.linuxfr@sud-ouest.org

      • [^] # Re: Bonne idée

        Posté par  (site Web personnel) . Évalué à 7 (+5/-0).

        Pour l'installation du serveur oui je m'appuie sur le test DNS pour que le end-user n'ai pas à choisir de serveur dans une liste où à faire une configuration compliquée … je ne sais pas si vous avez déjà vu un utilisateur face à l'appli jitsi par exemple, choisir un serveur c'est hors de portée de la majorité des gens.

        Je te rejoins sur le fait que les utilisateurs de base sont souvent paumés face à une option comme "entrez votre serveur". Mais justement, si ton logiciel a du succès et que pleins d'entreprises l'installent, comment ça se passe pour l'utilisateur ? Il a une longue liste de serveur qui s'affiche ? Ça ne sera pas forcément plus simple.

        Pour moi le comportement idéal serait : par défaut, c'est configuré avec ton propre serveur pro, avec une alerte lorsque tu veux envoyer ta première note qui dit : "ce service est paramétré pour un compte abonné chez doliscan.fr" et l'option "entrer un autre serveur". Et sinon, pouvoir paramétrer son serveur dans les options de l'appli.

        Ceci dit, cela me fait penser aussi à une autre limitation potentielle. Comment ça se passe si tu bosse pour plusieurs boites (vu qu'on peut cumuler des temps partiels ici et là) qui utilisent ce logiciel, chacune sur leur propre instance ? Ok, ce n'est peut-être pas le plus courant dans les métiers informatiques, mais ça peut valoir le coup de penser dès maintenant comment gérer ce genre de chose.

        Pour moi, ce que tu propose a vraiment un intérêt pour les associations, tu as probablement là un public, voir un marché. Et c'est le cas ou le multi-compte risque d'être intéressant… Peut-être avec des qrcode/liens raccourcis qui paramètrent un compte ?

        J'arrête les idées en l'air, ton logiciel répond déjà à un besoin de base, mais je ne résiste pas à essayer de voir plus loin quand un truc a un bon potentiel ;)

        En fait je n'ai aucune idée de savoir si ça intéresse vraiment du monde et si ça peut donner lieu à une communauté et donc "investir du temps" dans la constitution du site et tout le bazaar ou pas du tout :-)

        Ton site est déjà très bien, plus joli que la majorité de ceux des projets libres. C'est pour ça que les captures d'écran m'ont manqué, avant que je les vois sur les autres liens (j'ai posté un peu vite). Effectivement, n'y passe pas trop de temps pour le moment, ça s'améliorera peu à peu si besoin…

  • # Corrections

    Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

    J'ai corrigé deux petites fautes de frappe

    Un LUG en Lorraine : https://enunclic-cappel.fr

  • # rooté != non signé par google

    Posté par  . Évalué à 4 (+4/-0).

    https://doliscan.org/fr/client

    Les paquets sont proposés au téléchargemnt sur
    - Directement sur notre serveur si votre smartphone est rooté

    Il ne faut pas que le téléphone soit rooté pour installer des paquets non-signés. Android demandera explicitement la permission pour installer un tel paquet.

  • # le prix

    Posté par  . Évalué à 9 (+6/-0).

    il me semble correct. Mais les grosses boites n'aiment pas trop la gestion induite par la création/destruction de compte, c'est de l'administratif en plus.
    J'image qu'une version "entreprise" all you can eat devrait plaire (qq centaine d'euro ? Voir milliers pour te payer).

    "La première sécurité est la liberté"

    • [^] # Re: le prix

      Posté par  . Évalué à 2 (+1/-0).

      Oui je vois le principe, je vais faire une grille "corporate" … merci !

      eric.linuxfr@sud-ouest.org

  • # Contraintes légales

    Posté par  (site Web personnel) . Évalué à 6 (+5/-0).

    Hello,
    Je me suis intéressé à la question récemment pour mon entreprise.
    Déjà, la dématérialisation des justificatifs de notes de frais était interdite jusqu'à très récemment (moins de 3 ans !)
    Bon, maintenant, on peut, mais il y a plein de contraintes pour que l'URSSAF ne rejette pas tout en bloc en cas de contrôle. Une page qui m'a semblé bien complète : https://blog.mooncard.co/dematerialisation-justificatifs-notes-de-frais
    => est-ce que ton outil fait ça ?

    Concernant le prix, la boite qui s'occupe des feuilles de paye me propose ça pour 8€ mensuels par salarié (avec une app smartphone, tu photographies ton justificatif, tu remplis la catégorie (train, taxi, restau, hôtel,…) , et en fin de mois, tout est transmis direct au service paye, yapa plus trivial mon bon monsieur. Bon, c'est sur la plaquette commerciale, on n'a pas encore mis en place ;) )

    • [^] # Re: Contraintes légales

      Posté par  . Évalué à 4 (+3/-0).

      Hello Paul,
      concernant la démat' et la durée de conservation des tickets de notes de frais on est dans un domaine qui frise la connerie en barre d'après moi: Le délais de conservation d'environ 10 ans, je ne sais pas toi mais moi mes tickets d'autoroute et autres sandwich achetés chez le boulanger ne sont même plus lisible un an plus tard !!!

      C'est tellement vrai qu'un de mes experts comptables il y a 15 ans de ça m'avait conseillé de faire une photocopie des feuilles A4 sur lesquelles on colle les tickets car "l'encre des photocopies reste là où celle des imprimantes thermiques disparait"

      Ensuite il faut distinguer l'acquisition du document, son horodatage et sa signature électronique initiale de la partie stockage.

      L'horodatage et la signature sont la 1ere étape et sont conforme à la norme eIDAS quand à l'archivage c'est une autre histoire et comme conseillé dans l'article du blog je conseille aussi de conserver les "originaux" papier en tout cas pour l'instant.

      À terme la solution d'archivage permettra de ne plus conserver les documents papiers mais pour obtenir la certification de prestataire d'archivage il faut payer une boite qui viens faire la certification sur les 6 derniers mois de pratique … on se mords la queue donc on démarre comme ça et d'ici quelques mois on demandera la certification (qui coûte 2 reins) :)

      Pour en revenir à DoliSCAN, l'appli est telle que tu la décris: choix d'une rubrique de dépense, photo, renseignement de quelques infos (prix ttc, moyen de paiement, invités si c'est du resto) et zouu c'est sauvegardé.

      eric.linuxfr@sud-ouest.org

  • # Paquet sur f-droid

    Posté par  . Évalué à 2 (+1/-0).

    Le merge request est fait, https://gitlab.com/fdroid/fdroiddata/-/merge_requests/6907 si vous connaissez une personne qui a les droits en écriture sur le dépôt principal n'hésitez surtout pas à lui faire suivre l'info :)

    eric.linuxfr@sud-ouest.org

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.