Ethan Hayoun
← Tous les projets01 / 05

Plateforme web · Aéronautique · Performance

Architecture API

Une API FastAPI pour externaliser les traitements d’une application Streamlit, et une campagne de 15 utilisateurs ramenée de 13 minutes à 1 min 30.

Rôle
Ingénieur logiciel Python · architecture API et évolution applicative
Période
Depuis nov. 2025
Statut
En production interne · évolutions en cours
Contexte
Plateforme web de suivi de maintenance aéronautique · client confidentiel

Le défi

Sur une plateforme web de suivi de maintenance, des traitements lourds exécutés dans les sessions dégradaient la réactivité de l’application.

La réponse

Une couche API FastAPI : l’interface Streamlit appelle les traitements existants à travers elle, sans réécrire le moteur métier — puis des campagnes de charge pour mesurer le gain.

La coupe

Sous l’interface.

  1. 01

    Interface

    Des vues de données plus prévisibles.

    Évolution des interfaces de consultation : restitution des résultats, tableaux, exports, et correction de recalculs inutiles.

    Consultation et filtres · Tableaux de résultats · Exports de données

    Python · Streamlit · pandas

  2. 02

    Services

    Une API entre l’interface et les traitements.

    Les appels de l’interface migrent vers FastAPI, qui orchestre l’exécution en processus dédiés. Les traitements métier sont réutilisés, pas réécrits.

    Clients API · Services FastAPI · Traitements de données · Exécution parallèle

    Python · FastAPI · Pydantic · pandas · SQLite

  3. 03

    Infrastructure

    Mesurer avant d’optimiser.

    Des outils de monitoring et des campagnes de charge reproductibles comparent durées, CPU et mémoire sous plusieurs sessions simultanées.

    Collecte de métriques · Visualisation des campagnes · Scénarios multi-utilisateurs · Gestion des versions

    Python · Git · scripts de monitoring · tests de charge

Suivi des exécutions : durées, CPU et mémoire (maquette fictive).
Schéma avant / après : l’interface appelle les traitements via une API FastAPI.
Espace d’exploration : filtres, graphique et tableau de résultats (maquette fictive).

Décisions

Pourquoi ces choix.

  1. 01Interface

    Limiter les traitements redondants

    Certaines interactions pouvaient entraîner des calculs non nécessaires.

    Corriger les déclenchements et vérifier les parcours concernés.

    → Comportement plus prévisible et réduction du travail superflu sur les cas corrigés.

  2. 02Services

    Faire exécuter les traitements existants via une API

    Les opérations de calcul et de préparation de données peuvent dégrader la réactivité des sessions web.

    Créer la couche API et adapter l’interface pour appeler les traitements existants à travers elle.

    → Meilleure isolation des charges de travail et possibilité de mesurer les comportements en concurrence.

  3. 03Infrastructure

    Mesurer avant d’optimiser

    Les impressions de rapidité ne suffisent pas à comparer des versions ou à diagnostiquer un ralentissement.

    Instrumenter les actions et les ressources, puis comparer des campagnes définies.

    → Écarts de performance observables et investigations mieux ciblées, sans revendiquer de gain chiffré.

Le parcours

De la donnée au résultat exploitable.

  1. Sélection d’un jeu de données (maquette fictive).
    01

    Sélectionner un jeu de données

    L’utilisateur choisit un ensemble fictif de données et consulte les paramètres généraux de l’analyse.
  2. Exécution d’une analyse avec journal (maquette fictive).
    02

    Lancer une analyse

    L’application exécute un traitement et signale son avancement ou son statut.
  3. Résultats en tableaux filtrables (maquette fictive).
    03

    Explorer les résultats

    Les données consolidées sont présentées en tableaux filtrables et indicateurs lisibles.

Résultats

13 min → 1 min 30
pour une campagne de 15 utilisateurs simultanés
≈ 86 %
de gain de rapidité et de performance mesuré
0
traitement métier réécrit
RetourTous les projets