Sur Doctrine et PostgreSQL, les réponses sont solides, de la mesure au correctif. Sur Symfony et les traitements asynchrones, l'idempotence et la reprise sont couvertes, les tests moins complets. Sur la fiabilité des flux de paiement, le raisonnement est juste mais la pratique manque. La conception orientée domaine est un point fort, Redis est correct, et l'assistant IA est utilisé avec une frontière claire.
La pièce à transmettrePart telle quelle chez votre client : sans score, sans verdict, sans signal.
Revelyum
Rapport d'entretien technique
Établi pour Nordlys Conseil
Développeur PHP Symfony mid, plateforme fintech (H/F)
· Benjamin Roger · 18/10/2026
Synthèse
Benjamin décrit trois ans d'architecture hexagonale où le domaine ignore Doctrine et Symfony, avec le prix annoncé : plus de classes et un temps d'explication. Il maîtrise le diagnostic Doctrine (N+1, index composites) et raisonne juste sur les paiements, qui sont nouveaux pour lui, en disant qu'il ne connaît pas la réconciliation bancaire.
Détail par exigence
Symfony et traitements asynchrones
indispensableSolide
Rend les messages rejouables avec un identifiant unique et reprend avec délai ; les tests de transport sont moins développés.
Fiabilité des flux de paiement
indispensableSolide
Raisonne juste sur l'idempotence, le verrou court et le journal, sans pratique des paiements.
Doctrine et PostgreSQL
indispensableSolide
Diagnostique les relations et les index par la mesure et migre par étapes.
Conception orientée domaine
Solide
Isole le domaine de l'infrastructure par interfaces, avec un gain mesuré.
Redis et cache
Solide
Cache les barèmes avec invalidation à la sauvegarde et protège l'import nocturne par un verrou.
Usage de l'IA
indispensableSolide
Délègue tests et adaptateurs, relit tout et garde la frontière du domaine.
Points d'appui
Architecture hexagonale expliquée avec son gain (changer de fournisseur en deux semaines) et son coût.
Diagnostic Doctrine par le profileur puis par le plan, avec des index composites réels.
Raisonnement par analogie juste sur les paiements : clé d'idempotence, verrou court, journal.
Contrainte de schéma posée en deux temps après un verrou subi.
Points de vigilance
Aucune pratique des paiements ni de la réconciliation bancaire.
Tests fonctionnels surtout au niveau des cas d'usage, peu au niveau du transport.
Sujets abordés
Symfony et traitements asynchrones · Fiabilité des flux de paiement · Doctrine et PostgreSQL · Conception orientée domaine · Redis et cache · Usage de l'IA
Entretien conduit en autonomie par le candidat, réponses transcrites puis analysées.
L'évaluation finale appartient au recruteur : Revelyum n'émet aucune décision automatisée.
En clair
Oui, il peut faire ce job
Benjamin sait séparer le métier de la technique et accélérer des pages lentes par la mesure. Les paiements sont nouveaux pour lui, mais son raisonnement est juste et il le dit sans détour.
Ses points forts
Conception claire du métier
Résout les lenteurs par la mesure
Honnête sur les paiements
À creuser en entretien
Aucune pratique des paiements
Tests de flux à renforcer
Savoir-être
Expliquer
Présente l'architecture avec son gain et son coût.
S'intégrerait rapidement sur la conception, avec un parcours à construire sur les paiements.
Détail par exigence
Symfony et traitements asynchrones
indispensableSolide · 7,7/10
Handlers idempotents face aux messages rejoués · 8/10Idempotence correcte.on garde un identifiant de traitement avec une contrainte d'unicitéRéponse
R3
Stratégie de retry et file des messages en échec · 7/10Reprise bornée.Les échecs réessayent trois fois avec un délai croissantRéponse
R3
Découpage en services et injection de dépendances · 8/10Découpage et injection maîtrisés.Les cas d'usage dépendent d'interfaces, les adaptateurs les implémentent, et le conteneur fait le branchementRéponse
R1
Fiabilité des flux de paiement
indispensableSolide · 7,7/10
Transactions et verrous contre les doubles débits · 7/10Raisonnement juste.un verrou pessimiste sur la ligne du compte dans une transaction très courteRéponse
R4
Traçabilité et journal des opérations · 8/10Principe de traçabilité.un journal des mouvements qu'on n'efface jamaisRéponse
R4
Représenter les montants sans erreur d'arrondi · 8/10Représentation correcte.Les montants en centimes, avec la deviseRéponse
R4
Doctrine et PostgreSQL
indispensableSolide · 7,3/10
Hydratation, N+1 et chargement des relations · 8/10Cause identifiée et corrigée.Un N+1, c'est le cas le plus courantRéponse
R2
Requêtes lentes, index et plan d'exécution · 7/10Mesure avant index.j'ouvre le plan avec EXPLAIN ANALYZE pour savoir s'il manque un index compositeRéponse
R2
Migrations de schéma sans coupure de service · 7/10Méthode par étapes.on ajoute d'abord les colonnes en nullableRéponse
R5
Conception orientée domaine
Solide · 8/10
Frontières entre contextes métier · 8/10Frontière qui a prouvé son utilité.changer de fournisseur de tarification en deux semainesRéponse
R1
Redis et cache
Solide · 7,5/10
Invalidation du cache · 8/10Invalidation à l'écriture.une invalidation à la sauvegardeRéponse
R6
Verrous distribués · 7/10Cas réel de verrou.sur l'import de tarifs de nuit pour éviter qu'il ne tourne en doubleRéponse
R6
Usage de l'IA
indispensableSolide · 7,5/10
S'il code avec un assistant IA (Copilot, Cursor, Claude Code, ChatGPT…) : quelles tâches de développement il lui confie, et lesquelles il garde · 8/10Tâches déléguées.surtout pour les tests des cas d'usage et pour réécrire des adaptateursRéponse
R7
Ce qu'il ne confie jamais à l'assistant : données confidentielles, sécurité, décisions d'architecture, cas où il s'est trompé · 7/10Décision d'architecture gardée.Je garde pour moi la frontière entre domaine et infrastructureRéponse
R7