Mettre un système IA en production : dossier de lancement et critères d’arrêt

Le POC qualifie correctement les demandes SAV de démonstration. L’équipe ouvre l’outil au support, puis découvre une file de propositions que personne n’a le temps de vérifier. Une réponse part avec une source ancienne et l’astreinte ne sait pas quelle capacité couper. Le problème n’est plus la seule qualité du modèle : le dispositif a été ouvert sans décision commune sur ses limites et sa reprise.

En pratique, le lancement doit porter sur une version, une population et une mission explicites. Les résultats d’évaluation justifient une partie du verdict. Les droits, les dépendances, la capacité de revue et l’exercice d’arrêt justifient les autres. Un dossier de lancement réunit ces preuves et indique qui peut ouvrir, limiter ou suspendre le service lorsque leur validité change.

Nous proposons le dossier d’un assistant fictif de qualification SAV qui prépare des propositions internes, sans envoi automatique. Le livrable rassemble les pièces du lancement et une matrice de décisions. Les scénarios décrivent ce qu’il faudrait tester ; aucun essai client ou système IA en production n’est revendiqué à partir de cet exemple.

Pour passer de l’essai à une IA sur mesure conçue pour les opérations, votre support doit pouvoir identifier la version en service, attribuer les propositions en attente et couper la capacité défaillante. L’industrialisation et la gouvernance d’un système IA préparent ces décisions avec les personnes qui les exécuteront. Le dossier présenté ici permet d’exiger leur preuve avant l’ouverture.

Pour qui le passage du POC à un service change la responsabilité

Ouvrir un usage durable plutôt qu’une démonstration

Le dossier concerne un responsable produit, une DSI et des opérations qui veulent utiliser régulièrement l’assistance sur des demandes réelles. Le périmètre nomme les familles de tickets, les utilisateurs, les sources et les sorties. « Le support peut utiliser l’IA » ne précise pas si l’outil rédige, classe, propose une action ou modifie réellement un dossier.

Pour notre exemple, l’ouverture prépare une qualification et un brouillon que le gestionnaire peut refuser. Le canal de réponse au client reste en dehors de cette capacité. Une extension vers l’envoi ou la création d’objet possède un autre rayon d’impact ; elle ne bénéficie pas automatiquement du verdict obtenu sur la proposition interne.

Différer lorsque le repli n’est pas soutenable

Le service doit pouvoir s’arrêter sans abandonner les tickets. Si le support a perdu son parcours manuel, l’IA devient une dépendance dont le retrait menace l’activité. Le comité doit comprendre cette conséquence et la capacité de repli réelle. Une procédure écrite qui suppose une équipe indisponible ne constitue pas une preuve de continuité.

Le coût complet inclut revue, erreurs, maintenance du corpus, interfaces et astreinte. Un POC peut être utile tout en nécessitant une réduction de périmètre avant lancement. Cette décision conserve le gain démontré sans imposer une charge que l’organisation ne peut pas absorber durablement.

Attacher les preuves à une version réellement déployable

Définir ce qui compose la version du service

La version comprend application, configuration d’orchestration, prompt, contrat de sortie, outils, modèle ou déploiement identifié, corpus et politiques d’accès utiles. Les éléments qui peuvent changer le comportement sont retrouvables ensemble. Un identifiant de modèle seul ne dit pas quel corpus a été servi ni quels paramètres d’outil ont été autorisés.

Une dépendance peut évoluer sans être totalement figée. Le dossier indique alors ce qui est versionné, ce qui reste variable et comment détecter une modification. La recette d’un modèle connu ne vaut pas preuve pour tout comportement derrière un alias fournisseur. Les limites de reproductibilité restent explicites plutôt que masquées sous une version commerciale stable.

Empêcher une configuration différente de profiter de la recette

Les résultats sont liés à la configuration évaluée et à son environnement. La promotion vérifie cette relation avant d’ouvrir. Un outil ajouté après la recette ou une politique assouplie constitue un changement à revoir. La publication conserve les références et empreintes utiles sans exposer les valeurs de secrets dans le dossier de lancement.

