Évaluer une API
Choisir une API est une décision produit
À un moment donné, votre équipe technique dira : "On a besoin d'un service pour X." Ça peut être l'envoi de SMS, le traitement de paiements, le géocodage d'adresses ou la génération d'images. Il y aura plusieurs options. Et en choisir une, ce n'est pas juste une décision technique. C'est une décision produit.
L'API que vous choisissez affecte la tarification, la fiabilité, l'expérience utilisateur, et la vitesse à laquelle votre équipe peut livrer. En tant que PM, vous devez savoir quoi regarder.
Ce qu'il faut évaluer
Modèle de tarification
Les API facturent différemment. Certaines facturent par requête (chaque appel API coûte de l'argent). D'autres facturent par utilisateur ou par siège. Certaines ont un niveau gratuit qui couvre l'usage de base et facturent une fois que vous le dépassez.
C'est important parce que ça affecte directement votre économie unitaire. Si vous envoyez 10 000 SMS par mois, la différence entre 0,0075 $ et 0,004 $ par message s'accumule vite.
Rate limits
La plupart des API limitent le nombre de requêtes que vous pouvez faire dans une fenêtre de temps donnée. Twilio peut autoriser 100 requêtes par seconde. Une API gratuite peut vous limiter à 10 par minute.
Pourquoi est-ce important ? Si votre application envoie une campagne marketing à 50 000 utilisateurs et que l'API SMS n'autorise que 100 messages par seconde, cette campagne prend plus de 8 minutes à envoyer. Les rate limits affectent ce que votre produit peut faire, pas seulement la façon dont votre équipe technique le construit.
Developer experience (DX)
Vous connaissez l'UX (user experience). La DX, c'est le même concept, mais pour les développeurs. C'est la facilité et le plaisir qu'a votre équipe technique à travailler avec l'API.
Une bonne DX signifie que vos développeurs peuvent intégrer plus vite et avec moins d'erreurs. Une mauvaise DX signifie plus de tâtonnements, plus de bugs, plus d'allers-retours avec le support du fournisseur. Ce qui fait une bonne DX :
- Documentation : des explications claires, des exemples de code concrets, des pages de référence à jour.
- SDK : des bibliothèques prêtes à l'emploi dans les langages populaires (Python, JavaScript, etc.) pour que votre équipe n'ait pas à écrire des requêtes HTTP brutes. Stripe, par exemple, fournit des SDK qui transforment une requête de 15 lignes en un seul appel de fonction.
- Sandbox ou mode test : un moyen d'essayer l'API sans conséquences réelles. Le mode test de Stripe utilise de fausses cartes bancaires. Twilio permet d'envoyer des SMS de test sans frais.
- Messages d'erreur : quand quelque chose ne va pas, est-ce que l'API vous dit ce qui s'est passé et comment corriger ? Une bonne erreur dit "Format de numéro de téléphone invalide. Format E.164 attendu, par exemple +33612345678." Une mauvaise dit juste "Bad request."
Pourquoi devriez-vous, en tant que PM, vous soucier de la DX ? Parce que ça affecte directement la vitesse de livraison de votre équipe. Une API avec une excellente DX peut prendre quelques jours à intégrer. La même fonctionnalité avec une API mal documentée pourrait prendre des semaines, plus des maux de tête de maintenance permanents.
Fiabilité
Si le service SMS tombe en panne, vos clients ne reçoivent pas leurs confirmations de commande. Si l'API de paiement a des interruptions, vous ne pouvez plus facturer personne.
La plupart des fournisseurs d'API publient un SLA (Service Level Agreement), une garantie de disponibilité. 99,9 % de disponibilité, ça semble bien, mais ça représente quand même environ 8 heures d'indisponibilité par an. 99,99 %, c'est environ 50 minutes. La différence compte quand votre chiffre d'affaires en dépend.
Webhooks et support temps réel
Est-ce que l'API envoie des webhooks quand quelque chose se passe ? Ou devez-vous faire du polling (vérifier en boucle) ?
Si Twilio vous envoie un webhook quand un SMS est délivré, votre application le sait immédiatement. Si un service concurrent ne supporte pas les webhooks, votre serveur doit continuer à demander "est-ce que c'est délivré ?" toutes les quelques secondes. C'est plus de travail pour votre équipe et une moins bonne expérience pour vos utilisateurs.
Comparaison : Twilio vs Vonage pour le SMS
Comparons deux vrais fournisseurs de SMS pour voir comment ces critères se concrétisent :
| Criteria | Twilio | Vonage |
|---|---|---|
| Pricing (per SMS) | $0.0079 per message (US) | $0.0068 per message (US) |
| Free tier | Free trial with $15 credit | Free trial with EUR 2 credit |
| Rate limits | 100 messages/second default | 30 messages/second default |
| Developer experience | Extensive docs, SDKs in 7 languages, sandbox mode | Good docs, SDKs in 6 languages, fewer interactive examples |
| Webhooks | Yes, delivery status callbacks | Yes, delivery receipts via webhook |
| Uptime SLA | 99.95% | 99.99% |
| Support | Email, chat, phone (paid plans) | Email, chat (paid plans) |
Aucune option n'est objectivement "meilleure". Vonage est moins cher par message mais a des rate limits par défaut plus bas. Twilio offre une meilleure developer experience et un crédit gratuit plus élevé, mais coûte un peu plus cher. Si vous envoyez de gros volumes, les rate limits peuvent compter plus que le coût par message. Si votre équipe est petite et doit aller vite, la qualité de la documentation peut vous faire gagner des jours de temps de développement.
L'idée à retenir : c'est une analyse de compromis, exactement le genre de décision que les PM prennent tous les jours.
Les questions à poser avant de choisir
Avant que votre équipe s'engage avec un fournisseur d'API, passez en revue cette checklist :
| Question | Pourquoi c'est important |
|---|---|
| Combien ça coûte par requête/utilisateur/mois ? | Affecte vos marges. Pas cher à 1 000 utilisateurs, coûteux à 100 000. |
| Y a-t-il un niveau gratuit ou une sandbox pour tester ? | Permet à votre équipe de tester sans frais et de repérer les problèmes tôt. |
| Quels sont les rate limits ? | Détermine ce que votre produit peut faire à grande échelle (envois en masse, pics de trafic). |
| Est-ce que ça supporte les webhooks ? | Notifications en temps réel vs. polling. Gros impact sur l'expérience utilisateur et l'effort technique. |
| Quel est le SLA de disponibilité ? | Combien de temps d'indisponibilité par an. Important si l'API est sur un chemin critique. |
| Comment est la developer experience ? | Une bonne DX (docs, SDK, sandbox, messages d'erreur) = intégration plus rapide, moins de bugs. |
| Que se passe-t-il si on dépasse les capacités de ce fournisseur ? | Changer d'API coûte cher. Vérifiez si le format de données et les patterns sont standards. |
| Y a-t-il un concurrent qu'on devrait évaluer ? | Comparez toujours au moins deux options. Ne choisissez pas la première qui fonctionne. |
Vous n'avez pas besoin de répondre à toutes ces questions vous-même. Mais les poser lors de la discussion avec votre équipe technique montre que vous comprenez les enjeux, et aide l'équipe à prendre une meilleure décision ensemble.
Points clés
- Choisir une API est une décision produit, pas seulement une décision technique. Ça affecte la tarification, la vitesse, la fiabilité et l'expérience utilisateur.
- Les critères principaux : modèle de tarification, rate limits, developer experience (DX), fiabilité (SLA), et support des webhooks.
- Comparez toujours au moins deux options. L'API la moins chère par requête peut avoir les pires rate limits ou la pire documentation.
- Utilisez la checklist ci-dessus quand votre équipe évalue un nouveau service. Vous n'avez pas besoin d'être l'expert, mais vous devez poser les bonnes questions.