Pourquoi les pilotes s'arrêtent
Un pilote est optimisé pour montrer qu'une capacité est possible. Il fonctionne sur des exemples choisis, en présence de ses auteurs, et il est jugé sur l'impression. Ce sont précisément ces conditions qu'une opération de production supprime. En production, les entrées sont adverses et illimitées, aucun auteur ne surveille, et le système est jugé sur son pire comportement, pas sur le meilleur.
Les pilotes s'arrêtent donc non pas parce que le modèle s'est dégradé, mais parce que les questions ont changé. « Peut-il faire cela ? » devient « Pouvons-nous en dépendre, le prouver, et récupérer quand il échoue ? » Un pilote a rarement une réponse à ce second ensemble, car il n'a jamais été construit pour cela.
Ce qu'un pilote prouve, et ce qu'il ne prouve pas
Un bon pilote prouve qu'une capacité existe et qu'un flux de travail est plausible. Il ne prouve pas la fiabilité sous un changement de distribution, le comportement face à des entrées adverses, le coût et la latence à volume, ou l'échec sûr. Traiter le premier comme s'il était le second est la raison la plus fréquente pour laquelle le travail d'IA n'atteint pas la production — ou l'atteint alors qu'il n'aurait pas dû.
Les six éléments que la production ajoute
Franchir l'écart signifie concevoir ce que le pilote a omis :
- Évaluation. Jeux de données, métriques et seuils définis, mesurés avant la mise en service et surveillés après — pas une impression ponctuelle.
- Contrôles. Une limite autour du modèle : permissions restreintes, actions sur liste blanche, vérifications de politique, et une porte humaine sur les actions conséquentes.
- Observabilité. Traces, métriques et journaux respectueux de la confidentialité, afin qu'une régression soit visible avant de devenir un incident.
- Récupération. Nouvelles tentatives, dégradation élégante vers un chemin manuel, mise en file d'attente morte pour les cas empoisonnés, et un chemin de retour documenté vers un bon état.
- Autorité humaine. Propriété claire des décisions conséquentes, et la capacité de passer outre, enregistrée.
- Propriété. Quelqu'un responsable du système en exploitation, avec la capacité de l'exécuter, de le modifier et de le retirer.
L'évaluation est une boucle, pas une porte que l'on franchit une fois
Le changement le plus important est de traiter l'évaluation comme continue. Une version est mesurée par rapport à des jeux de données et des métriques, doit franchir une porte d'acceptation avec des seuils fixés à l'avance, et ce n'est qu'alors qu'elle fonctionne — sous une surveillance qui observe les mêmes métriques. Les résultats opérationnels alimentent la prochaine amélioration, qui est à nouveau évaluée avant d'être acceptée.
Boucle d'évaluation
Description textuelle de ce diagramme
L'évaluation est une boucle, pas une validation ponctuelle. Une version est mesurée par rapport à des jeux de données et des métriques définis, puis doit franchir un point d'acceptation dont les seuils sont fixés à l'avance. Ce n'est qu'alors qu'elle fonctionne — sous une surveillance qui observe la qualité, le coût, la latence et les dérogations humaines.
Les résultats opérationnels reviennent alimenter l'amélioration suivante, et le système modifié est réévalué avant d'être accepté. Les jeux de données, les métriques et les seuils sont exposés dans la spécification de menace, d'évaluation et d'acceptation.
Une liste de contrôle de préparation à la production
Avant qu'un système n'obtienne l'autorité opérationnelle, ces questions devraient avoir de vraies réponses :
- Que mesure-t-on, sur quelles données, et quel seuil doit-il franchir ?
- Comment se comporte-t-il face à des entrées adverses et hors distribution ?
- Quelle est la pire action qu'il puisse entreprendre, et qu'est-ce qui l'arrête ?
- Comment une défaillance est-elle détectée, et quel est le chemin de retour ?
- Qui est responsable d'une décision conséquente ?
- Qui en est propriétaire en exploitation, et peut-il le modifier et le retirer ?
Où cela se réalise, et ses limites
Le système gouverné d'opérations de dossiers est construit autour de cette boucle, et sa spécification de menaces, d'évaluation et d'acceptation énonce intégralement les jeux de données, métriques et critères. Cette publication argumente ce que la préparation à la production exige ; elle ne rapporte pas de métriques de production pour un déploiement quelconque, et chaque opération doit définir ses propres seuils avec ses responsables.