Le sur-engineering data est l'un des pièges les plus chers du monde tech moderne. Une PME marocaine qui traite quelques gigaoctets de données par jour n'a pas besoin de Spark, et pourtant on voit régulièrement des stacks complètes Databricks ou Spark on Kubernetes déployées pour des cas d'usage qu'un script Python sur Azure Functions, AWS Lambda ou Cloud Run réglerait en 1 % du coût. Ce guide aide à faire le bon arbitrage entre les deux approches en 2026, en partant des volumes réels que rencontrent les équipes marocaines.
La règle simple : 100 Go par jour
Posons la règle d'arbitrage la plus utile en pratique. Au-dessus de 100 Go de données traitées par jour de manière distribuée, Apache Spark commence à devenir le bon outil. En dessous, les serverless functions (Azure Functions, AWS Lambda, Google Cloud Run) couvrent la quasi-totalité des besoins, à un coût et une simplicité radicalement supérieurs.
C'est une règle indicative — il existe des exceptions — mais pour 80 % des PME marocaines, vous êtes dans la zone "small data" qui ne justifie pas Spark. Voici pourquoi, et comment construire une stack data adaptée à votre vraie volumétrie.
Pourquoi Spark a été conçu pour des problèmes que vous n'avez pas
Apache Spark a été créé en 2009 à Berkeley pour résoudre un problème spécifique : traiter des téraoctets de données en mémoire répartie sur des dizaines ou centaines de nœuds. C'était l'évolution naturelle de Hadoop MapReduce, plus rapide grâce à l'in-memory processing et à un graphe d'exécution optimisé.
Le problème : la majorité des entreprises qui adoptent Spark ne traitent jamais des téraoctets en pratique. Elles traitent des fichiers de 5 à 50 Go quelques fois par jour, et passent leur temps à gérer la complexité opérationnelle de Spark — clusters Databricks ou EMR à provisionner, jobs qui crashent pour cause de skew de partition, dépendances de bibliothèques difficiles à figer, coûts de cluster largement supérieurs au volume de données réellement traitées.
Pour une PME marocaine typique avec 1 à 10 millions de transactions par mois, voici les volumes que vous croisez vraiment :
- Logs applicatifs : 1 à 10 Go par jour
- Événements e-commerce / transactionnels : 100 Mo à 5 Go par jour
- Données CRM / marketing : 10 Mo à 1 Go par jour
- Exports comptables / financiers : 1 à 50 Mo par jour
- Données de logs réseau / sécurité : 5 à 50 Go par jour
À ces volumes, Spark est l'équivalent d'utiliser un camion 40 tonnes pour livrer une pizza. Vous payez pour de l'infrastructure que vous n'utilisez pas, vous gérez de la complexité que vous n'avez pas besoin de gérer, et vous perdez en agilité de développement.
Quand utiliser des serverless functions
Azure Functions, AWS Lambda, et Google Cloud Run couvrent à eux trois 90 % des cas d'usage data des PME. Le pattern le plus courant : un trigger (fichier déposé sur Blob Storage / S3, événement HTTP, message Queue) déclenche une fonction qui traite les données, écrit le résultat dans une base ou un fichier, et meurt. Pas de cluster à maintenir, pas d'orchestrateur compliqué, paiement à la milliseconde de calcul.
Cas typique 1 : ETL e-commerce nocturne.
Chaque nuit à 2h du matin, votre boutique exporte les commandes de la journée vers un fichier CSV. Une Azure Function s'exécute, lit le fichier, fait le mapping vers votre data warehouse, met à jour le dashboard. Volume : 50 000 lignes, 20 Mo. Coût : moins de 0,01 USD par run.
Cas typique 2 : enrichissement d'événements en temps réel.
Vos événements Stripe arrivent sur un webhook. Une Azure Function les enrichit (calcul de marge, attribution marketing, anti-fraude basique) et les pousse vers votre data lake. Volume : 1 000 événements par heure. Coût : moins de 5 USD par mois.
Cas typique 3 : génération de rapports hebdomadaires.
Tous les lundis matins, une fonction extrait les données de la semaine, calcule les KPI, génère un PDF, l'envoie par email à l'équipe. Volume : 500 Mo extraits, 200 KPI calculés. Coût : 0,03 USD par run.
Pour un projet typique, l'ensemble de la stack data mensuelle d'une PME marocaine en serverless coûte 50 à 300 USD par mois. Le même besoin sur Databricks Spark coûterait 1 500 à 5 000 USD par mois.
Quand Spark devient le bon outil
Trois scénarios légitiment l'investissement dans Spark.
Scénario 1 : Traitement par lots de jeux de données très volumineux.
Si votre activité génère plus de 100 Go de données par jour à traiter — typiquement, une plateforme de logs réseau, un site d'audience massive (millions de visiteurs uniques par jour), ou un opérateur télécom — Spark est l'outil pertinent. La parallélisation distribuée devient nécessaire pour respecter des SLAs de batch overnight.
Scénario 2 : Pipelines de machine learning lourds.
Si vous entraînez des modèles ML sur de gros datasets ou faites du feature engineering sur plusieurs millions de lignes, Spark MLlib ou Spark + PyTorch sur Databricks reste le standard. Pour des modèles plus simples (classification, régression sur < 1M de lignes), pandas + scikit-learn dans une Azure Function suffit largement.
Scénario 3 : Compliance audit et data lineage.
Certaines régulations sectorielles (santé, finance, télécoms) imposent un audit trail complet des transformations data. Spark sur Databricks fournit cet audit trail nativement via Unity Catalog. Sur des serverless, il faut le construire à la main — possible, mais complexe.
Tableau de comparaison
| Critère | Serverless Functions | Apache Spark | |---|---|---| | Volume idéal/jour | Moins de 100 Go | Plus de 100 Go | | Coût mensuel typique PME | 50 à 300 USD | 1 500 à 10 000 USD | | Complexité opérationnelle | Faible | Élevée | | Temps mise en production | 1 à 2 semaines | 4 à 12 semaines | | Compétences requises | Python ou Node.js | Spark + Scala/Python + Kubernetes | | Latence démarrage | 100 ms à 5 s (cold start) | 30 s à 5 min (cluster startup) | | Adapté streaming temps réel | Limité (Event Hubs / Kinesis) | Oui (Spark Structured Streaming) | | Intégration ML lourde | Limité | Excellent (MLlib) |
Architecture recommandée pour une PME marocaine
Pour 80 % des PME marocaines, la stack data idéale en 2026 ressemble à ceci.
Stockage : Azure Blob Storage ou AWS S3 comme data lake (50 à 500 USD par mois selon le volume). PostgreSQL managé (Azure Database for PostgreSQL, AWS RDS) pour les transactions et les vues métier. BigQuery, Snowflake, ou ClickHouse pour les requêtes analytiques (à partir de 100 USD par mois sur les petits volumes).
Ingestion : Azure Functions ou AWS Lambda pour les triggers. Logic Apps ou Step Functions pour les orchestrations multi-étapes. Azure Data Factory ou AWS Glue pour les pipelines ETL plus complexes (50 à 200 USD par mois).
Transformation : dbt (data build tool) pour modéliser vos transformations en SQL versionné. C'est devenu le standard 2025-2026 pour les PME, plus simple que Spark et plus puissant que des scripts Python ad-hoc.
Visualisation : Metabase (self-hosted, gratuit), Looker Studio (gratuit pour les usages basiques), ou Superset (self-hosted) selon votre maturité.
Cette stack couvre l'essentiel des besoins data d'une PME marocaine pour 200 à 800 USD par mois, et ne demande pas de compétence Spark ou Kubernetes. Si votre équipe veut moderniser sa stack data sans tomber dans le sur-engineering, notre audit digital inclut souvent ce type de cadrage. Notre équipe développement sur mesure implémente régulièrement ces architectures pour des PME marocaines, en évitant les pièges classiques.
Quand le crossover devient inévitable
Une PME qui croît finit parfois par dépasser le seuil des 100 Go par jour. Voici les signaux qui indiquent qu'il est temps d'envisager Spark.
- Vos Azure Functions atteignent régulièrement le timeout de 10 minutes.
- Vous payez plus de 2 000 USD par mois sur des serverless qui tournent en quasi-permanence.
- Votre data warehouse (BigQuery, Snowflake) facture plus de 3 000 USD par mois en compute scan.
- Vos data scientists se plaignent de ne pas pouvoir charger les datasets en mémoire pour itérer.
Quand 2 ou 3 de ces signaux apparaissent simultanément, c'est le moment de prototyper Databricks ou Spark on Kubernetes. Pas avant.
Ressources associées
Vous hésitez entre plusieurs prestataires ? Consultez notre comparatif :
FAQ
Quelle est la différence entre Azure Functions et Azure Databricks ?
Azure Functions est un environnement serverless pour exécuter du code court (jusqu'à 10 minutes) en réponse à un événement. Azure Databricks est une plateforme Spark managée pour traiter de gros volumes de données en distribué. Les deux ne couvrent pas les mêmes besoins : Functions pour le small/medium data, Databricks pour le big data.
Peut-on faire du machine learning dans Azure Functions ?
Oui, pour des modèles déjà entraînés et de l'inférence. Pour entraîner des modèles, c'est plus contraignant — vous êtes limité par la mémoire (jusqu'à 14 Go sur les plans Premium) et la durée d'exécution. Pour entraîner sur des datasets >100 Mo, préférez Azure ML, AWS SageMaker, ou Databricks.
Combien coûte Apache Spark on Kubernetes versus Databricks ?
Spark on Kubernetes est souvent 30 à 50 % moins cher que Databricks à puissance de calcul équivalente, mais demande beaucoup plus d'expertise opérationnelle. Pour une PME marocaine, Databricks reste plus rentable une fois additionné le coût de la maintenance opérationnelle.
dbt remplace-t-il Spark pour la transformation de données ?
Pour la majorité des transformations analytiques (jointures, agrégations, modélisation dimensionnelle), oui. dbt s'exécute directement dans votre data warehouse (BigQuery, Snowflake, Redshift, ClickHouse) et n'a pas besoin de Spark. Spark reste pertinent pour des transformations très lourdes ou du machine learning distribué.
Le serverless est-il fiable pour des pipelines de production critiques ?
Oui, à condition de soigner trois choses : idempotence (votre fonction peut être réexécutée sans dommage), monitoring (logs centralisés, alerting sur erreurs), et gestion des dead-letter queues (ce qui se passe quand une fonction échoue 3 fois). Avec ces garde-fous, Azure Functions et AWS Lambda offrent une fiabilité de 99,95 % SLA — supérieure à beaucoup de stacks Spark mal opérées.