Sur Symfony et les traitements asynchrones, la reprise et la file des échecs sont décrites avec une rigueur d'exploitation. Sur la fiabilité des flux de paiement, les montants, les verrous et le journal d'audit sont maîtrisés. Sur Doctrine et PostgreSQL, la lecture du plan réel et la surveillance des relations sont en place. La conception orientée domaine est comprise dans la pratique mais le vocabulaire manque. L'usage de l'IA est borné par la relecture et par des décisions gardées.
Maxime tient une API publique avec une trentaine de partenaires sur une règle simple : un appel rejoué ne produit jamais un second effet, grâce à une clé d'idempotence et une réponse mémorisée vingt-quatre heures. Il décrit une file des échecs réellement exploitée et un journal d'audit qui a répondu à un audit externe. Il reconnaît être moins à l'aise avec le vocabulaire de conception orientée domaine.
Détail par exigence
Symfony et traitements asynchrones
indispensableSolide
Rend les appels rejouables, limite les reprises aux erreurs transitoires et exploite la file des échecs par un tableau de bord.
Fiabilité des flux de paiement
indispensableSolide
Tient les montants en entiers, choisit son verrou selon les conflits et garde un journal d'audit qui a servi lors d'un contrôle.
Doctrine et PostgreSQL
indispensableSolide
Lit le plan réel, couvre le tri par un index et surveille les relations avant la production.
Conception orientée domaine
Solide
Raisonne en modules reliés par interfaces et événements, avec un vocabulaire de conception encore incertain.
Redis et cache
Solide
Met en cache les réponses publiques peu changeantes et exclut les données de compte.
Usage de l'IA
indispensableSolide
Utilise la complétion et la revue croisée, garde la sécurité et les contrats, relit chaque diff.
Points d'appui
Clé d'idempotence avec réponse mémorisée, appliquée aux appels des partenaires.
Gestion de la file des échecs : erreurs réessayables seulement, tableau de bord, rejeu après diagnostic.
Journal d'audit en ajout seulement relié aux logs par l'identifiant de requête.
Choix entre verrou pessimiste et optimiste justifié par la fréquence des conflits.
Points de vigilance
Vocabulaire de la conception orientée domaine encore incertain (agrégat ou entité).
Pas de pratique décrite de la réconciliation avec des relevés bancaires.
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
Maxime fait fonctionner une interface utilisée par une trentaine de partenaires et a pensé à tout ce qui peut mal tourner : appels répétés, traitements en échec, besoin de retrouver qui a fait quoi. Il est moins familier du vocabulaire de conception avancé.
Ses points forts
Très fiable sur les incidents
Journal de toutes les opérations
Cadre bien son usage de l'IA
À creuser en entretien
Vocabulaire de conception à compléter
Pas de pratique citée du rapprochement bancaire
Savoir-être
Structurer sa réponse
Énumère retries, file des échecs et rejeu dans l'ordre d'une exploitation réelle.
Serait un point d'appui pour la fiabilité de l'équipe, à compléter côté vocabulaire de conception.
Détail par exigence
Symfony et traitements asynchrones
indispensableSolide · 9,5/10
Handlers idempotents face aux messages rejoués · 9/10Idempotence de bout en bout.on demande aux partenaires une clé d'idempotence dans l'en-têteRéponse
R1
Stratégie de retry et file des messages en échec · 10/10Reprise ciblée sur le transitoire.Quatre tentatives avec un délai qui double, mais seulement pour les erreurs de réseau ou de baseRéponse
R2
Fiabilité des flux de paiement
indispensableSolide · 9,7/10
Représenter les montants sans erreur d'arrondi · 10/10Aucun flottant dans le métier.En entiers de centimes avec un code de deviseRéponse
R4
Transactions et verrous contre les doubles débits · 9/10Choix argumenté.un verrou pessimiste sur la ligne concernée, ou un verrou optimisteRéponse
R4
Traçabilité et journal des opérations · 10/10Contenu précis du journal.l'acteur, l'opération, l'état avant et après, l'identifiant de la requêteRéponse
R3
Doctrine et PostgreSQL
indispensableSolide · 10/10
Requêtes lentes, index et plan d'exécution · 10/10Mesure sur le réel.Je regarde le plan réel, pas le plan estiméRéponse
R5
Hydratation, N+1 et chargement des relations · 10/10Détection précoce.je surveille le profileur de Symfony en développement pour repérer les N+1Réponse
R5
Conception orientée domaine
Solide · 9/10
Frontières entre contextes métier · 9/10Frontières justes sans le vocabulaire.modules qui ne se connaissent que par leurs interfaces et par des événementsRéponse
R7
Redis et cache
Solide · 10/10
Invalidation du cache · 10/10Invalidation à la modification.une invalidation quand la ressource est modifiéeRéponse
R7
Usage de l'IA
indispensableSolide · 10/10
Son workflow avec l'assistant : découper la demande, lui donner le contexte (fichiers, conventions), tenir la taille du contexte et le coût en tokens, itérer · 10/10Contexte maîtrisé pour le coût.Je le relance avec des extraits courts plutôt qu'un gros contexteRéponse
R6
Ce qu'il ne confie jamais à l'assistant : données confidentielles, sécurité, décisions d'architecture, cas où il s'est trompé · 10/10Limites nettes.jamais les règles de sécurité ni les décisions de contrat avec les partenairesRéponse
R6