Brancher OpenAI ou Anthropic dans votre produit : le choix, le prompt, et le contexte que personne ne budgète

« Quel fournisseur - OpenAI ou Anthropic » est posé dans presque chaque appel de kickoff comme si c’était la plus grosse décision du projet. Ce ne l’est presque jamais. Les deux API font des sorties structurées, les deux font de l’appel d’outils/fonctions, les deux diffusent en streaming, et les différences qui comptent vraiment - taille de la fenêtre de contexte, prix par token, à quel point un modèle suit strictement un schéma, comment il se comporte face à des instructions ambiguës - se tranchent en testant vos vrais prompts sur vos vraies données, pas avec un classement de benchmark.

Les décisions qui façonnent vraiment le build viennent après : comment le prompt est écrit et versionné comme du code au lieu d’être ajusté dans un playground puis oublié, comment une réponse est validée avant que votre appli lui fasse confiance, et comment vous gérez le contexte une fois qu’une conversation, un document ou un job batch dépasse ce qui tient dans un appel.

1. OpenAI contre Anthropic est rarement la décision qui compte

Je choisis selon le job, pas par loyauté de marque : lequel a le support de sorties structurées le plus strict pour un pipeline chargé en schémas, lequel a une fenêtre de contexte qui contient vraiment le document en question, quel palier de prix survit au volume d’appels attendu, et - sous-estimé - lequel a un comportement de refus adapté à un cas d’usage proche d’un sujet sensible. Deux fournisseurs différents peuvent tous deux « marcher » en démo et diverger fortement dès que de vrais utilisateurs envoient de vrais cas limites.

Je garde le fournisseur derrière un seul adaptateur fin dans le code, précisément pour que cette décision reste réversible. Un client qui demande à changer de fournisseur six mois plus tard à cause d’un changement de prix, d’une limite de débit ou d’une dépréciation de modèle devrait obtenir un changement de config et une série de tests de régression de prompts, pas une réécriture.

2. L’ingénierie de prompt est une spec, testée comme telle

Un prompt qui vit dans la tête d’un seul développeur, qu’on ajuste dans un playground de chat, et qui part en prod dès qu’il « a l’air bon » sur trois exemples, est un passif dès que le trafic dépasse ces trois exemples. J’écris les prompts comme des fichiers versionnés, avec un petit jeu de test d’entrées réelles et de formes de sortie attendues, et je les teste en régression comme je le ferais pour une fonction - surtout avant de changer de modèle ou de fournisseur.

Les sorties structurées et l’appel d’outils/fonctions sont ce qui rend un prompt testable du tout : au lieu de noter du texte libre à l’œil, je vérifie qu’un payload JSON correspond à un schéma et que les valeurs qu’il contient respectent les règles métier. C’est le vrai livrable de « l’ingénierie de prompt » sur un projet réel, pas un paragraphe malin.

3. Gestion du contexte : la partie que personne ne budgète

Toute intégration LLM finit par rencontrer une conversation, un document ou un job batch plus grand que la fenêtre de contexte, et ce qui se passe ensuite décide si la fonctionnalité reste bon marché et précise ou devient lente et se met à halluciner. Ajouter naïvement chaque message à l’historique marche en démo puis casse en silence : les coûts grimpent à chaque tour, la latence suit, et passé un certain point le modèle commence à perdre de vue la vraie question enterrée sous les vieux tours.

La solution est un mélange de coupe des vieux tours, de résumé de ce qui précède au lieu de le rejouer, et de récupération de seulement la tranche pertinente via des embeddings et une base vectorielle quand la source est un document plutôt qu’une conversation. L’entrée multimodale - une image ou une page de PDF - est juste un autre type de contexte à gérer de la même façon : elle compte dans la même fenêtre et demande la même discipline sur ce qui doit vraiment y être.

Conclusion : l’appel API est la plus petite partie de l’intégration

Câbler une LLM dans un produit, ce n’est surtout pas l’appel au modèle - c’est l’adaptateur qui rend le fournisseur interchangeable, le prompt traité comme une spec testée, le schéma qui attrape une réponse malformée avant qu’elle n’atteigne un utilisateur, et la stratégie de contexte qui continue de marcher après la première conversation de démo facile. Je construis tout ça autour de celui d’OpenAI ou Anthropic qui convient vraiment au job. Écrivez via le formulaire ce que vous voulez que la LLM fasse dans votre produit, et je vous dirai ce dont l’intégration a vraiment besoin.