10 échecs de release CI/CD dans les modèles de langage personnalisés — et quelle étape du pipeline attrape chacun

Notes from the Release Cycle — Part II

Le premier article de cette série a parcouru le pipeline de release en quatre étapes que nous livrons — Enregistrer → Gater → Dérouler → Observer. Ce billet, ce sont les reçus : dix modes d’échec spécifiques que nous avons désormais attrapés grâce à lui, à quoi chacun ressemblait en pratique, et quelle étape du pipeline l’a empêché d’atteindre la production.

La liste est organisée par étape, pas par gravité, parce que l’étape vous indique où investir si vous construisez quelque chose comme cela vous-même. Si votre porte est le maillon faible, six des dix échecs ci-dessous continueront à vous frapper. Si votre observateur est le maillon faible, deux d’entre eux vous frapperont en silence — autrement dit, le seul signal que vous obtiendrez jamais sera une plainte client, ce qui est le pire signal possible.

Un pipeline qui attrape les dix n’est pas une liste de fonctionnalités. C’est un petit nombre de décisions architecturales prises avec cohérence. Chaque échec ci-dessous nomme la décision qui s’applique.

Comment lire cette liste

Chaque échec est étiqueté avec l’étape qui l’attrape :

• ① ENREGISTRER — la couche manifeste. Stoppe les échecs où on ne pouvait pas dire quel changement avait cassé la production parce que l’état était réparti sur plusieurs systèmes.
• ② GATER — Spearman par domaine face à un juge calibré et ancré sur l’humain. Stoppe les échecs qui se cachent à l’intérieur des scores agrégés.
• ③ DÉROULER — canary à 5 % → 25 % → 100 % avec un moniteur de qualité à chaque point de contrôle. Stoppe les échecs qui n’apparaissent qu’à l’échelle.
• ④ OBSERVER — replay continu des traces à travers le candidat, scoré par le juge de la porte. Stoppe les chutes silencieuses de qualité que la latence et les 5xx ne remarquent jamais.

Chaque section se termine par le fix — la configuration exacte que nous livrons chez Divinci, plus ce qu’il faut construire soi-même si vous ne nous utilisez pas.

Étape ① — Enregistrer

1. Co-déployer modèle + prompt + routage dans un seul bundle et ne pas savoir lequel l’a cassé

Ce qui s’est passé. Nous avons changé trois choses dans la même release : passage du modèle de base de Gemma 4 E2B à Gemma 4 26B-A4B, édition du prompt système du domaine juridique pour ajouter une instruction « cite le texte de loi », et ajustement de la règle de routage qui décide quelle classe de trafic atterrit sur quel modèle. La précision sur la rédaction de contrats a chuté de 7 points. Aucun des trois changements n’avait été testé indépendamment. Le déboguer a exigé d’annuler une variable à la fois sur deux jours.

Pourquoi le pipeline l’attrape désormais. Une release Divinci est un manifeste immuable regroupant model_ref, prompt_template_ref, routing et dataset_version en un seul artefact adressé par SHA-256. Le pipeline refuse de déployer un manifeste qui regroupe plus d’un changement sauf si le SHA de la release précédente est référencé comme baseline de comparaison. Si vous voulez livrer trois changements d’un coup, vous devez le reconnaître dans le manifeste, et le chemin d’attribution de l’échec reste propre parce que la prochaine release est forcée de revenir à une variable à la fois.

Fix. Ne laissez pas des humains assembler des releases à la main. Le manifeste de release doit être généré par un pipeline qui ne peut pas regrouper en silence. Voir Étape 1 — Enregistrer pour l’API.

2. Éditer un prompt système dans un tableau de bord et le livrer sans revue de code

Ce qui s’est passé. Quelqu’un a ajusté le prompt système dans une UI d’administration pour « rendre le modèle moins verbeux ». Cela ressemblait à une édition d’un seul mot. Le prompt résultant était plus court de 38 caractères, ce qui le faisait passer sous un seuil de longueur que le réécrivain de prompts en aval utilisait pour décider d’ajouter ou non du boilerplate de sécurité. Deux heures plus tard, le modèle répondait à des questions qu’il aurait dû refuser.