La comparaison versionnée des régressions IA précise cette pièce du dossier : population et juge constants, résultats appariés et défauts bloquants. Un contrôleur synthétique montre pourquoi une moyenne améliorée peut rester refusée et comment un cas manquant invalide la comparaison. La décision d’ouverture conserve les limites de cette preuve et les autres validations nécessaires à la capacité livrée.

Exemple concret : le candidat SAV-R3 possède uniquement des outils de lecture, tandis qu’une configuration de démonstration inclut un envoi de message. Leur nom de modèle peut être identique ; leur capacité ne l’est pas. Le contrôle d’ouverture doit refuser le second ensemble. Les noms et configurations de cet exemple sont fictifs.

Séparer résultat métier, frontières et capacités d’exploitation

Vérifier le résultat au-delà de la réponse annoncée

La recette métier vérifie qualification, fidélité des faits, question utile et destination de transfert. Les tentatives abandonnées ou inachevées restent dans le bilan. La recette de frontière teste accès étranger, instruction injectée, paramètres refusés et capacité non ouverte. Les deux bilans restent distincts : une bonne qualité moyenne ne compense pas une divulgation.

Anthropic explique dans Demystifying evals for AI agents la différence entre trace et résultat final dans l’environnement. Cette distinction aide à définir la preuve. Pour notre service, dire « ticket qualifié » ne suffit pas si la fiche attendue ne contient ni faits accessibles ni motif de transfert.

Tester les personnes et les outils qui devront reprendre

L’exercice d’exploitation part d’un incident et demande à l’astreinte de retrouver version, dossier, dépendance et conduite à tenir. Il vérifie la coupure et le repli dans l’environnement choisi. Le développeur qui connaît tout le système ne doit pas réaliser seul la démonstration de passation puis en déduire que le support est autonome.

Les preuves techniques et métier n’utilisent pas forcément le même juge. Une assertion peut vérifier l’absence d’une mutation ; un expert métier arbitre une question de précision. Un évaluateur automatique aide à trier les sorties mais demande une calibration et des contrôles adaptés. Son score ne devient pas un verdict universel de lancement.

Répartir les décisions sans perdre le propriétaire du service

Nommer l’autorité de chaque frontière

Le métier arbitre la sortie acceptable et la capacité de vérification. La sécurité valide les accès et les barrières. Les responsables des données et des interfaces attestent les sources et opérations disponibles. L’exploitation vérifie les alertes et la reprise. Un propriétaire du service rassemble ces décisions et conserve la responsabilité du périmètre ouvert.

Une réserve possède un motif, une personne, une conséquence et une date de revue. « À corriger plus tard » ne permet pas de savoir quelle famille doit rester fermée. Certaines réserves bloquent tout lancement ; d’autres limitent une source ou une population. Le dossier rend cette différence visible et ne transforme pas toutes les cases en un accord implicite.

Permettre un arrêt sans attendre un nouveau comité complet

Les critères et délégations d’arrêt sont approuvés avant l’ouverture. L’astreinte doit pouvoir suspendre une capacité lorsqu’un événement prévu survient, puis informer le propriétaire et attribuer les dossiers. Elle ne décide pas seule d’élargir les permissions pour résoudre l’incident. La réouverture suit une preuve et une autorité désignées.

Le budget d’exécution d’une mission d’agent précise l’arrêt avant un nouvel appel : consommation rapprochée, réservation ouverte, plafond d’appels et marge de clôture. Onze scénarios fictifs distinguent reprise d’une lecture et effet d’écriture inconnu. Cette pièce explique ce qui reste engagé lorsque le service interrompt la mission, sans supposer qu’un timeout annule le travail distant.

Le NIST AI RMF Core organise gestion des risques autour de gouvernance, contexte, mesure et traitement. Cette référence aide à structurer les questions ; elle n’impose pas notre fiche de lancement et ne certifie pas le dispositif. Le dossier proposé reste adapté aux responsabilités de l’organisation.

Construire un dossier de lancement qui permet un verdict

Relier chaque pièce à une décision observable

La fiche ne demande pas seulement si un document existe. Elle indique ce qu’il prouve, la version concernée et ce qui ferait perdre sa validité. Une recette antérieure au dernier changement d’outil reste une pièce disponible mais insuffisante pour l’ouverture actuelle. Un responsable doit pouvoir retrouver les écarts non clos depuis la décision.

