API IA « compatible OpenAI » ou Anthropic : le test de portabilité avant de changer

Compatible ne veut pas dire interchangeable

De nombreux services annoncent une API « compatible OpenAI ». Cette formule décrit souvent la possibilité d’utiliser une structure de requête connue, une clé de type Bearer et un point d’accès personnalisé. Elle peut suffire pour une conversation texte simple. Dès qu’une application utilise des outils, des images, du streaming, un schéma JSON strict ou la reprise d’état, les écarts apparaissent.

La compatibilité doit donc être traitée comme une hypothèse à tester, pas comme un contrat universel. Même les interfaces d’un fournisseur évoluent : OpenAI distingue notamment Chat Completions et Responses, tandis qu’Anthropic documente son propre protocole Messages et une couche de compatibilité SDK. Une migration fiable commence par l’inventaire exact des fonctions utilisées aujourd’hui.

La question utile n’est pas « l’API répond-elle ? », mais « la tâche complète reste-t-elle correcte, sûre, observable et réversible ? ».

Dessiner la frontière de portabilité

Placez derrière un petit adaptateur tout ce qui dépend du fournisseur : adresse, authentification, nom du modèle, format des messages, déclaration des outils, extraction de la réponse et gestion des erreurs. Le reste de l’application doit manipuler vos propres objets : consigne, pièces jointes, résultat attendu, usage mesuré et trace de validation.

Cette frontière ne demande pas nécessairement une grande architecture. Pour une micro-entreprise, un module de quelques fonctions et un fichier de configuration séparé peuvent suffire. L’objectif est d’éviter que le nom d’un modèle, une clé ou une structure de réponse soit recopié dans dix écrans et cinq scripts.

Écrire un contrat minimal avant le code

Décrivez les entrées, les sorties et les invariants. Les entrées précisent les types de texte, fichiers et paramètres acceptés. Les sorties définissent les champs obligatoires, erreurs récupérables et délais. Les invariants fixent les règles qui ne changent pas : aucune clé dans les journaux, aucune réponse utilisée sans validation, aucune commande exécutée hors bac à sable.

Un contrat explicite empêche de valider une migration parce qu’une démonstration a produit une jolie réponse. Il permet aussi de savoir qu’une fonction est volontairement hors périmètre. Si votre application n’utilise jamais la vision, son absence n’est pas un échec ; si elle dépend d’un appel d’outil structuré, une approximation textuelle l’est.

1. Lister les cinq appels fréquents et les deux plus critiques
2. Définir les champs obligatoires
3. Écrire les erreurs et délais acceptables
4. Identifier les fonctions propriétaires
5. Fixer une validation humaine par niveau de risque

Tester la syntaxe, les erreurs et le streaming

Commencez avec un message court, puis ajoutez le streaming, une limite de sortie, un arrêt volontaire et un format structuré. Simulez une clé invalide, un modèle inconnu, une limite de débit et une réponse trop longue. Votre adaptateur doit produire des erreurs compréhensibles sans révéler la clé ni enregistrer le contenu sensible.

Vérifiez les codes HTTP sans leur faire une confiance aveugle : deux fournisseurs peuvent employer des statuts proches avec des corps différents. Normalisez les erreurs utiles — authentification, quota, saturation, requête invalide, indisponibilité — et conservez le détail brut seulement dans un journal protégé et limité.

Les appels d’outils sont le vrai test

Pour un agent, le modèle ne livre pas seulement du texte : il choisit parfois une fonction et construit ses arguments. Testez une fonction simple, une fonction avec choix contraint et un cas où aucun outil ne doit être appelé. Vérifiez le nom, le JSON, les champs obligatoires, les doublons et le comportement après une erreur de l’outil.

Ajoutez un outil factice qui refuse toute action dangereuse. Un modèle peut proposer un argument inattendu, répéter un appel ou poursuivre après un échec. La couche d’exécution doit valider chaque argument et appliquer les autorisations ; elle ne doit jamais considérer la sortie du modèle comme une permission.

Mesurer la qualité et le coût sur vos tâches

Préparez vingt exemples anonymisés couvrant le travail réel : cas facile, ambigu, long, multilingue et impossible à conclure. Écrivez les critères avant de lancer les modèles. Mélangez l’ordre des résultats lors de la revue, puis notez exactitude, format, qualité du français, incertitude signalée et temps de correction. Aucun benchmark général ne remplace ce test.