Pourquoi le pipeline l’attrape désormais. Les prompts font partie du manifeste enregistré. Éditer un prompt dans un tableau de bord signifie découper un nouveau manifeste, ce qui signifie générer un nouveau SHA, ce qui signifie que la porte tourne face au changement. Vous pouvez toujours éditer des prompts dans un tableau de bord. Vous ne pouvez juste pas les livrer sans que la porte les voie.

Fix. Traitez les prompts comme du code : versionnez-les avec un hash de contenu, enregistrez-les comme partie de la release, gatez-les sur la suite de QA scorée. Le compte rendu Semver Lie de Tianpan^[1] décrit exactement ce mode d’échec se produisant dans la nature — un changement de prompt qui « est passé la revue de code, a été déployé sans portes d’évaluation, a atteint la production sans A/B par utilisateur, et n’a déclenché aucun rollback automatique ».

3. Décalage de préprocessing entre entraînement et service

Ce qui s’est passé. Le pipeline d’entraînement normalisait les espaces et mettait en minuscules un champ particulier. Le pipeline de service ne le faisait pas. Même modèle, même prompt, même routage — entrées différentes au niveau octet. Sur les fixtures de dev tout passait. Sur le vrai trafic, le modèle se comportait comme s’il avait été ré-entraîné sur des données plus bruitées, parce que de son point de vue c’était le cas.

Pourquoi le pipeline l’attrape désormais. Le manifeste enregistre un preprocessing_ref aux côtés de model_ref. L’évaluation de porte tourne à travers le même préprocessing que la pile de service de production utilise. Si les deux divergent, les chiffres hors-ligne de la porte ne correspondent plus à la production, et le Spearman par tranche chute d’une manière mesurable avant la promotion.

Fix. Conteneurisez le préprocessing comme un artefact versionné. Référencez-le depuis le manifeste. Refusez de déployer si la porte a été calculée face à une version de préprocessing différente de celle que la production utilisera.

Étape ② — Gater

Les quatre échecs ci-dessous sont ceux qu’une porte à score agrégé aurait livrés. La raison pour laquelle une porte agrégée les rate est structurelle, pas un réglage de paramètres — moyenner sur les tranches détruit exactement le signal que vous utiliseriez pour attraper une régression localisée sur une seule tranche.

4. L’effondrement des licences PI (régression consciente des tranches n°1)

Ce qui s’est passé. Un fine-tune QLoRA a amélioré la précision en Q&A juridique sur cinq sous-domaines et fait s’effondrer les licences PI — rédaction de contrats 0,71, interprétation statutaire 0,74, résumé de jurisprudence 0,69, conformité réglementaire 0,66, analyse de juridiction 0,62, licences PI 0,41. Le Spearman ρ agrégé sur les six était 0,64. Le seuil de porte était 0,65. À un seul score agrégé près, la release était d’un cheveu sous la ligne. À la vue par tranche, un sous-domaine s’était effondré de 27 points.

Pourquoi le pipeline l’attrape désormais. Le seuil de la porte est par tranche, pas agrégé. Toute tranche unique tombant sous son seuil marque la release gate_fail, peu importe à quoi ressemble la moyenne. Le graphique des seuils de porte dans le billet n°1 est la visualisation réelle que le pipeline produit pour des releases comme celle-ci.

Fix. Tranchez la porte. Les tranches qui comptent sont les sous-domaines de vos segments clients, pas la taxonomie qui se trouve dans le framework d’éval que vous avez importé.

5. Régression de la tranche oncologie pédiatrique (régression consciente des tranches n°2)

Ce qui s’est passé. Un modèle de Q&A médical a été fine-tuné sur des données supplémentaires de cardiologie adulte. La précision médicale agrégée s’est améliorée de 4 points. La précision en oncologie pédiatrique a chuté de 11 points — apparemment, les nouvelles données d’entraînement déséquilibraient subtilement les ajustements posologiques pédiatriques. La porte agrégée l’aurait promu.

Pourquoi le pipeline l’attrape désormais. L’oncologie pédiatrique était l’une des tranches configurées par le client lorsqu’il a enregistré la suite de QA scorée. L’évaluation de Gate-2 a produit un Spearman ρ par tranche qui chutait de 0,72 à 0,61, sous le seuil oncologie-pédiatrique de 0,68. Marquée gate_fail. Pas de déploiement.

