AI Tools10 min de lecture

Une phrase suffit-elle pour créer un circuit d’approbation de contrat dans Box ?

Box Architect part d’un résultat métier. Un exemple de réception de contrat montre ce que l’outil peut proposer et les décisions qui restent à la personne responsable.

K
Ken Jo

Une équipe commerciale reçoit un contrat fournisseur avec une pièce jointe appelée « final ». Le montant figure dans un tableau à la page 13. La juridiction compétente manque et la personne chargée de relire est absente. Quiconque a traité ce genre de demande sait combien de travail se cache dans « envoyez le contrat pour approbation ». Les étapes sont réparties entre les règles écrites, les habitudes et le jugement de la première personne qui ouvre le fichier.

Box, plateforme de gestion des contenus d’entreprise, a présenté Box Architect lors de BoxWorks le 5 novembre 2026. Le produit annoncé part d’un objectif formulé en langage courant et utilise des procédures et contenus déjà stockés dans Box pour proposer un processus. Selon Box, Architect assemblera des formulaires, des modèles de métadonnées, des agents et des applications. Il pourra ensuite signaler des points de blocage. La société a annoncé un début de déploiement en bêta pour les clients Enterprise Advanced au quatrième trimestre 2026. Annonce BoxWorks et disponibilité

La première version d’un processus pourrait devenir plus facile à produire. Le travail le plus important reste de décider comment traiter les cas qui le font échouer. La réception des contrats est un exemple assez circonscrit pour voir quelles décisions doivent figurer dans le projet, quoi vérifier avant le déploiement et ce qu’un pilote utile mesurerait.

Extérieur du siège de Box à Redwood City, en Californie

Siège de Box à Redwood City, photographié en mars 2017 par Jeanjung212. Photo d’illustration recadrée et redimensionnée, CC BY-SA 4.0. Source de l’image · Licence.

Un objectif métier devient une proposition que l’équipe peut examiner

Dans sa présentation du 5 novembre, Box décrit une séquence de conception, de mise en place et d’amélioration. Elle part du résultat recherché et des procédures existantes. Architect propose les étapes, les décisions et les transferts, puis peut assembler les composants Box correspondants. L’entreprise cite Forms, Extract, Automate, Apps, Doc Gen et Sign. La personne responsable peut réviser la proposition, tester les cas limites et ajouter des étapes de contrôle et d’approbation avant le déploiement. Box indique aussi que le produit suggérera des améliorations après avoir détecté, par exemple, des informations manquantes récurrentes. Présentation de Box Architect

Un verbe précis par étape aide à comprendre le processus. La réception reçoit un fichier. L’extraction relève des champs. L’affectation désigne la personne qui relit. L’approbation consigne une décision. La diffusion transmet le résultat approuvé à un destinataire autorisé. Ces étapes peuvent utiliser les mêmes documents et avoir des conséquences très différentes. Quelqu’un peut extraire un montant alors que seuls les achats peuvent l’approuver. La personne qui autorise une dépense n’a pas pour autant de raison de partager un dossier entier avec un tiers.

La réception d’un contrat passe par l’extraction et les règles, puis par l’approbation ou la file d’exceptions

L’exemple sépare la réception, l’extraction, l’affectation et la décision. Illustration originale de Telli.sh.

Une instruction initiale bien délimitée pourrait ressembler à ceci :

Recevez les contrats fournisseurs et identifiez le responsable de la demande, le type de contrat, le montant et la juridiction compétente. Affectez les dossiers complets à la personne désignée dans le tableau approuvé. Transmettez les champs manquants, les montants contradictoires et les juridictions inconnues à un responsable désigné. Attendez qu’une personne autorisée valide la version exacte et le destinataire avant tout partage externe.

L’instruction est plus utile si elle renvoie à une règle en vigueur. Ajoutez la version contrôlée du tableau d’affectation et précisez la conduite à tenir si deux règles s’appliquent. Définissez le montant de référence et l’effet de la devise ou de la durée du contrat sur le seuil. Si le service juridique et les achats interviennent, précisez si les relectures se font en parallèle ou dans un ordre donné. Le projet de processus donne un objet concret à relire pendant que l’équipe règle ces questions.