Conserver les limites plutôt qu’un total rassurant

Une famille peut être ouverte alors qu’une autre reste exclue. Le verdict précise ce qui est permis, les plafonds d’admission, la date de revue et les conditions de suspension. Il conserve les résultats négatifs et les réserves. Une note globale « validé » sans périmètre empêche de reconnaître une extension non recettée.

Cette fiche est un livrable à compléter, pas une déclaration que notre exemple a été testé. Aucun responsable réel, résultat de recette ou accord client n’y est inventé. Les preuves datées doivent venir de votre système et des personnes habilitées ; un dossier entièrement rempli à partir d’hypothèses reste un plan d’essai.

Ouvrir une cohorte sans doubler les effets

Choisir une population et un chemin de retour

L’ouverture initiale identifie les utilisateurs et familles de demandes autorisés. L’admission applique ce périmètre côté serveur. Le service conserve un chemin de traitement antérieur et des plafonds cohérents avec la revue disponible. La cohorte ne s’étend pas parce que de nouveaux utilisateurs ont trouvé l’URL ou reçu un accès technique trop large.

Une bascule progressive doit permettre d’attribuer les résultats à une version. Deux candidats peuvent être comparés sur des copies autorisées de demandes, avec des outils sans effet. Le budget de dépendances et l’exposition de données augmentent malgré l’absence de mutation ; ils sont inclus dans la décision de comparaison.

Limiter explicitement le mode d’observation

Un traitement en parallèle du parcours actuel ne doit pas déclencher un second envoi ou une seconde création. Le mode d’observation retire les capacités d’effet et vérifie cette absence, plutôt que demander au modèle de ne pas utiliser un outil disponible. Si la comparaison exige un outil d’écriture, elle utilise un environnement et des objets conçus pour cet essai.

La bascule réelle précise quel service possède chaque dossier. Une requête déjà engagée ne traverse pas automatiquement les deux chemins après changement de configuration. Le suivi distingue tentative de comparaison et action métier. Cette séparation devient nécessaire lorsqu’un incident impose le retour au parcours précédent pendant que des demandes restent en cours.

Observer la qualité et la charge que les utilisateurs absorbent

Mesurer des résultats avec leur population réelle

Le tableau associe version, famille et nombre de demandes admises. Il distingue propositions acceptées, corrigées, refusées, abandonnées et reprises. Le temps de vérification et l’âge de file complètent la latence technique. Une moyenne de réponses rapides peut cacher un assistant dont les gestionnaires corrigent silencieusement toutes les fiches.

Les dénominateurs restent comparables : mesurer seulement les propositions terminées exclut les pannes et les demandes difficiles. Le monitoring suit aussi taux de passation, corrections récurrentes et questions déjà répondues par le client. Ces signaux conduisent à une décision sur la mission ou le corpus, pas systématiquement à un changement de modèle.

Attacher une action à chaque seuil utile

Les seuils sont arrêtés localement selon conséquence et charge support. Un âge de file excessif peut réduire l’admission ; une source retirée peut fermer une famille ; une fuite d’accès peut imposer une suspension immédiate du chemin concerné. Le propriétaire choisit ces réponses avant le lancement et sait qui recevra l’alerte.

Un seuil sans conduite à tenir ajoute une notification, pas une capacité de pilotage. Une alerte conserve référence de dossier, catégorie, version et responsable, sans recopier tous les contenus sensibles dans le canal d’astreinte. Les investigations nécessitant ces contenus disposent d’un accès distinct et attribué, conforme à la politique de l’organisation.

Suspendre la bonne capacité et gérer les dossiers en cours

Distinguer arrêt d’admission, coupure d’outil et retrait de version

Une saturation humaine peut demander de ne plus admettre de nouvelles demandes tout en laissant terminer les lectures en cours. Une capacité d’écriture défaillante demande de couper les transmissions et rapprocher les effets. Une régression de génération peut retirer un candidat et rétablir une configuration connue. Les trois arrêts n’ont pas les mêmes conséquences.

La suspension précise le devenir des propositions déjà produites. Elles peuvent rester consultables mais demander une nouvelle revue si leur version est en cause. L’équipe ne les supprime pas pour améliorer le tableau de bord. Les demandes ouvertes possèdent un propriétaire et une prochaine action dans le parcours de repli.

