CI/CD pour modèles LLM dans un SaaS : pipeline complet pour CTO et lead dev

CI/CD pour modèles LLM dans un SaaS : pipeline complet pour CTO et lead dev

Pourquoi un pipeline CI/CD spécifique aux modèles LLM ? Parce qu'un assistant IA en production n'est pas qu'un service web : il combine code applicatif, artefacts modèles (poids, tokenizers), données de test, images conteneurisées et exigences de sécurité/supply-chain. Ce guide technique montre un pipeline reproductible et sécurisé pour construire, tester et déployer modèles LLM et microservices dans un SaaS multienvironnement (dev → staging → prod).

Vue d'ensemble du pipeline (phases)

1. Contrôle de source et déclencheurs (Git branches / monorepo ou repo séparés).
2. Build : packaging du modèle (MLflow / DVC), construction d'image Docker (buildx).
3. Tests : unitaires, tests d'inférence, tests de performance et tests de contrat.
4. Analyse de sécurité & SBOM (Trivy, SLSA guidance).
5. Publication : push image vers registry, push artefact modèle vers Model Registry.
6. CD GitOps : Argo CD / flux pour appliquer manifests et rollouts (canary/blue-green).
7. Observabilité & monitoring post-déploiement (latence p50/p95, erreurs, dérive modèle).

Exemples et outils montrés : GitHub Actions + docker/build-push-action pour le build, MLflow pour packager/registrer le modèle, Trivy pour scan sécurité, Argo CD pour GitOps. Ces choix sont illustratifs ; adaptez selon votre stack.

1) Packaging et versioning du modèle

Objectif : produire un artefact versionné (weights + metadata) que la CD-consumer pourra déployer. Une pratique courante est d'utiliser un model registry (ex. MLflow) pour référencer versions et métadonnées.

Exemple Python minimal pour logguer et enregistrer un modèle avec MLflow :

import mlflow
from my_llm_wrapper import MyLLMModel

with mlflow.start_run():
    model = MyLLMModel.train(...)  # entraînement hors pipeline CI
    mlflow.pyfunc.log_model("model", python_model=model)
    mv = mlflow.register_model("runs:/%s/model" % mlflow.active_run().info.run_id, "my-llm-model")
# Le registry conserve name/version, metadonnées et permet déploiement contrôlé

