Rafiq IA Lab

IA-19 — Comprendre les API IA

---

1. Titre du module

IA-19 — Comprendre les API IA

Partie 5 — Créer des outils, agents IA, projets et SaaS (module d'ouverture)

---

2. Objectif pédagogique

À la fin de ce module, l'apprenant doit être capable de :

• définir une API et une API IA ;
• expliquer la différence entre utiliser un assistant dans une interface et utiliser une API ;
• citer des exemples : OpenAI, Anthropic, Google Gemini, Mistral, et modèles locaux via Ollama ;
• comprendre les notions de clé API, requête, réponse, tokens, coût, quota, rate limit ;
• identifier les risques de sécurité (fuite de clé, coût incontrôlé, données sensibles) ;
• décrire des cas d'usage IT (résumé, assistant support, chatbot documentaire, analyse de tickets, rapports) ;
• appliquer les bonnes pratiques (stocker les clés correctement, limiter les permissions, journaliser, contrôler les coûts, anonymiser).

Prérequis : IA-04 (tokens, LLM), IA-13 (automatisation/nœud IA), IA-15 (Ollama) et IA-17/IA-18 (sécurité des données, clés API, coûts).

---

3. Niveau

Professionnel.

Ce module ouvre la Partie 5 (créer des outils). Il reste conceptuel : on comprend les API IA pour pouvoir, ensuite, en concevoir l'usage (IA-20) — sans construire de site ni écrire son code applicatif.

---

4. Durée estimée

---

5. Résumé clair et simple

Une API (interface de programmation) est un moyen pour deux programmes de se parler. Au lieu de cliquer dans une interface, un programme envoie une requête à un service et reçoit une réponse, automatiquement. Une API IA est simplement une API qui donne accès à un modèle d'IA : votre programme envoie un texte, le modèle répond.

La grande différence avec un assistant « dans une interface » (comme ChatGPT sur le web) est l'automatisation et l'intégration. L'interface, c'est pour un humain qui discute. L'API, c'est pour brancher l'IA dans un outil : un workflow (IA-13), un script, une application. C'est ce qui permet de créer ses propres outils IA (IA-20).

Pour utiliser une API IA, il faut une clé API : un identifiant secret qui vous authentifie et permet de facturer l'usage. Chaque requête consomme des tokens (IA-04), et les tokens ont un coût. S'ajoutent des quotas (volume autorisé) et des rate limits (nombre de requêtes par minute). Comprendre ces notions évite les mauvaises surprises : une facture qui explose ou un service bloqué.

Les principaux fournisseurs proposent une API : OpenAI, Anthropic, Google (Gemini), Mistral, et l'on peut aussi exposer un modèle local via Ollama (IA-15) pour une API privée et confidentielle. Les risques à maîtriser sont clairs : ne jamais exposer sa clé API, contrôler les coûts, et ne pas envoyer de données sensibles (IA-17). Bien utilisées, les API IA sont la porte d'entrée vers la création d'outils intelligents.

---

6. Compétences visées

À l'issue de ce module, l'apprenant saura :

• expliquer ce qu'est une API et une API IA ;
• distinguer usage par interface et usage par API ;
• décrire le cycle requête → traitement → réponse et le rôle des tokens ;
• comprendre clé API, coût, quota et rate limit ;
• identifier les risques de sécurité et les bonnes pratiques associées ;
• repérer des cas d'usage IT pertinents ;
• choisir entre API cloud et API locale selon la confidentialité.

---

7. Notions clés à comprendre

• API (Application Programming Interface) : moyen standardisé pour deux programmes de communiquer.
• API IA : API donnant accès à un modèle d'IA (envoi de texte, réception d'une réponse générée).
• Clé API : identifiant secret qui authentifie les requêtes et permet la facturation.
• Requête : message envoyé au service (votre texte + paramètres).
• Réponse : ce que le service renvoie (la sortie du modèle).
• Token : unité de texte (IA-04) ; la consommation se mesure en tokens (entrée + sortie).
• Coût : facturation généralement au nombre de tokens (entrée et sortie).
• Quota : volume d'usage autorisé sur une période.
• Rate limit : nombre maximal de requêtes par unité de temps.
• Endpoint : l'adresse (URL) à laquelle on envoie la requête.