Box indique que le contenu reste dans Box, sous ses permissions et ses règles. Testez tout de même avec des comptes représentant le déposant, la personne chargée de relire et une personne sans accès au contrat. Le document important est le schéma approuvé du processus, avec les entrées, transmissions, exceptions et responsables des décisions. Un nouveau membre peut alors comprendre le trajet d’un fichier sans reconstituer une conversation passée avec l’assistant. Présentation de Box Architect

La file d’exceptions met la conception à l’épreuve

Prenons deux versions d’un accord. Le fichier importé annonce un total de 49 500 dollars. Son avenant signé porte la somme à 52 000 dollars. Les deux valeurs sont faciles à extraire. Déterminer quelle pièce fait foi pour l’approbation est une autre tâche. Dans cet exemple, les deux montants devraient figurer dans le rapport d’exception avec leurs pages et noms de fichier, et l’affectation automatique devrait s’arrêter. Si le système choisit un montant sans garder le désaccord, la personne chargée de relire peut ne jamais apprendre qu’un deuxième montant existait.

Autre cas, le contenu est bon mais l’accès ne l’est pas. Une personne peut demander une relecture mais joint un fichier situé hors des dossiers autorisés. Elle doit voir que sa demande est bloquée ou incomplète sans recevoir d’aperçu du document protégé. Si le propriétaire déplace le fichier, l’ancien lien ou la tâche d’approbation doit suivre les règles d’accès de l’organisation. Testez ce comportement, car un déploiement d’entreprise se limite rarement à un dossier auquel tout le monde accède de la même manière.

Un troisième cas teste le remplacement. Une personne approuve la version 4, mais la version 5 arrive juste avant la demande de signature. Décidez s’il faut rouvrir la relecture, comment la version 4 reste visible dans le journal d’audit et qui peut relancer la demande. La décision doit porter sur une version précise. Un résumé des clauses peut être utile, mais le processus doit indiquer sur quel accord portait la décision humaine.

Cas d’essaiÉléments nécessaires à la relectureAction attendue pendant le pilote
Accord standardVersion, champs obligatoires et règle d’affectationAffecter la personne désignée
Montants contradictoiresLes deux montants, avec page ou fichierSuspendre et demander une clarification
Fichier requis mais protégéRésultat du contrôle d’accès et correction autoriséeSuspendre sans exposer le document
Nouvelle version après approbationVersion approuvée et nouvelle versionRouvrir la relecture ou appliquer la règle documentée
Demande reçue deux foisIdentifiant existant et heure de réceptionRelier ou signaler sans créer une deuxième approbation

Les cas du tableau sont des exemples. Préparez des documents aux réponses connues et aux mises en page proches de celles que l’équipe rencontre. Un accord propre d’une page établit le parcours normal. Un PDF numérisé de travers, une annexe multilingue ou une signature manquante révèle si le processus reste compréhensible quand l’extraction devient incertaine.

Un deuxième processus peut montrer si la méthode se transfère à une autre équipe. La comptabilité fournisseurs peut extraire des identifiants de facture, comparer les montants aux bons de commande et transmettre les écarts. Le parcours de réception ressemble à celui des contrats, mais les preuves changent. La personne chargée d’une facture a besoin du numéro de commande, des lignes et de la règle de tolérance. Gardez le premier pilote sur un seul circuit. Si la deuxième équipe reprend la méthode, vérifiez si elle réutilise la structure de réception et d’exception avec ses propres sources contrôlées et approbations. Ce résultat renseigne davantage qu’un schéma visuellement similaire.

La bêta d’Architect et les contrôles disponibles suivent des calendriers distincts

Le 5 novembre, Box a regroupé plusieurs produits sous l’automatisation par agents et la protection. Architect devait arriver en bêta pour les clients Enterprise Advanced. Les nouvelles protections contre les menaces étaient prévues pour les offres éligibles début 2027. Les contrôles de sécurité des agents étaient déjà disponibles pour les clients Shield et Enterprise Advanced, selon Box. Ils incluent des règles fondées sur la classification, des restrictions sur les actions via le serveur MCP de Box et des alertes par seuil. Vérifiez l’offre et les accès de votre environnement avant de déduire la disponibilité d’une fonction à partir de la démonstration d’une autre. Annonce Box et disponibilité

