Checklist go-live

Pourquoi ce chapitre est le plus utile

Les sept chapitres précédents ont donné les outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire pour construire, tester et surveiller un système LLMLLMIAGrand modèle de langage (Large Language Model) entraîné sur d'énormes corpus pour prédire et générer du texte.Voir dans le glossaire : golden set, red-teaming, LLM-as-judgeLLM-as-judgeIAÉvaluation automatisée où un LLM note ou compare des sorties selon des critères définis, souvent en complément de métriques classiques.Voir dans le glossaire, tests de régression, monitoring de production, réponse aux incidents. Ce chapitre les assemble en une décision unique et binaire : peut-on mettre ce système entre les mains d'utilisateurs réels, aujourd'hui, dans cet état ?

Cette décision est souvent prise trop vite, sur la seule impression que « ça marche bien en démo ». Une démo ne teste ni les cas limites, ni la charge, ni la malveillance, ni la dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire dans le temps. Le go-live est le moment où l'ensemble des garanties construites en amont doit être vérifié une dernière fois, formellement, avant que le système ne devienne responsable de décisions ou d'interactions qui engagent l'organisation.

Ce chapitre propose une checklist de sortie structurée en quatre familles de critères, un modèle de gouvernance pour trancher les cas ambigus, et les pièges les plus fréquents observés lors de mises en production précipitées.

Les quatre familles de critères de sortie

Un critère de sortie (« exit criterion ») est une condition mesurable et vérifiable qui doit être satisfaite avant le passage en production. Contrairement à une impression qualitative, il produit un résultat binaire : rempli ou non rempli. Les critères de sortie d'un système LLMgrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire se répartissent en quatre familles.

Qualité fonctionnelle. Le système répond-il correctement aux cas d'usage prévus ? Cette famille s'appuie directement sur le golden set et les seuils de score définis lors des tests de régression. Un score en dessous du seuil convenu bloque le passage, sans négociation de dernière minute.

Robustesse et sécurité. Le système résiste-t-il aux tentatives de contournement, d'injection de promptInjection de promptCybersécuritéAttaque visant à détourner un LLM en insérant des instructions malveillantes dans le contexte (entrée utilisateur, document RAG, etc.).Voir dans le glossaire, d'extraction de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire sensibles ? Cette famille reprend les résultats de la campagne de red-teaming et vérifie que les vulnérabilités critiques identifiées ont été corrigées, pas seulement documentées.

Opérabilité. L'équipe peut-elle observer, diagnostiquer et corriger le système une fois en production ? Cela couvre le monitoring, les alertes, la traçabilité des décisions du modèle et la procédure de réponse aux incidents. Un système qui fonctionne bien mais qu'on ne sait pas surveiller n'est pas prêt.

Gouvernance et conformité. Le système respecte-t-il les obligations légales et internes applicables — protection des données, information de l'utilisateur sur l'usage d'une IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire, droit de recours, documentation des décisions à fort impact ? Cette famille est souvent négligée car elle ne se mesure pas avec un score, mais son absence expose l'organisation à un risque disproportionné par rapport au gain de vitesse obtenu.

Un système qui obtient un excellent score de qualité fonctionnelle mais dont personne ne sait comment il réagira à un pic de trafic ou à une tentative d'extraction de données n'est pas prêt. Les quatre familles doivent être validées ensemble ; une seule ne suffit jamais à justifier la mise en production.

Checklist go-live détaillée

Le tableau suivant reprend les points de contrôle les plus fréquemment omis, classés par famille. Chaque ligne doit avoir un porteur nommé et une preuve vérifiable — un lien vers un rapport, un tableau de bord ou un document — et non une simple case cochée de mémoire.

Une équipe finalise un assistant de support client, golden set au vert, red-teaming sans vulnérabilité critique. Le go-live est bloqué in extremis parce que personne n'a vérifié que l'utilisateur était informé qu'il échangeait avec un système automatisé, une obligation légale dans plusieurs juridictions. Le correctif est trivial une fois identifié, mais son absence en fin de checklist aurait exposé l'organisation à un risque disproportionné par rapport à l'effort de correction.

Le comité de mise en production

Sur un système à fort enjeu, la décision de sortie ne devrait jamais reposer sur une seule personne, et encore moins sur l'équipe qui a construit le système — elle est structurellement la moins bien placée pour juger objectivement de ses propres limites. Un comité de mise en production réunit typiquement :

• Le porteur produit, responsable de la valeur métier et du périmètre fonctionnel couvert.
• Le porteur technique, responsable de la qualité mesurée et de l'opérabilité du système.
• Un représentant sécurité ou conformité, responsable de la famille gouvernance, avec un droit de veto sur les points non négociables (protection des données, obligations réglementaires).
• Un représentant du support ou de la relation client, qui porte la voix de ceux qui géreront les conséquences en cas de problème après le lancement.

Le rôle du comité n'est pas de refaire les tests, mais de vérifier que les preuves existent et sont convaincantes, et de trancher les cas où deux critères entrent en tension — par exemple un excellent score de qualité mais une procédure de rollback jamais testée en conditions réelles.

Il est tentant, sous pression de calendrier, de considérer qu'une majorité du comité favorable au lancement suffit à passer outre une réserve de conformité. Ce raisonnement inverse la hiérarchie des risques : une non-conformité réglementaire ou une fuite de donnéesfuite de donnéesIAErreur consistant à laisser entrer dans l'entraînement une information qui n'existera pas au moment réel de la prédiction. Le modèle affiche des scores excellents puis s'effondre en production.Voir dans le glossaire personnelles a un coût potentiel sans commune mesure avec le coût d'un délai de quelques jours. Le représentant conformité doit disposer d'un veto réel, pas consultatif.

