Parler à votre équipe technique
Vous n'avez pas besoin de coder. Vous avez besoin de communiquer.
L'objectif de ce cours n'a jamais été de faire de vous un développeur. C'était de vous donner le vocabulaire et les modèles mentaux pour avoir des conversations productives avec votre équipe technique. Cette leçon, c'est la mise en pratique.
Passons en revue les situations que vous rencontrerez réellement : ce que vos développeurs disent, ce que ça signifie, et ce que vous pouvez demander ensuite.
Quand votre développeur dit...
"On doit mettre en place un webhook"
Ce que ça signifie : un service externe (comme Stripe ou Twilio) doit notifier votre serveur quand quelque chose se passe. Votre équipe va créer un endpoint sur votre serveur et enregistrer son URL auprès du service externe.
Ce que vous pouvez demander : "À quels événements doit-on s'abonner ?" Ça aide à cadrer le travail. S'abonner à tous les types d'événements, c'est plus de code à écrire et à maintenir. Peut-être que vous avez seulement besoin de payment_intent.succeeded et que customer.updated ne vous intéresse pas.
"L'API a un rate limit de 100 requêtes par minute"
Ce que ça signifie : le service externe n'autorise que 100 appels API par minute. Si vous dépassez, les requêtes sont rejetées (généralement avec un code de statut 429 Too Many Requests).
Ce que vous pouvez demander : "Est-ce que ça limite ce qu'on peut faire en pic de trafic ?" Si votre fonctionnalité envoie une notification à chaque utilisateur qui passe une commande, et que vous avez 200 commandes par minute pendant une promo, vous avez un problème. C'est une contrainte produit, pas seulement une contrainte technique.
"On doit gérer la pagination"
Ce que ça signifie : quand vous demandez à une API une liste d'éléments (commandes, utilisateurs, produits), elle ne les envoie pas tous d'un coup. Elle les envoie par pages, peut-être 20 ou 50 à la fois, et vous demandez la page suivante avec un appel supplémentaire.
Ce que vous pouvez demander : "Est-ce que ça affecte les temps de chargement pour l'utilisateur ?" Si votre fonctionnalité affiche la liste de toutes les commandes passées, et que chaque page nécessite un appel API séparé, l'utilisateur pourrait voir les résultats se charger par morceaux. C'est bon à savoir lors de la conception.
"On va utiliser OAuth pour cette intégration"
Ce que ça signifie : au lieu d'une simple clé API, l'intégration nécessite que les utilisateurs se connectent et accordent une permission (comme "Se connecter avec Google"). C'est plus complexe à construire, mais nécessaire quand votre application doit agir au nom de l'utilisateur.
Ce que vous pouvez demander : "Quelles permissions demande-t-on ?" Les flux OAuth montrent à l'utilisateur un écran de consentement ("Cette application veut accéder à votre email et votre calendrier"). Demander trop de permissions fait hésiter les utilisateurs. En demander trop peu signifie que vous devrez redemander plus tard.
"La réponse ne contient pas ce champ"
Ce que ça signifie : la donnée que vous attendiez (comme le numéro de téléphone d'un utilisateur ou l'adresse de livraison d'une commande) n'est pas dans la réponse de l'API. Le endpoint ne la renvoie peut-être pas, ou elle se trouve peut-être dans un autre endpoint.
Ce que vous pouvez demander : "Y a-t-il un autre endpoint qui l'a, ou faut-il faire un second appel ?" Parfois, obtenir toutes les données dont vous avez besoin nécessite d'enchaîner deux appels API. C'est normal, mais ça ajoute de la latence et de la complexité.
Le glossaire
Voici un tableau de référence rapide. Chaque terme correspond à quelque chose que vous avez appris dans ce cours.
| Terme | Ce que ça signifie | Exemple |
|---|---|---|
| Endpoint | Une URL spécifique que votre app appelle pour faire quelque chose | POST /api/orders crée une nouvelle commande |
| API key | Une chaîne secrète qui identifie votre app auprès du service | a]Y8kP2x... dans le header Authorization |
| OAuth | Un flux de connexion où l'utilisateur autorise votre app à accéder à ses données | Bouton "Se connecter avec Google" |
| Webhook | Une requête POST qu'un service externe envoie à votre serveur quand un événement se produit | Stripe vous notifie quand un paiement réussit |
| Rate limit | Nombre maximum d'appels API autorisés dans une fenêtre de temps | 100 requêtes par minute, ensuite vous recevez une erreur 429 |
| Pagination | L'API renvoie les résultats par pages au lieu de tout d'un coup | Le premier appel renvoie les éléments 1-20, le suivant 21-40 |
| Payload | Les données envoyées dans le body d'une requête ou d'une réponse | L'objet JSON avec les détails de la commande |
| Sandbox | Un environnement de test où vous pouvez essayer l'API sans conséquences réelles | Le mode test de Stripe avec de fausses cartes bancaires |
| SLA | Service Level Agreement, la garantie de disponibilité du fournisseur | 99,95 % de disponibilité = environ 4,4 heures d'indisponibilité par an |
| Idempotent | Envoyer la même requête deux fois produit le même résultat (pas de doublons) | Réessayer un paiement ne facture pas le client deux fois |
| Polling | Vérifier une API en boucle au lieu d'attendre un webhook | Appeler GET /status toutes les 10 secondes |
| Status code | Un nombre dans la réponse qui vous dit ce qui s'est passé | 200 = succès, 404 = non trouvé, 429 = rate limited |
Les bonnes questions à poser
Vous n'avez pas besoin d'avoir toutes les réponses. Mais poser les bonnes questions fait de vous un meilleur collaborateur. Voici celles que les développeurs apprécient :
| Question | Quand la poser |
|---|---|
| Combien de temps prendra cette intégration ? | Quand vous cadrez une fonctionnalité qui dépend d'une API externe |
| Quelle authentification ça utilise ? | Quand vous évaluez un nouveau service (une API key c'est simple, OAuth c'est plus de travail) |
| Y a-t-il une sandbox ou un mode test ? | Avant de s'engager avec un fournisseur, pour que votre équipe puisse tester en toute sécurité |
| Que se passe-t-il si l'API tombe en panne ? | Quand la fonctionnalité est critique (paiements, notifications, authentification) |
| Est-ce qu'ils ont des webhooks pour ça ? | Quand votre fonctionnalité a besoin de mises à jour en temps réel du service externe |
| Quels sont les rate limits ? | Quand la fonctionnalité implique de gros volumes (emails en masse, imports en lot) |
| On peut voir un exemple de réponse ? | Quand vous rédigez les specs, pour savoir quelles données sont disponibles |
Ces questions montrent à votre équipe que vous comprenez les contraintes avec lesquelles ils travaillent. C'est tout l'intérêt.
Points clés
- Vous n'avez pas besoin d'écrire du code. Vous devez comprendre le vocabulaire suffisamment bien pour poser de bonnes questions et prendre des décisions éclairées.
- Quand votre développeur mentionne des webhooks, des rate limits, de la pagination ou OAuth, vous savez maintenant de quoi il parle et quoi demander ensuite.
- Gardez le glossaire à portée de main. C'est une référence pour chaque conversation technique que vous aurez sur les API.
- La meilleure question d'un PM n'est pas "comment ça marche ?" C'est "comment ça affecte l'expérience utilisateur ?"