Ces distinctions comptent lorsqu’un processus crée des enregistrements ou partage des fichiers. Box documente des règles administratives MCP pour les écritures appelées par un agent externe. Un administrateur peut y limiter les opérations prises en charge. Un circuit d’approbation natif de Box demande des essais avec les composants qu’il utilise effectivement. Rattachez chaque écriture à son composant et à sa règle, puis vérifiez le résultat avec le rôle qui l’exécute. Documentation Box Support sur les protections MCP

Concevoir le processus et contrôler son exécution représentent deux coûts. Une personne peut passer moins de temps à relier les formulaires et métadonnées, et plus à tenir les règles et préparer les essais. Si la politique est dispersée entre d’anciennes versions, des lecteurs partagés et des courriels, la première amélioration peut être un seul tableau d’affectation à jour. Un processus reproductible rend la dérive visible, car chaque exception a une destination. Une modification de responsabilité limitée à une règle permet aussi de réviser plus vite un processus approuvé.

Donnez une modification de règle concrète à répéter. Supposons qu’une règle d’achat abaisse le seuil de contrôle juridique au 1er décembre. Une demande déjà en cours peut rester sous l’ancienne règle, tandis qu’un nouveau dossier suit la nouvelle. Précisez quel horodatage tranche et qui autorise le changement. Gardez un contrat d’essai de chaque côté de la date. Si la révision modifie aussi l’extraction, recommencez séparément les contrôles de montant et de devise pour savoir si une nouvelle affectation vient de la règle ou d’une lecture différente.

Comparer deux processus avant de transmettre un vrai contrat

Un pilote compare le processus manuel et le projet Architect sur les mêmes dossiers d’essai avant la validation humaine

Utilisez les mêmes dossiers et critères pour le processus manuel et le projet Architect. Illustration originale de Telli.sh.

  1. Choisir un processus restreint. Commencez avec une entité et un type d’accord. Notez la procédure actuelle et désignez une personne capable de répondre aux questions d’affectation et d’escalade.
  2. Réunir des sources approuvées. Consignez les versions et autorisations. Préparez des documents fictifs ou correctement anonymisés, avec des exceptions connues et un compte de test sans accès.
  3. Créer le projet dans l’environnement éligible. Après ouverture de l’accès bêta, donnez l’objectif et les procédures à Architect. Examinez les formulaires, métadonnées, affectations et décisions avec la personne responsable. Indiquez explicitement la file d’exceptions.
  4. Rejouer les mêmes cas manuellement et dans le projet. Vérifiez que les valeurs viennent de la bonne version, que le dossier atteint le bon rôle et que le contenu protégé le reste.
  5. Examiner les changements avant activation. Gardez la proposition initiale, les modifications humaines, les responsables de l’approbation et la procédure de retour. Exigez l’approbation nécessaire avant partage ou signature réels. Vérifiez ce qui arrive lorsqu’une exécution se répète ou qu’une règle change.

Distinguez le temps de construction du temps d’exploitation. Mesurez les minutes jusqu’à la première version exploitable puis le temps de correction après relecture. Pendant le rejeu, relevez la part des cas complets correctement affectés, celle des exceptions détectées et le nombre de décisions annulées par une personne. Incluez des cas sans autorisation même s’ils sont rares. Un processus qui traite 20 cas faciles et expose un accord protégé révèle un problème de mise en service.

Pour le premier lot réel, gardez une procédure manuelle et définissez qui peut suspendre les nouvelles exécutions. Comparez la trace de l’équipe à celle de la personne qui dépose le dossier. Les deux doivent pouvoir savoir s’il manque une information, si la demande attend une approbation ou si elle a été retournée, avec le détail autorisé pour chaque rôle. Si le processus est plus facile à créer mais que les employés ne savent plus où sont leurs contrats, la charge est passée du paramétrage au support.

Un processus utile reste explicable lorsqu’il s’arrête

L’élément le plus intéressant de la proposition d’Architect est le projet modifiable entre objectif métier et processus opérationnel. Il permet une discussion avec le juridique, les achats et l’informatique avant qu’un vrai contrat ne circule. Un pilote réussi répond à une question qui survit à la démonstration. Lorsqu’un document se bloque, la personne responsable sait-elle quelle règle l’a arrêté, quelle version a été lue et qui peut agir ensuite ?

Sources


Pour retrouver les conversations et les décisions qui ont guidé votre travail, créez un compte Telli.sh.


← Retour au blog