Backend d'un banc d'étalonnage de débitmètres gaz

Contexte

Un banc d’essai NaTran R&I sert à l’étude, la qualification et l’étalonnage de compteurs de gaz naturel industriels. Ce backend remplace le logiciel d’exploitation existant du banc, en réimplémentant l’ensemble de la chaîne de traitement métrologique : de l’acquisition des mesures jusqu’au calcul des débits étalon et compteur d’un point d’essai.

Le périmètre couvre trois volets : l’étalonnage de compteurs de gaz naturel (campagnes d’essai, dépouillement, certificats d’étalonnage de tuyères), les calculs thermophysiques et de débits (propriétés du gaz via les modèles d’AGA8 et de REFPROP, débits de référence par tuyères en régime sonique selon ISO 9300, coefficients de décharge d’organes déprimogènes selon ISO 5167-2, corrections et conversions d’unités), et l’acquisition temps réel multi-protocoles (OPC-UA, Modbus TCP, un multimètre en SCPI et des automates par RS-232), chacune avec surveillance de connexion et reprise automatique après coupure.

Le développement backend a été mené par une équipe de quatre développeurs, dont j’assurais la direction technique (lead dev) : répartition du périmètre, revue des choix d’architecture et de la couverture de tests, arbitrages sur le coeur de calcul métrologique. J’ai personnellement développé la quasi-totalité du backend, à l’exception de la base de données.

Contraintes techniques

Le coeur de calcul métrologique est le point le plus sensible du projet : il réimplémente des formules de métrologie légale (AGA8 Detail et GERG-2008 de l’American Gas Association, REFPROP du NIST, NF EN ISO 5167-2:2022, ISO 9300) où une dérive d’arrondi n’est pas acceptable.

Le client a imposé ses propres règles de codage et de qualité, vérifiées par une infrastructure CI/CD très stricte, ainsi qu’une méthode Agile en sprints pour la conduite du projet. La cible de déploiement est un Windows Server, ce qui contraint l’ensemble de la chaîne (développement, intégration continue, déploiement) à rester compatible Windows tout en restant portable vers Linux.

Une partie du matériel du banc étant en pleine rénovation pendant le développement, certains essais et démonstrations ne pouvaient pas s’appuyer sur les équipements réels.

Démarche

Deux décisions découlent directement de la sensibilité du coeur de calcul :

• Decimal systématique

  Dans le coeur de calcul, plutôt que des flottants, pour éviter toute dérive d’arrondi sur les formules métrologiques.

• Validation contre un référentiel indépendant

  Chaque calcul est vérifié par comparaison automatisée à un référentiel métier historique, avec tolérances documentées et suivi explicite des écarts, plutôt qu’une confiance a priori dans la réimplémentation.

Chaque fonction du coeur de calcul est couverte par des cas nominal / limite / erreur, avec des docstrings qui associent explicitement le numéro de formule du référentiel métier au code et au test correspondant. La traçabilité entre la norme et l’implémentation est documentée à la fonction, pas seulement au module.

Côté acquisition, chaque protocole (OPC-UA, Modbus TCP, SCPI pour le multimètre, RS-232 pour les automates) implémente une détection de coupure active et une reprise de connexion automatique, testée en conditions réelles de coupure/reprise, car un banc d’essai ne peut pas se permettre de perdre silencieusement des mesures pendant une campagne. Pour pallier le manque de matériel réel pendant la rénovation du banc, j’ai supervisé le développement de simulateurs de serveur OPC-UA et de périphériques Modbus, fidèles au comportement cible.

J’ai développé la partie déploiement : la chaîne, du lint au déploiement, passe par la CI de NaTran et devait fonctionner aussi bien sous Linux que sous Windows malgré une cible en Windows, en anticipant une migration future vers un environnement Linux.

Enfin, toute évolution du schéma de base de données passe par une migration Alembic versionnée, testée à l’upgrade et au downgrade, pour garder la base traçable sur la durée de vie du banc.

Réalisations

• Gestion de campagnes d’essai

  Dépouillement et génération de certificats d’étalonnage de tuyères.

• Calculs métrologiques

  Propriétés thermophysiques du gaz et débits de référence, validés contre un référentiel métier historique.

• Acquisition temps réel multi-protocoles

  OPC-UA, Modbus TCP, SCPI (multimètre) et RS-232 (automates), avec reprise automatique après coupure.

• Simulateurs OPC-UA / Modbus

  Développés pour pallier le manque de matériel réel pendant la rénovation du banc.

• Chaîne de déploiement Linux/Windows

  Du lint au déploiement sur la CI de NaTran, malgré une cible en Windows Server.

Déploiement

Déploiement prévu pour octobre 2026.

Enseignements

Ce projet a été ma première expérience de lead dev : au-delà des arbitrages techniques sur le coeur de calcul, il m’a fallu répartir le périmètre entre quatre développeurs et interagir en continu avec le client au fil des sprints, plutôt que sur la base de livraisons figées en amont. La gestion agile de projet imposée par le client s’est autant apprise sur le plan humain que sur le plan technique.

Cette conduite en sprints a aussi changé ma manière de penser l’architecture : les décisions structurantes (typage Decimal, validation contre un référentiel indépendant, traçabilité formule-code-test) ont été pensées et documentées au fil de l’eau, au rythme des sprints, plutôt que figées une fois pour toutes dans une phase de conception isolée en amont.

Le niveau d’exigence qualité demandé sur un projet Python m’a poussé à approfondir des pratiques qu’un contexte moins critique aurait laissées de côté : typage strict et revue systématique sur un langage où rien de tout cela n’est imposé par le compilateur. Le coeur de calcul a aussi demandé d’interfacer Python avec du code de référence existant dans d’autres langages :

• Wrapper C/Python

  Adapté pour l’implémentation AGA8.

• Wrapper Fortran/Python

  Pour REFPROP, logiciel propriétaire du NIST.

Enfin, la chaîne de déploiement Windows/Linux développée pour ce projet a été une première occasion concrète de concevoir un outillage portable dès le départ, plutôt que de porter après coup un outillage pensé pour une seule plateforme.