Comment Evaneos utilise Claude pour sécuriser ses transformations d’architecture
Regards croisés de Nicolas Gomes, Staff Engineer chez Evaneos, et Rémy Jardinet, Architecte d’Entreprise chez Eleven Labs | 08/09/2026
Evaneos est une plateforme de voyage qui met en relation les voyageurs avec des agences locales sélectionnées afin de concevoir des voyages sur mesure.
Staff Engineer, Evaneos
Pouvez-vous nous présenter le contexte d’Evaneos et les enjeux auxquels vous faisiez face ?
Nicolas Gomes — Staff Engineer, Evaneos
Notre système d’information s’est construit et enrichi au fil des années autour d’une architecture distribuée composée de nombreux services. Dans cet environnement, certaines transformations demandent un important travail de cadrage en amont pour comprendre précisément leurs impacts sur le reste du SI.
Nous avons identifié quatre types de besoins récurrents sur lesquels nous voulions fiabiliser cette phase de cadrage :
- Décommissionnement : supprimer ou débrancher un service ou une capacité sans oublier un appelant ou un usage existant.
- Migration de données : déplacer des données entre différentes bases ou différents modèles en identifiant les dépendances et les impacts associés.
- Ajout de fonctionnalité : déterminer les services, domaines et composants concernés avant d’introduire une nouvelle capacité.
- Déplacement de responsabilité : extraire une responsabilité d’un service pour la repositionner dans le service correspondant au bon domaine métier.
Pour chacun de ces chantiers, la difficulté est la même : avoir une vision suffisamment complète de l’existant avant de décider comment le transformer.
Une partie de cette connaissance repose historiquement sur les personnes qui connaissent le système. Avec l’évolution des équipes et de l’organisation, nous avions besoin de réduire cette dépendance à la connaissance individuelle, mais aussi de rendre le cadrage plus reproductible : deux personnes travaillant sur un même besoin ne doivent pas aboutir à des découpages, des hypothèses ou des niveaux de risque complètement différents.
Nous disposions déjà de nombreuses sources d’information. L’enjeu était donc de construire une méthode capable de les mobiliser systématiquement pour sécuriser ces décisions d’architecture.
Quel était précisément l’objectif du projet ?
Nicolas Gomes — Staff Engineer, Evaneos
Nous voulions pouvoir partir d’un besoin exprimé en une phrase et arriver à un projet Linear structuré, documenté et directement exploitable par les équipes.
Entre ces deux points, il faut être capable de reconstruire tout le raisonnement nécessaire au cadrage du projet.
Prenons le décommissionnement d’un service. Avant de décider de le supprimer, il faut connaître ses dépendances, vérifier s’il est réellement encore utilisé, comprendre les données qu’il manipule, déterminer où doivent être repositionnées ses éventuelles responsabilités et identifier les autres projets susceptibles d’interférer avec cette transformation.
C’est sur ce travail que nous voulions utiliser l’IA. Pas pour confier la décision d’architecture à Claude, mais pour rendre ce processus d’analyse beaucoup plus systématique et reproductible.
Le résultat attendu n’était donc pas une recommandation générée par un LLM, mais un projet complet : architecture documentée, hypothèses explicites, décisions tracées, milestones, issues et sous-issues, avec des points d’arbitrage humain avant toute création du backlog.
“ Notre objectif n’était pas de laisser l’IA décider de notre architecture. Nous voulions qu’elle prépare chaque décision avec suffisamment d’éléments factuels pour que nos équipes puissent réellement l’arbitrer. “
Comment avez-vous conçu la solution pour répondre à ce besoin ?
Rémy Jardinet — Architecte d’Entreprise, Eleven Labs
Notre point de départ a été l’écosystème déjà en place chez Evaneos. Il existait plusieurs briques très riches, mais utilisées séparément selon les besoins.
Le référentiel interne rchiv, propre à Evaneos, apporte une cartographie précise de la structure du SI et permet notamment d’identifier les services, leurs handlers, les tables lues ou écrites, les événements et les connexions entre applications.
Les outils internes de connaissance et d’engineering apportent le contexte sur le fonctionnement du SI, tandis que les principes d’architecture et le modèle de domaines définissent la cible vers laquelle les responsabilités doivent évoluer.
Datadog apporte une autre dimension essentielle : la réalité de l’utilisation. Une dépendance présente dans le code n’est pas nécessairement utilisée et, inversement, un composant que l’on pense inactif peut encore être sollicité ponctuellement. L’analyse doit donc prendre en compte des fenêtres suffisamment longues pour absorber la saisonnalité propre à l’activité d’Evaneos.
Enfin, Linear apporte le contexte projet et devient également le point d’arrivée du processus.
Nous avons conçu la pipeline pour que Claude puisse mobiliser chacune de ces briques au moment où elle devient pertinente dans le raisonnement, notamment grâce aux interfaces MCP déjà présentes chez Evaneos.
Comment Claude intervient-il tout au long de la pipeline ?
Rémy Jardinet — Architecte d’Entreprise, Eleven Labs
Claude constitue le moteur de la pipeline. La solution s’appuie sur les modèles Claude d’Anthropic, exploités directement via le compte Anthropic d’Evaneos. Plutôt que de lui soumettre un énorme prompt en lui demandant de produire directement un plan d’architecture, nous avons décomposé le cadrage en une succession d’étapes spécialisées.
Le processus commence par qualifier précisément le besoin et son périmètre. Il établit ensuite la cartographie des ramifications du changement, vérifie l’usage réel des composants concernés et détermine les domaines et responsabilités impactés.
Une fois ces fondations établies, la pipeline prépare le filet de sécurité nécessaire à la transformation — tests, observabilité, ordre des opérations — puis construit séparément la stratégie concernant le code et celle concernant les données.
Elle génère ensuite les représentations de l’architecture, synthétise le plan complet du chantier puis le décompose progressivement jusqu’à obtenir des étapes directement actionnables par les équipes.
Chaque étape possède des entrées, des outils autorisés, une condition de sortie et un format attendu. Les artefacts structurés produits par une étape servent d’entrée à la suivante.
Des JSON Schema permettent de contrôler ces contrats et quelques scripts JavaScript assurent notamment leur validation ainsi que la génération de certains diagrammes. Cette architecture permet aussi de rejouer une étape sans devoir recommencer systématiquement l’intégralité du processus.
Cette architecture a permis d’industrialiser la pipeline et de la déployer en production chez Evaneos. Elle est aujourd’hui utilisée par les équipes pour accompagner le cadrage de leurs transformations d’architecture.
“ La vraie valeur de Claude ici n’est pas de générer un plan plausible. C’est sa capacité à parcourir plusieurs sources, à confronter ce qui est déclaré à ce qui se passe réellement et à restituer les contradictions pour permettre à un architecte de prendre une décision éclairée. “
La pipeline d’architecture développée pour Evaneos
De l’expression du besoin à la création des issues dans Linear, la pipeline orchestre avec Claude les différentes étapes d’analyse, croise les sources techniques, métier et opérationnelles d’Evaneos et intègre trois gates humaines avant la génération du backlog.
Pourquoi avoir intégré trois validations humaines dans la pipeline ?
Rémy Jardinet — Architecte d’Entreprise, Eleven Labs
Parce que certaines informations peuvent être vérifiées techniquement, alors que d’autres relèvent nécessairement d’un choix d’organisation ou d’architecture.
Nous avons donc positionné trois gates humaines aux moments où cet arbitrage apporte réellement de la valeur.
La première intervient notamment sur les questions de domaines et d’attribution des responsabilités. La deuxième permet de challenger et valider la synthèse du plan avant sa décomposition opérationnelle. La troisième constitue l’approbation finale avant la création effective des issues dans Linear.
À chaque gate, Claude présente les éléments qu’il a établis, mais également les hypothèses ou questions qui restent ouvertes. L’architecte peut confirmer une proposition, la modifier ou remettre en cause une hypothèse.
Et ce dernier cas est important : une réponse humaine peut provoquer le retour vers une étape antérieure. Si l’arbitrage modifie le périmètre du projet, la pipeline peut recalculer la cartographie, les impacts ou le plan plutôt que de continuer sur une hypothèse devenue fausse.
L’objectif est donc de faire travailler Claude sur ce qu’il sait particulièrement bien systématiser, tout en conservant la responsabilité de l’architecture là où elle doit rester : chez les équipes Evaneos.
Qu’obtiennent concrètement les équipes à l’issue d’un run ?
Rémy Jardinet — Architecte d’Entreprise, Eleven Labs
Nous voulions aller beaucoup plus loin qu’un rapport d’analyse généré par une IA.
À chaque utilisation de la pipeline en production, l’objectif est d’aller beaucoup plus loin qu’un simple rapport d’analyse généré par une IA. La pipeline produit les différents artefacts nécessaires pour comprendre et exécuter le chantier : synthèse de l’analyse, hypothèses et décisions prises, cartographie de l’existant, architecture de transition et architecture cible.
Elle génère surtout un véritable projet dans Linear. Le chantier est structuré en lots et milestones puis décomposé en issues et sous-issues avec leurs dépendances et leur niveau de complexité. Les équipes techniques disposent ainsi d’un backlog directement exploitable plutôt que d’un document d’architecture qu’elles doivent ensuite retraduire manuellement en tâches.
L’ensemble des artefacts produits est également versionné dans Git.
Ce point est particulièrement important pour des transformations qui évoluent dans le temps. Si un nouvel élément apparaît pendant le chantier, la pipeline peut être rejouée avec ce nouvel entrant et mettre à jour l’analyse, les cartographies et le plan.
Nous conservons ainsi l’historique des différentes hypothèses et décisions et pouvons retracer pourquoi un plan a évolué entre son cadrage initial et son exécution.
Quels bénéfices concrets avez-vous observés depuis la mise en production ?
Nicolas Gomes — Staff Engineer, Evaneos
Depuis sa mise en production, la pipeline est utilisée par nos équipes pour accompagner le cadrage de nos transformations d’architecture. Elle a permis de diviser par deux le temps nécessaire au cadrage d’une transformation et de gagner en moyenne trois jours de travail de collecte et de synthèse par projet.
Au-delà du gain de temps, la pipeline nous permet de confronter beaucoup plus systématiquement nos hypothèses aux différentes sources disponibles. Dans 70% des cas, elle met en lumière des dépendances ou des usages qui n’auraient pas été détectés sans elle. C’est particulièrement important pour les projets de décommissionnement ou de migration, où un appelant oublié ou un usage ponctuel non identifié peut remettre en cause une décision.
Le troisième bénéfice concerne la traçabilité. Chaque hypothèse, chaque arbitrage et chaque évolution du plan est conservé et versionné. Nous pouvons ainsi comprendre quelle décision a été prise, sur quelles informations elle reposait et pourquoi elle a éventuellement évolué.
“ Ce que la pipeline nous apporte, c’est la capacité à confronter nos intuitions à la réalité du SI avant de lancer un chantier. Nous pouvons identifier des dépendances ou des usages que nous n’aurions pas forcément vus manuellement, tout en gardant la décision finale entre les mains de nos équipes. “
Enfin, l’automatisation du travail de collecte, de vérification et de synthèse permet à nos architectes et tech leads de consacrer davantage de temps aux arbitrages qui nécessitent réellement leur expertise.
