Versionner les invites, les modèles et la logique de flux comme une seule livraison d’IA

Une livraison d’IA n’est ni une chaîne d’invite ni un point de terminaison de modèle pris isolément. C’est l’ensemble résolu qui peut changer ce que le service répond, consulte, autorise, coûte ou journalise. Revenir au modèle précédent tout en laissant en production une nouvelle permission d’outil, une nouvelle logique de reprise ou un nouveau schéma ne rétablit pas le comportement connu. Pour savoir ce qui a été évalué, servi et approuvé, l’équipe a besoin d’une identité unique pour toute la configuration, de preuves rattachées à cette identité et d’une cible de retour arrière vérifiée.

Qu’est-ce qui doit compter comme une seule livraison d’IA?

Une livraison d’IA doit comprendre chaque dépendance capable de modifier le comportement servi, l’autorité du système, le risque, le coût, la latence ou l’observabilité. Le modèle n’est qu’une pièce d’un système de production qui comprend aussi la configuration, les essais, les métadonnées, l’infrastructure de service et la surveillance. La frontière demeure propre au service : on inclut une dépendance interne ou tierce lorsqu’elle peut réellement changer une requête, une réponse, une action ou la décision qui permet la mise en production.

• L’invite, l’identifiant résolu du modèle et ses paramètres d’inférence effectifs.
• Les schémas d’outils, leurs permissions, les politiques, les garde-fous et les règles d’approbation.
• La récupération de contexte, le code du flux, les schémas d’entrée et de sortie, les dépendances d’exécution et les liaisons d’environnement pertinentes.
• Les jeux d’évaluation, évaluateurs, grilles et seuils, versionnés comme actifs d’assurance même s’ils ne s’exécutent pas dans le chemin de service.

Les historiques de chaque composant restent utiles, mais ils ne remplacent pas une identité commune. Un changement d’invite, d’instantané de modèle, de paramètre, de contrat d’outil, de permission, de politique, de réglage de récupération, de schéma, de dépendance ou de liaison influente produit un nouveau candidat. Les actifs d’évaluation demeurent liés au dossier de décision : leur modification ne change pas nécessairement l’exécution, mais elle peut changer le sens d’un résultat et doit donc rester visible.

Comment lier toute la pile dans un manifeste de livraison?

Il faut figer un manifeste qui nomme le candidat et résout chaque pointeur modifiable vers une référence stable. Le dossier indique l’identifiant de livraison, la date de création, le responsable, le service ciblé, l’état, les conditions d’arrêt, le responsable du retour arrière et la dernière livraison connue comme fiable. Pour chaque composant, il conserve une version, une révision, une empreinte de contenu ou un condensé d’artefact, ainsi que les paramètres réellement appliqués.

Un alias comme « production » ou « latest » n’est qu’un pointeur. Une version d’invite peut être immuable alors que l’alias ou certains réglages associés restent modifiables; le manifeste doit donc saisir la cible résolue et la configuration effective. Lorsqu’un fournisseur offre un instantané de modèle, l’équipe épingle celui qui a été testé. Elle consigne aussi les connexions approuvées, la référence de données ou de récupération, la clé de fonctionnalité et les contraintes de routage, sans inscrire les secrets eux-mêmes.

• Le candidat support-assistant-r18 lie l’invite p-42, le modèle m-2026-07, une température de 0,2 et la limite de sortie effective.
• Il lie aussi le schéma d’outil CRM t-9, la politique d’autorisation policy-12, la révision de flux wf-a71, le schéma reply-6 et le verrou des dépendances d’exécution.
• Son dossier d’assurance rattache séparément la suite eval-23, les versions des évaluateurs, les résultats, l’approbation et les observations de déploiement.
• La cible support-assistant-r17 n’est admissible qu’après une vérification de compatibilité avec les nouveaux champs facultatifs d’échéance et d’escalade.

Les allocations de trafic et les heures de déploiement vont dans des événements de promotion liés au manifeste, plutôt que de modifier celui-ci. Une hausse d’exposition déjà approuvée peut faire avancer le même candidat. En revanche, une modification de routage, de connexion ou de permission qui change le traitement, l’autorité ou le contexte d’une requête exige une nouvelle identité et de nouvelles preuves adaptées. Cette séparation permet de distinguer clairement ce qui a changé dans le produit de ce qui a changé dans son exposition.

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

Quelles preuves doivent autoriser la promotion du candidat?

La promotion doit reposer sur des notes orientées vers la décision et sur des portes appliquées au candidat complet qui pourrait recevoir du trafic. Les notes expliquent l’intention comportementale, chaque dépendance modifiée, les scénarios et interfaces touchés, les changements de permissions ou d’observabilité, les limites connues, le risque résiduel, le responsable du déploiement et la cible compatible de retour arrière. Les méthodes, jeux d’essai, évaluateurs, grilles et seuils sont versionnés avec les résultats afin que la décision puisse être relue sans ambiguïté.

La comparaison porte sur la livraison courante, les scénarios réels du flux, les cas limites coûteux, les segments importants et les interfaces de service. Une moyenne favorable ne doit pas masquer un contrat brisé, une permission excessive, un comportement interdit ou une régression concentrée. Les évaluateurs automatisés demandent eux-mêmes des vérifications, et les spécialistes du domaine restent nécessaires lorsque le sens opérationnel dépasse une mesure mécanique. Chaque porte se termine par une décision consignée — promouvoir, suspendre ou rejeter — et par le nom du responsable.

Comment promouvoir le même candidat jusqu’en production?

