Une démonstration est un chemin choisi à travers un système. Il est sélectionné parce qu’il fonctionne. Ce n’est pas malhonnête — c’est la fonction même d’une démonstration — mais cela signifie qu’elle ne vous apprend presque rien sur la capacité du système à survivre à un mardi ordinaire.
Où se situe réellement le travail
D’après notre expérience, le modèle est rarement la partie difficile. Les difficultés sont dans les interstices : que se passe-t-il quand l’entrée est malformée, quand l’API amont est lente, quand deux enregistrements se contredisent, quand le score de confiance est de 0,61 et que personne n’a jamais décidé de ce que 0,61 signifie.
- Modes dégradés — ce que fait le système lorsqu’une dépendance est indisponible
- Seuils de confiance — convenus à l’avance, non découverts en production
- Escalade humaine — qui voit l’exception, et avec quel contexte
- Plafonds de coût — par action, par client, par jour
- Détection de dérive — car la précision que vous avez mesurée n’est pas permanente
Mesurer avant d’automatiser
Nous ne démarrons pas une mission d’automatisation sans référence de départ. Non par souci de procédure, mais parce que sans elle, rien ne distingue le succès de l’activité. Si le processus manuel prenait un temps inconnu et produisait un nombre d’erreurs inconnu, toute affirmation d’amélioration ultérieure n’est qu’une supposition.
Automatiser sans référence de départ, c’est deviner en costume.
La référence protège aussi le client contre nous. C’est le mécanisme qui permet de juger qu’une mission a échoué — et un prestataire qui ne peut pas échouer est un prestataire à qui l’on ne peut rien opposer.