Déploiement d'un modèle adapté

Pourquoi ce chapitre est le plus critique du pipeline

Entraîner un modèle adapté est un problème borné : on dispose d'un jeu de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire, d'une métrique d'évaluation, et le processus s'arrête. Le déploiement, lui, ne s'arrête jamais. Un modèle en production est exposé à un trafic réel, à des distributions de requêtes qui dérivent avec le temps, à des contraintes de latence et de coût qui n'existaient pas en environnement d'entraînement. La majorité des incidents liés à l'IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire en production ne viennent pas d'un modèle mal entraîné, mais d'un déploiement mal maîtrisé : absence de rollback, versions non tracées, bascule à 100 % sans phase intermédiaire.

Ce chapitre traite le déploiement comme une discipline d'ingénierie à part entière, avec ses propres garanties à apporter : traçabilité de ce qui tourne, réversibilité rapide en cas de problème, et visibilité continue sur le comportement réel du modèle.

Un modèle fine-tuné qui n'est pas versionné, monitoré et réversible n'est pas prêt pour la production — quels que soient ses scores d'évaluation hors ligne.

Du modèle entraîné au modèle servi

Entre la fin d'un run d'entraînement et la première requête utilisateur traitée, plusieurs étapes distinctes doivent être franchies :

1. Export et conversion — le checkpoint issu de l'entraînement (souvent au format du framework d'entraînement) est converti vers un format optimisé pour l'inférenceinférenceIAUtilisation d'un modèle déjà entraîné sur une donnée nouvelle. Peu coûteuse à l'unité mais répétée à chaque requête, elle constitue le coût récurrent d'exploitation.Voir dans le glossaire.
2. Enregistrement dans un registre — le modèle reçoit un identifiant de version et des métadonnées associées.
3. Déploiement progressif — le modèle est exposé à un trafic croissant, généralement en plusieurs paliers.
4. Bascule en production — le modèle devient la version active servant l'intégralité du trafic.
5. Surveillance continue — le comportement en production est comparé en permanence aux attentes.

Omettre une de ces étapes ne fait pas disparaître le risque associé, il se contente de se déplacer plus tard dans le cycle de vie, souvent au moment le plus coûteux : après l'incident.

<rect x="190" y="120" width="150" height="70" rx="6" fill="none" stroke="currentColor" stroke-width="2"/>
<text x="265" y="150" text-anchor="middle" font-size="13" font-weight="700">Enregistrement</text>
<text x="265" y="168" text-anchor="middle" font-size="13" font-weight="700">registre</text>

<rect x="370" y="120" width="150" height="70" rx="6" fill="none" stroke="currentColor" stroke-width="2"/>
<text x="445" y="150" text-anchor="middle" font-size="13" font-weight="700">Déploiement</text>
<text x="445" y="168" text-anchor="middle" font-size="13" font-weight="700">progressif</text>

<rect x="550" y="120" width="150" height="70" rx="6" fill="none" stroke="currentColor" stroke-width="2"/>
<text x="625" y="150" text-anchor="middle" font-size="13" font-weight="700">Bascule</text>
<text x="625" y="168" text-anchor="middle" font-size="13" font-weight="700">100 % trafic</text>

<rect x="730" y="120" width="150" height="70" rx="6" fill="none" stroke="currentColor" stroke-width="2"/>
<text x="805" y="150" text-anchor="middle" font-size="13" font-weight="700">Surveillance</text>
<text x="805" y="168" text-anchor="middle" font-size="13" font-weight="700">continue</text>

<line x1="160" y1="155" x2="186" y2="155" stroke="currentColor" stroke-width="2" marker-end="url(#depArrow)"/>
<line x1="340" y1="155" x2="366" y2="155" stroke="currentColor" stroke-width="2" marker-end="url(#depArrow)"/>
<line x1="520" y1="155" x2="546" y2="155" stroke="currentColor" stroke-width="2" marker-end="url(#depArrow)"/>
<line x1="700" y1="155" x2="726" y2="155" stroke="currentColor" stroke-width="2" marker-end="url(#depArrow)"/>

<path d="M805,190 C805,240 85,240 85,194" fill="none" stroke="currentColor" stroke-width="1.5" stroke-dasharray="5,4" marker-end="url(#depArrow)"/>
<text x="445" y="260" text-anchor="middle" font-size="12">une dérive détectée en surveillance déclenche un rollback vers le registre</text>

