Quand l'API vaut le coup, et quand elle ne le vaut pas

Pensez à une tâche que vous confiez à l’assistant plusieurs fois par semaine. Avant d’écrire la moindre ligne de code, vous allez la noter sur quatre critères et voir si elle mérite une API, ou si une conversation suffit. Aucune clé, aucun code.

Avant de commencer (30 secondes). Cette tâche mérite-t-elle une API à votre avis ? Notez oui, non ou « peut-être », avec le nombre de fois par mois où vous la faites.

Votre premier essai, tout de suite

Notez la tâche sur ces quatre critères, oui ou non : revient-elle au moins plusieurs dizaines de fois par mois ? Les entrées se ressemblent-elles et la sortie se décrit-elle en une phrase ? Pouvez-vous contrôler vite le résultat ? Une erreur occasionnelle se rattrape-t-elle sans dommage ? Puis collez dans un assistant :

Voici une tâche : [description en cinq lignes, sans donnée sensible]. Je l’ai notée oui/non sur quatre critères (volume, forme stable, résultat contrôlable, enjeu supportable) : [vos réponses]. Conteste mes réponses, et dis-moi si une conversation, un outil sans code ou une API conviendrait le mieux, en précisant ce qui te manque pour décider.

Comparez avec votre pari. Au moins trois « oui » sur quatre : la tâche vaut qu’on regarde l’API de près.

Maintenant, questionnez-le. Demandez : « Qu’as-tu supposé sur le volume et sur le coût ? Quelle erreur serait la plus coûteuse ? ».

Ce qu’est une API, et ce qu’elle change

Vous utilisez déjà l’IA dans une fenêtre de conversation. Une API (interface de programmation) fait la même chose sans fenêtre : un programme envoie une demande par internet, reçoit la réponse, et la place où vous voulez : un tableur, votre outil de devis, une base de clients, un message qui part tout seul. C’est ce qui permet de traiter cent dossiers pendant que vous faites autre chose, ou de glisser l’IA au milieu d’un processus qui existe déjà.

Ce chapitre ne vous fait pas écrire de code tout de suite. Il répond à la question qui évite les mois perdus : cette tâche mérite-t-elle une API, ou une conversation, ou un outil sans code suffirait-il ? À la fin, vous aurez noté vos candidates avec une grille de quatre critères, calculé combien de temps il faut pour rentabiliser le montage, et vous saurez ce qui change pour vous sur les données, la facturation et la responsabilité.

Prérequis : avoir déjà lancé un petit script (Python, de préférence) ou être accompagné par quelqu’un qui le fait. Aucune formation de développeur n’est nécessaire : tout le code de cette formation est court, commenté et exécutable tel quel, une fois votre clé installée.

Ce qu’une API change, concrètement

Dans une conversation, vous êtes le programme : vous collez, vous lisez, vous copiez. Avec une API, quatre choses changent.

Vérifié à l’automne 2026 : la documentation d’Anthropic décrit l’API Claude comme une interface REST située à https://api.anthropic.com, dont le point d’entrée principal pour converser est POST /v1/messages. Les prérequis cités sont un compte sur la console du fournisseur et une clé d’API. La documentation d’OpenAI décrit la même logique (une bibliothèque officielle, une clé lue dans une variable d’environnement, un appel qui renvoie du texte). Les noms des méthodes diffèrent d’un fournisseur à l’autre ; les principes de cette formation s’appliquent aux deux.

La conséquence la plus importante est la deuxième ligne du tableau. Un modèle n’a aucune mémoire entre deux appels. Si votre programme traite une série de messages, c’est lui qui décide ce qu’il envoie à chaque fois : les consignes, les exemples, le document, la question. Cela donne un contrôle total (et un coût mesurable) mais cela demande de la méthode, d’où cette formation.

Les tokens : l’unité qui explique la facture

