Workflow de validation : rôles, circuit de validation et signature d'un contrat dans Chaindoc

Un workflow de validation, au sens métier du terme et non celui d'un flux technique qu'on teste, c'est le chemin qu'un contrat suit du brouillon à la signature : qui peut l'ouvrir, qui doit le valider, dans quel ordre, et quelle trace reste. Le principe des quatre yeux en est la règle de base. Dans Chaindoc, il repose sur deux réglages. Les rôles décident qui voit et modifie un document ; avec l'offre Business, un circuit de validation fixe l'ordre des validations et des signatures. Tout le reste en découle. Ce guide montre comment les régler avec la gestion d'équipe Chaindoc, ce que chaque offre inclut et où SharePoint et consorts vont plus loin.

La plupart des problèmes d'un workflow de validation naissent avant la validation. Un brouillon atterrit sur le lecteur partagé, le lien circule, et le temps que le juridique l'ouvre, cinq personnes l'ont lu et deux l'ont modifié.

C'est le réglage par défaut de bien des outils. Dans Google Drive, toute personne que vous passez en éditeur peut partager le fichier et modifier ses autorisations, tant que le propriétaire ne l'interdit pas, et l'accès donné sur un dossier s'applique à tous les fichiers qu'il contient (Aide Google Drive). Pratique pour une présentation. Moins pour un contrat fournisseur où figurent vos marges.

Dans Chaindoc, l'accès aux documents joue sur deux niveaux, plus un troisième pour les développeurs :

• Espace de travail. Chaque utilisateur a un espace personnel, et les offres d'équipe en ajoutent un partagé. Les deux ne se recoupent pas : un brouillon gardé dans votre espace personnel reste invisible pour l'équipe, et les contrats de l'équipe vont dans l'espace partagé.
• Rôle. Dans l'espace partagé, ce qu'une personne peut faire d'un document (le consulter, le modifier, le valider, le signer) découle de son rôle, pas d'un lien que quelqu'un a transféré.
• Via l'API Chaindoc, qui exige l'offre Business, chaque document porte un type d'accès : privé (private), public ou restreint (restricted). Un document restreint liste par e-mail les personnes autorisées à l'ouvrir, avec un niveau comme read.

Notre règle empirique : donnez le brouillon à ceux qui doivent le lire avant la validation, pas à tous ceux que ça intéresserait. Vous pourrez élargir l'accès après la signature. Le reprendre une fois le fichier téléchargé, c'est une autre histoire. Avec des données personnelles dans le contrat, ce n'est pas qu'une question de prudence : voir plus bas les articles 25 et 32 du RGPD.

Une limite, sans détour : les fichiers circulent en TLS, mais il n'y a pas de chiffrement de bout en bout, donc les serveurs de Chaindoc peuvent lire ce qu'ils traitent. À l'intérieur de votre entreprise, ce sont les rôles qui gardent un contrat sous les bons yeux.

Le contrôle d'accès basé sur les rôles (RBAC) rattache des permissions à un rôle, puis donne le rôle aux personnes. Le glossaire du NIST le décrit comme un contrôle d'accès fondé sur les rôles des utilisateurs, un rôle étant un ensemble d'autorisations d'accès. Au quotidien, c'est la gestion des droits d'accès aux documents : qui a le droit de faire quoi, sur quoi. La CNIL parle de gestion des habilitations. Quand quelqu'un change de poste, vous modifiez un rôle et son accès suit.

La gestion d'équipe Chaindoc propose quatre rôles intégrés, la moitié « accès » de tout workflow de validation :

• Owner : tous les droits sur les documents, plus les commandes d'administration de l'équipe. En général la fondatrice ou celui qui tient le budget.
• Admin : gère les utilisateurs et garde un œil sur les workflows. Typiquement un responsable des opérations ou de l'administration.
• Member : lit et modifie dans la limite des droits du rôle. C'est là que se range l'essentiel de l'équipe.
• Accounter : voit le versant financier et analytique des documents. Pensez au comptable ou à l'expert-comptable externe.

Chaque rôle intégré peut être ajusté, et vous créez autant de rôles sur mesure que nécessaire, avec n'importe quelle combinaison de permissions. Deux reviennent souvent : un rôle de relecture juridique, qui consulte et valide les contrats sans les envoyer, et un rôle commercial, qui rédige et envoie mais ne valide jamais. Les changements faits dans l'onglet Rôles s'appliquent aussitôt à tous les workflows actifs.

Quatre rôles, est-ce assez ? Pour une équipe de cinq à cinquante personnes, le plus souvent oui. Les suites d'entreprise proposent des menus plus longs, mais d'après notre expérience les petites équipes en ont rarement besoin, et chaque rôle de plus est un rôle que quelqu'un devra revoir chaque trimestre.

