GazFlow : simuler un réseau de gaz en Rust, sur une carte 3D, avec l’IA dans la boucle

Peut-on simuler l'écoulement du gaz dans un réseau de pipelines, le visualiser sur une carte 3D dans le navigateur, et construire l'outil avec des technologies récentes plutôt qu'avec la stack historique du secteur ? C'est la question qui nous a menés à GazFlow, un simulateur hydraulique de réseaux de gaz naturel publié en open source sur GitHub. Pas pour remplacer un SCADA certifié, mais pour explorer ce qu'on peut faire aujourd'hui avec Rust, le web géospatial et l'IA comme copilote dans un contexte scientifique exigeant.

Comment ça a commencé

Le déclencheur n'est pas venu d'un appel d'offres ni d'un cahier des charges. C'est une conversation informelle : le père d'un collègue a travaillé chez Natran, opérateur du réseau de transport de gaz à haute pression en France. Il nous a parlé de SIMONE (Simulation Of Gas Networks), le logiciel de référence du métier, et de la complexité de ces simulations hydrauliques : régimes permanents et transitoires, équipements de régulation, études de sécurité, calage sur mesures terrain.

Nous ne connaissions pas grand-chose au secteur. Mais la curiosité est passée : et si on plongeait dedans pour voir ? Comprendre comment un exploitant raisonne sur son réseau, quelles équations sont en jeu, ce qu'un outil comme SIMONE couvre vraiment, et ce qu'on pourrait explorer avec une stack plus récente (Rust, visualisation web, tests automatisés).

Ça nous a pris du temps. Beaucoup de lectures croisées (Osiadacz, GasLib, ISO, GERG), et une sacrée consommation d'Opus 4 rien que pour comprendre les enjeux : vocabulaire du transport de gaz, modèles hydrauliques, contraintes opérationnelles, limites des approximations. Avant même d'écrire une ligne de solveur sérieuse, il a fallu absorber un domaine où chaque simplification a un sens métier.

Le chantier au labo Improba dure depuis environ six mois, immersion comprise. Le dépôt public trace surtout l'implémentation à partir de mars 2026 ; le code avance par petites touches quand le labo retrouve des créneaux.

GazFlow n'est pas un simulateur d'exploitation certifié. C'est un banc d'essai pour comparer des scénarios, visualiser des résultats, et apprendre en construisant.

Ce que fait GazFlow

GazFlow calcule des points de fonctionnement hydrauliques en régime permanent sur des réseaux de transport et de distribution : pressions nodales, débits volumiques normalisés (Nm³/s), avec prise en compte de la composition du gaz, de la gravité, des régulateurs de pression et des vannes de contrôle. Les résultats s'affichent sur une carte 3D CesiumJS, avec un dégradé de couleurs (pression, débit) mis à jour en direct pendant le calcul via WebSocket.

Au-delà du scénario GasLib de base, l'outil couvre aujourd'hui une chaîne opérationnelle plus large :

