GPT

Un nom devenu courant

GPT est l'abréviation de Generative Pre-trained Transformer : un modèle génératif, préentraîné sur de grands corpus, fondé sur l'architecture Transformer. Le sigle désigne une famille de modèles, pas un produit unique. Dans le langage courant, il est souvent confondu avec l'interface de dialogue qui les utilise, au point de servir de nom générique pour tout assistant conversationnel. Cette simplification de vocabulaire complique ensuite les discussions techniques entre une direction et une équipe projet. Le sigle circule désormais comme un nom commun, y compris dans les offres d'emploi.

Cette confusion a une conséquence pratique. Dire que l'on utilise GPT ne dit rien de la version, du mode d'accès, du tarif ni des conditions de traitement des données. Pour un projet sérieux, il faut préciser le modèle exact, la date de la version, le canal d'appel et le contrat qui l'encadre. Sans ces éléments, aucune comparaison ni aucune évaluation ne peut être reproduite, et les incidents deviennent impossibles à analyser sérieusement.

Ce qui distingue les générations

Les versions successives ne diffèrent pas seulement par la taille. Elles changent de comportement : certaines sont optimisées pour la vitesse et le coût, d'autres pour le raisonnement sur des problèmes en plusieurs étapes, d'autres pour le traitement d'images ou l'appel d'outils. Une version peut être meilleure en rédaction et moins bonne en extraction structurée, ce qui interdit de conclure d'un usage à l'autre sans test préalable sur vos propres cas.

Les modèles dits de raisonnement prennent davantage de temps avant de répondre, en exposant parfois leurs étapes intermédiaires. Ce délai se paie en latence et en jetons. Pour une tâche simple, il est inutile ; pour un calcul ou une analyse de dossier, il peut changer le résultat. Le choix doit donc se faire par tâche, avec un test comparatif, et non par préférence générale pour la version la plus récente ou la plus commentée.

Interface et API

Deux voies d'accès coexistent. L'interface grand public convient à l'expérimentation, à la rédaction et aux échanges ponctuels ; elle est soumise aux conditions du service et à ses limites d'usage. L'API s'adresse aux applications : elle permet de fixer le modèle, de journaliser les appels, de gérer les clés et d'intégrer la réponse dans un logiciel métier. C'est elle qui rend un usage industrialisable, mesurable et reproductible dans la durée.

L'API introduit ses propres sujets : coût variable selon le volume, gestion des clés, quotas, files d'attente, reprise en cas d'erreur. Un service qui dépend d'un fournisseur externe doit prévoir une solution de repli, au moins pour les usages critiques. Cette dépendance n'est pas rédhibitoire, mais elle doit être connue, chiffrée et acceptée par la direction, pas subie par l'équipe technique au moment où le service tombe. Un quota mal dimensionné produit des échecs en série, au moment où le service est le plus sollicité.

Choisir sans s'enfermer

Un modèle de cette famille constitue souvent un point de départ raisonnable : documentation abondante, outils disponibles, compétences faciles à recruter. Ce n'est pas une raison pour y enfermer toute l'architecture. Isoler l'appel au modèle derrière une interface interne permet de changer de fournisseur sans réécrire l'application, et de comparer les offres à mesure que les prix et les capacités évoluent. C'est une précaution de conception, pas une défiance envers l'éditeur.

La question des données reste prioritaire. Un dossier client, un contrat ou un fichier de paie ne se déposent pas dans n'importe quelle interface. Les conditions du service, la localisation des serveurs et la durée de conservation des journaux doivent être vérifiées avant le premier essai, et pas après. C'est un travail de quelques heures qui évite des situations difficiles à rattraper une fois qu'un document confidentiel a été transmis à un service tiers.