Le problème

Au début d'un projet data, les mêmes questions reviennent : streaming ou batch ? Faut-il un entrepôt de données en plus du lac ? Spark, ou du serverless suffit-il ? Les réponses existent, mais elles sont dispersées entre la documentation des clouds, les retours d'expérience et l'intuition de l'architecte. Résultat : des choix difficiles à expliquer à une équipe ou à un décideur, et difficiles à remettre en question.

Data Architecturer formalise ce raisonnement. L'outil pose les questions qu'un architecte poserait, applique des règles explicites, et rend ces règles publiques.

Les contraintes

Explicable : chaque brique recommandée doit pouvoir être reliée à la réponse qui l'a déclenchée.
Multi-environnement : la même logique doit produire une architecture AWS, GCP, Azure, multi-cloud ou on-premise.
Sans friction : aucun compte, aucune donnée envoyée à un serveur, un résultat exportable en PDF.

L'architecture

Tout s'exécute dans le navigateur. Les douze réponses (type et volume de données, croissance, schéma de lecture, fréquence d'écriture, latence, cas d'usage, sécurité, taille d'équipe, cloud, budget, délai) alimentent un moteur de règles organisé par couche. Chaque couche produit des composants abstraits (« streaming », « entrepôt », « calcul distribué »), qui sont ensuite traduits en outils concrets selon l'environnement choisi.

flowchart LR
    Q["12 réponses
du questionnaire"] --> R{"Règles par couche"}
    R --> I["Ingestion
streaming / batch"]
    R --> S["Stockage
lac, entrepôt, NoSQL, recherche"]
    R --> P["Traitement
distribué / serverless, ML"]
    R --> E["Exposition
BI, API"]
    R --> T["Transverse
orchestration, sécurité, monitoring"]
    I & S & P & E & T --> M["Correspondance cloud
AWS · GCP · Azure · multi · on-prem"]
    M --> O["Architecture recommandée
+ estimation de coûts + export PDF"]

Exemple : la décision d'ingestion

Le streaming est activé dès qu'une condition l'exige : latence temps réel, lecture temps réel ou cas d'usage IoT. Le batch est activé pour les lectures batch et les cas ETL, et il sert de choix par défaut quand aucune condition streaming n'est remplie. Les deux peuvent coexister.

flowchart TB
    L{"Latence temps réel ?"} -->|oui| ST["Streaming
Kinesis · Pub/Sub · Event Hubs · Kafka"]
    R{"Lecture temps réel ?"} -->|oui| ST
    IOT{"Cas d'usage IoT ?"} -->|oui| ST
    B{"Lecture batch
ou cas ETL ?"} -->|oui| BA["Batch
Glue · Dataproc · Data Factory · Airflow"]
    N{"Aucune condition
streaming ?"} -->|oui| BA

Les sept arbres (ingestion, stockage, traitement, exposition, recommandations transverses, coûts, correspondance cloud) sont consultables et téléchargeables au format Mermaid sur la page Arbres de décision.

Quelques règles de conception

Le lac de données est toujours présent : c'est le socle commun. L'entrepôt, le NoSQL et le moteur de recherche s'y ajoutent selon le type de données, les schémas de lecture et les cas d'usage.
Serverless par défaut : le calcul distribué (Spark, Databricks) n'est recommandé qu'au-delà de 100 To ou pour une charge analytique OLAP.
Orchestration et monitoring systématiques ; le niveau de sécurité module le reste (chiffrement, masquage des données personnelles, contrôle d'accès).

Les choix écartés

Option	Pourquoi elle a été écartée
Un LLM qui génère l'architecture	Résultat non reproductible et impossible à justifier ligne à ligne. Des règles explicites donnent la même réponse aux mêmes questions et se relisent.
Un back-end pour calculer les recommandations	Inutile pour ce volume de règles. Tout en JavaScript côté client : aucune donnée ne quitte le navigateur et l'hébergement reste statique.
Des schémas dessinés à la main	Ils divergeraient du code. Les arbres sont écrits en Mermaid, versionnés avec le projet et téléchargeables.

Une question du diagnostic Data Architecturer : comment vos données sont-elles principalement lues ? Choix entre OLTP, OLAP, temps réel et batch — Une des douze questions : le schéma de lecture oriente le choix du moteur de requêtes.

Résultats et limites

L'outil est en ligne et utilisable sans inscription. Le PDF exporté peut servir de point de départ pour challenger une architecture existante avec une équipe.

Ses limites sont assumées :

Des règles volontairement simples : pas de pondération entre critères, et un seuil unique (100 To) pour basculer vers le calcul distribué.
Une estimation de coûts indicative : elle repose sur des ratios fixes (stockage autour de 23 $ par To, calcul 40 %, réseau 15 %, licences 20 % du budget), pas sur les grilles tarifaires réelles des fournisseurs.
Un catalogue d'outils à maintenir : l'écosystème data évolue vite, et la correspondance cloud doit suivre.
Pas de prise en compte de l'existant : l'outil propose une cible, pas un plan de migration.

Rôle et stack

Conception des règles, du questionnaire et des schémas, développement et mise en ligne : Jawed Tahir.

Stack : JavaScript (vanilla), Mermaid.js, html2pdf.js, hébergement statique.