Asana ne sait pas qu'un conteneur est bloqué en douane.

Oui. Le même composant Tâches s'affiche dans trois portails : opérateur (visibilité complète), client (l'acheteur — voit les tâches créées pour lui, comme « Approuver l'échantillon » ou « Confirmer l'expédition fractionnée »), et fournisseur (le fabricant — voit les tâches créées pour lui, comme « Soumettre le rapport SGS » ou « Accuser réception du calendrier d'inspection »). Chaque portail utilise le même modèle de données avec un préfixe API différent (opérateur : /api/tasks · client : /api/portal/client/tasks · fournisseur : /api/portal/supplier/tasks) et une liste blanche de types d'entités restreinte. L'opérateur crée une tâche, l'assigne à un contact fournisseur, et elle apparaît dans la liste des tâches du portail fournisseur — même énumération de statuts, même priorité, même flux d'activité. Le fournisseur la marque comme terminée ; l'opérateur voit la complétion en temps réel.

Les approbations sont des tâches. Plus précisément, une tâche avec le statut pending_approval — l'un des six statuts natifs. Lorsqu'un opérateur ou une contrepartie soumet un livrable nécessitant une validation (une redline de contrat, une évaluation d'échantillon, un dépassement budgétaire, une version de document), le travail passe à pending_approval et remonte dans la liste des tâches de l'approbateur avec tout ce dont il a besoin pour agir. L'approbation, le rejet et la mention « modifications requises » sont des transitions de statut sur la tâche. La piste d'audit — qui a approuvé quoi, quand et pourquoi — vit dans le flux d'activité de la tâche. Nous avons délibérément évité de construire un moteur d'approbations séparé ; l'intégrer aux Tâches signifie une seule boîte de réception, un seul flux de travail, un seul endroit où regarder.

Oui — c'est la partie « système nerveux » de l'architecture. Les événements dans les autres sections (changement de statut de commande, QC de production terminé, retard d'expédition, facture en souffrance, échantillon évalué, réclamation déposée, document téléversé, message signalé avec un point d'action) sont tous émis via le moteur des Tâches. La plateforme détermine si l'événement nécessite une attention humaine sur la base de règles configurables par catégorie, et lorsque c'est le cas, une tâche est créée avec le lien d'entité hérité, la catégorie prédéfinie et un responsable suggéré issu de l'historique des parties responsables. Les Tâches sont la façon dont la plateforme communique aux humains les travaux à réaliser — et dont elle suit si ces travaux ont bien été effectués.

La principale surface d'action d'Atlas EST la création de tâches. Lorsqu'Atlas détecte quelque chose nécessitant un jugement humain — une marge qui descend en dessous d'un seuil, une contrepartie qui devient silencieuse sur un fil, un document expirant, un schéma récurrent à travers les commandes — il crée une tâche avec les données pertinentes déjà attachées. Un message de chat pose une question et défile. Une tâche porte le contexte, le responsable, la date d'échéance et la piste d'audit indiquant si l'opérateur a agi. Cela rend le signal d'Atlas mesurable : la tâche a-t-elle été clôturée dans les délais ? A-t-elle été clôturée du tout ? Le fait qu'Atlas crée des tâches (plutôt que de simplement poster des messages) est la façon dont nous rendons l'IA responsable du travail qu'elle signale.