Le serving : choisir comment le modèle répond

Le serving désigne l'infrastructure qui reçoit une requête, exécute l'inférence et renvoie une réponse. Trois familles de choix structurent cette couche.

Endpoint managé ou auto-hébergé

Un endpoint managé (proposé par un fournisseur cloud ou une plateforme spécialisée) délègue la gestion du matériel, de la scalabilité et d'une partie de la sécurité. C'est l'option la plus rapide à mettre en œuvre, adaptée quand l'équipe n'a pas de compétence MLOps dédiée ou quand le volume de requêtes reste modéré.

Un serving auto-hébergé (sur des GPUGPUIAProcesseur graphique parallélisant massivement les calculs matriciels ; indispensable à l'entraînement et à l'inférence des modèles de deep learning.Voir dans le glossaire loués ou possédés, avec des serveurs d'inférence comme vLLM, TGI ou Triton) offre un contrôle total sur la latence, le coût marginal par requête et la confidentialité des données. Il exige en contrepartie une équipe capable de gérer la scalabilité horizontale, le monitoring bas niveau et la reprise après incident matériel.

Le critère de décision n'est presque jamais technique en première intention : c'est un arbitrage entre coût d'opportunité (temps d'équipe à investir dans l'infrastructure) et coût marginal (prix par million de tokenstokenIAFragment de texte manipulé par un modèle de langage, généralement plus court qu'un mot — trois à quatre caractères en français. La tarification et la limite de contexte se comptent en tokens.Voir dans le glossaire ou par heure GPU) à un volume de trafic donné.

Quantization et formats d'inférence

Un modèle fine-tuné en précisionprécisionIAProportion des alertes émises par un modèle qui sont justifiées. Elle s'oppose au rappel : améliorer l'une dégrade l'autre.Voir dans le glossaire native (FP16 ou BF16) peut être trop lourd ou trop lent pour certains cas d'usage. La quantization réduit la précision numérique des poids (INT8, INT4, ou des formats mixtes comme GPTQ ou AWQ) pour diminuer l'empreinte mémoire et accélérer l'inférence, au prix d'une perte de qualité généralement faible mais jamais nulle.

Un modèle ayant subi un fine-tuningFine-tuningIAAjustement des poids d'un modèle pré-entraîné sur un jeu de données spécifique pour adapter son comportement à un domaine ou une tâche cible.Voir dans le glossaire sur une tâche étroite peut se dégrader de façon disproportionnée après quantization agressive, en particulier sur les cas limites que le fine-tuningaffinageIAPoursuite de l'entraînement d'un modèle existant sur des données propres à un usage. Il enseigne une manière de répondre, non des connaissances fiables — d'où la préférence pour le RAG en entreprise.Voir dans le glossaire visait justement à corriger. Il faut réévaluer le modèle quantifié sur le jeu de testjeu de testIAPartie des données réservée à l'évaluation finale, à n'utiliser qu'une seule fois. Ajuster le modèle d'après ses résultats sur ce jeu lui ôte toute valeur de mesure indépendante.Voir dans le glossaire métier, pas seulement sur des benchmarks génériques.

Batching et gestion de la latence

Le batching dynamique regroupe plusieurs requêtes concurrentes pour les traiter en un seul passage GPU, ce qui améliore le débit global au prix d'une latence légèrement accrue pour les requêtes individuelles. Le réglage de la taille de batch et du délai d'attente maximal (souvent quelques dizaines de millisecondes) est un compromis direct entre débit et latence perçue par l'utilisateur — un paramètre à ajuster selon que l'usage est interactif (chat) ou différé (traitement par lot).

Versioning : savoir exactement ce qui tourne

Le registre de modèles

Un registre de modèles centralise chaque version entraînée avec ses métadonnées : identifiant unique, dataset d'entraînement utilisé, hyperparamètreshyperparamètreIARéglage choisi avant l'entraînement — vitesse d'apprentissage, taille du modèle, nombre d'itérations. Il se distingue des paramètres, ajustés automatiquement pendant l'entraînement.Voir dans le glossaire, scores d'évaluation, empreinte du modèle de base, date et auteur. Sans registre, la question « quelle version tourne actuellement en production et sur quelles données a-t-elle été entraînée ? » devient impossible à répondre de façon fiable au bout de quelques itérations.