Le même candidat résolu doit franchir une progression mesurée, de la répétition sans action jusqu’au trafic complet. Une répétition en mode fantôme peut comparer des demandes représentatives, mais les outils d’écriture et les autres effets conséquents doivent être désactivés ou placés dans un environnement isolé. L’équipe passe ensuite à un groupe interne, puis à une cohorte de production stable, à une exposition élargie et enfin au plein trafic. À chaque étape, elle compare les signaux de tâche, de sécurité, d’outil, de fiabilité, de latence et de coût avec la livraison courante.

1. Répéter des cas représentatifs sans déclencher d’actions externes et comparer les traces complètes.
2. Ouvrir le candidat à un groupe interne en conservant les approbations prévues.
3. Utiliser une cohorte de production stable afin qu’une même entité reste associée à la même livraison pendant l’observation.
4. Élargir seulement après l’obtention des observations et du volume jugés suffisants pour le risque du service.
5. Passer au plein trafic tout en maintenant la surveillance par identifiant de livraison et la cible de retour arrière.

Les règles de cohorte, l’allocation, le début de l’observation et la décision sont des événements liés au candidat immuable. Une augmentation planifiée de trafic ne crée pas une nouvelle livraison; modifier l’invite, le modèle, un outil, une permission, une politique, un schéma, une dépendance ou une liaison influente en crée une. Les parts de trafic, le nombre d’observations et la durée ne sont jamais universels : ils dépendent du risque, du volume, du délai de détection et de la capacité d’intervention. Même bien conçu, un canari ne couvre pas toutes les conditions ni les défaillances rares.

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

La livraison doit s’arrêter lorsqu’une condition ferme définie avant l’exposition est confirmée : atteinte aux règles de sécurité ou d’autorité, comportement d’outil non autorisé, contrat brisé ou défaillance grave de fiabilité. Les autres régressions suivent des limites propres au service, à ses engagements et à ses capacités. Une constatation ambiguë peut justifier une suspension et une enquête plutôt qu’un retour automatique, mais la décision, son motif et son responsable doivent rester explicites.

Le retour arrière restaure le trafic vers l’ensemble complet connu comme fiable et encore compatible, pas vers un seul composant antérieur. Avant la livraison, l’équipe répète ce rétablissement et vérifie les schémas, les états persistants, les migrations, la disponibilité du fournisseur, les contrats d’outils, les connexions et le routage. Une ancienne configuration peut cesser d’être exploitable après une migration ou la disparition d’un instantané; la mention « dernière version fiable » ne remplace donc jamais une vérification de compatibilité.

• Consigner le déclencheur, l’heure observée, la livraison, la cohorte, les chemins touchés et la cible restaurée.
• Valider le rétablissement du trafic et conserver séparément les identifiants des requêtes et des actions externes concernées.
• Désactiver au besoin le chemin d’action, puis appliquer un guide autorisé de confinement, de rapprochement, de correction, de notification ou de compensation.
• Mettre à jour les évaluations et la surveillance après la décision finale, sans confondre cette remise en état avec le retour de configuration.

Le retour de configuration contrôle les requêtes futures; il ne supprime pas un message envoyé, n’annule pas une écriture de données et ne retire pas une approbation déjà exécutée. Pour support-assistant-r18, une tâche CRM erronée doit être retrouvée au moyen de la trace et de son identifiant, puis traitée selon le guide de correction autorisé. Le simple rétablissement de r17 ne la fait pas disparaître. Cette distinction évite qu’une opération technique réussie soit déclarée résolue alors que ses effets externes demeurent actifs.

Quel dossier rend une livraison d’IA reconstructible plus tard?

Un dossier durable doit permettre de reconstruire la configuration effective, les preuves observées et la décision de livraison. Il conserve le manifeste immuable, les identifiants et paramètres résolus, les liaisons d’environnement, les résultats de compatibilité, les versions des actifs d’évaluation, les approbations, les événements de déploiement, les allocations, les constatations, les retours arrière et la décision finale. Les heures, responsables, artefacts et références vers la livraison précédente complètent la chaîne sans obliger l’équipe à deviner l’état réel à partir de plusieurs registres.

• Joindre l’identifiant de livraison aux traces des générations, appels d’outils, transferts, garde-fous, durées et résultats.
• Enregistrer les identifiants de requête du fournisseur et ceux de l’application lorsqu’ils sont disponibles.
• Conserver les identifiants et les échantillons gouvernés nécessaires sans archiver par défaut chaque invite, entrée d’outil, sortie de modèle ou donnée de clientèle.
• Appliquer aux contenus sensibles les politiques organisationnelles de collecte, d’accès, de conservation et de suppression.

Ce dossier fournit une reproductibilité de configuration et une reproductibilité de décision, pas une promesse de réponse identique. Un modèle stochastique, un service hébergé ou une infrastructure externe peut produire un résultat différent malgré des identifiants épinglés et des réglages archivés. La bonne question est plutôt : pouvons-nous établir quelle configuration a servi la demande, quelles preuves ont autorisé sa promotion et pourquoi l’équipe a poursuivi, suspendu ou restauré? Cette formulation demeure vérifiable sans attribuer au versionnement un déterminisme qu’il ne possède pas.

Commencez par le plus petit dossier qui identifie encore le candidat complet, ses preuves versionnées, ses décisions de promotion et sa cible compatible. Lorsqu’un changement touche des données sensibles, des permissions conséquentes, un travail réglementé, la conservation de dossiers ou la correction d’actions externes, faites intervenir les responsables qualifiés de la sécurité, de la protection des renseignements personnels, du droit, des archives, du risque ou du domaine. Cette méthode organise la livraison; elle ne détermine pas à leur place les obligations applicables.