J’ai vu beaucoup de comités de validation se terminer sur une démo réussie. L’agent répond bien, le cas d’usage est convaincant, tout le monde applaudit, et la décision de mise en production est prise dans la même réunion.
Une démo prouve une seule chose : que le système peut fonctionner, dans les conditions que le démonstrateur a choisies.
Elle ne dit rien de ce qui arrive quand les conditions ne sont plus choisies. Quand l’entrée n’est pas celle du script. Quand le document lu contient une instruction cachée. Quand l’appel arrive sans identité valide. Quand une boucle de raisonnement multiplie la consommation par vingt. Quand un outil est appelé par un chemin que personne n’avait modélisé.
Ce sont exactement les situations où l’on découvre l’écart entre la configuration déclarée et le comportement réel. Et cet écart, on ne le trouve pas en regardant le tableau de bord : le tableau de bord est vert, c’est bien le problème.
La bonne question, en comité, n’est donc pas « est-ce que ça marche ? ». Tout le monde vient de le voir. La bonne question est : « qu’avez-vous mesuré, et que pouvez-vous montrer ? »
Concrètement, ça veut dire disposer, avant le go-live, de réponses observées à quelques questions simples : la passerelle peut-elle être contournée ? Un appel non authentifié atteint-il le modèle ? Le plafond de coût par tâche existe-t-il vraiment, ou seulement le quota mensuel ? Une entrée piégée modifie-t-elle le comportement de l’agent ? Peut-on retracer une action de l’utilisateur jusqu’au résultat métier ?
Quand ces réponses existent et sont documentées, la décision devient défendable : GO, GO conditionnel ou NO-GO. Quand elles n’existent pas, ce n’est pas une décision. C’est un pari, pris collectivement, sur la foi d’une démonstration.