Construire une plateforme data avec Snowflake : les choix d’architecture qui comptent

Avant de rejoindre aiko, Antoine Douez a participé à la conception et à la mise en production de la nouvelle plateforme data de Clinitex. Du choix de Snowflake à l’organisation des modèles dbt, de l’ingestion à la supervision, ce parcours lui a permis d’éprouver une architecture complète sur des besoins métier concrets, notamment le pilotage de la rentabilité des chantiers.

Ce travail a aussi donné du recul sur les décisions qui facilitent la suite : centraliser les transformations, rendre les données réutilisables et installer tôt les environnements de développement. Les résultats tiennent à la façon dont toute la chaîne a été repensée, avec Snowflake, Airbyte, dbt et Prefect.

Pour un DSI, un CTO ou un responsable Data, cinq questions permettent de structurer ces arbitrages. Elles vont du premier usage à valider jusqu’aux conditions d’exploitation et d’évolution de la plateforme. L’enjeu est de comprendre ce que chaque choix apporte, ce qu’il demande à l’équipe et à quel moment le prendre.

1. Quel problème Snowflake doit-il résoudre dans votre SI ?

La multiplication des applications crée de nouveaux besoins de rapprochement entre les données. Un indicateur de rentabilité peut, par exemple, mobiliser la paie, les achats et la facturation. Chaque application détient une partie de l’information ; le calcul demande de les réunir et de s’accorder sur les règles à appliquer. C’est ce besoin transverse qui donne une direction au projet de plateforme.

Dans le projet porté par Antoine, la croissance des sources SaaS et des échanges entre applications appelait une nouvelle organisation des flux. Snowflake a été retenu pour la simplicité constatée lors du POC, la facilité de migration et les perspectives d’usages IA. La capacité à mettre rapidement en œuvre une première chaîne a compté dans la décision.

Un POC utile doit permettre de juger ce fonctionnement sur des données représentatives : peut-on les ingérer, appliquer les transformations attendues et livrer un résultat que le métier reconnaît comme exploitable ? Il permet aussi d’évaluer le travail demandé à l’équipe, les compétences à développer et les contraintes des sources. Ce sont des éléments de décision plus solides qu’une comparaison abstraite de fonctionnalités.

Le choix doit rester lié aux usages analytiques visés, aux fréquences de mise à jour et aux capacités d’exploitation. Antoine invite notamment à examiner d’autres options pour les usages transactionnels ou les petits volumes nécessitant des mises à jour très fréquentes. Il souligne aussi l’importance de former l’équipe à la modern data stack et d’impliquer les métiers dès le départ. Notre retour du Snowflake World Tour Paris 2026 (nouvelle fenêtre) prolonge cette réflexion sur la place d’une data platform dans le système d’information des PME et ETI.

2. Que charger dans Snowflake, et à quel rythme ?

Le choix de la plateforme ne règle pas celui de l’ingestion. Il reste à déterminer quelles sources alimenteront les usages prioritaires, ce qu’elles permettent d’extraire et la fréquence nécessaire. Cette décision pèse directement sur la durée des traitements et sur la disponibilité des données pour les consommateurs.

L’architecture mise en place s’appuie sur Airbyte pour charger les données brutes, avec des scripts Python pour certaines applications anciennes. Snowflake accueille ces données et les traitements analytiques. dbt assure les transformations ; Metabase consomme les modèles préparés. Prefect coordonne les exécutions des scripts, des jobs d’ingestion et des traitements dbt. Chacune de ces briques intervient sur une responsabilité précise de la chaîne.

L’un des arbitrages déterminants a été de faire évoluer les copies intégrales vers des chargements incrémentaux. Selon les possibilités des sources, le suivi reposait sur des timestamps ou sur la capture des changements, le CDC. La chaîne pouvait ainsi prendre en compte les évolutions depuis les synchronisations précédentes, au lieu de recopier systématiquement toutes les tables.

Sur un périmètre comparable, le traitement nocturne est passé de dix heures à moins de quinze minutes. Ce résultat vient de la modernisation de l’ensemble de la chaîne, notamment de cette évolution de l’ingestion. Il montre combien la stratégie de chargement compte dans la performance obtenue avec une plateforme data Snowflake.

L’incrémental doit toutefois être pensé avec les contraintes réelles des applications. Les données anciennes, les identifiants disponibles et les mécanismes d’extraction conditionnent la mise en œuvre. Le rôle du data engineering consiste aussi à composer avec cet existant pour obtenir des flux exploitables, en choisissant les moyens adaptés à chaque source.

3. Où construire les règles métier pour les réutiliser ?

Une fois les données chargées, il faut décider où vivront les règles de calcul. Si chaque nouvel indicateur repart des sources et reconstruit ses transformations, une partie du travail sera répétée à chaque demande. Centraliser les modèles donne aux usages suivants une base commune sur laquelle s’appuyer.

La rentabilité par chantier a été un cas important dans le parcours d’Antoine. Son calcul rapprochait salaires, consommables, achats et facturation. Le reconstruire a demandé de revenir aux définitions avec les métiers : comprendre les traitements existants, retrouver le sens des calculs et traduire ces règles dans les nouveaux modèles. Cette étape de compréhension fait pleinement partie du travail d’architecture.

Avec dbt, la logique a été découpée en modèles documentés et testés, notamment sur l’unicité et les valeurs attendues. Les transformations devenaient plus lisibles et leur résultat pouvait servir à d’autres besoins. L’outil permet de structurer ce travail ; la pertinence du modèle repose aussi sur la compréhension de l’indicateur et la qualité des échanges avec les métiers.