Un modèle ne lit pas des mots mais des tokens, des morceaux de texte plus ou moins courts. Vous payez deux quantités : les tokens que vous envoyez (l’entrée : consignes, document, historique) et ceux que le modèle produit (la sortie). Le prix de chaque catégorie est publié par le fournisseur, par million de tokens, et il dépend du modèle choisi.

Deux règles pratiques suffisent pour raisonner avant de mesurer :

• La sortie coûte en général plus cher que l’entrée, token pour token : c’est le cas dans la grille d’Anthropic à l’automne 2026, à vérifier chez chaque fournisseur sur sa page de tarifs. Demander une réponse courte et structurée réduit la facture.
• Plus l’entrée est longue, plus chaque appel coûte, et vous renvoyez cette entrée à chaque appel. Un long document posé en début de consigne et interrogé cinquante fois est cinquante fois facturé, sauf à utiliser les mécanismes d’économie vus plus loin dans cette formation.

Vérifié à l’automne 2026 : l’API d’Anthropic fournit un point d’accès pour compter les tokens avant d’envoyer une requête (POST /v1/messages/count_tokens), et chaque réponse indique les tokens réellement consommés dans un champ usage. Les deux sont utiles pour chiffrer un projet sans deviner.

Le calcul de base tient en une ligne :

coût d’un appel = (tokens d’entrée × prix d’entrée) + (tokens de sortie × prix de sortie)

Les prix changent ; vous les lirez sur la page de tarifs du fournisseur le jour où vous construisez. Dans les exemples qui suivent, les prix sont fictifs et servent à montrer le raisonnement, jamais à prévoir votre facture.

Les quatre critères d’une bonne tâche

Toutes les tâches ne méritent pas une API. Celles qui la méritent cochent au moins trois de ces quatre cases.

1. Du volume. La tâche revient au moins plusieurs dizaines de fois par mois. En dessous, l’effort de montage dépasse presque toujours le gain.
2. Une forme stable. Les entrées se ressemblent (des e-mails, des factures, des fiches) et vous savez décrire en une phrase ce que vous voulez en sortie (une catégorie, quatre champs, un brouillon de réponse).
3. Un résultat qu’on peut contrôler. Vous pouvez vérifier la sortie vite, ou la comparer à des cas connus. Si personne ne sait dire si la réponse est bonne, il ne faut pas l’automatiser.
4. Un enjeu supportable. Une erreur occasionnelle se rattrape sans dommage grave : un mail mal classé se corrige, une décision de refus de contrat ne s’automatise pas (voir la formation sur les agents pour la règle « l’IA prépare, une personne décide »).

Une tâche qui échoue sur le critère 3 ou 4 n’est pas condamnée : elle devient une tâche où l’IA prépare et où vous validez. Elle passe alors par une file de relecture, et le gain se calcule sur le temps de relecture au lieu du temps de traitement.

Chat, outil sans code, ou API : choisir la voie

La bonne trajectoire est souvent : démarrer dans la conversation pour trouver la bonne consigne, passer à l’outil sans code pour valider le flux, passer à l’API quand le volume, le coût ou la fiabilité l’exigent. Les formations « n8n et Make » et « Agents IA qui agissent » couvrent la deuxième étape ; celle-ci couvre la troisième.

Notez aussi qu’un outil sans code appelle lui-même une API, avec vos clés ou les siennes. Comprendre les appels de cette formation vous aide donc, même si vous ne programmez pas : vous saurez lire ce que l’outil envoie, ce qu’il coûte et pourquoi il échoue.

Un exemple complet, avec des chiffres d’illustration

Clara dirige une petite entreprise de rénovation. Chaque semaine, environ 120 demandes de devis arrivent par e-mail. Pour chacune, elle fait trois choses : classer la demande (salle de bains, cuisine, toiture, autre), relever les informations utiles (ville, surface, délai souhaité, budget s’il est mentionné) et recopier le tout dans son tableur de suivi.

