Versionner prompts, modèles et logique de workflow comme une seule mise en production

Une mise en production IA est la configuration complète qui détermine le comportement servi, pas uniquement un prompt ou un point de terminaison de modèle. Revenir au modèle précédent tout en laissant actifs une nouvelle consigne, un schéma d’outil, une permission ou un chemin de reprise ne restaure pas l’ancien service. Une identité commune doit donc désigner précisément ce qui a été évalué, approuvé, exposé et, si nécessaire, rétabli.

Que faut-il considérer comme une seule version IA?

Une version IA doit englober toutes les dépendances qui peuvent modifier le comportement servi, l’autorité accordée au système, son risque, son coût, sa latence ou son observabilité. Le modèle n’est qu’une pièce d’un système de production. Les activités et composants du cycle de vie sont interdépendants, et les architectures de ML en production comprennent aussi configuration, vérification, métadonnées, infrastructure de service et suivi.

• Prompt et instructions système, avec leur version ou empreinte de contenu.
• Identifiant résolu du modèle, paramètres d’inférence et format de réponse effectif.
• Schémas d’outils, permissions, approbations, politiques et garde-fous.
• Réglages de recherche, contexte, routage, workflow, schémas d’entrée et de sortie.
• Dépendances d’exécution et liaisons d’environnement capables de modifier le traitement.

Les jeux d’évaluation, évaluateurs, rubriques et seuils ne s’exécutent généralement pas dans le chemin de service, mais ils peuvent changer la décision d’autoriser une version. Ils doivent donc posséder leurs propres identités et rester liés au dossier de mise en production. La frontière demeure propre au système: une dépendance interne ou tierce n’entre dans l’inventaire que si elle peut matériellement influer sur le service ou sur la décision de le promouvoir.

Comment réunir la pile de comportement dans un manifeste?

Le manifeste doit figer un candidat identifiable et interdire sa modification silencieuse pendant la promotion. Il indique au minimum l’identifiant de version, l’heure de création, le propriétaire, le service cible, le statut, les conditions d’arrêt, le responsable du retour arrière et la dernière version connue comme bonne. Toute modification d’un composant capable de changer le comportement crée un nouvel identifiant, même si le changement paraît minime.

• Pour chaque composant, conserver une version résolue, un commit, un condensat d’artefact, une empreinte de contenu ou une autre référence stable, ainsi que les réglages effectifs.
• Résoudre les alias flottants tels que «production» ou «latest»: ils sont des pointeurs de déploiement, pas des identités immuables.
• Référencer les connexions approuvées, l’identité du feature flag, les règles de routage et la source de données ou de recherche sans enregistrer les secrets eux-mêmes.
• Placer allocations de trafic, cohortes et heures de déploiement dans des événements liés afin de ne pas réécrire le manifeste.

Prenons l’assistant interne d’un éditeur de logiciels qui résume les tickets, propose une réponse et ne crée une tâche CRM qu’après approbation humaine. Le candidat support-assistant-r18 lie le prompt p-42, l’instantané m-2026-07 avec une température de 0,2 et sa longueur de sortie, le schéma d’outil t-9, la politique policy-12, le commit wf-a71, le schéma reply-6 et le verrou des dépendances. Son dossier référence séparément eval-23 et les versions des évaluateurs. support-assistant-r17 ne devient la cible de repli qu’après vérification des nouveaux champs facultatifs.

Ce qui peut changer le comportement servi — ou la preuve qui l’autorise — doit avoir une identité résolue dans le dossier de version.

Quelles preuves doivent autoriser la promotion du candidat?

La décision doit reposer sur des preuves produites avec le candidat complet qui sera réellement promu. Les notes de version expliquent l’intention comportementale, chaque dépendance modifiée, les scénarios et interfaces concernés, les changements de permission ou d’observabilité, les limites connues, le risque résiduel, le propriétaire du déploiement et la cible de repli compatible. Elles rendent la décision lisible sans remplacer les résultats détaillés.

Les évaluations générales d’un modèle ne suffisent pas à représenter un workflow métier précis. Il faut comparer le candidat à la version courante sur des exemples proches du travail réel, des segments importants et des cas rares mais coûteux, puis auditer les évaluateurs automatisés. Une moyenne favorable ne compense pas une rupture matérielle de contrat, d’autorité, de sécurité ou de qualité sur un segment critique.

Chaque porte se termine par une décision enregistrée: promouvoir, suspendre ou rejeter, avec un propriétaire nommé. Les versions plus risquées peuvent séparer l’auteur du changement de l’approbateur. Les jeux de données, évaluateurs, rubriques et seuils portent aussi une version, car une porte modifiée peut changer l’interprétation des mêmes résultats sans que le candidat d’exécution ait bougé.

Comment faire progresser le même candidat en production?