L’organisation en couches soutient cette réutilisation. Le bronze conserve les données brutes. Le silver prépare des données qualifiées et communes, notamment des dimensions. Le gold organise les modèles consommés par les domaines métiers. Les règles partagées trouvent ainsi leur place en amont des restitutions, et plusieurs usages peuvent capitaliser sur les mêmes données préparées.

Le premier passage demande de l’effort : comprendre, découper, documenter et tester. La réutilisation a ensuite facilité le développement de nouveaux projets. C’est un point central du retour d’Antoine : le coût initial de préparation doit aussi être apprécié au regard de ce qu’il évite de refaire.

La qualité dépend enfin des données d’origine. Certaines applications nécessitaient un travail de qualification et de création de référentiels. La responsabilité métier reste essentielle pour définir les informations de référence et les règles attendues. Un modèle technique bien organisé a besoin de définitions métier tout aussi solides.

4. Que faut-il prévoir avant la mise en production ?

Des flux que l’équipe peut suivre et faire évoluer

La supervision doit trouver une place dans le fonctionnement quotidien. Avec Prefect, un tableau de bord de l’état des flux était partagé chaque matin sur le plateau. L’équipe disposait ainsi d’une vue commune sur les batchs de la nuit. L’intérêt concret de l’orchestration tient aussi à cette capacité à comprendre comment la chaîne s’est exécutée.

Les reprises sur erreur et les contrôles de qualité méritent la même attention. Avec le recul, Antoine y aurait consacré davantage de temps dès la conception. Savoir qu’une exécution est terminée et savoir que les données produites sont exploitables demandent des contrôles complémentaires.

La séparation des environnements est un autre enseignement net. La séparation dev/prod reposait sur des environnements gérés via dbt au sein d’un même compte Snowflake. Un environnement de développement a également été appliqué aux jobs dbt, Prefect et Airbyte. Cette organisation a permis de développer plus sereinement. Antoine l’installerait dès le début d’un nouveau projet, pour disposer plus tôt d’un cadre où préparer les évolutions.

Pour une nouvelle plateforme, prévoir tôt le versioning et les pratiques de CI/CD permet de mieux organiser les changements. Ces pratiques doivent être proportionnées aux besoins de l’équipe et soutenir les développements successifs. La plateforme doit pouvoir continuer à évoluer lorsque ses premiers usages deviennent indispensables aux métiers.

Des accès et des consommations compréhensibles

L’ordre recommandé par Antoine est explicite : définir les rôles, puis les warehouses, puis les garde-fous. Partir des utilisateurs et de leurs besoins aide à organiser les accès aux données et les ressources de calcul qui serviront les traitements.

Le compute demande aussi un apprentissage lorsqu’on vient d’une infrastructure sur site. Dans le projet, l’équipe suivait mensuellement les consommations dans Snowflake et utilisait des resource monitors pour encadrer les warehouses concernés. Ces mécanismes ont un périmètre précis : ils ne contrôlent pas toutes les dépenses, notamment celles des fonctionnalités serverless.

La formation aux pratiques d’économie a accompagné ce pilotage. L’exploitation demande de comprendre ce qui consomme et comment les réglages influencent le fonctionnement. Il faut également intégrer les autres briques dans l’arbitrage : Airbyte et Prefect étaient hébergés en interne, avec les moyens techniques et humains que cela mobilise.

5. Comment ouvrir le socle à de nouveaux usages ?

La réutilisation des modèles prépare plusieurs façons de consommer les données : reporting, applications métier et futurs usages IA. Le travail réalisé sur un premier indicateur peut alors profiter aux projets suivants. Cette capacité à capitaliser donne une autre dimension au choix de l’architecture : la valeur du socle grandit avec les usages qu’il permet d’ajouter.

Les définitions métier et les accès restent déterminants dans cette évolution. Une interface conversationnelle a besoin de données dont le sens est maîtrisé et dont les conditions de consultation sont claires. Notre analyse de ce que Snowflake et Claude changent dans l’accès aux données (nouvelle fenêtre) approfondit ces questions de consultation et de responsabilité autour des indicateurs.

Les perspectives IA ont compté dans le choix initial de Snowflake. Leur concrétisation doit ensuite partir de cas d’usage précis, avec une évaluation de l’utilité et de la fiabilité des résultats. Les modèles partagés, la qualité et la gouvernance constituent les fondations sur lesquelles mener ce travail.

Construire un premier usage solide, puis élargir la plateforme

Le retour d’Antoine met en évidence deux bénéfices complémentaires : une chaîne de traitement plus rapide et des modèles de données sur lesquels les projets suivants peuvent s’appuyer. Le premier vient notamment d’une ingestion mieux adaptée aux sources. Le second repose sur la compréhension des règles métier, leur documentation et leur réutilisation. La valeur de la plateforme se mesure aussi à cette capacité à éviter de refaire le même travail.

Pour engager un projet, le point de départ est donc un usage métier précis, que l’on peut éprouver rapidement avec un POC. Antoine insiste sur la liberté d’action et la confiance de la direction qui ont permis d’avancer, puis d’apprendre en construisant. Ce retour invite à associer cette dynamique à quelques fondations prévues tôt : les rôles, les environnements, la qualité et la supervision. Elles permettent de faire évoluer la plateforme plus sereinement à mesure que les besoins se développent.

C’est dans cette perspective qu’aiko accompagne les entreprises pour concevoir et industrialiser une plateforme data (nouvelle fenêtre) : relier les premiers usages aux choix techniques, construire un socle exploitable et préparer son évolution vers de nouveaux projets Data & IA.