Les briques

Tous les outils du marché proposent les mêmes briques sous des noms différents. Les connaître évite d’apprendre un outil et permet d’en changer.

Le déclencheur

Ce qui met l’enchaînement en route. Deux familles, et le choix a des conséquences.

L’événement. Le service prévient dès qu’il se passe quelque chose. Immédiat, économe, mais tous les services n’en proposent pas.

L’interrogation régulière. L’enchaînement va vérifier toutes les X minutes s’il y a du nouveau. Universel, mais il consomme une exécution à chaque passage, même quand il n’y a rien.

Trois pièges classiques.

L’intervalle trop court. Vérifier toutes les minutes une boîte qui reçoit trois mails par jour consomme des milliers d’exécutions pour rien. Cinq à quinze minutes suffisent presque toujours.

Le déclencheur trop large. « À chaque nouveau mail » déclenche sur les publicités, les réponses automatiques et les accusés de réception. Filtre tout de suite, pas trois étapes plus loin.

Le double déclenchement. Une modification de ligne qui déclenche un enchaînement qui modifie la ligne, donc déclenche l’enchaînement. Ça arrive plus souvent qu’on ne croit, et ça se voit sur la facture.

Le filtre

Ce qui décide si l’enchaînement continue. La brique la plus sous-utilisée, et celle qui coûte le moins cher.

Place les filtres le plus tôt possible. Une exécution arrêtée à la deuxième étape coûte moins qu’une exécution arrêtée à la dixième, en argent comme en risque.

Et écris tes filtres en positif : « continuer si le montant dépasse 500 » se relit mieux que « arrêter si le montant ne dépasse pas 500 », six mois plus tard.

L’action

Ce qui est fait. Trois recommandations qui évitent l’essentiel des problèmes.

Une action par étape. Un module qui fait trois choses est un module dont on ne sait pas laquelle a échoué.

Nomme tes étapes. « Créer la ligne de suivi » plutôt que « Google Sheets ». Dans six mois, le deuxième nom ne t’apprendra rien, et la personne qui reprend l’enchaînement encore moins.

Écris ce qui se passe si l’étape échoue. C’est le sujet de la fiche sur les reprises, et ça se décide au moment de créer l’action, pas après.

La boucle

Traiter plusieurs éléments d’un coup : les lignes d’un tableau, les pièces jointes d’un mail, les résultats d’une recherche.

Deux règles, et la première est une règle de sécurité.

Borne toujours. Fixe un maximum d’éléments traités par exécution. Une boucle non bornée sur une source qui renvoie soudain dix mille lignes consomme ton quota en quelques minutes, et c’est irréversible.

Prévois le cas zéro. Une boucle sur une liste vide doit se terminer proprement, pas produire une erreur ou un message vide envoyé à quelqu’un.

La règle des sept étapes

Repère empirique, mais il tient.

Au-delà de sept ou huit étapes, un enchaînement devient difficile à comprendre, à tester et à réparer. Et surtout, il devient difficile à reprendre pour quelqu’un d’autre.

Trois façons de découper.

Par événement métier. « Une commande arrive » et « une commande est expédiée » sont deux enchaînements, pas un seul avec une grande condition.

Par point d’attente. Si le processus attend une action humaine, coupe là. Le premier enchaînement prépare, le second reprend après validation.

Par système. Si une partie touche la comptabilité et l’autre le service client, deux enchaînements sont plus faciles à confier à deux propriétaires.

Nommer, la discipline qui rapporte le plus

Trois conventions à décider avant de construire, et à tenir.

Le nom de l’enchaînement dit ce qu’il fait et pour qui : « Commandes web vers tableau de suivi Opérations ». Pas « Automatisation 3 ».

Le nom des étapes dit l’intention métier, pas le nom du connecteur.

Une note dans l’enchaînement lui-même, quand l’outil le permet : qui l’a construit, quand, à quoi il sert, qui prévenir.

Ça prend cinq minutes et ça change tout le jour où quelqu’un d’autre ouvre le dossier. Le module 3 en fait un livrable.

Les données entre les étapes

Point technique, expliqué une fois, et qui évite beaucoup de tâtonnements.

Chaque étape produit des données que les suivantes peuvent utiliser. Trois précautions.

Vérifie le format. Une date peut arriver en texte, un nombre avec une virgule ou un point, un montant avec ou sans symbole. La plupart des pannes silencieuses viennent de là.

Prévois le champ vide. Un client sans numéro de téléphone, une commande sans commentaire. Si l’étape suivante exige ce champ, elle échouera sur ce cas et pas sur les autres, donc rarement, donc tard.

Ne fais pas circuler ce dont tu n’as pas besoin. Si l’étape suivante n’a besoin que du numéro de commande, ne lui transmets pas la fiche client entière. C’est plus simple à déboguer, et c’est le sujet de la fiche sur les données.

Par où commencer, concrètement

Construis dans cet ordre. Il paraît lent et il est plus rapide.

Le déclencheur seul, et regarde ce qu’il produit réellement. Souvent différent de ce que tu imaginais.

Puis le filtre, et vérifie qu’il laisse passer ce qu’il doit.

Puis une seule action, la plus simple, sur un environnement de test.

Puis les autres, une par une, en vérifiant à chaque ajout.

Ceux qui construisent l’enchaînement complet avant de tester passent leur après-midi à chercher laquelle des huit étapes pose problème.

Vérifie ta compréhension

Question : ton enchaînement se déclenche à chaque modification d’une ligne du tableau, met à jour une colonne de statut dans cette même ligne, puis envoie une notification. Où est le problème ?

Réponse : la mise à jour de la ligne modifie la ligne, ce qui redéclenche l’enchaînement, qui met à jour, qui redéclenche. Tu as une boucle infinie qui consommera ton quota d’exécutions et enverra des notifications en rafale. Les solutions habituelles : filtrer sur la colonne modifiée pour ignorer tes propres écritures, écrire le statut dans une autre source, ou utiliser un marqueur que l’enchaînement reconnaît comme venant de lui.

Fiche suivante : où mettre l’IA, et où surtout pas.