Edenred Essentials
Comment Edenred Essentials a objectivé ses dysfonctionnements techniques et accéléré sa transition CTO en 8 semaines
Contexte
Edenred Essentials est une filiale d'Edenred qui opère sur le marché américain. Sa plateforme gère les dépenses de flotte automobile (carburant, recharge électrique, entretien, péages) avec une intégration directe au réseau Visa. Chaque transaction est vérifiée en temps réel. Le niveau de disponibilité requis est celui d'un système de paiement : les interruptions n'ont pas de marge.
La direction a décidé de faire appel à Hones dans un contexte de changement de CTO. L'équipe technique réunissait une poignée de développeurs internes basés aux États-Unis et une équipe offshore en Inde. Sans profil technique en interne pour assurer la continuité dans l'intervalle, la direction avait besoin d'un état des lieux objectif : comprendre d'où venaient les dysfonctionnements, et donner au nouveau CTO une base solide pour démarrer.
Défis
Défi #1 — Identifier les causes réelles d'une architecture qui pésait sur toute la plateforme
La plateforme avait été construite sur une architecture microservices, dimensionnée pour absorber une charge bien supérieure aux volumes réels. Ce type d'approche offre généralement de la flexibilité, mais en pratique, les services censés être indépendants partageaient des dépendances logiques non anticipées. Résultat : la complexité était là, les bénéfices attendus ne s'étaient pas matérialisés. Bugs fréquents, déploiements lents, temps de développement disproportionné par rapport à la valeur livrée.
Hones a croisé l'analyse du code source avec les métriques de delivery pour identifier précisément les points de friction. L'architecture avait été pensée pour une échelle qui n'existait pas encore, et la dette accumulée dans cette implémentation ralentissait chaque évolution. La direction est passée d'un sentiment diffus à une lecture documentée des causes.
Défi #2 — Objectiver les tensions entre l'équipe produit et l'équipe technique offshore
L'organisation reposait sur un déséquilibre structurel : trois développeurs internes face à plus de dix intervenants offshore. Le décalage horaire et les différences culturelles compliquaient la collaboration directe. L'équipe produit absorbait la pression des bugs sans avoir de prise réelle sur leur résolution.
L'audit a mis en lumière les mécanismes précis de ce désalignement. Il a permis de formuler des recommandations concrètes sur les interfaces de communication entre équipes et les modes de pilotage de la prestation offshore.
Défi #3 — Accélérer la prise en main du nouveau CTO dans un environnement fragmenté
Le nouveau CTO est arrivé en cours de mission. Prendre en main un environnement aussi fragmenté avec une architecture héritée, une équipe offshore, un codebase peu documentée, représente normalement plusieurs mois d'exploration avant de pouvoir décider quoi que ce soit.
Hones a tenu le nouveau CTO informé tout au long de l'audit, lui permettant de s'approprier progressivement les enjeux. À la livraison finale, il disposait d'une vision complète de l'existant, avec des priorités classées par criticité business. Cette base lui a permis d'être opérationnel sur les décisions structurantes dès ses premières semaines.
Résultats
- Le nouveau CTO a démarré avec une vision complète et priorisée de l'architecture, de l'organisation et des points de tension. Un état des lieux qui lui aurait pris plusieurs mois à construire seul.
- La direction a compris les causes concrètes des bugs et du ralentissement du delivery. Fini les interprétations floues : les problèmes étaient documentés, sourcés, classés par criticité.
- Les recommandations architecturales ont été mises en œuvre par le nouveau CTO : simplification de l'architecture, réduction de la complexité accumulée sans contrepartie fonctionnelle.
- La relation entre l'équipe produit et l'équipe technique a été restructurée, avec des canaux de communication clarifiés et un mode de pilotage de la prestation offshore redéfini.
Ce qu'on a appris
Quand une architecture a été pensée pour une échelle très supérieure à l'usage réel, le problème n'est pas forcément dans le code lui-même. Il est dans les décisions prises trop tôt, sur des hypothèses de croissance qui ne se sont pas vérifiées. Les microservices ne sont pas mauvais par nature. Ils deviennent un frein quand ils ajoutent de la complexité sans contrepartie en volume ou en modularité effective. Stack Overflow a fonctionné longtemps sur un monolithe. Google aussi. La bonne architecture est celle qui correspond à l'échelle réelle du moment, pas à celle qu'on espère atteindre.
L'autre enseignement de cette mission : un audit tech réalisé pendant une transition CTO a une valeur double. Il sert à la fois la direction, qui comprend ce qui s'est passé, et le nouveau dirigeant, qui sait où il met les pieds. Ces deux lectures ne se substituent pas l'une à l'autre, elles se renforcent.
