Prise en charge de toute l'infrastructure, du front et de l'API client

Contexte

Le produit fournissait des recommandations de taille par IA à plusieurs enseignes de mode (Balsamik, Terre de Marins et Temps des cerises) et nécessitait une modernisation de son API et de son infrastructure. Alors que tout l'équipe démissionnait progressivement en 3 mois, j'ai pris en charge seul avec un freelance back-end la maintenance et l'évolution du produit.

Responsabilités

• Prendre en charge seul l’application front-end et l’infrastructure de production de bout en bout.
• Faire évoluer seul l’API exposée aux clients e-commerce.
• Concevoir en équipe les traitements asynchrones du produit.
• Assurer la continuité du produit malgré le départ progressif de l'équipe initiale.

Problèmes adressés et solutions apportées

Améliorer les performances du front-end

Problème

Toute la code base front-end déjà en production souffrait de problèmes de performance, de bugs fréquents et de style incohérent.

Solution

J'ai migré la code base JavaScript vers TypeScript, mis en place un design system pour améliorer la maintenabilité et la performance, réduit les rendus inutiles côté React + Redux Saga et passé la code base d'un container Docker à un bucket S3 + CloudFront pour une meilleure distribution des assets.

Effet

Le front-end est devenu plus réactif et les bugs ont été significativement réduits.

Monohlite Symfony avec trop de legacy

Problème

Le produit ayant essayé plusieurs approches avant de trouver une solution stable, la code base PHP/Composer/Symfony était devenue un monolithe avec trop de legacy.

Solution

Le LLM étant déjà dans une infrastructure Python/Flask, avec l'aide du freelance back-end, nous avons donc choisit de migrer progressivement vers les micro services Python basés sur Flask, tout en débugant le code restant dans le monolithe Symfony le temps de la migration complète.

Effet

100% des fonctionnalités critiques ont été migrées avec succès vers les micro services Python, en sépérant clairement les responsabilités via des API (gateway OAUTH2, tratiement des fiches techniques, scoring).

Incendie OVH

Problème

Un incendie a détruit une partie de l'infrastructure OVH, impactant la disponibilité des services.

Solution

J'ai dû seul rapidement migrer les services critiques cloud tournant sur l'infrastructure OVH dans VPS/Portainer + Mysql managed vers une nouvelle infrastructure AWS/EKS(Kubernetes + Helm charts + CI/CD), en minimisant les interruptions pour les utilisateurs.

Effet

La continuité des services a été assurée malgré l'incendie, et l'infrastructure est devenue plus résiliente.

Amélioration continue

Problème

Même après les migrations et les refactorings, il restait des points de friction et des opportunités d'optimisation.

Solution

Nous avons mis en place un processus d'amélioration continue, prise en compte des retours clients, avec une surveillance proactive des performances via Datadog/sentry et des sprints en méthode agile via Jira d'optimisation réguliers.

Effet

Le produit est devenu plus stable, performant et maintenable sur le long terme.

Amélioration de l'application mobile

Problème

Reprise de l'application mobile livrée par une agence.

Solution

J'ai dû seul reprendre le code de l'application mobile, corriger les bugs existants, améliorer les performances et mettre en place des tests automatisés pour assurer la qualité du code.

Effet

L'application mobile est devenue plus stable, performante et maintenable.

Reception des fiches techniques

Problème

Les fiches techniques contienent les mensurations lié à chaque produit et marques, car les tailles étant définies par chaque marque, les ERPs livrant différent format et valeur selon le fournisseur, il était important de standardiser et automatiser leur traitement.

Solution

En collaboration continue avec le freelance back-end et le CEO, nous avons mis en place un système automatisé pour la réception et le traitement des fiches techniques, réduisant les erreurs et améliorant l'efficacité. Prenant aussi en compte les caractéristiques techniques spécifiques de chaque produit afin d'assurer une standardisation optimale des données.

Effet

Le processus de gestion des fiches techniques est devenu plus fiable et rapide, avec des résultats en testréel satisfaisants.

Cumul des données de mensurations

Problème

Les données de mensurations étaient rare, et l'acquisition de nouvelles base de données n'était pas suffisant en volume, il fallait donc collecter et centraliser de nouvelles données.

Solution

Lors qu'un utilisateur entrait ses mensurations, il faillait automatiquement centraliser ces données dans une base de données Elasticsearch, visible dans un Kibana dashboard pour le client et pour nous, avec un système de fenêtre temporelle et par client.

Effet

Les données de mensurations sont désormais centralisées et facilement accessibles, permettant une meilleure analyse et utilisation pour les recommandations de taille.

Highlights

• Participation à l'appel d'offre pour étudier les tailles/mesures afin d'équiper les athlètes Français pour les JO de Tokyo (2021).
• Collaborer avec le data-scientist pour améliorer les recommandations de taille par IA.

Technologies

• PHP
• ERP
• Symfony
• Composer
• Python
• Flask
• OVH
• VPS
• Cloud
• EKS
• S3
• IAM
• Route 53
• CloudFront
• RabbitMQ
• AWS
• Kubernetes
• Docker
• SQL
• Elastic search
• AI
• React
• Redux
• Redux saga
• SDK
• React native
• Datadog
• Helm charts
• CI/CD
• Git
• Portainer
• micro-service
• Kibana
• jira
• FTP
• API
• mysql
• agile
• TypeScript

Résultats

Clients e-commerce intégrés

3

Rerendue côté client réduite

~5 to 1

réduction des erreurs dans le front client / clean console

100%

score Lighthouse sur les site e-commerce intégrés

~80%

Chunks du code front-end optimisés

3+

Temps de réponse de l'API client réduit (vectorisation)

3s to 3 ms

Passage d'un monolithe à une architecture micro-service

1 to 5

Disponibilité de l'infrastructure cloud assurée

90%

Déploiements automatisés réussis

100+