Aller au contenu
ADAMA OSESG · DATA · SYSTEMS
RecruteurProfil, preuves, disponibilitéÉchangeons

JOURNAL DES DÉCISIONS DEC-002

Python plutôt que Node.js pour les moteurs de calcul

Statut
AcceptéeEn vigueur aujourd’hui.
Date
Portée
Le groupe
Impact
Architecture
Réversibilité
Revenir en arrière demande un chantier

Entrée reconstruite à partir du dépôt. Les options listées ci-dessous sont celles que le code démontre. Elles ne prétendent pas décrire ce qui a été envisagé à l’époque, et les questions restées ouvertes sont écrites en fin de page.

Contexte

Le groupe a deux moteurs de calcul à écrire : l’empreinte carbone sur les scopes 1, 2 et 3, et l’analyse documentaire des standards ESRS.

L’interface était déjà en Next.js, donc en TypeScript. Écrire les moteurs dans le même langage aurait évité une deuxième plateforme d’exécution.

Un moteur de calcul de durabilité doit être testable ligne à ligne et rejouable sur un jeu de données connu, parce que son résultat sera contesté sur sa méthode.

Options envisagées

  • Retenue

    Écrire les moteurs en Python, exposés par une API séparée

    Le calcul reste isolé de l’interface, testable seul, et l’outillage de traitement documentaire est celui de son écosystème d’origine.

  • Écartée

    Écrire les moteurs en TypeScript, dans la même application

    Une seule plateforme, mais le calcul se mélange à l’interface, et l’outillage scientifique et documentaire disponible est plus pauvre.

Décision

Les moteurs de calcul et d’analyse du groupe sont écrits en Python et exposés par une API séparée. L’interface reste en Next.js.

Raisonnement

Technique
Un moteur sans interface et sans base se teste sur des entrées connues et se rejoue à volonté. Le séparer de l’application le rend remplaçable sans toucher au reste.
Réglementaire
Un résultat de durabilité doit être reconstituable. Un moteur isolé, testé, dont les entrées et les sorties sont explicites, se défend devant un tiers.
Économique
Deux plateformes d’exécution à déployer et à surveiller au lieu d’une, contre un temps de développement du calcul plus court.

Compromis accepté

Deux langages, deux chaînes de dépendances, deux déploiements et deux façons de gérer les erreurs. Pour une personne seule, c’est le double de surface à tenir à jour.

DÉCISION · CODE · RÉSULTAT

  1. LA DÉCISION

    Les moteurs de calcul et d’analyse du groupe sont écrits en Python et exposés par une API séparée. L’interface reste en Next.js.

  2. LE CODE QU’ELLE A PRODUIT
    • FichierContrat des passerelles produitapps/web/lib/ecosystem/gateways.ts
    • RouteRoute de santé de STRATA ScopeGET /health sur scope.esg-optimizer.fr
    • RouteRoute de santé d’ESG OptimizerGET /health sur api.esg-optimizer.fr
  3. LE RÉSULTAT OBSERVÉ

    STRATA Scope et ESG Optimizer exposent chacun une API Python, dont la seule surface publique en lecture est une route de santé. Ces deux routes sont ce que ce cockpit interroge, et rien d’autre : le contrat est décrit dans apps/web/lib/ecosystem/gateways.ts.

Questions ouvertes

Ce que le dépôt ne démontre pas, et que seul Adama peut trancher. Elles sont écrites plutôt que comblées.

  • La bascule a-t-elle coûté une réécriture, ou le moteur Node n’avait-il jamais dépassé le prototype ?

LE JOURNAL COMPLET

Toutes les décisions, au même format.

Elles se comparent : même gabarit, même vocabulaire, même exigence de trace.

Revenir au journal