Une machine à états, ou state machine en anglais, est une façon de décrire quelque chose qui ne peut se trouver que dans une situation à la fois, appelée état, et qui passe d'un état à un autre uniquement quand un événement précis se produit. Le feu de circulation est l'exemple classique. Il est rouge, vert ou orange, jamais deux à la fois, et il change dans un ordre fixe.

Le sujet concerne toute personne qui développe ou commande un logiciel, et tout e-commerçant, car les commandes, paiements, abonnements et retours se comportent tous comme des machines à états. Comprendre le principe aide à repérer des bugs comme une commande expédiée sans être payée ou un remboursement envoyé deux fois, et à briefer clairement des développeurs.

Qu'est-ce qu'une machine à états ?

Le nom complet est machine à états finis, ou automate fini, car la liste des états possibles est finie et connue à l'avance. Une machine à états repose sur cinq éléments.

  • Les états : les situations possibles, comme en attente, payée, expédiée, livrée, annulée et remboursée pour une commande.
  • L'état initial : le point de départ, par exemple en attente quand un client passe commande.
  • Les événements : ce qui arrive de l'extérieur, comme « paiement réussi », « étiquette imprimée » ou « le client demande un remboursement ».
  • Les transitions : les passages autorisés d'un état à un autre en réponse à un événement. Payée peut passer à expédiée. Expédiée ne peut pas revenir à en attente.
  • Les états finaux : là où le cycle de vie s'arrête, comme livrée, annulée ou remboursée.

Deux autres notions reviennent souvent.

  • Les gardes sont des conditions qui doivent être vraies pour qu'une transition ait lieu. Une commande ne peut passer à expédiée que si tous les articles sont en stock.
  • Les actions sont ce qui se produit pendant une transition, comme l'envoi d'un e-mail de confirmation quand une commande devient payée.

Une machine à états est une façon de penser, indépendante de toute technologie. On peut la dessiner sur papier, l'écrire dans n'importe quel langage de programmation ou la faire tourner avec des outils dédiés. Elle se distingue aussi d'un simple champ « statut ». Un champ statut se contente de stocker une valeur, alors qu'une machine à états définit aussi les changements autorisés et interdits.

Pourquoi c'est important

Sans états et règles clairs, un logiciel finit par se retrouver dans des situations qui ne devraient jamais arriver. Dans une boutique, ces situations coûtent de l'argent.

Imaginons une boutique qui traite 3 000 commandes par mois avec un panier moyen de 55 €. Son code met à jour le statut des commandes depuis plusieurs endroits, le checkout, le webhook de paiement, l'outil de l'entrepôt et le tableau de bord du support, sans règle sur les changements autorisés. De temps en temps, une notification de paiement en retard arrive après l'annulation d'une commande, qui repasse alors en payée et part en expédition. Si cela touche 0,5 % des commandes, cela fait 15 commandes par mois expédiées sans paiement valide, soit environ 825 € de marchandises plus les frais de port, chaque mois.

Avec une machine à états, la règle est explicite. Une commande annulée est un état final, et aucun événement ne peut la faire passer à payée. La notification tardive est enregistrée et ignorée, ou déclenche un remboursement. La même logique évite les doubles remboursements, les expéditions avant paiement et les abonnements qui se renouvellent après résiliation.

Comment ça marche

Vous pouvez concevoir une machine à états pour n'importe quel processus en quelques étapes.

  • Listez les états. Écrivez chaque situation possible. Gardez des noms courts et sans ambiguïté.
  • Choisissez l'état initial. Décidez où démarre chaque nouvel élément.
  • Listez les événements. Notez tout ce qui peut arriver, du fait des clients, de l'équipe, du prestataire de paiement ou du transporteur.
  • Dessinez les transitions. Pour chaque état, indiquez quels événements sont autorisés et vers quel état ils mènent. Tout ce qui n'est pas listé est interdit.
  • Ajoutez gardes et actions. Précisez les conditions, comme un stock disponible, et les effets, comme les e-mails, la mise à jour du stock ou la facture.
  • Prévoyez l'imprévu. Décidez de ce qui se passe quand un événement interdit arrive, par exemple l'enregistrer, alerter quelqu'un ou rembourser automatiquement.
  • Codez et testez. Les développeurs peuvent la coder directement ou utiliser des bibliothèques comme XState en JavaScript, ou des services de workflow comme AWS Step Functions.

