Contexte et rupture des hypothèses classiques

Les systèmes d’entreprise traditionnels reposent sur trois postulats : les jobs s’exécutent en quelques millisecondes, les tentatives de ré‑exécution sont pratiquement gratuites et un même jeu d’entrée produit toujours la même sortie. Les workloads dits agentic, c’est‑à‑dire pilotés par des modèles d’IA capables de prendre des décisions autonomes, invalident ces trois points. Un agent peut rester actif plusieurs minutes, dépasser les seuils de timeout que les piles logicielles n’ont jamais rencontrés, et ainsi provoquer des échecs que les équipes de support ne voient pas immédiatement.

Mécanismes qui augmentent les coûts et les délais

Dans un environnement facturé à l’usage, chaque appel d’API ou chaque token consommé génère une dépense, même si le résultat est rejeté. Le texte indique que les boucles d’IA autonomes « retry » les tâches échouées sans supervision, ce qui transforme une logique de retry « gratuit » en un facteur de coût important. Le modèle de facturation mensuel, typique des fournisseurs cloud, ne révèle ces dépenses qu’au moment de la facturation, parfois plusieurs semaines après l’incident. L’article cite un scénario où un planificateur lance 400 exécutions nocturnes, chaque tentative consommant des ressources, ce qui fait exploser la facture sans que personne ne l’ait anticipé.

Absence de reproductibilité et risques associés

Le troisième changement majeur concerne la non‑déterminisme : sans trace détaillée des décisions de l’agent, des appels d’API et des prompts, il devient impossible de reproduire une défaillance. Les équipes ne peuvent plus relancer un test en espérant obtenir le même résultat, ce qui rend les investigations purement spéculatives. Deux types d’incidents sont soulignés : d’une part, des sorties qui semblent structurellement correctes mais contiennent des données erronées, échappant aux systèmes de monitoring classiques ; d’autre part, des incidents dont aucune information (version du modèle, paramètres, horodatage) n’est disponible, rendant toute auditabilité quasi impossible.

Recommandations d’ingénierie et bonnes pratiques

Pour maîtriser ces risques, l’auteur propose cinq axes d’interrogation : définir des critères d’acceptation explicites avant chaque exécution, plafonner le nombre moyen de tentatives par unité de travail, enregistrer systématiquement l’entrée brute, le prompt, la version du modèle, le temps d’exécution, le nombre de retries, le coût en tokens et le résultat final, désigner clairement les responsables d’approbation et tester chaque mise à jour de modèle dans un environnement de staging. La consolidation des artefacts – prompts, logs, approbations – dans un espace de travail unique est présentée comme une discipline plutôt qu’une simple décision produit. En appliquant ces mesures, les équipes peuvent transformer les workflows agentiques d’un état de « boîte noire » à une chaîne observable, limitant les coûts invisibles et rétablissant la capacité de reproduire les scénarios de test.