• Import réseau : GeoJSON, CSV avec mapping YAML, Shapefile (adaptation aux conventions SIG locales).
• Profils de demande : courbes horaires thermosensibles (résidentiel, tertiaire, industriel), météo CSV, séries 24 h.
• Analyse N-1 : contingences parallèles, surcouche cartographique, export Excel/CSV.
• Calibration SCADA : optimisation Levenberg-Marquardt sur rugosité et facteurs de demande (jusqu'à 5 paramètres).
• Édition topologique : variantes de réseau, comparaison ΔP/ΔQ entre scénarios, undo/redo.
• Mode transitoire (partiel) : quasi-stationnaire ou PDE 1D sur conduites en série (linepack).
• Contraintes de capacité : bornes min/max de débit par nœud, modes vérifier ou optimiser (projection itérative sur les demandes).

Les exports couvrent JSON, CSV, XLSX et ZIP. Une page d'historique centralise les résultats. Le tout tourne dans Docker : pas besoin d'installer Rust ou Node sur la machine hôte pour démarrer.

Stack et architecture

Le backend est en Rust (Axum, Tokio, petgraph, solveur sparse faer, parallélisme Rayon). Le solveur hydraulique repose sur Newton-Raphson avec recherche linéaire, warm-start et repli Jacobi. La friction suit Darcy-Weisbach (Swamee-Jain), l'équation d'état Papay Z(P,T), avec bascule automatique vers Peng-Robinson 78 quand la part d'hydrogène dépasse 20 %. Au-delà d'environ 2 000 nœuds, un fallback GMRES + ILU0 complète la factorisation sparse directe.

Le frontend combine Vue 3, Quasar et CesiumJS pour le globe 3D. Le thème visuel est volontairement proche d'un SCADA industriel sombre : lisible, fonctionnel, pas décoratif. Pendant une simulation, le navigateur reçoit la progression et les pressions intermédiaires en streaming ; la carte se colore sans recharger la page.

La boucle complète ressemble à ceci : le client envoie un scénario (demandes, composition, bornes de capacité) → le backend lance le solveur dans un thread dédié (spawn_blocking) → les itérations Newton remontent par WebSocket → Cesium met à jour les entités réseau → l'utilisateur exporte ou compare des variantes.

SIMONE, GasLib, et ce qu'on ne prétend pas remplacer

SIMONE reste la référence du métier pour les études hydrauliques sur grands réseaux de transport. GazFlow s'en inspire explicitement (README : « inspired by SIMONE »), sans prétendre à l'équivalence fonctionnelle ni à la certification opérationnelle. Notre périmètre cible : des études comparatives (scénarios, variantes topologiques, analyse N-1, calibration sur mesures), pas la conduite en temps réel d'un réseau.

Pour la validation numérique, nous nous appuyons sur GasLib (ZIB Berlin), la bibliothèque académique de réseaux de référence. GasLib-11 sert de cas de test principal : le dépôt vérifie une erreur relative de pression inférieure à 5 % contre une référence interne versionnée (pas encore une comparaison systématique aux fichiers .sol officiels GasLib). GasLib-582 et GasLib-4197 passent en smoke test, avec convergence non garantie sur les cas les plus massifs. Les comparaisons de débits contre des références externes restent, elles aussi, un chantier ouvert.

Les limites du modèle sont documentées dans le dépôt (limitations.md) : transitoire PDE partiel (~55 %), compresseurs simplifiés, vannes en diamètre effectif plutôt qu'en modèle ISA complet, hypothèse isotherme, pas de GERG-2008. Ce ne sont pas des bugs cachés ; ce sont des compromis assumés pour un MVP opérationnel.

Prototyper avec l'IA dans un contexte expert

GazFlow est aussi une expérience de développement assisté par IA au labo Improba. Nous avons appris deux choses très différentes sur la façon de s'en servir.

Là où l'IA a été utile

En phase d'exploration, les modèles « frontier » (Opus 4 en tête) ont excellemment joué le rôle de tuteur accéléré : expliquer les enjeux techniques, traduire le jargon du secteur, relier un papier à une équation, proposer des lectures croisées. Quand on part de zéro sur le transport de gaz, cette capacité à structurer un domaine inconnu est précieuse. Elle ne remplace pas la validation, mais elle compresse des semaines de cartographie.

Là où l'IA a été catastrophique

Dès qu'on a lancé des instructions vagues et non cadrées sur un gros modèle (« implémente le solveur », « fais comme SIMONE »), la facture a explosé et les résultats étaient souvent décalés : code plausible, parfois élégant, mais physiquement ou architecturalement à côté. Sans sources de vérité écrites, sans tests, sans périmètre explicite, un modèle frontier part en exploration coûteuse et revient avec des propositions difficiles à intégrer.

Notre leçon : mieux vaut dialoguer d'abord (comprendre, reformuler, trancher), puis utiliser les gros modèles pour préparer des plans d'implémentation maîtrisés. Une fois la compréhension installée. C'est exactement l'esprit du fichier AGENTS.md dans le dépôt : sources de vérité (équations, plans, corpus de tests), conventions de code, protocole de contribution par lots testables.

Comme sur d'autres chantiers du labo (FLEXPART-GPU, modèle atmosphérique GPU), l'IA accélère l'implémentation une fois le cadre posé ; l'humain tranche sur la physique, les tests et ce qui ferme une porte. Concrètement, cela a permis d'enchaîner les phases du plan opérationnel (P6 à P13) : import réseau, profils horaires, N-1, calibration, édition topologique, amorce transitoire. Chaque lot s'accompagne de tests versionnés dans un corpus (docs/testing/corpus/) et de scripts CI reproductibles (./scripts/ci.sh). Ce n'est pas du « vibe coding » : un test qui échoue bloque la suite, et les équations sont écrites noir sur blanc dans docs/science/equations.md.

L'IA explique vite un secteur qu'on ne connaît pas. Elle code mal quand on ne sait pas encore ce qu'on veut. Le dialogue d'abord, le plan ensuite.

Ce qui manque encore

GazFlow progresse quand nous trouvons du temps pour le consacrer. Mais deux manques se font sentir clairement.

Des données réelles. Nous disposons de réseaux GasLib, de jeux synthétiques et de fixtures de test. Il nous manque des jeux de données opérationnels anonymisés : topologies SIG réelles, mesures SCADA, profils de prélèvement terrain, cas N-1 documentés. Sans cela, la calibration et la validation restent des démonstrations techniques, pas des preuves métier.

Un regard de terrain. La conversation avec le père de notre collègue nous a ouvert une porte, mais personne chez Improba n'a passé des années dans un poste d'exploitation gaz (transport, distribution, nomination, contrats d'accès). Ce regard manque pour prioriser les bonnes simplifications, interpréter un écart de 3 % sur un nœud frontière, ou savoir quels cas limites comptent vraiment pour un opérateur type Natran, GRTgaz ou GRDF.

Si vous travaillez dans le secteur et que ce sujet vous parle (données de test, relecture métier, retours sur les limites du modèle), nous serions heureux d'échanger. Le dépôt est ouvert, la licence est MIT, et les issues GitHub sont là pour ça.

Open source et état d'avancement

Le projet est publié sous licence MIT sur github.com/Improba/gazflow. Le quickstart tient en deux commandes : télécharger un réseau GasLib, lancer ./scripts/dev.sh. Backend sur le port 3001, frontend sur le port 9000.

L'état actuel (juin 2026) : MVP solide et phases opérationnelles P6 à P13 largement avancées (P11 transitoire ~55 % d'après le plan de complétion). Le transitoire PDE sur réseaux ramifiés reste le principal chantier ouvert (estimé 6 à 10 semaines dans ce même plan). GazFlow n'est pas « fini » ; c'est un outil vivant, amélioré par petites touches quand le labo retrouve des créneaux.

Ce que nous en retenons

• GazFlow montre qu'on peut construire un simulateur hydraulique de réseaux de gaz moderne (Rust + web 3D) en s'inspirant de SIMONE sans prétendre le remplacer.
• La visualisation Cesium et le streaming WebSocket rendent les résultats immédiatement lisibles ; c'est un atout pédagogique autant que technique.
• L'IA comme copilote accélère l'exploration d'un domaine inconnu et l'implémentation cadrée ; elle coûte cher et dérape si les instructions restent vagues.
• Les limites sont documentées : transitoire partiel, modèles simplifiés sur compresseurs et vannes, validation débits incomplète.
• Le prochain palier passe par des données réelles et un regard métier du secteur gaz : c'est là que le projet a le plus à gagner.

Si votre contexte ressemble (études hydrauliques, réseaux SIG, scénarios de sécurité N-1), le dépôt est là pour être exploré, critiqué et enrichi. Nous construisons GazFlow pour apprendre et pour proposer une brique open source au secteur. Pas pour vendre une promesse.