Les trois issues possibles

Un comité de mise en production ne doit pas se limiter à un choix binaire go / no-go. Une troisième issue, souvent la plus utile, est le go conditionnel : le système est mis en production avec un périmètre restreint et des garde-fous supplémentaires, le temps de lever les réserves restantes.

Go — tous les critères des quatre familles sont satisfaits, le système est déployé sans restriction particulière au-delà du plan de montée en charge standard.

Go conditionnel — les critères critiques sont satisfaits, mais un ou plusieurs points mineurs restent ouverts. Le système est déployé avec un périmètre réduit : trafic limité, population d'utilisateurs restreinte, supervision humaine renforcée sur certaines catégories de requêtes, ou fenêtre de service limitée. La date de levée des réserves est fixée explicitement.

No-go — un ou plusieurs critères bloquants ne sont pas satisfaits. Le lancement est reporté, avec un plan d'action daté et des responsables nommés pour chaque point à corriger.

Face à la pression du calendrier, l'alternative « soit on lance tout de suite, soit on décale de plusieurs semaines » est souvent fausse. Un lancement restreint à 5 % du trafic, avec une revue humaine systématique des cas à fort enjeu, permet de commencer à apprendre du comportement réel du système tout en gardant le contrôle sur l'exposition au risque.

Pièges fréquents observés en mise en production

La checklist remplie de mémoire. Une checklist cochée sans preuve documentée n'a aucune valeur de contrôle ; elle donne seulement une fausse impression de rigueur. Chaque point doit renvoyer vers un artefact daté et consultable.

Le red-teaming exécuté sur une version antérieure. Entre la campagne de tests offensifs et le lancement, le prompt système, le modèle sous-jacent ou la base de connaissances ont souvent changé. Une vulnérabilité corrigée sur une version peut réapparaître sur la suivante si le changement n'a pas été retesté.

L'absence de plan de rollback testé. Documenter une procédure de retour arrière ne suffit pas : il faut l'avoir exécutée au moins une fois en amont, dans un environnement représentatif, pour vérifier qu'elle fonctionne réellement sous pression et dans les délais annoncés.

Le monitoring configuré mais jamais déclenché volontairement. Une alerte qui n'a jamais été testée en conditions réelles peut échouer silencieusement — mauvais seuil, mauvais canal de notification, filtre trop restrictif. Un exercice de déclenchement volontaire avant le lancement permet de vérifier la chaîne complète, de la détection à la notification de l'astreinte.

La confusion entre performance en démonstration et performance en production. Un système testé sur des requêtes soigneusement choisies par l'équipe qui l'a construit se comporte presque toujours mieux que face au trafic réel, plus varié et parfois hostile. Le golden set doit refléter la diversité réelle attendue, pas seulement les cas qui mettent le système en valeur.

Après le lancement : le go-live n'est pas une ligne d'arrivée

La checklist de sortie protège le moment du lancement, mais un système LLM continue d'évoluer après sa mise en production : dérive du modèle côté fournisseur, évolution du trafic réel, nouveaux cas d'usage détournés qui n'existaient pas au moment des tests. Trois pratiques prolongent la logique du go-live dans la durée.

Une revue de sortie à échéance fixe. Trente jours après le lancement, rejouer une version allégée de la checklist — en particulier la famille qualité fonctionnelle et opérabilité — avec les données réelles de production, pas seulement celles du golden set initial.

Un registre des dérogations. Chaque point de la checklist accepté en go conditionnel doit être consigné avec sa date de résolution prévue. Un registre non suivi transforme silencieusement des dérogations temporaires en dette permanente.

Un rituel de retrait. Symétriquement au go-live, un système qui n'atteint plus ses critères de qualité en production, ou dont les incidents dépassent un seuil convenu, doit pouvoir être retiré ou repassé en mode restreint selon une procédure aussi formelle que celle de son lancement. L'absence de critère de retrait explicite conduit souvent à laisser tourner un système dégradé faute de décision claire.

Une checklist de sortie n'est pas un document figé. Chaque incident post-lancement documenté dans le chapitre sur la réponse aux incidents devrait, s'il révèle un angle mort, se traduire par un nouveau point de contrôle ajouté à la checklist pour les lancements suivants. C'est ce mécanisme de rétroaction qui rend la checklist réellement protectrice avec le temps, plutôt qu'une formalité qui se contente de reproduire les mêmes lacunes à chaque projet.

Checklist opérationnelle de synthèse

Avant toute présentation au comité de mise en production, vérifier que chacun des points suivants dispose d'un porteur nommé et d'une preuve datée :

1. Golden set exécuté sur la version exacte destinée au déploiement, seuils respectés.
2. Campagne de red-teaming — rejouée après le dernier changement de prompt ou de modèle.
3. Tableau de bord de monitoring actif et testé, avec au moins une alerte déclenchée volontairement.
4. Procédure de rollback documentée et exécutée au moins une fois en conditions représentatives.
5. Astreinte identifiée avec périmètre de responsabilité et moyens de contact vérifiés.
6. Information utilisateur sur le caractère automatisé du système validée juridiquement.
7. Voie de recours humain documentée pour les décisions contestées.
8. Registre des dérogations initialisé pour tout point accepté en go conditionnel.
9. Date de revue post-lancement fixée avant le jour du lancement, pas après.

Cette checklist ferme la boucle ouverte au premier chapitre de cette formation : construire un système LLM fiable ne s'arrête pas à la mesure de sa qualité, cela suppose une gouvernance capable de décider, sur preuves, du moment où ce système peut être exposé à des utilisateurs réels — et du moment où il doit en être retiré.