The assistant itself is internally called Simon. This post is about how Simon is actually built — the parts I think are worth talking about, not a marketing pitch.
Repo: github.com/sanayasfp/laplace-nearby.
The core of the system is SimonEngine, a small orchestrator that takes a channel-agnostic InteractionRequest and returns a channel-agnostic InteractionResponse. WhatsApp specifics — webhook payloads, message formatting, buttons and lists — live entirely in an adapter/renderer layer outside the engine. The engine itself just does four things on every message: load the user’s session context, check rate limiting, hand the message to whichever conversational flow is currently active (idle, search, or register), and save the result — always emitting an analytics side effect with the flow name, the state transition, and the latency, whether or not anything interesting happened:
async process(req: InteractionRequest): Promise<InteractionResponse> {
const context = await this.contextManager.load(req.profileId);
const flow = this.flowRegistry.get(context.session.activeFlow || IDLE);
const limitResult = this.rateLimitService.check(context.rateLimit);
if (!limitResult.allowed) {
return { messages: limitResult.notify ? [Responses.tooManyMessages(...)] : [] , ... };
}
const response = await flow.handle(req, context, interactionId);
await this.contextManager.save(req.profileId, response.contextUpdate);
return { ...response, sideEffects: [summaryEffect, ...response.sideEffects] };
}
This isn’t architecture for its own sake. It means the search logic, the registration flow, the rate limiting, and the metrics don’t need to be rewritten if a second channel (SMS, a web widget, whatever) shows up later — they were never coupled to WhatsApp in the first place.
Every incoming message needs an intent — is this a search, a registration request, small talk, a thank-you, an insult, “stop”? Routing every single message through an LLM call is the easy way to build this, and also the expensive and slow way. So intent classification is two-tiered.
FastIntentDetector runs first: a deliberately exhaustive set of regex patterns covering French, English, and local slang and abbreviations you’d actually see in a WhatsApp chat in Abidjan — “wesh,” “cc,” “gab” (cash machine), “essence/gazoil” (fuel), dozens of spelling variants of “merci,” “stop,” “annule.” Its docstring says exactly what it’s for: “Reduce LLM costs and latency for unambiguous user requests.” Only when nothing matches does IntentService fall back to Gemini (gemini-2.5-flash-lite), with temperature 0, JSON response mode, and a tight 150-token cap, asking for structured output: the intent, an extracted search keyword, and a list of semantically related terms to widen the search (“j’ai envie de porcodjo” → keyword “porcodjo restaurant”; “mon habit est sale” → “pressing nettoyage vêtement”).
Both paths report where the classification came from — REGEX or LLM — to a Prometheus counter (simonIntentTotal), so the fraction of traffic being deflected from the paid model is something you can actually watch on a dashboard, not something you have to guess at. And the Gemini call itself sits behind a circuit breaker: if it trips, the system doesn’t crash the conversation, it degrades to a neutral “chitchat” response with confidence 0 and moves on.
A huge share of real addresses given in chat aren’t geocodable strings — they’re descriptions: “je suis vers la cité Abdoulaye Diallo.” AddressCodingService takes that kind of input, checks a semantic cache (exact hash first, then embedding similarity above a 0.88 threshold) to avoid re-paying for something already resolved, and if it’s a miss, asks Gemini to turn it into a standardized address, an extracted neighborhood, and — importantly — a flag for whether the description is precise enough to geocode at all or whether the only honest answer is “ask the user to drop a GPS pin.” There’s even a dedicated dictionary of Nouchi (Abidjan street slang) terms feeding into this pipeline, because generic NLP tooling doesn’t know what a “gbaka” stop or a given neighborhood nickname refers to.
This is the part of the codebase I’m most proud of. search_nearby_places is a single Postgres function that blends three independent ranking signals for every candidate business inside a radius:
ts_rank_cd against a French tsquery) — good when the user typed something close to the business’s actual name or category.text-embedding-004, pgvector with an HNSW index) and each place’s embedding — good when the user described what they want in their own words instead of matching a label.ST_Distance over a PostGIS geography column) — because “closest” always matters, and can’t be papered over by relevance alone.These get combined with a weighted Reciprocal Rank Fusion: score = w_fts/(k + fts_rank) + w_vec/(k + vec_rank) + w_prox * proximity_term, with the weights shifting based on whether the user gave a keyword at all — 45/45/10 between text, vector, and proximity when there’s a keyword to match; 85% vector-driven when there isn’t, since full-text search has nothing to grab onto in a purely descriptive query. There’s also a “premium tier” mechanism: a second ranking pass, partitioned by tier, guarantees paying/listed businesses a small quota of slots without letting them drown out relevance for the general result set.
I later went back and rewrote this same function for performance after noticing it was doing redundant work: merging two CTEs that were reading the same rows twice, adding a LIMIT inside the vector-ranking CTE specifically so the HNSW index can short-circuit instead of sorting the entire candidate pool, and replacing two separate full materializations (general results, premium results) with a single windowed pass using ROW_NUMBER() OVER (PARTITION BY is_premium ...). That’s a genuinely satisfying kind of fix — same output, measurably less work per query — and it’s the sort of thing that only shows up once real usage patterns put pressure on a first draft.
When a place gets registered, or an interaction needs logging for analytics, or a user needs a notification, the engine doesn’t go do that work inline — it returns a plain SideEffect object describing what should happen. A PgmqSideEffectDispatcher collects these, groups them by target queue, and pushes them via pgmq.send_batch (Postgres’s own message-queue extension) inside the same database transaction that marks a newly registered place as “queued.” That detail matters: it means a place can’t end up half-registered — visible in the app but never actually indexed for search — because the status update and the queue write either both commit or neither does. Supabase Edge Functions on the other end (an analytics-worker, a place-embedding-worker, a place-tagging-worker) drain those queues asynchronously.
Fastify + TypeScript on Node.js, Prisma over Supabase Postgres (with pgvector, pgmq, PostGIS, pg_cron, and pg_net doing real work, not just sitting in a dependency list), Redis for caching and rate-limit state, Gemini for both NLU and embeddings, Geoapify for geocoding, and Prometheus metrics wired in from the start rather than bolted on later.
package.json says 0.4.0-rc.1 and I mean to leave that context in: this is a real, working system I use to reason about hybrid search and conversational engineering, actively evolving toward a 1.0 — not a finished, scaled product with a client roster behind it. The channel-agnostic design exists specifically so that if this ever needs to be more than a WhatsApp bot, the engine underneath doesn’t need to be rebuilt.
If you want to argue about the RRF weights, tell me PostGIS was overkill, or point out a better way to structure the side-effect dispatcher — the code’s public: github.com/sanayasfp/laplace-nearby.
]]>L’assistant lui-même s’appelle en interne Simon. Ce billet parle de la façon dont Simon est réellement construit — les parties que je trouve intéressantes à raconter, pas un argumentaire commercial.
Le dépôt : github.com/sanayasfp/laplace-nearby.
Le cœur du système est SimonEngine, un petit orchestrateur qui prend en entrée une InteractionRequest indépendante du canal et renvoie une InteractionResponse tout aussi indépendante. Les spécificités WhatsApp — format des webhooks, mise en forme des messages, boutons et listes — vivent entièrement dans une couche d’adaptateurs/renderers en dehors du moteur. Le moteur lui-même fait quatre choses à chaque message : charger le contexte de session de l’utilisateur, vérifier le rate limiting, transmettre le message au flow conversationnel actif (idle, recherche, ou enregistrement), puis sauvegarder le résultat — en émettant systématiquement un effet de bord analytique avec le nom du flow, la transition d’état et la latence, qu’il se soit passé quelque chose d’intéressant ou non :
async process(req: InteractionRequest): Promise<InteractionResponse> {
const context = await this.contextManager.load(req.profileId);
const flow = this.flowRegistry.get(context.session.activeFlow || IDLE);
const limitResult = this.rateLimitService.check(context.rateLimit);
if (!limitResult.allowed) {
return { messages: limitResult.notify ? [Responses.tooManyMessages(...)] : [] , ... };
}
const response = await flow.handle(req, context, interactionId);
await this.contextManager.save(req.profileId, response.contextUpdate);
return { ...response, sideEffects: [summaryEffect, ...response.sideEffects] };
}
Ce n’est pas de l’architecture pour le plaisir. Cela signifie que la logique de recherche, le flow d’enregistrement, le rate limiting et les métriques n’auront pas besoin d’être réécrits si un second canal (SMS, un widget web, peu importe) arrive un jour — ils n’ont jamais été couplés à WhatsApp en premier lieu.
Chaque message entrant a besoin d’une intention — s’agit-il d’une recherche, d’une demande d’enregistrement, de bavardage, d’un remerciement, d’une insulte, d’un « stop » ? Faire passer chaque message par un appel LLM est la solution de facilité, et aussi la plus lente et la plus coûteuse. La classification d’intention est donc à deux étages.
FastIntentDetector s’exécute en premier : un ensemble volontairement exhaustif d’expressions régulières couvrant le français, l’anglais, et l’argot local qu’on croise réellement dans une conversation WhatsApp à Abidjan — « wesh », « cc », « gab » (guichet automatique), « essence/gazoil », des dizaines de variantes orthographiques de « merci », « stop », « annule ». Sa docstring dit exactement à quoi il sert : « Reduce LLM costs and latency for unambiguous user requests » (réduire les coûts et la latence liés au LLM pour les requêtes non ambiguës). Ce n’est que lorsque rien ne correspond que IntentService bascule sur Gemini (gemini-2.5-flash-lite), avec une température à 0, un mode de réponse JSON, et un plafond de 150 tokens, en demandant une sortie structurée : l’intention, un mot-clé de recherche extrait, et une liste de termes sémantiquement proches pour élargir la recherche (« j’ai envie de porcodjo » → mot-clé « porcodjo restaurant » ; « mon habit est sale » → « pressing nettoyage vêtement »).
Les deux chemins signalent leur origine — REGEX ou LLM — à un compteur Prometheus (simonIntentTotal), ce qui fait que la part du trafic détournée du modèle payant est quelque chose qu’on peut littéralement observer sur un dashboard, pas quelque chose qu’on devine. Et l’appel à Gemini lui-même est protégé par un circuit breaker : s’il se déclenche, le système ne plante pas la conversation, il dégrade vers une réponse neutre de type « bavardage » avec une confiance à 0, et continue.
Une grande partie des adresses données dans le chat ne sont pas des chaînes géocodables — ce sont des descriptions : « je suis vers la cité Abdoulaye Diallo ». AddressCodingService prend ce type d’entrée, vérifie d’abord un cache sémantique (hash exact, puis similarité par embedding au-delà d’un seuil de 0,88) pour éviter de repayer un traitement déjà résolu, et en cas d’échec, demande à Gemini de la transformer en adresse standardisée, un quartier extrait, et — c’est le point important — un indicateur précisant si la description est assez précise pour être géocodée, ou si la seule réponse honnête est de demander à l’utilisateur d’envoyer un point GPS. Il existe même un dictionnaire dédié de termes nouchi (l’argot de rue abidjanais) qui alimente ce pipeline, parce qu’un outillage NLP générique ne sait pas ce que désigne un arrêt de « gbaka » ou le surnom d’un quartier.
C’est la partie du code dont je suis le plus fier. search_nearby_places est une unique fonction Postgres qui combine trois signaux de classement indépendants pour chaque commerce candidat dans un rayon donné :
ts_rank_cd sur un tsquery en français) — utile quand l’utilisateur a tapé quelque chose de proche du nom ou de la catégorie réelle du commerce.text-embedding-004, pgvector avec un index HNSW) et l’embedding de chaque lieu — utile quand l’utilisateur décrit ce qu’il veut avec ses propres mots plutôt qu’en reprenant une étiquette.ST_Distance sur une colonne geography PostGIS) — parce que « le plus proche » compte toujours, et ne peut pas être compensé par la seule pertinence.Ces signaux sont combinés via une Reciprocal Rank Fusion pondérée : score = w_fts/(k + fts_rank) + w_vec/(k + vec_rank) + w_prox * proximité, avec des poids qui varient selon que l’utilisateur ait donné ou non un mot-clé — 45/45/10 entre texte, vecteur et proximité s’il y a un mot-clé à faire correspondre ; 85% piloté par le vecteur sinon, puisque la recherche texte intégral n’a rien à quoi s’accrocher dans une requête purement descriptive. Il existe aussi un mécanisme de « palier premium » : une seconde passe de classement, partitionnée par palier, garantit aux commerces payants/référencés un petit quota de places sans pour autant noyer la pertinence pour l’ensemble des résultats.
Je suis revenu plus tard réécrire cette même fonction pour la performance, après avoir remarqué qu’elle effectuait du travail redondant : fusionner deux CTE qui relisaient deux fois les mêmes lignes, ajouter une LIMIT à l’intérieur du CTE de classement vectoriel spécifiquement pour que l’index HNSW puisse s’arrêter court plutôt que de trier tout le pool de candidats, et remplacer deux matérialisations complètes séparées (résultats généraux, résultats premium) par une seule passe fenêtrée utilisant ROW_NUMBER() OVER (PARTITION BY is_premium ...). C’est le genre de correction vraiment satisfaisant — même résultat, mesurablement moins de travail par requête — et c’est le genre de chose qui n’apparaît que lorsque l’usage réel met sous pression un premier jet.
Quand un lieu est enregistré, qu’une interaction doit être journalisée pour l’analytique, ou qu’un utilisateur doit recevoir une notification, le moteur n’exécute pas ce travail en ligne — il renvoie un simple objet SideEffect décrivant ce qui doit se produire. Un PgmqSideEffectDispatcher collecte ces effets, les regroupe par file cible, et les pousse via pgmq.send_batch (l’extension de file de messages propre à Postgres) dans la même transaction de base de données que celle qui marque un lieu nouvellement enregistré comme « en attente d’indexation ». Ce détail compte : cela signifie qu’un lieu ne peut pas se retrouver à moitié enregistré — visible dans l’application mais jamais réellement indexé pour la recherche — parce que la mise à jour du statut et l’écriture dans la file valident ensemble, ou aucune des deux. Des Supabase Edge Functions en bout de chaîne (un analytics-worker, un place-embedding-worker, un place-tagging-worker) vident ces files de manière asynchrone.
Fastify + TypeScript sur Node.js, Prisma au-dessus de Supabase Postgres (avec pgvector, pgmq, PostGIS, pg_cron et pg_net qui font un vrai travail, pas juste des lignes dans un fichier de dépendances), Redis pour le cache et l’état du rate limiting, Gemini à la fois pour le NLU et les embeddings, Geoapify pour le géocodage, et des métriques Prometheus intégrées dès le départ plutôt que rajoutées après coup.
Le package.json indique 0.4.0-rc.1, et je tiens à laisser ce contexte tel quel : c’est un système réel et fonctionnel qui me sert à raisonner sur la recherche hybride et l’ingénierie conversationnelle, en évolution active vers une version 1.0 — pas un produit fini, à grande échelle, avec un portefeuille de clients derrière. La conception indépendante du canal existe précisément pour que, si ce projet doit un jour dépasser le cadre d’un bot WhatsApp, le moteur sous-jacent n’ait pas besoin d’être reconstruit.
Si vous voulez débattre des poids de la RRF, me dire que PostGIS était superflu, ou pointer une meilleure façon de structurer le dispatcher d’effets de bord, le code est public : github.com/sanayasfp/laplace-nearby.
]]>Code’s here: github.com/sanayasfp/car-inspect-ai.
Before touching a model, the real constraint on a project like this is data. I trained on the public Car Parts Segmentation dataset (Kitsuchart Pasupa et al.), 500 annotated images of sedans, pickups, and SUVs in COCO format, covering 18 distinct vehicle parts — bumpers, doors, lights, mirrors, hood, trunk, wheels, and so on, shot from front, back, and angled views, with plates and faces blurred for privacy. 500 images is not a lot by deep-learning standards, and that constraint shaped almost every other decision in the project.
I picked YOLO11n — the nano variant — deliberately, not just because “YOLO is what people use for object detection.” Two things mattered:
To stretch that small dataset further, preprocessing included resizing to YOLO’s expected input dimensions and augmenting with rotation (simulating different shooting angles), horizontal flips, and Gaussian noise (to make the model less sensitive to lighting variation — a real problem when photos come from random phone cameras in a parking lot, not a studio).
Training ran for 50 epochs with an 80/20 train/validation split, batch size 16, and early stopping if validation performance stalled for 10 consecutive epochs. The result: 87% mAP on the validation set, with the strongest performance on well-defined, geometrically simple parts like wheels and doors — exactly where I’d expect a detector to do best, and exactly the kind of result that tells you where to focus next (smaller/ambiguous parts like mirrors are the harder cases).
This is the part of the project I’d guess most people skip past, but it’s the part I learned the most from. The app needs to track training runs — which model, how many epochs, whether it completed, where the checkpoint lives, and whether it resumes from a previous run. Instead of pulling in SQLAlchemy for what’s fundamentally a handful of tables, I wrote a small dataclass-based model layer myself:
@dataclasses.dataclass
class TrainLogsModel(BaseModel):
_table_name = "train_logs"
name: str
epochs: int
model: str
path: str
completed: bool = Field(type=bool, default=False).set()
id: Optional[int] = Field(type=int, primary_key=True, autoincrement=True).set()
created_at: Optional[float] = Field(type=int, default=lambda: dt.now().timestamp()).set()
resumed_from: Optional[int] = Field(type=int, foreign_key="id", foreign_table=_table_name).set()
BaseModel reads the dataclass’s type annotations and field metadata and turns them into SQL column definitions (INTEGER, TEXT, REAL, with primary keys, autoincrement, and foreign keys handled explicitly), and derives table names from class names in snake_case, camelCase, or PascalCase depending on what’s asked for. It’s a fraction of what a real ORM does — no query builder, no migrations system — but building even that fraction by hand forced me to actually understand what an ORM is automating away, rather than just importing one and trusting the magic. That’s the trade I’d make again: for a project this size, writing 100 lines to understand the mechanism beat 10 lines that hide it.
That model backs a genuinely useful feature: the training page lets me pick either a fresh YOLO11n base or any previous checkpoint, kick off training, and log it — including a resumed_from foreign key back to the run it continued, so I have an actual lineage of experiments instead of a folder full of best_v2_final_FINAL.pt files.
The whole thing is wrapped in a small multi-page Streamlit app — a home page, a “register a car” page (upload front/back/left/right photos plus color and plate number), the training page described above, and a scratch page for in-progress experiments. Streamlit was the right call here specifically because it isn’t the point of the project: I wanted to spend my time on the detection model and the training/versioning story, not on hand-rolling a frontend, and Streamlit gets out of the way for that.
I want to be precise about this rather than round it up: the part-detection model and the training/versioning pipeline are working and measured (that 87% mAP figure is real, from an actual run, not an estimate). The full inspection pipeline — fusing all four angles of a vehicle into a single confident report, and moving from “these are the detected parts” to an actual damage or fraud verdict — is still active, in-progress work, not a finished product. The README lists automated damage severity scoring and vehicle-history integration as future directions, and that’s accurate: those are the roadmap, not something I’m claiming already works end-to-end.
If I were pitching what’s genuinely done today: a lightweight, honestly-benchmarked vehicle part detector, trained reproducibly, with its own minimal experiment-tracking layer built from first principles. That’s a smaller claim than “automated fraud detection system,” but it’s the true one — and it’s a better foundation to build the rest on top of.
Repo’s public if you want to see the training code, the mini-ORM, or argue that I should’ve just used SQLAlchemy: github.com/sanayasfp/car-inspect-ai.
]]>Le code est ici : github.com/sanayasfp/car-inspect-ai.
Avant de toucher au moindre modèle, la vraie contrainte d’un projet comme celui-ci, ce sont les données. J’ai entraîné le modèle sur le jeu de données public Car Parts Segmentation (Kitsuchart Pasupa et al.), 500 images annotées de berlines, pickups et SUV au format COCO, couvrant 18 parties distinctes du véhicule — pare-chocs, portes, feux, rétroviseurs, capot, coffre, roues, etc. — photographiées de face, de dos et sous des angles inclinés, avec plaques et visages floutés pour la confidentialité. 500 images, ce n’est pas énorme à l’échelle du deep learning, et cette contrainte a façonné presque toutes les décisions qui ont suivi.
J’ai choisi YOLO11n — la variante “nano” — de manière délibérée, pas simplement parce que “YOLO, c’est ce qu’on utilise pour la détection d’objets.” Deux raisons :
Pour tirer le maximum de ce petit jeu de données, le prétraitement a inclus un redimensionnement aux dimensions d’entrée attendues par YOLO, ainsi qu’une augmentation par rotation (pour simuler différents angles de prise de vue), un flip horizontal, et l’ajout de bruit gaussien (pour rendre le modèle moins sensible aux variations d’éclairage — un vrai problème quand les photos viennent d’un téléphone au hasard sur un parking, pas d’un studio).
L’entraînement s’est fait sur 50 époques avec un split 80/20 entraînement/validation, une taille de batch de 16, et un arrêt anticipé si la performance sur le jeu de validation stagnait pendant 10 époques consécutives. Résultat : 87% de mAP sur le jeu de validation, avec les meilleures performances sur les parties géométriquement bien définies comme les roues et les portes — exactement là où on s’attend à ce qu’un détecteur soit le plus fiable, et exactement le genre de résultat qui indique où concentrer les efforts ensuite (les petites parties ambiguës comme les rétroviseurs restent les cas les plus difficiles).
C’est la partie du projet que la plupart des gens survoleraient, mais c’est celle où j’ai le plus appris. L’application doit suivre les runs d’entraînement — quel modèle, combien d’époques, si l’entraînement s’est terminé, où se trouve le checkpoint, et s’il reprend un run précédent. Plutôt que d’importer SQLAlchemy pour ce qui reste fondamentalement une poignée de tables, j’ai écrit moi-même une petite couche de modèles basée sur les dataclasses :
@dataclasses.dataclass
class TrainLogsModel(BaseModel):
_table_name = "train_logs"
name: str
epochs: int
model: str
path: str
completed: bool = Field(type=bool, default=False).set()
id: Optional[int] = Field(type=int, primary_key=True, autoincrement=True).set()
created_at: Optional[float] = Field(type=int, default=lambda: dt.now().timestamp()).set()
resumed_from: Optional[int] = Field(type=int, foreign_key="id", foreign_table=_table_name).set()
BaseModel lit les annotations de type et les métadonnées de la dataclass et les transforme en définitions de colonnes SQL (INTEGER, TEXT, REAL, avec clés primaires, autoincrément et clés étrangères gérées explicitement), et déduit les noms de table à partir des noms de classe en snake_case, camelCase ou PascalCase selon le besoin. C’est une fraction de ce que fait un vrai ORM — pas de query builder, pas de système de migrations — mais écrire cette fraction à la main m’a obligé à vraiment comprendre ce qu’un ORM automatise, plutôt que d’en importer un et de faire confiance à la magie. C’est un arbitrage que je referais : pour un projet de cette taille, écrire 100 lignes pour comprendre le mécanisme valait mieux que 10 lignes qui le cachent.
Ce modèle alimente une fonctionnalité réellement utile : la page d’entraînement permet de choisir soit un YOLO11n de base, soit n’importe quel checkpoint précédent, de lancer l’entraînement et de le journaliser — y compris une clé étrangère resumed_from pointant vers le run dont il repart, ce qui me donne une vraie généalogie d’expériences plutôt qu’un dossier plein de best_v2_final_FINAL.pt.
Le tout est enveloppé dans une petite application Streamlit multi-pages — une page d’accueil, une page “enregistrer une voiture” (upload des photos avant/arrière/gauche/droite plus couleur et numéro de plaque), la page d’entraînement décrite plus haut, et une page de brouillons pour les expérimentations en cours. Streamlit était le bon choix ici précisément parce que ce n’est pas l’objet du projet : je voulais passer mon temps sur le modèle de détection et sur le suivi des entraînements, pas sur un frontend fait main, et Streamlit s’efface pour ça.
Je préfère être précis plutôt que d’arrondir : le modèle de détection des parties et le pipeline d’entraînement/versioning fonctionnent et sont mesurés (ce chiffre de 87% de mAP est réel, issu d’un run effectif, pas d’une estimation). Le pipeline d’inspection complet — fusionner les quatre angles d’un véhicule en un seul rapport fiable, et passer de “voici les parties détectées” à un véritable verdict de dommage ou de fraude — reste un chantier actif, pas un produit terminé. Le README liste la notation automatique de la gravité des dommages et l’intégration à un historique véhicule comme axes futurs, et c’est exact : c’est la feuille de route, pas quelque chose que je prétends déjà fonctionnel de bout en bout.
Si je devais résumer ce qui est réellement acquis aujourd’hui : un détecteur de parties de véhicule léger, honnêtement benchmarké, entraîné de manière reproductible, avec sa propre couche minimale de suivi d’expériences construite à partir de zéro. C’est une ambition plus modeste que “système de détection de fraude automatisé”, mais c’est la vraie — et c’est une meilleure fondation pour construire la suite.
Le dépôt est public si vous voulez voir le code d’entraînement, le mini-ORM, ou me convaincre que j’aurais dû simplement utiliser SQLAlchemy : github.com/sanayasfp/car-inspect-ai.
]]>