Changer de modèle sans tout refaire

En bref. Pour rester libre de changer de fournisseur d’IA, il faut isoler dès le départ les éléments qui créent une dépendance technique ou contractuelle : les appels API, le format des données échangées et les règles métier qui entourent le modèle. En encapsulant ces trois couches derrière une interface propre, on peut substituer un modèle GPT‑4o par un Mistral ou un service interne sans réécrire les processus. Cette approche évite que le coût ou les conditions d’un seul fournisseur deviennent un verrouillage difficile à défaire.

1. Cartographier les points de contact avec le fournisseur

Lors d’une revue de projet d’automatisation du suivi des leads, l’équipe remarque que chaque nouveau lead déclenche un appel à l’API de GPT‑4o pour générer un premier message personnalisé. Le volume mensuel est d’environ 12 000 appels, soit un coût de l’ordre de 240 € à 0,02 € l’appel. Ce chiffre apparaît sur le tableau de bord financier comme une ligne de dépense récurrente, mais aucune documentation ne précise où sont stockés les prompts ni comment ils sont versionnés.

Le premier acte consiste à lister tous les endroits où le code ou la configuration fait référence à un endpoint extérieur : fonctions dans n8n, scénarios Make, formules Excel qui appellent un webhook, ou champs d’un CRM qui envoient une requête. On obtient ainsi une liste de points de contact, généralement entre cinq et quinze selon la complexité du processus.

• Endpoints API (URL, clé d’authentification)
• Modèle de prompt (texte envoyé)
• Format de la réponse attendue (JSON, texte brut)
• Gestion des erreurs et des retries

2. Isoler la couche d’accès aux données

Dans le même projet, les données clients proviennent d’un CRM (HubSpot) et sont extraites toutes les nuits via un scénario Make qui les dépose dans un fichier CSV sur un serveur SFTP. Le modèle IA ne reçoit que ce CSV, il n’a jamais besoin de lire directement la base du CRM.

En séparant l’extraction (Make → CSV) de l’inference (appel au modèle), on crée une frontière nette : si le fournisseur change, seul le scénario qui appelle l’API doit être modifié, pas l’étape d’extraction. Cette séparation réduit le travail de migration de plusieurs jours à quelques heures.

Un contre‑exemple fréquent consiste à appeler directement l’API depuis une formule Excel qui tire les données du CRM via un add‑on propriétaire. Dans ce cas, chaque changement de fournisseur oblige à revoir chaque feuille, ce qui devient rapidement ingérable lorsqu’on dépasse vingt feuilles de suivi.

3. Définir une interface d’abstraction pour les modèles

Pour éviter d’écrire du code spécifique à GPT‑4o dans chaque automatisation, on introduit une petite couche d’abstraction : un point d’entrée HTTP interne qui reçoit un payload standardisé (par exemple, { « prompt »: "...", « max_tokens »: 512 }) et retourne une réponse normalisée.

Cette couche peut être implémentée avec un service léger en n8n ou un webhook Make qui, selon une variable d’environnement, redirige vers l’API de GPT‑4o, de Mistral ou vers un modèle hébergé en interne sur un serveur GPU. Ainsi, le reste du workflow n’est jamais touché lorsqu’on change de fournisseur.

Un exemple concret : un scénario n8n nommé « IA‑Réponse‑Lead » possède deux nœuds : un nœud « Set » qui prépare le prompt, puis un nœud « HTTP Request » dont l’URL est chargée depuis une variable d’environnement appelée IA_ENDPOINT. En modifiant simplement cette variable, on passe de https://api.openai.com/v1/chat/completions à https://api.mistral.ai/v1/chat sans toucher au reste du flux.

4. Prévoir la réversibilité et estimer le coût de sortie

Avant de signer un contrat avec un fournisseur de modèle langage, il faut chiffrer le coût de retour à une solution interne ou à un autre prestataire. Cet exercice inclut :

• Le temps nécessaire pour re‑former ou fine‑tuner un modèle ouvert (Mistral 7B, Llama 3) sur les mêmes données de prompt‑réponse.
• Le stockage des historiques de prompts et de réponses pour garantir la traçabilité.
• Le éventuel besoin de licences supplémentaires si le nouveau fournisseur impose un modèle de facturation différent (par token, par heure de calcul).

