- Contexte
- Comités de validation conclus sur une démo réussie, décision prise en séance
- Constat
- Une démo prouve que le système peut fonctionner, pas qu’il est sous contrôle
- Pour qui
- Décideur en comité de mise en production, CTO, responsable plateforme
- Preuve
- Retour d’expérience de comités — aucun client identifiable
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.
Ce que la démo ne dit pas
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é
La bonne question, en comité, n’est 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 ? »
Quand les 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.
Vérifier ce point dans votre environnement
Les questions à poser avant le go-liveCinq questions simples, dont la réponse doit être observée — pas déclarée. Si l’une d’elles reste sans réponse mesurée, elle définit le travail restant.
- La passerelle peut-elle être contournée ? Qui a tenté l’appel direct au modèle, et qu’a-t-il obtenu ?
- Un appel non authentifié atteint-il le modèle ? Le refus a-t-il été observé, ou seulement configuré ?
- Le plafond de coût par tâche existe-t-il vraiment — ou seulement le quota mensuel, qui se constate après coup ?
- Une entrée piégée modifie-t-elle le comportement de l’agent ? Quel test l’a montré ?
- Peut-on retracer une action de l’utilisateur jusqu’au résultat métier, sur une exécution réelle ?
Ce que cela change à l’échelle d’un grand compte
- La démo est un artefact de conviction, pas un artefact de décision. Un comité qui décide sur une démo décide sur le cas nominal. Les incidents, eux, arrivent hors du cas nominal — c’est leur définition.
- Le dossier de mise en production doit contenir des mesures datées. Cinq réponses observées, avec leur méthode de reproduction, pèsent plus qu’un support de présentation — et restent opposables six mois plus tard, quand plus personne ne se souvient de la réunion.
- Le non-déterminisme aggrave l’écart. Sur un système IA, deux exécutions identiques peuvent diverger. L’écart entre « ça a marché en démo » et « c’est sous contrôle » y est structurellement plus large que sur du logiciel classique — et mérite donc plus de preuve, pas moins.
Frontière de preuveRetour d’expérience. Ce texte s’appuie sur des comités de validation observés au fil de missions passées, sans qu’aucun client ne soit identifiable. Les cinq questions proposées sont génériques : leur pertinence exacte dépend de votre architecture, et leur réponse ne peut venir que de mesures conduites sur votre propre système. Ce texte ne décrit pas un incident précis et ne constitue pas une statistique.
Si votre prochain comité approche et que les cinq réponses n’existent pas encore, c’est précisément le périmètre d’un sprint de preuve : dix jours, lecture seule, réponses mesurées.