---

8. Cours complet structuré

8.1 — Qu'est-ce qu'une API ?

Une API est un point de communication standardisé entre programmes. Un programme A envoie une requête à un programme/service B, qui renvoie une réponse. Tout cela sans interface graphique : c'est de la communication machine à machine.

Analogie. Une API, c'est comme un guichet avec des règles précises : vous présentez une demande dans le bon format, on vous rend un résultat dans un format attendu. Vous n'avez pas besoin de savoir ce qui se passe « derrière le guichet ».

8.2 — Qu'est-ce qu'une API IA ?

Une API IA est une API qui donne accès à un modèle d'IA. Votre programme envoie un texte (un prompt, éventuellement avec des paramètres), et l'API renvoie la réponse générée par le modèle.

C'est ce qui permet d'intégrer l'IA dans vos propres outils : un workflow (IA-13), un script (IA-11), une application. L'API IA est le moteur ; vous construisez la « voiture » autour.

8.3 — Interface vs API : la différence

En clair : l'interface est faite pour vous ; l'API est faite pour vos outils. Pour créer un outil IA (IA-20), on passe presque toujours par une API.

8.4 — Exemples d'API IA

• OpenAI API (modèles GPT) ;
• Anthropic API (modèles Claude) ;
• Google Gemini API ;
• Mistral API ;
• Modèles locaux via Ollama (IA-15) : Ollama expose une API locale, ce qui permet de brancher un modèle privé et confidentiel sur vos outils, sans envoyer de données dans le cloud.

Le choix dépend du besoin (puissance, langue, coût) et surtout de la confidentialité : pour des données sensibles, une API locale (Ollama) ou privée (IA-18) est souvent préférable à une API cloud publique.

8.5 — Clé API, requête, réponse

• Clé API : un secret qui identifie votre compte. Elle permet d'autoriser et de facturer vos requêtes. Si elle fuite, n'importe qui peut l'utiliser à vos frais et potentiellement accéder à des données → à protéger absolument (8.8).
• Requête : ce que vous envoyez (votre texte/prompt + des paramètres comme le modèle choisi, la longueur max…).
• Réponse : ce que le service renvoie (la sortie du modèle, plus des informations comme le nombre de tokens consommés).

Conceptuellement, une requête/réponse ressemble à un échange structuré (souvent au format JSON) : on envoie « voici mon texte et mes paramètres », on reçoit « voici la réponse et la consommation ». (Le code applicatif concret n'est pas l'objet de ce parcours.)

8.6 — Tokens, coût, quota, rate limit

• Tokens (IA-04) : le texte est découpé en tokens. On compte les tokens en entrée (votre requête) et en sortie (la réponse).
• Coût : la facturation se fait généralement au nombre de tokens. Plus la requête et la réponse sont longues, plus ça coûte. Les tarifs varient selon le modèle et le fournisseur (à vérifier sur les sites officiels).
• Quota : un volume autorisé sur une période (ou un crédit). Au-delà, le service refuse.
• Rate limit : un nombre maximal de requêtes par minute/seconde. Le dépasser provoque des erreurs temporaires → il faut espacer ou mettre en file les requêtes.

Ces quatre notions expliquent les deux mauvaises surprises classiques : une facture qui grimpe (tokens × volume) et un service bloqué (quota/rate limit atteint).

8.7 — Cas d'usage IT

Les API IA permettent de brancher l'IA dans des outils internes :

• résumé automatique (emails, tickets, documents) ;
• assistant support (aide à la rédaction de réponses) ;
• chatbot documentaire (questions/réponses sur une base interne, souvent avec RAG — IA-05) ;
• analyse / classification de tickets ;
• génération de rapports réguliers.

Ces usages seront concrétisés dans IA-20 (créer ses outils) et IA-22 (mini-projets).

8.8 — Risques de sécurité