Le tarif d’entrée et de sortie ne suffit pas. Ajoutez les relances, la longueur des réponses, le cache, les outils facturés, le stockage et le temps humain. Divisez le total par le nombre de tâches acceptées après contrôle. Cette unité — coût par tâche validée — reflète mieux la valeur et rend visibles les échecs coûteux.

Données, région et conservation changent aussi

Un changement de base URL change potentiellement le destinataire, le pays de traitement, les sous-traitants et les règles de conservation. Relisez la documentation de l’offre exacte : interface grand public, abonnement développeur, API et offre entreprise peuvent avoir des politiques différentes. Une compatibilité technique n’emporte aucune garantie juridique.

La CNIL recommande aux TPE-PME de cadrer les usages et de protéger les données confidentielles ou personnelles. Pour le test, utilisez des contenus fictifs. Avant la production, documentez la finalité, les catégories de données, les accès, la durée de conservation, la suppression et la procédure d’incident. Demandez un avis adapté si les données sont sensibles.

Protéger les clés et limiter les abus

Créez une clé par environnement et, si possible, par application. Stockez-la dans un gestionnaire de secrets, jamais dans le code. Restreignez les droits, modèles, budget et adresses réseau lorsque le fournisseur le permet. Faites tourner la clé après le test si elle a été manipulée sur un poste temporaire.

OWASP place notamment l’autorisation et la consommation non limitée de ressources parmi les risques des API. Appliquez des limites côté application : taille d’entrée, fréquence, nombre d’appels d’outils, temps total et budget. Le fournisseur protège son service ; vous devez protéger votre usage.

Construire le retour arrière avant la bascule

Conservez la configuration précédente, les tests et une procédure de repli. La bascule doit se faire par un réglage central, pas par une série de modifications manuelles. Commencez avec une faible part du trafic ou un groupe interne, puis comparez les résultats. N’envoyez pas la même donnée sensible à deux fournisseurs uniquement pour faciliter une comparaison.

Définissez les déclencheurs du retour : taux d’erreur, coût, latence, échec de sécurité ou dégradation de qualité. Testez réellement le retour avant la production. Une sauvegarde non restaurée et un fournisseur secondaire jamais appelé ne sont pas des plans de continuité.

1. Conserver deux configurations validées sans clé dans le dépôt
2. Basculer par paramètre central
3. Commencer par des tâches non sensibles
4. Surveiller coût, erreurs et qualité
5. Déclencher le retour selon des seuils écrits

Attribuer un propriétaire et une date de révision

Une couche de portabilité abandonnée vieillit vite. Nommez une personne responsable du jeu de tests, de la liste des modèles et des règles de sécurité. Elle ne choisit pas seule le fournisseur, mais elle s’assure que la décision repose sur des preuves datées et que les alertes de dépréciation sont suivies.

Conservez une fiche courte par fournisseur : protocole utilisé, fonctions validées, région, contrat, limites, clé responsable et dernière vérification. Programmez une révision trimestrielle ou après toute annonce de retrait. Si personne ne peut expliquer comment revenir en arrière, la portabilité annoncée n’est plus une capacité opérationnelle.

La décision honnête en une journée

Le matin, réalisez l’inventaire et l’adaptateur minimal. À midi, lancez les tests de contrat et les erreurs. L’après-midi, comparez les vingt exemples, les coûts et la sécurité. En fin de journée, choisissez entre trois conclusions : portable maintenant, portable avec travaux identifiés, ou non portable pour cette fonction.

Cette conclusion vaut mieux qu’un oui ou non générique. Elle relie la compatibilité à votre système, vos données et votre seuil de qualité. Rejouez le jeu de tests après une version importante ou chaque trimestre. Le but n’est pas de changer souvent de fournisseur ; c’est de pouvoir choisir sans subir une dépendance que personne n’a mesurée.

Terminez par un compte rendu compréhensible par une personne non technique : fonctions conservées, écarts, risques, coût observé, décision et prochaine date de contrôle. Joignez la version du modèle et la date des conditions consultées. Ainsi, un changement de fournisseur reste une décision de gestion documentée, pas une configuration connue d’un seul développeur.