Utiliser efficacement les feature flags pour désactiver des dépendances lourdes (ex. ONNX)

Par Emmanuel Forgues - 25 août 2025

Chapô – Les feature flags (ou commutateurs fonctionnels) sont un pilier du DevOps moderne pour livrer du code en continu tout en maîtrisant le risque fonctionnel. Lorsqu’une fonctionnalité repose sur une bibliothèque ou un composant lourd – comme les modèles d’inférence ONNX, les moteurs de rendu GPU ou les bibliothèques de traitement vidéo – la capacité à activer ou désactiver dynamiquement cette dépendance est un avantage stratégique. Ce texte analyse le principe des feature flags, leur rôle dans la gestion des dépendances lourdes en production, les bonnes pratiques d’architecture, de sécurité et de gouvernance, ainsi qu'une feuille de route pour les organisations souhaitant les adopter à grande échelle.

Publié initialement le 25 août 2025.

Mis à jour le 4 mai 2026.

Migré vers StratoSentry le 14 avril 2026.

Introduction – Le défi des dépendances massives dans un environnement CI/CD

Dans une organisation où le déploiement continu (CI/CD) est la norme, chaque commit peut toucher plusieurs services micro‑services, fonctions serverless ou pipelines de données. Introduire une nouvelle capacité d’inférence basée sur le format ONNX (Open Neural Network Exchange) implique souvent :

• un runtime de plusieurs dizaines de mégaoctets,
• des dépendances natives (CUDA, cuDNN, etc.) qui varient selon l’OS et la version du driver,
• un temps de démarrage allongé du processus d’application,
• une consommation CPU/GPU non négligeable même lorsqu’elle n’est pas utilisée.

Ces caractéristiques rendent le déploiement “tout‑ou-rien” risqué<0xE2><0x80><0xAF>: une mise à jour introduisant la prise en charge d’ONNX peut entraîner des régressions, augmenter les coûts d’infrastructure ou déclencher des incidents de sécurité si la bibliothèque comporte des vulnérabilités non patchées.

Les feature flags permettent de séparer le déploiement du lancement, afin de :

• Déployer le code et les dépendances une fois pour toutes, sans impacter immédiatement les utilisateurs,
• Activer la fonctionnalité uniquement sur des environnements cibles (ex. : canary, groupes d’utilisateurs),
• Désactiver rapidement en cas de problème, sans rollback complet du service.

Le cadre suivant détaille la mise en œuvre de ce principe pour ONNX, tout en garantissant la résilience opérationnelle, la sécurité et la conformité.

1. Feature flags : définitions, typologies et enjeux

Les feature flags sont décrits par Martin<0xE2><0x80><0xAF>Fowler et al.<0xE2><0x80><0xAF>: “Feature Toggles”<0xE2><0x80><0xAF>[1]. Ils répondent à trois objectifs fondamentaux :

• Release Management – Découpler le moment du déploiement du moment de la mise à disposition.
• Experimentation – Faciliter les tests A/B, canary releases ou dark launches.
• Mitigation des risques – Offrir un bouton d’arrêt immédiat en cas de régression.

2. Pourquoi les dépendances lourdes (ex. ONNX) posent problème

2.1 Charge de démarrage et consommation de ressources

Le runtime ONNX (onnxruntime) peut atteindre 200 Mo en mémoire dès le premier chargement, avec des bibliothèques supplémentaires pour le support GPU pouvant dépasser les 500 Mo. Dans un environnement à forte densité (ex. : 100 pods Kubernetes), cela représente plusieurs dizaines de gigaoctets de RAM inutiles si la fonctionnalité n’est pas encore utilisée.

2.2 Complexité d’infrastructure

Les dépendances natives (CUDA, drivers GPU) imposent une hétérogénéité du cluster : certains nœuds doivent être équipés de GPUs, d’autres non. Gérer cette contrainte via des node‑affinity ou taints/tolerations augmente la charge opérationnelle.

2.3 Risques de sécurité

Les bibliothèques tierces sont régulièrement affectées par des vulnérabilités (CVE). Par exemple, une faille dans onnxruntime détectée en 2023‑08 a concerné le parsing d’opérateurs malformés [2]. Si la dépendance est chargée mais jamais utilisée, le vecteur d’attaque reste présent tant que le code est exécuté.

2.4 Coût économique

Le facturation à l’usage du GPU (ex. : $0,90 / heure sur AWS) devient prohibitif si les pods restent alloués sans réellement exécuter de requêtes d’inférence.

Ces constats justifient l'instauration d'un contrôle fin via des feature flags pour ne charger le runtime ONNX que lorsqu’une réelle demande existe.

3. Principes d’architecture du basculement conditionnel

3.1 Découplage via un Feature Management Service (FMS)

┌─────────────────────┐        ┌───────────────────────────┐
│   Application API   │◀──────▶│ Feature Management Service │
│ (Python/Go/Java…)   │        │  (LaunchDarkly, Azure App)│
└─────────▲───────────┘        └───────▲─────────────────────┘
          │                            │
   Runtime ONNX ←─────► Flag «onnx_enabled»

