Versionner prompts, modèles et logique de workflow comme une seule release IA

Une release IA n’est ni un prompt isolé ni le nom d’un modèle : c’est l’ensemble résolu qui produit le comportement en service. Revenir seulement au modèle précédent peut laisser en production une consigne, un schéma d’outil, une permission, une règle de routage ou une logique de reprise modifiée. Sans identité commune, l’équipe peine ensuite à dire ce qui a été évalué, quelle configuration a traité une requête problématique et quel ensemble compatible doit reprendre le trafic.

Qu’est-ce qui doit constituer une release IA complète ?

Une release complète réunit les dépendances capables de changer le comportement servi, l’autorité accordée au système, son risque, son coût, sa latence ou son observabilité. L’inventaire couvre le prompt, l’identifiant résolu du modèle et ses paramètres d’inférence, les contrats et permissions des outils, les politiques ou garde-fous, la recherche documentaire et le contexte, le code du workflow, les schémas d’entrée et de sortie, les dépendances d’exécution et les liaisons d’environnement qui influencent le traitement.

Cette frontière reste propre au système. Une bibliothèque, une source tierce ou une connexion n’entre dans la release que si elle peut modifier matériellement le service ou la décision de le promouvoir. Les jeux d’évaluation, évaluateurs automatiques, grilles et seuils n’exécutent généralement pas les requêtes de production ; ils appartiennent néanmoins au dossier d’assurance, car leur version détermine la lecture des résultats. Chaque actif conserve son historique, mais le candidat complet reçoit une identité unique.

• Runtime : prompt, modèle résolu, paramètres, outils, permissions, politiques, contexte, workflow, schémas, dépendances et liaisons effectives.
• Assurance : jeu d’évaluation, évaluateurs, grilles, seuils, résultats et avis des responsables.
• Nouvelle candidature : toute modification d’un composant qui change le comportement, l’autorité, le contexte ou les conditions réelles d’exécution.

Comment lier toute la pile dans un manifeste de release ?

Le manifeste doit être un instantané immuable du candidat, lisible sans reconstruire plusieurs historiques. Il porte un identifiant de release, une date de création, un propriétaire, le service visé, un statut, les conditions d’arrêt, le responsable du rollback et la précédente release reconnue comme fiable. Pour chaque composant, il conserve une version résolue, un commit, une empreinte d’artefact, un hachage de contenu ou une autre référence stable, avec les réglages effectifs. Un alias comme production ou latest n’est qu’un pointeur.

Prenons un assistant interne qui résume les tickets, propose une réponse et crée une tâche CRM après validation humaine. Le candidat support-assistant-r18 associe le prompt p-42, l’instantané m-2026-07 avec une température de 0,2 et sa longueur maximale, 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 relie séparément la suite eval-23 et les versions des évaluateurs.

• Consigner les connexions approuvées, la référence de données ou de recherche, l’identité du feature flag et les contraintes de routage, sans enregistrer les secrets eux-mêmes.
• Placer allocations de trafic, cohortes et horodatages dans des événements de promotion liés au manifeste, afin de ne pas le modifier.
• Déclarer support-assistant-r17 comme cible de rollback seulement après vérification de sa compatibilité avec les champs facultatifs de date d’échéance et d’escalade.

Si un élément change le comportement servi ou la preuve qui l’autorise, son identité résolue doit figurer dans le dossier de release.

Quelles preuves doivent autoriser la progression du candidat ?

La progression doit dépendre de preuves portant sur le candidat complet, puis se conclure par une décision explicite : promouvoir, maintenir en attente ou rejeter. Les notes de release décrivent l’intention comportementale, les dépendances modifiées, les scénarios et interfaces touchés, les changements de permission ou d’observabilité, les limites connues, le risque résiduel, le responsable du déploiement et la cible de retour. Elles permettent au décideur de comprendre le changement, pas seulement de consulter un score.

Les contrôles combinent construction et contrats, qualité propre au workflow, sécurité et autorité, comportement des outils, fiabilité, latence et coût. Le candidat est comparé à la release courante sur les segments importants et les cas limites coûteux. Un résultat moyen favorable ne compense pas une rupture matérielle de schéma, une permission excessive, un défaut de sécurité ou une régression concentrée sur un segment critique. Les seuils restent propres au service et les évaluateurs automatiques doivent eux-mêmes être contrôlés.

