Théo Sillé

Cas pratique - Customer Operations Lead

Accompagner un client Ezus vers une extraction fiable de ses données comptables.

Qualifier le besoin, choisir la bonne réponse, et savoir quand un ticket client devient un signal produit.

Ops API SQL Automation

Section 1

Intégrations & API

Ce cas pratique, c'est aussi l'occasion de se poser une question plus large : est-on face à un besoin isolé qu'on traite et qu'on facture, ou face à un signal qui mérite de remonter au produit ? La réponse change tout à l'approche.

1.1

Qualifier le besoin avant de répondre

Avant de parler API, je clarifie ce que le client doit transmettre, à quelle fréquence et avec quel niveau d'autonomie.

?

Comprendre le besoin réel

  • Compréhesion du besoin réel et final du client
  • Type de format attendu par le client et types de factures attendues
  • Période concernée et volume attendu ?
↻

Comprendre la fréquence

  • Extraction one-shot pour une clôture ponctuelle ?
  • Envoi mensuel, hebdomadaire ou temps réel ?
  • Besoin de contrôle manuel avant transmission ?
⌘

Évaluer le contexte

  • Outil comptable déjà utilisé par le client ?
  • Profil technique disponible en interne ?
  • Signal partagé par d'autres clients Ezus ?
1.2

Arbre de décision

Deux axes suffisent pour choisir entre guidage, automation ponctuelle et signal produit.

Scénario retenu

One-shot, client isolé

On guide le client ou on construit pour lui - périmètre défini, date de fin, rôles clairs. C'est un service qu'on rend, potentiellement qu'on facture.

1.3

Modèle de données Ezus

Le rapprochement comptable s'appuie sur les projets, leurs alternatives et les références exposées dans les factures.

Agence compte Ezus API Clients GET /clients entreprises ou particuliers Projets GET /projects alternatives[].client Invoices GET /invoices global Invoices Suppliers filtre project_reference
Contrainte importante

GET /invoices ne propose pas de filtre client_reference ni project_reference. Les factures clients se rapprochent donc après récupération, via les champs invoice.client, invoice.project et les projets dont les clients sont imbriqués dans alternatives[].client. Un projet peut avoir plusieurs alternatives avec potentiellement des clients différents.

1.4

Workflow de récupération

Un flux concret, explicable au client et maintenable si le volume augmente.

  1. 01

    Authentification en deux temps : x-api-key fournie par Ezus, puis credentials utilisateur via POST /login pour obtenir un Bearer token valable 12h.

  2. 02

    Récupération des projets avec GET /projects : utiliser created_at pour filtrer par création du projet, ou trip_date_in / trip_date_out pour une période de voyage, souvent plus pertinente en comptabilité.

  3. 03

    Récupération des factures clients via GET /invoices, puis rapprochement côté traitement avec invoice.project et invoice.client.

  4. 04

    Pour les achats fournisseurs, récupération par projet avec GET /invoices-supplier?project_reference=... et, si besoin, alternative_order.

  5. 05

    Gestion de la pagination avec next_token si le volume dépasse la première page.

  6. 06

    Formatage et envoi en CSV, zip de PDFs ou email selon le besoin qualifié.

1.5

Limites à anticiper

Ce qu'il faut avoir dit avant que le client considère le workflow comme acquis.

Pagination 50 résultats par appel, boucle sur next_token nécessaire.

Format des factures les réponses exposent du JSON structuré et un champ url vers le PDF quand disponible.

Modèle centré projet impossible d'interroger les factures directement par client.

Rate limiting limites daily et burst a respecter sur les gros volumes.

Maintenabilité définir qui surveille le workflow si l'API évolue.

Section 2

SQL

Modélisation, jointures, agrégations. Les bases pour répondre à des questions métier concrètes.

2.1

Schéma de données

Six tables, avec deux colonnes polymorphiques à surveiller : item_type et item_id.

travelers

id, name, city, country, loyalty_tier

flights

id, origin, destination, airline, base_price, departure_at, arrival_at

hotels

id, name, city, country, stars, price_per_night

bookings

id, traveler_id, created_at, status

booking_items

id, booking_id, item_type, item_id, quantity, unit_price

reviews

id, traveler_id, item_type, item_id, rating, created_at

2.2

Requêtes types

Cinq requêtes, du filtre simple à la jointure polymorphique, chacune part d'une question métier concrète.

Hôtels à Barcelone avec 4 étoiles ou plus

  • Partir de hotels
  • Filtrer la ville et le niveau d'étoiles
SELECT *
FROM hotels
WHERE city = 'Barcelona'
AND stars >= 4

Voyageurs avec statut et date de réservation

  • Relier travelers et bookings
  • Utiliser la clé traveler_id
SELECT travelers.name, bookings.status, bookings.created_at
FROM travelers
JOIN bookings ON bookings.traveler_id = travelers.id

Nombre de réservations par voyageur

  • Compter les bookings
  • Grouper par voyageur et trier par activité
SELECT travelers.name, COUNT(bookings.id) AS nombre_reservations
FROM travelers
JOIN bookings ON bookings.traveler_id = travelers.id
GROUP BY travelers.name
ORDER BY nombre_reservations DESC

Voyageurs ayant fait plus de 3 réservations

  • Agréger par voyageur
  • Filtrer après agrégation avec HAVING
SELECT travelers.name, COUNT(bookings.id) AS nombre_reservations
FROM travelers
JOIN bookings ON bookings.traveler_id = travelers.id
GROUP BY travelers.name
HAVING COUNT(bookings.id) > 3
ORDER BY nombre_reservations DESC

Note moyenne des hôtels 5 étoiles

  • Filtrer reviews.item_type = 'hotel'
  • Joindre vers hotels puis moyenner les notes
SELECT hotels.name, AVG(reviews.rating) AS note_moyenne
FROM hotels
JOIN reviews ON reviews.item_id = hotels.id
WHERE reviews.item_type = 'hotel'
AND hotels.stars = 5
GROUP BY hotels.name
ORDER BY note_moyenne DESC
Bonus - Générateur SQL

Et si je pouvais simplement le dire ?

Module SQL vocal

Le SQL, c'est de la structure et de la logique - un langage que les LLMs maîtrisent mieux que la plupart des outils. S'outiller ici, c'est mettre la bonne ressource sur la bonne tâche. Et en parallèle, les bases s'acquièrent - les jointures rentrent, la dextérité vient avec la pratique.