Entretien Sanofi Flashcards
Continuous Delivery
RATP, MCM, FDJ
❓ Comment gérer le scaling d’une API sur AWS ?
📌 Réponse (STAR)
Situation : Un projet e-commerce voyait un pic de trafic lors du Black Friday, causant des erreurs 503 sur l’API.
Tâche : Assurer que l’API puisse gérer des milliers de requêtes par seconde.
Action :
Load Balancer (ALB) + Auto Scaling Group pour ajuster dynamiquement les instances.
Mise en place de Lambda + API Gateway pour gérer certaines requêtes sans serveur.
Redis + DynamoDB pour stocker les données temporaires et éviter de surcharger la base SQL.
Résultat : 99.99% uptime même lors de pics de 500 000 requêtes/minute.
🔹 Résumé rapide :
Auto-scaling des instances backend (EC2, Fargate).
AWS Lambda pour certaines tâches asynchrones.
Caching Redis/DynamoDB pour réduire la charge.
Comment optimiser un build Amplify (AWS) ?
Réponse (STAR)
Situation : Dans un projet Next.js hébergé sur Amplify, les builds prenaient 15 minutes, impactant la productivité.
Tâche : Réduire le temps de build et améliorer le déploiement continu.
Action :
Utilisation du cache de dépendances pour éviter de tout recompiler.
Passage à ISR (Incremental Static Regeneration) pour ne pas rebuild toutes les pages.
Migration des assets statiques vers S3 + CloudFront au lieu de les inclure dans le build.
Résultat : Temps de build réduit à 5 minutes et site plus réactif.
🔹 Résumé rapide :
Utiliser le cache des dépendances pour accélérer les builds.
Passer à ISR au lieu de SSG pour éviter les rebuilds complets.
Héberger les assets sur S3 + CloudFront pour améliorer les temps de chargement.
❓ Différences entre REST, GraphQL et RPC ?
📌 Réponse rapide (tableau comparatif)
Critère REST GraphQL RPC (Remote Procedure Call)
📌 Modèle Ressources (URLs) Schéma basé sur des requêtes Appelle directement des fonctions
⚡ Performance Peut être verbeux Optimisé (récupère que ce qu’il faut) Très rapide mais plus rigide
🔗 Flexibilité Peu flexible Très flexible (query sur mesure) Dépend du protocole
🔒 Sécurité Facile à sécuriser Nécessite plus de contrôle Sécurisé si bien implémenté
📌 Quand utiliser quoi ?
REST → Pour des APIs publiques bien définies (ex: API Stripe).
GraphQL → Quand le frontend a besoin de flexibilité (ex: Dashboard interactif).
❓ Explique le concept de Backend for Frontend (BFF) et ses avantages.
📌 Réponse (STAR)
Situation : Dans un projet multi-plateforme (web + mobile), chaque client appelait directement l’API backend, causant des problèmes de performance.
Tâche : Mettre en place une BFF (Backend for Frontend) pour optimiser les requêtes et adapter les réponses aux besoins du frontend.
Action :
Création d’un serveur Node.js spécifique qui sert de BFF.
Réduction des appels aux microservices backend en aggrégeant les données côté BFF.
Ajout d’un cache Redis pour éviter des appels répétitifs.
Résultat : Temps de réponse réduit de 40% et moins de charge sur l’API principale.
🔹 Résumé rapide :
BFF → Une API intermédiaire entre le frontend et les microservices backend.
Avantages : Meilleure performance, plus de flexibilité et simplification du code frontend.
❓ Comment sécuriser une API dans un projet Next.js / Node.js ?
📌 Réponse (STAR)
Situation : Sur un projet de plateforme de formation, on devait sécuriser l’API Next.js utilisée par le frontend et des clients tiers.
Tâche : Assurer une authentification robuste et éviter les fuites de données.
Action :
Implémentation de JWT avec expiration courte + refresh tokens.
Protection des routes API avec Middleware Next.js pour vérifier les permissions.
Mise en place de Rate Limiting via Redis pour bloquer les abus.
Résultat : Plus aucune tentative de brute force et une meilleure gestion des accès utilisateurs.
🔹 Résumé rapide :
JWT + Refresh Tokens pour l’authentification.
Middleware Next.js pour protéger les routes.
Rate Limiting (ex: Redis) pour éviter les attaques DDoS.
❓ Comment Next.js gère le rendering côté serveur et côté client ?
📌 Réponse (STAR)
Situation : J’ai travaillé sur un projet où il fallait améliorer les performances et le SEO d’un site e-commerce.
Tâche : Il fallait choisir entre SSG, SSR et ISR pour optimiser le rendu des pages.
Action :
Static Site Generation (SSG) → Utilisé pour les pages produit, pré-générées au build.
Server-Side Rendering (SSR) → Pour les pages qui changent souvent, comme les prix dynamiques.
Incremental Static Regeneration (ISR) → Pour régénérer une page après un certain temps sans reconstruire tout le site.
Résultat : Chargement 50% plus rapide, SEO amélioré et coûts réduits sur AWS grâce à moins de requêtes serveur.
🔹 Résumé rapide :
SSG (Static Site Generation) → Pages générées au build time, ultra rapide.
SSR (Server-Side Rendering) → Page générée à chaque requête, utile pour les contenus dynamiques.
ISR (Incremental Static Regeneration) → Pages statiques mises à jour en arrière-plan après un certain temps.
Contexte de Sanofi
Sanofi est un leader mondial de l’industrie pharmaceutique, spécialisé dans :
Les vaccins (Sanofi Pasteur)
Les traitements pour les maladies rares, la sclérose en plaques, l’immunologie
La médecine générale (diabète, maladies cardiovasculaires)
L’automédication (Doliprane, Lysopaïne, etc.)
Leur transformation digitale est une priorité, notamment pour améliorer la relation avec les professionnels de santé et patients via des outils numériques innovants.
À dire en entretien :
“Sanofi est un acteur majeur de la santé qui mise sur la digitalisation pour mieux accompagner les HCPs et les patients. Ce projet Marketing Suite s’inscrit dans cette stratégie en facilitant la diffusion de contenu médical personnalisé.”
Our ambition is to scale and adapt to every country’s needs and legal requirements, and any technical solution that could help us is welcome.
📌 Réponse Structurée (STAR Method)
Situation : “J’ai déjà travaillé sur des projets nécessitant une adaptation aux contraintes locales, notamment sur des aspects légaux et techniques.”
Tâche : “L’objectif était de construire une solution évolutive, capable de gérer des différences de réglementation, de langues et de besoins fonctionnels.”
Action :
Modularisation des fonctionnalités → Découper les fonctionnalités en modules activables/désactivables selon les besoins des pays.
Feature Flags (ex: LaunchDarkly) → Permet d’activer certaines règles spécifiques à un pays sans redéployer.
Configuration externalisée (ex: via CMS comme Magnolia ou fichiers de config sur S3) → Permet d’adapter dynamiquement l’application sans toucher au code.
Séparation des données (ex: multi-tenant architecture) → Pour respecter le RGPD en Europe ou d’autres régulations locales.
Résultat : “Grâce à cette approche, nous avons pu déployer rapidement dans plusieurs pays sans devoir maintenir des versions différentes du code.”
📌 Réponse Rapide
“Pour répondre aux besoins de chaque pays, il est essentiel d’avoir une architecture modulaire et configurable. J’utiliserais une approche basée sur des feature flags et une configuration dynamique pour activer ou désactiver certaines fonctionnalités sans impact global. En complément, un système de multi-tenant permettrait d’assurer la conformité aux réglementations locales comme le RGPD, tout en gardant une seule base de code scalable.”
