Deux produits Dropbox, deux connexions séparées
Dropbox Sign porte le nom de Dropbox et se branche pourtant autrement. Ce sont deux connecteurs distincts, avec deux clés distinctes, qui parlent à deux interfaces distinctes. Celle de Dropbox Sign répond d’ailleurs encore sous le nom de HelloSign, dont le produit est issu, et c’est la seule adresse à laquelle ce connecteur parle.
La différence qui compte porte sur la façon dont se décide la lecture. Un fichier stocké dans Dropbox tient son public des membres du dossier partagé qui le contient, et ce signal existe. Une demande de signature n’a rien d’équivalent, puisqu’elle ne vit dans aucun dossier, que l’interface n’expose aucun droit de lecture par demande, et que l’équipe désignée par la clé reste la seule frontière disponible.
Le connecteur en tire la conséquence prudente. Puisque l’interface ne lui offre aucun signal d’audience, il ne range rien avant qu’un administrateur ait nommé le service autorisé à lire les contrats. Aucun réglage ne rend une demande lisible par l’entreprise entière, et ce verrou tient dans le connecteur lui-même plutôt que dans un fichier de configuration.
Ce que vos signataires ont tapé ne remonte pas
Une demande de signature n’est pas seulement un fichier à parapher. Vos documents contiennent des champs que les personnes remplissent, un numéro de compte, une adresse personnelle, un montant, une case cochée qui vaut engagement. Dropbox Sign renvoie ces réponses avec la demande, et aucune ne franchit la porte. Les champs préremplis par l’expéditeur restent dehors eux aussi, tout comme l’objet et le message envoyés aux signataires, dont le texte libre porte souvent le contexte de la négociation.
Il ne lit ni ne résout non plus aucune des adresses que Dropbox Sign attache à une demande, celle qui mène au fichier signé, celle du parcours de signature et celle de la fiche. Une adresse qui suffit à obtenir un document n’a rien à faire dans un contenu qu’une IA relira ensuite, donc elle n’est écrite nulle part.
Il écrit en revanche le titre de la demande, le fait qu’elle soit achevée, refusée ou en erreur, le fait qu’elle ait été envoyée en mode d’essai, le nombre de signataires, puis l’état de chacun avec sa date de signature. Une IA branchée sait donc quelles demandes traînent et lesquelles sont bouclées, sans savoir ce que contient le document ni qui l’a signé nominativement.
Le suivi d’une signature, sans le document signé
Le connecteur nomme ces champs un par un, et il n’en lit aucun autre.
Si les réponses aux champs restent dehors, c’est parce qu’on y lit ce qu’une personne a écrit d’elle-même, et parce que c’est la partie d’une demande qui échappe le plus à celui qui l’a envoyée. Savoir qu’un engagement existe et où il en est ne demande pas de savoir ce qui a été tapé dedans.
Les quatre décisions qui ouvrent la lecture
Aucune n’est prise par le connecteur, et aucune n’est prise à votre place. Elles se prennent dans cet ordre.
Fournir une clé de lecture
Le connecteur demande une clé de lecture, propre à une équipe Dropbox Sign. Il vérifie qu’elle authentifie réellement avant de la conserver, et une clé qui échoue à cette vérification n’est pas rangée du tout. Une entreprise qui tient plusieurs équipes branche autant de connexions, et une clé ne franchit jamais la frontière de son équipe.
Choisir entre le compte et l’équipe
Par défaut, la liste ne rend que les demandes du compte qui porte la clé. Voir celles de toute l’équipe est un geste explicite, et il demande une clé dotée d’un rôle d’administration. Ce choix reste ouvert parce qu’une énumération d’équipe est une lecture plus large, et qu’une lecture plus large se décide plutôt que de s’appliquer par défaut.
Désigner le service qui aura le droit de lire
Un administrateur nomme le service auquel les demandes seront rattachées. Ce nom doit passer pour un identifiant valide, et le service doit figurer pour de vrai dans votre organisation. S’il manque, s’il est inventé, ou si votre gouvernance ne peut pas être lue, les demandes attendent, et aucune IA branchée ne les atteint.
Déclarer, ou non, que l’inventaire est complet
Le rapprochement des suppressions ne tourne que si un administrateur déclare que l’énumération capture bien toutes les demandes. Tant qu’il ne l’a pas fait, une demande absente de la liste n’est pas traitée comme supprimée, parce qu’un inventaire incomplet ferait passer pour retirées des demandes toujours en cours.
Une demande refusée reste, une demande retirée aussi
Une signature obtenue et un refus sont deux changements d’état, et le connecteur réécrit la fiche dans les deux cas. Une demande refusée garde donc sa place dans votre Kastel, avec l’état qui dit qu’elle a été refusée. Chaque passage relit toutes les demandes, faute d’un filtre de dernière modification sur la liste de Dropbox Sign, et une fiche inchangée n’est pas réécrite pour autant.
L’annulation, elle, ne laisse aucune trace côté Dropbox Sign, puisqu’une demande retirée sort simplement de la liste sans état qui l’indique. Ce qui est relevé, alors, c’est l’absence elle-même, une fois l’inventaire déclaré complet, et elle est notée à côté de la fiche plutôt que de faire disparaître la fiche. Les précautions que nous plaçons autour de ces lectures valent ici comme sur la page du connecteur PandaDoc, qui applique la même règle avec ses propres frontières.
Une précaution de la même famille mérite d’être nommée. Une pagination qui tourne en rond, ou qui rend un numéro de page inexploitable, fait échouer le passage, et un compte qu’on n’arrive plus à énumérer est mis de côté au lieu d’être comparé. Sans cette règle, une lecture tronquée passerait pour un inventaire complet et ferait conclure à tort que les demandes non lues ont été retirées.
Ce que ce connecteur ne fait pas
Il ne déclenche aucune signature. Aucun de ses appels n’écrit dans Dropbox Sign, la clé qu’il demande ne sert qu’à lire, et relancer un signataire ou récupérer un fichier ne fait pas partie de ce qu’il sait faire.
Le titre d’une demande entre, et c’est le champ qui identifie le contrat. Une entreprise qui intitule ses demandes « Rupture conventionnelle Dupont » met cette information dans votre Kastel en même temps que la demande. Nous le disons plutôt que de le laisser découvrir, et c’est la raison pour laquelle une fiche reste hors de portée jusqu’à la désignation d’un service.
Par défaut, il ne voit que les demandes du compte dont il porte la clé. Une équipe dont les signatures partent de plusieurs comptes n’aura donc qu’une partie de ses demandes tant que le périmètre d’équipe n’a pas été activé, et cette activation demande une clé d’un rôle plus élevé. Une équipe qui s’étonne de ne pas retrouver une demande dans son Kastel commence par vérifier ce réglage.
Une demande retirée de Dropbox Sign ne quitte pas votre Kastel. Sa fiche y reste, avec le même public qu’avant, et seul un administrateur peut l’effacer. Ce rapprochement ne tourne d’ailleurs pas avant qu’un administrateur ait déclaré l’inventaire complet, donc par défaut la disparition n’est même pas constatée. Débrancher la clé interrompt la lecture, sans faire sortir une seule fiche déjà écrite.
Vos demandes de signature méritent une conversation.
Sur une source qui porte des engagements et des données saisies par des personnes, une page web ne remplace pas un échange. Dites-nous depuis quels comptes vos signatures partent et qui doit pouvoir les consulter, et nous vous dirons précisément où s’arrête la lecture de ce connecteur.
Nous écrire
