Du prototype à la plateforme
Faire passer une donnée de l'état « prototype » à l'état « produit » : base relationnelle, stockage, sécurité, historique.
Le besoin
Cet outil sert le montage de dossiers de financement pour un opérateur de rénovation énergétique. Avant mon intervention, il existait sous la forme d'une application prototype monolithique : efficace pour un traitement ponctuel, inadaptée à un usage réel. Pas d'authentification, pas de rôles, pas de persistance des dossiers, aucune collaboration possible.
Ce que j'ai fait
J'ai mené la migration vers une architecture web complète — interface React et base de données — tout en conservant le cœur métier Python existant, que j'ai encapsulé derrière une API plutôt que de le réécrire. Côté données, j'ai conçu le modèle (clients, dossiers, documents, événements, notifications), mis en place le stockage des fichiers entrants et sortants, et défini la sécurité au niveau ligne.
Le pipeline d'extraction
Le cœur métier que j'ai intégré mérite d'être décrit, car c'est un bel exemple de transformation de données hétérogènes en information structurée. En entrée, des documents très variés : certificats énergétiques avant et après travaux, captures d'un logiciel de calcul thermique, factures, pièces d'identité, photos de chantier.
En sortie, les pièces administratives normalisées du dossier de financement, organisées en une arborescence standardisée et exportées prêtes à l'emploi. Entre les deux, le pipeline extrait les données structurées au moyen de modèles de langage, calcule des grandeurs techniques — surfaces, transmittances thermiques, énergie économisée, coordonnées géographiques par géocodage de l'adresse — et adapte les pièces produites à l'organisme concerné, chacun ayant ses propres modèles.
La robustesse reposait sur une stratégie de repli en cascade entre plusieurs fournisseurs de modèles : aucun n'étant fiable à 100 % sur la lecture de documents, l'échec de l'un déclenchait le recours à un autre. Le taux de réussite global s'en trouvait sensiblement amélioré.
Ce qui était difficile
La principale difficulté a été la cohabitation entre un code pensé pour des fichiers locaux et un flux passant désormais par un stockage distant — deux façons de désigner un fichier qui ne se recouvrent pas. S'y est ajoutée la gestion des caractères accentués dans les noms de fichiers, source récurrente d'erreurs côté stockage.
Cette mission illustre une compétence clé du parcours : faire passer une donnée d'un état prototype — fichiers locaux, traitement jetable — à un état produit : base relationnelle, stockage distant, sécurité, historique.