API

En profondeur

Une API est un contrat entre deux logiciels : une liste d’opérations disponibles, ce qu’il faut envoyer pour chacune, ce qui revient en retour. Ce contrat permet à celui qui appelle d’ignorer ce qui se passe derrière, et à celui qui répond de changer sa mise en œuvre sans casser les appels existants. Rien là-dedans n’appartient à l’intelligence artificielle : la notion est aussi ancienne que le logiciel, et vaut pour un service bancaire, une carte routière ou un modèle. Dans ce lexique, elle apparaît à deux endroits : c’est par une API qu’un harnais atteint un modèle, et c’est souvent une API qu’un outil interroge quand le harnais l’exécute.

Ce que fournit une API de modèle est plus étroit qu’on ne l’imagine. On envoie du texte, on reçoit du texte, et le service ne garde rien entre deux appels : la continuité de l’échange, la recherche documentaire, le format des réponses et les limites de comportement sont à la charge de celui qui appelle. La facturation suit la même logique, au volume de texte échangé, entrée comprise, ce qui rend chaque élément ajouté au contexte immédiatement comptable. C’est pourquoi deux produits bâtis sur la même API peuvent différer du tout au tout : la valeur se construit dans le harnais, pas dans l’accès.

Le premier piège est de confondre l’accès et la maîtrise. Appeler un modèle par une API signifie que vos données sortent de chez vous, ce qui déplace la question vers le contrat : lieu du traitement, durée de conservation, réutilisation éventuelle pour l’entraînement, sous-traitants. Le deuxième est la dépendance, car un accès n’est pas un acquis : les tarifs, les conditions d’usage et la disponibilité des versions relèvent du fournisseur, et une version retirée oblige à revalider tout ce qui reposait sur elle. Le troisième est plus discret : une clé d’accès qui circule dans une équipe est une porte que personne ne surveille, et c’est l’une des voies les plus courantes de l’IA clandestine en entreprise.