Le scénario heureux ne suffit pas

Une nouvelle demande arrive. Un contact est créé. Une tâche apparaît au bon endroit. La démonstration est réussie. Mais ce n’est qu’une partie du travail.

Je m’intéresse aussi au jour où une information manque, où un outil répond trop tard ou où la même demande arrive deux fois. C’est souvent là que l’automatisation révèle si elle aide vraiment l’équipe ou lui prépare un nouveau travail de nettoyage.

Définir qui fait foi

Avant de connecter deux outils, j’écrirais la responsabilité de chacun. Où modifie-t-on le nom d’un client ? Quel système détermine le statut d’une commande ? Une modification dans l’outil de destination doit-elle revenir vers la source ?

Ces questions semblent simples jusqu’à ce que deux systèmes donnent une valeur différente. Une petite carte du processus, avec un responsable pour chaque donnée importante, évite beaucoup d’ambiguïtés.

Prévoir les exceptions courantes

Je classerais les situations en trois groupes : poursuivre, réessayer, demander une intervention. Une valeur facultative absente ne mérite pas forcément de bloquer tout le scénario. Une identité ambiguë mérite parfois de s’arrêter.

  • Une demande répétée doit-elle mettre à jour un élément ou en créer un nouveau ?
  • Une erreur temporaire peut-elle être reprise sans répéter toute l’action ?
  • Qui reçoit l’alerte si le scénario reste bloqué ?
  • Où retrouve-t-on le contexte nécessaire pour comprendre l’échec ?

La documentation technique des outils guide la reprise. Par exemple, Klaviyo décrit les réponses liées aux limites de débit et la façon de respecter le délai communiqué avant une nouvelle tentative. Voir sa documentation des limites et erreurs API.

Rendre le fonctionnement visible

Un scénario silencieux n’est pas toujours un scénario qui fonctionne. Je définirais quelques signes simples : la dernière exécution utile, les éléments en attente et les erreurs qui demandent une décision.

Je documenterais aussi comment mettre en pause, reprendre et corriger un cas. Le jour où la personne qui a construit le scénario n’est pas disponible, cette information devient beaucoup plus précieuse qu’un diagramme impressionnant.

Commencer petit, puis élargir

Pour une première mise en service, je choisirais un périmètre limité et des exemples que l’on peut suivre. Je vérifierais le résultat dans l’outil de destination, puis la capacité à traiter un cas inhabituel.

Automatiser, ce n’est pas seulement faire circuler des données. C’est décider de ce qui doit se passer quand les données ou les outils ne se comportent pas comme prévu.

La réussite se mesure aussi à la facilité avec laquelle votre équipe peut comprendre le système et reprendre la main. C’est cette autonomie qui mérite d’être livrée avec la connexion.