Bibliothèque de cas pratiques · Cas B sur 3

Une automatisation exécutée. Une approbation absente.

Une condition autorise un envoi dès lors que son statut n’est pas « refusé ». Que devient une entrée absente, en attente ou associée à une autre version du document ? Cet exercice examine une règle d’autorisation avant de s’intéresser à la vitesse d’exécution.

Cas pratique pédagogique. Documents, transactions et traces synthétiques. Les réponses présentées sont préparées pour l’exercice ; elles ne sont pas les résultats d’un test de modèle réel. Il s’agit d’un exercice en JavaScript avec des fixtures locales : il ne décrit pas le fonctionnement de Make, n8n ou Zapier.

Les pièces

La règle fautive et la règle corrigée

// Règle fautive étudiée dans cet exercice JavaScript.
const weakAllows = input => input.approval_status !== 'refused';

// Contrôle pédagogique déterministe : ne remplace pas une autorisation serveur.
function allows(input, now) {
  const expires = Date.parse(input.expires_at);
  return input.approval_status === 'approved'
    && typeof input.operation_id === 'string'
    && input.operation_id.length > 0
    && typeof input.payload_hash === 'string'
    && input.payload_hash.length > 0
    && input.payload_hash === input.approved_payload_hash
    && input.document_version === input.approved_version
    && input.document_version === 'V4'
    && input.revoked === false
    && Number.isFinite(expires)
    && expires > now;
}

Dans cet exercice, les chaînes H-A et H-B servent seulement à tester une égalité. Ce ne sont pas des empreintes cryptographiques. Dans une application réelle, il faut calculer une empreinte sur une représentation canonique de la charge utile, vérifier l’identité et les droits de l’approbateur, empêcher l’altération des preuves et effectuer le contrôle au point d’exécution. Le contrôle dans le navigateur ne protège aucun service.

Les douze fixtures

Base : operation_id=OP-001, payload_hash=H-A, approved_payload_hash=H-A, document_version=V4, approved_version=V4, revoked=false, expires_at=2026-10-14T00:00:00Z. Horloge de test : 2026-10-13T12:00:00Z.

Journal : délai dépassé après effet (journal-B.csv)

L’exercice

1. Pourquoi la règle fautive autorise-t-elle onze fixtures sur douze ?
2. Quelles conditions la règle corrigée ajoute-t-elle, et laquelle aurait suffi à refuser B03 à B07 ?
3. Dans journal-B.csv : combien de tentatives, d’objets créés et de confirmations reçues par l’émetteur ?

Contre-exemple

Remplacer E05 par object_created,BON-002 (fichier journal-B-doublon.csv) montre un doublon dans cette autre fixture. La reprise n’implique donc pas automatiquement un doublon ; elle crée un risque qui dépend du destinataire et de son mécanisme d’unicité.

Simulateur local

Choisissez une fixture : le simulateur affiche la branche prise par chaque règle. Il ne déclenche aucun courriel, paiement ou appel externe.

Décision et limites

Une autorisation doit être positive et liée à l’action exacte. Une tentative n’est pas une preuve d’effet métier. Avant déploiement, vérifier le contrôle serveur, les changements après approbation, les reprises et les appels concurrents. Les fixtures présentes ne démontrent ni la sécurité d’une plateforme ni une garantie universelle d’exécution unique.

Pièces à télécharger

Sans formulaire. Licence CC BY 4.0. Empreintes dans SHA256SUMS.txt ; elles authentifient les fichiers distribués, pas une exécution réelle.

• tests-B.json — douze fixtures et résultats attendus
• journal-B.csv — journal de reprise
• journal-B-doublon.csv — journal alternatif avec doublon
• regles.js — règles fautive et corrigée

Toutes les pièces, le README et la licence

Les autres cas

Décider avant de déployer