Préparer un entretien : Business Analyst

WITH releve(id_op, reference, montant) AS (
  VALUES (1, 'A', 100), (2, 'A', 100), (3, 'B', 50)
),
comptable(id_op, reference, montant) AS (
  VALUES (4, 'A', 100), (5, 'C', 75)
),
releve_dedupe AS (
  SELECT DISTINCT reference, montant FROM releve
)
SELECT
  COALESCE(r.reference, c.reference) AS reference,
  r.montant AS montant_releve,
  c.montant AS montant_comptable,
  CASE
    WHEN r.reference IS NOT NULL AND c.reference IS NOT NULL AND r.montant = c.montant THEN 'rapproche'
    WHEN r.reference IS NOT NULL AND c.reference IS NOT NULL AND r.montant <> c.montant THEN 'ecart'
    WHEN r.reference IS NOT NULL AND c.reference IS NULL THEN 'releve_seul'
    ELSE 'comptable_seul'
  END AS status
FROM releve_dedupe r
FULL OUTER JOIN comptable c ON r.reference = c.reference;

La référence A apparaît deux fois dans releve avec le même montant 100 : c'est un doublon technique, éliminé par le DISTINCT dans releve_dedupe avant toute jointure, sinon la jointure multiplierait les correspondances. Sur ce jeu de données, le résultat exact est : A avec montant_releve 100, montant_comptable 100, status rapproche ; B avec montant_releve 50, montant_comptable NULL, status releve_seul ; C avec montant_releve NULL, montant_comptable 75, status comptable_seul. Une référence présente avec des montants différents dans les deux tables (non observée dans ce jeu) serait classée ecart et isolée pour vérification manuelle, jamais supprimée automatiquement. Le NULL du côté où une référence est absente signifie qu'aucune écriture correspondante n'existe, et ne doit jamais être interprété comme un montant de zéro.

La requête complète est exécutable telle quelle via CTE VALUES sans table externe, le doublon A/A est dédupliqué avant jointure, les statuts rapproche/releve_seul/comptable_seul/ecart sont distincts et le cas ecart isole plutôt que supprime, et le résultat numérique exact (A rapproché 100/100, B releve_seul 50/NULL, C comptable_seul NULL/75) est donné.

def consolider_centimes(montants_centimes: list[int]) -> str:
    total = sum(montants_centimes)  # entier, aucune conversion en float
    signe = '-' if total < 0 else ''
    euros, centimes = divmod(abs(total), 100)
    return f"{signe}{euros},{centimes:02d} \u20ac"
assert consolider_centimes([1999, 501, 3]) == "25,03 \u20ac"
assert consolider_centimes([]) == "0,00 \u20ac"
assert consolider_centimes([-3]) == "-0,03 \u20ac"

Avec [1999, 501, 3], la somme entière vaut 1999+501+3 = 2503 centimes. Le formatage utilise divmod(abs(total), 100) pour séparer euros et centimes, avec un signe géré séparément pour les totaux négatifs (ou, si l'on préfère, on peut restreindre explicitement la fonction aux montants non négatifs en levant une erreur sur un total négatif). Aucune opération, y compris l'affichage, ne passe par un float : diviser ou multiplier par 100.0 réintroduirait une représentation binaire imprécise pour des valeurs comme 0.1, ce qui provoquerait des écarts d'arrondi cumulés invisibles à l'œil mais détectables sur de grands volumes d'écritures. La fonction ne doit jamais arrondir une entrée qui est déjà un entier de centimes : l'arrondi n'a de sens qu'au moment de la conversion initiale d'une source décimale externe, en amont de cette fonction.

Le total en centimes vaut 2503 pour l'entrée [1999, 501, 3], aucune opération n'utilise de float y compris pour l'affichage, le formatage repose sur divmod, et les cas liste vide et montant négatif sont couverts par des assertions.

Dans ce système pédagogique, une transaction atomique regroupe la réservation d’un operation_id unique, le contrôle du solde, le débit de A, le crédit de B et l’écriture de la trace. Une contrainte d’unicité sur operation_id empêche deux requêtes concurrentes de traiter la même opération. Un simple test « déjà présent ? » suivi d’un ajout séparé ne suffit pas. Le contrôle et la mise à jour du solde doivent également être protégés contre les opérations concurrentes.

Après validation, A vaut 50000 − 7500 = 42500 centimes et B vaut 10000 + 7500 = 17500 centimes. Le total reste 60000 centimes. Si une étape échoue avant validation de la transaction, aucun des deux soldes ni la trace de réussite n’est conservé. Lors du rejeu avec le même identifiant et les mêmes paramètres, le système renvoie le résultat déjà enregistré sans mouvement supplémentaire. Le même identifiant avec un autre montant ou destinataire est rejeté comme conflit.

L’atomicité concerne le caractère indivisible de l’opération ; l’idempotence concerne son rejeu. Cette règle est définie pour l’exercice et ne décrit pas un réseau bancaire réel.

Les soldes finaux 42500 et 17500 sont corrects. Débit, crédit, identifiant unique et trace de réussite sont atomiques ; l’unicité résiste aux requêtes concurrentes. Le rejeu identique renvoie le résultat existant et un rejeu aux paramètres différents est rejeté.