Le principe des quatre yeux (on écrit aussi principe des 4 yeux) veut que deux personnes interviennent avant qu'un acte important compte : un paiement, la modification d'un enregistrement, un contrat. Les auditeurs parlent plus largement de séparation des fonctions (separation of duties en anglais). La définition du NIST est sans détour : aucun utilisateur ne devrait recevoir assez de droits pour détourner le système à lui seul (glossaire du NIST). La même entrée distingue deux cas. La séparation statique interdit de confier des rôles incompatibles à une seule personne. La séparation dynamique joue au moment de l'action, la règle des deux personnes en étant l'exemple classique.

En France, l'idée vit dans le vocabulaire du contrôle interne. Le cadre de référence de l'AMF, écrit pour les sociétés soumises à la loi de sécurité financière, demande une séparation des fonctions conçue pour permettre un contrôle indépendant (AMF). Une PME n'y est pas tenue, mais la logique se transpose. Dans une SAS, le président signe pour la société et peut déléguer sa signature au DAF, par écrit, avec les actes visés et un plafond de montant, selon ce que prévoient les statuts. Un workflow de validation range ce partage dans le document plutôt que dans la tête du dirigeant.

Pour une équipe qui traite des contrats, cela donne trois habitudes :

1. 1.
   Celui qui rédige un contrat n'est pas celui qui le valide.
2. 2.
   Les gros contrats portent plus d'un nom entre le brouillon et la signature.
3. 3.
   La finance voit ce que vaut un contrat sans pouvoir le réécrire.

Pas besoin d'un logiciel spécial pour cela. Il faut quelqu'un qui décide, et un outil qui se souvient de la décision.

Moindre privilège, en clair

Le NIST (SP 800-12) définit le moindre privilège ainsi : chaque utilisateur n'a que l'accès minimal nécessaire à ses tâches. Dans Chaindoc, Member est le réglage par défaut, Admin l'exception, Owner réservé à une ou deux personnes. Honnêtement, la plupart des petites équipes font l'inverse : les cinq premières personnes deviennent Admin parce que c'était plus rapide, et plus personne n'y revient.

Où se place le circuit de validation dans un workflow de validation

Les rôles couvrent la moitié statique, le circuit la moitié dynamique. Une demande de signature ordinaire dans Chaindoc invite tous les destinataires en même temps, et le premier qui l'ouvre signe le premier. Avec l'offre Business, un circuit de validation fixe l'ordre à la place : la personne suivante ne reçoit le document qu'une fois la précédente passée à l'acte. D'abord le juridique, puis la direction financière, puis la direction générale. Si votre politique veut que les contrats au-delà d'un certain montant passent par le DAF, écrivez la règle et laissez la personne qui envoie choisir le circuit qui convient. Un circuit fixe l'ordre, pas des seuils de montant.

Les rôles et l'espace partagé, le côté accès d'un workflow de validation, commencent avec l'offre Team. L'ordre fixe demande Business, tout comme l'accès à l'API. Les chiffres ci-dessous viennent des offres Chaindoc telles qu'elles étaient publiées le 20 septembre 2026 ; la page des tarifs donne les chiffres à jour. Si vous comparez un logiciel de workflow de validation sur le prix, comptez aussi les places : chaque membre supplémentaire coûte 19 € par mois en option sur les deux offres d'équipe.

Un chiffre manque exprès. Le nombre de signatures mensuelles de l'offre Team affiche une valeur sur la fiche de l'offre et une autre dans sa configuration. Nous le laissons donc à la page des tarifs plutôt que d'imprimer le mauvais.

Un workflow de validation ne sert que si l'on peut montrer plus tard qui a validé quoi. Chaindoc garde la preuve à deux endroits, qui ne font pas le même travail.

Le journal d'audit est le journal d'événements propre à l'application pour le document. Ses entrées sont chaînées par des empreintes (hash), si bien qu'une entrée manquante ou modifiée casse la chaîne. Vous pouvez l'exporter en PDF, et il existe un rapport de vérification en PDF distinct pour le fichier signé. Si vous avez utilisé une vérification d'identité, son résultat figure aussi dans le journal.

La blockchain enregistre deux moments : l'empreinte de la version à la publication, et la preuve de chaque signataire quand la signature se termine. C'est contre cette empreinte qu'une vérification ultérieure contrôle le fichier.

En pratique, la plupart des désaccords n'arrivent jamais jusqu'à la chaîne. Ils se règlent avec un relevé lisible de qui a fait quoi, et c'est pourquoi l'export PDF compte davantage au quotidien. Ce qu'un contrôleur ou un juge demande en général, voyez comment la trace d'une signature électronique tient face à un audit.

