Les principes directeurs de La Centrale pour se déployer dans le cloud public

Dans le cloud, La Centrale a fait son choix : à fond les services managés. Un choix pragmatique pour le CTO Thomas Berger : "On est locké chez AWS, mais le gros avantage, c'est que j'ai très peu d'équipes d'opération."

L'entreprise française, à l'origine d'une marketplace de véhicules d'occasion, compte 80 personnes à l'IT, structurée en 12 feature teams, pour un déploiement toutes les 4 heures.

Au-delà de la règle consistant à utiliser au maximum les services managés, La Centrale proscrit le lift & shift. Les microservices, qu'elle a massivement adoptés, "facilitent la transformation, au sens fonctionnel comme technique", explique Thomas Berger. Autre mantra : si ce n'est pas du core, on achète ("Je ne veux pas opérer des systèmes que je n'ai pas construits", résume le CTO).

PHP, Redis et New Relic poussés vers la sortie

L'entreprise a créé son Tech Radar, mis à jour à fréquence trimestrielle. Il couvre quatre axes :

• Langages et frameworks
  Node.js, Python et React sont en bonne position (catégorie "Adopt"), au contraire de Java ("Hold") et de PHP ("Drop").
  
  
• Infrastructure
  Athena, DynamoDB et Neptune font partie des bases de données privilégiées ("Adopt"), à l'inverse de RDS ("Hold"), Oracle et Redis ("Drop").
  
  
• Techniques et méthodologies
  Les voyants sont au vert, entre autres, pour le stateless, le data mesh et les pipelines as code ("Adopt"). Les architectures GraphQL ("Hold") et la revue de code cross-team sont vers l'autre bout du spectre ("Drop").
  
  
• Outils
  GitHub Copilot, Amazon Q, Cursor et l'API OpenAI sont dans le haut du panier ("Adopt"). Ansible et Packer vont vers la sortie, comme Bitrise et Gradle ("Drop"). Fluentd, New Relic et AWS Data Pipelines sont entre deux eaux ("Hold").

Une soixantaine de règles de gouvernance communes sont en place. Exemple : toutes les apps doivent privilégier Lambda. Un repli vers Fargate peut toutefois être envisagé pour motif économique ou pour les workloads qui dépassent le timeout Lambda (15 minutes).

Chaque application a sa fiche d'architecture qui contient :

• Schéma d'architecture
• Dépendances réseau
• Tags de suivi
• Procédure d'astreinte
• Monitoring/alarmes
• Swagger API
• Documentation du modèle de données
• Analyse des tests de charge

Ces fiches sont revues avant le début des développements par un comité comprenant jusqu'à une quinzaine de personnes. Elles le sont aussi avant le premier déploiement en production et à chaque changement important.

Un audit automatisé des technos via Wiz

La Centrale y adjoint un audit automatisé des technologies utilisées sur sa plate-forme, via Wiz. Il est réalisé au minimum une fois par mois, pour mesurer le delta par rapport aux règles de gouvernance.

Toutes les feature teams ont un budget mensuel, avec des alarmes en cas de dépassement. Chaque mois, elles analysent leurs coûts et réalisent les actions nécessaires. Cela ne prend pas en compte les réservations, gérées. Même chose pour les savings plans, de par leur complexité (avec eux, "on change d'instance toutes les 2 minutes", glisse Thomas Berger).

S'y ajoute un exercice dit SimDay. Organisé ponctuellement le vendredi matin, il consiste à simuler la perte du compte de prod AWS. Objectif : reconstruire le plus vite possible le site et les principaux services (environ 1400 noeuds). Lors du dernier, organisé il y a deux semaines, il a fallu la journée. La résilience est favorisée par l'usage de l'IaC (Infrastructure as Code), de backups immutables et de plans de terrain (ordre de remise en marche des applications).

Cas d'usage présenté lors des Universités du CRiP (16-17 juin 2025 à Paris).

Illustration © Annika - Adobe Stock