La réaction naturelle à un incident, c'est d'automatiser la détection. L'idée nous est venue dans l'heure : un agent qui surveille les échéances et nous prévient à l'avance.
Nous ne l'avons pas construit.
Le processus comptait trois couches, et nous étions sur le point d'automatiser la troisième. La première, c'est le renouvellement automatique avec un moyen de paiement valide. La deuxième, un registre écrit de ce qui expire et quand. La troisième, une sonde qui vérifie. Un agent qui vous prévient de quelque chose qui pouvait se renouveler tout seul, ce n'est pas de l'automatisation : c'est du théâtre coûteux monté par-dessus un processus brisé.
Ce que nous avons fait à la place : réparer la première couche — c'est là qu'était la véritable défaillance —, écrire la deuxième dans un fichier, et ajouter la troisième sous forme de quelques lignes dans une vérification qui existait déjà.
La part inconfortable : nous vendons la refonte des processus par l'IA, et notre premier réflexe a été de coller un agent sur un problème qu'une carte de paiement valide réglait. La tentation d'automatiser est la plus forte juste après un échec, parce que construire quelque chose donne l'impression de réparer quelque chose.
Éliminer avant d'automatiser. Et avant d'éliminer, trouver quelle couche fait réellement défaut.
Nous raconterons l'incident au complet dans quelques semaines.