Le cycle de vie classique d'une commande ressemble à ceci :

  1. En attente, quand la commande est créée au checkout.
  2. Payée, quand le prestataire de paiement confirme le paiement.
  3. Traitée ou expédiée, quand le colis part ou que le produit numérique est livré.
  4. Livrée, quand le transporteur confirme la livraison.
  5. Annulée ou remboursée, comme fins alternatives depuis les états autorisés.

Repères et exemples

  • Les paiements : l'objet PaymentIntent de Stripe passe par des états comme requires_payment_method, requires_action, processing, succeeded et canceled. Votre boutique réagit à chaque changement grâce aux webhooks.
  • Les commandes : presque toutes les plateformes e-commerce modélisent les commandes avec des états comme en attente, payée, traitée, remboursée et annulée, et le suivi de commande montre la partie livraison au client.
  • Les abonnements : période d'essai, actif, impayé, en pause et résilié.
  • Les retours : demandé, accepté, reçu, contrôlé, remboursé ou refusé.
  • Les objets du quotidien : feux de circulation, distributeurs automatiques, ascenseurs et tourniquets sont des machines à états.
  • La taille : la plupart des processus métier ont besoin de 5 à 12 états. Au-delà, c'est souvent le signe que deux processus sont mélangés, comme le paiement et la livraison, et qu'il faut les séparer.

Erreurs fréquentes

  • Modifier le statut depuis partout. Quand plusieurs parties du code changent librement le statut, des sauts impossibles deviennent possibles. Faites passer chaque changement par les mêmes règles.
  • Ignorer l'ordre des événements. Les notifications de paiement et de transporteur peuvent arriver en retard ou en double. Gérez les doublons et les événements dans le désordre.
  • Mélanger des processus indépendants. Réunir le statut de paiement et celui de livraison dans un seul champ crée des états comme « payée, expédiée et partiellement remboursée », difficiles à gérer.
  • Oublier les cas d'échec. Annulations, paiements refusés, colis perdus et remboursements partiels ont aussi besoin d'états.
  • Ne pas la documenter. Si le schéma n'existe que dans la tête d'un développeur, le support et les opérations ne comprennent pas pourquoi une commande est bloquée.

Bonnes pratiques

  • Dessinez-la d'abord. Un simple schéma avec des cases et des flèches, relu par l'équipe métier, évite la plupart des erreurs de conception.
  • Rendez les passages interdits explicites. Chaque état liste ses transitions autorisées, tout le reste est refusé.
  • Séparez paiement, expédition et retours. Donnez à chacun sa propre machine à états et reliez-les par des événements.
  • Enregistrez chaque transition. Conservez qui ou quoi a déclenché chaque changement et quand. Le support et les contrôles deviennent simples.
  • Rendez le traitement des événements idempotent. Traiter deux fois le même webhook ne doit pas changer le résultat.
  • Affichez les états aux clients en mots simples. « Commande en préparation » et « En route » sont plus clairs que des codes internes.

Dans Roctify

Vous n'avez pas besoin de concevoir une machine à états pour vendre sur Roctify. Chaque commande suit son cycle de vie automatiquement. Elle est créée au checkout, enregistrée comme payée quand Stripe ou PayPal confirment le paiement, ou traitée en paiement à la livraison, et les produits numériques sont livrés automatiquement après paiement. Vos commandes et vos clients sont partagés entre votre page de lien en bio et votre boutique, une commande a donc un seul statut partout.

FAQ

Qu'est-ce qu'une machine à états en termes simples ?

C'est un modèle où un élément ne peut être que dans une situation connue à la fois et passe de l'une à l'autre selon des règles fixes. Un feu de circulation ou une commande en ligne en sont de bons exemples. Les règles disent quels passages sont autorisés et lesquels sont interdits.

Pourquoi les machines à états sont-elles utiles en e-commerce ?

Les commandes, paiements, abonnements et retours passent tous par des étapes claires. Une machine à états garantit qu'ils n'avancent que de façon autorisée, ce qui évite des erreurs coûteuses comme expédier une commande impayée, rembourser deux fois ou renouveler un abonnement résilié.

Quelle différence entre une machine à états et un workflow ?

Un workflow décrit une suite de tâches, souvent réalisées par des personnes, comme valider un retour puis le rembourser. Une machine à états décrit les états possibles d'un élément et les transitions autorisées entre eux. Beaucoup d'outils de workflow s'appuient sur des machines à états pour savoir où en est chaque élément.