Mardi 27 août 2024 à 15:02

Au cours des 12 derniers mois, j'ai été confronté à la nécessité de compléter de nombreux dossiers administratifs complexes, chacun comprenant un grand nombre de documents. Voici quelques exemples concrets :

J'ai dû rassembler et transmettre à mon courtier immobilier un dossier complet de 70 fichiers pour l'achat de mon logement, une opération impliquant quatre acteurs : le courtier, la banque, ma compagne et moi-même.
J'ai constitué et envoyé un dossier à un diagnosticien pour obtenir un certificat de Diagnostic de performance énergétique
J'ai préparé et soumis un dossier pour une assurance de prêt immobilier.
Dans le cadre de mes fonctions de président d'association :
- J'ai demandé à des futurs employés de compléter un dossier d'embauche.
- J'ai rédigé trois dossiers distincts pour effectuer trois demandes de subventions différentes.
- J'ai constitué et transmis un dossier destiné au Commissaire aux comptes.
Demande de dossier pour l'entrée d'un locataire de logement.

Méthodes utilisées pour constituer et transmettre ces dossiers :

Partage via Google Drive ;
Envoi par email ;
Utilisation de plateformes en ligne proposées par certaines structures, comme la mairie ou le conseil départemental, pour l'upload des documents.

Difficultés rencontrées :

Identifier précisément les documents à fournir, avec un manque d'exemples ou de spécimens pour référence.
Gestion du workflow de validation des pièces.
Difficultés de nommage et d'identification des documents.
Problèmes de versionning des documents.
Difficile d'avoir une vue d'ensemble des documents manquants.
Suivi de la progression difficile.
Pas de statut clair si un document est validé ou non.
Méthode de notification de mise à jour de document imprécis.
Complexité accrue lorsque plusieurs personnes participent à la constitution d'un dossier.
Limites de taille pour certains documents.
Choix de la plateforme d'échange : certaines personnes refusent d'utiliser certains outils.
Conformité avec le RGPD.
…

Fort de cette expérience et des difficultés rencontrées, je m'interroge sur la possibilité de créer une application web capable de simplifier la constitution de dossiers.

Voici l'idée que j'envisage.

Souvent, un email ou un fichier PDF détaille les pièces nécessaires à la constitution d'un dossier.

Je propose de remplacer ou de compléter ces documents par une page web interactive. Cette page web intégrerait la documentation nécessaire ainsi que les emplacements pour uploader les documents requis.

L'objectif pour l'utilisateur chargé de rassembler les documents est de combler les "trous" : si un trou est visible, cela signifie qu'un document est manquant.

Les PDF seraient transformés en images miniatures, cliquables pour un aperçu en zoom, ce qui est bien plus pratique que d'ouvrir un PDF entier pour le consulter.

Dans ce croquis, j'ai tenté de représenter en bas à droite un composant d'interface permettant de savoir si une pièce est validée ou refusée (ce n'est qu'une première ébauche de cette fonctionnalité).

J'imagine également un espace dédié à la consultation des dernières activités effectuées sur le dossier.

L'interface utilisateur varierait légèrement en fonction du type d'utilisateur et de son rôle dans le processus. Par exemple, un courtier pourrait rapidement voir les pièces qu'il doit valider.

Je prévois aussi la possibilité de visualiser un spécimen du document, ainsi qu'un système de commentaires attachés à un document ou à un groupe de documents, permettant de comprendre facilement à quel document une remarque fait référence.

Je pense que tant la personne qui constitue le dossier que celle qui en demande la complétion pourraient devenir prescripteurs du service. Idéalement, c'est le demandeur des documents qui devrait être le prescripteur, car cela lui permettrait de configurer et documenter en amont un template de dossier. Ce template pourrait ensuite être réutilisé à volonté.

J'imagine également que le service pourrait envoyer un SMS contenant un message tel que « John Doe vous demande les documents suivants …url… » ou « Alice vous a envoyé les documents suivants …url… ».