• Fuite de clé API : le risque n°1. Une clé en clair dans le code, un dépôt public, une capture d'écran ou un prompt = compromission. Conséquences : coûts et accès non autorisés.
• Coût incontrôlé : un outil mal réglé (boucle, volume, requêtes trop longues) fait exploser la facture.
• Données sensibles envoyées : via une API cloud, les données sortent ; ne jamais transmettre la liste rouge (IA-17).

8.9 — Bonnes pratiques

• Stocker les clés correctement : jamais en clair dans le code ou un prompt ; utiliser des variables d'environnement ou un coffre à secrets ; ne pas les committer dans un dépôt.
• Limiter les permissions des clés et les faire tourner (rotation), révoquer en cas de doute.
• Contrôler les coûts : plafonds, alertes, suivi de consommation, modèle adapté au besoin, requêtes courtes.
• Respecter quotas et rate limits : espacer/mettre en file les requêtes, gérer les erreurs.
• Anonymiser les données envoyées (IA-17) ; préférer une API locale (Ollama) pour le sensible.
• Journaliser les usages (traçabilité, IA-18).

---

9. Exemples concrets liés au monde IT

1. Résumé de tickets. Un outil interne envoie chaque ticket (anonymisé) à une API IA et stocke un résumé. Coût maîtrisé par des requêtes courtes.
2. Assistant support. Une API génère un brouillon de réponse ; un humain valide avant envoi (IA-13).
3. Chatbot documentaire (RAG). Les questions sont enrichies par des extraits de la base interne avant d'appeler l'API (IA-05).
4. Classification de tickets. L'API attribue catégorie/urgence ; les cas critiques sont validés humainement.
5. Rapport quotidien. Un script appelle l'API une fois par jour pour synthétiser des indicateurs (rate limit respecté).
6. API locale (Ollama). Pour des logs sensibles, on utilise un modèle local exposé en API → aucune donnée ne sort (IA-15, IA-16).
7. Clé compromise évitée. Les clés sont en variables d'environnement, jamais dans le code partagé → pas de fuite via un dépôt.

Constante : l'API branche l'IA dans vos outils ; sécurité des clés, coûts et confidentialité sont les trois points de vigilance.

---

10. Cas pratique guidé

Objectif : concevoir l'usage d'une API IA pour un outil de résumé de tickets, en maîtrisant sécurité et coûts (sans écrire le code applicatif).

Contexte. Vous voulez un outil interne qui résume automatiquement les nouveaux tickets.

Étape 1 — Choisir cloud ou local. Les tickets contiennent-ils des données sensibles ? Si oui (noms, données clients), privilégiez une API locale (Ollama, IA-15) ou anonymisez fortement avant une API cloud.

Étape 2 — Définir la requête. Décidez ce que vous envoyez : l'objet + le corps anonymisés, et un prompt clair (« Résume en 2 lignes, propose une catégorie »). Limitez la longueur pour maîtriser les tokens.

Étape 3 — Protéger la clé API. La clé sera stockée en variable d'environnement / coffre à secrets, jamais dans le code partagé ni dans un prompt. Prévoyez sa rotation et sa révocation.

Étape 4 — Maîtriser coûts et limites. Estimez le volume (combien de tickets/jour × tokens). Fixez un plafond et une alerte. Respectez le rate limit (espacer les requêtes si gros volume).

Étape 5 — Vérifier et journaliser. La sortie (résumé/catégorie) est vérifiée (IA-09) ; les cas critiques passent par une validation humaine ; les usages sont journalisés (IA-18).

Résultat du cas pratique : une conception d'usage d'API claire — confidentialité arbitrée, clé protégée, coûts plafonnés, sorties vérifiées.

---

11. Exercice pratique à faire seul

Consigne. Concevez (sans coder) l'usage d'une API IA pour un besoin IT de votre choix (résumé, classification, assistant support, rapport). Décrivez :

