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

Version HTML de référence : https://talkweb.fr/analyses/api-compatible-openai-migration/

Publication : 2026-11-03T08:42:50+01:00. Révision : 2026-11-03T08:42:50+01:00.

Mémoire, recherche, outils, citations : testez les fonctions utilisées par votre service. Un appel réussi ne suffit pas à valider la migration.

## La réponse

Traitez la compatibilité de format comme un point de départ. Vérifiez les capacités effectivement utilisées par votre application, puis rejouez les parcours métier. Une requête qui retourne un texte sans erreur peut avoir ignoré une option nécessaire au service.

## 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.

Sources : [Lost in the Middle: How Language Models Use Long Contexts](https://doi.org/10.1162/tacl_a_00638); [AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents](https://proceedings.neurips.cc/paper_files/paper/2024/hash/97091a5177d8dc64b1da8bf3e1f6fb54-Abstract-Datasets_and_Benchmarks_Track.html)

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.

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.

## 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.

Sources : [Evaluating Verifiability in Generative Search Engines](https://doi.org/10.18653/v1/2023.findings-emnlp.467)

## 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.

Revue de bascule du service — proposition de suivi TalkWeb

| Ce que vous examinez | Comment le vérifier |

| --- | --- |

| Capacité requise vérifiée | Relier chaque fonction nécessaire à un test exécuté sur la version cible ; un paramètre accepté n’est pas une fonction démontrée. |

| Parcours métier abouti | Vérifier réponse, preuve et action attendue de bout en bout, avec les droits du véritable utilisateur. |

| Échec maîtrisé | Tester outil indisponible, résultat vide et réponse interrompue ; vérifier le message et le relais proposés. |

## Passer à l’action

Traitez la compatibilité de format comme un point de départ. Vérifiez les capacités effectivement utilisées par votre application, puis rejouez les parcours métier. Une requête qui retourne un texte sans erreur peut avoir ignoré une option nécessaire au service.

Rejouer le parcours documentaire complet avec un cas nominal, un échec d’outil et une reprise de session.

Même résultat métier attendu, actions non dupliquées et erreurs correctement signalées ; les capacités non vérifiées restent hors bascule.

## Limites

- Deux dénominateurs distincts : phrases et citations.

- Ne mesure pas les produits actuels ni la vérité de chaque affirmation.

## Sources

- [Liu, N., Zhang, T., & Liang, P. (2023). Evaluating Verifiability in Generative Search Engines. Findings of the Association for Computational Linguistics: EMNLP 2023.](https://doi.org/10.18653/v1/2023.findings-emnlp.467) — Lecture ciblée : résumé, pages 7004–7005 et 7007 ; définitions, évaluation humaine et résultats.

- [Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, & Percy Liang. (2024). Lost in the Middle: How Language Models Use Long Contexts. Transactions of the ACL.](https://doi.org/10.1162/tacl_a_00638) — Résumé primaire consulté ; texte intégral non audité.

- [Edoardo Debenedetti, Jie Zhang, Mislav Balunovic, Luca Beurer-Kellner, Marc Fischer, & Florian Tramèr. (2024). AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents. NeurIPS Datasets and Benchmarks.](https://proceedings.neurips.cc/paper_files/paper/2024/hash/97091a5177d8dc64b1da8bf3e1f6fb54-Abstract-Datasets_and_Benchmarks_Track.html) — Résumé primaire consulté ; texte intégral non audité.

## Documentation

- [DeepSeek — Using the Responses API](https://api-docs.deepseek.com/guides/responses_api/) — Compatibility Details, paramètres et outils ; lecture datée. Aucun appel à un compte fournisseur effectué par TalkWeb pour cet article.

- [OpenAI — Evaluation best practices](https://developers.openai.com/api/docs/guides/evaluation-best-practices) — Principes méthodologiques lus ; l’article ne dépend pas du service hébergé Evals, dont la documentation annonce la fermeture.

- [GitLab — modèles de description](https://docs.gitlab.com/user/project/description_templates/) — Modèles d’issues et de merge requests dans le dépôt. Ne prouve pas que les vérifications déclarées ont été exécutées.