Fix. Tranches définies par le client, pas par la plateforme. La plateforme doit permettre au client d’ajouter une tranche et un seuil par tranche sans écrire de code — parce que personne chez Divinci ne connaît les arêtes du domaine de votre client aussi bien que votre client lui-même.

6. Dérive multilingue sous-tranche (régression consciente des tranches n°3)

Ce qui s’est passé. Un modèle multilingue fine-tuné pour améliorer les réponses en français. La précision agrégée en français s’est améliorée de 3 points. À l’intérieur du « français », cependant, le modèle se comportait désormais moins bien sur les variantes régionales français de Belgique et français de Suisse — le corpus d’entraînement avait été dominé par le français de Paris. Une porte agrégée sur le français l’aurait livré.

Pourquoi le pipeline l’attrape désormais. Les variantes locales sont des sous-tranches de la tranche langue. Le Spearman par sous-tranche a attrapé la régression sur la variante belge avant la promotion. La release a été renvoyée pour soit (a) des données d’entraînement plus diverses soit (b) un force-override avec une justification écrite (« nous acceptons la régression régionale parce que l’amélioration agrégée en français compte plus dans ce déploiement ») — et l’override va dans la piste d’audit.

Fix. La profondeur des tranches compte. « Français » est trop grossier. « Français de Belgique » est le niveau où les régressions se cachent réellement.

7. Contournement de la porte sans justification écrite d’override

Ce qui s’est passé. Une fenêtre de release sous pression. La porte a échoué sur une tranche — non critique, selon le jugement de l’équipe. Quelqu’un a tendu la main vers le drapeau force-override. Dans une version antérieure du pipeline, force-override était un simple booléen. Le drapeau a basculé, la release est partie, et trois semaines plus tard personne ne pouvait reconstruire qui avait décidé quoi à propos de quelle tranche.

Pourquoi le pipeline l’attrape désormais. Force-override est une porte à deux champs : forceGateOverride: true ET overrideReason: "...". La raison est une chaîne de texte libre obligatoire écrite dans le journal d’audit aux côtés de l’ID utilisateur et du résultat de porte par tranche qui a été overridé. Le pipeline refuse l’override sans la raison. Vous pouvez toujours overrider — vous ne pouvez juste pas overrider anonymement.

Fix. Les portes de gouvernance ne sont pas une étape séparée. Elles sont une propriété de l’étape de gate : chaque override est un reçu signé avec un texte de justification.

Étape ③ — Dérouler

8. Passer de 0 % à 100 % du trafic en une seule étape

Ce qui s’est passé. Un modèle a passé la porte proprement. Il a été poussé à 100 % du trafic immédiatement. Sur une particularité de longueur de conversation, le nouveau modèle dépassait son délai sur les réponses de plus de ~2 400 tokens — un comportement qui ne surgissait pas sur l’ensemble d’évaluation de 100 questions de la porte parce que chaque prompt de test était court. 15 % des utilisateurs ont eu un timeout pendant 18 minutes avant que quelqu’un ne fasse un rollback manuel.

Pourquoi le pipeline l’attrape désormais. L’étape Dérouler tient à 5 % pendant dwell_5pct_seconds (par défaut 240) OU requests_5pct (par défaut 1 000), selon le plus tardif. À 5 % de trafic, les timeouts de longue conversation surgissent dans le moniteur de taux 5xx en ~3 minutes. Le pipeline refuse d’avancer au-delà de 5 % si un moniteur de point de contrôle dépasse sa plage. Le temps moyen d’arrêt était de 4 minutes ; le temps moyen jusqu’au rollback complet était d’environ 12 secondes après l’arrêt.

Fix. Canary en trois étapes avec un moniteur de qualité, pas seulement la latence et les 5xx. Le pattern « cinq pour cent en vingt secondes et c’est fini » est le dangereux. Le pattern « cinq pour cent pendant quatre minutes » est le sûr.

Étape ④ — Observer

Les deux échecs ci-dessous sont ceux qu’un canary basé sur des métriques d’infrastructure aurait promus. La raison pour laquelle les métriques d’infrastructure les ratent est aussi structurelle — la latence et les 5xx peuvent rester parfaitement propres pendant que le modèle esquive, refuse, ou hallucine en silence.