1. le besoin et le choix cloud vs local (justifié par la confidentialité) ;
2. la requête (que contient-elle ? qu'anonymisez-vous ? longueur ?) ;
3. la gestion de la clé API (stockage, permissions, rotation) ;
4. la maîtrise des coûts (volume estimé, plafond, alerte) et le respect du rate limit ;
5. la vérification des sorties et la validation humaine éventuelle ;
6. 2 risques de sécurité et leur parade.

Contexte. Vous raisonnez en concepteur d'outil IA responsable.

Résultat attendu. Une fiche de conception d'usage d'API.

Critères de réussite :

• choix cloud/local justifié ;
• requête minimisée et anonymisée ;
• gestion de clé sécurisée ;
• coûts et rate limit pris en compte ;
• vérification et validation prévues ;
• risques et parades identifiés.

---

12. Quiz de 10 questions QCM

Une seule bonne réponse par question.

Q1. Qu'est-ce qu'une API ?

• A. Un écran
• B. Un moyen standardisé pour deux programmes de communiquer
• C. Un modèle d'IA
• D. Un mot de passe

Q2. Qu'est-ce qu'une API IA ?

• A. Une API qui donne accès à un modèle d'IA
• B. Un antivirus
• C. Une interface graphique uniquement
• D. Un type de GPU

Q3. Différence entre interface et API ?

• A. Aucune
• B. L'interface est faite pour un humain ; l'API pour intégrer l'IA dans un programme
• C. L'API est plus lente
• D. L'interface ne fonctionne pas

Q4. Qu'est-ce qu'une clé API ?

• A. Un identifiant secret qui authentifie les requêtes et permet la facturation
• B. Un type de token public
• C. Un fichier de log
• D. Une adresse IP

Q5. La facturation d'une API IA se fait généralement :

• A. Au nombre de clics
• B. Au nombre de tokens (entrée + sortie)
• C. Au poids du fichier
• D. À l'heure de connexion

Q6. Qu'est-ce qu'un rate limit ?

• A. Le coût d'une requête
• B. Le nombre maximal de requêtes par unité de temps
• C. La taille du modèle
• D. Le nom de l'endpoint

Q7. Quel est le risque n°1 avec une clé API ?

• A. Qu'elle soit trop longue
• B. Sa fuite (coûts et accès non autorisés)
• C. Qu'elle soit en français
• D. Aucun risque

Q8. Comment stocker une clé API ?

• A. En clair dans le code partagé
• B. En variable d'environnement / coffre à secrets, jamais en clair
• C. Dans un prompt
• D. Sur un forum public

Q9. Pour des données sensibles, quelle option d'API est préférable ?

• A. Une API cloud publique sans précaution
• B. Une API locale (Ollama) ou privée, pour que les données ne sortent pas
• C. Un email non chiffré
• D. Aucune anonymisation

Q10. Comment éviter une facture qui explose ?

• A. Ne rien surveiller
• B. Plafonds, alertes, requêtes courtes, modèle adapté, suivi de consommation
• C. Envoyer le plus de tokens possible
• D. Ignorer les quotas

---

13. Réponses corrigées du quiz avec explications

Q1 → B. Une API permet à deux programmes de communiquer. A, C et D sont faux.

Q2 → A. Une API IA donne accès à un modèle d'IA. B, C et D sont faux.

Q3 → B. L'interface est pour l'humain, l'API pour l'intégration. A, C et D sont faux.

Q4 → A. La clé API est un secret qui authentifie et permet la facturation. B, C et D sont faux.

Q5 → B. La facturation se fait au nombre de tokens (entrée + sortie). Les autres réponses sont fausses.

Q6 → B. Le rate limit est le nombre max de requêtes par unité de temps. A, C et D sont faux.

Q7 → B. La fuite de clé (coûts + accès) est le risque n°1. A, C et D sont faux.

Q8 → B. On stocke la clé en variable d'environnement / coffre, jamais en clair. A, C et D l'exposent.

Q9 → B. API locale (Ollama) ou privée pour les données sensibles. A, C et D exposent les données.

Q10 → B. Plafonds, alertes, requêtes courtes, modèle adapté, suivi. A, C et D font déraper les coûts.

Barème indicatif : 8/10 ou plus = notions acquises. 5 à 7 = relisez les sections 8.6 et 8.8. Moins de 5 = reprenez le cours et rejouez le cas pratique.

---

14. Flashcards de révision

Carte 1 Q : Qu'est-ce qu'une API ? R : Un moyen standardisé pour deux programmes de communiquer (requête → réponse).

Carte 2 Q : Qu'est-ce qu'une API IA ? R : Une API qui donne accès à un modèle d'IA.

Carte 3 Q : Interface vs API ? R : L'interface est pour un humain ; l'API pour intégrer l'IA dans un programme.

Carte 4 Q : Qu'est-ce qu'une clé API ? R : Un identifiant secret qui authentifie les requêtes et permet la facturation.

Carte 5 Q : Comment se fait la facturation d'une API IA ? R : Généralement au nombre de tokens (entrée + sortie).

Carte 6 Q : Qu'est-ce qu'un quota ? R : Un volume d'usage autorisé sur une période.

Carte 7 Q : Qu'est-ce qu'un rate limit ? R : Le nombre maximal de requêtes par unité de temps.

Carte 8 Q : Risque n°1 avec une clé API ? R : Sa fuite : coûts et accès non autorisés.

Carte 9 Q : Comment stocker une clé API ? R : En variable d'environnement / coffre à secrets, jamais en clair ni dans un prompt.

Carte 10 Q : API pour données sensibles ? R : API locale (Ollama) ou privée, pour que les données ne sortent pas.

Carte 11 Q : Deux mauvaises surprises classiques avec une API ? R : Facture qui grimpe (tokens × volume) et service bloqué (quota / rate limit).

Carte 12 Q : Exemples de fournisseurs d'API IA ? R : OpenAI, Anthropic, Google Gemini, Mistral ; et modèles locaux via Ollama.

---

15. Erreurs fréquentes

• Exposer sa clé API (code partagé, dépôt public, capture, prompt).
• Ne pas surveiller les coûts (tokens × volume).
• Envoyer des données sensibles à une API cloud.
• Ignorer quotas et rate limits (service bloqué).
• Requêtes trop longues inutilement (coût gonflé).
• Pas de rotation/révocation des clés.
• Pas de journalisation des usages.
• Choisir le cloud pour du sensible alors qu'une API locale conviendrait.

---

16. Bonnes pratiques

• Protéger les clés API (variables d'environnement/coffre, permissions limitées, rotation, révocation).
• Contrôler les coûts (plafonds, alertes, requêtes courtes, modèle adapté).
• Respecter quotas et rate limits (espacer/mettre en file, gérer les erreurs).
• Anonymiser les données ; préférer l'API locale (Ollama) pour le sensible (IA-15).
• Vérifier les sorties (IA-09) et garder la validation humaine.
• Journaliser les usages (IA-18).
• Choisir le fournisseur/modèle selon besoin, langue, coût et confidentialité.

---

17. Point vigilance : limites, risques, sécurité et vérification humaine

Bloc obligatoire à lire attentivement.

Ce qu'il faut vérifier :

• la protection de la clé API (jamais en clair, permissions limitées) ;
• le coût estimé (tokens × volume) et les plafonds ;
• les quotas / rate limits du fournisseur ;
• l'exactitude des sorties (IA-09).

Ce qu'il ne faut pas faire :

• exposer une clé API (code, dépôt, capture, prompt) ;
• envoyer des données sensibles à une API cloud (liste rouge, IA-17) ;
• laisser un outil tourner sans plafond de coût ;
• diffuser une sortie non vérifiée.

Risques de mauvaise utilisation :

• compromission de la clé (coûts/accès) ;
• facture incontrôlée ;
• fuite de données ; service bloqué par dépassement.

Risques de confidentialité :

• via une API cloud, les données sortent ;
• préférer une API locale/privée pour le sensible ; RGPD et données sensibles : IA-17 ; gouvernance : IA-18.

Limites des API IA :

• elles donnent accès à un modèle faillible (hallucinations, IA-04) ;
• elles ne dispensent ni de vérification ni de validation humaine.

Cas où une validation humaine est indispensable :

• toute sortie destinée à un client ou à un livrable officiel ;
• toute action à impact déclenchée à partir d'une réponse d'API ;
• tout traitement de données sensibles.

Principe à retenir : une API IA branche l'IA dans vos outils. Maîtrisez les clés (secrets), les coûts et la confidentialité, et vérifiez les sorties. Pour le sensible : API locale/privée (IA-15, IA-18).

---

18. Mini-projet de fin de module

Titre : « Fiche d'usage d'une API IA pour un outil interne »

Objectif. Concevoir, sur le plan de l'usage (sans code applicatif), l'intégration d'une API IA dans un outil interne, en maîtrisant sécurité, coûts et confidentialité.

Contexte. Vous préparez l'usage d'une API IA pour un besoin réel (résumé, classification, assistant support…). Aucun code de site n'est demandé.

Prérequis. Avoir lu le cours (section 8) ; IA-17 (sécurité des données).

Étapes :

1. Définir le besoin et le cas d'usage.
2. Choisir cloud ou local/privé selon la sensibilité des données.
3. Décrire la requête type (contenu anonymisé, longueur, paramètres).
4. Définir la gestion des clés (stockage, permissions, rotation, révocation).
5. Estimer et plafonner les coûts ; prévoir le respect du rate limit.
6. Définir la vérification des sorties et la validation humaine.
7. Prévoir la journalisation et la conduite en cas d'incident (clé compromise).

Résultat attendu. Une fiche d'usage d'API claire et sécurisée.

Critères de réussite :

• besoin et cas d'usage clairs ;
• choix cloud/local justifié ;
• requête minimisée/anonymisée ;
• gestion des clés et des coûts solide ;
• vérification, validation et journalisation prévues ;
• conduite en cas d'incident incluse.

Amélioration possible. Reliez cette fiche au module IA-20 : vous y transformerez cet usage d'API en un véritable petit outil IA (entrée → contexte → IA → sortie → vérification → journalisation).

---

19. Ressources gratuites recommandées

Ne recommander que des ressources gratuites ou accessibles gratuitement. Toute ressource dont la gratuité ou la disponibilité n'est pas certaine est signalée par la mention « À vérifier avant publication. »

• Documentation officielle des API (OpenAI, Anthropic, Google Gemini, Mistral) — pour comprendre requêtes, tokens, tarifs, quotas et rate limits. Consultation gratuite. À vérifier avant publication (tarifs et limites évoluent ; vérifier sur les sites officiels).
• Documentation d'Ollama — ollama.com — pour exposer un modèle local via une API locale (confidentialité). À vérifier avant publication (vérifier le lien).
• Concepts d'API REST / JSON — de nombreux guides gratuits expliquent requête/réponse et le format JSON, utiles pour comprendre (sans coder un site). À vérifier avant publication (choisir une source fiable).
• « Objectif IA » (OpenClassrooms) — pour le cadre général de l'IA générative. (Gratuit, vérifié ; compte gratuit possible.)

Remarque : pour les tarifs et limites exacts, seuls les sites officiels font foi. Ce module ne promet aucune certification.

---

20. Résumé final du module

• Une API permet à deux programmes de communiquer (requête → réponse) ; une API IA donne accès à un modèle d'IA.
• L'interface est pour un humain ; l'API sert à intégrer l'IA dans des outils (IA-20) — automatisable et à grande échelle.
• Fournisseurs : OpenAI, Anthropic, Gemini, Mistral, et Ollama pour une API locale confidentielle.
• Notions clés : clé API (secret), requête/réponse, tokens, coût (au token), quota, rate limit.
• Risques : fuite de clé (n°1), coût incontrôlé, données sensibles envoyées.
• Bonnes pratiques : protéger les clés, plafonner les coûts, respecter quotas/rate limits, anonymiser, préférer l'API locale pour le sensible, vérifier les sorties, journaliser.
• Les API IA sont la porte d'entrée vers la création d'outils (IA-20), d'agents (IA-21), de mini-projets (IA-22) et d'un SaaS (IA-23).

---

21. Validation demandée avant le module suivant

Validation demandée avant le module suivant

Souhaites-tu que je passe au module suivant ou que je corrige/améliore ce module d'abord ?

(Modules suivants produits à la suite, à valider ensemble : IA-20 — Créer ses propres outils IA et IA-21 — Introduction aux agents IA.)