Tester votre propre API
Quand votre produit est l'API
Tout au long de ce cours, vous étiez du côté consommateur : votre application appelle Twilio, Stripe ou Google Maps. Mais parfois, votre entreprise est de l'autre côté. Votre produit expose une API que d'autres développeurs utilisent.
Peut-être que vous travaillez dans une fintech et que des partenaires intègrent votre API de paiement. Peut-être que votre plateforme a une API publique qui permet aux clients d'automatiser des workflows. Peut-être que votre produit se connecte à d'autres outils via une API.
Dans tous ces cas, les développeurs qui utilisent votre API sont vos utilisateurs. Et en tant que PM, vous devriez pouvoir tester ce qu'ils vivent.
Pourquoi les PM devraient tester leur propre API
Vous ne livreriez pas une nouvelle fonctionnalité sans la tester vous-même en cliquant partout. C'est pareil pour votre API. La tester vous permet de :
- Repérer les problèmes avant vos utilisateurs. Si une réponse manque un champ ou si un message d'erreur est confus, vous le verrez.
- Comprendre ce que vivent les développeurs. Si ça vous prend 20 minutes pour comprendre comment s'authentifier, imaginez un développeur qui évalue votre API face à celle d'un concurrent.
- Écrire de meilleures spécifications. Quand vous avez réellement envoyé une requête et lu la réponse, vous savez exactement ce que fait l'API. Pas de devinettes.
Vous n'avez pas besoin de tester chaque cas limite. Votre QA et votre équipe technique s'en occupent. Mais envoyer quelques requêtes à votre propre API et vérifier les réponses ? C'est quelque chose que tout PM peut (et devrait) faire.
Postman : votre outil de test
Postman est un outil gratuit qui vous permet d'envoyer des requêtes API sans écrire de code. Vous choisissez une méthode (GET, POST, PUT, DELETE), tapez une URL, ajoutez des headers, écrivez un body, et cliquez sur Send. Il affiche la réponse dans un format propre et lisible.
Voyez-le comme un navigateur pour les API. Un navigateur n'envoie que des requêtes GET (quand vous tapez une URL et appuyez sur Entrée). Postman vous permet d'envoyer n'importe quel type de requête.
Voici à quoi ressemble le test d'un endpoint simple en pratique. Disons que votre produit a une API publique et que vous voulez tester le endpoint "lister toutes les commandes" :
Vous tapez ça dans Postman, cliquez sur Send, et vous recevez la réponse JSON. Vous pouvez immédiatement vérifier : est-ce que les champs sont nommés clairement ? Est-ce que les données sont correctes ? Est-ce que la pagination fonctionne ? Est-ce que l'erreur est utile si vous supprimez la clé API ?
Ce qu'il faut regarder quand vous testez
Vous ne déboguez pas du code. Vous vérifiez l'expérience. Voici ce à quoi faire attention :
Est-ce que les réponses ont du sens ?
Envoyez une requête et lisez le JSON qui revient. Est-ce que les noms de champs sont clairs ? Si un développeur voit "st": 1 dans la réponse, il ne sait pas ce que ça veut dire. "status": "active" est évident. Le nommage des champs est une décision produit.
Est-ce que les messages d'erreur sont utiles ?
Essayez d'envoyer une mauvaise requête volontairement. Supprimez la clé API. Utilisez un mauvais endpoint. Envoyez un body invalide. Qu'est-ce qui revient ?
| What you send | Bad error | Good error |
|---|---|---|
| Missing API key | 401 Unauthorized | 401: Missing API key. Include it in the Authorization header as 'Bearer YOUR_KEY'. |
| Invalid phone number | 400 Bad Request | 400: Invalid 'phone' format. Expected E.164 format (e.g. +33612345678). |
| Non-existent resource | 404 Not Found | 404: No order found with ID 'ord_999'. Check the ID and try again. |
La différence est énorme. Une mauvaise erreur pousse les développeurs à ouvrir un ticket de support. Une bonne erreur leur dit exactement quoi corriger. En tant que PM, vous pouvez signaler ça et pousser pour de meilleurs messages.
Est-ce que la documentation correspond à la réalité ?
Ouvrez votre documentation API à côté de Postman. Est-ce que le endpoint renvoie exactement ce que la doc indique ? Y a-t-il des champs dans la réponse qui ne sont pas documentés ? Y a-t-il des champs documentés qui n'apparaissent pas ? Les écarts entre la documentation et la réalité sont l'une des principales frustrations des développeurs qui utilisent une API.
Est-ce que la sandbox fonctionne ?
Si votre API a un mode test ou une sandbox, essayez-la. Est-ce qu'un nouveau développeur peut s'inscrire, obtenir une clé API de test et faire son premier appel en moins de 5 minutes ? Si non, c'est une friction que vous devez connaître.
La checklist DX
Quand votre produit expose une API publique, la developer experience fait partie de l'expérience produit. Voici à quoi ressemble une bonne DX :
| Area | What to check | Why it matters |
|---|---|---|
| Onboarding | Can a developer go from signup to first successful API call in under 5 minutes? | First impressions. If it's hard to start, developers try the competitor. |
| Documentation | Are there clear examples for every endpoint? Is there a quickstart guide? | Developers don't read docs top to bottom. They scan for examples and copy-paste. |
| Error messages | Do errors explain what went wrong and how to fix it? | Bad errors = support tickets. Good errors = self-service. |
| Sandbox | Is there a test mode with fake data and no real consequences? | Developers want to experiment before committing. No sandbox = no experimentation. |
| Consistency | Are naming conventions, pagination, and auth patterns the same across all endpoints? | If /orders uses 'limit' and /users uses 'count' for the same thing, developers get confused. |
| Changelog | Are breaking changes announced in advance? Is there a versioning strategy? | Developers build on top of your API. Breaking their integration without warning breaks their trust. |
Vous n'avez pas besoin d'auditer chaque ligne de documentation. Mais passer en revue cette checklist de temps en temps vous donne une vision réaliste de ce que vivent vos utilisateurs API.
Points clés
- Quand votre produit expose une API publique, les développeurs qui l'utilisent sont vos utilisateurs. Leur expérience compte autant que celle de vos utilisateurs finaux.
- Postman vous permet de tester des requêtes API sans écrire de code. C'est le moyen le plus simple de voir ce que fait réellement votre API.
- Concentrez-vous sur ce que vous pouvez évaluer en tant que PM : la clarté des réponses, les messages d'erreur, la précision de la documentation et les frictions à l'onboarding.
- Une bonne developer experience (DX) n'est pas un bonus. C'est ce qui détermine si les développeurs choisissent votre API ou celle d'un concurrent.