9. Esquive silencieuse sur les requêtes juridiques (chute silencieuse de qualité n°1)

Ce qui s’est passé. Une mise à jour de modèle sensible à la sécurité a rendu l’assistant juridique nettement plus conservateur. Même latence, même taux 5xx, même usage de tokens. Mais là où la version précédente avait répondu « le délai de prescription est de X années », la nouvelle version disait « vous devriez consulter un avocat ». Les clients l’ont remarqué en quelques heures. Les tableaux de bord n’ont jamais bougé.

Pourquoi le pipeline l’attrape désormais. L’observateur de l’Étape 4 tourne un replay continu des traces de production à travers le modèle actif et les score avec le même juge calibré qui a alimenté Gate-2. L’esquive surgit immédiatement parce que le juge calibré — ancré sur des évaluations humaines de ce à quoi ressemble une « bonne » réponse juridique — pénalise le refus-quand-une-réponse-était-attendue. Le moniteur de qualité des sorties est descendu sous sa plage pendant trois minutes consécutives et le pipeline a fait un rollback automatique. Temps total écoulé : moins de cinq minutes.

Fix. Ne surveillez pas seulement la latence et les 5xx. Surveillez un score de qualité dérivé d’un juge calibré face à de vraies traces de production. Les garde-fous de déploiement de SageMaker^[2] font du rollback automatique sur des alarmes CloudWatch — utile pour l’infrastructure, mais l’alarme doit se déclencher sur une métrique, et « le modèle esquive » n’est pas une métrique que CloudWatch voit.

10. Dates hallucinées après un fine-tune (chute silencieuse de qualité n°2)

Ce qui s’est passé. Un fine-tune d’assistant de planification s’est mis à insérer avec assurance des dates qui n’existaient pas dans l’entrée. « Votre réunion est le jeudi 32 mars. » Latence inchangée. Taux 5xx inchangé. Les hallucinations passaient le filtre de sécurité parce que rien ne marquait « 32 mars » comme nuisible — juste impossible.

Pourquoi le pipeline l’attrape désormais. Le juge calibré de l’observateur — tournant sur de vraies traces de planification de production, pas synthétiques — donne aux réponses confiantes-mais-fausses un score pire que les refus appropriés « je ne sais pas ». La chute de la classe hallucination a déclenché le seuil par minute de l’observateur en deux minutes. Le rollback automatique s’est déclenché.

Fix. Un juge calibré face à l’expertise du domaine. Le LLM-as-judge générique ratera « jeudi 32 mars » de la même manière que les humains qui parcourent en diagonale le rateront. Les juges calibrés sur le domaine — ancrés face à des évaluations d’experts du domaine — ne le rateront pas.

Les 10 échecs mappés sur le pipeline

Les barres colorées en rouge sont les échecs que nous avons trouvés pendant que nous livrions ce pipeline — ce sont la raison pour laquelle nous avons fini par construire spécifiquement la porte consciente des tranches et l’observateur à replay de traces, au lieu de livrer un canary générique avec des métriques d’infrastructure comme tout le monde le fait.

En quoi le CI/CD pour LLM diffère-t-il du CI/CD logiciel ?

La version courte : une release LLM n’est pas un artefact déterministe. Le même prompt produit des sorties différentes d’une exécution à l’autre. Le même ensemble d’évaluation produit des scores différents selon le matériel. Le même modèle peut passer un contrôle de qualité agrégé tout en échouant silencieusement sur une tranche que vous n’aviez pas incluse dans l’éval. La plupart des hypothèses sur lesquelles le CI/CD traditionnel a été bâti ne survivent pas au contact avec un système probabiliste.

Trois conséquences concrètes :

1. Vous ne pouvez pas écrire d’assertions expect(output).toEqual(X). Il vous faut une évaluation consciente de la distribution qui consomme la corrélation de rang face à un correcteur ancré sur l’humain, pas l’égalité face à une fixture.
2. Un modèle « ayant passé le CI » peut livrer un comportement cassé. Le CI qui passe signifie que le code tourne. Cela ne signifie pas que le modèle a raison. Le pipeline de release doit imposer une porte de qualité par-dessus la porte de correction que le CI fournit.
3. Le rollback n’est pas optionnel et n’est pas lent. Parce que les modes d’échec sont probabilistes — et parce que certains d’entre eux sont silencieux au niveau de l’infrastructure — le chemin de rollback doit être une infrastructure de premier ordre, pas un plan de secours. Le manifeste de release existe spécifiquement pour rendre le rollback atomique.