Cela pourrait remplacer des solutions comme WeTransfer, Dropbox ou Google Drive.

Cette grande page web permettrait d'organiser et d'identifier clairement tous les documents, évitant ainsi de devoir gérer un amas de fichiers aux noms pas toujours explicites.

Si un utilisateur a un compte sur la plateforme, il pourrait très bien garder de coté des pièces très souvent demandé, comme sa carte d'identité par exemple.

Il serait également possible d'intégrer une fonctionnalité de chiffrement symétrique côté browser, pour assurer la confidentialité des documents (voir [référence 2024-08-27_1406]).

Une autre idée serait de proposer des templates préconfigurés :

Template standard pour une demande de location ;
Template standard pour une demande de prêt ;
Template standard pour un Diagnostic de Performance Énergétique (DPE).

De plus, si un utilisateur dispose d'un compte sur la plateforme, il pourrait conserver des documents fréquemment demandés, comme sa carte d'identité, pour les réutiliser facilement.

Idéalement, ce service serait distribué sous une licence de type fair source.

Pour l’implémentation, la première étape consisterait à configurer un template initial codé en dur, par exemple, un dossier de demande de location.

Ensuite, implémenter le système de gestion des documents manquants ("trous") avec un rendu des PDF sous forme d’images.

Ah… j'ai oublié quelque chose d'important ! #JeMeDemande si ce type de produit existe déjà !

Deux options s'offrent à moi : soit je me lance pour le plaisir et développe une première version de cette application, soit je prends les choses plus au sérieux et réalise une étude de marché 🤔.

Mon premier beta testeur pourrait être mon ami courtier en prêt immobilier.

Journaux liées à cette note :

En mars 2024, je me suis demandé comment utiliser correctement les termes Epic, Issue, User Story, Goal, Job Story, Vision, Pitch, Feature, Task, Bug, Spike, Dette technique, Theme.

Voici quelques réflexions à ce propos.

Tout d'abord, tous les artefacts suivants sont des Issues : Epic, User Story, Job Story, Vision, Pitch, Feature, Bug, Spike, Task.

Ensuite, Feature, Bug, Spike et Dette technique indiquent la finalité de l'issue, définissant la nature du travail à réaliser.

User Story et Job Story sont des méthodes de formulation d'issues.

J'ai mis beaucoup de temps à réaliser que les termes Epic, Vision, Theme, Pitch, Goal et Task permettent d'indiquer le niveau d'imprécision d'un objectif.

Exemple allant du flou très prononcé à une version faiblement floue :

Vision – Le niveau le plus large et abstrait, décrivant une aspiration à long terme.
Theme – Une direction stratégique regroupant plusieurs objectifs ou Epics.
Pitch – Une proposition d'idée ou une justification d'un projet, pouvant inclure des objectifs mais restant plus conceptuel.
Goal – Un objectif spécifique à atteindre, souvent mesurable.
Epic – Une grande fonctionnalité ou un ensemble de tâches qui contribuent à un objectif plus large.
Task – Niveau le plus précis, une tâche est une unité de travail concrète et actionnable.

Une ou plusieurs Merge Requests constituent une réponse formelle, exprimée en code, parmi toutes les réponses possibles à une demande formulée dans une issue.
Seule cette réponse formelle, exprimée en code, est véritablement précise. Même l'issue, aussi détaillée soit-elle, conserve toujours une part de flou.

Attention tout de même : quand je dis qu'une issue de type Vision est floue, cela ne veut pas dire que son auteur peut bâcler sa rédaction.
Si, par exemple, la description est limitée à 500 mots, l'auteur doit exploiter au mieux cette limite pour présenter sa vision avec précision. L'objectif n'est pas de créer du flou volontairement, mais plutôt d'exprimer clairement un concept qui, par nature, comporte encore des zones d'incertitude à explorer.

Voici quelques exemples d'issue floue publiés ici :

Une issue, en tant que texte écrit, comporte une part inévitable d'ambiguïté et nécessite donc son auteur pour être défendue :

