Détecter les bugs de reprise avant d’écrire le logiciel

Un traitement qui vérifie « déjà fait ? », exécute une action puis enregistre son résultat paraît simple. Pourtant, une panne entre ces étapes ou deux exécutions concurrentes peuvent faire disparaître l’action ou la déclencher deux fois. Il est possible de chercher ces défauts avant d’avoir le logiciel : décrivez les étapes, les états et les situations d’échec, puis vérifiez si les règles métier tiennent dans chacun des parcours possibles.

Dans sa présentation sur les méthodes formelles, Hillel Wayne explique sur InfoQ comment raisonner sur un système encore décrit sur le papier. La démarche ci-dessous reprend cette idée à hauteur de cadrage : elle ne requiert pas de commencer par un outil mathématique, mais elle demande de rendre explicites les règles et les hypothèses.

1. Décrire l’engagement métier, pas seulement le traitement

Commencez par nommer l’action qui compte réellement pour l’entreprise : expédier une commande, réserver un créneau, créer un dossier ou déclencher un paiement. Distinguez ensuite ce que le logiciel enregistre de ce qui se produit dans le monde extérieur. Une ligne marquée « terminée » est un état informatique ; un colis remis au transporteur ou un rendez-vous effectivement réservé est un effet métier. Les deux ne changent pas nécessairement au même instant.

Hillel Wayne présente une propriété comme une condition qui doit être vraie du système. Pour une action métier, deux formulations aident à faire émerger les risques : ne jamais effectuer l’action plus d’une fois et finir par l’effectuer au moins une fois. La première protège contre un doublon ; la seconde contre une action perdue. Dans le vocabulaire de sa présentation, éviter un mauvais événement relève de la sûreté, tandis que garantir qu’un événement souhaité arrive relève de la vivacité.

Ces règles doivent être précises pour être vérifiables. « Le traitement doit être fiable » ne dit pas ce qui est interdit ou obligatoire. « Une commande confirmée ne doit pas produire deux expéditions » et « une commande acceptée doit finir par être expédiée ou signalée en erreur » donnent des critères à discuter avec le métier. Le deuxième énoncé prévoit aussi une issue visible : rester bloqué sans signal ne satisfait pas le besoin.

2. Mettre au jour les reprises et les courses

Un scénario de réussite ne suffit pas. Pour chaque opération, demandez ce qui se passe si le service s’arrête juste avant ou juste après l’effet métier, si une réponse se perd, ou si une relance part alors qu’une première exécution n’a pas encore fini. Considérez également deux travailleurs qui prennent la même tâche presque au même moment. Ce sont des possibilités à examiner, pas des incidents que l’on prétend avoir observés dans votre système.

Wayne illustre le problème avec un traitement qui marque une tâche comme faite avant d’accomplir l’action. Si l’action échoue, la reprise voit la marque et peut conclure à tort que le travail est terminé. Inverser l’ordre n’écarte pas nécessairement le risque : si l’action réussit mais que l’enregistrement ne se fait pas, une relance peut la refaire.

Enfin, deux exécutions peuvent toutes deux agir avant que l’une d’elles n’enregistre la fin. Changer l’ordre des instructions ne répond donc pas, à lui seul, à toutes les situations.

Voici une chronologie courte pour organiser la revue d’un traitement asynchrone. Elle sert de support de discussion, pas de preuve que toutes les pannes possibles ont été couvertes.

1. Déclenchement : qui peut demander l’action, et une même demande peut-elle arriver plusieurs fois ?

2. Exécution : quel effet métier se produit, et quelles étapes peuvent échouer séparément ?

3. Enregistrement : quand le système considère-t-il le travail terminé, et que signifie réellement cette marque ?

4. Reprise : que relance-t-on après une erreur ou un délai, et que se passe-t-il si le premier traitement continue ?

5. Résolution : comment reconnaître une action perdue, répétée ou toujours en attente, et qui décide de la suite ?

3. Réduire le problème à quelques états utiles

Pour éviter de débattre d’une architecture entière, construisez une représentation minimale. Wayne propose de suivre l’étape de l’algorithme, la valeur du marqueur « terminé » et le nombre de fois où l’action a été exécutée. Pour une première revue, ces éléments obligent à séparer la position du traitement de son effet réel. Si le besoin comporte une autre contrainte déterminante, comme une échéance ou un statut d’annulation, ajoutez-la ; n’ajoutez pas des détails qui ne changent aucune règle étudiée.

Dans sa modélisation, les variables internes au logiciel et les effets extérieurs n’ont pas le même statut : l’équipe peut concevoir le marqueur, mais elle ne peut pas effacer un envoi déjà réalisé. Cette distinction aide à repérer les solutions qui ne font que corriger l’affichage d’un état sans annuler la conséquence métier. Avant de promettre une « remise à zéro », demandez donc si l’effet est réellement réversible et qui en a la responsabilité.

Quand plusieurs suites sont possibles depuis un même état, explorez-les toutes : réussite, échec, reprise et exécution simultanée. L’ensemble des états et des passages possibles forme l’espace d’états. En pratique, un tableau ou un schéma simple peut suffire pour une première revue d’équipe ; l’enjeu est de ne pas s’arrêter au parcours nominal. Si le système comporte beaucoup d’interactions ou si l’impact d’un défaut est élevé, une vérification plus formelle peut ensuite être justifiée.

4. Transformer les scénarios en livrables vérifiables

Un cadrage utile laisse des éléments que le métier, l’équipe technique et le prestataire peuvent relire ensemble. Le tableau ci-dessous associe chaque risque à une question et à une trace attendue. Ce sont des propositions de livrables à adapter au processus concerné, pas des garanties qu’un document isolé éliminera les défauts.

Le coût du cadrage dépend notamment du nombre de règles métier, d’états et d’interactions à examiner, ainsi que du niveau de preuve demandé. Il faut aussi prévoir le temps des personnes capables de confirmer les conséquences acceptables d’un doublon, d’un retard ou d’une annulation.

Sans ces décisions, l’équipe technique risque de devoir choisir seule une règle qui appartient au métier. Pour aller plus loin sur les choix de rejeu et d’idempotence après ce premier cadrage, consultez notre guide sur la conception de traitements asynchrones rejouables.

5. Savoir ce que cette revue ne démontre pas

Un modèle simple ne couvre que les états et les règles qu’on lui a donnés. Il ne prouve donc pas que le logiciel final est sans défaut, ni que l’environnement, les dépendances ou les comportements réels correspondent à toutes les hypothèses.

Dans sa présentation, Wayne souligne l’intérêt de chercher une erreur dans une abstraction tôt, tout en précisant que cette approche n’est pas parfaite. Un défaut trouvé dans un modèle constitue un signal fort à traiter ; l’absence de défaut dans un petit modèle reste limitée à ce qui y a été représenté.

Avant de développer ou de confier le travail, demandez que les hypothèses, les propriétés attendues, les scénarios d’échec et les limites de la revue soient consignés. Vous pourrez ensuite décider si une représentation manuelle suffit, si des tests ciblés sont nécessaires ou si une vérification plus rigoureuse vaut son coût. Le bon résultat du cadrage n’est pas une promesse d’absence de panne : c’est une règle métier explicite, des risques discutés et des critères que l’équipe pourra réellement vérifier.