Comment faire progresser le même candidat en production ?

Le même manifeste résolu doit franchir chaque étape, sans retouche discrète entre deux niveaux d’exposition. Lorsque c’est faisable, le parcours commence par un rejeu en mode fantôme ou non actionnant : les écritures et autres effets conséquents sont désactivés ou isolés. Il se poursuit auprès d’un groupe interne, puis d’une cohorte de production stable, avant une exposition élargie et le trafic complet. À chaque palier, les signaux convenus sont comparés à ceux de la release courante.

1. Rejouer des cas représentatifs sans exécuter d’actions externes.
2. Ouvrir le candidat à une équipe interne en conservant les validations prévues.
3. Former une cohorte de production stable et marquer toutes ses traces avec l’identifiant de release.
4. Élargir seulement après la durée d’observation et le volume d’éléments définis pour le service.
5. Passer au trafic complet tout en maintenant la cible de rollback disponible.

Une augmentation préapprouvée de l’exposition reste un événement de déploiement du même candidat. En revanche, changer le prompt, un paramètre du modèle, un outil, une permission, une politique, le contexte de recherche, le workflow, un schéma, une dépendance ou une liaison d’environnement crée un nouveau candidat. Les parts de trafic et fenêtres d’observation dépendent du risque, du volume, du délai de détection et de la capacité d’intervention. Ni le mode fantôme ni un canari ne représente toutes les conditions ou les défaillances rares.

Quand faut-il arrêter la release, et que doit restaurer le rollback ?

La release doit s’arrêter dès qu’une condition dure préalablement déclarée se réalise : violation de sécurité ou de politique, usage d’outil non autorisé, rupture de contrat d’interface ou défaillance grave de fiabilité. Les autres régressions suivent des limites propres au service. Un signal ambigu peut justifier une pause et une enquête plutôt qu’un rollback automatique, mais la décision, son motif et son propriétaire doivent rester explicites. Cette règle est fixée avant l’exposition, quand l’équipe peut encore raisonner sans urgence.

Le rollback restaure le trafic vers la release complète reconnue comme fiable, pas vers un modèle isolé. Cette cible doit avoir été répétée et vérifiée contre les schémas, états persistants, migrations, contrats d’outils, règles de routage et disponibilités fournisseur. Dans l’exemple, support-assistant-r17 ne convient que s’il tolère les nouveaux champs facultatifs. Après restauration, des contrôles ciblés confirment que le routage, les permissions et les fonctions essentielles correspondent bien à l’ensemble attendu.

• Le rollback de configuration empêche les futures requêtes d’utiliser le candidat défaillant.
• Il ne supprime pas un message envoyé, une écriture de données, une approbation ni une tâche CRM déjà créée.
• Les traces marquées par la release servent à retrouver requêtes et identifiants d’action, puis un runbook autorisé organise confinement, rapprochement, correction, notification ou compensation.

Quel dossier permet de reconstruire une release IA plus tard ?

Le dossier durable doit permettre de reconstruire la configuration effective, les preuves observées et la décision prise. 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 cohortes, les allocations de trafic, les constats, les événements de rollback et la décision finale. Une référence vers la release précédente complète la chaîne de responsabilité.

L’identifiant de release doit aussi accompagner les traces afin d’attribuer générations, appels d’outils, transferts, garde-fous, temps de traitement et résultats au candidat qui a servi la requête. Les identifiants de trace applicatifs et de requête fournisseur facilitent le diagnostic entre systèmes. Cette traçabilité n’impose pas de conserver chaque prompt, entrée d’outil, sortie de modèle ou contenu client : les données sensibles suivent les règles internes de collecte, d’accès et de conservation.

Il faut parler de reproductibilité de la configuration et de la décision, non de reproduction identique des sorties. Des identifiants figés et des réglages archivés réduisent l’incertitude, mais un service hébergé ou un modèle stochastique peut encore produire un résultat différent. Le bon point de départ est donc le plus petit dossier qui relie clairement candidat, preuves versionnées, décisions de promotion et cible compatible. Tout changement touchant des données sensibles, des pouvoirs conséquents ou un workflow réglementé doit être examiné par les spécialistes qualifiés de l’organisation.