Le premier billet de cette série décrit l’architecture en quatre étapes qui répond à ces conséquences. Ce billet décrit les échecs qu’elle attrape.

Comment construit-on un pipeline CI/CD résistant aux échecs pour des LMs personnalisés ?

La réponse honnête : vous acceptez que les échecs arriveront et vous minimisez le temps entre l’occurrence de l’échec et le retour du trafic de production à une version connue comme bonne. Le pipeline en quatre étapes ci-dessus est une implémentation spécifique de ce principe, mais c’est le principe lui-même qui compte.

Si vous n’utilisez pas Divinci et que vous voulez construire quelque chose d’équivalent, les pièces porteuses sont :

• Un manifeste de release immuable qui regroupe modèle + prompt + routage + dataset + préprocessing en un seul SHA. C’est ce qui rend 1, 2 et 3 attrapables. (Étape 1)
• Une porte par tranche avec des seuils définis par les propriétaires de domaine, pas les propriétaires de plateforme. C’est ce qui rend 4, 5 et 6 attrapables. (Étape 2)
• Un canary avec surveillance de la qualité à chaque point de contrôle, pas seulement la latence et les 5xx. C’est ce qui rend 8 attrapable et ce qui rend 9 et 10 survivables une fois qu’ils atteignent la production. (Étape 3)
• Un observateur continu qui score les vraies traces de production à travers le modèle actif avec le même juge calibré qui a alimenté la porte. C’est ce qui rend 9 et 10 attrapables. (Étape 4)
• Un reçu d’audit signé pour chaque décision. Chaîné par hash, ancrable en externe. Pour les modèles à poids ouverts, le reçu intègre une attestation de poids vindex prouvant que les poids actifs sont ceux que le manifeste a enregistrés. Pour les modèles à API fermée, le reçu couvre la chaîne de décision mais ne peut pas revendiquer la traçabilité des poids — et la piste d’audit le dit explicitement.

Les pièces ne sont pas nouvelles individuellement. Toute plateforme MLOps en a une ou deux. La combinaison — porte consciente des tranches + observateur sur traces de production + rollback atomique + reçu prouvable — est la partie que personne d’autre ne livre en 2026.

Où aller ensuite

• Le billet compagnon — Comment construire un pipeline CI/CD pour LLM avec Divinci AI — couvre l’architecture et l’API.
• La page de conformité documente le format des reçus vindex qui sous-tend chaque décision de release et comment il s’aligne sur l’EU AI Act, l’article 17 du RGPD, HIPAA et NIST AI RMF.
• La page produit AutoRAG couvre la réduction d’hallucinations côté RAG qui se marie naturellement avec le juge calibré qui pilote Gate-2 et l’observateur de l’Étape 4.
• La référence de l’API — chaque commande référencée dans cette série est un vrai endpoint.

FAQ

Quel est l’échec CI/CD le plus courant pour les modèles de langage personnalisés ?

À travers les releases que nous avons livrées, l’échec le plus dommageable est une régression consciente des tranches qui passe une porte agrégée — un modèle qui s’améliore en moyenne tout en s’effondrant silencieusement sur un sous-domaine spécifique (échecs 4, 5 et 6 ci-dessus). Il est plus courant qu’un rollback manquant, plus courant qu’une dérive de prompt, et plus difficile à détecter que l’un ou l’autre. Le fix est structurel, pas un réglage de paramètres : gater par tranche, pas sur la moyenne.

À quelle vitesse devriez-vous pouvoir faire un rollback d’une mauvaise release LLM ?

À l’ordre de grandeur des secondes, pas des minutes. Le temps moyen de rollback sur le pipeline Divinci est d’environ 12 secondes — c’est le drain des requêtes en cours sur un service à ~100 répliques, pas la bascule du manifeste elle-même, qui est sub-seconde. La décision architecturale qui rend cela possible est le manifeste de release groupé : parce que chaque composant (poids, prompt, routage, dataset) est référencé depuis un seul SHA, le rollback est un seul re-pointage atomique. Comparez cela aux postmortems publics : l’incident Cloudflare de juin 2022^[3] a pris 44 minutes pour être annulé parce que les ingénieurs se marchaient sur les reverts ; la panne Atlassian d’avril 2022^[4] a pris 12 heures par site affecté pour être restaurée parce que l’état était réparti sur plusieurs systèmes.

