Exécution d'outils
La mécanique sans éclat qui rend les gestes d'un agent sécuritaires : chaque appel d'outil a une limite de temps, une façon prudente de réessayer, et la garantie qu'il ne peut pas arriver deux fois par accident.
Vous avez déjà hésité au-dessus d'un bouton de paiement quand la page a figé — recliquer, c'est peut-être payer deux fois. Les bons systèmes de caisse rendent ça impossible : pesez sur le bouton autant de fois que vous voulez, vous êtes facturé une fois. L'exécution d'outils donne cette même garantie à chaque geste d'un agent.
Le problème, en mots simples
Un agent dit à un outil d'émettre un remboursement. Le réseau hoquette en plein appel. Le remboursement est-il passé ? Si l'agent réessaie, le client est peut-être remboursé deux fois. S'il ne réessaie pas, le client n'a peut-être jamais été remboursé du tout. Multipliez ce dilemme par chaque geste que vos agents posent, chaque jour, et « l'agent l'a fait deux fois » ou « l'agent a planté à mi-chemin » cesse d'être un détail technique — ça devient un problème visible par les clients, avec votre nom dessus.
Ce que nous mettons en place
Chaque appel porte une clé d'idempotence — un numéro de reçu unique dérivé du travail lui-même : si la même requête arrive deux fois, le système reconnaît le reçu et n'exécute l'action qu'une seule fois. Chaque outil a une limite de temps explicite, pour que rien n'attende éternellement. Les réessais sont bornés et espacés par un recul exponentiel (attendre un peu plus longtemps entre chaque tentative au lieu de marteler un système en difficulté). Chaque point d'appel déclare son plan d'échec d'avance — réessayer, remonter à un humain, ou stationner le travail dans une file des rebuts (un enclos d'attente pour le travail échoué, pour que rien ne disparaisse en silence). Et chaque tentative se rattache à son parent dans la trace, pour qu'un appel réessayé se lise comme une seule histoire au lieu de fragments éparpillés.
Comment ça fonctionne, étape par étape
- Chaque geste reçoit un numéro de reçu
La clé d'idempotence fait que la même requête arrivée deux fois est exécutée une fois. Réessayer devient sécuritaire par construction.
- Chaque appel a une limite de temps
Un outil coincé déclenche le délai au lieu de geler tout le workflow.
- Les réessais sont prudents, pas frénétiques
Un nombre borné de tentatives, chacune plus espacée que la précédente — on relâche la pression sur un système en difficulté au lieu d'en rajouter.
- Chaque appel connaît son plan B
Déclaré d'avance : réessayer, remettre à un humain, ou stationner dans la file des rebuts. L'échec est un plan, pas une surprise.
- Rien ne disparaît en silence
Le travail qui échoue pour de bon attend un humain dans l'enclos — il ne s'évapore jamais.
- Toute l'histoire tient sur un fil
Chaque réessai se relie à l'appel d'origine dans la trace : une enquête lit une seule ligne du temps, pas des confettis.
Ce qui change pour vous
Avant : un délai dépassé était un vrai dilemme — réessayer et risquer de doubler le geste, ou s'abstenir et risquer que rien ne soit arrivé — et un plantage à mi-chemin voulait dire un ménage manuel par la personne qui le remarquait. Après : les réessais sont sécuritaires, les plantages sont récupérables, le travail échoué attend visiblement un humain, et l'infrastructure cesse d'être une source de rapports d'incident. Ce qu'il ne fera pas : il rend les gestes sécuritaires à exécuter et à répéter — il ne juge pas si un geste devrait se produire. Cette décision appartient aux permissions et aux approbations humaines.