Outils
API
Interface par laquelle un logiciel expose des fonctions à un autre logiciel, qui les appelle selon un format convenu, sans intervention humaine et sans passer par un écran.
Le guichet, pas l'écran
Une interface graphique s'adresse à une personne : elle affiche, attend un clic, demande une confirmation. Une API s'adresse à un programme : elle reçoit une requête structurée, renvoie une réponse structurée. La même action — créer une facture, envoyer un message, récupérer un prix — peut exister des deux manières. L'API est celle qui permet l'enchaînement automatique, y compris la nuit, sans présence humaine et sans qu'une fenêtre reste ouverte sur un poste de travail.
Cette structure impose un contrat. Des noms de champs, des types de valeurs, des codes d'erreur, des limites de débit. Un intégrateur qui respecte ce contrat obtient des réponses prévisibles ; celui qui l'ignore reçoit des erreurs peu parlantes et perd du temps en essais successifs. La documentation d'une API n'est donc pas un accessoire commercial, c'est la partie réellement utilisable du produit, et elle se juge à la qualité de ses exemples.
Ce que cela change pour une PME
Une API permet de relier des outils qui ne se connaissaient pas : le logiciel de devis, l'outil de facturation, le suivi de chantier, un service d'IA. Sans elle, la même information se saisit plusieurs fois, et chaque ressaisie introduit une erreur. Le gain se mesure en heures récupérées et en cohérence des dossiers, rarement en innovation spectaculaire. C'est un travail d'infrastructure, peu visible, qui se remarque surtout le jour où il manque et où tout se fait à la main.
Elle crée aussi une dépendance. Un fournisseur peut modifier son API, en limiter l'accès, changer ses tarifs ou fermer le service. La question à poser avant de s'engager n'est pas seulement ce que l'API permet aujourd'hui, mais ce qui se passe si elle disparaît : les données sont-elles exportables, le format est-il documenté, existe-t-il une autre voie d'accès, et à quel coût de bascule ? Une sortie de service annoncée sans préavis reste la situation la plus coûteuse pour une entreprise qui a bâti son organisation dessus.
API et modèles de langage
L'accès aux modèles d'IA se fait presque toujours par API. On envoie un texte et des paramètres, on reçoit une réponse et un décompte de jetons. Ce mode d'accès explique une partie des coûts variables : chaque appel est facturé, y compris les répétitions inutiles et les essais de mise au point. Il explique aussi la latence, qui dépend de la longueur de l'entrée, de celle de la sortie demandée et de la charge du service à cet instant.
La clé d'API, elle, est un secret d'entreprise. La placer dans un site public revient à publier son moyen de paiement. Les incidents les plus fréquents ne viennent pas d'une attaque sophistiquée, mais d'une clé laissée dans un fichier partagé ou dans le code d'une application distribuée. Sa rotation régulière, sa restriction par usage et sa surveillance dans les journaux relèvent de l'hygiène de base, pas de la paranoïa. Un inventaire des clés en circulation, deux fois par an, évite la plupart des surprises.
En pratique
- Demander la documentation, un exemple d'appel et la procédure d'export avant de signer un abonnement.
- Placer les clés côté serveur, jamais dans une page web ni dans une application mobile distribuée.
- Surveiller la consommation par usage : un appel en boucle se voit dans les jetons, pas dans l'interface.
- Tester le comportement en cas d'erreur et de limite de débit avant la mise en production.
Voir aussi
- Clé APILe jeton qui identifie une application et autorise ses appels — donc la première chose à protéger.
- TokenLe morceau de mot que le modèle manipule et que le fournisseur facture.
- MCPUn protocole ouvert qui décrit à un agent les outils auxquels il a droit, et comment les appeler.
- Coût par usageLe prix réel d'une réponse, d'un document ou d'un dossier traité, modèles et hébergement compris.