SignIt ​

Présentation ​

Contexte : Le client doit faire signer et conserver un grand nombre de documents (fiche de présence, consentement, feuille de sécurité, contrat de prestation, etc.), qui peuvent être des documents contenants des données de santé, et cela, sur de très longues périodes de temps (jusqu’à plus de 10 ans).

Pour l’instant, en fonction des documents concernés, ils sont signés sur papier, puis parfois numériser pour stockage dans plusieurs silos, sans interconnexions, difficilement accessible par les personnes concernées.

Le projet, « Sign It », prendra la forme d’une web-app en 2 parties :

• Partie « Utilisateur / Signataire » : Après réception d’un lien unique (rattaché à un document vierge / en attente de signature), l’utilisateur pourra consulter le document, et amorcer le processus de signature (définis dans les fonctionnalités).

• Partie « Administrateur / Créateur de document » : Cette partie de l’application permettra de consulter les documents déjà existants, d’effectuer des recherches simples (signé par X, crée le Y, …), et de générer un nouveau document à signer.

L'application utilise Laravel, ainsi que Vue.js. D'autres modules sont aussi utilisés tel que :

• Inertia pour faire le lien facilement entre php et javaScript

• SweetAlert afin de créer des alertes modulable et réactive

• Tailwinds pour le CSS

  
  

  Apercu de l'application

  

Ma contribution ​

Fonctionnalités ​

Enregistrement & Authentification à 2 facteurs ​

Afin de garantir que la personne signant le document soit bien la personne qu’elle prétend être, il lui sera demandé d’avoir un compte préalablement crée, sous forme classique (nom, prénom, adresse e-mail valide et validée, mot de passe et, optionnellement, un numéro de téléphone acceptant les SMS).

Lors de la signature du document, l’utilisateur doit être identifié et doit recevoir l’une des notifications suivantes : -      Soit un code SMS à retranscrire lors de la signature, le SMS comprendra au moins le nom du document que l’utilisateur s’apprête à signer. -      Soit, en l’absence de numéro de téléphone compatible SMS, un e-mail contenant la même notification.

Génération de document ​

Pour la Phase 1, il faut structurer les Models afin de déjà avoir un type (presence, contract, … une simple chaîne alpha-numérique), mais lors de cette phase, il n’y aura que les fiches de présence.

Un document dispose aussi d’un statut :

• Created : Vient d’être crée
• Pending : En attente d’une signature par une ou plusieurs personnes
• Closed : Fermé pour signature
• Done : Terminé et validé, en attente de scellement
• Sealed : Sceau émis et enregistré dans la base (hash du PDF final)

Basé sur un modèle Word, la génération de document demande un nom pour le fichier, ainsi que 2 datetimes (null par défaut) définissants :

• Une date à laquelle les documents peuvent être signer (ouverture des signatures)
• Une date à laquelle les documents ne peuvent plus être signer (clôture des signatures)

Les personnes signants le document seront ajouter à la liste des personnes participantes, on affichera donc leur nom, prénom, une « semi-signature » (dans une police d’écriture cursive), ainsi qu’un hash correspond à la concaténation de l’user_id, du document_id et de la date de signature.

Scellé des documents ​

Lorsqu’un fichier est cloturé (closed) à la fin de la date de récolte des signatures, ou lorsqu’il est manuellement terminé (done), un scellé doit être appliqué sur le document (génération du PDF, ajout d’une marque à la fin du document servant de « signature numérique » (un hash aléatoire, qui sera ensuite enregistré en même temps que le sha1/sha256 du fichier), et calcul du sha1/sha256).

Les informations concernant le scellé seront stockées dans une table, avec une liaison vers le document.