Une automatisation s'exécute sans approbation : examiner la règle de passage
Ce cas pratique pédagogique examine une règle qui autorise une action lorsque la valeur n'est pas « refusé ». Une validation en attente satisfait alors cette règle. Le cas compare ce comportement à une règle exigeant une approbation explicite, sans l'attribuer à un logiciel commercial.
Une automatisation de démonstration prépare une proposition commerciale qui ne doit partir qu'après approbation. Une proposition est pourtant marquée comme transmise alors que son statut est « en attente ». La règle en cause n'exige pas une approbation : elle exclut seulement la valeur « refusé », si bien que les états « en attente », absent ou inconnu la satisfont. Une simulation en Python le montre sur une table de vérité ; la correction consiste à exiger explicitement « approuvé ». Cela ne suffit pas à sécuriser le processus : l'approbation doit porter sur la version transmise, et une reprise après une erreur peut produire deux effets, ce qu'examine le module E. Les résultats décrivent les expressions Python du dossier ; ils ne décrivent ni Make, ni Zapier, ni n8n, qui n'ont pas été testés. La simulation établit une divergence entre l'intention et la règle, pas l'exécution d'un service réel ni l'auteur d'une configuration.
Situation et pièces
L'action de transmission doit attendre une approbation. Le journal montre pourtant une transmission déclarée alors que le statut est « en attente ».
- B-01 regles.json — intention, règle initiale
statut != 'refuse', règle corrigéestatut == 'approuve'. - B-02 journal-synthetique.csv — création, évaluation de la règle, transmission déclarée, toutes « en attente ».
- B-03 table-verite.csv — résultats des deux règles pour cinq entrées.
La dernière ligne du journal indique ce que le journal déclare. Dans une situation réelle, elle ne suffirait pas à prouver la réception par un destinataire.
| Entrée | Règle initiale | Règle corrigée |
|---|---|---|
| en attente | autorise | bloque |
| approuvé | autorise | autorise |
| refusé | bloque | bloque |
| valeur absente | autorise | bloque |
| valeur inconnue | autorise | bloque |
Analyse
La règle initiale n'exige pas une approbation ; elle exclut seulement une valeur de refus. Dans la simulation, elle autorise donc les états « en attente », absent et inconnu. Le journal fourni est compatible avec ce mécanisme. La simulation démontre une divergence entre l'intention décrite et la règle formalisée, mais elle ne prouve ni l'exécution d'un service réel, ni la réception d'une proposition, ni l'identité de l'auteur d'une configuration.
Correction et risques résiduels
Exiger statut == 'approuve' bloque les autres entrées dans la simulation. Deux questions restent ouvertes :
- L'approbation porte-t-elle sur la version transmise ? Une proposition r1 approuvée ne doit pas autoriser une proposition r2 modifiée. Le modèle pédagogique exige un statut approuvé et l'égalité des révisions.
- Une reprise peut-elle déclencher plusieurs transmissions ? Un système réel demande un contrôle des doublons et des reprises. L'exercice ne teste ni concurrence, ni stockage transactionnel, ni livraison réseau ; un simple indicateur local ne garantit pas une exécution unique en production.
Une valeur de référence unique doit être définie : ne pas mélanger « approved » et « approuve » sans correspondance explicite, et documenter toute conversion de type plutôt que la laisser implicite.
Tests de recette de la règle corrigée
| Entrée | Résultat attendu |
|---|---|
| En attente | Bloqué |
| Refusé | Bloqué |
| Champ absent ou valeur inconnue | Bloqué |
| Approuvé, révision approuvée r1, révision courante r1 | Autorisé |
| Approuvé, révision approuvée r1, révision courante r2 | Bloqué |
| Une révision absente | Bloqué |
Ces résultats sont vérifiés par le programme verifier_exercices.py. Pour un connecteur réel, il faudrait encore vérifier le type exact des champs, leur origine, les transitions autorisées et le comportement lors d'une reprise.
Exercice
Si l'écran affiche « approuvé » aujourd'hui, peut-on en déduire que ce statut était présent avant la transmission ?
Non. Il faut une chronologie des changements reliée à l'objet et à sa révision. Une capture de l'état actuel ne remplace pas l'historique.
Module E : timeout après écriture, deux tentatives, combien d'effets ?
Une orchestration doit créer un seul bon interne pour l'opération OP-DEMO-07. Le premier appel crée le bon, mais sa réponse n'arrive pas : l'orchestrateur constate un timeout et reprend. Pièces : journal sans déduplication et variante avec registre de déduplication chez le destinataire. Le champ « ordre » est une séquence posée par l'exercice, pas une reconstruction à partir d'horloges.
| Mesure | Sans déduplication | Avec registre |
|---|---|---|
| Tentatives | 2 | 2 |
| Appels reçus par le destinataire | 2 | 2 |
| Objets créés | 2 | 1 |
| Notification à un client | Non documentée | Non documentée |
Le timeout ne prouve pas que la première action a échoué : le journal du destinataire montre une création avant ce timeout. Dans la seconde variante, le registre réutilise l'objet de la première tentative. Ce résultat décrit une simulation séquentielle ; il ne démontre pas une garantie universelle d'exécution unique.
Contre-exemples vérifiés par verifier_complements.py : une nouvelle clé à chaque reprise recrée un effet ; la même clé avec une charge différente est rejetée comme conflit. En production, la concurrence, l'atomicité, la durée de conservation des clés et le contrat du destinataire demandent d'autres contrôles, que le programme ne simule pas.
Et sur une plateforme réelle ?
Les plateformes documentent des mécanismes qui touchent directement ces questions, sans les trancher. La documentation de n8n distingue l'historique des exécutions de l'historique du workflow, et propose de reprendre une exécution échouée soit avec le workflow enregistré actuellement, soit avec celui d'origine. Celle de Make décrit le traitement des webhooks, l'option de traitement dans l'ordre, la conservation des exécutions incomplètes pour une reprise manuelle, et le choix des valeurs de variables actuelles ou de celles du moment de l'exécution initiale. Aucune de ces pages ne garantit qu'un effet externe n'est produit qu'une fois : cela dépend aussi du système destinataire. Les résultats Python de ce cas ne se transposent pas à ces outils sans essai spécifique.
Citer ce cas, signaler une erreur
Référence Denis Atlan, « Une automatisation s'exécute sans approbation : examiner la règle de passage », cas pratique pédagogique, sapiteur-ia.fr, version 1.0, publié le 24 septembre 2026, https://www.sapiteur-ia.fr/ressources/dossiers-pedagogiques/validation-absente/
Une erreur de raisonnement, de calcul ou de lecture des pièces ? Signaler une erreur dans ce raisonnement. Les corrections sont datées dans le journal des corrections.
Préparé avec l'assistance d'un outil d'IA, sous la responsabilité éditoriale de Denis Atlan (voir la méthode éditoriale). Aucune relecture externe n'est documentée pour ce cas.
Sources et références
- View executions for a single workflow, historique des exécutions et historique du workflow ; reprise avec le workflow enregistré ou d'origine.
- Scenario settings, traitement des webhooks, exécutions incomplètes, variables lors d'une reprise.
Rédaction : Denis Atlan Publié le Méthode éditoriale et corrections