Le même manifeste résolu doit traverser chaque étape, d’une répétition sans action jusqu’au trafic complet. Lorsque c’est faisable, le parcours commence par des requêtes rejouées en mode fantôme, avec les outils d’écriture désactivés ou isolés afin d’éviter de reproduire aveuglément des actions réelles. Il passe ensuite à un groupe interne, puis à une cohorte de production stable avant une exposition élargie.

1. Rejouer des cas représentatifs sans effets externes et comparer les traces complètes avec la version courante.
2. Exposer le candidat à une équipe interne en conservant les approbations requises.
3. Affecter une cohorte de production persistante et comparer qualité, sécurité, outils, fiabilité, latence et coût.
4. Élargir seulement après les observations prévues, sans modifier le candidat.
5. Passer au trafic complet tout en maintenant le suivi par identifiant de version.

Les règles de cohorte, l’allocation du trafic, les heures d’observation et la décision de chaque étape sont des événements liés au manifeste. Une hausse d’exposition préapprouvée ne crée pas nécessairement une nouvelle version. En revanche, modifier un prompt, un réglage de modèle, une permission, une politique, un outil, le contexte, le workflow, un schéma ou une liaison d’environnement impose un nouveau candidat et de nouvelles preuves.

Aucun pourcentage, nombre d’exemples ou délai n’est universel. Ces valeurs dépendent du risque du service, de son trafic, du temps nécessaire pour détecter un problème et de la capacité d’intervention. Une cohorte stable facilite la comparaison et des traces marquées par version facilitent l’attribution, mais ni le mode fantôme ni un canari ne représentent forcément toutes les conditions de production ou les défaillances rares.

Quand faut-il arrêter la version, et que doit restaurer le retour arrière?

La version doit s’arrêter dès qu’un arrêt franc prédéfini est confirmé: atteinte à la sécurité ou aux règles, comportement d’outil non autorisé, rupture de contrat ou défaillance sévère de fiabilité. Les autres régressions suivent des limites et fenêtres propres au service. Un signal ambigu peut justifier une suspension et une enquête plutôt qu’un retour automatique, mais la décision et son propriétaire restent explicites.

• Vérifier que les schémas, états, migrations, contrats d’outils, règles de routage et services du fournisseur restent compatibles avec la cible précédente.
• Rétablir le trafic vers l’ensemble complet connu comme bon, et non vers un composant isolé.
• Répéter ce rétablissement avant qu’il soit nécessaire, puis valider le service après le basculement.
• Conserver séparément le déclencheur, l’heure, la cohorte touchée, les requêtes et les identifiants d’actions externes.

Le retour de support-assistant-r18 à r17 empêche les nouvelles requêtes d’utiliser le candidat; il ne supprime pas un message envoyé ni une tâche CRM déjà créée. Les traces liées à la version servent à retrouver les requêtes et identifiants concernés. Une procédure distincte, exécutée par des personnes autorisées, traite ensuite le confinement, le rapprochement, la correction, la notification, la restauration ou l’action compensatoire adaptée.

Quel dossier permet de reconstruire une version IA plus tard?

Un dossier durable doit permettre de reconstruire la configuration effective, les preuves observées et la décision, sans promettre une répétition identique des sorties. Il réunit le manifeste immuable, les identifiants et paramètres résolus, les liaisons d’environnement, les conclusions de compatibilité, les versions et résultats d’évaluation, les approbations, les événements de déploiement, les allocations de trafic, les constats, les retours arrière et la décision finale.

• Attacher l’identifiant de version aux traces des générations, outils, transferts, garde-fous, délais et résultats.
• Enregistrer les identifiants de requête du fournisseur et les identifiants de trace applicatifs lorsqu’ils existent.
• Conserver les versions des composants, acteurs, heures, paramètres, artefacts et preuves de chaque décision.
• Préserver des identifiants et échantillons gouvernés sans exiger la rétention de tous les prompts, contenus clients ou résultats.

Cette discipline produit une reproductibilité de configuration et de décision: l’équipe peut établir ce qui devait fonctionner, pourquoi la promotion a été autorisée et quelle version a servi une requête. Elle ne garantit pas une sortie identique, car un service hébergé ou stochastique peut varier malgré des références épinglées. Le plus petit dossier utile reste celui qui identifie le candidat, ses preuves, ses étapes de promotion et sa cible de repli compatible.

Lorsqu’une version modifie le traitement de données sensibles, des permissions lourdes de conséquences, un workflow réglementé, des obligations de conservation ou la remédiation d’actions externes, l’équipe doit consulter les responsables qualifiés en sécurité, protection des données, droit, archives, risque ou domaine métier. Ce modèle d’exploitation aide à conserver une décision vérifiable; il ne détermine pas les exigences juridiques ou organisationnelles applicables.