Leçon 5 — La dépendance
Poser la question correctement
« Sommes-nous enfermés chez notre fournisseur ? » est une question mal formulée, parce qu'elle appelle une réponse binaire alors que la dépendance a des degrés et des formes très différentes.
La question utile est : si nous devions changer, qu'est-ce que cela coûterait, et pour chaque composant ? Cela se répond concrètement, et cela permet de décider où investir dans la portabilité et où l'accepter.
Voici les cinq formes, de la plus coûteuse à la moins gênante.
Forme 1 — La gravité des données
La plus coûteuse, et la plus sous-estimée.
Vos données s'accumulent dans le cloud. Elles pèsent des téraoctets. Les déplacer coûte des frais de sortie — voir la leçon 3 — et du temps. Surtout, tout ce qui les entoure s'est construit autour : les outils qui les lisent, les pipelines qui les alimentent, les droits d'accès, les tableaux de bord.
On appelle cela la gravité des données : plus les données sont volumineuses, plus elles attirent les traitements à elles, et moins elles sont mobiles.
Ce qui limite réellement le risque :
- Stocker dans des formats ouverts — Parquet, ORC, Avro pour les données structurées ; formats standard pour les images et le texte — plutôt que dans un format propriétaire lisible par un seul service.
- Préférer les formats de tables ouverts — Delta Lake, Iceberg — aux entrepôts entièrement propriétaires quand le choix existe.
- Éviter la duplication inutile : moins de volume, moins de gravité.
Une note utile : la réglementation européenne sur les données impose désormais aux fournisseurs de faciliter le changement de prestataire et encadre les frais de transfert dans ce cadre. Plusieurs grands acteurs ont supprimé les frais de sortie liés à une migration. Cela réduit le coût financier, pas le coût d'ingénierie.
Forme 2 — Les services propriétaires profondément intégrés
Un pipeline construit avec les briques natives d'une plateforme — orchestration, magasin de variables, registre, points de terminaison — ne se transpose pas ailleurs. Il faut le réécrire.
Le point important : ce n'est pas nécessairement un mauvais choix. Ces services vous font gagner un temps considérable et suppriment beaucoup de travail d'exploitation. Refuser les services managés pour rester portable coûte souvent plus cher que la migration hypothétique qu'on cherche à préparer.
Le compromis raisonnable :
- Gardez le code d'entraînement dans des conteneurs standard, exécutables partout. Un conteneur qui prend des données en entrée et produit un modèle en sortie se déplace en une journée.
- Acceptez la dépendance sur l'orchestration et l'exploitation, qui sont plus faciles à reconstruire qu'à porter.
- Refusez la dépendance sur la logique métier : les transformations qui définissent vos variables doivent être dans votre code, pas dans une configuration de plateforme.
Forme 3 — Le format des modèles
Souvent cité, et le moins grave des cinq.
Un modèle entraîné dans un cadriciel standard — PyTorch, TensorFlow, scikit-learn — s'exporte et se recharge ailleurs sans difficulté. ONNX est un format d'échange ouvert qui rend un modèle exécutable sur presque n'importe quel environnement.
Ce qui pose vraiment problème : les modèles entraînés par un AutoML propriétaire, qui ne sont parfois pas exportables du tout. Si vous utilisez l'AutoML d'une plateforme, vérifiez avant que le modèle est exportable, et pas au moment où vous voulez partir.
Forme 4 — Les compétences et les processus
La forme la plus discrète, et souvent la plus déterminante en pratique.
Votre équipe connaît une plateforme. Vos procédures, vos scripts, vos tableaux de bord, vos habitudes de diagnostic, vos contrats sont bâtis dessus. Changer signifie une baisse de productivité pendant des mois, indépendamment de toute question technique.
C'est cette dépendance qui, en réalité, empêche la plupart des migrations. Elle ne se supprime pas ; elle se reconnaît dans la décision.
Forme 5 — La dépendance aux API de modèles
Une forme récente, propre aux systèmes génératifs, et particulièrement inconfortable parce que vous ne contrôlez pas l'objet dont vous dépendez.
Quatre risques concrets, déjà signalés dans le cours sur les LLM :
Le modèle change sous vos pieds. Le fournisseur met à jour, et votre système se dégrade sans que vous ayez rien touché — vos consignes avaient été ajustées à l'ancien comportement.
Le modèle est retiré. Les versions anciennes sont dépréciées, avec un délai qui n'est pas toujours confortable. La migration devient obligatoire à une date que vous ne choisissez pas.
Le prix change. Votre modèle économique dépend d'un tarif que vous ne maîtrisez pas.
Les conditions changent. Restrictions d'usage, quotas, exigences de conformité.
Ce qui limite réellement le risque :
- Épingler une version précise du modèle, jamais un alias générique.
- Abstraire l'appel derrière votre propre interface, de façon à pouvoir changer de fournisseur sans réécrire l'application. C'est quelques dizaines de lignes de code, et cela vaut très largement l'effort.
- Maintenir un jeu d'évaluation figé qui permet de tester rapidement un modèle alternatif — le dispositif décrit dans le cours MLOps.
- Tester périodiquement un modèle de repli, ouvert ou d'un autre fournisseur, pour savoir ce que coûterait le basculement.
Le tableau de l'exposition réelle
| Forme de dépendance | Coût de sortie | Priorité d'action |
|---|---|---|
| Gravité des données | élevé | formats ouverts, éviter la duplication |
| Services propriétaires intégrés | moyen à élevé | garder l'entraînement en conteneurs |
| Format des modèles | faible | vérifier l'export de l'AutoML |
| Compétences et processus | élevé | à reconnaître, non à supprimer |
| API de modèles | moyen | épingler, abstraire, garder un repli testé |
Ce qu'il faut faire, concrètement
La position défendable n'est ni « tout portable », qui coûte cher en efficacité, ni « on verra », qui coûte cher le jour où il faut partir.
Cinq décisions suffisent :
- Formats de données ouverts dès le départ. Coût nul, bénéfice durable.
- Code d'entraînement en conteneurs standard, prenant des données en entrée et produisant un modèle en sortie.
- Logique métier dans votre code, pas dans la configuration de la plateforme.
- Abstraction des appels d'API de modèles derrière une interface maison.
- Un document d'une page décrivant le chemin de sortie : quoi migrer, dans quel ordre, avec quelle estimation de délai. Rédigé une fois, relu chaque année.
Ce dernier point est le plus utile et le moins fait. Il transforme une inquiétude vague en une donnée exploitable dans une négociation, et il révèle souvent que la dépendance est plus faible — ou plus forte — qu'on ne le pensait.
À retenir
- La bonne question n'est pas « sommes-nous enfermés » mais « que coûterait un changement, composant par composant ».
- La gravité des données est la dépendance la plus coûteuse et la plus sous-estimée.
- Les services managés sont un bon choix ; refuser la portabilité totale est souvent rationnel.
- Le format des modèles est la dépendance la moins grave, sauf pour l'AutoML propriétaire dont il faut vérifier l'export.
- Les compétences et processus empêchent la plupart des migrations réelles ; cela se reconnaît, cela ne se supprime pas.
- Les API de modèles créent une dépendance sur un objet que vous ne contrôlez pas : épinglez, abstrayez, gardez un repli testé.
- Cinq décisions suffisent, dont la plus utile est un document d'une page décrivant le chemin de sortie.
Leçon suivante — Récapitulatif, glossaire et FAQ →