Mesure de départ. Elle chronomètre vingt messages : deux minutes en moyenne. Soit 240 minutes par semaine, quatre heures.

Montage. Un petit programme lit les e-mails d’une boîte dédiée, envoie chacun au modèle avec une consigne stable, reçoit une réponse structurée (voir le chapitre sur les sorties exploitables) et écrit une ligne dans le tableur. Les messages que le programme juge incertains (champ manquant, demande hors catégories) vont dans une file à relire.

Résultat à mesurer, pas à promettre. Supposons que 15 % des messages arrivent en relecture et que chacun prenne trois minutes. Cela donne 18 messages × 3 minutes = 54 minutes, plus un quart d’heure de contrôle par échantillon, soit environ 70 minutes par semaine au lieu de 240 : « de quatre heures à un peu plus d’une heure ». Ce ratio est reproductible sur un cas comme celui-ci : volume, forme stable, résultat contrôlable. Il n’est pas garanti sur le vôtre. Votre première tâche, dans l’exercice, est de le mesurer.

Coût d’usage (valeurs fictives). Supposons 1 000 tokens d’entrée et 200 tokens de sortie par message, un prix fictif de 1 € par million de tokens en entrée et de 5 € par million en sortie.

• Entrée : 120 × 1 000 = 120 000 tokens, soit 0,12 million × 1 € = 0,12 €.
• Sortie : 120 × 200 = 24 000 tokens, soit 0,024 million × 5 € = 0,12 €.
• Total : 0,24 € par semaine avec ces chiffres fictifs.

Avec de vrais tarifs et un vrai modèle, refaites ce calcul. L’ordre de grandeur de ce poste est souvent petit devant le temps humain, mais c’est à vérifier pour chaque projet, surtout si les documents sont longs ou si une boucle d’appels se répète.

Le seuil de rentabilité du montage

Le montage a un coût : du temps pour écrire le programme, tester, brancher la boîte de réception, former la personne qui relit. Ce temps se compare au gain hebdomadaire.

Délai de retour (en semaines) = temps de montage ÷ (gain de temps par semaine − temps d’entretien par semaine)

Pour Clara, supposons 10 heures de montage et d’essais, un gain de 170 minutes (environ 2 h 50) et 20 minutes d’entretien par semaine :

• gain net : 170 − 20 = 150 minutes = 2,5 heures par semaine ;
• délai : 10 ÷ 2,5 = 4 semaines.

Ajoutez à droite le coût de l’API et d’éventuels abonnements. Si le délai dépasse quelques mois, interrogez-vous : la tâche est-elle assez fréquente, ou le montage est-il trop ambitieux pour un premier essai ? Réduisez le périmètre avant de renoncer.

Ce calcul ne tient compte que du temps. La formation sur la mesure du gain ajoute le coût complet et la qualité. Pour un premier tri entre vos candidates, il suffit.

Trois points à connaître avant de commencer

La facturation est séparée de vos usages en conversation. Pour l’API, la documentation d’Anthropic indique qu’on crée un compte sur la console du fournisseur et qu’on y génère une clé ; la consommation y est suivie. Prévoyez dès le départ une limite de dépense (voir le chapitre sur le premier appel) pour qu’un programme en boucle ne vide pas un budget.

Vos données quittent votre ordinateur. Chaque message envoyé à l’API est transmis au fournisseur, qui devient un sous-traitant au sens du règlement sur les données personnelles dès que ces messages contiennent des données de personnes. Cela se règle avec un contrat, des réglages et de la minimisation (n’envoyer que le nécessaire). Le chapitre final de cette formation et la formation sur le déploiement en entreprise y reviennent en détail. En attendant : ne branchez pas de vraies données de clients sans avoir lu les conditions de votre fournisseur.

Ce que fait le programme, c’est vous qui le faites. Un message envoyé par votre programme est votre message. Une erreur de classement qui retarde une demande urgente est votre erreur. Concevez donc une sortie de secours humaine dès le premier jour : la file « à relire » de Clara n’est pas un luxe.