C’est que l’écriture, Phèdre, a, tout comme la peinture, un grave inconvénient. Les œuvres picturales paraissent comme vivantes ; mais, si tu les interroges, elles gardent un vénérable silence. Il en est de même des discours écrits. Tu croirais certes qu’ils parlent comme des personnes sensées ; mais, si tu veux leur demander de t’expliquer ce qu’ils disent, ils te répondent toujours la même chose. Une fois écrit, tout discours roule de tous côtés ; il tombe aussi bien chez ceux qui le comprennent que chez ceux pour lesquels il est sans intérêt ; il ne sait point à qui il faut parler, ni avec qui il est bon de se taire. S’il se voit méprisé ou injustement injurié, il a toujours besoin du secours de son père, car il n’est pas par lui-même capable de se défendre ni de se secourir.

Phèdre - Dialogue de Platon

Conséquence pratique de tout cela :

L'auteur d'une issue doit être disponible et accorder du temps à la personne qui va implémenter son issue.
La personne qui implémente cette issue doit accepter l'imprécision de cette issue. En posant des questions, le développeur doit aider l'auteur à rendre cette issue plus précise.
L'auteur de l'issue doit accepter de recevoir une implémentation qui ne correspond pas exactement à sa vision… et dans ce cas, il doit soit l'accepter ou accorder plus de temps à cette issue afin d'effectuer plusieurs itérations de correction de l'implémentation.

Ces règles pratiques sont aussi valables lorsqu'une issue est déclinée dans des issues avec un niveau de précision supérieur. Par exemple, lors de la rédaction d'issues de type Epic à partir d'une issue de type Vision.

« Permettre à l'auteur de défendre son texte » ne signifie pas exclusivement un dialogue oral. Ce dialogue peut s'effectuer :

Par chat synchrone ;
Par commentaire d'issue asynchrone ;
Par visioconférence ;
etc

Je pense que le niveau de précision d'une issue détermine le mode de communication à privilégier. Pour les issues de haut niveau d'abstraction — très floues (Vision, Theme, Pitch), la communication orale se révèle généralement plus efficace, car elle permet des échanges dynamiques et immédiats sur des concepts abstraits.

En revanche, pour les issues plus précises (Tasks, certaines Features), je privilégie une approche asynchrone avec des questions écrites détaillées. Cette méthode offre à l'auteur le temps nécessaire pour réfléchir et affiner sa rédaction. Je ne recours à la communication orale que lorsque des problèmes de compréhension persistent malgré les échanges écrits, afin de débloquer rapidement la situation.

Je cherche des solutions pour bien indiquer le niveau de précision des issues que j'écris.

Voici quelques exemples d'introductions d'issues :

Cette issue est de type "vision", c'est donc normal qu'elle soit imprécise. Les zones d'ombre seront affinées progressivement dans des sous-issues spécifiques. Pour clarifier certains aspects, des échanges oraux pourront être organisés afin de répondre à vos questions et d'enrichir cette vision.

Autre exemple :

Cette issue a été rédigée avec un souci particulier de précision. Si vous identifiez des erreurs, des incohérences ou si certains points nécessitent des éclaircissements, n'hésitez pas à les signaler dans les commentaires. Pour toute difficulté de compréhension ou doute persistant, je reste disponible pour organiser une session en visioconférence afin de faciliter nos échanges.

La version 5 de Svelte vient de sortir : 5.0.0.

Il y a un an, j'avais lu le billet Introducing runes. Depuis, j'ai suivi ce sujet de loin.

J'aimerais tester et apprendre à utiliser la fonctionnalité rune.
#JeMeDemande dans quel projet 🤔. Est-ce que je préfère refactorer vers rune le projet sklein-pkm-engine ou gibbon-replay 🤔. Je pense que ces deux projets utilisent trop peu de "reactive state".
Je souhaite prochainement débuter le projet que j'ai présenté dans 2023-10-28_2008. Je pense que ça serait une bonne occasion pour créer mon premier projet 100% TypeScript avec Svelte 5 avec Rune.