Sémantique de version

Une convention de nommage explicite évite les ambiguïtés. Un schéma courant reprend la logique du versioning sémantique adapté au machine learningapprentissage automatiqueIABranche de l'IA où le programme dégage lui-même ses règles à partir d'exemples, au lieu de les recevoir d'un développeur. C'est ce déplacement des règles écrites vers les régularités apprises qui définit l'IA moderne.Voir dans le glossaire :

Traçabilité complète

Au-delà du numéro de version, chaque entrée du registre doit permettre de reconstituer intégralement les conditions d'entraînement : version exacte du dataset (avec hash ou identifiant immuable), configuration d'entraînement, résultats des évaluations automatiques et, si elles existent, des évaluations humaines. Cette traçabilité est ce qui permet, des mois plus tard, de comprendre pourquoi un comportement particulier est apparu — ou de reproduire un entraînement à l'identique.

Le registre n'est pas qu'un outil de conformité. C'est la première ligne de défense en cas d'incident : sans lui, un rollback devient une reconstruction archéologique sous pression.

Stratégies de déploiement progressif

Basculer directement d'une ancienne version vers une nouvelle à 100 % du trafic revient à parier l'ensemble de la production sur des évaluations hors ligne — qui, aussi soignées soient-elles, ne couvrent jamais parfaitement la distribution réelle des requêtes. Trois stratégies limitent ce risque.

Shadow deployment

La nouvelle version reçoit une copie du trafic réel mais ses réponses ne sont jamais envoyées à l'utilisateur — elles sont uniquement enregistrées et comparées à celles de la version en production. Cette approche permet de mesurer la latence, le coût et la divergence de comportement sans aucun risque pour l'utilisateur final. Sa limite : elle ne mesure pas l'impact sur des métriques qui dépendent d'une interaction réelle (taux de conversion, satisfaction exprimée).

Canary release

