🎯 Situation
Un client est venu nous voir avec un problème très courant. Son activité tournait sur quatre outils : Shopify pour l'e-commerce, HubSpot pour le CRM, Zendesk pour le support client, et QuickBooks pour la comptabilité. Chacun avait son propre dashboard. Aucun dashboard ne se parlait.
Ils voulaient répondre à une seule question simple : quels clients génèrent le plus de revenus — et ont aussi le plus grand volume de tickets support ? Autrement dit : quels clients à haute valeur sont en risque de churn ?
En quelques jours, on avait un pipeline qui récupérait les données des trois plateformes, les chargeait dans une base de données centrale, et alimentait un dashboard Power BI qui répondait à cette question — mis à jour automatiquement chaque nuit.
⚠️ Challenge
Les outils SaaS sont conçus pour gérer des workflows — pas pour exporter des données d'une façon facile à analyser entre plateformes. La plupart offrent quatre options pour extraire tes données, chacune avec ses vraies contraintes.
📄 Les quatre options
- Export manuel (CSV) — fonctionne une fois, ne scale pas, aucune automatisation possible
- Connecteur natif dans Power BI — facile quand il existe, périmètre limité, manque souvent les données dont tu as vraiment besoin
- ETL tiers (Fivetran, Airbyte) — puissant, fiable, mais ajoute un coût mensuel par connecteur
- Appel API direct — flexibilité maximale, fonctionne pour tout outil avec une API, nécessite une mise en place technique
🔍 Quand l'API l'emporte
- Pas de connecteur Power BI natif pour ton outil
- Le connecteur existe mais n'expose pas les données dont tu as besoin
- Tu veux un contrôle total sur ce qui est extrait et quand
- Tu construis de toute façon une couche de données centralisée
- Le coût d'un outil ETL n'est pas justifié pour le volume
Pour la plupart des PME, l'API est la bonne réponse quand le connecteur natif ne couvre pas le cas d'usage — ce qui arrive plus souvent qu'on ne le pense. Presque tout outil SaaS construit dans la dernière décennie dispose d'une API REST. Les données sont là. Il faut juste savoir comment les demander.
🔍 Comment fonctionne concrètement une API REST
Pas besoin d'être développeur pour comprendre le concept. Une API REST est essentiellement une URL qu'on appelle avec des paramètres spécifiques — et l'outil répond avec des données au format JSON.
Un exemple réel avec Shopify :
- On envoie une requête vers
https://ma-boutique.myshopify.com/admin/api/2024-01/orders.json - On inclut un token d'authentification dans l'en-tête de la requête (une clé API que la plateforme fournit)
- Shopify répond avec une liste JSON de commandes — info client, montants, dates, lignes de produits, statut
- On parse ce JSON, on le transforme en table structurée, et on le charge dans la base de données
C'est le cycle complet. La complexité technique est dans les détails — méthodes d'authentification (clé API, OAuth, Bearer token), pagination (la plupart des APIs retournent 100 enregistrements à la fois, donc on boucle sur les pages), rate limiting (les APIs plafonnent le nombre de requêtes par minute), et gestion des erreurs.
✓️ L'architecture qui fonctionne
Que tu utilises Python, Power Automate ou un outil ETL dédié, le pattern est toujours le même — et c'est la même architecture dont on a parlé dans les articles précédents :
- Extraire — appeler l'API selon un planning (chaque nuit, chaque heure, ou à la demande selon les besoins en fraîcheur des données)
- Transformer — nettoyer la réponse JSON : aplatir les objets imbriqués, renommer les champs, gérer les valeurs manquantes, standardiser les formats de date
- Charger — écrire les données propres dans une base centrale (Azure SQL, PostgreSQL, BigQuery, ou même SharePoint pour les cas plus légers)
- Connecter Power BI — pointer le dataset Power BI vers la base de données, pas vers l'API directement — ça garde le rapport rapide et les appels API gérables
Pour le client avec Shopify + HubSpot + Zendesk : la clé commune était l'adresse email du client. Chaque API l'exposait. On l'a utilisée comme clé de jointure dans la base de données pour lier commandes, contacts CRM et tickets support — créant la vue unifiée qu'aucun outil seul ne pouvait fournir.
💡 Synthèse
Si ton activité tourne sur des outils SaaS et que tu n'arrives pas à avoir une vue transversale de tes données, l'API est généralement le chemin le plus direct. Les étapes sont toujours les mêmes :
- Vérifier si l'outil a une API — presque toute plateforme SaaS moderne en a une. Cherche "API documentation" ou "developer docs" dans leur centre d'aide.
- Identifier la méthode d'authentification — clé API, OAuth 2.0, ou Bearer token. La doc le précise.
- Identifier les endpoints dont tu as besoin — commandes, contacts, tickets, transactions. Chacun a sa propre URL.
- Construire le pipeline — Python, Power Automate, ou un outil ETL. Extraire → transformer → charger dans une base centrale.
- Connecter Power BI à la base — pas à l'API. Laisse le pipeline faire le travail lourd selon un planning.
L'export CSV résout le problème du jour. L'API résout le problème pour les trois prochaines années. Et une fois les données dans une base centrale, chaque nouvelle question à laquelle tu veux répondre n'est qu'une nouvelle requête — pas un nouvel export manuel.
👉 Tes données ne manquent pas. Elles sont juste enfermées dans un outil qui n'a pas été conçu pour les partager.
L'API, c'est la clé.