• Le FMS centralise la définition des flags (stockage, versionnage, ciblage).
• Les clients récupèrent le flag à chaque appel ou via un cache rafraîchi périodiquement.
• La décision d’invoquer onnxruntime est prise au niveau du code métier, ce qui évite toute initialisation prématurée.

3.2 Isolation des dépendances lourdes

Pour un usage fréquent mais contrôlé, le lazy loading couplé au FMS est la solution la plus simple et économique.

4. Mise en œuvre technique – Patterns de feature flag

4.1 SDKs et bibliothèques courantes

• LaunchDarkly SDK (Java, .NET, Node.js, Go) [3]
• Azure App Configuration + Feature Management [4]
• Unleash (open‑source) [5]

Ces kits offrent :

• Un client léger qui met en cache les drapeaux,
• Des API de ciblage granulaires (par environnement, groupe d’utilisateurs, version d’application),
• La possibilité de définir des règles de fallback pour garantir la continuité.

4.2 Exemple de code – Python avec lazy loading

import os
from launchdarkly_sdk import LaunchDarklyClient

ld_client = LaunchDarklyClient(sdk_key=os.getenv("LD_SDK_KEY"))
ld_client.initialize()

def predict(input_tensor):
    # Lecture du flag à chaque appel (ou via cache local)
    if not ld_client.bool_variation("onnx_enabled", user={"key": "service-instance"}, default=False):
        raise RuntimeError("ONNX inference désactivée")

    # Chargement paresseux du runtime
    global ort_session
    try:
        ort_session
    except NameError:
        import onnxruntime as ort
        ort_session = ort.InferenceSession("model.onnx", providers=['CPUExecutionProvider'])

    return ort_session.run(None, {"input": input_tensor})

Le flag est évalué à chaque appel, mais le runtime n’est chargé qu’une seule fois grâce au global.

4.3 Gestion du cycle de vie des flags

5. Gestion des dépendances lourdes avec les flags

5.1 Chargement différé et libération de ressources

Lorsque le flag passe à false, il faut s’assurer que le runtime est correctement déchargé afin de libérer la RAM :

if not ld_client.bool_variation("onnx_enabled", user, default=False):
    if 'ort_session' in globals():
        del ort_session   # libère les objets C++ sous‑jacents
        import gc; gc.collect()

Dans des environnements Java ou .NET, le même principe s’applique via la réflexion et le ClassLoader dédié.

5.2 Versioning du modèle ONNX

Le flag peut également porter un payload (ex. : version du modèle) :

{
  "key": "onnx_enabled",
  "value": true,
  "variationId": "v3",   // indique le fichier model_v3.onnx
  "targets": [...]
}

Le service lit ce payload et charge le modèle correspondant, facilitant les déploiements de modèles A/B sans redéployer l’application.

5.3 Isolation au niveau du conteneur

Pour les organisations qui ne souhaitent pas que la présence même de onnxruntime soit visible dans tous les pods, elles peuvent :

• Construire deux images Docker – une light (sans ONNX) et une full (avec).
• Utiliser le flag pour choisir dynamiquement quel image déployer via un pipeline CI/CD (helm upgrade --set onnx.enabled=true).

6. Impacts sur la sécurité et la conformité

7. Gouvernance, observabilité et tests

7.1 Observabilité du basculement

• Métriques – Exporter un compteur feature_flag_state{flag="onnx_enabled",value="true"} via Prometheus.
• Logs – Ajouter le champ feature=onnx aux traces distribuées (OpenTelemetry) pour corréler les requêtes à l’état du flag.
• Alertes – Déclencher une alerte si le taux d’erreurs augmente dès que le flag passe à true.

7.2 Tests automatisés

7.3 Processus de gouvernance

• Définition du propriétaire – Un Feature Owner (souvent un Product Manager) valide l’usage du flag.
• Revue de changement – Toute modification du flag passe par un Change Advisory Board (CAB) incluant DSI, RSSI et DPO si les données sont sensibles.
• Documentation vivante – Le registre des flags doit être versionné dans le même dépôt que le code source (ex. : flags.yaml).

8. Cas d’usage concret : déploiement progressif d’un modèle de recommandation ONNX

Contexte

Une plateforme e‑commerce souhaite enrichir son moteur de recommandations avec un modèle Transformer entraîné en Python et exporté au format ONNX. Le service reco-service tourne sur Kubernetes, 8 pods en moyenne, chaque pod étant limité à 500 MiB de RAM.

Architecture proposée

+-------------------+        +---------------------------+
|   Front‑end API   | <---> |  reco‑service (Python)    |
+-------------------+        |  - Lazy load ONNX runtime |
                             |  - Feature flag «onnx_v2» |
                             +------------▲--------------+
                                          |
                               +----------+-----------+
                               | Feature Management   |
                               | Service (LaunchDarkly)|
                               +----------------------+

Étapes de mise en œuvre

| 3. Montée progressive | Augmenter le pourcentage à 30 % puis 60 %, tout en surve

Poursuivre le parcours : Conformité NIS2, DORA et RGPD → Solution → Produit → Demander une démonstration

Retour au blog