Pourquoi la plupart des projets d'automatisation n'arrivent jamais en production
Automatiser le happy path est souvent facile. La production commence quand le système doit gérer tout ce qui se passe autour.
La plupart des projets d'automatisation commencent par un moment satisfaisant.
Quelque chose qui était manuel commence à se produire tout seul. Une tâche s'exécute sans intervention. Une règle fonctionne correctement. Le système produit le résultat attendu.
Cette première version peut donner l'impression d'être proche de la ligne d'arrivée.
En réalité, ce n'est généralement que le début.
Le happy path n'est que le début
Automatiser le happy path est souvent plus facile que rendre l'automatisation fiable.
La première version suppose que les entrées sont valides, que les services externes répondent correctement, que le timing est raisonnable et que chaque étape précédente s'est terminée comme prévu. Ces hypothèses sont utiles pour prouver une idée, mais elles survivent rarement à la production.
Les vrais systèmes rencontrent des données manquantes, des réponses retardées, des échecs partiels, des rate limits, des redémarrages et des erreurs utilisateur.
La partie difficile n'est pas de faire fonctionner l'automatisation une fois. La partie difficile est de la faire se comporter correctement quand les conditions sont imparfaites.
La production demande du travail peu spectaculaire
Beaucoup de projets d'automatisation n'arrivent jamais en production parce que le travail restant semble moins excitant que le prototype.
Validation, permissions, observabilité, logique de retry, récupération d'état et gestion claire des erreurs ne créent pas la même sensation que le premier automatisme qui réussit.
Mais ce sont ces éléments qui transforment un workflow intelligent en système utilisable.
Sans eux, l'automatisation peut fonctionner techniquement, tout en restant trop fragile pour porter une vraie responsabilité.
La confiance est une exigence
L'automatisation change la relation de l'utilisateur au logiciel.
Quand un outil suggère seulement une action, l'utilisateur garde le contrôle. Quand un système agit automatiquement, la confiance devient une exigence. L'utilisateur doit comprendre ce que le système fait, quand il s'arrête et ce qui se passe si quelque chose tourne mal.
C'est particulièrement vrai dans le trading.
Un système connecté à du capital ne peut pas s'appuyer sur un comportement vague. Il a besoin de limites claires et de réponses prévisibles, même quand le marché ou l'infrastructure ne coopère pas.
Le prototype cache la vraie portée
La première version d'un projet d'automatisation cache souvent la quantité de travail restante.
Elle prouve que l'idée centrale est possible, mais pas que le système autour est prêt. Les pièces manquantes ne deviennent généralement visibles que lorsque le logiciel est censé fonctionner en continu.
C'est cet écart qui explique pourquoi beaucoup de projets stagnent.
La partie intéressante est terminée, mais la partie responsable vient à peine de commencer.
Avec le recul
Construire Oblivion a rendu cette leçon très concrète.
Le trading automatisé ne consiste pas seulement à faire exécuter une stratégie. Il consiste à s'assurer que le système peut continuer à fonctionner, récupérer après les problèmes et protéger les utilisateurs des hypothèses cachées dans le code.
La production commence quand l'automatisation doit gérer tout ce qui existe autour du happy path.