La plupart des automatisations meurent au troisième mois

Les projets d'automatisation ratés ont une forme reconnaissable. La construction se passe bien. La démo plaît. Ça tourne quelques semaines. Puis un format change en amont, le traitement échoue en silence, quelqu'un remarque une semaine plus tard que les chiffres sont faux, et l'équipe revient discrètement à l'ancien tableur pendant qu'un ticket est ouvert et que personne ne le prend.

Le système est toujours là. Il n'est simplement plus utilisé, et à la longue plus personne ne se souvient qu'il existe. Sur le papier, le projet a été livré. En pratique, il a acheté trois semaines de répit.

Presque rien de tout cela n'est un problème de qualité de construction. C'est un problème de responsabilité. L'agence qui l'a construit est passée à un autre client, l'équipe interne ne l'a jamais complètement compris, et ce qui l'aurait sauvé, que quelqu'un repère la panne en une heure plutôt qu'en une semaine, n'était le travail de personne.

Les remèdes sont peu spectaculaires. Des alertes qui atteignent un humain dont on attend une réponse, et non un canal que personne ne lit. Des runbooks écrits pour quelqu'un qui n'a pas construit le système. Un responsable nommé, encore joignable au sixième mois. Des modes de défaillance qui s'arrêtent bruyamment au lieu de continuer avec de mauvaises données, car une panne partielle silencieuse fait bien plus de dégâts qu'une panne franche.

C'est en grande partie pour cela que nous restons intégrés et exploitons ce que nous construisons. Non parce que les clients en seraient incapables, mais parce que le transfert est l'endroit où ces projets meurent d'ordinaire, et savoir que c'est nous qui serons alertés nous fait construire autrement dès le départ.