Sur cette page
Un projet de synchronisation compte vingt cases. La septième copie un statut dans un tableur. La huitième reformate le fichier pour une plateforme d’e-mail. La neuvième envoie un message à une responsable pour approuver l’importation. Le projet demande quel agent devrait exécuter les cases sept à neuf.
La première question est pourquoi ces cases existent. L’exemple est illustratif, pas l’audit d’une équipe réelle.
Une discussion sur la conception de processus propose quatre catégories : supprimer l’étape, employer du code simple, employer un agent ou garder la décision humaine. Le geste utile précède le choix d’un modèle. Supprimer une étape peut rendre inutile toute la mécanique qui l’entoure.
Commencez par le résultat visible pour le client
Nommez le résultat que le processus doit produire. Pour une connexion entre boutique et e-mail, ce pourrait être « une personne qui a acheté ne reçoit plus de rappel de panier ». Ce résultat implique un état, un délai et une règle d’exclusion. Il n’impose ni tableur, ni exportation complète chaque nuit, ni boîte de réception d’une responsable.
L’illustration Tajo ci-dessous centre l’examen sur la correspondance proposée et sur la limite avant activation. Elle n’implémente pas la suppression des rappels de panier. Pour obtenir ce résultat, il faut d’abord définir le signal d’achat et la règle de suppression. Ajouter un champ ne remplace aucune de ces décisions.
Examiner une synchronisation avant son lancement
Synchronisez les mises à jour clients avec ma plateforme email.
Synchronisation clients
| Champ source | Champ cible | Règle |
|---|---|---|
email | EMAIL | Directe |
first_name | FIRSTNAME | Directe |
last_name | LASTNAME | Directe |
Aperçu synthétique validé
3 champs associés · Aucune écriture dans la cible
Présentation illustrative fondée sur les outils de correspondance de Tajo. Un aperçu synthétique et un brouillon enregistré n'activent pas une synchronisation.
Remontez le chemin existant depuis le résultat. Pour chaque étape, demandez ce qui échouerait si elle disparaissait. Un vrai contrôle a une réponse : un consentement serait perdu, un paiement contesté serait ignoré ou un envoi non autorisé pourrait se produire. Un relais conservé par habitude n’a parfois qu’une justification historique : l’ancien système avait besoin d’un fichier.
La catégorie « supprimer » n’autorise pas à effacer les protections. Examinez le rôle de chaque étape avant de la classer.
- Résultat requiseffet pour le clientremonter le chemin
- Examiner les étapesrôle et contrôleretirer l’inutile
- Travail conservéresponsable et testable
L’examen identifie la livraison et les dépendances qui la protègent réellement. Si le tableur porte un jugement métier absent ailleurs, gardez ce jugement même si le fichier disparaît.
| Type d’étape | Question | Exemple dans un parcours de panier illustratif |
|---|---|---|
| Supprimer | Protège-t-elle ou produit-elle le résultat requis ? | Une exportation en double que personne ne lit |
| Code simple | La règle est-elle exacte et stable ? | Bloquer le rappel si un achat vérifié existe |
| Jugement du modèle | Une interprétation bornée est-elle nécessaire ? | Classer un message libre pour la bonne équipe |
| Personne ou politique approuvée | Le choix accorde-t-il une autorité ou entraîne-t-il des conséquences importantes ? | Approuver l’accès aux données clients |
Le tableau est un outil de conception. Il ne rapporte pas comment les étapes d’une entreprise ont réellement été classées.
Confiez les règles exactes au code
Un appel API, une validation de champ, une comparaison de dates ou une vérification de droits ne s’améliorent pas parce qu’un modèle les improvise. Le code peut exprimer une propriété, se comporter de la même façon deux fois et produire un échec vérifiable. Utilisez-le quand la règle peut être formulée.
Dans l’exemple du panier, l’événement d’achat peut arriver tard ou deux fois. Le programme doit identifier la commande, comparer l’état actuel et refuser le rappel quand l’achat est connu. Si le système ne peut déterminer si un achat a eu lieu, il lui faut un état d’incertitude. Le modèle ne peut pas s’autoriser à supposer que la personne n’a pas acheté.
Certaines tâches résistent aux règles exactes. Une demande de support pourrait dire : « J’ai acheté hier, mais le reçu affiche mon ancienne adresse. » L’acheminement du message peut demander un jugement sémantique borné. La sortie doit être une équipe connue ou « incertain », pas une instruction ouverte de modifier la commande. Séparez le choix du modèle du code qui contrôle les droits et écrit l’état.
Ce qu’un agent unique peut cacher
« Un agent pourrait lire le processus et tout faire. » Une démonstration peut sembler plus simple ainsi. En production, quelqu’un doit toujours expliquer pourquoi l’agent peut consulter un dossier, quelles actions il peut mener et comment réparer une mauvaise action. Un agent trop large cache souvent les mêmes étapes dans un prompt et supprime les étiquettes qui permettaient de les auditer.
Autre objection : le tri lui-même prend du temps. C’est vrai. Gardez-le court. Choisissez un résultat pour le client, listez les étapes nécessaires et demandez ce que chacune apporte. L’exercice ne vaut la peine que s’il réduit le travail ou clarifie les responsabilités. Un audit élaboré de tous les systèmes voisins deviendrait une case de plus.
Testez le classement avec un cas normal et un cas d’échec. Si l’étape supprimée était secrètement un contrôle, le test devrait le montrer. Si un jugement du modèle ne peut être évalué sur des exemples, restreignez-le ou redonnez la décision à une personne. Si le code doit changer pour chaque exception client, séparez la mécanique stable de la règle métier locale.
L’examen a aussi besoin d’un point d’arrêt. Une équipe peut décomposer chaque tâche jusqu’à ce que le classement coûte davantage que le travail économisé. Arrêtez-vous quand chaque étape conservée a un responsable, un déclencheur et une raison d’être vérifiable. Notez l’incertitude qui changerait le projet, puis testez-la sur la plus petite partie du processus réel. Pour une synchronisation, ce peut être le délai d’arrivée de l’événement d’achat avant l’envoi du rappel. Le guide d’intégration propose un plan plus large ; les quatre catégories évitent de conserver des étapes superflues. Reprenez le tri quand le processus ou les droits changent.
L’étape la moins chère est celle dont le résultat n’a jamais eu besoin.
Questions fréquemment posées
Que faut-il supprimer avant d’automatiser ?
Une étape qui ne sert qu’à compenser un relais évitable, un dossier en double ou un rapport inutilisé mérite examen. Vérifiez les personnes et contrôles qui en dépendent avant de la retirer.
Quand une étape exige-t-elle un modèle ?
Utilisez un modèle pour un jugement sémantique limité qui ne peut être formulé en règle exacte et stable, avec des entrées observables, des sorties typées et une issue en cas d’incertitude.
Quelles décisions doivent rester humaines ?
Confiez à une personne responsable ou à une politique explicitement approuvée les choix qui exigent le consentement, accordent des droits ou ont des conséquences hors du périmètre autorisé du système.