Un ordre de grandeur souvent observé : migrer d’un service SaaS facturé à l’appel vers un modèle open‑source hébergé sur une instance cloud de type GPU représente entre 8 et 12 heures de travail d’un data‑engineer, soit un coût interne d’environ 600 € à 900 €, largement inférieur aux frais de sortie ou de pénalité que certains contrats prévoient lorsqu’on veut quitter le service après douze mois.

Pour visualiser les différences, voici une comparaison simplifiée :

Critère	SaaS propriétaire (ex. GPT‑4o)	Open‑source auto‑hébergé (ex. Mistral)
Coût marginal par 1 000 tokens	≈ 0,02 €	≈ 0,005 € (coût d’infrastructure)
Réversibilité	Dépend des clauses de sortie, souvent coûteuses	Totale : les données et les poids restent sous votre contrôle
Maîtrise des données	Données transitent par le fournisseur, risque de rétention	Données restent dans votre environnement
Expertise requise	Faible (API prête à l’emploi)	Modérée (déploiement, monitoring, scaling)
Temps de mise en œuvre	Quelques heures pour créer la clé et appeler l’API	1 à 2 jours pour installer le modèle et configurer le serveur

5. Quand ne pas externaliser : garder le contrôle interne

Dans certains cas, la réponse stratégique est « ne le faites pas ». Par exemple, lorsqu’une décision de crédit doit être justifiable auprès d’un régulateur, il est interdit de s’appuyer sur un modèle dont les poids sont opaques et dont le fournisseur ne peut pas fournir de tracé d’audit.

Dans ce contexte, même si l’appel à GPT‑4o serait moins cher à court terme, le risque de non‑conformité outweigh les économies potentielles. La réponse consiste alors à développer ou à adapter un modèle interne, explicite (arbre de décision, régression logistique) ou à utiliser un service qui propose des modèles open‑source avec accès aux poids.

Un autre cas où la réponse est « n’y allez pas » apparaît quand le volume d’appels est extrêmement faible, inférieur à 200 requêtes par mois. Dans cette situation, le coût fixe d’abonnement à une plateforme low‑code (n8n ou Make) dédié à l’orchestration d’IA dépasse largement le coût marginal des appels API, rendant l’ajout d’une couche d’abstraction inutilement complexe.

En résumé, la décision d’externaliser doit être pesée contre deux critères : la nécessité de réversibilité et d’auditabilité, et l’échelle d’utilisation qui justifie l’infrastructure d’orchestration.

Questions fréquentes

Comment mesurer le volume d’appels nécessaires pour justifier une couche d’abstraction ?

Un ordre de grandeur utile est de considérer que chaque heure d’ingénierie vaut environ 75 €. Si le coût mensuel des appels API dépasse 300 €, soit environ quatre heures de travail, il devient rentable d’investir dans une abstraction qui facilite les changements futurs.

Quel niveau de compétence faut‑il pour maintenir un modèle Mistral auto‑hébergé ?

Il faut généralement une connaissance de base de Linux, de Docker ou de Kubernetes, ainsi que la capacité à surveiller l’utilisation de la GPU. Un data‑engineer junior peut prendre en charge le déploiement après une formation d’une journée, tandis que les mises à jour de modèle restent simples grâce aux dépôts Hugging Face.

Est‑il possible de garder le même format de prompt lorsqu’on passe de GPT‑4o à un modèle open‑source ?

Oui, tant que le modèle accepte la même structure de texte d’entrée. La plupart des modèles de langage récents comprennent des prompts en langage naturel identique ; il suffit de vérifier la longueur maximale de tokens et d’ajuster le paramètre max_tokens en conséquence.

Dans quels scénarios réglementaires l’usage d’un modèle propriétaire est‑il interdit ?

Lorsque la décision doit être explicable et traçable selon des normes telles que le RGPD pour le profilage ou les directives de l’ACPR pour le scoring de crédit, les modèles dont les poids ne sont pas accessibles ou dont le fournisseur ne fournit pas de journal d’inférence sont généralement prohibés.