Changer l’API d’un assistant IA : quels tests avant la migration ?

Qu’est-ce qui doit fonctionner au-delà du premier appel API ?

Scénario fictif : l’équipe change l’URL de base, le modèle répond et le ticket technique est presque terminé. Le service réel, lui, recherche des procédures, poursuit un échange et appelle un outil pour retrouver un dossier. Le test réussi ne couvre encore aucune de ces fonctions.

Pour le responsable produit, la question n’est pas seulement « l’API répond-elle ? ». C’est « le conseiller peut-il résoudre la même demande, avec les mêmes règles et les mêmes éléments vérifiables ? ». Cette formulation oblige à tester le parcours, pas uniquement le transport du message.

Le développeur a besoin d’un contrat métier testable

Une consigne comme « garder la même qualité » ne dit pas quel comportement préserver. Faites choisir au responsable produit des cas représentatifs et une issue acceptable pour chacun, y compris en échec. Le développeur peut alors montrer ce qui fonctionne et ce qui manque, au lieu de porter seul un engagement impossible à vérifier.

Compatibilité DeepSeek Responses : vérifier les fonctions documentées

La documentation Responses de DeepSeek, consultée le 24 octobre 2026, annonce une compatibilité partielle. Elle indique notamment que previous_response_id et conversation ne sont pas pris en charge, que file_search est ignoré, et que les paramètres non pris en charge peuvent être ignorés silencieusement. La prise en charge de web_search dépend aussi du modèle.

Ces différences n’empêchent pas de construire une application avec ce fournisseur. Elles signifient que certaines responsabilités doivent être prises en charge autrement. Si votre assistant dépend d’une recherche de fichiers gérée par l’API actuelle, modifier seulement le nom du modèle ne reconstitue pas cette recherche.

La compatibilité d’API ne garantit pas le même comportement

Les tests de Liu et ses collègues montrent que l’exploitation du contexte dépend du modèle et de la position des informations. AgentDojo évalue de son côté des tâches agentiques avec et sans attaques. Aucun de ces travaux ne certifie un fournisseur particulier ; ils illustrent pourquoi un échange de requêtes techniquement compatible ne suffit pas à valider une migration. (Nelson F. Liu et al., 2024)(Edoardo Debenedetti et al., 2024)

Rejouez des conversations avec documents longs, appels d’outils, refus attendus et erreurs réseau. Comparez les actions finales, pas seulement le texte. Vérifiez aussi les cas où un outil propose un résultat inattendu ou un document contient une instruction hostile. Gardez un retour arrière opérationnel tant que les comportements nécessaires au service n’ont pas été contrôlés dans le nouvel environnement.

Rejouer un parcours métier plutôt qu’un seul appel API

Prenez une demande réelle désensibilisée qui déclenche recherche documentaire, réponse sourcée puis appel d’un outil. Le développeur consigne le résultat attendu à chaque étape et l’architecte distingue ce qui dépend du fournisseur de ce qui appartient à votre application. Testez aussi une interruption, une réponse vide et un outil qui renvoie une erreur.

Si l’adaptateur est maintenu dans GitLab, utilisez un modèle de merge request pour demander les parcours rejoués, les capacités non couvertes et le retour arrière. Le modèle structure la déclaration ; les résultats de test restent à joindre. Cette petite évolution est possible avant de construire une plateforme d’évaluation dédiée. Documentation de l’outil ↗

Le responsable produit définit le comportement acceptable pour l’utilisateur : reprise possible, message compréhensible et aucune action rejouée par accident. La DSI vérifie les accès et l’exploitation ; l’équipe métier examine la réponse finale. La bascule se fait sur un périmètre où le retour à l’ancien chemin est préparé. Une compatibilité de format ne garantit ni les mêmes fonctions ni le même résultat ; les fonctions disponibles sont à vérifier dans les documentations datées liées au dossier.

Une compatibilité d’API documente un comportement technique ; l’étude des citations examine la relation entre texte et preuve. Pour migrer l’assistant, il faut vérifier les deux. Un appel qui réussit peut produire une réponse dont le document n’est plus accessible ou dont la citation ne soutient pas la consigne. Le test de bascule doit donc aller jusqu’au dossier que consulte réellement l’utilisateur.

Après migration, vérifier que les citations soutiennent encore les réponses

L’audit de moteurs génératifs réalisé par Liu et ses collègues en 2023 distingue les citations présentes des citations qui soutiennent réellement la phrase. Cette distinction est utile ici : un service migré peut encore afficher un lien tout en perdant la qualité du passage qui justifie sa réponse. L’étude ne compare pas les fournisseurs actuels ; elle fournit une dimension d’évaluation. Dans cet audit historique, 51,5 % des phrases sont entièrement soutenues par les citations et 74,5 % des citations soutiennent leur phrase : les dénominateurs diffèrent. Ces valeurs décrivent les systèmes de 2023, pas les API actuelles. (Liu et al., 2023)

Bloquer les parcours dont une capacité requise reste non vérifiée

L’exemple ci-dessous refuse un parcours tant que ses capacités nécessaires ne sont pas marquées comme vérifiées. Il ne remplace pas les tests et ne découvre rien automatiquement. Son intérêt est d’éviter qu’une capacité absente soit traitée comme disponible par défaut.

Dans votre implémentation, reliez ce contrat à des tests exécutés sur les versions réellement prévues. Conservez un jeu de cas indépendant de ceux utilisés pour ajuster les consignes. La documentation OpenAI sur l’évaluation recommande aussi de définir l’objectif, de choisir des cas propres à la tâche et d’associer métriques et jugement humain.

Si seule la génération de texte est utilisée, le périmètre peut rester réduit. Si l’assistant recherche, conserve un état et agit dans le SI, la migration doit couvrir ces comportements. Décidez alors usage par usage : conserver certaines fonctions côté application peut rendre le changement de fournisseur plus maîtrisable, mais cela ajoute du code et de la maintenance. Ce coût doit apparaître dans la décision, au même titre que le tarif des appels.

Après migration, vérifiez notamment si les procédures citées justifient réellement la réponse, au lieu de compter seulement les liens affichés.

Revue de bascule du service

Le développeur maintient les tests de capacités ; le métier valide les parcours ; l’exploitation prépare retour arrière et surveillance des premiers usages.

Un support pour le pilote

Contrat local illustratif. Le code lève volontairement une erreur pour les deux capacités non validées. Testé sans appel externe.

// Exemple local de contrat de capacités, à maintenir avec vos tests.
// Il ne détecte pas les capacités du fournisseur en appelant son API.
function requireCapabilities(required, verified) {
  const missing = required.filter(name => verified[name] !== true);
  if (missing.length) {
    throw new Error(`Capacités non validées : ${missing.join(", ")}`);
  }
}

const workflowNeeds = ["function_calls", "document_search", "conversation_state"];
const adapterVerified = {
  function_calls: true,
  document_search: false,
  conversation_state: false
};

// Refuse ce workflow tant que recherche et état ne sont pas validés.
requireCapabilities(workflowNeeds, adapterVerified);

Documentation & terrain

Les limites de cette analyse

• Deux dénominateurs distincts : phrases et citations.
• Ne mesure pas les produits actuels ni la vérité de chaque affirmation.

Sources et résultats utilisés dans cet article

Les passages et le périmètre de lecture sont consultables ci-dessous. L’accès à un texte intégral ne signifie pas que chaque résultat a été audité.