Plateforme AYDO Produits Structurés
Un espace unique pour rechercher, comparer et suivre les produits structurés. Construit pour que les analystes arrêtent de vivre dans 12 onglets.
La première fois que je me suis assis à côté d'une analyste AYDO, elle avait 12 onglets ouverts. Des term sheets dans trois portails de contreparties, un terminal Bloomberg en arrière-plan, un fichier Excel qui suivait les niveaux de barrière à la main, et un fil Slack sur la question de savoir si un autocall s'était déclenché sur un produit acheté six mois plus tôt. Les données existaient. Aucune n'était au même endroit.
C'est l'écart qu'AYDO devait combler. Rechercher un produit structuré, le comparer à d'autres sur des bases équivalentes, puis suivre le cycle de vie réel une fois le produit en portefeuille.
Ce qui était difficile
Le problème de comparaison ressemble à un problème de données. C'est en fait un problème de normalisation. Un reverse convertible d'un émetteur ressemble structurellement à celui d'un autre, mais les conventions de barrière, les dates d'observation, la mécanique des coupons diffèrent de façons qui comptent. Mettre deux produits sur le même écran avec des chiffres vraiment comparables a demandé de modéliser à la main chaque famille de produits, et d'être honnête quand la comparaison n'était pas sûre.
J'ai construit le backend Go autour d'un petit nombre de frontières de domaine claires : catalogue, valorisation, suivi. Chacune expose un contrat REST typé. Le frontend React s'appuie sur un jeu de blocs par famille de produits (autocalls, reverse convertibles, notes à capital protégé), pour qu'ajouter la quatrième famille ne réclame pas de redessiner l'écran.
Ce qu'on a sous-estimé
L'ordonnancement. Les produits structurés ont des dates d'observation qui comptent au centime. Un fixing de coupon raté d'un jour change le résultat d'un client. On a commencé avec un cron classique, encaissé notre premier passage à l'heure d'été, et appris que « tous les jours à l'ouverture du marché » n'est pas une notion que les crons gèrent bien sur les calendriers européens. On a réécrit l'ordonnancement sur une table de calendrier de marché explicite. Moins élégant. Beaucoup plus correct.
PostgreSQL sur RDS a bien tenu. S3 pour les PDF de term sheets et les snapshots de cycle de vie. Rien d'exotique côté infra ; la complexité était dans le domaine.
Où ça a atterri
Les recherches qui prenaient une heure tombent à quelques minutes sur les produits qu'on a modélisés proprement. Le suivi est passé de piloté-par-tableur à piloté-par-alerte. Surtout, les analystes ne possèdent plus la plomberie des données.
Ce qui reste ouvert : une intégration plus profonde avec les portails de contreparties. Aujourd'hui on ingère les term sheets et les observations via des flux normalisés. Tirer les observations live directement de chaque contrepartie fermerait la dernière boucle manuelle. C'est ce que je construirais ensuite.