La nouvelle version reçoit un pourcentage croissant du trafic réel — typiquement 5 %, puis 25 %, puis 50 %, puis 100 % — avec un palier d'observation entre chaque étape. Le déploiement s'arrête et repasse à la version précédente automatiquement si des seuils prédéfinis (taux d'erreur, latence, signaux de qualité) sont dépassés à un palier donné.

Blue-green

Deux environnements de production identiques coexistent (« bleu » et « vert »). Le trafic bascule d'un coup de l'un vers l'autre au niveau du routeur, ce qui rend le retour arrière quasi instantané puisque l'ancien environnement reste actif et prêt à reprendre le trafic. Cette stratégie protège bien contre les défaillances techniques (crash, erreurs serveur) mais, contrairement au canary, elle expose l'ensemble du trafic dès la bascule et ne détecte donc pas une dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire de qualité progressive avant qu'elle touche 100 % des utilisateurs.

Une équipe déploie une version fine-tunée d'un modèle de classification de tickets support. En shadow pendant 48 heures, la nouvelle version affiche une latence supérieure de 15 % sans gain de précision mesurable — le déploiement est annulé avant tout impact utilisateur, simplement en observant les journaux comparatifs.

Rollback : concevoir le retour arrière avant d'en avoir besoin

Un rollback improvisé au moment de l'incident prend systématiquement plus de temps et comporte plus de risques qu'un rollback préparé à l'avance. Trois éléments doivent être définis avant tout déploiement, pas pendant l'incident.

Déclencheurs de rollback

Les seuils doivent être quantifiés et automatisables autant que possible :

• Taux d'erreur applicatif au-delà d'un seuil (par exemple, doublement du taux de requêtes en échec).
• Latence P95 ou P99 dépassant un plafond défini pour l'usage concerné.
• Signaux de qualité issus d'un échantillonnage automatique ou d'un modèle juge, en particulier pour détecter une hausse des réponses hors-sujet ou des refus inattendus.
• Signaux métier en aval — chute d'un taux de conversion, hausse des escalades vers un humain dans un cas d'usage support.

Rollback automatique versus manuel

Un rollback automatique, déclenché par des seuils codés dans le pipeline de déploiement, réduit le temps de réaction à quelques minutes mais exige une confiance élevée dans les métriques de déclenchement — un faux positif provoque un retour arrière inutile et une perte de continuité. Un rollback manuel, validé par un humain d'astreinte, réduit ce risque de faux positif mais suppose une astreinte réactive et des tableaux de bord suffisamment clairs pour une décision rapide. En pratique, la plupart des équipes matures combinent les deux : rollback automatique sur les seuils techniques (erreurs, latence), validation humaine sur les seuils de qualité plus ambigus.

Ce que le rollback doit garantir

Un rollback réussi restaure non seulement le modèle précédent mais aussi toute la configuration associée (prompt système, paramètres d'inférence, filtres de sécurité) qui a été validée conjointement avec cette version. Faire revenir le modèle sans revenir sur sa configuration associée reproduit un système qui n'a jamais été testé dans cette combinaison précise.

Revenir à une version antérieure signifie aussi revenir sur ses limites connues. Si le déploiement visait à corriger un biaisbiaisIARégularité correctement apprise dans des données qui ne représentent pas la réalité visée, ou qui enregistrent des décisions passées avec leurs préjugés. Changer d'algorithme ne le corrige pas.Voir dans le glossaire ou une faille de sécurité, le rollback les réintroduit. Documenter ce compromis avant d'appuyer sur le bouton évite une fausse impression de sécurité retrouvée.

Monitoring post-déploiement

Le déploiement n'est pas un événement ponctuel mais l'entrée dans une phase de surveillance continue.

Dérive de performance

Un modèle fine-tuné est optimisé pour une distribution de données observée à un instant donné. Cette distribution évolue : nouveaux types de requêtes, changement de vocabulaire métier, évolution du comportement des utilisateurs. Cette dérive (souvent appelée drift) ne se détecte pas en observant uniquement les métriques d'entraînement — elle nécessite un échantillonnage continu du trafic réel, comparé périodiquement au jeu de référence.

Boucle de rétroaction

Les signaux de production — corrections manuelles, signalements utilisateurs, cas d'échec identifiés — doivent remonter vers l'équipe responsable du fine-tuning, pas seulement vers l'équipe d'exploitation. Un déploiement sans boucle de retour vers les données d'entraînement transforme chaque itération future en un nouveau départ, sans capitaliser sur ce que la production a révélé.

Checklist avant mise en production

• Le modèle est enregistré dans le registre avec version, dataset et scores d'évaluation associés.
• Le modèle a été testé en configuration de serving cible (format, quantization) sur le jeu de test métier, pas uniquement en précision native.
• Une phase de shadow ou de canary est planifiée, avec seuils de déclenchement définis à l'avance.
• La procédure de rollback est documentée, testée au moins une fois en environnement de pré-production, et inclut la configuration associée (prompts, filtres).
• Les tableaux de bord de monitoring (latence, erreurs, dérive de qualité) sont en place avant la première requête réelle.
• Un responsable d'astreinte est identifié pour la fenêtre suivant le déploiement.
• Une boucle de remontée des cas d'échec vers l'équipe de fine-tuning est active.

Pièges fréquents

• Confondre validation hors ligne et validation en production. Un score d'évaluation élevé sur un jeu de test ne garantit rien sur la distribution réelle du trafic.
• Basculer à 100 % sans palier intermédiaire pour gagner du temps sur un déploiement perçu comme urgent — c'est précisément dans ce contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire que l'absence de palier coûte le plus cher.
• Versionner le modèle sans versionner sa configuration d'inférence. Un même modèle avec un prompt système différent peut se comporter de façon radicalement différente.
• Définir des seuils de rollback après l'incident plutôt qu'avant le déploiement, ce qui transforme chaque décision en débat improvisé sous pression.
• Négliger le monitoring après la bascule à 100 %, en considérant à tort que la phase critique est terminée une fois le déploiement complet — c'est au contraire le moment où la dérive de distribution commence réellement à s'accumuler.

Un déploiement maîtrisé ne cherche pas à éliminer le risque, ce qui est impossible, mais à le rendre visible et réversible. C'est cette réversibilité — plus que la sophistication du modèle lui-même — qui détermine si une organisation peut itérer en confiance sur ses modèles adaptés.