Pourquoi les changements de prompt causent-ils tant de pannes de production ?

Parce que les prompts sont régulièrement édités hors du pipeline CI/CD — dans des tableaux de bord, dans des UIs d’administration, parfois par des personnes sans revue d’ingénierie. Ils sont traités comme de la configuration, mais ils se comportent comme du code. Une édition de 38 caractères sur un prompt système peut changer le comportement du modèle en aval plus qu’un ré-entraînement du modèle. Le fix est d’enregistrer les prompts comme partie du manifeste de release et d’exiger qu’ils passent la même porte que le modèle passe.

Comment détecte-t-on une dégradation silencieuse de qualité dans les sorties LLM ?

Pas avec des métriques d’infrastructure. La latence, le taux 5xx et l’usage de tokens n’attraperont pas l’esquive, le refus-quand-une-réponse-était-attendue, ou les dates hallucinées. Le signal de détection doit venir d’un score de qualité calculé par un juge calibré face à de vraies traces de production. L’observateur de l’Étape 4 dans le pipeline Divinci rejoue un échantillon glissant de traces de production à travers le modèle actif, les score avec le même juge Spearman ancré sur l’humain qui a alimenté Gate-2, et déclenche un rollback automatique quand le score de qualité descend sous le seuil pendant trois minutes consécutives.

Quelles exigences de piste d’audit s’appliquent aux déploiements de modèles d’IA ?

L’EU AI Act, l’article 17 du RGPD (droit à l’effacement), HIPAA et le NIST AI Risk Management Framework exigent tous que les organisations conservent des enregistrements des versions de modèles, des résultats d’évaluation, des décisions d’approbation et des déploiements. L’exigence implicite sous-jacente aux quatre est que les enregistrements doivent être vérifiables — auditable signifie plus que « nous avons un log ». Les reçus vindex de Divinci sont chaînés par hash et ancrables en externe, ce qui signifie qu’un auditeur peut vérifier la chaîne sans faire confiance à nos logs. Pour les modèles à poids ouverts, le reçu intègre aussi une attestation de poids ; pour les modèles à API fermée, le reçu note explicitement que la traçabilité des poids n’est pas revendiquée.

Références

1. Tianpan — The Semver Lie: how an LLM minor update breaks production (avril 2026). Nomme directement le mode d'échec d'édition de prompt dans un tableau de bord. Compagnon : LLM postmortem template — fields SRE missed.
2. AWS SageMaker — Use canary traffic shifting. Le rollback automatique standard piloté par métriques d'infrastructure. Comparaison utile pour ce que l'Étape 4 Observer fait différemment (score de qualité, pas alarmes CloudWatch).
3. Cloudflare — Cloudflare outage on June 21, 2022. Revert de 44 minutes parce que les ingénieurs se marchaient sur les reverts. Cité comme l'ancrage « le rollback est son propre type d'incident ».
4. Atlassian — Post-Incident Review: April 2022 Outage. 12 heures par site pour restaurer. Le mode d'échec « état réparti sur plusieurs systèmes » dans sa pire forme.
5. DORA — Software delivery performance metrics. Le seuil elite-performer du « failed deployment recovery time » est documenté à moins d'une heure. Cadrage utile pour « à quelle vitesse est assez vite » sur le rollback.
6. Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (arXiv:2306.05685, 2023). La référence pour expliquer pourquoi le LLM-as-judge peut égaler les évaluations humaines globalement mais varier largement par catégorie — c'est exactement le pattern qui rend le gating par tranche nécessaire.

Suite de cette série : Validation et release de LMs personnalisés dans des domaines réglementés. Le pipeline ci-dessus est l’architecture. Le parcours de conformité est la pratique de son utilisation. EU AI Act, article 17 du RGPD, HIPAA et NIST AI RMF — ce que chacun demande à un processus de release, et quels champs de reçu vindex couvrent quelle exigence.