Chaque mission Tzar.Tech se termine par 60 jours de recouvrement on-call. Les deux équipes — la nôtre et celle du client — partagent le pager. Au départ nous y voyions un geste de bonne volonté. Cela s'est avéré être la phase la plus importante de la mission.
Voici pourquoi.
Ce que la suite d'evals ne rattrape pas
La suite d'evals rattrape ce que vous avez pensé à tester. Par définition, elle ne rattrape pas ce que vous n'avez pas pensé.
Pour la plupart des systèmes à base d'agents IA livrés en production, les 60 premiers jours font remonter :
- Des entrées que personne n'avait anticipées. Un utilisateur upload un PDF de 400 pages en bulgare. Un client appelle l'endpoint avec des guillemets HTML-échappés. Une intégration envoie des timestamps en microsecondes.
- Des hypothèses de fréquence qui étaient fausses. Un chemin « rare » s'avère représenter 8 % du trafic. Un chemin « courant » s'avère être à 0,1 %.
- Une latence de queue que la charge des evals ne reproduisait pas. Le p99 a l'air bon à 100 RPS en load test ; à 250 RPS en production, le p99.9 explose à cause d'un pool de connexions dimensionné pour la mauvaise distribution.
- Des comportements de coût qui émergent sous de vrais prompts. Les vrais utilisateurs formulent les questions de manières qui triplent le compte de tokens du prompt par rapport à vos prompts d'eval synthétiques.
Cela n'apparaît dans aucune suite d'evals bien conçue, parce que la suite d'evals est un modèle de ce que vous savez. Les 60 premiers jours, c'est quand le système rencontre la réalité.
Ce que le recouvrement on-call fait vraiment
Deux choses, toutes deux importantes :
1. L'équipe qui part est encore branchée quand ça va mal. Quand le nouveau symptôme apparaît, l'ingénieur qui connaît le code est sur l'appel. Pas dans un canal Slack à deux fuseaux horaires — réellement pagé, en train de chercher activement. Le fix est livré au lieu de devenir un ticket.
2. L'équipe qui reçoit apprend les modes de défaillance dans son propre contexte. Elle est pagée. Elle parcourt le runbook (voir le runbook livré avec chaque agent). Elle escalade vers nous quand nécessaire. Chaque incident devient un exercice guidé d'opération du système, avec les auteurs originaux sur la ligne.
D'ici le jour 60, l'équipe qui reçoit a traité assez d'incidents pour savoir ce qui est difficile, ce qui est facile, ce qu'il faut ignorer, et ce qui vaut la peine de pager un exécutif.
Ce que nous ne faisons pas
Nous ne sommes pas on-call primaire. Nous sommes secondaires pendant le recouvrement. L'équipe du client possède le système. Notre rôle, c'est « l'on-call senior qui peut répondre à “est-ce normal ?” et à “quel est le chemin sûr ici ?” ».
C'est important : si nous tenions le primaire, l'équipe du client ne développerait jamais le réflexe. Elle nous pagerait en premier, à chaque fois, et au jour 60 elle serait encore dépendante. Le recouvrement est une fenêtre d'apprentissage, pas un service.
Ce que disent les données
Nous avons gardé des stats sur ce point à travers les missions. La forme est consistante :
- Deux premières semaines : environ la moitié des pages nous parviennent. La plupart sont des clarifications, pas de vrais incidents.
- Semaines 3–4 : environ un quart nous parviennent. L'équipe du client a intériorisé les diagnostics courants.
- Semaines 5–8 : moins de 10 % nous parviennent. Ceux qui le font sont de vrais nouveaux modes de défaillance qui valent un changement de code.
Après 60 jours, la mission médiane nous fait pager une fois par mois pour le trimestre suivant, et quasiment jamais après. Le système est à eux.
Pourquoi 60 jours, pas 30
On a essayé 30 une fois. Ce n'était pas suffisant.
Plusieurs modes de défaillance n'apparaissent qu'aux bornes de mois (cycles de facturation, batchs mensuels, charges de reporting de fin de trimestre). Un recouvrement de 30 jours peut se terminer sans jamais les rencontrer, laissant l'équipe du client aveugle à une catégorie de problèmes qui arrivera, tôt ou tard, sans senior de secours à appeler.
60 jours rattrape les défaillances aux bornes de mois et donne à l'équipe qui reçoit un second mois plein pour les gérer seule avec nous en backup. Ce n'est pas symétrique et ce n'est pas arbitraire — c'est ce que nous avons trouvé suffisant pour transférer réellement la propriété.
Combien ça coûte et pourquoi nous le faisons
Soixante jours d'on-call secondaire, c'est du vrai temps d'ingénierie que nous ne facturons pas séparément. Nous l'intégrons au prix de la mission. Certains clients ne nous croient pas quand nous disons que c'est obligatoire — nous insistons quand même, et ceux qui essaient de sauter cette étape nous rappellent en général au deuxième mois pour nous demander de revenir comme consultants.
Nous préférons rester 60 jours la première fois.