Reprendre depuis un résultat connu

Autre scénario : un connecteur a créé un objet puis la génération de synthèse échoue. Le retour de version ne rejoue pas la création pour obtenir une réponse complète. L’exploitation rapproche l’effet et reprend l’étape encore ouverte. Une compensation éventuelle suit sa propre procédure et autorisation.

La réouverture exige cause identifiée ou périmètre réduit, correction évaluée et vérification des dossiers touchés selon leur conséquence. L’absence de nouvelles erreurs après coupure ne prouve pas que les anciennes demandes sont résolues. Le dossier conserve les preuves de reprise et le verdict de la personne autorisée à rouvrir.

Matrice de décision : huit écarts qui changent le lancement

Préparer les décisions avant l’incident

Les cas suivants sont des scénarios de conception fictifs, non exécutés. Ils décrivent une attente de décision à confronter à votre périmètre. La recette doit conserver preuve, temps de reprise et limites constatées. Les règles ne deviennent applicables qu’après arbitrage des responsabilités et des conséquences dans l’organisation.

Lire les réserves par conséquence

Un défaut de mise en forme peut relever d’une correction planifiée ; une mutation hors compte ne suit pas le même chemin. La classification est arrêtée par le métier et la sécurité. Les réserves acceptées n’effacent pas les écarts : elles précisent la limite du service et la condition qui rend l’ouverture encore acceptable.

La recette compte les arrêts attendus comme des décisions correctes lorsque le contrat les exige. Cela ne signifie pas que le service apporte suffisamment de valeur : une abstention permanente peut être sûre et inutile. Le lancement examine à la fois les erreurs graves évitées, les résultats utiles et le travail nécessaire pour maintenir cette qualité.

Erreurs fréquentes des mises en production IA

Déduire la maîtrise d’une période sans incident déclaré

Paradoxalement, peu d’incidents peuvent révéler un usage faible ou des corrections absorbées par les utilisateurs. Le bilan doit connaître la population réelle, les tentatives et les motifs d’abandon. Une période calme ne remplace ni la recette des cas critiques ni un exercice de coupure conduit par les personnes de reprise.

Le signal faible est une hausse des demandes de vérification sans hausse des alertes techniques. L’assistant fonctionne mais l’équipe refait son travail. Une autre dérive apparaît lorsque les fiches anciennes disparaissent après chaque génération : la file paraît récente et la charge reste ouverte. Les métriques doivent conserver l’âge métier.

Traiter la confirmation humaine comme une barrière suffisante

Un bouton d’approbation ne vérifie pas seul les droits, les paramètres ou la pertinence des sources. Le gestionnaire doit disposer de preuves et d’une capacité réelle de refus. Les contrôles applicatifs restent présents. OWASP rappelle dans Excessive Agency les risques de capacités et permissions trop larges ; la supervision ne justifie pas leur ouverture générale.

La recette d’injection indirecte par document distingue consigne source, proposition d’outil et autorisation serveur. Un document piégé et des appels fictifs permettent d’exercer les refus ; les preuves du contrôleur, du modèle et du rendu final restent séparées avant toute ouverture de capacité.

La révision du prompt n’est pas un rollback universel. Elle ne révoque pas des accès et ne répare pas un effet externe. Une reprise complète relie configuration, droits, corpus et dossiers concernés. L’équipe choisit le changement nécessaire à partir des preuves, puis réévalue les frontières qu’il modifie.

Plan d’action : préparer ouverture, limitation et reprise

Rassembler un candidat et ses preuves avant la revue

Le propriétaire définit mission, population et effets autorisés. L’équipe prépare les entrées du dossier : versions, sources, résultats d’essai, limites et responsables. La sortie de revue sera un périmètre ouvert, limité ou différé. Les dépendances réellement utilisées sont inventoriées et leur disponibilité de repli est vérifiée, sans supposer qu’un modèle antérieur restera accessible.

La journalisation permet de relier chaque demande au candidat et à son résultat. Le monitoring dispose de seuils attribués sur qualité, accès, charge et âge de file. Le runbook décrit arrêt d’admission, suspension de capacité, rapprochement et réouverture. Les personnes concernées réalisent l’exercice ; leur résultat rejoint le dossier avec ses écarts.