Avant d'acheter un logiciel de validation de documents, regardez ce que vous avez déjà. Beaucoup d'équipes font tourner un workflow de validation dans un outil qu'elles possèdent, ou croient le faire. Voici ce que couvrent les trois plus courants.

SharePoint et Power Automate

Un workflow de validation SharePoint est le plus souvent un flux Power Automate. Le tutoriel de Microsoft le construit autour de l'action « Approbations - Démarrer et attendre une approbation », et les approbateurs répondent depuis leur boîte de réception, le centre d'approbation ou l'application mobile (Microsoft Learn). Les approbations séquentielles et parallèles ont chacune leur guide, et des invités extérieurs à l'entreprise peuvent approuver via Microsoft Entra. Le revers : vous construisez et entretenez le flux vous-même, et le tutoriel précise que la sécurité sort de son cadre.

DocuSign

Qui cherche les rôles et permissions de DocuSign tombe en général sur ses trois profils de permissions par défaut : DS Admin, DS Sender et DS Viewer. DocuSign décrit aussi dans son centre d'assistance un circuit de validation interne pour la relecture de documents. Un workflow de validation DocuSign est donc un travail de configuration dans un compte que vous payez peut-être déjà.

Google Drive

Les droits de partage de Google Drive tiennent en trois rôles : lecteur, commentateur et éditeur. Ils décident de qui peut ouvrir, commenter et modifier un fichier. Qui l'approuve et qui le signe, c'est une autre question, à régler ailleurs.

Là où ils ont de l'avance : Power Automate peut conditionner une validation à presque n'importe quelle condition et la faire tourner entre SharePoint, Dynamics 365 ou Salesforce, et les approbateurs Microsoft 365 utilisent les comptes d'entreprise avec lesquels ils se connectent déjà. Chaindoc n'a ni authentification unique ni provisionnement SCIM. On se connecte avec un mot de passe ou un compte Google, GitHub ou Apple, et vous retirez les départs à la main. Ce que Chaindoc réunit au même endroit, ce sont l'accès, l'ordre, la signature et la trace pour un même contrat.

Non. L'article 25, paragraphe 1, du règlement eIDAS interdit de refuser à une signature électronique ses effets juridiques et sa recevabilité comme preuve en justice au seul motif qu'elle est électronique. En droit français, l'écrit électronique vaut l'écrit papier si son auteur est dûment identifié et si l'écrit est établi et conservé dans des conditions qui en garantissent l'intégrité (art. 1366 du Code civil), et la signature électronique repose sur un procédé fiable d'identification (art. 1367, avec une présomption de fiabilité fixée par le décret n° 2017-1416). Votre workflow de validation relève de la gouvernance, pas de la formation du contrat. Ce qu'il change, c'est votre position si quelqu'un prétend plus tard que le contrat a été signé sans pouvoir.

L'accès joue pourtant dans les deux sens : tenez à l'écart ceux qui ne doivent pas voir un contrat, sans exclure ceux qui doivent pouvoir le retrouver. Pour les délais, voyez combien de temps conserver les contrats signés.

Si vos contrats contiennent des données personnelles, l'article 25, paragraphe 2, du RGPD demande que, par défaut, elles ne soient pas rendues accessibles à un nombre indéterminé de personnes, et l'article 32, paragraphe 4, que toute personne ayant accès n'agisse que sur instruction du responsable du traitement. Un lien que tout le monde peut ouvrir s'accorde mal avec l'un comme avec l'autre. Ceci est une information générale, pas un conseil juridique pour votre entreprise.

Les mêmes cinq défaillances reviennent sans cesse :

• Tout le monde est Admin. C'est arrivé à la mise en place et ça n'a pas bougé. Ramenez-les à une ou deux personnes.
• Le workflow de validation des contrats vit dans la tête de quelqu'un. Quand cette personne est absente, les contrats restent en plan ou partent sans validation. Écrivez les circuits et nommez-les d'après les types de contrat.
• Les validations se font par e-mail. Un « ça me va » dans un fil n'est pas dans le journal d'audit, et six mois plus tard personne ne le retrouve.
• Les partants gardent leur accès. Sans provisionnement automatique, le départ d'un collaborateur demande une ligne dans la checklist : le retirer de Chaindoc.
• La version validée n'est pas la version signée. Modifier après validation impose une nouvelle version publiée et un nouveau passage dans le circuit. L'empreinte de l'ancienne version est déjà sur la blockchain, ce qui est exactement ce que vous voulez quand on demande ce qui a changé.

Réglez ces cinq points et un workflow de validation dans Chaindoc se gère presque tout seul. Les rôles gardent les brouillons privés, le circuit garde l'ordre, et la trace répond aux questions plus tard.