Il y a quelques semaines, j'avais une app qui fonctionnait. Vraiment fonctionnait. Un formulaire, une logique, des données qui s'organisaient toutes seules. J'étais assez fière de moi.
Sauf que les données restaient là. Dans l'app. À attendre.
Pour envoyer un compte-rendu par mail, je copiais-collais. Pour mettre à jour ma liste de contacts, je copiais-collais. Pour déclencher quoi que ce soit ailleurs, je copiais-collais. À un moment, j'ai compté : sur une session de test d'une heure, j'avais ouvert l'onglet copier-coller dix-sept fois. Dix-sept.
J'avais construit quelque chose d'utile et d'inutilisable en même temps.
L'app qui fait des trucs mais reste dans son coin
Le problème n'était pas l'app. L'app marchait. Le problème, c'est qu'elle ne parlait à rien.
Elle ne savait pas envoyer un mail quand quelqu'un remplissait le formulaire. Elle ne savait pas créer une ligne dans mon tableur quand une nouvelle entrée arrivait. Elle ne savait pas prévenir qui que ce soit de quoi que ce soit. Elle faisait ses trucs dans son coin, et moi je faisais le lien à la main entre elle et le reste de mes outils.
C'est une sensation étrange. Tu as l'impression d'avoir construit quelque chose, et en même temps tu passes ton temps à jouer les intermédiaires entre tes propres outils. La promesse de l'automatisation, et la réalité du copier-coller.
Ce qui manquait, je l'ai compris plus tard, c'est une connexion. Un moyen pour mon app de parler à Gmail, à mon tableur, à n'importe quel autre service. Ce moyen, ça s'appelle une API.
Une API, c'est une porte avec un protocole
Chaque service numérique un peu sérieux a une porte. Gmail en a une. Stripe, l'outil de paiement en ligne, en a une. Notion, le service de prise de notes, en a une. Airtable, le tableur en ligne, en a une.
Cette porte, c'est l'API.
Mais une porte ne s'ouvre pas en tapant dessus avec le poing. Il y a un protocole. Un format précis pour frapper, une façon d'indiquer qui tu es et ce que tu veux. Frapper sans le protocole, et rien ne se passe. Frapper avec, et la porte s'ouvre.
La clé API, c'est le badge qui prouve que tu as le droit d'entrer. Gmail te la donne quand tu crées un accès développeur. Stripe aussi. Airtable aussi. C'est une longue chaîne de caractères, genre sk_live_AbCdEfGhIjKlMnOp, et elle ne se partage pas. Jamais. C'est le sésame.
Voilà pour la métaphore. Elle a fait son travail. On passe à ce que ça change vraiment.
Ce que ça change concrètement pour une app bricolée
Un formulaire qui envoie un mail tout seul
C'est le cas d'usage le plus simple, et c'est souvent le premier qu'on veut. Quelqu'un remplit un formulaire de contact sur ton site ou ton app. Tu veux recevoir un mail. Et lui aussi, pour confirmation.
Sans API : tu vas voir tes entrées manuellement, tu copies l'adresse, tu envoies le mail à la main.
Avec l'API de Gmail ou d'un service d'envoi de mails comme SendGrid (qui fait ça et rien d'autre, et le fait très bien) : le formulaire envoie le mail tout seul, dans la seconde, à toi et à la personne qui a rempli. Tu n'es plus dans la boucle.
J'ai mis ça en place pour un formulaire de liste d'attente sur Ask Aurelia. Quelqu'un s'inscrit, elle reçoit un mail de confirmation dans les trente secondes. Je ne touche à rien.
Un paiement qui déclenche autre chose
Stripe, c'est ce qui gère les paiements en ligne. Quand quelqu'un clique sur "payer" et entre sa carte, c'est Stripe qui traite la transaction.
Mais Stripe ne sait pas, tout seul, qu'il faut aussi créer un compte client dans ton app, envoyer une facture, ou cocher une case dans ton tableur de suivi. Pour ça, il faut lui dire. Via son API.
Le cas concret : un paiement validé par Stripe peut déclencher automatiquement la création d'une ligne dans Airtable avec le nom, le montant, la date. Plus de saisie manuelle. Plus d'oubli.
Des données qui bougent sans qu'on les pousse
Le troisième cas, c'est la synchronisation. Un nouveau contact ajouté dans un endroit qui apparaît automatiquement ailleurs.
Dans un outil interne que j'ai construit pour suivre des projets, j'avais ce problème : les informations étaient à deux endroits différents et je devais les maintenir à jour à la main. Avec une connexion API entre les deux, la mise à jour se propage. On entre l'information une fois. Elle voyage toute seule.
À chaque fois que j'ai mis en place une de ces connexions, j'ai eu le même sentiment : pourquoi j'ai attendu si longtemps.
Avant, il fallait savoir. Maintenant, il faut demander.
Je vais être honnête sur ce qu'était la réalité avant Claude Code.
Connecter une API, ça demandait de lire une documentation technique. Stripe a une doc de plusieurs centaines de pages. Gmail aussi. Airtable aussi. Ces docs sont bien faites, mais elles sont écrites pour des développeurs. Elles supposent que tu sais ce qu'est une requête HTTP, que tu comprends la différence entre GET et POST, que tu sais lire un exemple de code en Python ou en JavaScript.
Moi, je ne savais pas. Je lisais, je comprenais à peu près le principe, et je bloquais sur l'implémentation. Comment exactement est-ce que j'écris ça dans mon code ? Dans quel ordre ? Qu'est-ce que je mets où ?
Avec Claude Code, j'ai changé de méthode. Je décris ce que je veux en français. "Je veux que quand quelqu'un remplit ce formulaire, mon app appelle l'API de SendGrid pour envoyer un mail de confirmation à l'adresse qu'il a entrée." Claude Code lit la documentation à ma place, génère le code, et me l'explique.
Ce n'est pas de la magie. C'est une délégation. La partie que je ne savais pas faire, je la délègue. La partie qui reste à faire, c'est tester, vérifier que ça marche, comprendre les erreurs quand ça ne marche pas. Ce n'est pas rien. Mais la barrière d'entrée s'est effondrée.
La première connexion API que j'ai mise en place seule, avec Claude Code, m'a pris une après-midi. Avant, j'aurais soit abandonné soit payé quelqu'un pour le faire à ma place. Là, j'ai compris ce que je faisais pendant que je le faisais. C'est très différent.
Ce qu'on ne peut pas éviter de comprendre quand même
Je ne vais pas te vendre du rêve pur. Il y a quelques notions qu'on croise inévitablement et qu'il vaut mieux avoir vues une fois avant de les rencontrer dans le vif du sujet.
La clé API, d'abord. On en a parlé : c'est le badge d'entrée. La règle absolue, c'est de ne jamais la mettre dans du code visible. Pas dans un fichier que tu partages. Pas dans ton interface publique. Elle va dans ce qu'on appelle les variables d'environnement, un endroit protégé où l'app peut la lire sans qu'elle soit exposée. Claude Code sait où la mettre. Laisse-le faire.
Ensuite, les erreurs 401 et 403. Quand une connexion API ne fonctionne pas, ces deux codes reviennent souvent. Le 401, c'est "je ne te reconnais pas" : ta clé est absente ou mal formatée. Le 403, c'est "je te reconnais mais tu n'as pas le droit" : ta clé existe mais elle n'a pas les permissions pour faire ce que tu demandes. Dans les deux cas, le problème est côté accès, pas côté code.
Le 404, lui, c'est "cette adresse n'existe pas" : tu frappes à une porte qui n'est pas là. Souvent une faute de frappe dans l'URL de l'API, ou une version de l'API qui a changé.
Et le webhook, pour finir. Jusqu'ici, j'ai décrit des connexions où c'est ton app qui va chercher l'information ou déclenche une action. Le webhook, c'est l'inverse : c'est un service externe qui prévient ton app quand quelque chose se passe. Stripe utilise beaucoup les webhooks : quand un paiement est validé, Stripe envoie une notification à ton app. Ton app n'a pas besoin de vérifier toutes les cinq minutes si quelque chose a changé. Elle attend qu'on lui dise.
Ces quatre notions ne font pas de toi une développeuse. Elles font de toi quelqu'un qui comprend ce que Claude Code fait quand il travaille, et qui peut lire un message d'erreur sans paniquer.
Les connexions que j'ai testées, et ce que j'en pense
Pour Pimpela, l'app qui regarde ma garde-robe et propose des tenues, j'avais besoin de deux choses : la météo du jour et mon agenda. Deux API.
L'API météo a été la plus simple. Il en existe des gratuites pour des usages modérés, la documentation est claire, et Claude Code a généré le code en dix minutes. Aucune surprise.
L'API Google Calendar, pour récupérer les événements du jour, a été plus compliquée. Pas à cause du code, mais à cause de l'authentification. Google a un système de permissions en plusieurs étapes, et le mettre en place correctement m'a pris une journée entière. Pas parce que c'est insurmontable. Parce que je ne savais pas dans quel ordre faire les choses, et que j'ai dû recommencer deux fois. La troisième fois était la bonne.
Pour Ask Aurelia, l'assistante qui répond comme une amie qui s'y connaît, j'utilise l'API d'Anthropic, qui fabrique Claude. C'est le coeur de l'app : chaque question posée par l'utilisatrice part vers cette API, qui renvoie une réponse. Cette connexion-là, je la comprends maintenant dans ses moindres détails. Je sais ce que j'envoie, je sais ce que je reçois, je sais où ça peut coincer.
Ce que j'ai appris de ces expériences : les premières connexions prennent du temps non pas parce qu'elles sont complexes, mais parce qu'on ne sait pas encore où regarder quand quelque chose ne marche pas. Après deux ou trois API connectées, on développe un instinct. On sait que si ça bloque, c'est probablement l'authentification. On sait que si la réponse est vide, c'est peut-être un problème de permissions. On apprend à lire les erreurs comme on apprend à lire une carte : la première fois, c'est du bruit. La cinquième fois, c'est de l'information.
L'app isolée qui fait ses trucs dans son coin, c'est une étape. Utile, mais limitée. Dès qu'elle commence à parler au reste du monde, elle devient autre chose.