Les erreurs de cadrage les plus fréquentes

• Viser trop large. « Automatiser tout mon service client » échoue ; « classer et résumer les demandes de devis » aboutit.
• Oublier la mesure de départ. Sans chronomètre avant, vous ne saurez jamais ce que vous avez gagné.
• Choisir l’API par réflexe. Si la tâche revient cinq fois par mois, une bonne consigne dans une conversation fait mieux.
• Ignorer la relecture. Un système sans contrôle humain ni contrôle automatique finit par envoyer une erreur à un client.
• Négliger l’entretien. Les modèles et les outils évoluent ; un montage qui marche en octobre peut demander un ajustement trois mois plus tard. Prévoyez du temps pour cela dès le calcul de rentabilité.

Le modèle à copier : la fiche de candidate

Pour chaque tâche envisagée, remplissez cette fiche (dix lignes).

Exercice

Durée : 40 minutes. Résultat : une tâche choisie, un temps de départ chiffré, un délai de retour calculé.

1. Listez cinq tâches de votre activité que vous répétez au moins une fois par semaine.
2. Remplissez la fiche de candidate pour chacune.
3. Chronométrez trois occurrences de la tâche qui a le plus de critères cochés, et notez la moyenne.
4. Estimez le temps de relecture après automatisation en pourcentage de cas à relire et minutes par cas (soyez prudent : prenez le double de votre première idée).
5. Calculez le délai de retour avec la formule du chapitre, en supposant un temps de montage honnête (doublez votre première estimation).

Critère de réussite : vous avez une tâche élue, un chiffre de départ mesuré (pas deviné), un délai de retour inférieur à six mois, et vous savez quelles données personnelles elle contient.

Si cela ne marche pas : si aucune de vos cinq tâches ne coche au moins trois critères, c’est une information utile : gardez la conversation ou un outil sans code. Si le délai de retour dépasse six mois, réduisez le périmètre avant de renoncer. Si vous ne savez pas combien de fois la tâche revient, chronométrez-la pendant une semaine avant de remplir la fiche : un chiffre deviné fausse tout le calcul.

Ce que vous savez maintenant

Répondez de mémoire aux quatre questions, puis vérifiez avec les points qui suivent.

1. À quoi sert une API, et que ne fait-elle pas ?
2. Quels sont les quatre critères d’une bonne tâche ?
3. Comment calcule-t-on le coût d’un appel et le délai de retour du montage ?
4. Que prépare-t-on avant le premier vrai message, et que faut-il prévoir dans un programme ?

Points à retenir :

• Une API sert à traiter du volume et à s’intégrer à un système ; elle n’a pas de mémoire et se facture en tokens.
• Une bonne tâche coche volume, forme stable, résultat contrôlable et enjeu supportable.
• Le coût d’un appel se calcule avec les tokens d’entrée et de sortie, et le délai de retour du montage se calcule avec le temps gagné par semaine.
• Vos données partent chez un fournisseur : minimisation, contrat et réglages se préparent avant le premier vrai message.
• Un programme sans sortie de secours humaine n’est pas prêt.

Quand allez-vous le faire ?

Écrivez une phrase : « Le [jour], avant d’ouvrir un compte chez un fournisseur d’API, je chronomètre trois occurrences de ma tâche candidate. » Le chronométrage avant l’inscription est le déclencheur : il évite de monter un projet pour une tâche dont on ignore le coût réel.

La suite

Le chapitre suivant réalise votre premier appel : clé, requête, réponse, et la manière de garder vos secrets hors du code. Viennent ensuite les paramètres qui comptent vraiment, les sorties exploitables (JSON, schémas, validation), les documents et le contexte long, les outils et les appels de fonctions, la fiabilité en production, puis la sécurité, l’architecture durable et un projet de mise en service.