Un canevas visuel
Lire, filtrer, joindre, agréger, pivoter, écrire : chaque bloc porte ses paramètres, et le graphe se valide avant d’être exécuté.
← Vue d’ensemble
Pipelines low-code
Dessinez le pipeline. Le code vous appartient.
Vous assemblez les étapes sur un canevas ; graal écrit le code Pandas ou PySpark correspondant. Ce code est lisible, versionné et exécutable hors de graal : sur un poste, dans votre intégration continue, sur un autre cluster.
Un pipeline valide, exporté en PySpark depuis l’éditeur. Le même menu propose Pandas ; le bouton voisin en fait un job.
Interface réelle de la console graal, non retouchée ; données de démonstration fictives (locataire energie-demo — personnes, projets et jetons inventés).
Capacités clés
Du dessin au code, sans perte
L’aperçu à chaque étape
Un clic sur un bloc exécute le pipeline jusqu’à lui sur un échantillon et affiche les lignes produites.
Un export exécutable
Pandas pour les volumes modestes, PySpark pour passer à l’échelle. Le code se relit, se teste et tourne sans graal.
Des contrôles qualité intégrés
Non-nullité, unicité, plages de valeurs, expressions régulières, fraîcheur : un contrôle en échec arrête le run ou l’avertit, selon votre règle.
Le pipeline décrit en langage naturel
Vous décrivez le traitement en une phrase ; graal propose le graphe, que vous relisez et ajustez avant de l’enregistrer.
Des versions et Git
Chaque enregistrement crée une version du graphe, commitée dans le dépôt Git du projet. Vous comparez, vous revenez en arrière.
Comment ça marche
Du canevas au job planifié
Étape 01
Dessiner
Vous posez les blocs, vous les reliez et vous vérifiez l’aperçu des données à chaque étape.
Étape 02
Contrôler
Vous ajoutez des contrôles qualité là où la donnée doit tenir ses promesses. Leur rapport accompagne chaque run.
Étape 03
Industrialiser
Le graphe devient un job planifiable, enchaînable dans un workflow. Ou vous exportez le code et le déployez ailleurs.
Le graphe est la source, le code en est la traduction
Un pipeline graal est un graphe orienté : chaque bloc déclare ses entrées, ses paramètres et son schéma de sortie. Le moteur valide ce graphe, puis le traduit en un script Pandas ou PySpark complet, avec ses dépendances. Il n’y a pas d’exécution cachée : ce qui tourne dans graal est ce que vous exportez.
Un pipeline se relit comme du code
Parce que le code produit est lisible, il entre dans vos pratiques existantes : revue de code, tests unitaires, intégration continue. Vos data engineers gardent la main sur ce qui part en production, et vos analystes construisent sans attendre.
Le règlement européen sur les données (Data Act) interdit, à partir du 12 janvier 2027, les frais de changement de fournisseur de services de traitement de données (article 29). Un code exporté et des formats ouverts rendent ce changement concret.
Standards et intégrations
Des formats que vous gardez
- Pandas
- PySpark
- Python
- Parquet
- Apache Iceberg
- SQL
- Git
Gouvernance
Réversible par construction
- Le code exporté vous appartient et s’exécute sans licence graal
- Aucun identifiant dans le code produit, seulement des références à des secrets
- Droits distincts pour éditer, exporter et lancer un pipeline, projet par projet
Questions fréquentes
Que reste-t-il si nous quittons graal ?
Le code Pandas ou PySpark de vos pipelines, leur historique Git, et vos données en Parquet et en Iceberg. Rien n’est à reconvertir.
Faut-il savoir coder ?
Non pour dessiner. Le code produit est pensé pour être relu par vos data engineers : c’est lui qui fait foi.
Pandas ou PySpark ?
Le même graphe s’exporte dans les deux. Pandas convient à un volume qui tient en mémoire ; PySpark distribue le calcul sur votre cluster.
Voir un pipeline devenir un job
Du dessin à l’export du code, puis au job planifié : c’est l’un des actes de la démonstration.