MLflow fournit un format standard pour packager et déployer des modèles. Utiliser un model registry évite de pousser des fichiers binaires "naked" dans un registry non structuré. ([mlflow.org](https://www.mlflow.org/docs/latest/ml/model/?utm_source=openai))

2) Build : Dockerfile modèle + workflow CI (build & push)

Template Dockerfile pour un serveur d'inférence léger :

FROM python:3.10-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY server.py .
COPY model/ ./model/
EXPOSE 8080
CMD ["uvicorn", "server:app", "--host", "0.0.0.0", "--port", "8080"]

Exemple de workflow GitHub Actions pour builder et pousser l'image vers un registry (Docker Hub ou GHCR). Utilisez buildx pour multi-arch si besoin.

name: ci-build-push
on:
  push:
    branches: [ main, release/* ]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Log in to registry
        uses: docker/login-action@v2
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GHCR_TOKEN }}
      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ghcr.io/org/my-llm:${{ github.sha }}

GitHub Actions et le build-push-action permettent d'automatiser build+push d'images depuis le pipeline CI. Pensez à signer ou produire une SBOM durant le build pour la traçabilité. ([docs.github.com](https://docs.github.com/actions/tutorials/publishing-packages/publishing-docker-images?utm_source=openai))

3) Tests automatisés spécifiques aux modèles

• Unit tests : fonctions utilitaires, data loaders.
• Inference tests : charger l'artefact et vérifier réponses sur prompts canoniques (sémaphores pour outputs non déterministes).
• Performance tests : mesurer latence p50/p95, throughput sous charge simulée.
• Contract tests / smoke tests : endpoint health + checks d'input/output shapes.

Exemple simple d'inférence test (pytest) :

def test_inference_basic(tmp_path):
    model_path = "/tmp/model"  # récupéré depuis artefact CI
    client = load_model_client(model_path)
    out = client.predict("Quel est le capital de la France ?")
    assert "Paris" in out or len(out) > 0

4) Sécurité de la supply chain et scans

Avant de publier une image, exécutez un scan vulnérabilités et générez une SBOM. Trivy permet d'automatiser ces checks dans CI et de bloquer la publication si CVE critiques sont détectés.

# Example: scan image with trivy
trivy image --format table ghcr.io/org/my-llm:${{ github.sha }}
# Option to fail on critical:
trivy image --severity CRITICAL,HIGH --exit-code 1 ghcr.io/org/my-llm:${{ github.sha }}

Adopter des principes SLSA pour durcir la chaîne de build (provenance, signatures, artefacts immuables). Ces pratiques limitent les risques d'injection malveillante dans vos images/artefacts. ([trivy.dev](https://trivy.dev/docs/latest/guide/target/container_image/?utm_source=openai))

5) CD GitOps : Argo CD pour déployer depuis Git

Stratégie recommandée : la CI met à jour un manifeste (helm values ou Kustomize) avec le tag d'image et commit dans le repo infra. Argo CD détecte le changement et sync automatiquement l'environnement cible. Cela isole CI des accès Kubernetes directs et donne un historique audit-able dans Git. ([argo-cd.readthedocs.io](https://argo-cd.readthedocs.io/en/stable/user-guide/auto_sync/?utm_source=openai))

# exemple : mise à jour automatisée d'un value.yaml (simplifié)
image:
  repository: ghcr.io/org/my-llm
  tag: v1.2.3-

Pour rollouts plus sûrs, combinez Argo CD avec stratégies canary/blue-green ou Argo Rollouts (traffic splitting) et vérifiez health checks avant promotion en prod.

6) Observabilité et dérive modèle

Surveillez :

• Performance infra : p50/p95 latency, CPU/GPU usage.
• Qualité modèle : taux d'échec des réponses, drift distributionnel sur embeddings/features.
• Business metrics : taux de satisfaction utilisateur, taux d'escalade vers humain.

Exemple d'objectifs : p95 inference < 300 ms (si inference serveur CPU), disponibilité 99.9% selon SLA. Ajustez selon contexte et budget.

Bonnes pratiques, pièges et conseils

• Tagging immuable : ne jamais déployer l'image "latest" en production. Utilisez git-sha ou numéro de version sémantique.
• Séparer code et artefact modèle : le pipeline CI doit pouvoir rebuild le service sans réentraîner le modèle.
• SBOM & provenance : générez SBOM et stockez métadonnées du build (SLSA style) pour audits.
• Fail fast sur vulnérabilités critiques : bloquez la promotion vers prod automatiquement.
• Tests flakiness des LLM : isoler tests non déterministes avec tolérances et seeds, et privilégier tests basés sur propriétés plutôt que phrases exactes.
• Utilisez canary + métriques santé pour détecter dégradation causée par nouveau modèle.

Implémentation rapide : checklist CI/CD

1. Mettre en place model registry (ex. MLflow) et format de packaging. ([mlflow.org](https://www.mlflow.org/docs/latest/ml/model/?utm_source=openai))
2. CI : build image + empaqueter modèle + SBOM + scan vulnérabilités (Trivy). ([trivy.dev](https://trivy.dev/docs/latest/guide/target/container_image/?utm_source=openai))
3. Commit manifeste infra avec image tag et déclencher CD GitOps (Argo CD). ([argo-cd.readthedocs.io](https://argo-cd.readthedocs.io/en/stable/user-guide/auto_sync/?utm_source=openai))
4. Déploiement canary/monitoring et roll-back automatisé.
5. Surveillance continue de la dérive modèle et procédure d'alerte.

Exemples d'erreurs fréquentes

• Push direct en prod (contourne la traçabilité GitOps).
• Ignorer SBOM/scan : augmente risque d'exposer vulnérabilités connues.
• Méconnaître coût inference GPU en prod (coût non maîtrisé si modèles lourds).
• Tester uniquement en offline : l'API peut échouer sur comportements réseau/latence.

Pour aller plus loin, intégrez ces pipelines dans votre stratégie SaaS et logicielle : packaging modèle & CI s'intègrent naturellement à vos processus de développement d'application SaaS et d'ERP/CRM. Si vous utilisez Docker de façon intensive, la page technique de Novane sur Docker contient d'autres bonnes pratiques.

Conclusion — À la fin de ce guide vous devez pouvoir : définir un workflow CI qui genere un artefact modèle versionné, scanner/valider l'image, et déployer via GitOps avec rollbacks automatiques. L'effort initial paye rapidement en traçabilité, sécurité et capacité à itérer sur les modèles sans surprises.

Si vous souhaitez un diagnostic adapté à votre architecture (MVP, multitenant, contraintes GPU, ou conformité), contactez notre équipe pour une séance de consulting technique. Contactez-nous ou demandez un devis.