Promouvoir puis réexaminer le périmètre depuis l’usage

La promotion compare configuration attendue et servie, puis ouvre une cohorte bornée. Le repli est immédiatement disponible et son déclenchement ne demande pas de nouvelles permissions. La première revue rapproche usage, résultats, corrections et réserves. Les valeurs de plafonds, fréquence de revue et délais sont choisies selon la mission ; aucune durée universelle ne garantit la maîtrise.

Le rollback conserve dossiers et preuves utiles. Toute extension de source, outil, population ou capacité repasse les contrôles affectés. Une version corrective ne supprime pas les cas difficiles du jeu de référence pour améliorer son score. Le propriétaire conserve un historique de décisions permettant de comprendre pourquoi le service a été ouvert, limité puis éventuellement repris.

• Réunir d’abord périmètre, candidat et preuves sur la même version.
• Arbitrer les réserves et les responsabilités d’arrêt avant l’ouverture.
• Exercer la coupure et le repli avec les personnes qui reprendront.
• Étendre depuis les résultats d’usage et les frontières à nouveau évaluées.

Guides complémentaires pour l’évaluation et les effets métier

Construire l’évaluation qui précède le verdict

Le protocole d’évaluation d’un POC IA métier approfondit référence, échantillons et critères de décision. Il prépare les preuves de valeur ; le dossier de lancement ajoute la capacité d’exploitation, les responsabilités et la population réellement admissible.

Un résultat d’essai ne constitue pas un accord d’ouverture si la configuration a changé ou si la revue humaine manque de capacité. La décision peut conserver la proposition comme utile tout en différant son exposition. Cette limite évite d’opposer valeur métier et maîtrise opérationnelle comme si l’une pouvait remplacer l’autre.

Vérifier ce qui doit rester connu après une coupure

La connexion ERP/CRM avec contexte et actions contrôlées précise autorisation, paramètres et preuve d’effet. Elle complète le lancement dès que le dispositif dépasse le brouillon interne et transmet une instruction à un logiciel opérationnel.

Les effets déjà appliqués ne disparaissent pas avec le retrait de version. Le dossier de lancement doit savoir quels parcours demandent rapprochement ou compensation. Les preuves de retour et les responsabilités sont alors une condition de lancement de l’action, au-delà de la seule possibilité technique d’appeler le connecteur.

Le retrait de versions après un incident IA distingue portée touchée, effets conservés et conditions de retour. Sa recette locale examine vingt états sans exécuter de rollback réel. Elle prépare les questions à éprouver dans l’exploitation : compatibilité des checkpoints, sources encore admissibles et décision de réouverture.

Pour une interrogation de données, le contrat NL-to-SQL avec indicateurs et requêtes autorisées précise les preuves de calcul et d’accès. Le lancement doit pouvoir retirer une question lorsque sa définition ou sa source ne satisfait plus ce contrat, même si la connexion reste disponible.

Conclusion : rendre le lancement révisable depuis des preuves

Le lancement d’un système IA porte sur une mission, une population et une version. Le dossier relie les résultats métier aux frontières d’accès, à la capacité de revue et à l’exploitation. Il ne transforme pas une démonstration convaincante en autorisation générale d’utiliser toutes les fonctions.

Ouvrir, limiter et différer sont des verdicts utiles lorsqu’ils décrivent leurs conditions. La suspension devient opérable si les dossiers en cours gardent un responsable et un chemin de reprise. La réouverture attend une preuve adaptée à l’écart, pas seulement le retour d’un indicateur technique au vert.

L’industrialisation des systèmes IA met cette décision au cœur de la recette et du service. Les versions, les réserves et les exercices d’arrêt restent consultables lorsque l’usage ou une dépendance change.

Pour mettre en place cette IA sur mesure exploitable par vos équipes, Dawap prépare avec votre responsable de service une ouverture limitée et son exercice de coupure. Le support doit retrouver les demandes encore en attente, reprendre leur traitement et expliquer ce qui autorise le retour. Si l’exercice révèle une file sans propriétaire ou un repli indisponible, cette réserve reste bloquante dans le dossier ; une démonstration de génération réussie ne la clôt pas.