Sur Symfony et les traitements asynchrones, les réponses décrivent le mécanisme exact et ses pièges. Sur la fiabilité des flux de paiement, les montants, la réconciliation et le journal sont tenus avec des cas réels. Sur Doctrine et PostgreSQL, la démarche part du plan d'exécution et aboutit à un gain mesuré. La conception orientée domaine est juste mais moins développée que le reste, et Redis est bien cadré. L'usage de l'IA est borné par des tests écrits avant le code.
Bastien a tenu l'encaissement par carte et la gestion des litiges pendant quatre ans, et décrit un flux de bout en bout : webhook signé, message asynchrone, effet métier et déduplication dans la même transaction. Il anticipe les cas limites (litige partiel sur un paiement déjà remboursé) avant qu'on les lui demande. Il chiffre un gain de plusieurs secondes à quelques millisecondes sur une recherche.
Détail par exigence
Symfony et traitements asynchrones
indispensableSolide
Publie un message depuis un contrôleur minimal, déduplique dans la transaction métier et trie les échecs selon leur nature.
Fiabilité des flux de paiement
indispensableSolide
Garde les montants en entiers, vérifie les plafonds de remboursement, rapproche les paiements des fichiers bancaires et corrige par écritures.
Doctrine et PostgreSQL
indispensableSolide
Lit le plan d'exécution avant de créer un index composite, et traite aussi le chargement des relations.
Conception orientée domaine
Solide
Rattache les litiges à la transaction sans la modifier et protège l'invariant sur les montants.
Redis et cache
Solide
Exclut du cache tout ce qui engage de l'argent, et met en cache la configuration avec invalidation.
Usage de l'IA
indispensableSolide
Délègue les tâches mécaniques à l'assistant, garde le calcul sensible et verrouille par des tests écrits avant.
Points d'appui
Déduplication des événements dans la même transaction que l'effet métier, avec le cas qui l'a motivée.
Distinction entre erreurs récupérables et définitives dans la reprise des messages.
Rapprochement bancaire en trois cas, avec conservation de la ligne brute de la banque.
Index composite posé en concurrent, avec un gain mesuré.
Points de vigilance
Les verrous distribués sont décrits sans exemple chiffré de leur durée.
Les frontières entre contextes métier n'ont pas été abordées en détail.
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 clairement faire ce job
Bastien a géré l'encaissement par carte et les contestations de clients. Il explique comment éviter qu'un même paiement soit compté deux fois et comment retrouver chaque euro entre la base et la banque. Il chiffre ses améliorations de performance.
Ses points forts
Très fiable sur les flux d'argent
Anticipe les cas particuliers
Résultats chiffrés sur la performance
À creuser en entretien
Moins de détails sur l'organisation en grands blocs métier
Le cache distribué est à approfondir
Savoir-être
Quand on creuse
Anticipe le cas du paiement déjà partiellement remboursé sans y être invité.
S'intégrerait vite à une équipe core de paiement : il parle le même vocabulaire et anticipe les questions de revue.
Détail par exigence
Symfony et traitements asynchrones
indispensableSolide · 9,5/10
Handlers idempotents face aux messages rejoués · 10/10Mécanisme d'idempotence précis.j'insère l'identifiant de l'événement dans une table avec une contrainte d'unicitéRéponse
R2
Stratégie de retry et file des messages en échec · 9/10Reprise adaptée à la nature de l'erreur.on distinguait les erreurs récupérables des erreurs définitivesRéponse
R3
Fiabilité des flux de paiement
indispensableSolide · 9,3/10
Représenter les montants sans erreur d'arrondi · 10/10Règle appliquée jusque dans la CI.les flottants sont bannis, et on a une règle PHPStan maisonRéponse
R1
Rapprocher les paiements avec les relevés bancaires · 9/10Rapprochement ligne à ligne et statuts d'écart.un job de nuit qui lisait le fichier de règlement de l'acquéreurRéponse
R4
Traçabilité et journal des opérations · 9/10Journal jamais modifié.on ajoutait des écritures correctricesRéponse
R4
Doctrine et PostgreSQL
indispensableSolide · 9/10
Requêtes lentes, index et plan d'exécution · 9/10Index déduit du plan, sans blocage.j'ai créé un index composite commerçant puis date, en CONCURRENTLYRéponse
R5
Hydratation, N+1 et chargement des relations · 9/10Correction d'un N+1 réel.j'ai aussi supprimé un N+1 en chargeant les litiges avec une jointureRéponse
R5
Conception orientée domaine
Solide · 9/10
Agrégats et invariants métier · 9/10Frontière de l'agrégat respectée.ne jamais toucher à la transaction d'origineRéponse
R1
Redis et cache
Solide · 9/10
Invalidation du cache · 9/10Invalidation liée à l'action métier.une invalidation quand l'administrateur sauvegardeRéponse
R7
Verrous distribués · 9/10Durée du verrou réfléchie.un verrou avec une durée de vie un peu supérieure au temps moyen du jobRéponse
R7
Usage de l'IA
indispensableSolide · 9/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 · 9/10Tâches déléguées nommées.les tests de caractérisation, les migrations répétitives et les refactorings mécaniquesRéponse
R6
Un cas vécu où un assistant IA a changé son code ou son délai, et ce qu'il en a retenu · 9/10Cas où l'assistant s'est trompé.c'est un test de propriété qui l'a attrapéRéponse
R6